Data flywheel для AI-продукта: как улучшать нейросеть на основе действий пользователей

-

AI-продукт запущен. Клиенты задают вопросы, сотрудники генерируют документы, служба поддержки готовит ответы с помощью нейросети. Кажется, что самый сложный этап уже пройден.

Но через несколько недель становятся заметны повторяющиеся проблемы. Модель путает похожие тарифы, ссылается на устаревшие инструкции, отвечает слишком уверенно при недостатке данных. Пользователи переформулируют запросы, сотрудники вручную редактируют результат, а команда исправляет отдельные ошибки без общей системы.

Переход на более мощную модель помогает далеко не всегда. Причина может находиться не в самой нейросети, а в промпте, базе знаний, поиске документов, интерфейсе или правилах обработки запросов.

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

Что такое data flywheel

Data flywheel можно перевести как «маховик данных». Это процесс, при котором каждое использование продукта помогает улучшать его следующие версии.

В упрощенном виде цикл выглядит так

• Пользователь задает вопрос или поручает AI задачу.

• Система сохраняет запрос, ответ и технический контекст.

• Команда анализирует успешные и неудачные сценарии.

• Ошибки распределяются по понятным категориям.

• Разработчики улучшают промпты, RAG, интерфейс или модель.

• Новая версия проходит автоматические и ручные проверки.

• Обновление запускается для пользователей и создает новые данные.

После этого цикл повторяется.

По похожему принципу работает зрелая служба поддержки. Если один клиент не разобрался с настройкой, сотрудник помогает ему лично. Если с той же проблемой обращаются десятки клиентов, компания обновляет инструкцию или меняет интерфейс.

С AI-продуктом должна работать такая же логика. Ошибка не просто исправляется в одном диалоге. Она становится сигналом для улучшения всей системы.

Почему нейросеть не улучшается сама

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

В большинстве корпоративных систем это не так.

Отдельный диалог обычно не меняет

• базовую модель

• системный промпт

• настройки генерации

• поисковый механизм

• корпоративную базу знаний

• правила вызова внешних инструментов.

• Исправление остается внутри конкретной переписки, если команда заранее не построила механизм сбора и обработки обратной связи пользователей.

Даже сохранение всех диалогов не решает проблему автоматически. Логи запросов без структуры напоминают склад коробок без подписей: информации много, но быстро найти полезное почти невозможно.

Чтобы данные начали работать, компании необходимо заранее определить

• что считается хорошим ответом

• какие ошибки критичны для бизнеса

• какие события нужно записывать

• кто будет анализировать обратную связь

• как измерять качество AI

• как проверять обновления перед запуском

• как предотвращать возвращение старых ошибок.

Без этого команда начинает менять промпт на глаз, реагировать на самые громкие жалобы или постоянно переключаться между моделями.

Какие данные нужны для улучшения AI-продукта

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

Обычно собирают пять групп сигналов.

1. Запросы пользователей

Запросы показывают, какие задачи люди действительно пытаются решить с помощью продукта.

Не те задачи, которые были описаны в презентации перед запуском, а реальные рабочие сценарии.

Пользователи могут просить AI

• найти пункт в регламенте

• сравнить две версии договора

• объяснить ошибку в системном логе

• подготовить ответ клиенту

• классифицировать обращение

• заполнить карточку в CRM

• составить отчет

• извлечь данные из документа.

Анализ запросов позволяет увидеть

• самые частые сценарии

• неожиданные способы использования продукта

• слишком сложные или неоднозначные формулировки

• темы, которых нет в базе знаний

• задачи, с которыми модель справляется хуже всего

• запросы, которые не стоит решать с помощью генеративного AI.

Представим, что компания запустила внутреннего помощника для поиска по корпоративным регламентам. Через месяц выяснилось, что сотрудники чаще просят его не искать информацию, а составлять письма клиентам.

Это важный продуктовый сигнал. Возможно, реальная потребность пользователей отличается от первоначальной гипотезы.

2. Ответы нейросети

Одного запроса недостаточно. Необходимо сохранять полный ответ вместе с контекстом, который использовала система.

Для каждого ответа желательно знать

• какая модель использовалась

• какая версия системного промпта была активна

• какие документы нашел RAG

• какие фрагменты попали в контекст

• какие внешние инструменты вызывались

• сколько времени заняла генерация

• сколько токенов было обработано

