Editing Openai/69666c6a-17e0-8013-a33a-7965005f7b6a (section)

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

====== 4.1. Три объекта, которые MUST быть названы в любом сравнении ======
# Бюджет вычислений B Единица — FLOPs (или другая измеримая единица, но фиксированная в рамках сравнения). В расчёт включайте то, что реально платите: обучение + вычисление предсказаний на отложенной выборке. arXiv<ref>{{cite web|title=arXiv|url=https://arxiv.org/html/2601.03220v1|publisher=arxiv.org|access-date=2026-01-15}}</ref>
# Семейство вероятностных предсказателей F Это не «модель вообще», а конкретный класс реализуемых предсказателей (архитектура, токенизация/представление, формат входа‑выхода, допустимые процедуры обучения). В статье формализуется идея «модели, которая умеет сэмплировать и вычислять вероятность за заданное время», а в практических оценках — «семейство нейросетей с фиксированной процедурой обучения». arXiv<ref>{{cite web|title=arXiv|url=https://arxiv.org/html/2601.03220v1|publisher=arxiv.org|access-date=2026-01-15}}</ref>
# Вариант данных D_var Это конкретно: источник + очистка + дедуп + формат примера + порядок/факторизация полей + (если есть) генератор синтетики + параметры генерации.

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

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

Определите:
* <code>L_model(B; F, D_var)</code> — битовый объём модели Число бит, необходимое, чтобы описать выбранную вероятностную модель так, чтобы её можно было воспроизвести в рамках заданной вычислимости (в статье это длина описания «программы модели» в оптимальном двухчастном коде). arXiv<ref>{{cite web|title=arXiv|url=https://arxiv.org/html/2601.03220v1|publisher=arxiv.org|access-date=2026-01-15}}</ref> Практическая интерпретация для инженера: сколько информации «перешло» из данных в параметры/структуру предсказателя при обучении в этом бюджете.
* <code>L_resid(B; F, D_var)</code> — остаточные биты на данные Ожидаемая длина кодирования отложенных примеров при наличии этой модели. В ML‑терминах это пропорционально средней отрицательной лог‑вероятности (кросс‑энтропии) на тесте. arXiv<ref>{{cite web|title=arXiv|url=https://arxiv.org/html/2601.03220v1|publisher=arxiv.org|access-date=2026-01-15}}</ref> Практическая интерпретация: то, что даже лучшая вычислимо‑достижимая модель из вашего семейства всё ещё не умеет предсказывать (детали, шум, непредсказуемость).

Сумма L_total = L_model + L_resid — «сколько бит нужно, чтобы описать данные при ваших вычислениях», где часть бит платится «за модель», а часть — «за оставшуюся непредсказуемость». arXiv<ref>{{cite web|title=arXiv|url=https://arxiv.org/html/2601.03220v1|publisher=arxiv.org|access-date=2026-01-15}}</ref>

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

Режим A — быстрая инженерная оценка по кривой потерь (prequential‑оценка).
Используйте сохранённые точки кривой потерь (валидационная потеря vs объём обучения/compute). В статье описан способ оценивать модельную часть как площадь между кривой и финальным уровнем потерь (в битах), что даёт приближение к «сколько нужно передать, чтобы декодер восстановил параметры, повторив обучение». arXiv<ref>{{cite web|title=arXiv|url=https://arxiv.org/html/2601.03220v1|publisher=arxiv.org|access-date=2026-01-15}}</ref>

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

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

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

(i) Выбор источников (портфель данных).
Оптимизируйте не «потерю вообще», а профиль <code>⟨L_model, L_resid⟩</code> при вашем бюджете.
* Если цель — переносимость на новые задачи/распределения, отдавайте приоритет вариантам данных, у которых при вашем B заметно больше L_model (модель вынуждена хранить больше переносимых механизмов), а L_resid не доминирует. В статье мотивируется связь этой «модельной части» с переносимостью и приводятся сравнения между доменами данных. arXiv<ref>{{cite web|title=arXiv|url=https://arxiv.org/html/2601.03220v1|publisher=arxiv.org|access-date=2026-01-15}}</ref>
* Если L_resid огромен при низком L_model, это сигнал: данные содержат много деталей, которые при данном B остаются непредсказуемыми и плохо конвертируются в переносимые параметры (в статье так интерпретируется пример с изображениями относительно текста). arXiv<ref>{{cite web|title=arXiv|url=https://arxiv.org/html/2601.03220v1|publisher=arxiv.org|access-date=2026-01-15}}</ref>

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

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

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

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

(iv) Онлайн‑подбор смеси данных во время предобучения.
Если вы используете алгоритмы, которые перераспределяют доли подмножеств по сигналам обучения (например, по скорости убывания потерь), интерпретируйте это как попытку увеличивать L_model в рамках бюджета. В статье обсуждается подход ADO для языковых моделей и его связь с ростом модельной части и с downstream‑качеством. arXiv<ref>{{cite web|title=arXiv|url=https://arxiv.org/html/2601.03220v1|publisher=arxiv.org|access-date=2026-01-15}}</ref>

====== 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‑проверок» (назвать бенчмарки/срезы)