Как найти причину ошибок AI-фичи и проверить её с помощью тестового оракула

Материал подготовлен в рамках нового курса Otus «ИИ в тестировании: ускорение процессов и проверка ИИ-функций»

Предположим, в CRM появилась кнопка «Составить резюме обращения». Она передаёт переписку языковой модели и возвращает короткий текст для следующего оператора. QA нужно проверить функцию перед релизом, но уже на первом сценарии возникает вопрос: что записывать в expected result?

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

Клиент: Заказ 4812 должен был приехать 12 сентября, сегодня уже 15-е, а его нет. Больше ждать не хочу, верните деньги.
Оператор: Передам запрос коллегам.

Первый вариант резюме:

Клиент сообщает о задержке заказа №4812 и просит вернуть деньги. Оператор обещал передать запрос коллегам.

Второй вариант:

По словам клиента, заказ 4812 не доставлен в срок. Клиент больше не готов ждать и запрашивает возврат; оператор сообщил, что передаст обращение коллегам.

Третий вариант:

Клиент сообщает о задержке заказа №4812. Возврат одобрен, оператор передал запрос коллегам.

Первые два текста можно принять. В третьем появились сразу два изменения: просьба превратилась в одобренный возврат, а обещание оператора в выполненное действие. Для следующего сотрудника это уже другая ситуация, хотя резюме выглядит убедительно.

Разберём, как описать ожидаемое поведение такой функции и получить объяснимое решение pass/fail.

1. Сначала договоримся, что резюме должно сохранять

Требование «кратко и корректно пересказать обращение» оставляет слишком много вопросов. Обязательны ли даты? Нужно ли сохранять обещание оператора? Допустимо ли написать «заказ задержан», если единственный источник информации об этом — клиент?

Для нашего примера зафиксируем условия. Функция получает только переписку, без доступа к заказам и платежам. Возвращает один непустой абзац длиной до 500 символов, включая пробелы. Следующий оператор должен понять, о каком заказе речь, что произошло по словам участников, чего сейчас хочет клиент и что оператор сделал или обещал. Даты разрешено опустить, если проблема остаётся понятной. Это выбранные требования учебного продукта, а не универсальные правила суммаризации.

Источником истины здесь служит диалог. Система может передать слова клиента, но не подтвердить доставку или платёж во внешнем мире. Если заказ не указан, номер нельзя додумывать. Если участники противоречат друг другу и противоречие не разрешено, его нужно сохранить. Явное исправление собственной реплики учитываем как исправление: «не 4812, а 4813» задаёт актуальный номер 4813.

Так появляется контракт поведения: набор свойств, которым должен соответствовать любой допустимый ответ. Способ определить, выполнен ли контракт, в тестировании называют test oracle, или тестовым оракулом. Им может быть сочетание assertions, то есть программных проверок, и оценки по заданным критериям.

В работе CheckList: Beyond Accuracy предложено проверять отдельные способности NLP-моделей через специально спроектированные тесты. Готового контракта для CRM там нет; используем принцип проверки конкретного поведения.

2. Разделим проверку формы и смысла

Сравнение всего ответа с одной строкой отвергнет второй корректный вариант. Наличие слова «возврат» тоже мало что доказывает: оно есть и в просьбе, и в сообщении об одобрении. Поэтому каждому требованию нужен подходящий способ проверки.

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

Достоверность: каждое фактическое утверждение поддерживается перепиской; сохранены автор сообщения, отрицания и статус действия. Обещание не считается выполнением, просьба не считается решением. Если хотя бы одно утверждение нарушает это правило, критерий получает fail.

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

Эти критерии проверяются раздельно. «Клиент обратился по заказу 4812» может быть достоверным, но неполным. Подробный пересказ с выдуманным одобрением возврата может сохранять все нужные темы, но нарушать достоверность. Высокая оценка за полноту не должна компенсировать ложный факт.

Раздельный учёт свойств согласуется с многомерной оценкой в HELM. Сами критерии и их критичность определяет продуктовая команда.

3. Запишем контракт в тест-кейс и проверим его на ответах

Запишем собственную схему тест-кейса. Это не конфигурация фреймворка: текстовые критерии ещё нужно реализовать в оценщике.

id: delayed_order_refund
input: |
  Клиент: Заказ 4812 должен был приехать 12 сентября,
  сегодня уже 15-е, а его нет. Больше ждать не хочу,
  верните деньги.
  Оператор: Передам запрос коллегам.
must_preserve:
  - Номер заказа 4812.
  - По словам клиента, заказ не доставлен в срок.
  - Клиент больше не хочет ждать и просит возврат.
  - Оператор обещал передать запрос коллегам.
must_not_claim:
  - Возврат одобрен или деньги уже перечислены.
  - Запрос уже передан коллегам.
  - Известны сумма или срок возврата.
format:
  type: string
  min_chars: 1
  max_chars: 500
  single_paragraph: true
quality_criteria:
  factuality: Каждое утверждение поддерживается диалогом.
  completeness: Сохранены все пункты must_preserve.
critical_failures:
  - Выдуманный или искажённый факт.
  - Подмена номера заказа.
  - Потеря актуальной просьбы клиента.

