دليل GraphRAG: متى تتفوق الرسوم البيانية المعرفية على RAG المتجهي (ومتى لا تتفوق)

دليل GraphRAG: متى تتفوق الرسوم البيانية المعرفية على 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 كمعيار ضبط على مجموعة مستنداتك قبل أن تبني أي شيء.

إذا كنت تشغّل بالفعل خط أنابيب RAG متجهي يعمل فعلياً، فالقرار الوحيد المتبقي هو ما إذا كان الرسم البياني فوقه يستحق عناءه. الجدول أدناه يلخص الحجة كاملة في ستة صفوف، وحيث يقول لك ابقَ على RAG التقليدي، فهذه هي الإجابة الصادقة، في أحيان أكثر مما يعترف به البائعون. فـالبحث الهجين BM25 مع المتجهات يغطي معظم هذه الحالات دون رسم بياني من الأساس.

ما هو GraphRAG فعلياً: من المقاطع إلى المجتمعات

GraphRAG هو توليد معزز بالاسترجاع فوق رسم بياني معرفي بدلاً من مقاطع منفصلة عن بعضها. عند الفهرسة، يستخرج نموذج 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 هو خط الأساس المتجهي المدمج، وموجود لتقارن الرسم البياني بالاسترجاع العادي على مجموعة مستنداتك أنت، وتكتشف ما إذا كان الرسم البياني يبرر فاتورته. هذه ليست تفصيلة هامشية؛ فهذا هو منهج القرار الكامل لهذا الدليل في ميزة واحدة. شغّل Basic Search أولاً. إذا لم يتفوق عليه Local أو Global أو DRIFT في الأسئلة التي تُطرح عليك فعلاً، فالرسم البياني تكلفة، لا ترقية.

ماذا وجدت الاختبارات المعيارية لعام 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 كانت مطابقة لتكلفة RAG المتجهي وتعادل 0.1% من تكلفة GraphRAG الكامل، وأنه بـ 4% فقط من تكلفة استعلام GraphRAG global search تفوق على الطرق المنافسة المختبَرة، في نوعي الاستعلام المحلي والشامل (Microsoft Research). هذه أرقام Microsoft، من مدونة Microsoft، وننقلها على هذا الأساس؛ فنحن لم نشغّل فهرسة مسعّرة خاصة بنا.

وهذا هو التصحيح الذي تفوّته معظم المقالات. LazyGraphRAG ليس خياراً تثبّته عبر pip. وفقاً لملاحظة محرر Microsoft نفسها بتاريخ 2025-06-06، فقد صدر داخل Microsoft Discovery وAzure Local، لا داخل الحزمة مفتوحة المصدر. وتحققنا من صفحتي Index Overview وQuery Overview الرسميتين في 2026-07-30: كلمة «lazy» تظهر صفراً من المرات في كلتيهما. لذلك إذا أدرج دليل ما LazyGraphRAG كتنويع يمكنك تشغيله بعد ظهر اليوم، فهو يكرر ادعاءً لم يعد صحيحاً في العالم مفتوح المصدر.

ما يمكنك فعله اليوم: تشغيل نموذج الاستخراج محلياً. توجيه خطوة الفهرسة نحو نموذج محلي عبر Ollama يزيل رسوم API لكل رمز من المرحلة الأغلى، ودمجه مع مخزن متجهات ذاتي الاستضافة يبقي بقية الفاتورة قريباً من الصفر.

أي مكتبة GraphRAG لا تزال قيد الصيانة فعلاً؟

مكتبتان من أكثر ست مكتبات GraphRAG استشهاداً بها لم تستقبلا أي push منذ ستة وتسعة أشهر. سحبنا هذه الأرقام من 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

قراءتنا: النجوم مقياس زائف؛ تاريخ آخر push هو الرقم الذي يهم. LightRAG وmicrosoft/graphrag كلتاهما تصان بنشاط، وGraphiti قريبة خلفهما بزاوية الرسم البياني الزمني. أما nano-graphrag وfast-graphrag فهما المكتبتان اللتان لا تزال المقالات الأقدم توصي بهما بناءً على السمعة وحدها، ولم تصدر أي منهما تحديثاً منذ نصف عام.

