RAG-агенты против чистых LLM: когда база знаний важнее модели

Возьмите вопрос «какая гарантия на модель X по нашему договору от марта 2024». Агент на чистой LLM — даже на топовой Claude или GPT — ответит красиво и уверенно, но с высокой вероятностью выдумает срок: договора он не видел, а обучение закончилось до его подписания. Агент с retrieval-augmented generation (RAG) сначала найдёт нужный пункт в вашем хранилище документов, вставит его в контекст и ответит цитатой. Разница не в интеллекте модели, а в том, откуда берутся факты.

Спор «умная модель против модели с поиском» упирается в деньги, задержку ответа и цену ошибки. Ниже — где границы каждого подхода и почему на проде почти всегда получается гибрид.

Что скрывается за словами

Чистый LLM-агент — это языковая модель плюс инструменты (вызов функций, код, браузер), которая рассуждает и действует, опираясь на то, что запомнила при обучении, и на то, что вы положили ей в промпт. Её знания заморожены на дате отсечки обучения (knowledge cutoff)¹.

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

Чистый LLM знает всё в среднем и ничего про вас конкретно. RAG знает ровно то, что вы ему дали, и умеет это процитировать.

Почему это не одно и то же, что «большой контекст»

Соблазн отказаться от RAG в пользу окна на 200 тысяч и больше токенов понятен: закинул все документы в промпт — и готово. Но у длинного контекста три расплаты. Во-первых, деньги: вы платите за каждый токен ввода при каждом запросе, а корпоративная база на миллионы токенов в промпт не влезет физически. Во-вторых, задержка растёт с длиной контекста. В-третьих, известный эффект lost in the middle: модель хуже находит факт, если он лежит в середине длинного контекста, а не в начале или конце. RAG подаёт модели десяток релевантных фрагментов вместо всей библиотеки — дешевле и точнее.

Где чистый LLM выигрывает

Не каждая задача требует поиска. Чистый агент уместен, когда:

• Знания общие и стабильные. Перевод, переписывание текста, генерация кода на популярном языке, объяснение известной концепции — здесь свежесть данных не критична.
• Задача — рассуждение, а не факты. Разложить проблему на шаги, спланировать действия, отревьюить логику — модель делает это на своих весах, внешние документы только мешают.
• Нет надёжного источника. Если у вас нет курируемой базы, RAG будет доставать мусор, и «уверенная галлюцинация» модели окажется не хуже «уверенной цитаты из плохого документа».
• Важна минимальная задержка и простота. Один вызов модели без раунда поиска — быстрее и дешевле в инфраструктуре.

Где без RAG нельзя

• Факты меняются или приватны. Внутренние регламенты, цены, договоры, тикеты поддержки, документация продукта — модель их не видела и видеть не могла.
• Нужна прослеживаемость. RAG возвращает не только ответ, но и ссылку на источник. Для поддержки, юристов, медицины и финансов это обязательное требование, а не приятный бонус.
• Цена ошибки высокая. Ответ с цитатой конкретного документа проверяем; ответ «из головы модели» — нет.
• База обновляется чаще, чем вы готовы дообучать модель. Переиндексировать документы в векторной базе — минуты. Fine-tuning модели под новые данные — дни, деньги и риск деградации.

Сравнение по параметрам

Почему на практике это гибрид

Противопоставление обманчиво: production-агент обычно решает сам, когда лезть в поиск. Retrieval оформляется как один из инструментов (tool), который агент вызывает, если понимает, что вопрос про конкретные данные. На вопрос «переведи этот абзац» агент не пойдёт в базу. На вопрос «что написано в нашем SLA про время реакции» — пойдёт.

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

Что ломает RAG чаще всего

RAG — не магия, и его качество упирается в поиск, а не в модель:

1. Плохое разбиение на фрагменты. Если документ порезан так, что смысловая единица разорвана между чанками, поиск найдёт половину ответа.
2. Только векторный поиск. Семантический поиск промахивается по точным терминам, артикулам, номерам. Гибрид с полнотекстовым поиском (BM25) обычно точнее.
3. Нет переранжирования. Первые результаты поиска не всегда самые релевантные; reranker² переупорядочивает их перед подачей в модель.
4. Устаревший индекс. RAG отвечает по тому, что в базе. Если документ обновили, а индекс — нет, ответ будет уверенно неверным.

Как выбрать под свою задачу

• Ответы строятся на общих знаниях, факты не критичны, нужна скорость — начните с чистого LLM-агента.
• Ответы про ваши данные, важна проверяемость, база живая — стройте RAG.
• Смешанный поток вопросов — делайте агента с retrieval как инструментом и правилом «нет данных — так и скажи».
• Прежде чем усложнять модель, проверьте качество поиска: 70% провалов RAG — это провалы retrieval, а не генерации.

¹ Knowledge cutoff — дата, после которой модель не видела новых данных при обучении; всё, что произошло позже, ей неизвестно, если не передать в промпте.

² Reranker — отдельная модель, которая переупорядочивает найденные фрагменты по релевантности к запросу перед тем, как отдать их генеративной модели.