TL;DR: GraphRAG выбирайте для глобальных вопросов по корпусу, entity-centric reasoning и сводок по всему архиву. Обычный RAG выбирайте для прямого поиска по чанкам с цитатами и минимальной операционной сложности. Если нужен живой бенчмарк на вашем датасете, сравнение надо повторять отдельно.
Редакционная пометка: ниже сравнение по официальным источникам и релизам на 2026-08-13; живой latency-бенчмарк мы не проводили.
Под обычным RAG здесь понимаем стандартный chunk-based retrieval baseline; в практической части это сопоставляется с текущими документами OpenAI File Search / Vector Stores. Если хотите сначала освежить термины, откройте карточки GraphRAG (графовый RAG) и RAG (Retrieval-Augmented Generation). Для выбора между retrieval-стеком и сменой подхода пригодится и RAG vs файн-тюнинг, а при сборке пайплайна — LangChain vs LlamaIndex.
- Выбирайте GraphRAG, если вопрос требует ответов по всему архиву, связей между сущностями и community summaries.
- Выбирайте обычный RAG, если нужен быстрый baseline с файлами, цитатами и понятным chunking.
- Оба не подходят, если вы хотите готовую фиксированную цену и SLA из этого пакета источников: их здесь нет.
Для шаблона: FAQPage и BreadcrumbList добавьте на стороне CMS.
| Критерий | GraphRAG | Обычный RAG |
|---|---|---|
| Версия / срез | v3.1.1, релиз от 2026-07-18 | Текущая документация File Search / Vector Stores на 2026-08-13 |
| Тариф | В источниках не зафиксирован; код открыт, но индексирование может быть дорогим | В источниках не зафиксирован; цену нужно смотреть в live pricing и считать по своей конфигурации |
| Дата проверки | 2026-08-13 | 2026-08-13 |
Дата последней перепроверки: 2026-08-13.
| Критерий | GraphRAG | Обычный RAG |
|---|---|---|
| Цена и лимиты | Открытый код, но репозиторий предупреждает о дорогом индексировании и о том, что это демонстрация, а не официально поддерживаемое Microsoft offering | Managed baseline с upload/vector stores; тарифа в пакете источников нет, зато путь проще и понятнее |
| Качество на глобальных вопросах | Сильнее: добавляет knowledge graph и community summaries, а query docs выделяют Local Search, Global Search и DRIFT | Слабее на корпусном синтезе: оригинальный RAG хорошо отвечает по документам, но хуже на глобальных вопросах по всему корпусу |
| Скорость и стабильность | Global Search resource intensive, а общий пайплайн тяжелее и требует prompt tuning | Обычно проще по цепочке: загрузка файлов, chunking, retrieval, cited answer |
| Русский язык | Отдельной RU-оптимизации в источниках нет; результат зависит от модели, корпуса и prompt tuning | То же самое; в источниках нет отдельной оценки русского качества |
| Приватность и данные | Контроль зависит от вашей инфраструктуры; formal privacy SLA в пакете источников не зафиксирован | Файлы загружаются в provider workflow, значит контроль частично на стороне сервиса |
| Интеграции и API | Модульный graph-based system, режимы Local / Global / DRIFT / Basic, но есть предупреждения о миграциях версий | Документированы upload files и vector stores; авто-chunking по умолчанию 800 / 400 tokens |
Цена и лимиты
В источниках нет зафиксированного тарифа ни для GraphRAG, ни для базового RAG-сценария на OpenAI File Search / Vector Stores. Это важно: сравнивать нужно не только стоимость вызова модели, но и цену индексации, хранения, повторной индексации и поддержки.
У GraphRAG есть открытый код, но репозиторий прямо предупреждает, что индексирование может быть дорогим, а сам проект описан как демонстрация, а не официально поддерживаемое Microsoft offering. У обычного RAG baseline путь короче: загрузили файлы, прикрепили их к vector store, получили cited passages. Практический вывод простой: если вы делаете MVP, старт обычно дешевле по усилиям у обычного RAG; если корпус большой и вопросы сложные, считайте стоимость графовой индексации заранее.
- GraphRAG имеет смысл, когда вы готовы платить вычислениями за более богатую структуру корпуса.
- Обычный RAG имеет смысл, когда вам важнее предсказуемый старт и простой пайплайн.
Качество на глобальных вопросах
Именно здесь GraphRAG получает своё преимущество. В paper отмечено, что стандартный RAG умеет отвечать по private or unseen document collections, но спотыкается на глобальных вопросах по всему корпусу. GraphRAG добавляет LLM-built knowledge graph и community summaries, а в query docs разделяет Local Search, Global Search, DRIFT и Basic Search.
Практически это означает: если вопрос не лежит в одном фрагменте, а требует связывать сущности, темы и общие выводы, GraphRAG лучше соответствует задаче. Global Search ищет community reports map-reduce-образно и поэтому нацелен на corpus-wide synthesis. Обычный RAG сильнее там, где вам нужен один точный фрагмент с цитатой.
Если вы сравниваете не маркетинговые обещания, а рабочие сценарии, ориентир такой: direct lookup — обычный RAG; corpus-wide reasoning — GraphRAG.
Скорость и стабильность
По скорости нельзя честно назвать универсального победителя: в источниках нет единого latency-бенчмарка. Но структура GraphRAG тяжелее. Local Search комбинирует AI-extracted knowledge-graph data и raw text chunks, DRIFT расширяет local search community information, а Global Search прямо отмечен как resource intensive.
Из этого следует не только более сложный query path, но и большая цена обслуживания. Repo советует prompt tuning, а changelog предупреждает о версиях с breaking changes и о необходимости migration notebook для major upgrades. Это не минус сам по себе, но это операционная реальность GraphRAG.
Обычный RAG обычно проще эксплуатировать, потому что его путь короче: upload → chunking → vector retrieval → cited answer. Для внутренних помощников и MVP это часто важнее, чем попытка выжать максимум из корпуса на старте.
Русский язык и доступность
Ни один из источников не даёт отдельной оценки качества на русском языке. Значит, вывод о русском зависит не от названия подхода, а от модели, корпуса и prompt tuning. GraphRAG репозиторий вообще рекомендует prompt tuning, а не обещает языковую специализацию.
По доступности у OpenAI file search / vector stores есть полезная оговорка: функция доступна во всех перечисленных регионах, но доступность моделей на уровне endpoint и region всё равно может различаться. Для GraphRAG таких региональных обещаний в пакете источников нет: это OSS-код, и доступность определяется вашим стеком развёртывания.
Практический совет для русскоязычной команды простой: соберите маленький тестовый набор на русском и проверьте не только корректность ответа, но и стабильность цитирования.
Приватность и работа с данными
Если для вас критичны данные, различие архитектур заметно. Обычный RAG в baseline OpenAI требует загрузки файлов в сервис и работы через vector stores; это удобно, но контроль над потоком данных частично у провайдера. GraphRAG в пакете источников описан как кодовый проект: formal privacy policy здесь не зафиксирована, зато вы можете строить пайплайн под свою инфраструктуру и свои правила хранения.
Original RAG paper отдельно подчёркивает мотивы provenance и knowledge updating: для знаний важно не только ответить, но и показать, откуда ответ взят и как обновляются внешние данные. Для практики это означает, что в обеих схемах нужно смотреть, где лежат чанки, кто имеет доступ к индексу и как вы храните источники ответа.
Если у вас регулируемые документы, это не тот критерий, который можно оставить на потом.
Интеграции и API
У GraphRAG surface сложнее, но и гибче: в документации есть Local Search, Global Search, DRIFT и Basic Search, а сам репозиторий советует пользоваться CLI init flow между minor-версиями и migration notebook при major upgrade. На 2026-08-13 последняя release в GitHub — v3.1.1 от 2026-07-18. Это полезно знать, если вы хотите встроить решение в production, а не только показать demo.
Обычный RAG в baseline OpenAI проще подключить к существующему assistant/response workflow: upload files, attach them to vector stores, retrieve cited passages. У vector stores также зафиксированы default chunking values 800 max_chunk_size_tokens и 400 overlap tokens для auto chunking. Это делает обычный RAG более предсказуемым стартом, особенно если вы уже работаете в OpenAI stack.
Ещё один полезный ориентир: у GraphRAG в документации есть Basic Search как rudimentary vector-RAG baseline. То есть сам проект признаёт, что у него есть базовая, обычная RAG-опора, а ценность GraphRAG раскрывается выше неё — в graph-слое и корпусной синтезирующей логике.
Практический тест
Оговорка: это не стендовый latency-бенчмарк и не скриншоты из живой системы. Ниже — один и тот же workflow, сопоставленный по официальным документам. Для практики этого достаточно, но для финального выбора нужен прогон на ваших данных.
Задача
Один и тот же запрос: «Соберите ответ по всему корпусу: какие сущности связаны между собой, где есть повторяющиеся темы и какой общий вывод можно сделать без потери источников?»
Результат GraphRAG
В GraphRAG этот workflow ложится на Local Search и Global Search. Local Search смешивает AI-extracted knowledge graph data и raw text chunks, а Global Search уходит в community reports map-reduce-образно. Для вопросов про связи и обзор по всему архиву это именно тот режим, который нацелен на synthesis, а не на единичный фрагмент.
Результат обычного RAG
В обычном RAG baseline вы загружаете файлы, прикрепляете их к vector store и получаете cited passages. При auto chunking размер чанков по умолчанию 800 max_chunk_size_tokens, overlap — 400 tokens. Это хорошо работает для прямого ответа по фрагменту, но само по себе не строит граф и хуже связывает несколько далёких друг от друга фактов.
Вывод
Для этого workflow GraphRAG сильнее по замыслу и по документированному набору режимов. Обычный RAG выигрывает, когда вопрос уже сузился до поиска одного-двух фрагментов и вам важнее простота, чем корпусная синтезирующая логика.
Кому подойдёт GraphRAG
- Если у вас большой корпус и вопросы про связи между сущностями, а не только про отдельные фрагменты.
- Если вам нужны summary-level выводы по всему архиву и вы готовы использовать graph-based pipeline.
- Если вы готовы принять более сложную индексацию, prompt tuning и миграции версий.
- Если для вас важнее качество на сложном корпусе, чем минимальный setup.
Кому подойдёт обычный RAG
- Если вам нужен быстрый baseline с цитатами из загруженных файлов.
- Если вопросы в основном прямые: найти, процитировать, коротко объяснить.
- Если вы хотите минимальную операционную сложность и понятный chunking.
- Если вы уже работаете в OpenAI workflow и не хотите строить graph pipeline.
Когда оба не подходят
- Если вы ждёте фиксированную цену из этого пакета источников — её здесь нет.
- Если вам нужен production SLA или жёстко измеренный benchmark именно на вашем корпусе — нужен отдельный пилот.
- Если вы выбираете только по названию подхода, без проверки качества на своих данных, решение будет слабым.
Итог
Для direct retrieval и быстрого старта берите обычный RAG. Для corpus-wide synthesis, multi-hop entity reasoning и community-level summaries берите GraphRAG. Абсолютного победителя здесь нет: GraphRAG сильнее на сложных корпусных вопросах, обычный RAG — на простоте, предсказуемости и более низком пороге входа.
Вопросы и ответы
Что быстрее?
Для прямого retrieval обычно обычный RAG проще и короче по цепочке. У GraphRAG Global Search resource intensive, а универсальной latency-метрики в источниках нет.
Что дешевле?
В источниках нет цены. Но GraphRAG предупреждает о дорогой индексации, а обычный RAG проще стартует; точную стоимость считайте отдельно по вашему стеку.
Можно ли использовать оба?
Да. На практике часто начинают с обычного RAG, а GraphRAG подключают, когда обычный поиск перестаёт справляться с корпусным синтезом и связями между сущностями.
Нужен ли GraphRAG для небольшого корпуса?
Обычно нет. Если вопрос укладывается в несколько чанков и нужен цитируемый ответ, обычный RAG проще и достаточнее.
Есть ли отдельная оптимизация под русский язык?
В источниках такой оптимизации нет. Ориентируйтесь на модель, корпус и свой тестовый набор.
Источники
- GitHub – microsoft/graphrag
- GraphRAG Query Overview
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
- Releases · microsoft/graphrag
- CHANGELOG.md · microsoft/graphrag
- Files – OpenAI API Reference
- Vector stores files – OpenAI API Reference
- Default usage policies by endpoint – OpenAI Docs
- Microsoft Research GraphRAG project
