Инженерия AI-продуктов: как строить надёжные AI-системы

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

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

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

Ключевая практика инженерии AI-продуктов — evaluation loop: фиксированный набор репрезентативных входов с заведомо правильными выходами, прогоняемый на каждое изменение промпта, модели или логики. Это тестовый набор для поведения, которое нельзя ассертить исключениями.

• Golden examples — небольшой курируемый набор реальных кейсов с ожидаемыми результатами; фундамент цикла.
• Регрессионные проверки — каждое изменение промпта и каждая смена модели прогоняются на наборе; падение скора блокирует изменение.
• Метрики, которые имеют значение — принятие валидационным слоем, фактическая согласованность, время на задачу, стоимость на задачу.
• Вывод устаревших примеров — набор эволюционирует вместе с продуктом; устаревшие кейсы заменяются, а не накапливаются.

Evaluation loop превращает «надеемся, модель ведёт себя правильно» в «мы можем показать, что она не деградировала». Это разница между демо-качеством и production-качеством.

Надёжность обеспечивается не промптами, а системой вокруг модели:

• Типизированный структурированный вывод — модель возвращает данные по схеме; парсинг и валидация фейлят шаг, а не систему.
• Policy checks — бизнес-правила как код: что вывод может утверждать, на что ссылаться, что требует одобрения.
• Ревьюер-проходы — для высокорисковых выводов второй проход модели валидирует первый, затем человек одобряет финальное действие.
• Graceful degradation — провал валидации уводит задачу в человеческую очередь вместо распространения по процессу.

Человек — часть архитектуры, а не придаток. Система делает объём; люди держат решения, покидающие систему.

• Пошаговое логирование — каждый шаг фиксирует модель, версию промпта, токены, задержку и результат; проблемы production становятся объяснимыми трейсами.
• Версионирование моделей — пините версии моделей и оценивайте до обновления; изменение поведения становится решением, а не случайностью.
• Стоимость на задачу — учитывайте расход на завершённые задачи, а не на сырые токены; роутинг моделей и кэширование — это инженерия, а не оптимизация.
• Версионирование промптов — промпты живут в коде, версионируются и ревьюятся как код, деплоятся тем же пайплайном.

Эти практики не теоретические — на них работают наши собственные продукты:

• LeadForge AI — мультиагентная sales-система, где каждый сгенерированный research и outreach проходит reviewer-валидацию с policy checks; пошаговое логирование и PostgreSQL-состояние делают каждый запуск агентов объяснимым и аудируемым.
• LaunchPilot AI — структурированный вывод и есть продукт: генерация роадмапов и декомпозиция задач возвращают типизированные, проверенные планы, которые инструменты потребляют без повторного парсинга.

Оба продукта считают evaluation loop и валидацию ядром инженерной работы — тот же подход мы применяем к AI-системам клиентов.