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

===== ML.5:4 - Solution — Введите «профиль передачи информации» и оптимизируйте его при фиксированном бюджете на запрос =====

====== 4.1. Объекты, которые MUST быть названы в любом сравнении ======

Чтобы сравнение было проверяемым, зафиксируйте:
# Бюджет на запрос B_req Это одна числовая величина (например, доллары API на запрос, либо FLOPs на запрос, либо верхняя граница задержки), включающая и построение сводки, и генерацию ответа.
# Входные материалы X Это конкретный тип входа: последовательность токенов, составленная из документов/логов/фрагментов веб‑страниц и т.д., плюс правила сборки (порядок, обрезка, дедуп, формат).
# Запрос Q Это формулировка того, что нужно получить (вопрос пользователя или внутренний подзапрос конвейера).
# Модуль построения сводки G_sum Это фиксированная процедура генерации текста Z по (X, Q): модель, подсказка, стратегия декодирования, лимит длины, пост‑обработка.
# Промежуточная сводка Z Это конкретный текст (последовательность токенов), который читает модуль ответа.
# Модуль генерации ответа G_ans Это фиксированная процедура генерации ответа Y по (Z, Q).
# Оценочная модель для logprobs M_score Это модель, под которой вы считаете логвероятности токенов сводки (может совпадать с G_sum, а может быть отдельной «прокси‑моделью»).

====== 4.2. Две величины вместо одной «успешности»: биты информации и биты на токен ======

