Инженер Арун Мишра строил инструмент, который объясняет причины расхождений в данных при миграции. Первая версия выдавала гладкие и уверенные ответы, и команда их приняла. Когда же объяснения проверили на кейсах, где настоящая причина была известна заранее, модель ошиблась достаточно часто, чтобы это имело значение. Так выяснилось: уверенность LLM не связана с точностью, и качественная проверка этого не видит.

Почему проверка «звучит разумно» пропускает ошибки

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

Он стабильно пропускает другой класс: ответы, которые неверны так, что без внешней сверки этого не увидеть. Объяснение, которое уверенно называет не ту причину, звучит авторитетно, рассуждение кажется правдоподобным. Качественная проверка такой ответ пропускает. Ошибка всплывает, только когда человек с контекстом сверяет ответ с тем, что случилось на самом деле.

Разрыв между «этот вывод звучит правильно» и «этот вывод подтверждён фактами» - место, где большинство LLM-инструментов тихо ломаются. Внутреннюю проверку они проходят, потому что ответ звучит убедительно. В проде падают, потому что проверявшие сверялись не с истиной, а со своей интуицией о том, как выглядит хороший ответ.

Это становится важнее по мере того, как инструменты на LLM переходят из разряда помощников для продуктивности в компоненты, влияющие на деловые решения. Если ИИ-инструмент подсказывает аналитику, как разбирать проблему с качеством данных, влияет на решение комплаенс-специалиста о том, эскалировать ли запись, или помогает операционной команде сортировать сбои валидации, точность ответа имеет последствия. «Выглядит разумно» - недостаточный стандарт оценки для такого.

Как устроен eval harness

Альтернатива - оценочный стенд (eval harness), который сравнивает вывод модели с размеченной истиной (ground truth): набором кейсов, где правильный ответ известен заранее. Вместо связности измеряется точность.

Автор собрал такой стенд для объяснителя причин расхождений при миграции данных. Инструмент получает обнаруженное расхождение и выдаёт ранжированный список вероятных причин. Стенд состоит из трёх частей.

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

Вторая - функция скоринга для ранжированных ответов. Бинарный «верно/неверно» не подходит, когда модель выдаёт список вероятных причин. Объяснение, которое поставило настоящую причину на третье место, отличается от того, что поставило её на первое. Оценка шла по двум осям: присутствие (появился ли правильный ответ в выводе вообще) и ранг (насколько заметно он подан относительно неверных кандидатов). Взвешенная сумма поощряла и нахождение ответа, и правильную расстановку приоритетов.

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

Что показали тесты

Результаты оказались информативнее любой качественной проверки.

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

Главный вывод: уверенность модели не коррелировала с точностью. Она была наиболее уверена в тех случаях, где ошибалась сильнее всего. Без стенда, измеряющего точность против известных ответов, эта закономерность осталась бы невидимой.

Качественная проверка такой вывод не дала бы в принципе. Она заточена под очевидные дефекты и слепа к уверенной ошибке.

Что это значит для бизнеса

Для команд, которые внедряют инструменты на LLM в корпоративные процессы, вопрос перед запуском в прод один: точность измерена на кейсах с известным ответом или только проверено, что выводы выглядят разумно? Если второе, инструмент протестирован на связность, но не на правильность. Это разные свойства. Для инструментов, влияющих на решения, нужна именно правильность.

Самая трудная и самая ценная часть - синтетический датасет с известными ответами. Он заставляет точно определить, что значит «правильно» для вашего сценария, и это полезное упражнение само по себе. Функция скоринга и инфраструктура стенда собираются быстро, когда определение есть. Без него вы измеряете не то, что хотите гарантировать.

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