Editing Openai/69675db8-b8dc-8013-8d6c-c3552df72868 (section)

===== ML.5:5 - Archetypal Grounding — Tell–Show–Show =====

====== Tell: ситуация, где профиль экономит недели экспериментов ======

Команда строит внутреннего «помощника‑аналитика» для длинных отчётов и тикетов. Входные материалы на один вопрос занимают десятки тысяч токенов, и прямой вызов большой модели в облаке становится дорогим и нестабильным по качеству. В команде спорят: покупать более дорогую модель ответа или усиливать модуль сводки, и каждый вариант требует множества прогонов.

После внедрения ML.5 команда сначала сравнивает кандидатов модуля сводки по R_bits_per_tok и длине T_sum, оставляет 2–3 лучших, и только затем делает ограниченный перебор вариантов модуля ответа.

====== Show 1 (System): оптимизация конвейера «поиск → сводка → ответ» под стоимость API ======

Контекст: конвейер похож на «Deep Research»: локальный модуль делает сводки найденных материалов, облачный модуль пишет итоговый отчёт. В статье показано, что такие правила позволяют локальным моделям сводки порядка 3B параметров достигать 99% точности «фронтирной» системы при 26% стоимости API. arXiv<ref>{{cite web|title=arXiv|url=https://arxiv.org/abs/2512.21720|publisher=arxiv.org|access-date=2026-01-15}}</ref>

Шаги:
# Фиксируйте B_req как «доллары на один отчёт» и отдельным числом — задержку, которую готовы терпеть.
# Для каждого кандидата G_sum измерьте ⟨I_bits, R_bits_per_tok, T_sum, C_req⟩ на репрезентативной подвыборке запросов.
# Выберите кандидата, который даёт максимальный R_bits_per_tok при ограничении на C_req и T_sum.
# Для выбранного G_sum переберите 1–2 кандидата G_ans (например, текущую модель и следующую по цене) и сравните итоговую метрику отчёта.

Что записать в карточке решения: «При B_req = … модуль сводки X дал R_bits_per_tok = … и T_sum = …; это позволило заменить модель ответа на более дешёвую при сохранении метрики D».

====== Show 2 (Episteme): записка‑обоснование «почему увеличили модель сводки, а не ответа» ======

Вопрос: в следующем релизе есть бюджет на улучшение: увеличить размер модуля сводки или модуля ответа.

Действия:
# Зафиксируйте один набор тестов H и одну M_score.
# Оцените профили для двух изменений по отдельности: - G_sum_small → G_sum_large при фиксированном G_ans, - G_ans_small → G_ans_large при фиксированном G_sum.
# Сравните: - прирост R_bits_per_tok, - изменение T_sum (и входных токенов в модуль ответа), - изменение C_req и D.

Аргумент из статьи: в их мета‑анализе семейство и размер модуля сводки оказываются более значимыми факторами для правильности ответа, чем размер модуля ответа, а большие модели сводки часто дают ещё и более короткие сводки. ar5iv<ref>{{cite web|title=ar5iv|url=https://ar5iv.org/html/2512.21720v1|publisher=ar5iv.org|access-date=2026-01-15}}</ref>