Архитектура RAG: однопроходный поиск, ИИ-агенты или GraphRAG?
Автоматический перевод Эта статья была автоматически переведена с оригинальной английской версии.
Начните с одного прохода retrieval, который передаёт модели релевантные фрагменты источников. Добавляйте итеративный поиск, если для ответа нужен второй запрос, зависящий от результата первого. Тестируйте GraphRAG, когда для ответа нужны связи между сущностями или представление всей коллекции, которых не даёт обычный retrieval по фрагментам.
Это варианты сбора доказательств, а не стадии, через которые должна пройти каждая RAG-система. Сначала я бы изучил вопросы, на которых система ошиблась, и фрагменты, фактически полученные моделью. Дополнительный поиск не исправит текст, отброшенный парсером документов.
Последняя проверка: 2026-09-08.
Сопоставляйте поиск с вопросом
| Формулировка вопроса | Первый подход для тестирования | Какая дополнительная работа нужна |
|---|---|---|
| «Какая команда сброса настроек у этого устройства?» | Один проход retrieval, затем ответ с указанием источника | Релевантный фрагмент должен попасть в модель, генерирующую ответ |
| «Какая замена подходит для детали, указанной в этом отчёте?» | Итеративный поиск: найти деталь, затем отправить запрос в каталог деталей | Больше вызовов, правило остановки и тесты обоих поисковых шагов |
| «Какие темы повторяются в этих отчётах?» | Глобальный поиск GraphRAG в сравнении с более простым подходом на основе саммари | Построение и обновление саммари, производных от графа |
| «Как связаны эти поставщики?» | Retrieval с учётом графа в сравнении с повторным поиском по фрагментам | Корректные связи сущностей, отношения и подтверждение источниками |
В документации Microsoft по запросам GraphRAG локальный поиск по извлечённым сущностям и исходным чанкам отличают от глобального поиска по сгенерированным отчётам сообществ. Отчёт сообщества суммирует группу сущностей в извлечённом графе. Глобальный поиск использует эти отчёты для ответов на вопросы обо всей коллекции. Это не просто векторный lookup под новым названием.
Итеративный retrieval — отдельный архитектурный выбор, который может использовать обычный текстовый поиск. В работе Adaptive-RAG исследуется роутинг вопросов между отсутствием retrieval, одним шагом и несколькими шагами retrieval. Это позволяет тестировать разные пути, но не показывает, какой из них лучше работает на вашем корпусе.
Проверьте, каких доказательств не хватает, прежде чем менять архитектуру
Для каждого вопроса, на котором система ошиблась, сохраняйте ожидаемый источник и извлечённые чанки. Затем найдите, где произошла первая потеря:
- Если источник так и не попал в индекс, исправьте ingestion или парсинг.
- Если необязательный фильтр по теме исключил его, протестируйте фильтр или сохраните более широкий путь поиска. Фильтры доступа должны применяться на каждом пути.
- Если чанк был извлечён, но получил слишком низкий ранг, протестируйте изменения retrieval и реранкинга.
- Если нужное имя встречается только в первом результате, протестируйте второй lookup с использованием этого имени.
- Если модель получила достаточно доказательств, но ответила неправильно, изучите шаг генерации ответа, прежде чем добавлять retrieval.
Ответ про search stack рассматривает BM25, эмбеддинги и реранкеры в рамках одного retrieval-прохода. Эти компоненты можно использовать и в итеративной системе, но они не определяют, сколько поисковых запросов должна выполнить система.
Пусть более сложная архитектура оправдает свою стоимость
Сравнивайте пути на одних и тех же вопросах и разрешённых документах. Задайте для каждого явный бюджет по времени и числу вызовов модели. Измеряйте, нашла ли система необходимые подтверждения, правильно ли ответила и привела ли фрагменты, подтверждающие её утверждения. Таймауты и исчерпанный бюджет поиска также учитывайте как ошибки.
Для графа проверяйте не только итоговые ответы, но и извлечённые сущности и связи. Неверная связь с поставщиком может привести к связному ответу не о той компании. Учитывайте в сравнении стоимость построения и обновления индекса: одна лишь стоимость запроса не отражает эту работу.
Если однопроходный retrieval достигает целевого показателя, остановитесь на нём. Добавляйте другой путь только для тех типов вопросов, где измеренная ошибка даёт ему конкретную задачу.
Дополнительные материалы
- Метрики оценки RAG помогают локализовать потерю подтверждений на этапах парсинга, фильтрации, retrieval и генерации.
- Практическое руководство по LLM-инжинирингу описывает пайплайны ingestion и запросов и знакомит с GraphRAG.
- Enterprise RAG Challenge 3 рассматривает публичные записи, роутинг, подтверждения и их ограничения.