Process | НейроИнженерия

Что команда получает на каждом этапе процесса

Работа над ИИ-системой редко идёт по прямой. Ниже — то, что должно быть на выходе у каждого шага, чтобы следующий не превратился в переделку.

Понятная постановка задачи

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

Осознанный выбор между дообучением и поиском с генерацией

Дообучение и RAG решают разные задачи и стоят по-разному. На выходе — решение, привязанное к частоте обновления знаний, требованиям к стилю ответа и бюджету на инфраструктуру.

Оценка качества на трёх уровнях

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

Подготовка инференса к продакшену

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

Политика работы с данными

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

Право вернуться на шаг назад

Результаты оценки часто показывают, что задача сформулирована иначе, чем казалось. Процесс это учитывает: возврат на предыдущий этап — часть работы, а не сбой.

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

Как устроен процесс работы над ИИ-системой

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

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

Формулировка задачи и инвентаризация данных

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

Выбор подхода: дообучение или поиск с генерацией

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

Настройка оценки качества

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

Подготовка к продакшену

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

Политика работы с данными

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

Возврат на предыдущий этап

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