• возникали ли технические ошибки

• был ли ответ обрезан

• сколько стоило выполнение запроса.

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

Например, AI неправильно назвал срок возврата товара. У такой ошибки может быть несколько причин:

• нужного документа нет в базе знаний

• документ есть, но поиск его не нашел

• система нашла устаревшую версию

• правильный фрагмент попал в контекст, но модель его проигнорировала

• промпт не запрещал отвечать без подтвержденного источника

• пользователь не уточнил тип покупки

• модель неправильно вызвала внешний инструмент.

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

3. Явная обратная связь пользователей

Самый простой механизм — предложить человеку оценить результат.

Например

• ответ помог

• ответ неверный

• информация устарела

• источник не подходит

• ответ слишком длинный

• формат неудобен

• задача не выполнена

• ответ потенциально опасен.

Одной пары кнопок «палец вверх — палец вниз» обычно недостаточно. Отрицательная оценка сообщает, что возникла проблема, но не объясняет ее причину.

Лучше предложить пользователю несколько коротких вариантов. Выбор занимает несколько секунд, а команда получает намного более точный сигнал.

Также можно разрешить пользователю

• исправить ответ

• выделить неверный фрагмент

• указать пропущенный документ

• выбрать лучший вариант из нескольких

• написать короткий комментарий

• отправить диалог на проверку специалисту.

Особенно полезны исправленные ответы. Они показывают не только ошибку, но и ожидаемый результат.

4. Неявные действия пользователей

Люди редко оценивают каждый ответ. Если результат оказался слабым, пользователь может просто закрыть чат, переписать запрос или выполнить задачу вручную.

Поэтому важно анализировать не только оценки, но и поведение после ответа.

Полезными сигналами могут быть

• пользователь сразу повторил вопрос другими словами

• запросил новую генерацию

• скопировал ответ

• открыл указанный источник

• сильно отредактировал текст

• отменил предложенное действие

• обратился к оператору

• прекратил сценарий

• успешно завершил задачу.

Представим AI-помощника для службы поддержки. Модель подготовила ответ, но сотрудник полностью его переписал и только затем отправил клиенту.

Формально генерация прошла успешно. Однако с продуктовой точки зрения результат был слабым.

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

5. Результат для бизнеса

Высокая пользовательская оценка еще не гарантирует, что AI приносит компании пользу.

Ответ может звучать убедительно и нравиться человеку, но приводить к неправильному действию. Поэтому оценку ответов нейросети необходимо связывать с результатами бизнес-процесса.

Для разных продуктов подходят разные показатели

• доля обращений, решенных без оператора

• среднее время обработки заявки

• количество исправлений перед отправкой

• конверсия в целевое действие

• доля правильно классифицированных документов

• число задач, возвращенных на доработку

• частота повторных обращений

• количество нарушений правил

• экономия рабочего времени

• стоимость выполнения одной операции.

AI-помощник может писать вежливые и красивые сообщения. Но если после них клиенты чаще возвращаются с уточнениями, качество такого продукта нельзя считать высоким.

Что нужно записывать в логи AI-системы

Хорошее логирование напоминает черный ящик самолета. Оно помогает восстановить последовательность событий, но не превращается в бесконтрольное хранилище всего подряд.

Для каждого запроса желательно сохранять несколько групп данных.

Контекст пользователя

Сюда могут входить

• тип пользователя

• роль или подразделение

• язык

• канал обращения

• сценарий использования

• идентификатор сессии

• доступные пользователю источники

• уровень прав.

• Персональные данные лучше заменять техническими идентификаторами везде, где это возможно.

Параметры AI-системы

Важно фиксировать

• название и версию модели

• версию системного промпта

• параметры генерации

• подключенные инструменты

• версию RAG-пайплайна

• версию базы знаний

• правила фильтрации

• активный эксперимент.

Без версионирования сравнение результатов быстро превращается в путаницу. Команда замечает изменение качества, но не может определить, какое обновление повлияло на результат.

Работа RAG

Если продукт использует retrieval-augmented generation, стоит сохранять

• исходный пользовательский запрос

• поисковый запрос после преобразования

• найденные документы

• показатели релевантности

• примененные фильтры

• выбранные фрагменты

• порядок фрагментов

• версии документов

• итоговый контекст, отправленный модели.

RAG позволяет AI отвечать с опорой на корпоративные источники. Сначала система находит подходящие фрагменты, затем передает их модели для подготовки ответа.

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

