RAG Is Simpler Than You Think

Большинство команд переусложняют RAG-системы, сразу внедряя эмбеддинги и векторные БД, хотя пользователи часто ищут простые документы вроде «Как сбросить пароль». Автор предлагает пошаговый подход: начинать с простых решений и переходить к сложным только при доказательстве необходимости. Ключевые факторы выбора архитектуры — свежесть данных, характеристики корпуса, паттерны запросов, нагрузка и компетенции команды.

Для большинства случаев (60%) достаточно полнотекстового поиска (BM25, Elasticsearch, Postgres) с переформулировкой запросов через LLM — это дешево, быстро (<50 мс), не требует чанкинга и легко отлаживается. Если нужно лучшее семантическое понимание, добавляют гибридный поиск: on-the-fly эмбеддинги для часто меняющихся данных (200–500 мс задержка), hot/cold tiers для средней нагрузки (50–100 мс) или полное предварительное эмбеддинги для стабильного корпуса и высокой нагрузки (<50 мс, но сложно в поддержке). Только 10% систем требуют полного предварительного эмбеддинга, а 5% — кастомных решений. Главное — не строить сложную систему для простой задачи.

Комментарии (199)

Обсуждение подтверждает, что полнотекстовый поиск (FTS) и BM25 чаще всего достаточны для RAG, а векторные эмбеддинги и векторные БД добавляют сложность, стоимость и операционную нагрузку без значимого прироста качества в большинстве реальных сценариев. FTS прост, портативен, масштабируем и решает 80% задач. Эмбеддинги требуют постоянной настройки, переэмбеддинга и сопровождения, не давая ожидаемого преимущества. BM25 — надёжный старт для RAG; эмбеддинги стоит добавлять только когда ключевой поиск действительно не справляется. Операционная нагрузка от векторных БД (обновление, хранение, реранкинг) часто превышает выгоды, особенно для небольших или внутренних корпусов. При этом размер чанков важнее выбора модели поиска — неправильный чанк сводит на нет преимущества любого подхода. Многие RAG-системы работают лучше без ретривала: когда ретривал-патч возвращал нулевые результаты, пользователи этого не замечали. **Практические советы:** - Для простого RAG с PostgreSQL — plpgsql_bm25, открытая реализация BM25 на PL/pgSQL без внешних зависимостей. - При отсутствии больших корпусов — эмбеддить всё сразу, суммировать и очищать текст дешёвой моделью, затем хранить в BigQuery, который нативно поддерживает векторный поиск. - Агенты для итеративного переформулирования запросов к Lucene/FTS дают эффект, близкий к эмбеддингам, но без неопределённости. - Для локального RAG с клиентскими моделями — Qdrant и Mem0 (обновление в реальном времени, без облака). - Сначала оценить паттерны запросов: если пользователи не знают точных ключевых слов, эмбеддинги могут быть оправданы, иначе — FTS. - Агенты с простыми инструментами автоматически усиливают усилия для сложных вопросов и минимизируют их для простых, снижая общую сложность. **Спор:** - Часть участников считает, что 90% документальных RAG-проектов должны использовать семантический поиск как основной метод — он прост и эффективен. - Другие возражают: эмбеддинги добавляют неопределённость на неопределённость (LLM + семантический поиск), тогда как лексический поиск предсказуем и надёжен. Большинство современных RAG-систем на деле — это FTS с переформулированием и реранкингом, а не настоящий семантический поиск. Сложность RAG-архитектур часто неоправданна.