RAG-системы ломаются на реальных данных: виновник — retrieval, не модель

RAG-пайплайн выглядит как магия: загрузил документы, нарезал на чанки, сгенерировал эмбеддинги, подключил векторную БД. Задал вопрос — модель отвечает уверенно и подробно. Показал заказчику, тот в восторге. Но потом начинается реальное тестирование на настоящих вопросах, и оказывается, что система отвечает мимо на половину из них.

Узкое место RAG На реальных вопросах система часто отвечает неправильно.

То находит не тот документ совсем, то находит правильный документ, но извлекает не тот кусок текста, то вообще ничего релевантного не достаёт и модель уверенно галлюцинирует. Кажется, что проблема в модели. На самом деле виноват retrieval. GPT-4 и Claude отвечают отлично, если им дать правильный контекст. Если контекст неправильный — галлюцинация гарантирована, как бы хороша была модель. Модель отвечает ровно настолько хорошо, насколько хорош контекст, который ей подсунули. Проблема не в моделях. Проблема в retrieval — в том, как мы ищем релевантные куски документов из вашей базы. Это узкое место, через которое проходит весь RAG-пайплайн. Если retrieval дал модели неправильный контекст, всё остальное — потраченное время и деньги.

«Модель отвечает настолько хорошо, насколько хорош контекст, который

ей подсунули.»

Когда retrieval ломается Retrieval может ломаться по десяткам причин.

Вот самые частые: Нарезка на чанки слишком крупная или мелкая. Чанк из 512 слов может ловить соседний контекст вместо нужного куска. Вопрос про политику возвратов, чанк содержит описание таблицы размеров Эмбеддинги сгенерированы под англоязычные данные, а вопрос на русском.

Семантическое расстояние между вектором вопроса и векторами документов огромное, совпадений нет Вопрос переформулирован так, что вектор его эмбеддинга не совпадает с векторами в базе. Ищете «вернуть заказ», документы содержат «возврат товара» — разная семантика Релевантный документ найден 8-м из 10, а модели скормили только топ-5 результатов. Нужный контекст просто не попадает в окно видимости * Индекс заполнен дубликатами и шумом.

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

Цена retrieval Оптимизация retrieval — это не забава для энтузиастов.

Это настоящая рабочая задача: неделя или две, потраченные разработчиком на анализ, обнаружат, что система на 30-40% ниже, чем expected accuracy. Причина не в модели, а в том, что retrieval ищет неправильно. На реальных проектах это огромная потеря: потратили время на RAG, потратили деньги на инфраструктуру, а система не работает потому что вектора документов не совпадают с векторами вопросов.

Что это значит RAG работает только если retrieval работает.

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