RAG, поиск и LongContext: когда сложные пайплайны избыточны

Что изменилось в подходах к интеграции знаний в LLM

В 2023 году Retrieval‑Augmented Generation (RAG) был почти единственным способом «засунуть» внешние знания в большие языковые модели. Ограничения контекстных окон (до 8 KB) и частые галлюцинации заставляли разработчиков строить тяжёлый пайплайн: разбиение текста (чанкинг), векторные эмбеддинги, построение векторных баз и отдельный реранкер для поиска релевантных фрагментов.

С тех пор контекстные окна моделей выросли в разы – GPT‑4‑Turbo, Claude 3.5, Gemini 1.5 и другие поддерживают до 100 KB и более. Это открыло возможность LongContext‑подходов, когда большая часть документации может быть передана в запросе без предварительного индекса.

Почему RAG всё ещё популярен

• Гибкость – позволяет работать с любыми источниками без переобучения модели.
• Точность – поиск по векторной базе часто даёт более релевантные отрывки, чем простое скольжение окна.
• Экономия токенов – при большом объёме данных отправка только нужных фрагментов снижает стоимость запросов.

Цена сложного пайплайна

• Время разработки – от двух до трёх месяцев для построения полной инфраструктуры (чанкинг, эмбеддинги, векторная БД, реранкер).
• Поддержка – требуется мониторинг индексов, обновление эмбеддингов и масштабирование сервисов.
• Технический долг – каждый компонент добавляет точку отказа и усложняет отладку.

Когда проще использовать LongContext

1. Ограниченный объём документации (до 50 KB) – её можно загрузить полностью в запрос.
2. Новые модели с расширенными окнами – позволяют хранить контекст без потери качества.
3. Быстрый прототип – без необходимости развёртывать векторные сервисы.

Компромиссный подход

Для крупных баз знаний всё ещё имеет смысл держать RAG‑pipeline, но автор советует гибрид: использовать LongContext для небольших справочных материалов и переключаться на RAG только при росте объёма или необходимости высокой точности поиска.

Читать оригинальную статью на Habr AI