Как подобрать порог эскалации AI-заявок по precision и recall

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

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

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

Метки [1,0,1,0], оценки [0.9,0.6,0.4,0.1]; при 0.5 один TP, один FP, один FN. Для 0.5 выводится (1,1,1,0.5,0.5); для 0.8 — (1,0,1,1.0,0.5). Показатели только учебные. Перед тем как применять правило к закрытым данным, обсудите пограничные случаи, которые могут поменять интерпретацию входа. Запись в документации о границах теста не менее важна, чем зелёный check.

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

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

# scripts/check.py
rows=[(1,0.9),(0,0.6),(1,0.4),(0,0.1)]
def metrics(threshold):
    tp=sum(y==1 and p>=threshold for y,p in rows)
    fp=sum(y==0 and p>=threshold for y,p in rows)
    fn=sum(y==1 and p<threshold for y,p in rows)
    precision=tp/(tp+fp) if tp+fp else 0.0
    recall=tp/(tp+fn) if tp+fn else 0.0
    return tp,fp,fn,precision,recall
assert metrics(0.5)==(1,1,1,0.5,0.5)
assert metrics(0.8)==(1,0,1,1.0,0.5)
print("0.5:",metrics(0.5),"0.8:",metrics(0.8))

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

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

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

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

Практический разбор именно этого контроля

Выбрать рабочий порог передачи обращения оператору на отдельной валидационной выборке. Для самостоятельной проверки сначала выпишите три наблюдаемых состояния: допустимый вход, намеренно недопустимый вход и видимый сигнал отказа. В данной фикстуре это выглядит так: Метки [1,0,1,0], оценки [0.9,0.6,0.4,0.1]; при 0.5 один TP, один FP, один FN. При успешном тесте ожидается: Для 0.5 выводится (1,1,1,0.5,0.5); для 0.8 — (1,0,1,1.0,0.5). Показатели только учебные. Не превращайте это в числовой KPI: здесь проверяется контракт на конкретных примерах, а не поведение модели на пользовательском трафике.

Значения 0.5 и 0.8 не рекомендованы как универсальный порог. При отсутствии положительных прогнозов условный ноль в коде — договорённость примера, а не надёжное измерение precision. Подключая проверку к продукту, расположите её до той операции, ради которой она написана: парсинга, сохранения, отображения или экспорта. Для каждого нового формата добавляйте отдельный негативный пример и письменное решение, почему он отклоняется. Отдельно просмотрите обработку ошибок: система должна отличать невалидный ответ AI от сбоя тестовой инфраструктуры, а пользователь не должен видеть сырой стек или приватное содержимое.