Маховик данных

Определение. Маховик данных — петля обратной связи, в которой каждое решение AI и его подтверждение человеком улучшают саму систему.

TL;DR. Без маховика любой AI-проект упирается в пилот: модель не учится на ваших данных, и через полгода её точность не растёт. С маховиком — растёт. Ниже разбираем, из чего маховик собирается и почему его нельзя купить «коробкой» — только построить под себя.

Что это такое

Маховик данных (data flywheel) — архитектурная петля обратной связи в AI-системе. Её ядро простое: AI делает предложение, человек подтверждает или отклоняет, результат превращается в тестовый кейс, на котором проверяется следующая версия системы. Чем дольше система работает, тем больше у неё материала для самообучения — и тем труднее конкуренту, который начнёт через год, её догнать.

У маховика три уровня зрелости — от логирования сценариев до дообучения моделей. Уровни строятся последовательно, пропустить нельзя. Без маховика AI-проект выглядит как разовая интеграция: подключили модель, получили эффект на старте, через 6 месяцев качество не растёт, конкурент догоняет.

Из чего состоит

Уровень 1. Расширение набора проверок

Самый доступный уровень — логирование каждого решения AI плюс обратная связь человека. Система выдаёт предложение (классификацию, ранжирование, текст), человек одобряет или отклоняет. Одобрение становится положительным примером в наборе проверок, отклонение — отрицательным.

Что нужно: полное логирование контекста (запрос, параметры, время), конвейер конвертации логов в формат проверок, версионирование набора параллельно версиям системы.

Что даёт: за 6 месяцев eval-набор вырастает с 200 до 4 500 кейсов — типичный темп для процесса со средним потоком ~50 решений в день. Это операционная дисциплина, не магия. Уверенность в том, что новая версия системы не сломала старые сценарии, перестаёт быть надеждой.

Уровень 2. Обогащение через примеры (few-shot)

Лучшие записи из eval-набора подставляются в контекст следующего запроса. Модель видит, как мы это делали раньше, и подстраивается под наш контекст. Качество ответа растёт без переподготовки модели.

Что нужно: семантический поиск или эмбеддинги для примеров, контроль размера контекстного окна, кэширование частых примеров.

Что даёт: улучшение качества без задержки. Few-shot обновляется в реальном времени — не нужно ждать переподготовки модели на дни или недели.

Уровень 3. Дообучение модели (fine-tuning)

Когда в eval-наборе накопилось 10 000+ размеченных примеров, можно дообучать модель на домене. Она учится на реальных сценариях вашей компании, не на универсальном датасете.

Что нужно: MLOps-инфраструктура (конвейер переподготовки, мониторинг), валидация на отдельной выборке, механизм отката на случай ухудшения качества.

Что даёт: максимальную отдачу при максимальной сложности. Идти на этот уровень имеет смысл только когда уровни 1 и 2 уже стабильны.

Что даёт бизнесу

Дальше — два обобщённых кейса: цифры собраны по 2–3 реальным проектам в каждой области и сведены вместе. Это ориентир порядка величин, не отчёт по конкретной компании.

В антифрод-системе банка (масштаб ~50 тыс транзакций в день) до маховика реакция на новый паттерн фрода занимала 3–4 недели — ручной анализ, потом обновление правил. После трёх месяцев с расширением проверок (2 000 кейсов) время реакции упало до 2–3 дней, уверенность модели поднялась с 60 % до 78 %. После 6 месяцев и few-shot — около 85 %. После 12 месяцев и дообучения — около 91 %, доля ложных срабатываний снизилась примерно с 8 % до 3 %.

В классификации юридических контрактов у консалтинговой компании расширение проверок за 2 месяца дало эталон для сравнения новых моделей. Больше не было споров «новая нейросеть лучше или хуже» — на каждый аргумент был ответ цифрой. Few-shot принёс плюс 12 % точности без затрат на инфраструктуру. Дообучение через 8 месяцев — ещё плюс 8 % и сократило время ручной проверки примерно на 30 %.

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

