محادثة مع ⁨1000⁩+ ملف ⁨PDF⁩ محلياً: ⁨RAG⁩ على نطاق واسع يتجاوز نماذج الاختبار

لماذا تفشل إعدادات RAG الافتراضية مع أكثر من 1,000 مستند

• الفهرس خارج RAM: تبدأ LanceDB وChromaDB وFAISS كلها بالذاكرة المقيمة. حين يتجاوز الفهرس الذاكرة المتاحة (عادةً 5–8 GB من المتجهات على حاسوب محمول بـ 16 GB) تنتقل للقراءة من القرص ويقفز زمن استجابة p95 من ~300 ms إلى 1–3 ثوانٍ.
• التشابه الجيبي وحده يفشل مع المصطلحات النادرة: التضمينات الكثيفة تُقلّل من وزن الأسماء غير الشائعة وأسماء الأدوية وأرقام القوانين ومعرفات الكود. استعلام "Section 230(c)(1)" يسترجع مقاطع عن "Section 9" لأن التضمين لا يستطيع تمييز الخصوصية العددية. يلتقطها BM25؛ البحث بالتشابه الجيبي وحده يُفوِّتها.
• top-K من 4 ضيق جداً على نطاق واسع: مع 1,000 مقطع top-4 له استرجاع معقول. مع 50,000 مقطع يكون أفضل مقطع في الغالب في الرتبة 12–30 خارج نافذة top-4. يبدو الاسترجاع يعمل (الإجابات معقولة) لكنه يستند إلى مقاطع خاطئة.
• بدون تصفية بيانات وصفية يُهدَر الفهرس: السؤال "ما الذي قاله Smith عن X؟" على مجموعة من 10,000 مستند يبحث في جميع مقاطع الفهرس، حين يجب على النظام أن يُصفّي أولاً إلى "مستندات كتبها Smith". RAG الأساسي لا يمتلك مفهوم التصفية المسبقة بالبيانات الوصفية.
• حجم المقطع الافتراضي 512/0 يُجزّئ السياقات الطويلة: فقرات PDF والأقسام القانونية نادراً ما تناسب 512 رمزاً. التداخل الافتراضي 0 يُضيّع المعنى بين الأجزاء. يحل الضبط 1,000/200 هذا لمجموعات الحجم المتوسط؛ يلزم تقطيع هرمي إلى ما هو أبعد من 5,000 مستند.
• انجراف التضمين عند التحديث: حين تضيف 1,000 ملف PDF جديد بعد ثلاثة أشهر من الفهرس الأصلي ربما تكون إصدارات نموذج sentence-transformer قد تغيرت. خلط تضمينات من إصدارين مختلفين في نفس الفهرس يُدهوِر الاسترجاع بصمت — جميع المعماريات تُجبر على إعادة فهرسة كاملة عند تغيير أداة التضمين.

شجرة قرار المعمارية: اختر أولاً حسب حجم المجموعة

• أقل من 1,000 مستند (أقل من ~5,000 مقطع): تطبيق AnythingLLM Desktop مع حجم مقطع 1,000 / تداخل 200 وnomic-embed-text-v1.5 كأداة تضمين. بدون كود مخصص. راجع الدليل خطوة بخطوة في 30 دقيقة للإعداد.
• 1,000–5,000 مستند (5,000–25,000 مقطع): LlamaIndex في الوضع المحلي بالكامل مع فهارس هرمية (DocumentSummaryIndex + VectorStoreIndex) وOllama كمزود LLM وnomic-embed-text-v1.5 كأداة تضمين وLanceDB أو ChromaDB كمخزن متجهات. ~150 سطر Python، يعمل كعملية طويلة الأمد.
• 5,000–10,000 مستند (25,000–50,000 مقطع): مكدّس مخصص مع Ollama وChromaDB وبحث هجين BM25 عبر Whoosh أو Tantivy وأداة إعادة ترتيب BGE-reranker-v2-m3 على أفضل 50 مرشحاً. ~300–400 سطر Python. أداة إعادة الترتيب ضرورية على هذا النطاق.
• 10,000+ مستند (50,000+ مقطع): Ollama + Qdrant في وضع عقدة واحدة مع تصفية بيانات وصفية قائمة على الحمولة وبحث هجين باستخدام متجهات Qdrant المتفرقة الأصلية وBGE-reranker-v2-m3 وفهرس ملخصات هرمي بمعرّفات المستندات. إعداد درجة إنتاج لمستخدم واحد.
• متعدد المستخدمين (أي نطاق): Open WebUI أمام أي من السابقة، أو غلاف FastAPI صغير حول نفس خلفية Qdrant + Ollama. تعدد المستخدمين يُغيّر التركيز التشغيلي (المصادقة والعزل وحد المعدل) لكن ليس معمارية الاسترجاع.

