28 октября 2026 года вышел разбор проверки AI-инструментов до запуска. Речь идёт о ботах для внутренней базы знаний, саммари писем в CRM и черновиках ответов для службы поддержки.
Сотрудники редко заводят тикеты на ошибки внутреннего бота: они либо возвращаются к прежнему способу работы, либо принимают уверенный ответ без проверки. Поэтому после запуска команда может не увидеть часть проблем.
Для предварительной проверки используют eval — набор сценариев и критериев, по которым оценивают ответы модели. Сначала команда определяет, что считать хорошим результатом для конкретной задачи.
Для саммари это сохранённые ключевые факты, отсутствие выдуманных деталей и разумная длина. Для ассистента по внутренним документам — правильный ответ, соблюдение правил и передача вопроса человеку, если данных недостаточно.
Демо-запросы обычно аккуратнее рабочих. В реальной переписке встречаются короткие сообщения, длинные цепочки, таблицы, жаргон, опечатки, тексты на двух языках и противоречивые просьбы.
Внутренняя база знаний тоже создаёт риски: рядом могут находиться документы разных лет, которые выглядят одинаково официально. В тестах нужно проверять, находит ли система актуальный источник и опирается ли на него в ответе.
Одной средней оценки недостаточно. Для классификации обращений используют accuracy, precision и recall. Тексты проверяют отдельно по фактам, полноте, соблюдению инструкции и тону.
Отдельно считают тяжёлые ошибки и случаи, когда система признаёт, что не знает ответа. Для некоторых задач отказ от догадки и передача вопроса сотруднику безопаснее уверенного, но неверного ответа.
Набор тестов можно составить из реальных запросов коллег. В него стоит включить случаи с недостающими данными, двусмысленными формулировками, конфликтующими инструкциями и попытками нарушить правила.
Если в примерах есть персональные данные, сведения о зарплате или условия договоров, их нужно очистить либо хранить с той же защитой, что и исходные материалы.
После проверки на подготовленных сценариях инструмент предлагают одной команде в режиме, где сотрудник проверяет каждый результат. На пилоте измеряют долю ответов без правок, частоту использования, время ответа, стоимость запроса и обращения к коллегам с тем же вопросом.
До запуска нужно определить недопустимые ошибки, ответственных за проверку и случаи обязательной передачи задачи человеку. Начать можно с небольшого набора типичных и сложных рабочих сценариев.
