Openai/69675db8-b8dc-8013-8d6c-c3552df72868

This conversation was exported from ChatGPT

gpt-5-2-pro

User: В файле у тебя спецификация FPF.

В файле у тебя спецификация FPF. Прочти полный текст статьи https://arxiv.org/abs/2512.21720. Пиши по-русски на основе статьи паттерн ML.5 по шаблону из E.8, применяя приёмы повышения точности из паттернов кластера A.6 (особенно A.6.P и его подпадтерны). Не используй при этом терминологию FPF, не объясняй FPF и распаковку, пиши по-русски, добавь дидактичности, текст итогового паттерна будут читать инженеры-менеджеры. В паттерне используй не оригинальные понятия из статьи, а только "распакованные" (восстановленная semantic precision) понятия. Следи, чтобы в тексте не проскакивали нераспакованные понятия, которые в A.6.P и его специализациях заявлены как red-flag. Проверь, чтобы вместо одного невнятного перегруженного понятия ты не выбрал в качестве замены другое, столь же перегруженное (скажем, вместо "якоря" использовать "основу" или "базу" - это слишком общие понятия, они не отражают онтологию предметной области, это метафоры, а не точные объекты, с этим и имеет дело A.6.P и его специализации. Если нужной специализации не найдётся, используй A.6.P напрямую). Все остальные паттерны используй в тексте по потребности. Учти также ещё и вот этот паттерн ML.4:

ML.4 — Двухчастная оценка данных через «битовый объём модели» при заданном бюджете вычислений

Type: Architectural (A)

Status: Proposed

ML.4:1 - Problem frame — Когда «перплексия лучше» не отвечает на вопрос «какие данные покупать/генерировать/упорядочивать»

Команды, которые обучают большие модели (языковые, мультимодальные, рекомендательные), регулярно принимают решения уровня «портфель данных»:

• какие источники включить в смесь (веб‑текст, код, диалоги, доменные документы, логи, изображения),
• какие преобразования применить (дедупликация, фильтры, синтетические добавки, симуляции),
• в каком порядке предъявлять примеры (куррикулум, перестановки полей, последовательность задач),
• и всё это под ограничением по FLOPs/времени/деньгам.

Типичная практика — опираться на среднюю потерю на отложенной выборке (для LM — кросс‑энтропия/перплексия) и считать, что «если потеря ниже, то данные лучше». Статья Finzi et al. (2026) показывает, что такая опора неполна: одна и та же величина потерь может скрывать радикально разное количество «переносимых в параметры» зависимостей, и именно эта «переносимая часть» часто важнее для переносимости на задачи вне распределения обучения. ([arXiv][1])

В этой же работе демонстрируется, что:

• детерминированная генерация (симуляции/само‑игра/процедурные миры) может давать данные, которые требуют более сложной модели, чем «правила генератора», если обратная реконструкция скрытых причин вычислительно трудна; ([arXiv][1])
• порядок и факторизация наблюдений (что показывать «сначала») могут менять то, какие вычислимые модели выгодно выучиваются при заданных FLOPs, и это коррелирует с переносимостью; ([arXiv][1])

ML.4:2 - Problem — Отсутствует инженерная метрика, которая разделяет «остаточную непредсказуемость» и «регулярности, записанные в параметры»

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

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

Одна скалярная «потеря на тесте» даёт только часть картины: она измеряет, сколько бит в среднем остаётся для кодирования примеров после обучения (то есть «остаточную непредсказуемость» для выбранного семейства моделей в выбранном режиме обучения). Статья вводит разложение двухчастного кода на:

1. длину описания вычислимо‑достижимой вероятностной модели,
2. и ожидаемую длину кодирования данных при наличии этой модели. ([arXiv][1])

Без такого разложения команда неизбежно скатывается к неоперациональным словам («качество», «информативность», «сложность», «разнообразие») и к решениям, которые трудно защищать, воспроизводить и проверять на переносимость.

