Как взрослеть AI-продукту: аудиты, тесты и ремонтные циклы

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

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

NIST в AI Risk Management Framework описывает управление рисками через функции map, measure, manage и govern. Для практики это можно перевести проще: сначала понять контекст и риски, потом измерять поведение, затем управлять исправлениями и держать это в повторяемом процессе.

Почему “поменять модель” не равно “починить продукт”

Когда AI-система ошибается, первая реакция часто звучит так: давайте возьмем модель сильнее. Иногда это помогает. Но если ошибка возникла из-за грязных данных, плохого промпта, слабого retrieval, неправильных прав, устаревшего источника или отсутствия теста, новая модель просто принесет новый вид ошибки.

OWASP Top 10 for LLM Applications полезен именно как напоминание: риски LLM-приложений живут не только в модели. Есть prompt injection, утечки данных, небезопасные действия, чрезмерные права, проблемы цепочки поставки и слабый мониторинг. Значит, чинить нужно весь контур.

Главное:

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

Как выглядит ремонтный цикл

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

Какие тесты нужны AI-системе

Google в работе The ML Test Score описывает идею производственной готовности ML-систем через проверяемые тесты и снижение технического долга. Для LLM-продуктов логика похожая: нужно проверять не только код, но и данные, поведение модели, качество источников, устойчивость к плохим входам и безопасность действий.

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

Как применить это в Codex

Codex удобно использовать как ремонтного инженера, но только с четкой рамкой. Не “улучши AI-продукт”, а “прочитай журнал ошибок, сгруппируй инциденты, предложи тесты, внеси одну ограниченную правку и запусти проверку”. Тогда агент не переписывает систему целиком, а помогает вести ремонтный цикл.

В хорошем контуре Codex создает или обновляет файлы качества: evalcases.yaml, knownfailures.md, releasegate.md, auditlog.md, regression_report.md. Человек при этом остается владельцем решения: он принимает, какие ошибки критичны, какие исправления можно выпускать и где нужен ручной контроль.

Где граница

Аудиты и тесты не делают AI-продукт безошибочным. Они делают ошибку управляемой. Команда перестает спорить на уровне “модель тупит” и начинает видеть конкретику: не тот источник, слабая проверка, плохой запрос, опасное действие, устаревший документ, нет отказа в рискованном сценарии.

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