Как вычислить precision и recall AI-маршрутизации с обработкой нуля

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

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

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

В синтетическом наборе один TP, один FP, один FN, один TN: обе метрики равны 0.5. Если ни одна запись не предсказана urgent, precision равен None. На четырёх искусственных кейсах оба значения 0.5. На одном обычном обращении без urgent ни precision, ни recall не определены, результат (None, None); это не означает идеального качества. Перед тем как применять правило к закрытому корпусу, обсудите пограничные случаи, которые могут поменять интерпретацию входа. Запись в документации о границах теста не менее важна, чем зелёный check.

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

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

# scripts/check.py
def score(expected, actual):
    if len(expected) != len(actual) or not expected:
        raise ValueError("paired nonempty arrays required")
    allowed = {"urgent","normal"}
    if set(expected + actual) - allowed:
        raise ValueError("unknown label")
    tp = sum(e == a == "urgent" for e, a in zip(expected, actual))
    fp = sum(e == "normal" and a == "urgent" for e, a in zip(expected, actual))
    fn = sum(e == "urgent" and a == "normal" for e, a in zip(expected, actual))
    precision = tp / (tp + fp) if tp + fp else None
    recall = tp / (tp + fn) if tp + fn else None
    return precision, recall

assert score(["urgent","normal","urgent","normal"],
             ["urgent","urgent","normal","normal"]) == (0.5,0.5)
assert score(["normal"],["normal"]) == (None,None)
print("Synthetic arithmetic verified")

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

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

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

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

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