ML.4:3 - Forces — Требования, которые тянут решение в разные стороны

1. Ограничение по бюджету вычислений. Метрика должна быть определима для конкретного потолка FLOPs/времени (и не смешивать результаты, полученные при разных потолках).
2. Сопоставимость вариантов данных. Нужно сравнивать источники и преобразования данных без обязательного прогона большого набора downstream‑бенчмарков на каждом шаге (дорого и медленно).
3. Управляемость в продакшене. Метрика должна превращаться в «карточку решения» для менеджеров: что изменили, зачем, чем подтверждено, какой риск.
4. Устойчивость к «накрутке». Любая оптимизируемая метрика становится целью. Нужны ограничения, чтобы «улучшение» метрики не превращалось в искусственное усложнение предсказания без полезной переносимости.
5. Вариативность семейств моделей. То, что «выучивается», зависит от архитектуры/оптимизатора/токенизации; нужно явно фиксировать эти параметры, иначе сравнение превращается в смешение причин.

ML.4:4 - Solution — Введите «битовый объём модели» и отделите его от «остаточных бит на данные» при заданном бюджете

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

1. Бюджет вычислений B

  Единица — FLOPs (или другая измеримая единица, но фиксированная в рамках сравнения). В расчёт включайте то, что реально платите: обучение + вычисление предсказаний на отложенной выборке. ([arXiv][1])

1. Семейство вероятностных предсказателей F

  Это не «модель вообще», а конкретный класс реализуемых предсказателей (архитектура, токенизация/представление, формат входа‑выхода, допустимые процедуры обучения). В статье формализуется идея «модели, которая умеет сэмплировать и вычислять вероятность за заданное время», а в практических оценках — «семейство нейросетей с фиксированной процедурой обучения». ([arXiv][1])

1. Вариант данных D_var

  Это конкретно: источник + очистка + дедуп + формат примера + порядок/факторизация полей + (если есть) генератор синтетики + параметры генерации.

4.2. Две величины вместо одной: «битовый объём модели» и «остаточные биты на данные»

Для заданных B, F, D_var рассмотрите наилучший (в смысле минимальной суммарной длины двухчастного кода) предсказатель, который вы можете получить в этом бюджете.

Определите:

• L_model(B; F, D_var) — битовый объём модели

 Число бит, необходимое, чтобы описать выбранную вероятностную модель так, чтобы её можно было воспроизвести в рамках заданной вычислимости (в статье это длина описания «программы модели» в оптимальном двухчастном коде). ([arXiv][1])
 Практическая интерпретация для инженера: сколько информации «перешло» из данных в параметры/структуру предсказателя при обучении в этом бюджете.

• L_resid(B; F, D_var) — остаточные биты на данные

 Ожидаемая длина кодирования отложенных примеров при наличии этой модели. В ML‑терминах это пропорционально средней отрицательной лог‑вероятности (кросс‑энтропии) на тесте. ([arXiv][1])
 Практическая интерпретация: то, что даже лучшая вычислимо‑достижимая модель из вашего семейства всё ещё не умеет предсказывать (детали, шум, непредсказуемость).

Сумма L_total = L_model + L_resid — «сколько бит нужно, чтобы описать данные при ваших вычислениях», где часть бит платится «за модель», а часть — «за оставшуюся непредсказуемость». ([arXiv][1])

4.3. Как оценивать L_model на практике (два режима)

Режим A — быстрая инженерная оценка по кривой потерь (prequential‑оценка). Используйте сохранённые точки кривой потерь (валидационная потеря vs объём обучения/compute). В статье описан способ оценивать модельную часть как площадь между кривой и финальным уровнем потерь (в битах), что даёт приближение к «сколько нужно передать, чтобы декодер восстановил параметры, повторив обучение». ([arXiv][1])

