Посібник з GraphRAG: коли графи знань перемагають vector RAG (а коли ні)

Посібник з GraphRAG: коли графи знань перемагають vector RAG (а коли ні)

GraphRAG не помер, але й не став стандартом. microsoft/graphrag випустив v3.1.1 2026-07-18, маючи 35 088 зірок на GitHub, а три бенчмарк-статті 2026 року тепер вголос констатують, що він часто програє звичайному векторному пошуку. Тож цей посібник з GraphRAG відповідає на єдине питання, що лишилося: чи вартий граф знань рахунку за індексацію?

Чи варто використовувати GraphRAG? Коротка відповідь

Використовуйте GraphRAG, коли ваші запитання перетинають сутності або охоплюють весь корпус, як-от «яким постачальникам також продає наш найбільший клієнт?». Для односкокових пошуків фактів, документів, що швидко змінюються, і жорстких бюджетів затримки залишайтеся на звичайному або гібридному RAG. Граф окуповується на багатоскокових запитаннях і коштує грошей всюди інде.

GraphRAG не помер і не є типовим вибором. Він відпрацьовує свій рахунок за індексацію, коли ваші запитання багатоскокові або глобальні для корпусу, і втрачає гроші, коли це не так.

Коротка версія:

• GraphRAG перемагає в багатоскокових і загальнокорпусних запитаннях; звичайний RAG перемагає в односкокових пошуках.
• Бенчмарки 2026 року суперечливі: графи допомагають агрегації, але можуть шкодити детальному підсумовуванню.
• Вартість виникає на етапі індексації, у викликах LLM для екстракції, а не під час запиту.
• Перш ніж щось будувати, запустіть Basic Search як контроль на власному корпусі.

Якщо у вас уже працює конвеєр vector RAG, єдине рішення полягає в тому, чи окупиться граф поверх нього. Таблиця нижче це вся аргументація у шести рядках, і там, де вона каже залишатися на звичайному RAG, це чесна відповідь, частіше, ніж визнають вендори. Гібридний пошук BM25 плюс вектори покриває більшість цих випадків узагалі без графа.

Що таке GraphRAG насправді: від фрагментів до спільнот

GraphRAG це генерація з доповненням через пошук (retrieval-augmented generation) над графом знань, а не над розрізненими фрагментами. На етапі індексації LLM витягує сутності та зв'язки з ваших документів, алгоритм Leiden групує ці сутності у спільноти, і кожна спільнота отримує підсумок. На етапі запиту граф плюс ці підсумки відповідають на запитання, на які вікно top_k над фрагментами структурно не здатне відповісти.

Конвеєр від початку до кінця:

Documents
  |
  v
Chunks --> LLM entity + relationship extraction
  |
  v
Knowledge graph (entities = nodes, relations = edges)
  |
  v
Leiden community detection --> community summaries
  |
  v
Vector index over entity + community descriptions

Дві фази виконують роботу. Фаза індексації дорога: кожен фрагмент коштує виклику LLM, щоб витягти сутності й зв'язки, а підсумки спільнот коштують додаткових викликів понад те. Віддача з'являється на фазі запиту. Оскільки граф зберігає зв'язки явно, запитання на кшталт «яким постачальникам також продає наш найбільший клієнт?» стає обходом графа, а не надією, що потрібні два фрагменти потраплять у те саме вікно top_k.

Підсумки важливі, бо саме їх читає Global Search: загальнокорпусні запитання отримують відповідь із заздалегідь написаного тексту спільнот, а не з сирих фрагментів. А кожне ребро є судженням LLM, збереженим як трійка, яку можна було б запитати мовою Cypher у справжній графовій базі даних. Ця сама конструкція пояснює, чому індексація домінує у вартості, що числа нижче роблять конкретним.

Формулювання, яке заслуговує на місце: звичайний RAG отримує уривки, а GraphRAG отримує структуру. Ваш вибір моделі ембедінгів досі важливий для векторного шару, а ваша векторна база даних досі зберігає описи, але граф це новий несучий елемент. Офіційна документація Index Overview описує кожен етап детально.

Які чотири методи запитів GraphRAG?