جدول مقارنة المعماريات

الخيار 1: AnythingLLM محسَّن (100–1,000 مستند)

• النموذج: Llama 3.3 8B Q4_K_M عبر Ollama (5 GB RAM أثناء الاستدلال). على الأنظمة بـ 24 GB+، يُحسِّن Qwen 3 14B Q4 التوليف بشكل ملحوظ.
• أداة التضمين: غيّر من أداة التضمين الافتراضية لـ AnythingLLM إلى nomic-embed-text-v1.5 عبر Ollama. أداة التضمين الافتراضية هي السبب الرئيسي لتقارير "AnythingLLM لا يتوسع".
• التقطيع: 1,000 رمز مع تداخل 200 رمز، يُضبط لكل مساحة عمل في إعدادات Vector Database. الافتراضي 512/0 خاطئ لأي مجموعة أكبر من بضع عشرات من المستندات.
• Top-K: ارفع من الافتراضي 4 إلى 6–8. مع 1,000 مستند، يكون أفضل مقطع في الغالب في الرتبة 5–7، والنموذج يستطيع تجاهل مقاطع ضعيفة أفضل مما يستطيع اختراع المفقودة.
• التقسيم حسب مساحة العمل: أنشئ مساحة عمل لكل فئة مستند (مقالات، عقود، ملاحظات). لكل مساحة عمل LanceDB مفهرس بشكل منفصل؛ الاستعلامات عبر مساحات العمل غير مدعومة لكن الاسترجاع لكل مساحة عمل أعلى بكثير من تجمّع كبير واحد.

الخيار 2: LlamaIndex محلي (1,000–5,000 مستند)

• المكدّس: Ollama + LlamaIndex + LanceDB (أو ChromaDB) + nomic-embed-text-v1.5 عبر محوّل OllamaEmbedding. مستمر على القرص؛ يعمل كعملية Python طويلة الأمد تتفاعل معها عبر CLI أو غلاف FastAPI صغير.
• DocumentSummaryIndex على VectorStoreIndex: يبني LlamaIndex ملخصاً لكل مستند في وقت الفهرسة، ثم يختار الاسترجاع أولاً المستندات ذات الصلة (بحث الملخصات) ثم يبحث في المقاطع داخل تلك المستندات. هذا أرخص نمط استرجاع هرمي.
• توجيه الاستعلامات: يُرسل RouterQueryEngine استعلامات استرجاع الحقائق إلى فهرس المقاطع واستعلامات التوليف إلى فهرس الملخصات. ~30 سطر من الكود؛ يُضاعف جودة الإجابة في مجموعات المستندات الطويلة.
• استرجاع نافذة الجمل: فهرس ثانٍ اختياري يسترجع جملة هدف بالإضافة إلى N جملة محيطة. مفيد للمجموعات القانونية والأكاديمية حيث تكون الإجابة جملة واحدة لكن معناها يعتمد على الفقرة المحيطة.
• الاستمرارية: index.storage_context.persist(persist_dir=...) يحفظ كل شيء. وقت إعادة التحميل لفهرس من 5,000 مستند يتراوح بين 10 و30 ثانية على NVMe SSD.