Режим B — более строгая оценка через кодирование «учитель→ученик» (requential‑оценка). Если нужно более надёжное сравнение вариантов данных, используйте процедуру, где модель‑«учитель» задаёт последовательность распределений, а «ученик» обучается на сгенерированных токенах, а длина кода выражается через накопленную дивергенцию между распределениями учителя и ученика по шагам. В статье это предложено как способ получить более точную оценку модельной части при заданной вычислимости. ([arXiv][1])

Практическое правило:

• для ранжирования 10–30 кандидатов и быстрой итерации чаще достаточно режима A;
• для решения “влить миллионы $ в новый источник данных” включайте режим B хотя бы на финальном шорт‑листе.

4.4. Как использовать разложение для решений о данных

(i) Выбор источников (портфель данных). Оптимизируйте не «потерю вообще», а профиль ⟨L_model, L_resid⟩ при вашем бюджете.

• Если цель — переносимость на новые задачи/распределения, отдавайте приоритет вариантам данных, у которых при вашем B заметно больше L_model (модель вынуждена хранить больше переносимых механизмов), а L_resid не доминирует. В статье мотивируется связь этой «модельной части» с переносимостью и приводятся сравнения между доменами данных. ([arXiv][1])

• Если L_resid огромен при низком L_model, это сигнал: данные содержат много деталей, которые при данном B остаются непредсказуемыми и плохо конвертируются в переносимые параметры (в статье так интерпретируется пример с изображениями относительно текста). ([arXiv][1])

(ii) Преобразования данных (очистка, генерация, симуляции). Сравнивайте D_var до/после преобразования по профилю ⟨L_model, L_resid⟩ при фиксированном B.

• Полезное преобразование для переноса часто проявляется как рост L_model без взрыва L_resid.
• Преобразование, которое «делает задачу предсказания тяжелее» только за счёт шума, обычно увеличит L_resid и почти не увеличит L_model.

В статье подчёркивается, что вычислительная ограниченность делает возможным сценарий, когда детерминированная генерация (включая симуляции) повышает «информационное содержимое для вычислимого ученика», потому что обратное восстановление причин может быть вычислительно трудным. ([arXiv][1])

(iii) Порядок/факторизация обучающих примеров (куррикулум). Отдельно рассматривайте «что именно предсказывает модель на каждом шаге». Перестановка факторов может менять, какие вычислимые стратегии становятся выгодны.

В статье показан пример с шахматами: вариант, где сначала предъявляется доска, а затем ходы, даёт более высокий «модельный битовый объём» и лучшую переносимость на задачу оценки позиции при близкой точности на задаче из распределения обучения. ([arXiv][1])

(iv) Онлайн‑подбор смеси данных во время предобучения. Если вы используете алгоритмы, которые перераспределяют доли подмножеств по сигналам обучения (например, по скорости убывания потерь), интерпретируйте это как попытку увеличивать L_model в рамках бюджета. В статье обсуждается подход ADO для языковых моделей и его связь с ростом модельной части и с downstream‑качеством. ([arXiv][1])

4.5. Мини‑лексикон точных формулировок (чтобы не прятать смысл за общими словами)

В документах о данных используйте конструкции вида:

• «Профиль данных при бюджете»:

 Profile(D_var | B, F) = ⟨L_model, L_resid, L_total⟩.

• «Действие над портфелем данных» (вместо неопределённых «обновили/подкрутили»):

  включить источник* S в смесь с долей w;
  исключить источник* S;
  переназначить долю* источника S с w_old на w_new;
  заменить* преобразование T_old на T_new в пайплайне подготовки;
  изменить* порядок факторизации примера (например, «часть A предсказывается по части B» вместо обратного);
  пересчитать профиль* при новом бюджете B' или новом семействе F'.

Каждая запись о действии MUST указывать: {что изменили → в каком варианте данных → при каком бюджете → для какого семейства → какой профиль получился}.

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

Слова‑триггеры, которые нельзя использовать как замену смысла в техническом решении (разрешены только в черновике, после чего MUST быть переписаны):