Рушій запитів GraphRAG постачає чотири методи: Local Search, Global Search, DRIFT Search і Basic Search. Local Search міркує від конкретних сутностей назовні, Global Search агрегує підсумки спільнот у всьому корпусі, DRIFT Search рекурсивно поєднує обидва, а Basic Search це звичайна векторна базова лінія. П'ята можливість, Question Generation, лежить поверх рушія, а не поруч із ним.

Ми перевірили чинну документацію на microsoft.github.io/graphrag/query/overview/ 2026-07-30, і їх чотири. Більшість рейтингових посібників називають два або три. Та сама перевірка виявила слово «lazy» нуль разів на обох оглядових сторінках Index і Query, що важливо для розділу про вартість нижче.

Рядок, вартий вашої уваги, останній. Basic Search це вбудована базова лінія на звичайних векторах, і вона існує, щоб ви могли A/B-тестувати граф проти звичайного пошуку на власному корпусі й дізнатися, чи граф відпрацьовує свій рахунок. Це не дрібниця; це вся процедура ухвалення рішення з цього посібника в одній можливості. Спершу запустіть Basic Search. Якщо Local, Global або DRIFT Search не перемагає його на запитаннях, які вам справді ставлять, граф це витрата, а не апгрейд.

Що насправді виявили бенчмарки 2026 року?

Три бенчмарк-статті 2026 року виявляють, що GraphRAG допомагає в багатоскокових завданнях і завданнях агрегації кількох фактів, але часто поступається звичайному RAG деінде. Одна з них будує бенчмарк спеціально, щоб знайти, де графи програють. Усі три погоджуються, що виграш залежить від типу запитання, а не від розміру корпусу. Докази кажуть, що GraphRAG ситуативний, а не типовий.

Четверта робота, GraphRAG-Bench (репозиторій), оцінює дев'ять методів GraphRAG у 16 дисциплінах і 20 підручниках і сягає того самого висновку з ширшого кута.

Усі три статті сходяться в одному: граф відпрацьовує свою вартість на багатоскоковій агрегації й втрачає її на детальній повноті видачі.

Наше прочитання: цикл хайпу завдав шкоди, а ці статті є виправленням. Жодна з них не каже, що графи марні. Що вони кажуть послідовно, то це те, що крок агрегації, який робить GraphRAG добрим у темах усього корпусу, є тим самим кроком, що розмиває дрібні деталі. WildGraphBench найчіткіший приклад: графи допомогли агрегації кількох фактів із помірної кількості джерел і зашкодили точності підсумовування в тій самій оцінці. Це не суперечність; це один механізм, що виявляється двічі.

Практичний наслідок: ви не можете ухвалити це рішення лише з літератури. Статті кажуть, які типи запитань тестувати, а не чи ваш корпус є одним із них. Саме для цього існує контроль Basic Search із розділу про методи вище.

Скільки коштує GraphRAG? (І застереження про LazyGraphRAG, яке всі повторюють неправильно)

Вартість GraphRAG це рахунок на етапі індексації, а не на етапі запиту, і саме тому він застає зненацька. Виклики LLM, що витягують сутності й зв'язки з кожного фрагмента, плюс прохід підсумовування спільнот ось що робить його дорогим. Ви платите наперед, ще до першого запиту. Час запиту дешевший, але не безкоштовний: Global Search розгортається по підсумках спільнот із викликом LLM на кожну спільноту, тому таблиця методів вище позначає його як високий.

Єдині тверді публічні цифри походять від Microsoft Research. 2024-11-25 команда повідомила, що вартість індексації LazyGraphRAG була ідентична до vector RAG і становила 0,1% вартості повного GraphRAG, і що при 4% вартості запиту глобального пошуку GraphRAG він перевершив протестовані конкуруючі методи на обох типах запитів, локальному й глобальному (Microsoft Research). Це цифри Microsoft, з блогу Microsoft, і ми наводимо їх як такі; власного проіндексованого за ціною прогону ми не робили.

Ось виправлення, яке більшість оглядів пропускає. LazyGraphRAG не є опцією pip install. Згідно з власною приміткою редактора Microsoft від 2025-06-06, він увійшов до Microsoft Discovery та Azure Local, а не в пакет з відкритим кодом. Ми перевірили офіційні сторінки Index Overview і Query Overview 2026-07-30: слово «lazy» з'являється нуль разів на обох. Тож якщо посібник подає LazyGraphRAG як варіант, який можна розгорнути сьогодні вдень, він повторює твердження, що перестало бути правдою у світі відкритого коду.