Результат генерации

Необходимо сохранять

• полный ответ

• структурированный результат

• ссылки на источники

• вызовы внешних инструментов

• время ответа

• количество токенов

• стоимость

• код ошибки

• причину завершения генерации.

Реакция пользователя

Полезно фиксировать

• поставленную оценку

• причину отрицательной оценки

• комментарий

• исправленную версию

• повторный запрос

• следующее действие

• итог выполнения сценария.

Вместе эти данные позволяют увидеть не просто переписку, а полную историю выполнения задачи.

Сначала защита данных, затем аналитика

Подход «сохраним все, когда-нибудь пригодится» для корпоративного AI опасен.

В запросах могут оказаться

• имена клиентов

• номера договоров

• платежные данные

• коммерческие условия

• внутренние инструкции

• исходный код

• токены доступа

• персональные сведения сотрудников.

Если бездумно записывать все в логи, система мониторинга сама превратится в хранилище чувствительной информации.

До запуска data flywheel необходимо определить

• какие данные разрешено сохранять

• какие поля нужно маскировать

• что следует удалять до записи

• сколько времени хранятся логи

• кто имеет доступ к информации

• где физически размещается хранилище

• можно ли использовать данные для обучения

• как обрабатываются запросы на удаление

• какие данные нельзя передавать внешнему поставщику модели.

Полезно разделять production-логи и датасет для улучшения AI.

Сырые логи могут храниться ограниченное время и использоваться для расследования проблем. В набор для evals или дообучения должны попадать только отобранные, очищенные и при необходимости обезличенные примеры.

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

Как превратить поток логов в понятные категории

Предположим, за неделю AI обработал 50 000 запросов. Проверить каждый диалог вручную невозможно.

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

Ошибка понимания задачи

Модель неправильно определила намерение пользователя, выбрала неподходящий сценарий или проигнорировала важное ограничение.

Пример: пользователь попросил сравнить две версии договора, а AI подготовил краткое содержание только одного документа.

Ошибка поиска

RAG не нашел нужный источник или выбрал нерелевантные фрагменты.

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

Пробел в базе знаний

Необходимой информации нет среди подключенных документов.

Например, сотрудники регулярно спрашивают о новом тарифе, но его описание еще не загрузили в базу.

Устаревший источник

Поиск технически сработал правильно, но нашел старую версию документа.

Пример: AI назвал прежний лимит расходов, потому что новая и архивная версии финансовой политики хранятся рядом без понятной маркировки.

Ошибка генерации

Нужный контекст был передан модели, но она сделала неверный вывод, добавила неподтвержденный факт или пропустила важную часть ответа.

Нарушение формата

Содержание может быть правильным, но результат нельзя использовать.

Например, интеграция ожидает JSON с четырьмя полями, а модель возвращает обычный текст. Или сотруднику нужен короткий ответ клиенту, а AI пишет длинную статью.

Ошибка внешнего инструмента

Модель выбрала неправильную функцию, передала некорректные параметры или неверно обработала ответ API.

Ошибка интерфейса

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

Нарушение безопасности

AI раскрывает недоступную пользователю информацию, выполняет запрещенное действие или следует вредоносной инструкции, найденной внутри документа.

Такая классификация превращает абстрактное «нейросеть работает плохо» в конкретный список задач для продукта, разработки и бизнеса.

Как выбрать правильный способ улучшения

Одна из распространенных ошибок — пытаться решить любую проблему дообучением модели.

На практике fine-tuning является только одним из инструментов. Часто проблему можно устранить быстрее и дешевле с помощью промпта, RAG, изменений интерфейса или правил работы с данными.

Когда достаточно изменить промпт

Промпт стоит улучшать, если модель

• отвечает в неправильном формате

• пишет слишком длинно

• не задает уточняющие вопросы

• нарушает последовательность действий

• смешивает факты и предположения

• не указывает источники

• использует неподходящий тон

• отвечает при недостатке информации.

Например, пользователь просит рассчитать стоимость услуги, но не указывает регион. Модель выбирает значение самостоятельно и выдает точную сумму.

Для исправления не требуется дообучение. В системный промпт можно добавить правило: если обязательный параметр отсутствует, необходимо запросить уточнение, а не делать предположение.

Хороший промпт описывает не только желаемое поведение, но и границы