• «качество данных» → замените на набор метрик/профиль ⟨L_model, L_resid⟩ + конкретные показатели (дедуп‑доля, доля токсичности, доля PII и т.п.)
• «сложность данных» → замените на «битовый объём модели L_model при бюджете B и семействе F»
• «информативность» → замените на «прирост L_model при добавлении источника в смесь при фиксированном B»
• «лучше/хуже» → замените на «по какой целевой функции и при каких ограничениях» (например: «максимизируем L_model при ограничении L_resid ≤ τ и соблюдении политики безопасности»)
• «переносимость» → замените на «качество на заранее указанном наборе OOD‑проверок» (назвать бенчмарки/срезы)

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

Tell: ситуация, где метрика экономит месяцы

Команда планирует новый прогон предобучения. Есть два кандидата на “улучшение данных”:

• добавить большой объём изображений из открытого датасета,
• или купить лицензированный корпус доменных текстов.

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

После внедрения ML.4 обсуждение меняется: команда строит для обоих вариантов профили ⟨L_model, L_resid⟩ при конкретном B (под бюджет кластера) и фиксированном F (архитектура + оптимизатор). В споре появляется предмет: что именно “покупается” за FLOPs — переносимые механизмы или остаточные детали.

Show 1 (System): выбор смеси данных для предобучения LLM под бюджет

Контекст: планируется обучение трансформера; бюджет и стратегия подбираются с оглядкой на compute‑оптимальность (см. scaling‑законы Kaplan 2020 и Hoffmann 2022). ([arXiv][2])

Кандидаты данных:

• веб‑корпус (например, FineWeb‑подобная очистка веба), ([arXiv][3])
• код,
• доменные PDF/тикеты,
• синтетические диалоги (генерация моделью‑предшественником).

Шаги:

1. Фиксируем B (FLOPs) и семейство F (архитектура, токенизация, оптимизатор).
2. Для каждого D_var строим профиль ⟨L_model, L_resid⟩ в режиме A (по кривой потерь). ([arXiv][1])
3. Для 2–3 финалистов подтверждаем ранжирование режимом B (учитель→ученик). ([arXiv][1])
4. Формируем смесь:

  * увеличиваем долю источников, которые дают высокий L_model при допустимом L_resid,
  * уменьшаем долю источников, где L_resid доминирует (много непредсказуемых деталей при текущем бюджете).

Результат для менеджера: решение оформляется как «портфельная карточка» с явным B, явным F, и таблицей Profile(D_var | B, F).

Show 2 (Episteme): записка‑обоснование по перестановке факторизации примеров

Вопрос: менять ли представление обучающего примера в шахматном корпусе: «доска→ходы» или «ходы→доска».

Действия:

• вычисляем профиль ⟨L_model, L_resid⟩ для двух вариантов при одинаковом B и одном семействе F;
• дополнительно фиксируем одну OOD‑проверку (оценка позиции).

Наблюдение из статьи: вариант «доска→ходы» даёт больше модельной части и лучше переносится на оценку позиции, при близком качестве на задаче из распределения обучения. ([arXiv][1])

Вывод в записке: «Перестановка факторизации увеличивает количество бит, записываемых в параметры при заданном бюджете; эта прибавка коррелирует с переносимостью на OOD‑оценку. Риск: возможная специализация под шахматы; контроль: повторить тест на ещё одном домене последовательных данных.»

ML.4:6 - Bias-Annotation — Какие “очки” надеты в этом паттерне

• Управленческая перспектива: паттерн принуждает фиксировать бюджет и критерии, повышая воспроизводимость решений, но добавляет шаг измерений.
• Архитектурная перспектива: акцент на измеримом профиле данных; возможно недоучёт “мелких” требований (юридические ограничения, политика безопасности).
• Онтология/эпистемология: требование точных объектов (B, F, D_var, ⟨L_model, L_resid⟩) снижает риск спорить о словах, но может казаться «слишком формальным».
• Прагматика: ориентир на быстрое ранжирование по кривым потерь; риск — принять приближение за истину.
• Дидактика: вводятся короткие определения и «предохранитель» лексики; это помогает инженерам‑менеджерам, но требует дисциплины письма.

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

