# AI-фичи без эталона: как тестировать через оракул

> 2026-09-29 · AI Release · @ai_release1

> #AI-тестирование #тестовый #NLP

### ⚡ Главное за 5 секунд - **Суть:** Для генеративных AI-фич нет единственного правильного ответа, поэтому классический expected result не работает. Вместо него используют тестовый оракул — набор правил, определяющих, какой ответ допустим. - **Где доступно:** Материал опубликован в блоге компании OTUS на Хабре 29 сентября; автор — SiYa_renko. - **Ограничение:** Описанный подход — контракт поведения с критериями достоверности и полноты — требует настройки под конкретный продукт и не является универсальным решением. ### 🔍 Что обнаружено В статье разбирается функция CRM «Составить резюме обращения»: она передаёт переписку языковой модели и возвращает короткий текст для следующего оператора. QA нужно проверить функцию, но уже на первом сценарии возникает вопрос: что записывать в expected result. Приведён учебный диалог по заказу №4812, где из трёх вариантов резюме два корректны, а третий содержит выдуманные факты — просьба клиента превратилась в одобренный возврат, а обещание оператора — в выполненное действие. Отсюда вывод: сравнивать весь ответ с одной строкой нельзя, это отвергнет допустимые варианты. Чтобы описать ожидаемое поведение, автор предлагает контракт поведения — набор свойств, которым должен соответствовать любой ответ. В примере функция получает только переписку (без доступа к заказам и платежам), возвращает один непустой абзац длиной до 500 символов, сохраняет номер заказа, проблему клиента, его актуальную просьбу и действие либо обязательство оператора. Даты разрешено опускать, если проблема остаётся понятной. Источником истины служит сам диалог: если участники противоречат друг другу и противоречие не разрешено, его нужно сохранить. Способ проверки контракта называют тестовым оракулом — это сочетание программных assertions и оценки по заданным критериям. Критерия два: достоверность (каждое фактическое утверждение поддерживается перепиской, сохранены автор, отрицания, статус действия) и полнота (сохранены все важные элементы из входа). Они проверяются раздельно: высокая полнота не должна компенсировать ложный факт. ### 💡 Почему это важно Сравнение ответа с эталонной строкой здесь не работает: второй корректный вариант резюме был бы отвергнут, а наличие слова «возврат» не отличает просьбу от сообщения об одобрении. Контракт поведения даёт объяснимое pass/fail для генеративной функции: вместо «похоже на правду» QA проверяет конкретные свойства. Например, отдельным критерием фиксируется, что просьба клиента не становится решением, а обещание оператора — выполненным действием. Автор ссылается на практики CheckList (проверка отдельных способностей NLP-моделей через специально спроектированные тесты) и многомерную оценку HELM, так что подход согласуется с известными методологиями, а не является разовым решением для учебного кейса. ### 🧩 Контекст Материал подготовлен в рамках курса OTUS «ИИ в тестировании: ускорение процессов и проверка ИИ-функций». В статье приводится структура тест-кейса с id `delayed_order_refund`: списки `must_preserve` (номер заказа, слова клиента, просьба, обещание оператора), `must_not_claim` (запрещено утверждать, что возврат одобрен, запрос уже передан, известны сумма или срок), формат и критические сбои. При этом автор уточняет: это не конфигурация фреймворка, а собственная схема — текстовые критерии ещё нужно реализовать в оценщике. Список `must_not_claim` также не перечисляет все возможные выдумки: например, фраза «курьер потерял посылку» должна провалить проверку достоверности, хотя её нет в списке.

[Источник](https://habr.com/ru/companies/otus/articles/1087130/)