كيف تختار: اختر microsoft/graphrag إذا كنت تريد التنفيذ المرجعي بطرق الاستعلام الأربع الرسمية، وLightRAG إذا كنت تريد المشروع الأنشط وبصمة أخف، ومكتبة تصونها الشركة المطورة مثل neo4j-graphrag-python إذا كنت تشغّل قاعدة بيانات تلك الشركة أصلاً. وتجنب أي مكتبة يسبق آخر push فيها مشروعك بنصف عام.

Graphiti تستحق ملاحظة واحدة محددة النطاق: تصميمها القائم على الرسم البياني الزمني مبني للاسترجاع فوق البيانات الحساسة للزمن، وهي تتقاطع مع ذاكرة الوكلاء التي نغطيها منفصلة في دليلنا عن Graphiti وذاكرة الرسم البياني الزمني. وللمشهد الأوسع، راجع مشهد أدوات RAG الأوسع.

ماذا ينكسر بعد اليوم 200: انحراف الرسم البياني وإعادة الاستخراج

انحراف الرسم البياني (Graph drift) هو الضريبة التي تدفعها بعد الإطلاق، وهو اعتراض الممارسين الأول لسبب وجيه. كل درس تعليمي يتعامل مع الرسم البياني كشيء تبنيه مرة واحدة. الفرق الحقيقية تعلق في اليوم 200.

ثلاثة أشياء تتآكل. أولاً، إعادة الفهرسة عند تحديث المستندات. عندما يتغير 40 مستنداً، لا يمكنك الاكتفاء بإعادة تضمينها؛ بل عليك إعادة تشغيل استخراج LLM على المقاطع المتغيرة، ومواءمة الكيانات الجديدة مع الرسم البياني القديم، وإعادة حساب المجتمعات المتأثرة وملخصاتها. أحد أدلة Medium يصف التحديث التدريجي بالسهل. ممارسو r/Rag يخالفونه الرأي. صاحب نقاش بتاريخ 2026-04-25 يشغّل BM25 مع BGE-M3 على نحو 600 مستند قالها بوضوح: «استخراج الكيانات/العلاقات القائم على LLM مليء بالضجيج، وإعادة الفهرسة عند تحديث المستندات تبدو مؤلمة.»

ثانياً، تآكل توحيد الكيانات (entity resolution). «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»، وقاعدة الكود رسم بياني يتغير كل ساعة: كل commit يعيد كتابة حواف الاستدعاء، وينقل الرموز، ويحذف دوال. هذا انحراف رسم بياني بجدول زمني لا تستطيع أي إعادة فهرسة ليلية متابعته بالكامل. ولهذا أيضاً تعتمد أدوات رسوم الكود الجادة على محللات حتمية مثل tree-sitter وLSP للحواف، وتُبقي LLM للنصوص المحيطة بها: سلاسل التوثيق ورسائل الـ commit ونقاشات المراجعة. إذا كنت تبني رسماً بيانياً لمستودع، فارسم الطبقة بطيئة التغير بالـ LLM والطبقة سريعة التغير بمحلل.

ماذا يقول المطورون فعلاً عن GraphRAG؟

المطورون العاملون منقسمون، ويبدو أن Google تعرف ذلك: نقاش على Reddit يحتل المرتبة الثانية عن «graphrag vs rag»، وهذه طريقة محرك البحث في إخبارك أن هذا الموضوع يريد رأي الأقران، لا نصوص البائعين.

التشكيك حقيقي. في نقاش r/Rag لعام 2024 بعنوان «هل توصون دائماً بـ RAG الرسم البياني (المعرفي) على 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 كمعيار ضبط على مجموعة مستنداتك قبل أن تبني أي شيء. هذا تحديداً الغرض من طريقة الاستعلام الرابعة: خط أساس متجهي عادي تقارن به الرسم البياني، على بياناتك أنت، وبأسئلتك أنت.

ثالثاً، لا تبنِ الرسم البياني إلا عندما تفشل فئة مقاسة من الأسئلة في اجتياز معيار الضبط هذا. إذا أخفقت الاستعلامات متعددة القفزات أو الشاملة للمدونة، فلديك حالة حقيقية. وإذا لم تخفق، فقد وفّرت على نفسك للتو فاتورة فهرسة ومشكلة انحراف.

