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

Арун Мишра

В процессе разработки инструментов, использующих большие языковые модели (LLM), есть этап, который большинство команд пропускают, поскольку он утомителен, занимает много времени и не дает результатов, видимых конечным пользователям: проверка того, действительно ли модель говорит правильно. Не бегло, не связно, не тематически релевантно — правильно в смысле точного определения правильного ответа на конкретную проблему, для решения которой был создан инструмент.

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

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

Что именно выявляет качественная оценка?

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

Это позволяет выявить определенный класс проблем: результаты, которые явно неверны, плохо отформатированы или не соответствуют теме. Это действительно важные проблемы, которые стоит выявить. К тому же, это самые простые проблемы.

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

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

Как выглядит реальный оценочный ремень безопасности.

Альтернативный вариант — создание системы оценки, которая сравнивает результаты работы модели с размеченными эталонными данными — набором случаев, где известен правильный ответ, и на основе которых можно измерить точность, а не согласованность.

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

Созданный мной оценочный жгут состоит из трех частей.

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

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

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

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

Что показала оценка

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

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

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

Практические последствия для внедрения ИИ в предприятиях.

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

Если ответ — второй вариант, то инструмент был протестирован на беглость и связность, но не на корректность. Это разные свойства. Для инструментов, влияющих на принятие бизнес-решений, важна именно корректность.

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

Арун Мишра — архитектор корпоративных систем.

Добро пожаловать в сообщество VentureBeat!

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

Узнайте больше о нашей программе гостевых публикаций — и ознакомьтесь с нашими рекомендациями, если вы заинтересованы в написании собственной статьи!

Источник: venturebeat.com