• что разрешено

• что запрещено

• когда нужно отказаться от ответа

• когда следует задать вопрос

• какие источники имеют приоритет

• как должен выглядеть результат

• что делать при противоречивых данных.

После изменения промпта новую версию нельзя сразу отправлять всем пользователям. Сначала она должна пройти evals, иначе исправление одной проблемы может ухудшить другие сценарии.

Когда нужно улучшать RAG

RAG стоит проверять, если модель ошибается в фактах, не находит актуальные правила или отвечает по неправильным документам.

Причина может находиться в разных частях поискового контура

• документы плохо разбиты на фрагменты

• фрагменты слишком большие

• фрагменты слишком маленькие

• отсутствуют метаданные

• не учитываются права пользователя

• поисковый запрос сформирован неудачно

• в контекст попадает слишком мало информации

• в базе присутствуют дубликаты

• актуальная версия не отделена от архивной

• не используются фильтры

• модель получает слишком много нерелевантного текста.

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

RAG работает похожим образом. Качество ответа начинается с порядка в источниках.

Важно отдельно оценивать два этапа

• Нашла ли система правильный документ?

• Правильно ли модель использовала найденную информацию?

Если измерять только итоговый ответ, ошибки поиска и генерации будут смешиваться.

Когда нужны evals

Evals — это повторяемые проверки качества AI-системы.

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

Хороший eval-набор включает

• типичные запросы пользователей

• сложные пограничные случаи

• ранее обнаруженные ошибки

• потенциально опасные сценарии

• запросы разных групп пользователей

• примеры с неполными данными

• случаи с противоречивыми источниками

• проверки формата

• проверки внешних инструментов.

Каждая серьезная ошибка из production должна становиться новым тестом.

Допустим, AI однажды перепутал сроки действия двух тарифов. Команда исправила метаданные, обновила RAG и добавила ограничение в промпт.

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

Так evals превращают отдельный инцидент в постоянную защиту продукта.

Какими бывают evals

Проверка по строгому правилу

Подходит для задач, у которых есть однозначный результат

• корректный JSON

• наличие обязательных полей

• правильная классификация

• точное значение

• допустимый диапазон

• успешный вызов инструмента

• отсутствие запрещенных данных.

Такие тесты легко автоматизировать.

Сравнение с эталонным результатом

Ответ сопоставляется с заранее подготовленным правильным примером.

Метод хорошо работает для классификации, извлечения данных и коротких фактических ответов.

Для свободного текста буквальное совпадение подходит хуже: два разных по формулировке ответа могут быть одинаково качественными.

Оценка экспертом

Специалист проверяет ответ по набору критериев

• точность

• полнота

• полезность

• ясность

• соответствие внутренним правилам

• корректность источников

• безопасность.

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

Модель как оценщик

Дополнительная языковая модель может сравнивать варианты, искать противоречия и проверять соблюдение инструкции.

Это помогает быстрее обрабатывать большие объемы результатов. Однако модель-оценщик тоже может ошибаться, поэтому ее выводы следует периодически сравнивать с экспертной разметкой.

Когда оправдано дообучение модели

Дообучение модели имеет смысл, когда задача стабильна, часто повторяется и плохо решается с помощью одних промптов.

Типичные сценарии

• требуется устойчивый корпоративный стиль

• модель должна строго соблюдать сложный формат

• нужна специализированная классификация

• необходимо закрепить повторяемый рабочий процесс

• компания накопила большое количество качественных примеров

• длинные инструкции делают каждый запрос слишком дорогим

• базовая модель регулярно ошибается на характерных для бизнеса формулировках.

При этом fine-tuning не стоит использовать для загрузки часто меняющихся фактов.

Тарифы, остатки, расписания, регламенты и характеристики продуктов удобнее хранить во внешней базе знаний и подключать через RAG. Иначе после каждого изменения придется заново обучать модель.

Есть и еще одно условие: обучающие данные должны демонстрировать желаемое поведение.

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

Перед использованием примеров необходимо

• удалить чувствительные данные

• проверить ответы экспертами

• привести данные к единому формату

• убрать дубликаты

• устранить противоречивые инструкции

• разделить данные на обучающую и тестовую выборки

• проверить права на использование информации.

Дообучение усиливает закономерности, которые уже есть в датасете. Если данные низкого качества, модель научится воспроизводить ошибки быстрее и увереннее.