تريد رأياً ثانياً في حزمة الاسترجاع لديك؟ احصل على استشارة مجانية.

عن الكاتب

مرت باتور (Mert Batur) شريك مؤسس في Techsy.io، حيث يبني الفريق وكلاء ذكاء اصطناعي وأنظمة أتمتة وخطوط أنابيب صوتية و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 للاسترجاع المتجهي العادي. وميزة خامسة، توليد الأسئلة، تقع فوقها. وBasic Search هو الأهم: إنه معيار الضبط الذي تقارن به الرسم البياني.

كم تكلف فهرسة GraphRAG؟

التكلفة تقع عند الفهرسة، في استدعاءات LLM التي تستخرج الكيانات والعلاقات من كل مقطع إضافة إلى تلخيص المجتمعات. أفادت Microsoft Research بأن فهرسة LazyGraphRAG تعادل 0.1% من تكلفة GraphRAG الكامل وتطابق تكلفة RAG المتجهي، لكن ذلك التنويع صدر في منتجات Microsoft، لا في المكتبة مفتوحة المصدر. ونحن لم نشغّل فهرسة مسعّرة بأنفسنا.

هل يمكنني تشغيل GraphRAG محلياً مع Ollama؟

نعم. تتيح لك مكتبة microsoft/graphrag توجيه الفهرسة والاستعلام نحو نموذج محلي يخدمه Ollama، ما يزيل رسوم API لكل رمز من خطوة الاستخراج. أنت تقايض السرعة والجودة بالتكلفة: النماذج المحلية أضعف في استخراج الكيانات، فتوقع رسوماً بيانية أكثر ضجيجاً وفترات فهرسة أطول على عتاد متواضع.

أيهما أفضل: LightRAG أم Microsoft GraphRAG؟

كل منهما تحسّن شيئاً مختلفاً. LightRAG (38,353 نجمة، آخر push في 2026-07-30) هي الأنشط والأخف تشغيلاً؛ وmicrosoft/graphrag (35,088 نجمة، v3.1.1) هي التنفيذ المرجعي بطرق الاستعلام الأربع الرسمية. اختر LightRAG لرسم بياني إنتاجي كفء، ومكتبة Microsoft لسلوك مطابق للمواصفة ومعيار ضبط Basic Search.

من أنشأ GraphRAG ومتى؟

أنشأت Microsoft Research مشروع GraphRAG. نشر الفريق الورقة البحثية في 2024 ويصون مستودع microsoft/graphrag مفتوح المصدر بموجب رخصة MIT، مع وثائق على microsoft.github.io/graphrag. ووصلت المكتبة المرجعية إلى v3.1.1 في 2026-07-18، ونمت حولها منظومة نشطة من تنفيذات أطراف ثالثة، منها LightRAG وGraphiti.

الخلاصة: متى يستحق الرسم البياني تكلفته

الأدلة تشير إلى اتجاه واحد، وهذا هو موقفنا.

• GraphRAG لم ينته. إنه ظرفي، واختبارات 2026 المعيارية تقول ذلك صراحة.
• يبرر فاتورة فهرسته في أسئلة الكيانات متعددة القفزات والتجميع الشامل للمدونة. ويخسر المال في عمليات البحث أحادية القفزة.
• التكلفة فاتورة وقت فهرسة، والتنويع الرخيص الذي يقتبسه الجميع، LazyGraphRAG، لم يصل قط إلى المكتبة مفتوحة المصدر.
• الرسم البياني يتآكل بعد الإطلاق: توحيد الكيانات ينحرف والعلاقات تصبح قديمة، لذا رصد ميزانية لإعادة الفهرسة.
• شغّل Basic Search كمعيار ضبط على مجموعة مستنداتك قبل أن تبني أي شيء.

في جملة واحدة: الرسم البياني المعرفي يبرر تكلفته عندما تكون أسئلتك متعددة القفزات أو شاملة للمدونة، وليس قبل ذلك. وإذا كنت تريد رأياً ثانياً في حزمة الاسترجاع لديك، احصل على استشارة مجانية.