Ликбез про RAG. ч.2. Фундаментальные ошибки.
За последние 3 года я пообщался с десятком+ команд из разных компаний, работающих над приложениями на основе RAG.
Две самые частые ошибки, которые я встречал:
- плохая подготовка данных - garbage-in > garbage-out,
- отсутствие evaluation (оценки качества) - не возможно улучшать то, что не измеряешь.
Разумеется, существует множество других проблем, но это фундамент для всей системы, без которого остальные решения теряют значимость. И самое нелепое, что обе проблемы очевидны с первого взгляда, но из-за сложности их решения, менеджеры зачастую игнорируют их до последнего.
1️⃣ Плохая подготовка данных - самая частая и известная ошибка любых DS/ML/DL проектов.
Я заметил, что она особенно актуальна для Gen AI проектов, потому что люди, работающие над такими проектами часто не имеют профильного образования или опыта работы с DS проектами. Некоторые инженеры всерьез считают, что если они сделали pip install langchain, то теперь они AI Engineer. Уже 3 года веду репо с подборкой бесплатных материалов по AI разработке, чтобы закрыть эту проблему в своих командах: GH repo.
Что делать с проблемой плохих данных? Ответ очевиден - чистить.
Самые универсальные советы:
- удалять старые и нерелевантные данные, дубликаты, пустые документы,
- проверять, что pdf, картинки, диаграммы, Excel, Word, attachements правильно обрабатываются,
- эффективно использовать мета-данные и структуру в данных,
- вычистить ошибки (фактологические, грамматические),
- предпочтительно иметь все тексты на одном языке,
- нормализовать онтологию - особенно, актуально для внутрипроектной документации.
Когда пишешь это, кажется, что все это какая-то базовая база, но вы не поверите как много людей не задумываются, что не надо игнорировать Excel, прикрепленный к Confluence странице или что невозможно делать нормальный векторный поиск по базе, где 30% документов - это заголовок без дополнительного текста.
После того как данные вычищены очевидный следующий шаг - разобраться, как правильно структурировать и предобрабатывать данные именно для вашего алгоритма поиска.
2️⃣ С evaluation все немного сложнее.
Зачем вообще мерить качество системы? С точки зрения бизнеса - без оценки качества не понятно решает ли система поставленную задачу и приносит ли она вообще пользу. С точки зрения разработчика - не возможно улучшать то, что ты не измеряешь.
Существует 3 типа метрик:
- бизнесовые (какую пользу в деньгах приносит RAG приложение),
- продуктовые (DAU, MAU, NPS, Session Length, actions or events и тд),
- качественные (точность, релевантность, полнота, MRR, …)
Бизнес метрики мерить напрямую, как правило, сложно, поэтому используются продуктовые прокси-метрики. Например, это может быть количество закрытых задач и среднее время, сэкономленное на задачу. Если все честно померить, то внезапно может оказаться, что разработка и внедрение AI приложения не оправдывает ожиданий.
Для качественных метрик можно выделить 4 дополнительных подмножества:
- оценка качества собранных данных (не популярно, а зря),
- оценка поиска,
- оценка генерации,
- оценка всей системы целиком - то есть качества ответов.
Последний вариант самый простой и можно начинать с него, но проблема в том, что через E2E оценку очень сложно управлять качеством отдельных этапов. Тем не менее начинать лучше всего именно с него - максимум ценности за минимум затрат.
Есть несколько способов померить качество ответов:
- Автоматические метрики (Bertscore, BLEURT, ROGE, и тд). На практике не применяются из-за крайне низкого качества оценки,
- Бинарный или фактологический датасет с закрытыми вопросами и однозначными ответами поверх которого можно посчитать F1 и другие классические DS-метрики,
- Human eval - человек вручную читает ответы и оценивает качество. Обычно самый точный из способов, но самый дорогой. Его не возможно прогонять eval на каждое улучшение,
- LLM as-a-judge и его разновидности,
- Автоматическая верификация результата. Отлично работает для задач программирования или математики, где можно автоматически проверить полученный результат.
Как правило, нужен датасет эталонных вопросов-ответов (validation и test датасеты). Лучше всего составлять его частично вручную частично с использованием AI, но под очень пристальным контролем с валидацией каждой пары.
Самым частым способом оценки является LLM as-a-judge, потому что он дешевый в реализации, его можно прогонять вместе с тестами на каждое изменение и он относительно универсальный. Но как всегда есть нюанс. Нужно убедиться, что LLM дает такую же оценку качества системы как и человек. Для этого делают meta evaluation, когда человек делает оценку качества вручную и затем сравнивают с подходом LLM-as-a-judge.
Есть много библиотек для evaluation, из того что я пробовал: RAGAS, DeepEval, TrueLens. Но в итоге написать собственную обвязку оказалось эффективнее.
Для менеджеров важным инсайтом будет, что пропорция времязатрат на разработку и eval, такая же как у разработки и тестирования. В среднем “по больнице” 3 к 1. Но если вы делаете высокорисковое приложение, на тестирование которого уходит почти столько же времени сколько на разработку, то и для evaluation приложения в этом домене нужно ожидать сопоставимое количество трудозатрат.
@max_about_ai