# Minimal LlamaIndex local RAG with hierarchical indices (~30 lines)
from llama_index.core import VectorStoreIndex, DocumentSummaryIndex, SimpleDirectoryReader
from llama_index.embeddings.ollama import OllamaEmbedding
from llama_index.llms.ollama import Ollama
from llama_index.core import Settings

Settings.llm = Ollama(model="llama3.3:8b-instruct-q4_K_M", request_timeout=120)
Settings.embed_model = OllamaEmbedding(model_name="nomic-embed-text:latest")
Settings.chunk_size = 1000
Settings.chunk_overlap = 200

docs = SimpleDirectoryReader("./pdfs").load_data()

# Summary index for routing + chunk index for retrieval
summary_index = DocumentSummaryIndex.from_documents(docs)
chunk_index = VectorStoreIndex.from_documents(docs)

summary_index.storage_context.persist("./storage/summary")
chunk_index.storage_context.persist("./storage/chunks")

# At query time, route by question type
response = chunk_index.as_query_engine(similarity_top_k=8).query(
    "What sample size did Smith et al. use?"
)
print(response)

الخيار 3: Ollama + ChromaDB مخصص (5,000–10,000 مستند)

• المكدّس: Ollama + ChromaDB (وضع الخادم) + Whoosh أو Tantivy لـ BM25 + BGE-reranker-v2-m3 (~570 MB، يعمل على CPU بـ 50–100 مرشح/ثانية). يُستضاف كعملية Python واحدة أو مقسّم إلى عمال استيعاب + استعلام.
• البحث الهجين في وقت الاسترجاع: شغّل BM25 والاسترجاع الكثيف بالمتجه بشكل متوازٍ، خذ أفضل 25 من كل منهما، أزِل التكرارات ثم أعِد ترتيب أفضل 50 مدمج بالمُشفِّر التقاطعي. أفضل K نهائي من 6–8 يذهب للنموذج.
• حقول بيانات الوصف في ChromaDB: اشترط source_filename وpage_number وdocument_type وauthor وyear في كل مقطع في وقت الفهرسة. التصفية في وقت الاستعلام (where={"document_type": "contract"}) تُقلل نطاق بحث الاسترجاع بين 5 و10 أضعاف بدون فقدان جودة.
• الفهرسة دفعةً دفعة: يولّد ChromaDB التضمينات في دفعات من 32–128 مقطعاً. على RTX 4070، BGE-reranker هو عنق الزجاجة (50–100 مرشح/ثانية على CPU؛ 400+/ثانية على GPU).
• الاستمرارية: يكتب ChromaDB في مجلد SQLite + Parquet. فهرس من 50,000 مقطع على القرص ~3–5 GB. النسخ الاحتياطي هو نسخ المجلد.

الخيار 4: Ollama + Qdrant (10,000+ مستند)

• المكدّس: Ollama + Qdrant (Docker، عقدة واحدة) + متجهات متفرقة أصلية (ما يعادل BM25 مدمج في Qdrant 1.10+) + BGE-reranker-v2-m3 + طبقة تنسيق Python صغيرة.
• الهجين الأصلي: يدعم Qdrant متجهات كثيفة + متفرقة في نفس المجموعة مع دمج موزون في وقت الاستعلام. لا عملية BM25 منفصلة للصيانة.
• ضبط HNSW: مع 50,000+ متجه، ارفع ef_construct إلى 200 وm إلى 32 لبناء الفهرس، واستخدم ef=128 في وقت الاستعلام. الإعدادات الافتراضية تعمل لكنها تتبادل ~10% من الاسترجاع مقابل سرعة البناء.
• مخططات الحمولة للتصفية: يتعامل Qdrant مع الحمولات كمواطنين من الدرجة الأولى. فهرس author وdocument_type وyear وtags كحمولات كلمات مفتاحية لتفعيل التصفية المسبقة في أقل من ميلي ثانية.
• الاسترجاع الهرمي: حافظ على مجموعتين — summaries (متجه واحد لكل مستند) وchunks (المعتادة). وجِّه الاستعلامات أولاً عبر مجموعة الملخصات ثم ابحث في مقاطع معرّفات المستندات المطابقة.
• الاستمرارية: يكتب Qdrant في وحدة تخزين واحدة مرفقة. مجموعة من 100,000 مقطع تشغل ~6–12 GB على القرص حسب حجم الحمولة وإعدادات HNSW.

