Прибыль:
- Определение показателей, которые отдельно измеряют удержание и качество генерации.
- Создайте золотой набор вопросов и запустите автоматическую оценку с помощью LLM-as-Judge.
- Поддержание качества посредством обратной связи, мониторинга и регрессионного тестирования в производстве
Предложение «Установил помощник, вроде работает нормально» не является инженерным высказыванием. Системы RAG выходят из строя незаметно: новый тип документа затрудняет поиск, быстрое изменение снижает точность, индекс устаревает. Единственный способ понять это – измерить. В этом разделе мы рассмотрим, как измерять качество RAG (извлечение и генерация отдельно), автоматическую оценку (LLM-как судья) и поддерживать качество в производстве (мониторинг, регрессия). «Невозможно улучшить то, что не измеряешь» — девиз этого подразделения.
Измерьте две разные вещи
RAG имеет две ножки, и их необходимо измерять отдельно, поскольку проблема может быть в любой из них:
- Качество поиска: пришла ли нужная деталь?
- Качество генерации: был ли правильный ответ получен из входящего фрагмента?
Если ответ плохой, вам нужно сначала узнать, какая нога плохая. Если нужная часть так и не приходит, даже самая лучшая подсказка не сможет сохраниться (проблема с поиском). Если пришла правильная часть, но модель неправильно ее прочитала, улучшение поиска бесполезно (проблема генерации).
Метрики извлечения
Поиск — это проблема сортировки/доступа; измеряется классическими метриками информационного поиска. Для этого у вас должна быть золотая гроздь: знание того, какая часть «правильная» для каждого вопроса.
метрика
Какие меры
Простое определение
Напомним@к
Правильная фигура находится в верхнем k?
Правильная скорость захвата деталей
точность@к
Сколько из k возвращенных частей являются релевантными?
Уборка принесенного
MRR (средний обратный ранг)
В каком порядке правильный фрагмент?
Награды за первые места
Частота попаданий
Пришла хотя бы одна правильная деталь?
Самый основной показатель успеха
Практический комментарий: если Recall@k низкий, стратегию разбивки или поиска (гибрид, k, переранжирование) следует переработать. Если точность низкая, но запоминаемость высокая, добавление повторного ранжирования является хорошим шагом.
Метрики поколения
Когда поступает нужная деталь, мы измеряем качество ответа модели. Три основных измерения:
- Правдивость: Подтверждается ли каждое утверждение в ответе контекстом? Есть ли примерка? Это прямой показатель галлюцинаций.
- Актуальность ответа: действительно ли ответ отвечает на вопрос или это не по теме?
- Полнота: вся ли соответствующая информация в контексте была использована или она отсутствует?
Часто они оцениваются по шкале (например, от 1 до 5), а не по двоичной шкале, например «верно/неверно».
Совет: отслеживайте верность как отдельный показатель. Если достоверность снижается по мере снижения точности, проблема в генерации; Если верность высокая, но ответ неправильный, проблема в неправильном фрагменте (извлечение). Вместе эти две метрики представляют собой компас, показывающий место неисправности.
Создание золотого набора вопросов
Для каждого измерения требуется золотой набор/набор оценочных данных: реалистичные вопросы + ожидаемые правильные ответы + правильные исходные данные. Лучше начать с 30–50 хорошо подобранных вопросов, чем с 500 случайных вопросов. Включите в набор: часто задаваемые реальные вопросы, известные трудные вопросы, вопросы-ловушки без ответов (нужно сказать «не знаю»), вопросы с противоречивыми источниками.
# Пример золотого кластера (концептуальный)[ {"question": "Сколько дней ежегодного отпуска?", "expected_answer": "14 дней для стажа от 1 до 5 лет", "correct_part_id": "two-part-3", "category": "leave"}, {"question": "Где находится офис компании на Марсе?", "expected_answer": "NO_INFORMATION", # ловушка: I не знаю "correct_part_id": null, "category": "trap"}]
LLM как судья: автоматическая оценка
Набирать сотни ответов вручную утомительно. Модель LLM как судьи – это когда одна модель оценивает и обосновывает ответ другой модели на основе определенных критериев. Хороший судья четко определяет критерии, приводит примеры и требует обоснования.
# Подсказка для LLM как судьи (концептуальная) Вы беспристрастный оценщик. Оцените ОТВЕТ ниже в соответствии с данным КОНТЕКСТОМ и ОЖИДАЕМЫМ ОТВЕТОМ. Оцените (1-5) и обоснуйте: - достоверность: каждое утверждение в ответе подтверждается контекстом? - точность: соответствует ли ответ ожидаемому ответу? - полнота: является ли соответствующая информация полной? В частности: если ответ содержит информацию, не входящую в контекст, укажите достоверность1 и укажите, какое утверждение сфабриковано. КОНТЕКСТ: {контекст}ОЖИДАЕМЫЙ: {ожидаемый}ОТВЕТ: {ответ}Вывод: {достоверность, точность, полнота, обоснованность}
Внимание: степень магистра права в качестве судьи не идеальна; У них могут быть свои предубеждения (длинный ответ, предпочтение своему стилю). Также проверьте судью: получите несколько ответов, оцененных как судьей, так и человеком, и измерьте согласие между ними. Если Джадж соответствует человеческим оценкам, ему можно доверять.
Слабый/сильный рейтинг
Слабые («мне было хорошо»):
Я задал несколько вопросов, и ответы показались мне хорошими. У меня все работает.# Проблема: нет измерений, регресс незаметен, улучшение слепое.
Мощный (золотой кластер + дискретные показатели + автоматическое суждение + регрессия):
Золотой кластер из 40 вопросов. При каждом изменении, rev@5, достоверность и точность измеряются автоматически. Если оценка падает, изменение откатывается. В процессе производства отзывы пользователей собираются и добавляются в набор.
Мониторинг и регрессия в производстве
Оценка не делается один раз и не завершается. Три постоянные практики:
- Регрессионное тестирование: автоматический запуск золотого кластера при каждом изменении запроса/извлечения/модели. Если количество очков уменьшается, изменение отменяется. Это предотвращает «сломание при попытке сделать лучше».
- Мониторинг производства: отслеживается показатель «Не удалось найти информацию» в реальных вопросах, средняя задержка, стоимость, отзывы пользователей (👍/👎). Внезапное увеличение числа «Я не знаю» часто является первым признаком неисправности индекса или поиска.
- Цикл обратной связи: реальные вопросы, заданные пользователем 👎, просматриваются и добавляются в золотую стопку; Таким образом, со временем набор становится богаче и слепые зоны системы закрываются.
Три мини-кейса
Случай 1 — Тихая регрессия. Команда изменила приглашение, чтобы «улучшить» его; Общая точность увеличилась, но достоверность в вопросах-ловушках снизилась на 30% (модель стала лучше подходить). Этого бы не заметили, если бы не вопросы-ловушки в золотом кластере; Регрессионное тестирование вернуло изменения.
Случай 2 — Выпрямление не той ноги. У одного помощника ответы были плохими; Команда работала над подсказкой несколько недель. Когда мы измерили метрики поиска, отзыв@5 составил всего 48% — проблема была в поиске, а не в генерации. Когда было добавлено гибридное + повторное ранжирование, запоминаемость увеличилась до 89%, а также увеличилась точность.
Случай 3 — Производственное оповещение. Однажды показатель «Я не смог найти информацию» для помощника службы поддержки подскочил с 6% до 34%. Трекпад предупредил; Причина заключалась в том, что работа по индексированию, которая выполнялась ночью, молча завершилась неудачно, и новые статьи не были загружены. Без мониторинга неверные заявления типа «Я не знаю» продолжались бы в течение нескольких дней.
Распространенные ошибки
- Удовлетворенность тем, что «мне это помогло»: без измерения регресс остается незамеченным.
- Не разделяя поиск и генерацию: вы поправите не ту ногу и потратите время.
- Не задавать вопросов-ловушек. Тенденция выдумывать не проявляется в золотом кластере.
- Непроверка судьи: предвзятое жюри дает ложную уверенность.
- Отсутствие контроля над производством: провал индекса, взрыв затрат продолжается молча.
В заключение
- В RAG качество извлечения и генерации измеряется отдельно; Сначала необходимо определить, какая нога повреждена.
- отзыв@k, точность@k, MRR для поиска; Для генерации используются достоверность, пригодность, полнота.
- Для каждого измерения требуется золотой кластер; Задавайте в нем реальные, трудные, ловушки и противоречивые вопросы.
- LLM в качестве судьи автоматически набирает большие наборы баллов; но судья сам должен быть оправдан перед человеком.
- Регрессионное тестирование, мониторинг производства и цикл обратной связи поддерживают качество с течением времени.
Задача приложения
(1) Создайте золотой набор как минимум из 15 вопросов для своего помощника: включите как минимум 3 ловушки (без ответов), 3 сложных и 2 противоречивых вопроса. Напишите ожидаемый ответ и правильную часть для каждого вопроса. (2) Вручную сравните две разные версии приглашения с этим набором; За достоверность и точность дайте каждому ответу 1–5 баллов. (3) Адаптируйте приведенную выше подсказку «магистр права в качестве судьи» к своим собственным критериям. (4) Определите три показателя, которые вы будете отслеживать в производстве, и для каждого задайте вопрос: «При каком пороге я предупреждаю?» напишите значение.
контрольный список
- [ ] Я могу измерить качество удержания и генерации с помощью отдельных показателей.
- [ ] Я знаю, что означают такие показатели, как отзыв @k, верность.
- [ ] Я могу создать золотую группу вопросов, включающую реальные, трудные, ловушки и противоречивые вопросы.
- [ ] Я могу настроить автоматическую оценку и проверить судью с помощью LLM-as-Judge.
- [ ] Я могу управлять регрессионным тестированием, мониторингом производства и обратной связью.