| ID | Requirement | Purpose | | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | CC‑ML4‑1 | Решение MUST явно назвать B (единицы вычислений) и что именно входит в бюджет (обучение, инференс на тесте). | Убирает скрытое смешение режимов. | | CC‑ML4‑2 | Решение MUST зафиксировать семейство F (архитектура + представление данных + оптимизаторный режим). | Не даёт перепутать эффект данных и эффект модели. | | CC‑ML4‑3 | Для каждого сравниваемого D_var MUST быть описано, что входит в вариант данных (источник, очистка, формат примера, порядок/факторизация). | Делает сравнение проверяемым. | | CC‑ML4‑4 | MUST публиковать профиль ⟨L_model, L_resid⟩ (и при необходимости L_total) для каждого D_var. | Разделяет переносимые механизмы и остаточную непредсказуемость. | | CC‑ML4‑5 | Если используется оценка по кривой потерь, MUST указать метод построения кривой и её дискретизацию; SHOULD приложить артефакты (логи/графики). | Контроль качества приближения. | | CC‑ML4‑6 | Любая фраза вида «данные лучше/хуже/качественнее/сложнее» MUST быть переписана в терминах профиля и ограничений. | Убирает неоперациональные слова из решения. | | CC‑ML4‑7 | Для изменения портфеля данных MUST быть записано действие из явного списка (включить/исключить/переназначить долю/заменить преобразование/сменить факторизацию) + до/после профили. | Делает историю решений аудируемой. | | CC‑ML4‑8 | SHOULD иметь хотя бы одну внешнюю проверку переносимости (OOD‑срез/другой домен) для крупных изменений. | Снижает риск оптимизации “в пустоту”. |

ML.4:8 - Common Anti-Patterns — Типовые ошибки и как их чинить

1. «Оптимизируем только тестовую потерю»

  Симптом: выбирают данные с минимальным L_resid, игнорируя L_model.
  Ремонт: публиковать профиль ⟨L_model, L_resid⟩ и вводить ограничения/цели (например: максимум L_model при пороге L_resid). ([arXiv][1])

1. «Сравниваем результаты при разных бюджетах»

  Симптом: один вариант данных оценили на маленьком прогоне, другой — на большом, затем сравнили.
  Ремонт: фиксировать B или строить кривую профиля по нескольким B и сравнивать на согласованном наборе бюджетов.

1. «Смешали изменение данных и изменение семейства модели»

  Симптом: поменяли токенизацию или оптимизатор и объявили, что “данные стали лучше”.
  Ремонт: в карточке решения разделять: изменение F и изменение D_var.

1. «Усложнили предсказание ради роста модельной части»

  Симптом: преобразование делает задачу предсказания тяжелее (рост L_model), но OOD‑проверки не улучшаются.
  Ремонт: добавлять внешние проверки переносимости и ограничивать рост L_resid.

1. «Слова‑заменители вместо метрик»

  Симптом: в тексте решения появляются “качество/сложность/информативность/разнообразие” без явных определений.
  Ремонт: включить лексический предохранитель (см. 4.6) и требовать переписывания таких фраз.

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

Положительные эффекты

• Появляется управляемая «финансовая модель» данных: что покупаем за FLOPs — переносимые механизмы или остаточные детали.
• Можно сравнивать источники и преобразования данных без полного downstream‑цикла на каждой итерации.
• Решения о синтетике и куррикулуме получают количественную опору, а не спор о вкусах. ([arXiv][1])

Издержки и риски

• L_model — оценка относительно F и режима обучения; переносимость между семействами моделей ограничена.
• Приближения по кривым потерь чувствительны к качеству логов, стабильности оптимизации и гиперпараметров.
• Есть риск «натренировать» организацию оптимизировать профиль и забыть про продуктовые требования (безопасность, юрисдикции, приватность).