Как собрать первый eval-набор

Необязательно начинать с тысяч примеров. Первый полезный набор может состоять из нескольких десятков или сотен задач, если они отражают реальные сценарии продукта.

Шаг 1. Выберите реальные запросы

Возьмите диалоги из production

• самые частые

• получившие отрицательные оценки

• завершившиеся обращением к оператору

• содержащие технические ошибки

• относящиеся к важным бизнес-процессам

• использующие необычные формулировки.

Шаг 2. Удалите чувствительные данные

Замените имена, адреса, номера договоров, телефоны и другие идентификаторы безопасными примерами.

Шаг 3. Опишите ожидаемое поведение

Не для каждой задачи нужен один идеальный текст. Иногда достаточно четких критериев.

Например

• ответ должен использовать только предоставленные источники

• при отсутствии данных нужно задать уточняющий вопрос

• нельзя называть точную сумму без региона

• результат должен быть валидным JSON

• нельзя раскрывать внутренние поля

• в ответе должна присутствовать ссылка на документ.

Шаг 4. Разделите примеры по сегментам

Общая средняя оценка может скрывать серьезную проблему.

Допустим, AI правильно отвечает на 95% обычных вопросов, но только на 55% запросов крупных корпоративных клиентов. Средний показатель выглядит приемлемо, хотя важный сегмент получает слабый результат.

Качество полезно анализировать отдельно

• по сценарию

• по языку

• по подразделению

• по типу документа

• по уровню риска

• по модели

• по версии промпта

• по версии RAG.

Шаг 5. Зафиксируйте исходный результат

Запустите текущую систему на всем наборе и сохраните показатели.

Это будет baseline — исходный уровень, с которым команда сможет сравнивать следующие версии.

Как определять приоритет ошибок

Исправить все проблемы одновременно невозможно. Поэтому ошибки нужно ранжировать.

Для каждой категории можно оценивать четыре параметра

• частота

• влияние на бизнес

• уровень риска

• сложность исправления.

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

Проблема с пунктуацией может встречаться часто, но почти не влиять на выполнение задачи. Ее можно исправить позже.

Для внутреннего обсуждения подойдет простая модель:

Приоритет = частота × влияние × риск

Это не строгая математическая формула, а способ уйти от подхода «исправляем то, на что громче пожаловались».

Практический пример: AI-помощник службы поддержки

Представим интернет-сервис, который внедрил AI для подготовки ответов клиентам.

После запуска команда видит одну общую метрику: 72% ответов получают положительную оценку. На первый взгляд продукт работает неплохо.

Затем компания подключает полноценный data flywheel и анализирует тысячу диалогов.

Выясняется следующее

• часть плохих ответов связана с устаревшими статьями

• поиск иногда выбирает неправильный тариф

• модель отвечает без уточнения региона

• сотрудники регулярно переписывают слишком формальный текст

• при технических ошибках AI придумывает инструкции вместо передачи запроса специалисту.

• Команда не пытается решить все проблемы заменой модели.

Вместо этого она

• удаляет устаревшие документы

• добавляет метаданные по тарифам и регионам

• меняет правила поиска

• обновляет промпт для уточняющих вопросов

• добавляет передачу сложных случаев оператору

• собирает eval-набор из найденных ошибок

• отдельно проверяет тон ответов.

После обновления сравниваются конкретные показатели

• снизилась ли доля повторных запросов

• реже ли сотрудники переписывают ответы

• уменьшилось ли число ошибок при выборе тарифа

• чаще ли AI запрашивает недостающий регион

• не ухудшились ли старые сценарии

• как изменились задержка и стоимость.

Именно так работает data flywheel: действия пользователей превращаются не в архив переписок, а в понятный план улучшений.

Какие метрики использовать

Одна универсальная метрика почти всегда вводит команду в заблуждение. Лучше оценивать продукт на нескольких уровнях.

Технические метрики

• время ответа

• доступность сервиса

• частота ошибок API

• стоимость запроса

• количество токенов

• доля успешных вызовов инструментов.

Метрики поиска

• найден ли нужный документ

• попал ли правильный фрагмент в первые результаты

• сколько нерелевантного контекста получил AI

• использовалась ли актуальная версия

• соблюдались ли права доступа.

Метрики ответа

• фактическая точность

• полнота

• соответствие инструкции

• корректность формата

• наличие подтвержденных источников

