Пятиэтапная методика построения строгих и воспроизводимых эталонных показателей для поиска с использованием ИИ — прежде чем принимать решения о вложении шестизначных сумм в инфраструктуру.
Делиться
Я работаю в сфере оценки ИИ почти десять лет, и меня часто спрашивают: «Как узнать, оптимизирована ли наша текущая система ИИ?» Честный ответ? Многочисленные тесты. Четкие критерии позволяют измерять улучшения, сравнивать поставщиков и обосновывать окупаемость инвестиций.
Большинство команд оценивают эффективность поиска с использованием ИИ, выполняя несколько запросов и выбирая ту систему, которая «кажется» лучшей. Затем они тратят шесть месяцев на её интеграцию, только чтобы обнаружить, что точность на самом деле хуже, чем у их предыдущей системы. Вот как избежать этой ошибки стоимостью 500 000 долларов.
Проблема: тестирование «на ходу» не отражает реальную работу системы, не воспроизводимо, а корпоративные бенчмарки не адаптированы к вашим конкретным задачам. Эффективные бенчмарки должны быть разработаны с учетом специфики вашей предметной области, охватывать различные типы запросов, давать согласованные результаты и учитывать разногласия между оценщиками. После многолетних исследований в области оценки качества поиска, вот процесс, который действительно работает в реальных условиях.
Базовый стандарт оценки
Шаг 1: Определите, что означает «хорошо» в вашем конкретном случае.
Прежде чем запускать хотя бы один тестовый запрос, определите, как выглядит «правильный» ответ. К общим характеристикам относятся базовая точность, актуальность результатов и релевантность источников.
Для клиента из сферы финансовых услуг это может быть: «Числовые данные должны быть точными с погрешностью не более 0,1% по сравнению с официальными источниками, с указанием времени публикации». Для компании, разрабатывающей инструменты для разработчиков: «Примеры кода должны выполняться без изменений в указанной версии языка».
Затем задокументируйте свой порог для смены поставщика услуг. Вместо произвольного «улучшения на 5-15%» свяжите его с влиянием на бизнес: если улучшение точности на 1% экономит вашей команде поддержки 40 часов в месяц, а смена поставщика обходится в 10 000 долларов в виде затрат на инженерное время, вы выходите на точку безубыточности при улучшении на 2,5% уже в первый месяц.
Шаг 2: Создайте свой эталонный набор тестовых данных.
«Золотой набор» — это тщательно подобранная коллекция запросов и ответов, которая позволяет вашей организации прийти к единому мнению относительно качества. Начните сбор этих запросов с анализа журналов запросов в производственной среде. Я рекомендую заполнить «золотой набор» на 80% запросами, относящимися к распространенным шаблонам, а оставшиеся 20% — к крайним случаям. Для размера выборки стремитесь к минимуму в 100-200 запросов; это обеспечит доверительные интервалы ±2-3%, достаточно узкие для выявления значимых различий между поставщиками.
Затем разработайте оценочную шкалу для проверки точности каждого запроса. Для фактических запросов я определяю следующее: «4 балла, если результат содержит точный ответ с авторитетной ссылкой. 3 балла, если ответ верен, но требует выводов пользователя. 2 балла, если частично релевантно. 1 балл, если косвенно связано. 0 баллов, если не связано». Включите 5-10 примеров запросов с оцененными результатами для каждой категории.
После составления списка попросите двух независимых экспертов в данной области оценить 10 лучших результатов каждого запроса и измерить степень согласованности с помощью коэффициента Каппа Коэна. Если он ниже 0,60, возможно, существуют различные проблемы, такие как нечеткие критерии, недостаточное обучение или различия в суждениях, которые необходимо устранить. При внесении изменений используйте журнал изменений для фиксации новых версий каждой оценочной шкалы. Вам потребуется поддерживать отдельные версии для каждого теста, чтобы иметь возможность воспроизвести их в последующих тестах.
Шаг 3: Проведение контролируемых сравнений
Теперь, когда у вас есть список тестовых запросов и четкая критерия оценки точности, выполните свой набор запросов параллельно для всех поставщиков и соберите 10 лучших результатов, включая позицию, заголовок, фрагмент, URL и временную метку. Также следует регистрировать задержку запроса, коды состояния HTTP, версии API и количество результатов.
Для конвейеров RAG или тестирования агентного поиска пропустите каждый результат через одни и те же LLM с идентичными подсказками синтеза, установив температуру на 0 (поскольку вы изолируете качество поиска).
Большинство оценок не проходят, потому что каждый запрос выполняется только один раз. Системы поиска по своей природе стохастичны, поэтому случайность выборки, изменчивость API и поведение по таймауту вносят вариативность от попытки к попытке. Для корректного измерения этого параметра следует проводить несколько попыток для каждого запроса (я рекомендую начинать с n=8-16 попыток для задач структурированного поиска, n≥32 для задач сложного рассуждения).
Шаг 4: Оценка работ членами жюри программы LLM.
Современные LLM обладают значительно большей вычислительной мощностью, чем поисковые системы. Поисковые системы используют небольшие алгоритмы переранжирования, оптимизированные для задержки в миллисекунды, в то время как LLM используют более 100 миллиардов параметров, на рассуждение по каждому результату уходит несколько секунд. Эта асимметрия в вычислительной мощности означает, что LLM могут оценивать качество результатов более тщательно, чем системы, которые их создали.
Однако этот анализ работает только в том случае, если вы предоставите LLM подробную систему оценки, использующую те же критерии, что и эксперты-люди. В качестве демонстрации предоставьте примеры запросов с оцененными результатами и потребуйте структурированный вывод в формате JSON с оценкой релевантности (0-4) и кратким пояснением к каждому результату.
Одновременно с этим, проведите оценку с помощью LLM-эксперта, поручив двум экспертам оценить подмножество из 100 вопросов, охватывающих простые, средние и сложные запросы. После этого рассчитайте согласованность между экспертами, используя коэффициент Каппа Коэна (целевое значение: κ > 0,70) и коэффициент корреляции Пирсона (целевое значение: r > 0,80). Я видел, как Клод Сонне достигал согласованности 0,84 с экспертами, когда критерии оценки были четко определены.
Шаг 5: Оценка стабильности результатов оценки с помощью коэффициента внутриклассовой корреляции (ICC).
Одной лишь точности недостаточно, чтобы судить о достоверности вашей оценки. Вам также необходимо знать, отражает ли наблюдаемое вами расхождение в результатах поиска реальные различия в сложности запросов или просто случайный шум, вызванный непоследовательным поведением поставщика моделей.
Коэффициент внутриклассовой корреляции (ICC) разделяет дисперсию на две категории: дисперсия между запросами (некоторые запросы просто сложнее других) и дисперсия внутри запросов (непоследовательные результаты для одного и того же запроса при разных запусках).
Вот как интерпретировать ICC при проверке поставщиков поисковых услуг на основе ИИ:
- ICC ≥ 0,75: Хорошая надежность. Ответы поставщиков услуг согласуются.
- ICC = 0,50-0,75: Умеренная надежность. Смешанный вклад от сложности запроса и непоследовательности поставщика услуг.
- ICC < 0,50: Низкая надежность. Результаты, полученные за один сеанс, ненадежны.
Рассмотрим двух поставщиков услуг, оба демонстрируют точность в 73%:
| Точность | МУС | Интерпретация |
| 73% | 0,66 | Последовательность поведения на протяжении всех испытаний. |
| 73% | 0.30 | Непредсказуемо. Один и тот же запрос выдает разные результаты. |
Без ICC вы бы развернули второго поставщика, полагая, что получаете 73% точности, но в производственной среде обнаружили бы проблемы с надежностью.
В ходе нашего исследования, оценивающего поставщиков услуг по задачам GAIA (задачи на логическое мышление) и FRAMES (задачи на поиск информации), мы обнаружили, что коэффициент внутриклассовой корреляции (ICC) резко меняется в зависимости от сложности задачи: от 0,30 для сложных задач на логическое мышление с использованием менее совершенных моделей до 0,71 для структурированного поиска информации. Часто улучшение точности без улучшения ICC отражало скорее удачную выборку, чем реальное повышение возможностей системы.
Как на самом деле выглядит успех
После такой проверки вы можете оценить поставщиков услуг по всему набору тестовых данных. Результаты могут выглядеть следующим образом:
- Поставщик услуг A: точность 81,2% ± 2,1% (95% доверительный интервал: 79,1–83,3%), внутриклассовый коэффициент корреляции = 0,68
- Поставщик B: точность 78,9% ± 2,8% (95% доверительный интервал: 76,1–81,7%), внутриклассовый коэффициент корреляции = 0,71
Интервалы не перекрываются, поэтому преимущество поставщика услуг A в точности статистически значимо при p<0,05. Однако более высокий коэффициент внутриклассовой корреляции (ICC) у поставщика услуг B означает, что он более стабилен — один и тот же запрос, более предсказуемые результаты. В зависимости от конкретного случая, стабильность может иметь большее значение, чем разница в точности в 2,3 процентных пункта.
- Показатель точности поставщика услуг C: 83,1% ± 4,8% (95% доверительный интервал: 78,3–87,9%), внутриклассовый коэффициент корреляции = 0,42.
- Показатель точности поставщика услуг D: 79,8% ± 4,2% (95% доверительный интервал: 75,6–84,0%), внутриклассовый коэффициент корреляции = 0,39.
Поставщик C выглядит лучше, но эти широкие доверительные интервалы существенно перекрываются. Что еще более важно, у обоих поставщиков коэффициент внутриклассовой корреляции (ICC) < 0,50, что указывает на то, что большая часть вариации обусловлена случайностью от испытания к испытанию, а не сложностью запроса. Когда вы видите подобную вариацию, вам необходимо отладить саму методологию оценки, прежде чем вы сможете доверять сравнению.
Это не единственный способ оценки качества поиска, но я считаю его одним из наиболее эффективных для достижения баланса между точностью и практической осуществимостью. Данная методика обеспечивает воспроизводимые результаты, позволяющие прогнозировать производительность в производственной среде, что дает возможность сравнивать поставщиков на равных условиях.
Сейчас мы находимся на этапе, когда полагаемся на выборочные демонстрации, и большинство сравнений поставщиков бессмысленны, потому что у всех разные показатели. Если вы принимаете решения о поисковой инфраструктуре на миллионы долларов, вы обязаны своей команде проводить правильные измерения.
Зайра Мустасан Посмотреть все от Зайры Мустасан
Источник: towardsdatascience.com
