Инструмент оценки обнаружил то, что не смог качественный анализ: модели ИИ наиболее уверены в себе, когда они ошибаются
Существует этап в процессе разработки инструментов на базе больших языковых моделей (LLM), который большинство команд пропускают, поскольку он является утомительным, трудоемким и не приносит результатов, видимых конечным пользователям: проверка того, действительно ли то, что говорит модель, является правильным. Не беглым, не когерентным, не актуальным по теме — правильным в смысле точного определения верного решения конкретной проблемы, для которой был создан этот инструмент.
Разрыв между «этот результат звучит для меня убедительно» и «этот результат доказанно верен» — это то место, где большинство созданных для корпоративного сектора инструментов на базе LLM незаметно терпят неудачу. Они проходят внутреннюю проверку, потому что результат звучит убедительно. Они ломаются в продакшене, потому что эти люди проверяли результат не на соответствие объективной реальности — они сверялись со своей интуицией о том, как должен выглядеть хороший ответ.
Это различие приобретает все большее значение по мере того, как инструменты на базе LLM переходят из категории вспомогательных средств повышения производительности в разряд компонентов, влияющих на реальные бизнес-решения. Если ваш инструмент на основе ИИ влияет на то, как аналитик исследует проблему качества данных, как специалист по комплаенсу решает, следует ли эскалировать отмеченную запись, или как операционная команда проводит триаж сбоя валидации — точность его вывода имеет вполне реальные последствия. Формулировка «выглядит разумно» не является адекватным стандартом оценки для таких задач.
Что на самом деле выявляет качественная оценка
Стандартный подход к оценке результатов работы LLM в корпоративных инструментах носит качественный характер: выборка результатов проверяется кем-то, кто обладает предметными знаниями, оценивается на основе ментальной модели того, как должен выглядеть хороший ответ, и промпт корректируется, если слишком много результатов кажутся отклоняющимися от нормы.
Это позволяет выявить определенный класс проблем: результаты, которые явно ошибочны, плохо отформатированы или не относятся к делу. Это реальные проблемы, которые стоит выявлять. Но это также и самые простые задачи.
Чего качественная оценка неизменно упускает из виду, так это класс результатов, которые неверны таким образом, что это трудно заметить без сверки с чем-то внешним. Объяснение, в котором уверенно указывается не та первопричина, написанное авторитетным языком и основанное на правдоподобно звучащих рассуждениях — такой результат проходит качественную рецензию. И он терпит крах в тот момент, когда человек с надлежащим контекстом сверяет его с тем, что произошло на самом деле.
В системе, ценность которой зависит от точности, «звучит правдоподобно» не означает «правильно». Эти два понятия могут существенно расходиться, и качественная проверка не подскажет вам, когда именно это произошло.
Как выглядит реальный тестовый комплекс для оценки (eval harness)
Альтернативой является создание системы оценки (eval harness), которая оценивает результаты работы модели по размеченным эталонным данным (ground truth) — набору кейсов, где правильный ответ известен заранее, что позволяет измерять точность, а не когерентность.
Я создал такую систему при разработке модуля поиска первопричин для дрейфа данных при миграции: инструмента, который принимает обнаруженное событие дрейфа и генерирует ранжированное объяснение того, что наиболее вероятно его вызвало. Первый прототип выдавал беглые, звучащие конкретно объяснения, которые прошли качественную проверку. Когда я протестировал его на кейсах, где первопричина была мне уже известна, объяснение оказывалось неверным достаточно часто, чтобы это имело значение.
Построенный мной комплекс оценки работает в три этапа.
Во-первых, синтетический набор эталонных данных: кейсы, где правильный ответ известен по определению. Это означало внедрение конкретных, контролируемых причин в тестовый конвейер — изменений схемы, багов в логике трансформации, изменений в поведении исходной системы, — с фиксацией того, что именно я внедрил, и запуском модели на полученных событиях дрейфа. Правильным ответом для каждого кейса была та причина, которую я намеренно заложил.
Придание синтетическим сценариям достаточной для практической пользы реалистичности потребовало больше внимания, чем я ожидал. Ранние версии были слишком «чистыми» — сигнал о дрейфе был очевидным совсем не так, как это бывает при реальных производственных сбоях. Добавление реалистичного шума, накладывающихся друг на друга сигналов и случаев, когда одновременно присутствовало несколько правдоподобных причин, — именно это сделало синтетический набор действительно прогностически ценным для оценки реальной производительности.
Во-вторых, функция оценки, которая анализирует ранжированный вывод. Бинарная оценка верно/неверно недостаточна, когда модель выдает ранжированный список вероятных причин, а не единственный ответ. Объяснение, которое правильно определяет первопричину как третий по вероятности кандидат, существенно отличается от того, которое определяет ее как наиболее вероятную. Функция оценки оценивала два измерения: присутствие — появился ли правильный ответ в выводе вообще — и ранг — насколько заметно он выделялся по сравнению с неверными кандидатами. Они объединялись в взвешенную оценку, которая вознаграждала как нахождение правильного ответа, так и его адекватное ранжирование.
В-третьих, систематическая оценка по всему синтетическому набору данных вместо выборочной проверки. Запуск тестового комплекса на всем наборе выявляет закономерности, которые ускользают при выборочной проверке: с какими категориями проблем модель справляется надежно, в каких стабильно ошибается и какие комбинации сигналов приводят к наибольшему количеству уверенных, но ошибочных объяснений.
Что показала оценка
Результаты оказались более информативными, чем любая качественная проверка могла бы обеспечить.
Сценарии с изменением схем получили хорошие оценки — модель надежно определяла изменения исходной схемы, когда доказательства были налицо и отличались специфичностью. Ошибки в логике трансформаций давались сложнее — модель стабильно определяла общую категорию, но неверно атрибутировала конкретное изменение, вызвавшее проблему, особенно когда несколько изменений были внесены близко друг к другу. Сценарии с накладывающимися сигналами оказались самыми сложными — случаи, когда две разные причины происходили с небольшим интервалом по времени, генерировали наибольший процент уверенно неверных объяснений.
Этот последний вывод качественная проверка никогда бы не обнаружила. Выраженная моделью уверенность не коррелировала с ее точностью — она была наиболее уверена в тех случаях, когда ошибалась сильнее всего. Без системы оценки, измеряющей результаты по эталонным данным, эта закономерность осталась бы незамеченной.
Практическое значение для развертывания корпоративного ИИ
Для команд, развертывающих инструменты на базе LLM в корпоративной среде — особенно инструменты, которые влияют на то, как люди расследуют проблемы, проводят триаж алертов или принимают решения о маршрутизации, — ключевой вопрос перед развертыванием в продакшене звучит так: измерили ли мы точность на кейсах, где нам известен правильный ответ, или мы лишь оценили, кажутся ли результаты разумными?
Если ответ заключается в последнем, инструмент был протестирован на беглость и когерентность, но не на правильность. Это разные свойства. Для инструментов, определяющих бизнес-решения, именно правильность имеет решающее значение.
Создание синтетического набора эталонных данных — это самая сложная часть и то, во что больше всего стоит инвестировать. Это заставляет вас четко определить, что именно означает «правильно» для вашего конкретного сценария использования, что само по себе оказывается полезным упражнением, независимым от самой оценки. Функция оценки и инфраструктура тестового комплекса относительно просты, как только у вас появляется такое определение. Без него вы измеряете что-то другое, а не то, что пытаетесь гарантировать.
Арун Мишра — корпоративный архитектор.
Добро пожаловать в сообщество VentureBeat!
Наша программа гостевого блогинга — это место, где технические эксперты делятся идеями и публикуют нейтральные, неангажированные глубокие обзоры об ИИ, инфраструктуре данных, кибербезопасности и других передовых технологиях, формирующих будущее корпоративного сектора.
Читайте далее в рамках нашей программы гостевых публикаций и ознакомьтесь с нашими правилами, если вы заинтересованы в публикации собственной статьи!