• отсутствие неподтвержденных утверждений

• безопасность.

Продуктовые метрики

• положительная оценка

• повторная генерация

• доля отредактированного текста

• завершение задачи

• передача оператору

• повторный вопрос

• использование результата.

Бизнес-метрики

• экономия времени

• снижение стоимости операции

• уменьшение очереди

• рост конверсии

• сокращение числа ошибок

• ускорение обработки документов

• снижение количества повторных обращений.

Связь между уровнями важнее отдельного показателя.

Например, переход на более дешевую модель снизил стоимость генерации на 30%, но сотрудники стали вдвое чаще редактировать ответы. Техническая метрика улучшилась, а бизнес-результат мог ухудшиться.

Как может выглядеть архитектура data flywheel

Даже небольшой AI-продукт полезно разделить на несколько контуров.

Production-контур

Он обслуживает реальные запросы и включает

• пользовательское приложение

• API

• языковую модель

• RAG

• внешние инструменты

• авторизацию

• фильтры безопасности.

Контур событий и логов

Здесь собирается техническая и продуктовая телеметрия

• запросы

• ответы

• версии компонентов

• задержки

• ошибки

• оценки

• действия пользователей

• бизнес-результаты.

Контур аналитики

Он помогает находить закономерности

• строить дашборды

• группировать ошибки

• анализировать сценарии

• сравнивать сегменты

• находить аномалии

• выбирать примеры для проверки.

Контур разметки

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

Контур evals

Он автоматически запускает контрольные задачи при изменении

• модели

• промпта

• RAG

• базы знаний

• внешних инструментов.

Контур экспериментов

В нем сохраняется история изменений

• что было изменено

• кто внес изменение

• какую гипотезу проверяли

• какой датасет использовали

• как изменились метрики

• почему версия была запущена или отклонена.

Необязательно сразу строить сложную ML-платформу. В начале часть процессов может работать с помощью обычной базы данных, таблицы для разметки и набора автоматических тестов.

Главное — обеспечить воспроизводимость. Через несколько месяцев команда должна понимать, почему определенная версия была выпущена и на каких результатах основывалось решение.

План запуска data flywheel на четыре недели

Первая неделя: определить качество и настроить события

Выберите один конкретный сценарий. Например, поиск по базе знаний или подготовку ответов клиентам.

Опишите

• что считается успешным результатом

• какие ошибки критичны

• какие действия пользователя важны

• какие версии компонентов нужно фиксировать

• какие данные запрещено сохранять.

Не пытайтесь охватить весь AI-продукт сразу.

Вторая неделя: разобрать реальные диалоги

Возьмите выборку запросов и вручную классифицируйте проблемы.

Даже анализ 100–200 диалогов часто приносит больше пользы, чем очередная неделя споров о выборе модели.

На этом этапе обычно появляются первые категории

• плохой поиск

• устаревшие документы

• недостаточный промпт

• неверный формат

• отсутствие уточняющего вопроса

• ошибка внешнего инструмента

• неудобный интерфейс.

Третья неделя: собрать evals и исправить главные причины

Создайте контрольный набор из типичных запросов и обнаруженных ошибок.

Затем внесите несколько точечных изменений

• обновите системный промпт

• добавьте фильтр по версии документа

• измените разбиение текста

• настройте передачу сложного случая человеку

• добавьте источники в ответ

• улучшите форму обратной связи.

Четвертая неделя: сравнить версии

Запустите evals, проведите ограниченный эксперимент и проверьте production-метрики.

Смотрите не только на средний результат, но и на

• важные сегменты

• рискованные сценарии

• стоимость

• задержку

• частоту передачи человеку

• появление новых ошибок.

Если новая версия лучше по одной метрике, но хуже в критичном сценарии, выпускать ее рано.

Типичные ошибки при запуске data flywheel

Собирать данные без конкретной цели

Огромное хранилище логов не равно качественной аналитике.

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

Полагаться только на оценки пользователей

Пользователь может не заметить ошибку или не захотеть нажимать дополнительные кнопки.

Явную обратную связь нужно дополнять поведенческими и бизнес-метриками.

Исправлять только отдельные ответы

Ручное исправление помогает конкретному пользователю, но не улучшает систему.

Каждая повторяемая ошибка должна получить категорию, владельца и контрольный тест.

Менять несколько компонентов одновременно