# Qdrant collection with dense + sparse vectors and metadata filtering
from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, SparseVectorParams, SparseIndexParams
)

client = QdrantClient(host="localhost", port=6333)

client.create_collection(
    collection_name="docs",
    vectors_config={
        "dense": VectorParams(size=768, distance=Distance.COSINE),  # nomic-embed-text-v1.5
    },
    sparse_vectors_config={
        "bm25": SparseVectorParams(index=SparseIndexParams(on_disk=False)),
    },
)

# Query: hybrid search + payload filter, no separate BM25 process needed
from qdrant_client.models import Filter, FieldCondition, MatchValue, Prefetch

results = client.query_points(
    collection_name="docs",
    query=dense_vec,
    using="dense",
    prefetch=[
        Prefetch(query=sparse_vec, using="bm25", limit=25),
        Prefetch(query=dense_vec, using="dense", limit=25),
    ],
    query_filter=Filter(
        must=[FieldCondition(key="document_type", match=MatchValue(value="contract"))]
    ),
    limit=50,  # before rerank
)

البحث الهجين: BM25 + متجه يتفوق على أيٍّ منهما منفرداً

• لماذا يفشل الكثيف وحده: التضمينات تُقلّل من وزن الرموز النادرة. استعلامات مثل "RFC 9110 القسم 7.4" أو "MNDA-2024-0143" تُضمَّن بالقرب من مقاطع IETF/عقد عامة. BM25 يلتقط المعرف الدقيق؛ البحث بالتشابه الجيبي وحده يُفوِّته.
• لماذا يفشل BM25 وحده: المطابقة المعجمية تُفوِّت الأساليب الأخرى. استعلام "كيف نُلغي؟" على مقطع بعنوان "إجراءات الإنهاء" يطابق في الفضاء الكثيف لكن يحصل على 0 في BM25.
• Reciprocal Rank Fusion (RRF) هو الجامع المعياري: لكل مقطع يظهر في أي قائمة نتائج، درجّه كـ 1/(60+rank_dense) + 1/(60+rank_bm25). رتّب بشكل تنازلي. 60 ثابت تمهيد؛ تعمل القيم بين 30–100 عملياً.
• الوصفة العملية: استرجع أفضل 25 من كل أسلوب، ادمج عبر RRF، خذ أفضل 50، أرسل لأداة إعادة الترتيب ثم أفضل 6–8 للنموذج. هذا هو خط أنابيب الإنتاج القياسي على أي نطاق يتجاوز 1,000 مستند.
• تكلفة التخزين: فهارس BM25 صغيرة (~50–150 MB لـ 10,000 مستند) مقارنةً بالفهارس الكثيفة (~500 MB–2 GB على نفس النطاق). إضافة BM25 لمخزن كثيف موجود اقتصادية.

إعادة الترتيب: خطوة تنقية أفضل N

