Как проверить согласованность AI-разметки для повторяющегося вопроса

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

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

Вход и ожидаемый результат

Одна строка Срочно: оплата не проходит размечена urgent, вторая такая же в другом регистре — normal. Ожидается конфликт пары IDs. A1 и A2 попадают в один нормализованный ключ, но имеют разные метки; B1 не участвует. Выход показывает только ID и метки, не текст пользовательского обращения. Перед тем как применять правило к закрытому корпусу, обсудите пограничные случаи, которые могут поменять интерпретацию входа. Запись в документации о границах теста не менее важна, чем зелёный check.

Пошаговые действия

1. Создайте scripts/check.py в корне репозитория и вставьте код из блока ниже. Он использует названия функций стандартной библиотеки, указанные в официальных ссылках в конце статьи.
2. Выполните python scripts/check.py локально. Не продолжайте, если уже демонстрационная фикстура даёт иной результат: сначала проверьте копирование кода и кодировку файла.
3. Запустите скрипт и проверьте обнаружение A1/A2. В рабочем корпусе при конфликте останавливайте оценку с ненулевым кодом и передавайте обе записи ответственному редактору. После согласования правила исправьте expected или разделите сценарии дополнительным контекстом, который делает случаи действительно разными. Если даже при одинаковом тексте результат зависит от истории диалога, включите нужный контекст в ключ сравнения, не объявляйте проблему дубликатом по умолчанию.
4. Создайте .github/workflows/ai-corpus-check.yml из YAML-шаблона. Событие pull_request полезно для проверки корпуса до слияния; чтение репозитория ограничено permissions: contents: read. Скрипт не должен получать ключ внешней модели или реальные секреты.
5. В разделе Actions откройте job check, сопоставьте его код завершения с локальным прогоном и зафиксируйте ссылку на проверенный коммит в PR. Не принимайте зелёный результат на старой ревизии за проверку последнего изменения.

# scripts/check.py
from collections import defaultdict

cases = [("A1","Срочно: оплата не проходит","urgent"),
         ("A2","срочно: оплата не проходит","normal"),
         ("B1","Когда чек?","normal")]
groups = defaultdict(list)
for case_id, text, label in cases:
    if label not in {"urgent", "normal"}:
        raise SystemExit("Unknown label in " + case_id)
    groups[text.strip().casefold()].append((case_id,label))
conflicts = {text: entries for text,entries in groups.items()
             if len({label for _,label in entries}) > 1}
if not conflicts:
    raise SystemExit("Demo conflict was not detected")
for entries in conflicts.values():
    print("Conflicting fixture IDs:", entries)

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

Ошибки интерпретации и границы

Метод не находят перефразы и может ошибочно считать дубликатом две записи с разным невидимым контекстом. Ручной разбор — часть процесса, а не недостаток скрипта. Не перенастраивайте модель по противоречивому эталону. Если вы увеличиваете корпус, добавляйте не только новые примеры, но и отрицательные случаи, на которых тест обязан упасть. Проверяйте, что изменение expected прошло ревью отдельно от изменения кода: иначе можно незаметно изменить правило под текущий ответ системы. Избегайте вывода полного корпуса в CI и не сохраняйте в артефактах ответ закрытой модели без решения о доступе и хранении.

Ошибка выполнения самого Python, нераспознанный формат входа и обнаруженный бизнес-дефект — разные ситуации. В сообщении теста указывайте тип проблемы и безопасный ID. Если тест требует внешний сервис, вынесите его из PR с недоверенным кодом и явно ограничьте доступ к токенам; этот пример намеренно работает локально. Перед публикацией каких-либо результатов опишите методику, размер и происхождение набора, иначе читатель воспримет демонстрационную арифметику как характеристику продукта.

Чек-лист финальной проверки