С чего начать

Первый шаг — не модель и не платформа. Первый шаг — eval-набор. На неделе 1 у вас должно быть 50–100 размеченных примеров «правильное решение для нашего процесса». Это меньше, чем кажется: 2–3 часа работы доменного эксперта плюс инженер, который оформит примеры в JSON или CSV.

Ведёт это владелец процесса — тот, кто отвечает за бизнес-результат, а не за AI-стек. Инженер настраивает инфраструктуру, но критерии «правильно / неправильно» задаёт владелец. Без этой связки маховик не запустится: будут красивые логи без бизнес-смысла.

В Mid-market компании уровня 1 часто хватает на 12–18 месяцев — простой eval-набор плюс прогон новых версий на старом наборе дают ровный рост точности и не требуют дорогой инфраструктуры. В Enterprise обычно нужно за 4–6 месяцев дойти до уровня 2: объём решений такой, что без few-shot модель не успевает реагировать на изменения в данных. На уровень 3 идём только когда уровни 1 и 2 операционно стабильны и есть бюджет на MLOps-команду.

Где разваливается

Грязные данные усиливают ошибку. Маховик улучшает то, что видит чаще всего. Если в исходных данных перекос — например, 80 % обращений на русском и 20 % на казахском, — маховик его закрепит, а не исправит. Разметчик неосознанно одобряет больше русских примеров, модель становится точнее на русском и хуже на казахском, а потом мы удивляемся, почему точность на казахских клиентах падает. Лечение — раз в месяц проверять, какие группы клиентов в наборе представлены мало: по языку, региону, отрасли, периоду. И точечно добирать примеры из этих групп в разметку — даже если в реальном потоке их немного.

Деградация качества разметки. Разметчик устаёт, становится небрежным, примеры становятся шумными. Через 3–4 месяца модель учится не на правильных решениях, а на спешке уставшего человека. Лечение — раз в месяц давать двум разным разметчикам одинаковые 50 примеров и сверять оценки. Если расходятся больше чем в 20 % случаев — остановить процесс и переподготовить разметчиков.

Прыжок через уровни. Самая дорогая ошибка, особенно в Enterprise с большим бюджетом: «есть деньги — сразу дообучение». Модель выглядит лучше, потому что новая архитектура, но нет эталона для сравнения — невозможно доказать, что улучшение не случайность. Лечение — всегда начинай с уровня 1 как опорной точки, даже если кажется, что это слишком просто. Без неё все дальнейшие шаги — вера, а не инженерия.

Маховик закрепляет «вчерашний мир». Самый коварный сбой. Маховик честно крутится: каждый месяц eval-набор растёт, метрики поднимаются на 3–5 п.п., новая версия модели лучше прошлой. И всё это — на устаревшем срезе реальности. Распределение клиентских запросов сдвинулось 4 месяца назад: новый сегмент, новые типы обращений, новые требования. А маховик докручивает модель под старое распределение. Признак — eval-метрика растёт, а бизнес-показатель (CSAT, конверсия, доля решений без эскалации) стоит или падает. Лечение — раз в квартал брать 30 свежих кейсов из продакшена и проверять, попадают ли они хоть в один кластер eval-набора. Если 30 %+ — за пределами кластеров, набор перевзвешивается под актуальный поток. Это та же ловушка, что описана в тестах раньше системы — только в маховике она проявляется быстрее, потому что петля короче.

Разметчик копирует AI. Когда разметчик видит предложение AI и решает «согласен/не согласен», он невольно сдвигается к ответу модели. Через 3–4 месяца разметка теряет независимость, маховик закрепляет свои же ошибки. Лечение — 10–20 % кейсов размечать вслепую: разметчик не видит ответ AI и пишет свой с нуля. Если расхождение со «зрячей» разметкой больше 15 %, долю слепых кейсов поднимаем до 30–40 %. Для критичных по риску процессов (антифрод, медицина) слепая разметка обязательна всегда.