• BGE-reranker-v2-m3 (~570 MB، متعدد اللغات، Apache 2.0) هو الخيار الافتراضي في مايو 2026. يعمل بـ 50–100 مرشح/ثانية على CPU حديث؛ 400+ /ثانية على GPU. تكلفة زمن الاستجابة لإعادة ترتيب أفضل 50 هي ~200–500 ms على CPU، ~80–150 ms على GPU.
• لماذا تتفوق المُشفِّرات التقاطعية في الاسترجاع: التضمينات الكثيفة تُشفِّر الاستعلام والمستند بشكل مستقل لذا لا يراهما النموذج معاً أبداً. مُشفِّر تقاطع يقرأ `[CLS] استعلام [SEP] مرشح [SEP]` بشكل مشترك ويُدرِّج الزوج مباشرةً. يقفز Recall@5 عادةً 15–25 نقطة.
• أين تحقن أداة إعادة الترتيب: بعد البحث الهجين وقبل النموذج. خذ أفضل 50 من الهجين، أعِد الترتيب إلى أفضل 6–8، وأرسل تلك للنموذج كسياق.
• بديل — Cohere Rerank API: جودة أعلى لكن يتطلب استدعاءً سحابياً. للمكدسات المحلية بالكامل، BGE-reranker-v2-m3 هو الافتراضي العملي. mxbai-rerank-base-v2 مرشح بديل قوي.
• تخطّي أداة إعادة الترتيب مقبول دون 1,000 مستند: مكسب الجودة لا يبرر تكلفة زمن الاستجابة. إلى ما هو أبعد من 5,000 مستند، تركها يُبقي ~15–25% من الإجابات مستندةً إلى مقاطع خاطئة.

تصفية بيانات الوصف: تقليص نطاق البحث مسبقاً

• حقول الحمولة الشاملة لملء في وقت الفهرسة: source_filename وpage_number وdocument_type (مقال / عقد / ملاحظة / ويكي) وauthor وyear وlanguage بالإضافة إلى علامات خاصة بالمجال (مثل case_number وproject_id وclient_id).
• التصفية المسبقة في وقت الاستعلام: "ما الذي قالته محاضر مجلس الإدارة للربع الثالث 2024 عن التسعير؟" ← صفِّ document_type=board_minutes AND year=2024 AND quarter=3 أولاً، ثم بحث بالمتجه داخل ~12 مستند بدلاً من 10,000.
• دعم مخزن المتجهات: تدعم حمولات Qdrant وخصائص Weaviate وبيانات وصف ChromaDB وأعمدة مخطط LanceDB جميعها التصفية. يتفاوت الأداء — تصفية حمولة Qdrant على حقول مفهرسة أقل من ميلي ثانية؛ تصفية بيانات وصف ChromaDB على أكثر من 100,000 مقطع قد تضيف 50–150 ms.
• الاستخراج التلقائي للبيانات الوصفية: للمجموعات القانونية، خطوة نموذج صغيرة في وقت الفهرسة يمكنها استخراج أرقام القضايا والتواريخ وأسماء الأطراف لكل مستند. تكلف ~30 ثانية لكل مستند على Llama 3.3 8B؛ تُشغَّل مرة واحدة لكل استيعاب.
• دمج مع البحث الهجين: تصفية الحمولة تُقلص الكون ← استرجاع BM25 + كثيف داخل المجموعة المصفاة ← إعادة الترتيب. تصفية الحمولة هي أرخص تسريع 5–10 أضعاف في أي نظام RAG كبير.

الاسترجاع الهرمي: الملخص أولاً، المقاطع لاحقاً

• ملخصات لكل مستند: في وقت الفهرسة، اطلب من النموذج كتابة ملخص من 100–200 رمز لكل مستند. أنشئ تضمينات تلك الملخصات في مجموعة summaries منفصلة. التكلفة ~30–90 ثانية لكل مستند على Llama 3.3 8B.
• الاسترجاع على مرحلتين: (1) أنشئ تضمين الاستعلام، ابحث في summaries، خذ أفضل 5 مستندات؛ (2) داخل تلك المستندات الخمسة، استرجع أفضل 8 مقاطع عبر بحث هجين؛ (3) طبّق إعادة الترتيب إن لزم؛ (4) أرسل للنموذج.
• متى يُفيد أكثر: استعلامات التوليف والمتعددة المستندات ("قارن كيف تتناول هذه المقالات X"). استرجاع الحقائق ("ما القيمة التي أفادت بها Smith؟") يعمل جيداً بفهرس المقاطع فقط — الانحراف عبر الملخص يضيف زمن استجابة بدون مكسب جودة.
• مقايضة التكلفة: يضاعف تخزين الفهرس (الملخصات صغيرة لكن الفهرس نفسه بنية تحتية مضاعفة). يضاعف زمن الاستجابة للاستعلامات غير الموجَّهة. المكسب في تقليص الضوضاء من 10,000+ مستند.
• LlamaIndex يدمجه: DocumentSummaryIndex بالإضافة إلى RouterQueryEngine تطبيق من 30 سطر. Python مخصص مع ChromaDB أو Qdrant هو ~80–120 سطر.

