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

Перед кодом сформулируйте один проверяемый инвариант из задачи: что конкретно должно пройти и какой специально нарушенный пример обязан завершиться ошибкой. Используйте синтетические обращения и стабильные ID. Данные, попавшие в репозиторий или журнал CI, могут увидеть участники проекта; не копируйте сюда реальные обращения, ключи и закрытые документы. Фикстура не должна зависеть от сегодняшнего ответа модели: ожидаемое значение задаётся после предметной проверки.

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

Входная фикстура, которую можно скопировать

Сохраните строки в обозначенный ниже файл; комментарии с путями — пояснение и не входят в JSONL или CSV. Если пример показывает две версии ответа, прогоните их отдельно, как описано в шагах.

{"id":"urgent-payment","input":"Срочно: платеж не прошёл","expected":"urgent"}
{"id":"ordinary","input":"Когда чек?","expected":"normal"}

Пошаговая реализация

1. Создайте каталог scripts и файл scripts/evaluate.py; при необходимости добавьте каталог data и пример из предыдущего блока. Убедитесь, что кодировка текстовых файлов — UTF-8.
2. Скопируйте скрипт ниже и запустите команду python scripts/evaluate.py локально. Для проекта с отдельным модулем замените демонстрационную функцию на импорт приложения. Сначала сохраните исходное проверяемое поведение.
3. Запустите шаблон и проверьте вывод обеих версий по каждому ID. Затем добавьте пограничную фикстуру Пожалуйста, срочно проверьте чек: она может выявить реальное различие между old_rule и new_rule. Вручную решите ожидаемую метку и только после этого добавьте expected. Заменяя функции на два варианта AI-промпта, фиксируйте одни и те же входные документы и проверяйте структурированный результат, а не дословный свободный текст. В CI проверяйте соответствие новой версии эталону; старую используйте как контекст для объяснения изменения, но не как безошибочное «золото».
4. Добавьте workflow из следующего блока в .github/workflows/ai-evaluation.yml. Он запускается для pull request и не передаёт секреты коду из PR. Если сетевой интеграционный тест всё же необходим, выведите его в отдельный доверенный workflow и ограничьте доступ к ключу.
5. Откройте успешный и намеренно неуспешный запуск. Убедитесь, что статус job соответствует коду завершения Python, а сообщение указывает на кейс, который нужно исправлять. После проверки верните корректные данные, не оставляйте искусственный сбой в ветке.

# scripts/evaluate.py
cases = [
    {"id":"urgent-payment", "input":"Срочно: платеж не прошёл", "expected":"urgent"},
    {"id":"ordinary", "input":"Когда чек?", "expected":"normal"},
]
def old_rule(text):
    return "urgent" if text.startswith("Срочно:") else "normal"
def new_rule(text):
    return "urgent" if "срочно" in text.lower() else "normal"

failures = []
for case in cases:
    old, new = old_rule(case["input"]), new_rule(case["input"])
    print(f"{case['id']}: expected={case['expected']}, old={old}, new={new}")
    if new != case["expected"]:
        failures.append(case["id"])
if failures:
    raise SystemExit("New rule violates gold cases: " + ", ".join(failures))
print("New rule passes all gold cases")

Готовый workflow для проверки в pull request

Файл ниже запускает скрипт через Python. permissions: contents: read оставляет встроенному токену только чтение кода. Если вы уже используете другой CI, сохраняйте тот же негативный тест и ненулевой код выхода, а файл workflow адаптируйте к своей инфраструктуре.

name: AI evaluation
on:
  pull_request:
permissions:
  contents: read
jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v7
        with:
          python-version: '3.13'
      - run: python scripts/evaluate.py

Пример входа и ожидаемого результата

Для двух базовых входов old и new дают одинаковые urgent/normal. Для фразы со словом «срочно» не в начале версии расходятся: old даёт normal, new urgent. После ручной разметки этого кейса станет понятно, какой результат корректен, без выдуманной метрики улучшения. Это наблюдаемое поведение демонстрационного кода, а не отчёт о запуске на внешней модели. В production проверяйте, что конкретный контракт подходит к бизнес-процессу, и сохраняйте вход/ожидание рядом с именем кейса.

Где этот тест может обмануть

Изменение корпуса и правил в одном PR допустимо, но требует отдельного ревью ожидаемых меток. Расхождение версий не означает автоматическую ошибку новой или старой версии. Если модель стохастична, одиночная пара не даёт оценки стабильности; повторения и критерии нужно проектировать отдельно, с учётом затрат и вариации ответов. Если тест проверяет только формат, не представляйте его как оценку фактической правильности ответа. Если тест проверяет только список ID, не делайте вывода о полноте подтверждающих документов. Разделяйте сбой инфраструктуры, некорректный корпус и нарушение прикладного инварианта: у этих проблем разные действия.