ML.4:10 - Rationale — Почему разложение работает как инженерный инструмент

Ключевой ход статьи: рассматривать обучение как построение вероятностного предсказателя при ограничении вычислимости и описывать данные двухчастным кодом:

• первая часть — описание модели, которую реально можно получить/использовать в рамках бюджета;
• вторая часть — то, что модель всё ещё не предсказывает на отложенных данных.

В таком взгляде “случайность” не является абсолютным свойством данных; это свойство пары (данные, вычислимо‑достижимый класс предсказателей). Поэтому детерминированные вычисления (симуляции, само‑игра) могут создавать данные, которые для данного бюджета требуют более «богатой» модели (в смысле длины её описания), даже если для неограниченного наблюдателя правила генератора «короткие». ([arXiv][1])

Аналогично, перестановка факторизации/порядка наблюдений меняет то, какие предсказательные стратегии становятся вычислительно выгодны в обучении, и это может отражаться на переносимости. ([arXiv][1])

ML.4:11 - SoTA-Echoing — Как паттерн встраивается в современную практику (после 2015)

• Compute‑оптимальное масштабирование (Kaplan et al., 2020; Hoffmann et al., 2022): эти работы дают практический язык «бюджет → оптимальный размер модели и объём токенов». ML.4 добавляет к этому язык «бюджет → профиль данных ⟨L_model, L_resid⟩», то есть делает данные первоклассным объектом оптимизации рядом с размером модели. ([arXiv][2])
• Оценка ценности данных для обучения (Ghorbani & Zou, 2019): Data Shapley измеряет вклад отдельных примеров относительно конкретной целевой метрики. ML.4 дополняет это «задачно‑независимым» (в смысле отсутствия выбора downstream‑задачи) профилем данных относительно бюджета вычислений и семейства предсказателей. ([arXiv][4])
• Датасеты и курация веб‑текста на масштабе (FineWeb, 2024): современные пайплайны очистки/дедупа можно сравнивать не только по итоговой потере, но и по тому, как они меняют L_model при реальном бюджете (то есть насколько они заставляют модель хранить переносимые зависимости). ([arXiv][3])
• Онлайн‑подбор смеси данных при предобучении (обсуждение ADO в Finzi et al., 2026): практики, которые изменяют веса подмножеств по сигналам кривых потерь, можно интерпретировать как эвристику, нацеленную на рост модельной части при фиксированном бюджете. ([arXiv][1])

ML.4:12 - Relations — С чем этот паттерн стыкуется в инженерном контуре

• Телеметрия обучения: логи потерь/compute‑счётчики → вход для режима A оценки L_model. ([arXiv][1])
• Планирование ресурсов: выбор B и распределение FLOPs между размером модели и количеством токенов (scaling laws). ([arXiv][2])
• Данные как портфель: процедуры включения/исключения источников и замены преобразований должны ссылаться на профили ⟨L_model, L_resid⟩ до/после.
• Контроль переносимости: внешние OOD‑проверки как предохранитель от оптимизации «в пустоту». ([arXiv][1])

ML.4:End

[1]: https://arxiv.org/html/2601.03220v1 "From Entropy to Epiplexity: Rethinking Information for Computationally Bounded Intelligence" [2]: https://arxiv.org/abs/2001.08361?utm_source=chatgpt.com "Scaling Laws for Neural Language Models" [3]: https://arxiv.org/abs/2406.17557?utm_source=chatgpt.com "Decanting the Web for the Finest Text Data at Scale" [4]: https://arxiv.org/abs/1904.02868?utm_source=chatgpt.com "Data Shapley: Equitable Valuation of Data for Machine Learning"

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

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

Type: Architectural (A)

Status: Proposed

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