قياسات موثوقة عند 100 و1,000 و10,000 مستند

تحديد حجم التخزين ومتطلبات الأجهزة

• النص الخام لـ 1,000 ملف PDF (~12 صفحة لكل منها): ~50–150 MB من النص المستخرج. يتفاوت بشكل كبير حسب الكثافة.
• متجهات لـ 1,000 مستند: ~300–400 MB على القرص شاملاً تكلفة فهرس HNSW. ~120–180 MB إذا تجاهلت فهرس HNSW واستخدمت البحث بالقوة الغاشمة (مقبول دون 5,000 مستند).
• متجهات لـ 10,000 مستند: ~3–5 GB على القرص. بناء HNSW يستغرق 10–30 دقيقة على CPU حديث.
• متجهات لـ 50,000 مستند: ~15–25 GB على القرص. وقت بناء الفهرس هو عنق الزجاجة — خطط لـ 2–4 ساعات من عمل CPU لمرة واحدة.
• RAM أثناء الاستعلام: الاسترجاع الكثيف يحتاج ~30–50% من الفهرس في ذاكرة العمل لاستعلامات ذات زمن استجابة منخفض. فهرس من 5 GB يُستعلَم بشكل مريح بـ 8–16 GB RAM مع HNSW؛ القوة الغاشمة تحتاج الفهرس كاملاً في الذاكرة.
• RAM أثناء الفهرسة: يرتفع إلى 2–3 أضعاف حجم نموذج التضمين (~600 MB لـ nomic-embed-text) بالإضافة إلى النص لكل دفعة. 8 GB RAM حرة كافية لخطوة الفهرسة.
• GPU مقابل CPU: إنتاجية التضمين أسرع 4–8 أضعاف على GPU منفصل أو Apple Silicon. للفهرسة على مرور واحد مع 10,000+ مستند، يوفر GPU 1–3 ساعات. للتضمين في وقت الاستعلام (استعلام واحد في كل مرة)، CPU كافٍ.
• نوع القرص مهم: NVMe SSD هو الحد الأدنى العملي من 5,000+ مستند. SATA SSD يضيف 30–100% لزمن استجابة الاستعلامات الباردة؛ القرص الدوار غير قابل للاستخدام إلى ما هو أبعد من ~2,000 مستند.

الفهرسة التدريجية وإزالة التكرار

• إزالة التكرار الدقيق القائم على التجزئة عند الاستيعاب: SHA-256 لبايتات الملف الخام. تخطَّ الملفات التي تجزئتها موجودة بالفعل في الفهرس. رخيص، يلتقط الملفات المتطابقة لكن يُفوِّت شبه المكررة (مسحات ضوئية OCR مختلفة لنفس المستند، تحويلات الصيغ).
• إزالة التكرار بتجزئة المحتوى: SHA-256 للنص الخام المستخرج بعد حذف المسافات البيضاء. يلتقط نفس المستند بصيغ ملفات مختلفة. يضيف ~5 ms لكل ملف في الاستيعاب.
• MinHash لشبه المكررات: للمجموعات القانونية والأكاديمية حيث تتراكم مسودات متعددة لنفس المستند، احسب بصمة MinHash (~128 بايت لكل مستند) وتخطَّ الملفات ضمن حد تشابه Jaccard لمدخل موجود.
• معرّفات المستندات دائمة: لا تعيد استخدام معرّف مستند بعد حذفه. كثيراً ما تحتفظ مخازن المتجهات بمتجهات يتيمة لفترة وجيزة؛ إعادة استخدام المعرّفات يُسبب ارتباكاً صامتاً. استخدم UUID أو معرّفات قائمة على التجزئة.
• إعادة التضمين عند تغيير أداة التضمين: جميع المعماريات تُجبر على إعادة فهرسة كاملة عند تغيير نموذج التضمين. خطط لاختيار أداة تضمين تلتزم بها لمدة سنة على الأقل قبل فهرسة 10,000 مستند.
• الحذف: ChromaDB وQdrant يدعمان حذف النقاط بالمعرّف. LanceDB يتطلب خطوة ضغط لاستعادة مساحة القرص — خطط لها أسبوعياً إذا حذفت أكثر من ~5% من المجموعة شهرياً.