Определите для вашего набора запросов средние величины:
* <code>I_bits = I(X; Z | Q)</code> — число бит информации о входных материалах, присутствующих в сводке при данном запросе. Инженерная интерпретация: сколько «различимых вариантов входа» модуль ответа может различить, читая только сводку, а не исходные материалы. Авторы прямо используют эту постановку «сколько информации несёт сводка о входе» и строят оценку на основе logprobs. ar5iv<ref>{{cite web|title=ar5iv|url=https://ar5iv.org/html/2512.21720v1|publisher=ar5iv.org|access-date=2026-01-15}}</ref>
* <code>R_bits_per_tok = I_bits / |Z|</code> — информационная плотность сводки в битах на один выходной токен. В статье это вводится как «rate / bit‑efficiency» и используется в анализе компромисса «информационная плотность ↔ ошибка». ar5iv<ref>{{cite web|title=ar5iv|url=https://ar5iv.org/html/2512.21720v1|publisher=ar5iv.org|access-date=2026-01-15}}</ref>

Дополнительно MUST фиксировать:
* <code>T_sum = |Z|</code> — длину сводки в токенах.
* <code>C_req</code> — фактическую стоимость на запрос (по выбранной единице бюджета: деньги/время/FLOPs).

: Дидактическая проверка масштаба: если средняя сводка имеет T_sum = 200 токенов, а оценённая плотность R_bits_per_tok = 0.5, то сводка несёт около 100 бит информации о входных материалах при данном запросе. Это не «качество», а конкретный объём переданной информации.

====== 4.3. Как оценить I(X; Z | Q) на практике, имея только logprobs ======

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

Практический рецепт (в инженерных терминах):
# Возьмите набор примеров {(X_i, Q_i)}.
# Для каждого i сгенерируйте сводку Z_i ~ G_sum(· | X_i, Q_i).
# Посчитайте две величины под M_score: - s_pos = log p(Z_i | X_i, Q_i) — насколько правдоподобна эта сводка при «правильном» входе. - s_neg = log ( (1/K) * Σ_j p(Z_i | X_j, Q_i) ) — насколько правдоподобна эта же сводка при «чужих» входах X_j (выборка отрицательных примеров).
# Положите оценку Î_i = s_pos − s_neg. Усредните по i.
# Если из‑за дисперсии выборки появляются небольшие отрицательные значения, авторы обнуляют их клиппингом. ar5iv<ref>{{cite web|title=ar5iv|url=https://ar5iv.org/html/2512.21720v1|publisher=ar5iv.org|access-date=2026-01-15}}</ref>

Важные инженерные оговорки из статьи:
* Малые модели в диапазоне 1–3B параметров могут выдавать завышенные вероятности «бессмысленным» последовательностям токенов, поэтому logprobs могут быть плохо калиброваны. ar5iv<ref>{{cite web|title=ar5iv|url=https://ar5iv.org/html/2512.21720v1|publisher=ar5iv.org|access-date=2026-01-15}}</ref>
* Чтобы стабилизировать оценку, авторы в большинстве экспериментов используют отдельную прокси‑модель масштаба 7–8B из другого семейства, и показывают, что выводы сохраняются при разных прокси‑моделях. ar5iv<ref>{{cite web|title=ar5iv|url=https://ar5iv.org/html/2512.21720v1|publisher=ar5iv.org|access-date=2026-01-15}}</ref>

Практическое правило: для ранжирования вариантов <code>G_sum</code> внутри одной команды фиксируйте <code>M_score</code> и не меняйте его между экспериментами, иначе сравнение перестаёт быть сопоставимым.

====== 4.4. Инженерное правило распределения бюджета: усиливайте модуль сводки, а не модуль ответа ======

Статья формулирует и эмпирически проверяет правило «переносить вычисления в модуль сводки»: при увеличении мощности модуля сводки растут и точность, и информационная плотность, а масштабирование модуля ответа даёт меньший прирост при сопоставимых затратах. arXiv<ref>{{cite web|title=arXiv|url=https://arxiv.org/abs/2512.21720|publisher=arxiv.org|access-date=2026-01-15}}</ref>

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

Пример из аннотации статьи (как ориентир масштаба эффектов): модуль сводки Qwen‑2.5 7B оказался 1.6× точнее, 4.6× более кратким и нёс 5.5× больше бит взаимной информации на токен, чем вариант 1.5B. arXiv<ref>{{cite web|title=arXiv|url=https://arxiv.org/abs/2512.21720|publisher=arxiv.org|access-date=2026-01-15}}</ref>

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

====== 4.5. Как превратить метрику в управляемую процедуру выбора конфигурации ======

Используйте «профиль передачи информации» как карточку решения:

Profile(G_sum, G_ans | B_req, M_score, H) = ⟨ I_bits, R_bits_per_tok, T_sum, C_req, D ⟩

где H — фиксированный набор тестов, а D — выбранная ошибка/потеря (например, 1−Accuracy для задач с точным ответом). ar5iv<ref>{{cite web|title=ar5iv|url=https://ar5iv.org/html/2512.21720v1|publisher=ar5iv.org|access-date=2026-01-15}}</ref>

Процедура:
# Зафиксируйте бюджет <code>B_req</code> и протокол. Протокол включает: одна сводка или несколько раундов, лимиты токенов, правила добавления источников.
# Сформируйте 10–30 кандидатов <code>G_sum</code>. Отличайте кандидатов по семейству модели и размеру, а подсказки и лимиты меняйте как вторичные ручки.
# Посчитайте профиль <code>⟨I_bits, R_bits_per_tok, T_sum, C_req⟩</code> для каждого кандидата под одной и той же M_score.
# Оставьте шорт‑лист по <code>R_bits_per_tok</code> при ограничении на стоимость и длину. Это даёт быстрый отсев без полного перебора всех G_sum × G_ans.
# Проведите ограниченный энд‑ту‑энд прогон (например, 2–3 варианта G_ans) только на шорт‑листе, чтобы убедиться, что выбранный профиль даёт выигрыш в вашей целевой метрике D.
# Запишите решение в виде “что поменяли → какой профиль получилcя → чем подтверждено”. Это снижает риск ретроспективных споров «почему выбрали так».

Два практических вывода из экспериментов авторов, полезные как правила по умолчанию:
* Изменение “уровня краткости” в подсказке заметно сдвигает длину сводки и стоимость, но точность и взаимная информация почти не меняются; драйвером масштабирования выступает ёмкость модели сводки, а не формулировка “3/6/9 предложений”. ar5iv<ref>{{cite web|title=ar5iv|url=https://ar5iv.org/html/2512.21720v1|publisher=ar5iv.org|access-date=2026-01-15}}</ref> Поэтому можно экономить токены через более строгую краткость, но контроль делайте через профиль и небольшой энд‑ту‑энд прогон.
* В многораундовых протоколах добавление второго раунда увеличивает взаимную информацию, а третий раунд уже не даёт дополнительного выигрыша на их настройке; это удобно использовать как эмпирическое правило “останавливайся, когда прирост I_bits насыщается”. ar5iv<ref>{{cite web|title=ar5iv|url=https://ar5iv.org/html/2512.21720v1|publisher=ar5iv.org|access-date=2026-01-15}}</ref>

====== 4.6. Лексический предохранитель для обсуждений (чтобы не прятать смысл в общих словах) ======

Слова‑триггеры, которые нельзя оставлять без разъяснения в техническом решении (разрешены только как черновик, после чего MUST быть переписаны):
* «качество сводки» → переписать как ⟨I_bits, R_bits_per_tok, T_sum⟩ при фиксированных B_req, M_score, H.
* «стало лучше/хуже» → переписать как «R_bits_per_tok вырос/упал на …, T_sum изменился на …, C_req изменился на …, D изменилась на …».
* «модуль A связан с модулем B» → переписать как «G_ans получает на вход только Z, а Z сгенерирован G_sum по (X,Q); изменение G_sum изменило профиль …».
* «тот же режим/та же конфигурация» → переписать как «при фиксированных B_req, M_score, H и неизменных лимитах токенов/декодировании».
* «синхронизировали/привязали/подключили» → переписать как конкретное действие: «заменили G_sum», «изменили лимит T_sum», «добавили второй раунд запроса к модулю сводки», «перешли на другой M_score».