Skip to main content
AI9 min read

Как оценивать AI-функции до их выпуска

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

Part ofAI Engineering->
By Jason TeixeiraJune 16, 2026
AI EvaluationProduct EngineeringQALLMsReliability
Share:
On this page

AI-функция не готова, когда она работает в демо.

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

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

Цикл оценки AIобещание -> доказательство
ОбещаниеСценарии отказаПроверкаРелиз

Функция оценивается не один раз. Она проходит через цикл: сформулировать обещание, собрать набор отказов, проверить реальные результаты и только потом решить, что можно выпускать.

Начните с обещания

Первый вопрос — не «Какую модель нам использовать?»

Первый вопрос: во что пользователь имеет право поверить после того, как эта функция ответит?

Эта формулировка важна. Если функция резюмирует документ, пользователь верит, что резюме достоверно. Если она составляет ответ в поддержку, пользователь верит, что она не выдумает политику возврата. Если она объясняет торговый сигнал, пользователь верит, что это не финансовый совет, замаскированный под дружелюбный тон.

Сформулируйте обещание в одну строку:

  • «Эта функция классифицирует запрос и направляет его в нужный workflow.»
  • «Эта функция составляет черновик ответа, который человек утверждает перед отправкой.»
  • «Эта функция ищет во внутренних документах и цитирует использованный источник.»

Если обещание занимает абзац — функция ещё не проработана.

Соберите набор отказов до того, как писать счастливый путь

Большинство AI-демо случайно натренированы проходить демо.

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

  • расплывчатые запросы
  • противоречивые инструкции
  • отсутствующий контекст
  • вредоносные инъекции в промпт
  • устаревшие политики
  • дублирующиеся записи
  • гневные сообщения клиентов
  • пограничные случаи, которые стоят денег при ошибке

Для клиентского AI-воркфлоу мне нужно как минимум 25 примеров, прежде чем я доверю форме системы. Не 25 идеальных строк из бенчмарка. Двадцать пять некрасивых примеров, отражающих реальную работу.

Набор для оценки — не бумажная работа. Это граница продукта.

Отделите качество модели от качества продукта

Модель может быть хорошей, а продукт — плохим.

Модель может выдать правильный ответ без цитирования. Воркфлоу может сослаться на правильный документ, но спрятать важное предупреждение. Интерфейс может сделать ответ окончательным, хотя это лишь черновик.

Я оцениваю AI-функции по уровням:

  1. Поняла ли она задачу?
  2. Использовала ли правильный источник или инструмент?
  3. Избежала ли утверждений за пределами источника?
  4. Вернула ли результат в форме, пригодной для действий пользователя?
  5. Показал ли интерфейс уверенность и ограничения системы?

Только первые два пункта — в основном вопросы к модели. Остальное — вопросы к продукту.

Держите человека в цикле дольше, чем кажется удобным

Первая продакшн-версия AI-воркфлоу обычно должна быть «сначала черновик», а не «сначала отправка».

Это звучит менее волшебно. Хорошо.

Подход «сначала черновик» даёт данные для проверки. Он показывает, где пользователи редактируют вывод, где отклоняют его, какие поля исправляют и какие задачи вообще не стоило автоматизировать.

Шаг проверки человеком — не постоянный костыль. Это инструментарий.

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

Вы не убираете человека, потому что демо сработало. Вы убираете человека, когда лог проверок говорит, что система это заслужила.

Чеклист перед релизом

Перед тем как выпустить AI-функцию, я хочу иметь следующее:

  • обещание в одно предложение
  • набор для оценки с некрасивыми примерами
  • критерии прохода/провала для каждого примера
  • логирование промпта, вызовов инструментов, источников и результата
  • путь проверки человеком для высокорисковых выводов
  • запасной вариант, когда модель недоступна
  • способ сообщить о плохом выводе из интерфейса

Ничто из этого не делает функцию менее впечатляющей.

Это делает функцию настоящей.

Связанная система: Аудит внедрения AI до начала разработки разбирает ту же идею в формат предварительного аудита для команд, решающих, что автоматизировать в первую очередь.

Reader route

article -> proof -> offer

ReadClusterProofScope

cluster

AI Engineering

intent

AI

route

next step

What to do with this

Turn the note into a build path.

If this topic maps to a real business problem, keep reading the cluster, study the academy path, or route the work into a scoped engagement.

Jason Teixeira
Written by
Jason Teixeira
Founder, Sage Ideas Studio · Principal Engineer
livebuild 5d6c8652026-08-05 06:00Z
// solo studio// no analytics resold// every commit human-reviewed