В разговоре об инженерии ИИ-систем легко сместить акценты: принять прототип за продукт, метрику за качество, а архитектурный выбор за универсальное решение. Ниже — оговорки, которые мы проговариваем заранее, чтобы не осталось спорных трактовок.
Мы не начинаем с выбора модели. Сначала разбираемся, какие данные есть, как часто они меняются и что для вас означает «качество ответа». Дальше — по шагам, с понятными ожиданиями на каждом этапе.
Обсуждаем, что именно должен делать контур: отвечать на вопросы, извлекать поля, суммировать. Смотрим, какие данные доступны, в каком они виде и можно ли их использовать. На этом шаге часто выясняется, что часть работы — не про модель, а про подготовку источников.
Дообучение или поиск с генерацией — решаем по задаче, а не по моде. Если знания меняются часто, обычно выигрывает контур поиска. Если нужно устойчивое поведение и стиль формулировок — смотрим в сторону дообучения. Иногда разумно совмещать.
Собираем минимальный рабочий контур: пайплайн данных, вызов модели, базовую обработку ответа. Цель — не демонстрация, а возможность проверить гипотезу на реальных примерах. Здесь важно заранее зафиксировать версию промпта и версию модели.
Строим трёхуровневую схему: быстрые автоматические проверки на регрессиях, офлайн-наборы с эталонными ответами и сигналы от пользователей. Автоматические метрики редко совпадают с ощущением качества, поэтому смотрим на все три слоя вместе.
Настраиваем инференс под реальную нагрузку: задержка, стоимость вычислений и надёжность — это компромисс, а не три независимые цели. Добавляем наблюдаемость, чтобы понимать, где теряется время и почему падает качество.
После запуска контур живёт: обновляются данные, меняются требования, накапливаются сигналы. Мы возвращаемся к шагам оценки и эксплуатации по мере необходимости. План следующих шагов и формат работы обсуждаем на странице процесса, а состав и условия — на странице планов.
Если после чтения страницы остались неясные места — например, как мы разграничиваем оценку качества и эксплуатацию или почему выбираем тот или иной способ работы с данными, — напишите нам. Отвечаем по существу, без шаблонных отписок. Удобнее всего описать контекст: с какой задачей работаете и на каком этапе находитесь.
Многие вопросы уже разобраны в разделе помощи: там собраны пояснения по терминам, подходам и типичным ситуациям на стыке исследования и продакшена.
Инженерный подход начинается там, где заканчивается исследовательский прототип. Ниже — последовательность шагов, которую мы проходим вместе с командой: без обещаний по срокам и без выдуманных результатов, только предметные этапы и то, что на каждом из них важно не упустить.
Сначала фиксируем, что именно должна делать система и где проходит граница между моделью и остальным контуром. На этом шаге становится понятно, какие данные нужны, что уже есть в наличии, а что придётся собирать или размечать. Отдельно проговариваем ограничения: чувствительность данных, допустимая задержка ответа, требования к воспроизводимости.
Данные — это не разовая загрузка, а поток, который меняется. Мы описываем, как устроены источники, как фиксируются версии наборов и как связать конкретный ответ модели с конкретной версией данных и промпта. Без этого шага невозможно разобраться, почему качество упало после очередного обновления.
Пайплайн собирается из отдельных шагов: подготовка данных, вызовы модели, постобработка, логирование. Мы разбираем, где нужны повторные попытки, где — кэш, а где — ручная проверка. Цель не в том, чтобы автоматизировать всё сразу, а в том, чтобы каждый шаг был наблюдаемым и воспроизводимым.
Дообучение и поиск с генерацией решают разные задачи и имеют разные издержки. Мы разбираем критерии выбора: как часто меняются знания, насколько важен стиль формулировок, какой бюджет на вычисления и какую задержку можно допустить. Иногда разумнее комбинировать оба подхода, и это тоже обсуждается на этом шаге.
Автоматические метрики редко совпадают с ощущением качества у пользователя. Поэтому оценка строится из трёх слоёв: быстрые автоматические проверки на регрессиях, офлайн-наборы с эталонными ответами и постоянный сбор сигналов от пользователей. Критерии формулируются под конкретную задачу, а не берутся из общей таблицы.
В продакшене инференс — это компромисс между задержкой, стоимостью вычислений и надёжностью. Мы обсуждаем квантование и батчинг, кэширование повторяющихся вызовов, поведение под нагрузкой и деградацию вместо падения. Отдельно — какие метрики снимать, чтобы понимать, где именно теряется время.
После запуска работа не заканчивается. Нужны журналы, метрики, алерты и понятная процедура разбора инцидентов. Мы описываем, как отслеживать дрейф данных и качества ответов, как фиксировать изменения в конфигурации и как возвращаться к предыдущей версии, если что-то пошло не так.
Этапы не всегда идут строго друг за другом: на практике команда возвращается к данным или к оценке качества, когда меняются требования. Важно, чтобы каждый шаг оставлял после себя артефакт — версию набора, конфигурацию пайплайна или набор тестов, — на который можно опереться при следующем изменении.