🧭 Глава 6. Костёр, приборы и выводы

Промпт нужно хранить в Git, версионировать, тестировать в CI 🧪, сравнивать метрики между версиями и откатывать при деградации. Если промпт живёт в голове разработчика и в чате с коллегой — это не контракт, это фольклор, а фольклор прекрасен у костра, но в проде его место — в истории коммитов 📦. Версия модели — тоже часть контракта.

🔍 Наблюдаемость AI-пайплайна — способ перестать гадать на костях и токенах. Логировать и измерять нужно задержку, входные и выходные токены, стоимость, долю ошибок, повторы и откаты, попадания в кэш, качество ответа, версии модели и промпта. Инструменты известны: Micrometer, OpenTelemetry, Prometheus, Grafana. Без этого вы не узнаете, что новая версия промпта стала лучше по качеству, но в три раза дороже и в два раза медленнее, или что сорок процентов запросов уходят в непротестированный fallback. Раньше племя гадало на костях, теперь графики рисуются сами 📈 — прогресс в том, что рисует их не шаман 📊.

Экономика — тоже QA, просто с другой единицей измерения. AI-вызовы дорогие и медленные, поэтому нужны ограничение частоты, обратное давление, изоляция, предохранитель, повтор с задержкой, кэширование, батчинг и бюджетные guardrails. Иначе один энтузиаст в CI запустит десять тысяч eval-прогонов, и финансовый отдел придёт с вопросами, на которые у QA нет ответа. Мамонт ест много — считайте запасы до охоты, а не после 💸.

Меняется и набор навыков. Мало знать Selenium и API-тестирование — нужно уметь проектировать контракты, работать со схемами, валидировать неструктурированные данные и строить наблюдаемость для AI-компонентов: видеть, когда запросы тормозят, падают или сжигают бюджет. Хорошая новость: валидация, контракты и контроль воспроизводимости — это то, что QA-инженер делал всегда. Теперь просто за внимательность платят выше. Аналогия напрашивается сама: AI — ветер, который двигает паруса, Java — корпус корабля, контракты — киль, наблюдаемость — компас, безопасность — водонепроницаемые переборки. Без корпуса ветер разбросает всё по волнам; без киля корабль перевернётся на первой же волне; без компаса вы не узнаете, что плывёте не туда; без переборок утонете тихо и с достоинством ⛵. Правило универсальное: транспортное средство проверяют до спуска на воду, а не с середины реки.

Честность требует признать ограничения. 🧠 Java не спасёт от неверного контракта: если схема описана неправильно, типизация лишь аккуратно пропустит мусор. Валидный JSON не равен корректным данным: схема проверяет структуру, но не смысл. Модель может пройти схему и всё равно ошибиться — семантическая валидация и человеческий контроль остаются. 🔬 Eval-наборы не гарантируют отсутствие галлюцинаций: они лишь делают их измеримыми. И никакая типизация не заменит понимания предметной области — это не отменял ни один каменный век.

✅ Прежде чем объявлять AI-функционал готовым, QA проходит по списку, короткому, как охотничья память: описан ли контракт, валидируется ли схема, используется ли structured output, есть ли fallback при отказе модели, настроены ли таймауты и повторы, маскируются ли персональные данные до отправки, версионируется ли промпт в Git, есть ли eval-набор и метрики качества, видны ли стоимость и задержка в мониторинге, ведётся ли аудит запросов и ответов 🧾, есть ли план отката, зафиксирована ли версия модели, стоят ли бюджетные guardrails и проверено ли, что модель не вызовет deleteAllUsers() из любопытства. Распечатайте и повесьте на стену пещеры.

В мире, где AI приносит гибкость и скорость, инженерные контракты остаются опорой, которая не даёт качеству рассыпаться: превращают хаос вариативности в порядок схем, а идеи моделей — в предсказуемые и проверяемые решения. Java здесь — не единственный, но убедительный пример зрелой платформы. 🗺️ Остаётся открытый вопрос: что будет, когда модели научатся сами писать и валидировать контракты? Сместится ли роль Java — или она, как добросовестный корпус корабля, просто станет невидимой, а качество останется спроектированным, а не случайным? Поживём — увидим. Но проверять всё равно будем сами: это правило не устареет раньше нас 🛡️.