Що можна зробити сьогодні: запустити модель екстракції локально. Спрямування кроку індексації на локальну модель через Ollama прибирає плату за токени з найдорожчої фази, а поєднання з векторним сховищем власного хостингу тримає решту рахунку біля нуля.

Яка бібліотека GraphRAG насправді підтримується?

Дві з шести найцитованіших бібліотек GraphRAG не мали пушів шість і дев'ять місяців. Ми взяли ці цифри з GitHub API 2026-07-30, і перепис нижче це перевірка, яку старіші огляди пропускають, разом із командою, щоб повторити її, перш ніж зупинитися на якійсь. LightRAG і microsoft/graphrag активні; nano-graphrag і fast-graphrag дрейфують до закинутого ПЗ.

for r in HKUDS/LightRAG microsoft/graphrag getzep/graphiti neo4j/neo4j-graphrag-python gusye1234/nano-graphrag circlemind-ai/fast-graphrag; do gh api "repos/$r" --jq '.full_name,.stargazers_count,.pushed_at,.open_issues_count'; done

Наше прочитання: зірки це метрика марнославства; дата пушу ось число, що має значення. LightRAG і microsoft/graphrag обидві активно підтримуються, Graphiti поруч із темпорально-графовим кутом. nano-graphrag і fast-graphrag ось ті дві, які старіші пости досі радять лише за репутацією, і жодна не випускала релізів пів року.

Як обрати: microsoft/graphrag, якщо хочете еталонну реалізацію з чотирма офіційними методами запитів; LightRAG, якщо хочете найактивніший проєкт і легший слід; бібліотеку від вендора, як-от neo4j-graphrag-python, якщо вже використовуєте базу даних цього вендора. Уникайте будь-чого, чий останній пуш передує вашому проєкту на пів року.

Graphiti заслуговує на одну прицільну нотатку: його дизайн темпорального графа створено для пошуку над даними з урахуванням часу, і він перетинається з пам'яттю агентів, яку ми розбираємо окремо в посібнику з Graphiti та темпоральної графової пам'яті. Для ширшого поля дивіться ширший ландшафт інструментів RAG.

Що ламається після дня 200: дрейф графа й повторна екстракція

Дрейф графа це податок, який ви платите після запуску, і це закономірно застереження номер один від практиків. Кожен туторіал поводиться з графом як із чимось, що будується раз. Реальні команди застрягають на день 200.

Три речі деградують. Перша: переіндексація при оновленнях документів. Коли змінюються 40 документів, ви не можете просто пере-ембедити їх; вам треба повторно запустити екстракцію LLM на змінених фрагментах, узгодити нові сутності зі старим графом і переобчислити уражені спільноти та їхні підсумки. Один посібник на Medium називає інкрементне оновлення легким. Практики на r/Rag не згодні. Автор гілки від 2026-04-25, що ганяє BM25 плюс BGE-M3 на приблизно 600 документах, каже прямо: «Екстракція сутностей/зв'язків на базі LLM шумна, і переіндексація при оновленнях документів виглядає боляче».

Друга: деградація розв'язання сутностей. «Acme Corp», «Acme» і «ACME Corporation» приходять у різних документах із різницею в місяці й розщеплюються на три вузли, що мали б бути одним. Ніщо не об'єднує їх автоматично.

Третя: зв'язки, що були правдиві на момент екстракції й тихо перестали бути правдивими. Ніхто не отримує сповіщення, коли ребро reports_to застаріває.

def on_documents_changed(changed_docs):
    stale = find_affected_nodes(changed_docs)
    re_extract(changed_docs)
    reconcile_entities(stale)
    recompute_communities(affected_only=True)
    re_summarize(affected_communities)

Кодова база це найгірший і водночас найцікавіший випадок. Автопідказки пошуку тепер показують «graphrag for codebase», «graphrag claude code» і «graphrag mcp server», а кодова база є графом, що змінюється щогодини: кожен коміт переписує ребра викликів, переміщує символи й видаляє функції. Це дрейф графа за розкладом, який жодна нічна переіндексація не відстежить повністю. Це також причина, чому серйозні інструменти кодових графів спираються на детерміновані парсери, як-от tree-sitter і LSP, для ребер і залишають LLM прозу навколо них: docstrings, повідомлення комітів, гілки ревью. Якщо ви будуєте граф репозиторію, будуйте граф повільного шару через LLM, а швидкого через парсер.