Многошаговые конвейеры на языковых моделях всё чаще строят так: один модуль обрабатывает длинные входные материалы (документы, логи, результаты поиска) и выдаёт короткий текст‑сводку, а второй модуль читает только эту сводку и генерирует итоговый ответ. Этот приём используется в прикладных системах класса «Deep Research» и «Claude Code», в том числе как способ обходить ограничения окна ввода и деградацию качества при чрезмерно длинном входе. arXiv

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

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

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

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

Статья предлагает рассматривать промежуточную сводку как сообщение, которое переносит часть сведений о входных материалах, и измерять это число в битах через оценку взаимной информации между входом и сводкой. Авторы утверждают, что эта величина позволяет предсказывать итоговую успешность конвейера без полного перебора всех пар модулей под каждую задачу. arXiv

ML.5:3 - Forces — Требования, которые тянут решение в разные стороны

1. Бюджет на запрос ограничен. Считается стоимость токенов/времени/вычислений на один запрос, а не «качество вообще».
2. Длинный вход не помещается или ухудшает результат. Поэтому появляется промежуточная сводка как отдельный артефакт, который должен быть коротким и содержательным. ar5iv
3. Слишком много ручек настройки. Выбор семейства модели, размера, подсказки, лимитов токенов, числа раундов в диалоге, параметров декодирования.
4. Параметры модулей смешивают причины. Улучшение итоговой точности может происходить из‑за более удачной сводки, а может — из‑за более сильного «ответчика».
5. Метрика должна считаться без “внутренностей”. На практике часто доступны только токен‑логвероятности (logprobs) и счётчики токенов, а не полные распределения по словарю. ar5iv
6. Риск «выиграть метрику» обходным способом. Например, если сводка начинает включать готовый ответ или подсказки к нему, сравнение модулей становится нечестным.

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

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

Чтобы сравнение было проверяемым, зафиксируйте:

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

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

Определите для вашего набора запросов средние величины:

• I_bits = I(X; Z | Q) — число бит информации о входных материалах, присутствующих в сводке при данном запросе. Инженерная интерпретация: сколько «различимых вариантов входа» модуль ответа может различить, читая только сводку, а не исходные материалы. Авторы прямо используют эту постановку «сколько информации несёт сводка о входе» и строят оценку на основе logprobs. ar5iv
• R_bits_per_tok = I_bits / |Z| — информационная плотность сводки в битах на один выходной токен. В статье это вводится как «rate / bit‑efficiency» и используется в анализе компромисса «информационная плотность ↔ ошибка». ar5iv

Дополнительно MUST фиксировать:

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

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

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

Авторы предлагают практический оцениватель, который:

• опирается на представление взаимной информации через KL‑дивергенцию,
• использует выборку отрицательных примеров из датасета,
• считается по logprobs без необходимости получать полное распределение по словарю. ar5iv

Практический рецепт (в инженерных терминах):

1. Возьмите набор примеров {(X_i, Q_i)}.
2. Для каждого i сгенерируйте сводку Z_i ~ G_sum(· | X_i, Q_i).
3. Посчитайте две величины под 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 (выборка отрицательных примеров).
4. Положите оценку Î_i = s_pos − s_neg. Усредните по i.
5. Если из‑за дисперсии выборки появляются небольшие отрицательные значения, авторы обнуляют их клиппингом. ar5iv

Важные инженерные оговорки из статьи:

• Малые модели в диапазоне 1–3B параметров могут выдавать завышенные вероятности «бессмысленным» последовательностям токенов, поэтому logprobs могут быть плохо калиброваны. ar5iv
• Чтобы стабилизировать оценку, авторы в большинстве экспериментов используют отдельную прокси‑модель масштаба 7–8B из другого семейства, и показывают, что выводы сохраняются при разных прокси‑моделях. ar5iv

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

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

Статья формулирует и эмпирически проверяет правило «переносить вычисления в модуль сводки»: при увеличении мощности модуля сводки растут и точность, и информационная плотность, а масштабирование модуля ответа даёт меньший прирост при сопоставимых затратах. arXiv