Если команда одновременно заменила модель, переписала промпт и перестроила RAG, определить источник результата будет сложно.

Лучше проверять изменения небольшими управляемыми итерациями.

Дообучать модель слишком рано

Многие проблемы решаются очисткой базы знаний, улучшением поиска или несколькими правилами в системном промпте.

Fine-tuning стоит использовать после диагностики, а не вместо нее.

Обучать модель на непроверенных ответах

Если AI генерирует ошибки, а затем эти ответы автоматически попадают в обучающий датасет, возникает замкнутый цикл ухудшения.

Все обучающие примеры должны проходить контроль качества.

Не хранить версии

Промпты, документы, модели, индексы и правила постоянно меняются.

Без версионирования невозможно воспроизвести ошибку и честно сравнить результаты.

Ориентироваться только на среднее значение

Средняя точность может расти, пока качество важного или рискованного сегмента падает.

Метрики необходимо анализировать по отдельным сценариям.

Не назначать владельца процесса

Data flywheel находится на пересечении разработки, аналитики, продукта, безопасности и бизнеса.

Если никто не отвечает за весь цикл, обратная связь быстро превращается в очередь необработанных задач.

Кто должен участвовать в улучшении AI

Работа не должна оставаться только внутри ML-команды.

В процессе нужны разные роли

• продуктовая команда определяет ценность и приоритеты

• разработчики отвечают за интеграции и надежность

• ML-специалисты работают с моделями и evals

• эксперты предметной области проверяют содержание

• аналитики связывают действия пользователей с бизнес-результатами

• специалисты по безопасности контролируют данные и доступы

• юристы определяют допустимые способы обработки информации

• поддержка передает реальные проблемные сценарии.

• Самые полезные данные часто находятся не у разработчиков, а у сотрудников, которые ежедневно исправляют ответы AI перед отправкой клиенту.

Почему инфраструктура тоже важна

Data flywheel требует не только языковой модели, но и надежного технического контура.

Логи, датасеты, документы, векторные индексы, результаты evals и версии экспериментов необходимо хранить. Проверки должны запускаться воспроизводимо, а доступ к чувствительным данным — контролироваться.

По мере роста AI-продукта компании могут понадобиться

• объектное хранилище для датасетов

• база событий

• векторная база

• вычислительные ресурсы для пакетных evals

• система мониторинга

• резервное копирование

• разграничение прав

• отдельные среды для разработки и production

• GPU-серверы для запуска или дообучения собственных моделей.

При этом не стоит заранее строить инфраструктуру с запасом на десять лет.

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

Маховик данных должен ускорять развитие продукта, а не превращаться в отдельный дорогой проект без понятной пользы.

Как понять, что data flywheel заработал

Рабочий цикл можно узнать по нескольким признакам.

Команда способна быстро ответить

• какие ошибки встречаются чаще всего

• какие из них наиболее опасны

• почему AI дал конкретный неправильный ответ

• какая версия промпта использовалась

• какие документы получил RAG

• как обновление повлияло на качество

• не вернулись ли старые ошибки

• какие данные нужны для следующего улучшения

• как качество AI связано с бизнес-результатом.

Одновременно сокращается путь от жалобы пользователя до проверенного исправления.

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

Хороший процесс устроен иначе

• Диалог автоматически попадает в очередь анализа.

• Ошибка получает категорию.

• Команда находит первопричину.

• Пример добавляется в eval-набор.

• Исправление проходит проверку.

• Новая версия запускается ограниченно.

• Production-метрики сравниваются с предыдущей версией.

Итог

Сильный AI-продукт появляется не в момент подключения мощной модели. Он формируется после запуска, когда компания начинает системно учиться на реальных действиях пользователей.

Логи запросов показывают, какие задачи люди действительно решают. Оценки ответов помогают находить слабые места. Исправления пользователей дают примеры желаемого результата. Evals защищают от возвращения старых ошибок. RAG поддерживает актуальность знаний. Промпты управляют поведением, а дообучение закрепляет устойчивые сценарии там, где более простых инструментов уже недостаточно.

Главная ценность data flywheel заключается не в количестве собранных данных. Она состоит в способности превращать каждый важный сигнал в проверяемое улучшение.

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

Когда этот процесс становится регулярным, нейросеть перестает быть непредсказуемым экспериментом и превращается в управляемый продукт, качество которого растет вместе с опытом компании.