Що насправді кажуть розробники про GraphRAG?

Працюючі розробники розділені, і Google, здається, це знає: гілка Reddit посідає другу позицію за запитом «graphrag vs rag», і це пошукова система каже вам, що тема хоче думки колег, а не тексту вендорів.

Скепсис реальний. У гілці r/Rag 2024 року «Would you always recommend (knowledge) graph RAG over normal RAG?» (10 балів, 86% схвалення) u/EncartaIt написав: «Усі туторіали, що я знаходив, надмірно спрощені й не дають переконливого кейсу для патерну з графом знань». u/Prestigious_Run_4049 був різкіший: «Я думаю, graph rag це просто хайп. Люди люблять говорити про нього, і це звучить круто, але ніхто насправді не використовує його в реальних кейсах». Не всі згодні. u/pytheryx, аргументуючи з продакшену, зауважив, що графовий пошук виграє на запитаннях типу списків, що потребують контексту з більшої кількості фрагментів, ніж повертає top_k; його корпус технічних документів потребує близько 50 фрагментів для повної відповіді.

Гілка 2026 року виваженіша. u/Popular_Sand2773: «Більшість сетапів graph rag просто шахраюють на масштабі. Ви робите стандартний векторний пошук або пошук за метаданими, щоб знайти початкові вузли, а тоді гуляєте графом». u/ggone20, що тримає систему на приблизно 300 мільйонів артефактів: «На масштабі ви буквально не можете жити без них, щоб відповідати на реальні запитання».

Наше прочитання збігається з найгострішим аргументом в обох гілках: переломна точка це складність ваших запитань, а не розмір вашого корпусу. Це також те, що виявили бенчмарки вище, тому ми на боці практиків, які обмежують інструмент багатоскоковою роботою, а не тих, хто називає його мертвим.

Як Techsy підходить до цього

Ось послідовність, яку ми використовуємо на клієнтських проєктах, і вона навмисно нудна.

Перше: доведіть стелю гібридного пошуку. Більшість запитів «нам потрібен граф», які ми чуємо, насправді є замаскованою проблемою нарізки на фрагменти або ранжування. Конвеєр BM25 плюс вектори з пристойним ранжувальником відповідає на більше, ніж команди очікують.

Друге: запустіть Basic Search як контроль на власному корпусі, перш ніж щось будувати. Саме для цього існує четвертий метод запитів: базова лінія на звичайних векторах, з якою ви можете A/B-тестувати граф на ваших даних, з вашими запитаннями.

Третє: будуйте граф лише тоді, коли виміряний клас запитань не проходить цей контроль. Якщо багатоскокові або загальнокорпусні запити хибують, у вас є реальний кейс. Якщо ні, ви щойно заощадили собі рахунок за індексацію й проблему дрейфу.

Хочете другу пару очей на ваш пошуковий стек? Отримайте безплатну консультацію.

Про автора

Мерт Батур співзасновник Techsy.io, де команда відвантажує AI-агентів, системи автоматизації та голосові/SDR-конвеєри для B2B-клієнтів. Він пише про стек інструментів LLM, який команда Techsy насправді використовує в продакшені. На клієнтських проєктах він ухвалює рішення щодо архітектури пошуку: коли гібридного пошуку достатньо, а коли корпус насправді потребує графа. Зв'яжіться з ним у LinkedIn.

Часті запитання

Як працює GraphRAG?

GraphRAG індексує ваші документи в граф знань. LLM витягує сутності й зв'язки з кожного фрагмента, алгоритм Leiden кластеризує ці сутності у спільноти, і кожна спільнота отримує підсумок. На етапі запиту рушій шукає в графі та цих підсумках, тож може з'єднувати факти, що лежать у різних фрагментах.

Чим GraphRAG відрізняється від RAG?