Ключевой факт для менеджера: увеличение размера модуля сводки часто уменьшает число выходных токенов сводки при сохранении или росте точности, поэтому стоимость на генерацию растёт суб‑линейно по отношению к размеру модели. Авторы прямо отмечают «меньше выходных токенов → меньше FLOPs на генерацию», и приводят примеры суб‑линейного роста FLOPs‑на‑генерацию при росте размера модели именно из‑за более коротких выходов. ar5iv

Пример из аннотации статьи (как ориентир масштаба эффектов): модуль сводки Qwen‑2.5 7B оказался 1.6× точнее, 4.6× более кратким и нёс 5.5× больше бит взаимной информации на токен, чем вариант 1.5B. arXiv

Авторы также делают мета‑анализ и получают иерархию «что важнее для итоговой правильности»: семейство модели сводки → размер модели сводки → размер модели ответа. ar5iv

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

Процедура:

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

Два практических вывода из экспериментов авторов, полезные как правила по умолчанию:

• Изменение “уровня краткости” в подсказке заметно сдвигает длину сводки и стоимость, но точность и взаимная информация почти не меняются; драйвером масштабирования выступает ёмкость модели сводки, а не формулировка “3/6/9 предложений”. ar5iv Поэтому можно экономить токены через более строгую краткость, но контроль делайте через профиль и небольшой энд‑ту‑энд прогон.
• В многораундовых протоколах добавление второго раунда увеличивает взаимную информацию, а третий раунд уже не даёт дополнительного выигрыша на их настройке; это удобно использовать как эмпирическое правило “останавливайся, когда прирост I_bits насыщается”. ar5iv

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

Шаги:

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

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

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

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

Действия:

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

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

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 — Типовые ошибки и как их чинить

1. «Меняем и сводку, и ответ, и подсказки одновременно». Симптом: непонятно, что именно дало выигрыш. Ремонт: менять ровно один элемент протокола на эксперимент и публиковать профиль до/после.
2. «Сравниваем I_bits при разных M_score». Симптом: метрика прыгает, ранжирование кандидатов неустойчиво. Ремонт: фиксировать M_score; менять её только отдельным экспериментом и заново собирать базу сравнения. ar5iv
3. «Используем плохо калиброванную малую модель для logprobs». Симптом: странно высокие вероятности бессмысленных токенов, отрицательные оценки. Ремонт: использовать более надёжную прокси‑модель, как делают авторы, или проверять выводы на альтернативной M_score. ar5iv
4. «Увеличиваем размер модуля ответа и игнорируем модуль сводки». Симптом: стоимость растёт, прирост D минимальный. Ремонт: сначала усилить G_sum и оценить рост R_bits_per_tok, затем пересмотреть G_ans. ar5iv
5. «Добавляем третий и четвёртый раунд “на всякий случай”». Симптом: растёт стоимость, а I_bits почти не растёт. Ремонт: измерять прирост по раундам и останавливаться при насыщении (в статье третий раунд не дал выигрыша на их настройке). ar5iv

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

Положительные эффекты

• Появляется измеримая «экономика конвейера»: сколько бит о входных материалах попадает в модуль ответа при заданной стоимости.
• Сокращается пространство перебора: сначала ранжируете варианты модуля сводки по R_bits_per_tok, потом делаете ограниченный энд‑ту‑энд прогон.
• Появляется практическое правило распределения бюджета: усиление модуля сводки часто даёт больший эффект и может одновременно уменьшать число токенов сводки. ar5iv

Издержки и риски

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

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

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

Авторы связывают это с анализом компромисса «информационная плотность ↔ ошибка»: они вводят R_bits_per_tok и рассматривают, как меняется ошибка при росте информационной плотности, ожидая насыщение к нижней границе (неустранимая ошибка). ar5iv

Оцениватель взаимной информации в статье выбран из прагматических соображений: он строится из logprobs и отрицательных примеров, не требует полного распределения по словарю и подходит для современных движков инференса. ar5iv

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.