Сохранять выходные данные перед их обобщением
Анализ начинается с соединения входных данных, эталонов и предсказаний. Убедитесь, что каждый ожидаемый идентификатор встречается ровно один раз. Отличайте неверный ответ от незавершённого запроса, дубликата или нечитаемого вывода. Эти проблемы требуют разных мер и не должны исчезать при вычислении среднего.
Сохраняйте необработанный вывод рядом с его нормализованной версией, ревизию модели, промпт, настройки и причину вердикта. Преобразование, которое молча превращает неоднозначную дату, может создать искусственный успех. Начинайте исследование на валидации. Если финальный тест служит для придумывания следующей коррекции, потребуется новое подтверждение, хранимое отдельно.
Технические источники: scikit-learn 1.9 — держать тест в стороне от выбора модели
Читать матрицу ошибок с её численностями
Для классификации с одной категорией на вход матрица сопоставляет эталонный класс и предсказанный класс. В используемой здесь и в scikit-learn конвенции строки содержат эталон, а столбцы — предсказание. Сохраняйте исходные численности до нормализации: процент без числа примеров может преувеличить надёжность вывода.
Следующий пример вымышлен и носит исключительно арифметический характер. Сто тикетов распределены между категориями «Счёт», «Доступ» и «Удаление». По диагонали расположены 54 + 24 + 5 = 83 правильных ответа, то есть 83 %. Этот итог скрывает класс «Удаление»: из 10 ожидаемых тикетов распознаны лишь 5. Ни одна модель и ни один GPU не выдавали этих цифр.
| Эталон | Предсказано «Счёт» | Предсказано «Доступ» | Предсказано «Удаление» | Реальный итог |
|---|---|---|---|---|
| Счёт | 54 | 5 | 1 | 60 |
| Доступ | 4 | 24 | 2 | 30 |
| Удаление | 4 | 1 | 5 | 10 |
| Предсказанный итог | 62 | 30 | 8 | 100 |
Технические источники: scikit-learn 1.9 — определение матрицы ошибок
Связать точность, полноту и практическое последствие
Для «Удаления» точность равна 5/8 = 62,5 %: среди тикетов, отнесённых к этой категории, пять верны. Полнота равна 5/10 = 50 %: найдена половина тикетов этой категории. F1 равен 2 × 5 / (2 × 5 + 3 + 5), то есть примерно 55,56 %. Три ложноположительных и пять ложноотрицательных результатов описывают разные проблемы.
F1 классов «Счёт», «Доступ» и «Удаление» равны соответственно 88,52 %, 80 % и 55,56 %. Их невзвешенное среднее, macro-F1, составляет примерно 74,69 %. Оно дополняет 83 % правильных ответов, не заменяя численности. Если класс отсутствует в эталонах или предсказаниях, некоторые метрики могут быть неопределены: объявляйте используемую конвенцию вместо того, чтобы прятать этот случай в среднем.
Технические источники: scikit-learn 1.9 — точность, полнота, F1, средние и деление на ноль
Построить короткую таксономию, связанную с действиями
Категория ошибки должна помогать решить, что именно проверять. Начните с нескольких категорий, определения и показательного примера. Добавьте основную метку, чтобы считать случаи без двойного учёта, затем вторичные метки, если сосуществуют несколько явлений. Оставьте категорию «требует проверки» вместо того, чтобы навязывать объяснение.
Эта таксономия — рабочее предложение, а не автоматический диагноз. Усечённый документ может также содержать неоднозначность ссылки. Частота метки описывает перепроверенные случаи; она ещё не доказывает причину. Сохраняйте входной фрагмент, который обосновывает вашу интерпретацию, и различайте наблюдаемую причину, гипотезу и недостающую информацию.
| Основная ошибка | Что нужно проверить | Возможный следующий эксперимент |
|---|---|---|
| Неполный вход | Усечение, отсутствующий фрагмент, неверная сборка | Исправить подготовку и перезапустить те же случаи |
| Неверный формат | Запрещённое поле или категория, разбор невозможен | Изменить контракт вывода и проверить также содержимое |
| Неверное содержимое | Ложное поле, путаница между категориями | Проверить целевую инструкцию или пример |
| Спорная ссылка | Неоднозначная аннотация, противоречивая инструкция | Вынести решение, затем версионировать эталон для всех вариантов |
| Неполное выполнение | Остановка, timeout, отсутствующий результат | Обработать пайплайн; сохранить сбой в итоге |
Для извлечения считайте поля и документы
Допустимый формат JSON не гарантирует, что значения верны. Зафиксируйте разрешённые нормализации: канонический формат даты, десятичный разделитель, пробелы или коды категорий. Различайте отсутствующее поле, выдуманное значение и разрешённое воздержание. Отсутствующее в документе значение не должно заменяться догадкой ради повышения доли заполнения.
Вот второй иллюстративный расчёт, независимый от таблицы классификации. В пятидесяти документах ожидается по три поля, то есть 150 значений. Предположим, 38 документов полностью корректны, шесть — с двумя верными полями и шесть — с одним. Это даёт 38 × 3 + 6 × 2 + 6 × 1 = 132 верных значения, то есть 88 %. Однако лишь 38/50 = 76 % документов полностью приемлемы, если требуются все три поля.
18 неверных значений затрагивают двенадцать документов. Не представляйте их как восемнадцать проблемных документов. В зависимости от задачи полезной единицей будет проверенное поле или полностью принятый документ; определите её до сравнения. Сохраняйте результаты по полям, чтобы понимать, связана ли сложность с датами, суммами или категориями.
| Тип документа | Документы | Верных полей на документ | Всего верных полей |
|---|---|---|---|
| Полностью корректно | 38 | 3 | 114 |
| Одна ошибка | 6 | 2 | 12 |
| Две ошибки | 6 | 1 | 6 |
| Итого | 50 | — | 132 из 150 |
Выбрать исправление до перезапуска кампании
Расставляйте приоритеты по последствиям и охвату, а не только по числу строк. В фиктивной матрице пять ошибок категории «Удаление» могут заслуживать проверки раньше шести ошибок категории «Счёт», если проект определил эту категорию как критическую. Этот приоритет принадлежит контракту проекта; таблица не позволяет выдумать бизнес-значимость.
Сформулируйте проверяемую гипотезу: «Длинные входы теряют решающий фрагмент при подготовке». Выберите изменение, позволяющее её проверить, затем оставьте всё остальное неизменным. Одновременное добавление примеров, смена модели и увеличение контекста могут повысить оценку, но уже не позволят приписать эффект одному исправлению.
- Перепроверьте несколько успешных случаев помимо ошибок, чтобы убедиться, что критерий применяется последовательно.
- Сравнивайте варианты на одних и тех же идентификаторах и ссылках; отдельно отмечайте любое изменение корпуса.
- Различайте исправленные ошибки, сохраняющиеся ошибки, новые ошибки и неизменённые случаи.
- Запускайте также примеры вне целевой категории, чтобы искать регрессии.
Проверить прирост, не стирая регрессии
Парный расчёт показывает то, что скрывает чистая оценка. На ста фиктивных тикетах представим, что исправлено девять ошибок, но четыре прежних успеха стали неверными. Итог меняется с 83 на 83 + 9 − 4 = 88 правильных ответов. Прирост составляет пять пунктов при четырёх регрессиях, требующих проверки. Это не означает, что девять исправлений были получены без компенсации.
В отчёте о решении сохраняются таблицы «до/после», исправленные случаи, новые ошибки, версия исправления и пройденные критерии. Если критическое правило по-прежнему нарушается, более высокий средний балл не даёт оснований принять вариант. Затем затраты и время сравниваются между допустимыми вариантами; ускорение отклонённого результата не решает проблему качества.
Ограничьте вывод тем, что было проверено
Эффектная ошибка не обязательно показательна. Если вы перечитываете в основном длинные записи или неудачи редкой категории, укажите этот способ отбора и не представляйте их частоты как частоты по всему корпусу. Также сохраняйте неразрешённые случаи: они определяют неопределённость вашей оценки.
Ваш анализ пригоден к использованию, когда другой читатель может найти запись, понять вердикт и проверить предложенное исправление. Он не доказывает ни внутреннюю причину сгенерированного ответа, ни гарантированное качество в будущем. Переходите к отложенному финальному набору после выбора исправления, а затем архивируйте ограничения вместе с выводом.
Практические вопросы
Достаточно ли роста общего балла, чтобы принять вариант?
Нет. Проверьте критические категории, новые ошибки и принятые полные выходные данные. Средний рост может coexствовать с регрессией, нарушающей критерий проекта.
Нужно ли исправлять эталон, когда модель ему противоречит?
Сначала проверьте запись и инструкцию по аннотированию. Если эталон ошибочен, примите решение и версионируйте исправление, затем примените его ко всем вариантам. Одного несогласия модели недостаточно, чтобы менять ожидаемый ответ.
Можно ли суммировать категории моей таксономии?
Только если у каждого случая есть одна основная эксклюзивная категория для этого подсчёта. Вторичные метки могут пересекаться; тогда их сумма считает вхождения меток, а не отдельные ошибки.