Стандартний RAG отримує top-k найсхожіших фрагментів і подає їх моделі. GraphRAG отримує структуру: сутності, зв'язки між ними та заздалегідь написані підсумки спільнот. Ця додаткова структура те, що дає змогу відповідати на багатоскокові й загальнокорпусні запитання, і вона ж робить індексацію повільнішою й дорожчою.

Коли варто використовувати GraphRAG?

Використовуйте, коли ваші запитання перетинають сутності або охоплюють весь корпус, як-от запитання про перетин постачальників чи аналіз повторюваних тем на тисячах документів. Пропустіть для односкокових пошуків фактів, корпусів, що швидко змінюються, і жорстких бюджетів затримки чи вартості. Якщо звичайний гібридний конвеєр уже відповідає на клас запитань, граф додає вартість, не додаючи цінності.

GraphRAG помер?

Ні, але й не є типовим вибором. Бенчмарки 2026 року показують, що він часто поступається звичайному RAG на повсякденних завданнях, що вбило хайп, водночас досі виграючи на багатоскокових запитаннях і агрегації. Чесне формулювання ситуативне: GraphRAG відпрацьовує свою вартість для правильних типів запитань і втрачає гроші на решті.

Які методи запитів GraphRAG?

Офіційний рушій запитів постачає чотири: Local Search для запитань навколо сутностей, Global Search для агрегації всього корпусу, DRIFT Search для рекурсивного поєднання обох і Basic Search для звичайного векторного пошуку. П'ята можливість, Question Generation, лежить поверх. Basic Search найважливіший: це контроль, з яким ви A/B-тестуєте граф.

Скільки коштує індексація GraphRAG?

Вартість припадає на етап індексації, на виклики LLM, що витягують сутності й зв'язки з кожного фрагмента, плюс підсумовування спільнот. Microsoft Research повідомила, що індексація LazyGraphRAG коштує 0,1% вартості повного GraphRAG і ідентична до vector RAG, але цей варіант увійшов у продукти Microsoft, а не в бібліотеку з відкритим кодом. Власного проіндексованого за ціною прогону ми не робили.

Чи можна запустити GraphRAG локально з Ollama?

Так. Бібліотека microsoft/graphrag дає змогу спрямувати індексацію й запити на локальну модель, яку обслуговує Ollama, що прибирає плату за токени з кроку екстракції. Ви міняєте швидкість і якість на вартість: локальні моделі слабші в екстракції сутностей, тож очікуйте шумніших графів і довших прогонів індексації на помірному залізі.

Що краще: LightRAG чи Microsoft GraphRAG?

Вони оптимізують різне. LightRAG (38 353 зірки, пуш 2026-07-30) найактивніша й легша в запуску; microsoft/graphrag (35 088 зірок, v3.1.1) еталонна реалізація з чотирма офіційними методами запитів. Оберіть LightRAG для ефективного продакшн-графа, Microsoft для поведінки за специфікацією й контролю Basic Search.

Хто створив GraphRAG і коли?

GraphRAG створила Microsoft Research. Команда опублікувала статтю 2024 року й підтримує репозиторій з відкритим кодом microsoft/graphrag під ліцензією MIT, з документацією на microsoft.github.io/graphrag. Еталонна бібліотека досягла v3.1.1 2026-07-18, і навколо неї виросла активна екосистема сторонніх реалізацій, зокрема LightRAG і Graphiti.

Вердикт: коли граф відпрацьовує свою вартість

Докази вказують в один бік, тож ось позиція.

• GraphRAG не помер. Він ситуативний, і бенчмарки 2026 року кажуть це вголос.
• Він відпрацьовує свій рахунок за індексацію на багатоскокових запитаннях про сутності й агрегації всього корпусу. Він втрачає гроші на односкокових пошуках.
• Вартість це рахунок на етапі індексації, а дешевий варіант, який усі цитують, LazyGraphRAG, так і не дійшов до бібліотеки з відкритим кодом.
• Граф деградує після запуску: розв'язання сутностей дрейфує, а зв'язки застарівають, тож закладайте бюджет на переіндексацію.
• Запустіть Basic Search як контроль на власному корпусі, перш ніж щось будувати.

Одне речення: граф знань відпрацьовує свою вартість, коли ваші запитання багатоскокові або глобальні для корпусу, і не раніше. Якщо хочете другу думку щодо вашого пошукового стека, отримайте безплатну консультацію.