مراقبة جودة RAG على نطاق واسع

• بناء مجموعة ذهبية صغيرة: 30–50 استعلاماً تعرف الإجابة الصحيحة لها، مستخرجة من الاستخدام الفعلي. تشمل: استرجاع حقائق (5–10)، توليف (5–10)، عبر مستندات (5–10)، حالات حدية (5–10)، واستعلامات فقدان معروف (5–10) حيث الإجابة غير موجودة في المجموعة.
• تتبع ثلاثة مقاييس لكل استعلام: استرجاع الاسترجاع (هل ظهر المقطع الصحيح في أفضل K?)، دقة التوليد (هل الإجابة تطابق المقطع?)، ومعدل الرفض (هل يقول النظام بشكل صحيح "غير موجود في المجموعة" لاستعلامات الفقدان المعروف?).
• أعِد التشغيل عند كل تغيير مهم: دفعات استيعاب جديدة، تغييرات أداة التضمين، تغييرات حجم المقطع، تعديلات الكلمة التوجيهية. قارن النتائج بالتشغيل السابق؛ ضَع علامة على أي استعلام تغير فيه استرجاع الاسترجاع أو الإجابة.
• Trulens أو RAGAS لأطر التقييم الآلي. كلاهما يعمل محلياً ويتكامل مع LlamaIndex. التقييم اليدوي لـ 30–50 استعلاماً صالح أيضاً وغالباً أدق.
• ميزانيات زمن الاستجابة: تتبع زمن استجابة الاستعلام p50 وp95 بمرور الوقت. قفز 50% في p95 يعني عادةً أن الفهرس تجاوز RAM — الإشارة المبكرة بأنك تحتاج للانتقال إلى المستوى التالي من المعمارية.

الأسئلة الشائعة

قراءات ذات صلة

• AnythingLLM مقابل PrivateGPT مقابل Open WebUI: أفضل RAG محلي في 2026 — السياق الأساسي لاختيار منصة RAG لسطح المكتب قبل التوسع.
• أفضل نماذج التضمين لـ RAG المحلي في 2026 — اختيار أداة التضمين هو القرار الفردي الأهم قبل فهرسة 10,000 مستند.
• RAG محلي للبيانات التجارية الخاصة — التوسع الطبيعي حين يلتقي RAG على نطاق شخصي بمتطلبات امتثال مؤسسية.
• بناء RAG محلي على ملفات PDF الخاصة بك في 30 دقيقة (Ollama + AnythingLLM) — إعداد المستوى الأساسي قبل الوصول إلى منحدر التوسع.
• RAG موضَّح: كيف تُثبّت إجابات الذكاء الاصطناعي في بيانات حقيقية (2026) — المرجع المفاهيمي حول ما هو RAG ولماذا يهمّ كل مكون استرجاع.
• دليل أجهزة نموذج اللغة المحلي 2026 — مرجع تحديد حجم الأجهزة لمجموعات 10,000+ مستند.
• مركز Power Local LLM — المكتبة الكاملة لأدلة هذا التجمع.