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

==== ML.5 — Профиль передачи информации через промежуточную сводку в многошаговых системах на языковых моделях ====

: Type: Architectural (A)
: Status: Proposed

===== ML.5:1 - Problem frame — Когда «брать модель побольше» не отвечает на вопрос «куда тратить бюджет: на сводку или на ответ» =====

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

В инженерной практике выбор «какой модуль сделать сильнее» часто решают перебором: берут несколько моделей для сводки, несколько моделей для ответа, прогоняют пары на задаче и выбирают победителя. Авторы статьи подчёркивают, что такой перебор дорогой, а объяснить, почему именно стало лучше (из‑за модуля сводки или из‑за модуля ответа), без дополнительных измерений трудно. arXiv<ref>{{cite web|title=arXiv|url=https://arxiv.org/abs/2512.21720|publisher=arxiv.org|access-date=2026-01-15}}</ref>

===== ML.5:2 - Problem — Нет управляемой метрики «сколько полезной информации дошло до модуля ответа» при фиксированной стоимости =====

Нужно уметь отвечать на управленческий вопрос:

: «При фиксированном бюджете на один запрос, какой вариант модуля сводки передаёт в модуль ответа больше релевантной информации из входных материалов, и насколько это предсказывает итоговую точность?»

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

===== ML.5:3 - Forces — Требования, которые тянут решение в разные стороны =====
# Бюджет на запрос ограничен. Считается стоимость токенов/времени/вычислений на один запрос, а не «качество вообще».
# Длинный вход не помещается или ухудшает результат. Поэтому появляется промежуточная сводка как отдельный артефакт, который должен быть коротким и содержательным. ar5iv<ref>{{cite web|title=ar5iv|url=https://ar5iv.org/html/2512.21720v1|publisher=ar5iv.org|access-date=2026-01-15}}</ref>
# Слишком много ручек настройки. Выбор семейства модели, размера, подсказки, лимитов токенов, числа раундов в диалоге, параметров декодирования.
# Параметры модулей смешивают причины. Улучшение итоговой точности может происходить из‑за более удачной сводки, а может — из‑за более сильного «ответчика».
# Метрика должна считаться без “внутренностей”. На практике часто доступны только токен‑логвероятности (logprobs) и счётчики токенов, а не полные распределения по словарю. ar5iv<ref>{{cite web|title=ar5iv|url=https://ar5iv.org/html/2512.21720v1|publisher=ar5iv.org|access-date=2026-01-15}}</ref>
# Риск «выиграть метрику» обходным способом. Например, если сводка начинает включать готовый ответ или подсказки к нему, сравнение модулей становится нечестным.

===== 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».

===== 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>

===== ML.5:6 - Bias-Annotation — Какие “очки” надеты в этом паттерне =====
* Управленческая перспектива: паттерн переводит спор «куда вкладывать бюджет» в профиль измеримых величин, но требует дисциплины измерений и фиксации протокола.
* Архитектурная перспектива: паттерн предполагает явный промежуточный текстовый артефакт Z; если ваша система работает без промежуточного текста, применимость ограничена.
* Онтология/эпистемология: «биты в сводке» — величина, зависящая от датасета H и выбранной M_score; это инструмент сравнения, а не абсолютная истина.
* Прагматика: нужен доступ к logprobs или возможность оценивать вероятности токенов; некоторые API это ограничивают.
* Дидактика: вводятся простые объекты (X, Q, Z) и профиль, чтобы менеджеры и инженеры говорили об одном и том же; это может казаться «слишком формальным», пока не накопится история решений.

===== ML.5:7 - Conformance Checklist — Что проверить перед тем как ссылаться на ML.5 в решении =====

| ID       | Requirement                                                                                                                                     | Purpose                                                  |
| -------- | ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------- |
| CC‑ML5‑1 | Решение MUST назвать B_req и перечислить, что входит в стоимость на запрос (сводка + ответ + доп. раунды).                                      | Убирает скрытое смешение бюджетов.                       |
| CC‑ML5‑2 | Решение MUST зафиксировать протокол генерации Z (подсказка, декодирование, лимит токенов, число раундов).                                       | Делает профиль воспроизводимым.                          |
| CC‑ML5‑3 | Решение MUST зафиксировать M_score (какая модель считает logprobs) и не менять её внутри сравнения кандидатов.                                  | Сохраняет сопоставимость I_bits.                         |
| CC‑ML5‑4 | Для каждого кандидата G_sum MUST публиковать ⟨I_bits, R_bits_per_tok, T_sum, C_req⟩ на одном и том же наборе H.                                 | Даёт предмет сравнения вместо «ощущений».                |
| CC‑ML5‑5 | Решение SHOULD включать ограниченный энд‑ту‑энд прогон на 2–3 финалистах, чтобы проверить, что высокий R_bits_per_tok даёт улучшение целевой D. | Снижает риск «метрика улучшилась, продукт не улучшился». |
| CC‑ML5‑6 | MUST иметь защиту от утечки ответа в Z (инструкции, формат, автоматическая проверка), если это может исказить сравнение.                        | Предотвращает нечестные улучшения.                       |
| CC‑ML5‑7 | Любая фраза «сводка/конвейер стал лучше» MUST быть переписана в терминах профиля и конкретных чисел.                                            | Убирает неоперациональные формулировки.                  |
| CC‑ML5‑8 | Если добавляются дополнительные раунды, MUST измерять прирост I_bits по раундам и останавливать рост числа раундов при насыщении.               | Не даёт наращивать сложность без измеримой отдачи.       |

===== ML.5:8 - Common Anti-Patterns — Типовые ошибки и как их чинить =====
# «Меняем и сводку, и ответ, и подсказки одновременно». Симптом: непонятно, что именно дало выигрыш. Ремонт: менять ровно один элемент протокола на эксперимент и публиковать профиль до/после.
# «Сравниваем <code>I_bits</code> при разных <code>M_score</code>». Симптом: метрика прыгает, ранжирование кандидатов неустойчиво. Ремонт: фиксировать M_score; менять её только отдельным экспериментом и заново собирать базу сравнения. ar5iv<ref>{{cite web|title=ar5iv|url=https://ar5iv.org/html/2512.21720v1|publisher=ar5iv.org|access-date=2026-01-15}}</ref>
# «Используем плохо калиброванную малую модель для logprobs». Симптом: странно высокие вероятности бессмысленных токенов, отрицательные оценки. Ремонт: использовать более надёжную прокси‑модель, как делают авторы, или проверять выводы на альтернативной M_score. ar5iv<ref>{{cite web|title=ar5iv|url=https://ar5iv.org/html/2512.21720v1|publisher=ar5iv.org|access-date=2026-01-15}}</ref>
# «Увеличиваем размер модуля ответа и игнорируем модуль сводки». Симптом: стоимость растёт, прирост D минимальный. Ремонт: сначала усилить G_sum и оценить рост R_bits_per_tok, затем пересмотреть G_ans. 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>

===== ML.5:9 - Consequences — Что вы получите и что заплатите =====

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

Издержки и риски
* Оценка I_bits зависит от M_score и от распределения входов H; переносимость между доменами требует перепроверки.
* Нужен доступ к logprobs и инфраструктура для расчёта метрики.
* Есть риск оптимизировать профиль и забыть про продуктовые требования (безопасность, приватность, юридические ограничения), которые не выражаются в I_bits.

===== ML.5:10 - Rationale — Почему «биты в сводке» предсказывают полезность конвейера =====

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

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

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

===== ML.5:11 - SoTA-Echoing — Как паттерн встраивается в современную практику =====

| Практика (после 2015)                                                   | Первичный источник                     | Что берём                                                                     | Что добавляет ML.5                                                                                                              | Статус      |
| ----------------------------------------------------------------------- | -------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ----------- |
| Многошаговые конвейеры «планирование/поиск/агрегация» на LLM            | He et al., 2025 (данная статья) 
arXiv | Декомпозицию на модуль сводки и модуль ответа + измерение передачи информации | Делает выбор конфигурации управляемым через профиль ⟨I_bits, R_bits_per_tok, T_sum, C_req⟩                                      | Adopt       |
| Агентные схемы «рассуждение + действие» (трассы, инструментальные шаги) | ReAct (2022/2023) 
Google Research
+1  | Идею промежуточных текстовых артефактов (следы рассуждений/действий)          | Даёт способ количественно сравнивать «что реально переносит промежуточный текст» между шагами                                   | Adapt       |
| Оркестрация нескольких моделей через язык как интерфейс                 | HuggingGPT (2023) 
arXiv
+1            | Язык как протокол взаимодействия модулей                                      | Добавляет метрическое сравнение вариантов «языкового протокола» через R_bits_per_tok                                            | Adapt       |
| Извлечение внешних знаний и генерация (retrieval‑augmented generation)  | RAG (Lewis et al., 2020) 
arXiv
+1     | Разделение «доступ к источникам → генерация ответа»                           | Предлагает измерять не только retrieval‑метрики, но и «сколько информации о найденном тексте дошло в сжатом виде до генератора» | Adapt       |
| Информационный подход к представлениям в нейросетях                     | Shwartz‑Ziv & Tishby (2017) 
arXiv     | Концептуальный язык компромисса «сжатие ↔ предсказание»                       | Переносит этот язык с уровня внутренних слоёв на уровень интерфейса между модулями системы                                      | Adopt/Adapt |

===== ML.5:12 - Relations — С чем этот паттерн стыкуется в инженерном контуре =====
* ML.4: если ML.4 помогает выбирать и преобразовывать обучающие данные через разложение на «то, что записалось в параметры» и «остаточную непредсказуемость», то ML.5 помогает выбирать инференс‑архитектуру через разложение на «сколько бит о входе прошло через промежуточную сводку» и «сколько стоит этот проход».
* Телеметрия инференса: счётчики токенов, логирование logprobs и затрат на запрос становятся входом для профиля ML.5.
* Планирование затрат: ML.5 превращает обсуждение «локальная сводка + облачный ответ» в измеримую оптимизацию B_req.

===== ML.5:End =====