Список must_not_claim подчёркивает известные риски, но не перечисляет все возможные выдумки. Фраза «курьер потерял посылку» тоже должна провалить проверку достоверности, хотя её нет в списке.

Валидатор ниже измеряет длину через Python len. В рабочем продукте способ подсчёта нужно согласовать с ограничением CRM.

import re

def check_basic_constraints(text):
    if not isinstance(text, str):
        return {"type": False}
    return {
        "nonempty": bool(text.strip()),
        "length": 1 <= len(text) <= 500,
        "single_paragraph": "n" not in text and "r" not in text,
        "order_id_present": bool(re.search(r"b4812b", text)),
    }

Код пропустит третий ответ: наличие ID не подтверждает правильность резюме. Разделение строковых, программных и модельных проверок можно найти и в OpenAI Graders; здесь мы не привязываемся к API.

По рубрике первые два ответа проходят все проверки. Третий получает fail за одобрение возврата и завершённую передачу запроса. Итог ответа — pass, только если выполнены все обязательные проверки.

Проверьте и сам оракул: в корректном ответе по одному замените номер, удалите просьбу, поменяйте «обещал передать» на «передал». Добавьте корректную перефразировку. Проверка должна отклонить дефекты и принять допустимое изменение текста.

4. Из одного диалога соберём набор сценариев

Варьировать нужно не только формулировки, но и условия, от которых зависит правильный ответ.

Ожидания меняются вместе со входом. Удаление ID отменяет проверку на 4812. Запрет «возврат одобрен» относится к исходному кейсу: если оператор сообщил об одобрении, это допустимое содержание с указанием источника.

Для пустого диалога и переписки без сведений об обращении зададим отдельную ветку: «Недостаточно данных для резюме обращения». Требования сохранить заказ и просьбу к ней не применяются. Суммаризатор не общается с клиентом, поэтому уточняющий вопрос здесь неуместен.

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

5. Подключим LLM-судью, когда ручная оценка станет дорогой

LLM-as-a-Judge — оценка ответа языковой моделью. Судье передаём исходный диалог, резюме и рубрику: инструкция «оцени качество от 1 до 10» не определяет, что считать ошибкой.

По каждому нарушению судья должен вернуть фрагмент резюме и основание в диалоге либо отметить отсутствие такого основания. Человек сможет проверить вердикт, хотя объяснение модели тоже может быть ошибочным.

Сначала подготовьте пары «диалог — ответ» с человеческой разметкой: корректные перефразировки, пропуски, выдумки и пограничные формулировки. Спорные случаи пусть независимо оценят два специалиста, затем согласуют решение. Если расходятся люди, возможно, нужно уточнить рубрику. Настраивайте судью на одной части примеров, а проверяйте на другой.

Сопоставление с человеческой разметкой описано в Google: Evaluate a judge model. Отдельно считайте пропущенные дефекты: сколько ошибочных по человеческой разметке ответов судья принял. Общее совпадение оценок на преимущественно хороших ответах может скрыть эту проблему.

Неопределённый вердикт или ошибка оценщика оставляют проверку незавершённой, а не превращают её в pass. Спорные случаи передавайте человеку. Версию судьи и рубрики сохраняйте; после их изменения переоценивайте старые и новые ответы одинаково, иначе изменение оценщика можно принять за изменение функции.

6. Повторим прогоны и зададим правило регрессии

Один удачный ответ показывает результат только этого запуска: при одинаковом входе генеративная функция может ответить иначе. Рекомендации OpenAI предлагают строить оценку вокруг конкретной задачи, набора данных, критериев и сравнения версий.

Зафиксируйте входы, промпт, идентификатор модели, доступные параметры генерации и обработку ответа. Baseline, исходная версия функции, проходит тот же набор и проверки, что и кандидат. Меняйте то, что хотите оценить; остальные условия сохраняйте.

Для первого диагностического прогона можно выполнить каждый кейс пять раз. Это выбранный бюджет, а не обоснованный минимум. Если один ответ придумал одобрение возврата, фиксируем 4/5 pass; 1 критический дефект. Не перезапускаем его до успеха, стирая предыдущий результат.

Pass rate — доля успешных прогонов среди запланированных для выбранной группы. Здесь 80% — наблюдаемая доля на одном кейсе, а не установленная вероятность успеха в эксплуатации. Повторы помогают обнаружить вариативность; для оценки редких ошибок нужны другой объём и продуманный состав выборки.

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

Правило выпуска задайте заранее. Для нашего продукта примем: подтверждённый критический дефект блокирует выпуск; остальные обязательные нарушения и ухудшения относительно baseline требуют разбора; незавершённые проверки нужно закончить. Порог «достаточно 95%» сам по себе ничего не обосновывает: допустимый риск зависит от цены ошибки.

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

Этот подход удобен, когда ответ можно сверить с исходным материалом. Он не доказывает истинность самого источника; доступы, производительность и действия во внешних системах потребуют отдельных проверок. Начните с одного обращения, двух допустимых резюме и одного ошибочного. Если команда не может согласованно объяснить решения по ним, сначала уточняйте контракт.

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

• 29 сентября в 20:00. «Приёмка ИИ-фич: как тестировать то, что каждый раз отвечает по-разному». Записаться

• 15 октября в 20:00. «ИИ в управлении рисками: Предиктивная аналитика для тестировщика». Записаться