Как проверить нейросеть на редких именах, артикулах и опечатках

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

Начните с поля, а не с модели

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

Соберите 80–120 обезличенных примеров из реальной работы. Разделите их на группы: привычные строки, редкие фамилии, латиница и кириллица рядом, цифры с буквами O/0 и I/1, лишний пробел, дефис, намеренная опечатка. Если архив не содержит достаточно редких примеров, добавьте искусственные, но отметьте их происхождение отдельно. Искусственный набор помогает проверить механику, однако не заменяет проверку на живом потоке. Для персональных данных используйте безопасные подстановки и не выгружайте исходный список в посторонний сервис.

Сделайте эталон человеком

Два редактора независимо размечают спорные строки. Один фиксирует точное значение поля, второй проверяет по первичному документу. Если документ сам нечитаем или содержит два кандидата, не заставляйте разметчиков угадывать: ставьте отметку «неопределённо» и объясняйте причину. Эталон должен содержать исходный текст, ожидаемый выход, класс сложности и допустимые варианты. Например, пробел вокруг дефиса может быть допустим в поиске, но недопустим в ключе учётной системы. Такие правила запишите до запуска модели.

Для сравнения разных инструментов используйте одинаковый запрос, контекст и набор входных строк. Не меняйте инструкцию после просмотра половины ответов, иначе тест превратится в настройку на контрольной выборке. Если нужен подбор формулировки, разделите примеры на разработочный и финальный набор. Последний открывайте только один раз после выбора способа. В практике контрольного набора новой модели разобрана эта граница между подбором и честной оценкой.

Посчитайте разные виды ошибки

Для артикула считайте долю точных совпадений, а не только «похоже на правильный товар». Отдельно отмечайте замены символа, потерю ведущего нуля, объединение двух полей и выдуманный код. Для поиска полезна доля запросов, где нужная карточка попала в первые результаты, но она не заменяет точность извлечения идентификатора. Для фамилий фиксируйте случаи, когда модель самовольно привела редкое написание к распространённому. Посмотрите результаты по каждой группе сложности, иначе высокий общий процент, полученный на обычных строках, скроет плохую работу на важных исключениях.

Затем добавьте цену ошибки. В черновике ответа сотруднику неверная буква может быть заметна при проверке. В автоматическом заказе она способна вызвать возврат, задержку и расходы. Поэтому один и тот же уровень точности может быть приемлем для подсказки оператору и неприемлем для прямой записи в систему. Решение о пороге должен принимать владелец процесса. Если модель возвращает уверенность, проверьте, совпадает ли она с реальной частотой ошибок на вашей выборке. Красивые 0,99 в интерфейсе ничего не значат без калибровки.

Проверьте ручной маршрут

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

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

Успешный результат здесь — не «нейросеть понимает текст», а конкретная доля корректно перенесённых кодов и понятная остановка там, где модель не уверена. Это измеримо и пригодно для решения о запуске.

Вопросы по тесту

Можно ли ограничиться десятью примерами? Десять помогут обнаружить грубую ошибку, но не покажут устойчивость по разным группам строк.

Исправлять ли все опечатки автоматически? Нет. В идентификаторе или имени «исправление» может создать новый неверный объект. Лучше предложить вариант на подтверждение.

Что делать с несколькими допустимыми написаниями? Зафиксировать их в эталоне и определить, где допустима нормализация, а где требуется точная копия.

Нужна ли генеративная модель для такого поля? Не всегда. Правило, словарь или точный поиск могут быть дешевле и надёжнее; сравните их на том же наборе.