هندسة RAG المؤسسية: دليلٌ لقواعد البيانات الشعاعية والتقطيع والتقييم

أصبح RAG (Retrieval-Augmented Generation) خلال السنوات الثلاث الماضية الهندسةَ السائدة لمشاريع الذكاء الاصطناعي في المؤسسات. ومتطلباتٌ كالامتثال لـ KVKK، وإدارةُ البيانات الحساسة، والعملُ مع قواعد المعرفة الداخلية للشركات، فتحت مسارًا أكثر عمليّةً من الـfine-tuning للنماذج المفتوحة؛ اترك النموذجَ الأساس كما هو، وأطعِم مستنداتِ المؤسسة للنموذج لحظة الاستدعاء، ودعه يُنتج الإجابة. الشعارُ بسيط؛ وقلّةُ الانضباط في التنفيذ تُعفّن المشاريع. والفرقُ بين RAG الإنتاجي وRAG العَرض هو جودةُ المعمارية؛ فكلُّ طبقةٍ من اختيار قاعدة البيانات الشعاعية إلى استراتيجية التقطيع، ومن البحث الهجين إلى الـReranker، ومن إطار التقييم إلى مراقبة الإنتاج، يجب أن تكون مَقيسةً ومختبَرة.

في إطار خدماتنا في هندسة أنظمة RAG وهندسة قواعد البيانات الشعاعية عملنا خلال الأشهر الثمانية عشر الأخيرة على 12 مشروع RAG مؤسسي، ونُشغّل منصّتَنا AIGENCY v4 على هندسةٍ مكثّفة الـRAG. نَستعرض في هذا المقال سبعةَ قراراتٍ حرجة لهندسة RAG المؤسسية بالترتيب؛ اختيارُ مستودع المستندات، استراتيجيةُ التقطيع، نموذجُ الـembedding، البحثُ الهجين، طبقةُ الـReranker، إطارُ التقييم، ومراقبةُ الإنتاج.

1. القرار الاستراتيجي؛ RAG أم Fine-Tuning أم هجين؟

السؤالُ الأول ليس لِنستخدم RAG؛ بل ينبغي أن يكون هل RAG الأداةُ الصحيحة لهذه المشكلة؟. ثلاثةُ مقاربات مطروحة:

• Pure RAG؛ يبقى النموذجُ الأساس بلا تغيير، وتُسحَب مستنداتُ المؤسسة في كل استعلامٍ لحظةَ الاستدعاء. مثاليٌّ للسيناريوهات التي تَتحدّث فيها البيانات باستمرار، وتَستلزم التدقيق والتتبّع (الشؤون القانونية، دعمُ العملاء، قاعدةُ المعرفة المؤسسية).
• Fine-Tuning؛ يُخصَّص النموذجُ الأساس لنبرةٍ أو صيغةٍ أو مهمّةٍ مجاليّةٍ معيّنة. جيّدٌ للمهامّ الثابتة الضيقة (التقارير الطبية، تحويل أسلوب الكود، توليد أوصاف المنتجات).
• الهجين (RAG + Fine-Tuning)؛ يحمل النموذجُ المُعدَّل المعرفةَ الأساس (مصطلحاتُ المجال، الصيغة)، فيما يوفّر RAG البياناتِ المُحدَّثة باستمرار. المقاربةُ السائدة في السيناريوهات المؤسسية المعقّدة عالية الحجم.

اختبارُ القرار؛ إن كانت المعرفة تُحدَّث يوميًا فـRAG؛ وإن كان السلوك/الصيغة بحاجةٍ إلى تعلُّم فـFine-Tuning؛ وإن كانا معًا مطلوبَين فـهجين. وحوالى 70 بالمئة من المشاريع المؤسسية تبدأ بـ Pure RAG؛ ومع بلوغها حجمَ الإنتاج الفعلي ينتقل نحو نصفها إلى الهجين. ويظلّ الـFine-Tuning الصرف أقليّةً في الاستخدام المؤسسي لأن إعادة التدريب مع كل تغيير معرفي مكلفة وتعسّر التدقيق.

النقطةُ العملية الثانية؛ ليس RAG حلًّا سحريًا. فإن طُبّق خطأً تَزيد معدّلاتُ الهلوسة (يَعدّ الـLLM المستنداتِ غير المعنيّة مصادر)، ويرتفع زمنُ الانتظار، وتنفجر الكلفة. وإن طُبّق صحيحًا أَنطَق النموذجَ بـ لا أعرف حين يجب، وأَنطَقَه بإجابةٍ مع الاستشهاد بمصدرها حين يَعرِف. الفرقُ هو الانضباط المعماري.

2. اختيار مستودع المستندات؛ pgvector مقابل Qdrant مقابل Milvus مقابل الخدمات المُدارة

اختيارُ قاعدة البيانات الشعاعية هو قرارُ الهيكل العظمي لهندسة RAG؛ وتغييرُه لاحقًا يعني ألمَ الترحيل وأشهرًا من الاحتكاك. ثلاثُ فئاتٍ رئيسة:

PostgreSQL + pgvector؛ يُثبَّت بصفته امتدادًا فوق PostgreSQL القائم. قاعدةُ بياناتٍ واحدة، نسخةٌ احتياطية واحدة، تشغيلٌ واحد. عَمليٌّ في نطاق 100-500 ألف embedding. مزايا؛ فلترةُ بيانات وصفية على مستوى SQL، اتّساقٌ معاملاتي، الأداةُ التي يعرفها فريقك أصلًا. عيوب؛ تتباطأ فهرسةُ HNSW عند 1 مليون فأكثر، وتحتاج تركيباتُ الفلاتر مع البحث الشعاعي إلى ضبطٍ خاص. توصيتُنا؛ الاختيارُ الافتراضي للمشاريع المؤسسية الصغيرة والمتوسطة.

Qdrant؛ مكتوبٌ بـ Rust، قاعدةُ بياناتٍ vector-first. أداءٌ ممتاز لفهرس HNSW، فلترُ payload أصلي، واجهتا REST وgRPC. النقطةُ المثلى من 1 إلى 50 مليون embedding. self-hosted أو سحابةٌ مُدارة. ازدادت شعبيّتُه في المشاريع المؤسسية منذ 2023. ونحفظ في خطّ AIGENCY 8 ملايين embedding في عنقود Qdrant.

Milvus؛ هندسةٌ موزّعة مُصمَّمة لأحجامٍ كبيرة جدًا (10 ملايين إلى مليار فأكثر embedding). عبءُ التشغيل عالٍ (مكوّناتُ Kubernetes وetcd وMinIO)؛ وصعبٌ من دون حضور DevOps مخصّص في الفريق. الميزة؛ فهرسةٌ مُسرَّعة بالـGPU وخياراتُ فهرسٍ متقدّمة (IVF/HNSW/DiskANN).

Pinecone / Weaviate Cloud / Zilliz Cloud؛ خدماتٌ مُدارة. بلا عبء تشغيل، جاهزةٌ للإنتاج خلال دقائق. الكلفة؛ شهريًا 70-1.500 دولار لحملٍ صغير-متوسط، و3.000-15.000 دولار لـSLA مؤسسي. ومن منظور KVKK يُعدّ مكانُ البيانات حرجًا؛ لـ Pinecone منطقةٌ في الاتحاد الأوروبي، ولـ Weaviate خياراتُ self-hosted أو AWS Frankfurt؛ وDPA (Data Processing Agreement) إلزاميٌّ في العقد.

مصفوفةُ القرار:

المعيار	pgvector	Qdrant	Milvus	المُدارة
النطاقُ المثلى	<500 ألف	1-50 مليون	10 مليون-1 مليار+	أيُّ نطاق
عبءُ التشغيل	منخفض	متوسط	عالٍ	لا يوجد
كلفةُ البنية التحتية شهريًا	500-3.000 ليرة	3.000-15.000 ليرة	10.000-40.000 ليرة	70-15.000 دولار
التحكّمُ بـ KVKK	كامل	كامل	كامل	تبعًا للعقد
البحثُ الهجين	يدوي	أصلي	أصلي	أصلي
زمنُ الانتظار p95	30-100 مللي ثانية	10-50 مللي ثانية	5-30 مللي ثانية	20-100 مللي ثانية

التوصيةُ العملية؛ ابدأ بـ pgvector. ومع اقترابك من حدّ 500 ألف embedding، خطّط لترحيلٍ إلى Qdrant. وفوق 10 ملايين فكّر في Milvus أو خدمةٍ مُدارة. ومحاولةُ اختيارٍ كبير من البداية تَخلق إرهاقًا تشغيليًا وكلفةً غير ضرورية في معظم المشاريع.

3. استراتيجية التقطيع؛ الحجمُ الثابت لا يكفي

العاملُ المنفرد الأكثر حسمًا في جودة RAG هو استراتيجيةُ التقطيع. والـchunks السيئة تُهدر حتى أفضلَ نموذج embedding في العالم. ثلاثُ أنماطٍ أساسية:

التقطيعُ ثابت الحجم؛ يُقسَّم المستند إلى عددٍ ثابتٍ من الرموز (مثلًا 500 رمزٍ، تداخل 15 بالمئة). الأبسطُ والأسرع؛ ومقبولٌ للنصوص الحرّة (البريد الإلكتروني، سجلّات المحادثة). العيب؛ قد تقع القطعُ في منتصف فقرةٍ أو جملة، فتنزاح الحدودُ الدلالية.

التقطيعُ المُدرِك للبنية؛ يُقسَّم وفق بنية المستند؛ بحسب عناوين Markdown (# و##)، بحسب وسومٍ section/article في HTML، وفي PDF بحسب تغيّرات الخطوط أو النقاط التعدادية. ويُعطي للمستندات التقنية والنصوص القانونية ومواصفات المنتجات استرجاعًا أفضل 2-3 مرّات. التنفيذ؛ موزّعاتٌ جاهزة في Unstructured.io ومُقطّعاتُ العقد في LlamaIndex وText Splitters في LangChain.

التقطيعُ الدلالي؛ تقسيمٌ مُدرِكٌ لـembedding؛ يبدأ chunk جديد عندما تتجاوز مسافةُ cosine بين embeddings جملتين متتاليتين عتبةً معيّنة. الأكثرُ تطوّرًا لكنّه مُكثّفُ الحوسبة (تمريرةُ embedding إضافية لكل مستند). يُنتج قيمةً فعلية للنصوص الطويلة المعقّدة (المقالات الأكاديمية، التقارير).

الحجمُ الأمثل للـchunk مرتبطٌ بالمجال:

نوعُ المستند	حجمُ chunk الموصى به	التداخل	الاستراتيجية
عقد، نصٌّ قانوني	600-900 رمزًا	20 بالمئة	مُدرِكٌ للبنية (المادة/الفقرة)
توثيقٌ تقني	400-600 رمزًا	15 بالمئة	مُدرِكٌ للبنية (العناوين)
FAQ دعم العملاء	200-400 رمزًا	10 بالمئة	زوجُ Q-A بصفته chunk واحدًا
بريد إلكتروني، سجلّ محادثة	300-500 رمزًا	15 بالمئة	ثابت + نافذةٌ منزلقة
مقالٌ أكاديمي	500-800 رمزًا	20 بالمئة	دلالي
ملفُّ كود	الدالّةُ كاملةً	0	مُدرِكٌ للـAST (Tree-sitter)

في خطّ AIGENCY لدينا يُصنّف مصنّفُ نوع المستند المستندَ أولًا (عقد / بريد / FAQ / سجلّ / مقال)، ثم يُشغَّل مُقطّعٌ متخصّص لكل نوع. وقد رَفع هذا النهجُ recall في top-5 بنسبة 35 بالمئة مقارنةً بالتقطيع الثابت الموحَّد.

النقطةُ العملية الثالثة؛ إثراءُ البيانات الوصفية. أضِف إلى كل chunk ليس النصّ فقط، بل عنوانَ المستند، وعنوانَ القسم، ونوعَ المستند، وعنوانَ المصدر، واللغة، وتاريخَ آخر تحديث، والمؤلّف. وفي مرحلة الاسترجاع تكون هذه البياناتُ ذهبًا للفلاتر (مثلًا مستنداتُ الأشهر الستّة الأخيرة فقط)؛ وفي مرحلة التوليد تكون ذهبًا لنسب المصدر.

4. نموذجُ الـEmbedding؛ متعدّدُ اللغات، dense، sparse، هجين

جودةُ نموذج الـembedding هي سقفُ جودة الاسترجاع. ومع نموذجٍ خطأ يُعطي حتى أفضلُ تقطيعٍ recall منخفضًا. وحتى 2026 ثمّة أربعُ عائلاتٍ عملية:

OpenAI text-embedding-3-large؛ 3072 بُعدًا، قويٌّ في الإنجليزية والتركية والعربية، وبكلفة نحو 0.00013 دولار لكل استعلام. شائعٌ في الإنتاج، لكنّ كل استعلام يذهب إلى OpenAI؛ ومن منظور KVKK قد يَخلق ذلك مشكلةً في مكان البيانات ويتطلّب DPA في العقد.

Cohere embed-multilingual-v3؛ 1024 بُعدًا، 100+ لغة؛ أضعفُ قليلًا من OpenAI في التركية والعربية، لكنّه قويٌّ كذلك. وعرضُ Cohere في منطقة الاتحاد الأوروبي ميزةٌ لـ KVKK. الكلفةُ قريبةٌ من OpenAI.

مفتوحُ المصدر؛ BGE-M3، mE5-large، multilingual-MiniLM؛ self-hosted، يعمل على GPU. ويمكن لـ BGE-M3 العمل في أوضاع dense وsparse ومتعدّدة المتّجهات (شبيه بمنهج Cohere الحاصل على براءة اختراع). مزايا؛ تحكّمٌ كامل بـ KVKK، بلا كلفة لكل استعلام، وبإمكانك fine-tuning. عيوب؛ عبءٌ تشغيلي على GPU؛ وقد يكون زمنُ الانتظار الخامُّ أعلى 2-5 مرّات من OpenAI/Cohere.

مُعدَّلٌ لمجالٍ محدّد؛ تُجري المؤسسةُ contrastive fine-tuning لـ BGE أو E5 على corpus خاص بها. والتدريبُ خلال 1-3 إيبوكات على 5-50 ألف زوج من query-positive_doc يَرفع recall بنسبة 10-25 بالمئة. وثمّة قيمةٌ حقيقية للّغة المجالية (القانون، المالية، الطب).

التوصيةُ العملية؛ OpenAI أو Cohere للتجارب والـPoC؛ BGE-M3 self-hosted للمؤسسات الحرجة في KVKK؛ BGE أو mE5 المُعدَّل للحجم الفعلي والدقّة المجالية. وتبديلُ نموذج الـembedding يستلزم إعادةَ embed للـcorpus كلّه؛ احسب هذه الكلفة والوقت من البداية (مليون مستند × ساعتان إعادة embed × كلفة ساعة GPU).

5. البحثُ الهجين؛ Vector + BM25 + RRF

يُخطئ البحثُ الشعاعي الصرف بعض الاستعلامات:

• مطلوبٌ تطابقٌ حرفي (كود المنتج XR-2050-A، القانون 5651)
• أسماء الأشخاص والأماكن (تُمثّل نماذجُ embedding أسماءَ العَلم تمثيلًا ضعيفًا)
• الاختصارات والمصطلحات التقنية (KVKK، MASAK، TS 13638)
• النفي (الأنظمةُ غيرُ المتوافقة مع KVKK؛ تتعامل embeddings مع النفي بضعف)

الحلُّ هو البحثُ الهجين؛ BM25 (sparse) + Vector (dense) يَعملان معًا، وتُدمَج النتائج. منهجان للدمج:

Reciprocal Rank Fusion (RRF)؛ يُمرَّر رتبةُ المستند في كل نظامٍ عبر 1/(k+rank) (k=60 افتراضيًا)، وتُجمَع الدرجتان. ولا حاجة إلى تطبيع الدرجات، وهو متين. الخيارُ الافتراضي في الإنتاج.

درجةٌ موزونة؛ يُطبَّع BM25 score وvector score منفصلَين، ثم يُدمَجان بوزنٍ (مثلًا 0.4 لـ BM25 و0.6 لـ vector). تحتاج الأوزانُ إلى ضبطٍ لكل مجال؛ أكثرُ مرونة، لكنّه مُجهِدٌ في الضبط.

التنفيذ:

قاعدةُ بياناتٍ شعاعية	دعمُ الهجين
pgvector	يدوي (ts_vector + cosine، يُدمَج في الكود)
Qdrant	أصلي (Fusion API)
Weaviate	أصلي (Hybrid Query)
Milvus	أصلي (BM25 + Vector + RRF)
Elasticsearch	أصلي (knn + match query)

في قياساتنا رفع البحثُ الهجين recall في top-5 بنسبة 18-32 بالمئة ودقّة top-1 (أفضلُ نتيجة) بنسبة 25-40 بالمئة مقارنةً بالشعاعي الصرف. وخارج الـPoC نَعدّه إلزاميًّا لكل RAG إنتاجي.

6. الـReranker؛ مرشّحُ الدقّة في الخطّ

مرحلةُ الاسترجاع سريعةٌ + واسعة (top-50 وtop-100 من المستندات)؛ والـReranker بطيءٌ + دقيق (يقيّم cross-encoder كلّ زوج استعلام-مستند منفردًا، ويقصّ إلى top-5). ورياضياتُ المنهج الثنائي بسيطة؛ يُحوّل embedding الـbi-encoder الاستعلامَ والمستندَ إلى متّجهَين منفصلَين، ثم يحسب مسافة cosine؛ فتُفقَد معلومات. ويُعطي الـcross-encoder الاستعلامَ والمستند للنموذج معًا ويُنتج درجةً أدقّ؛ لكن لأن كل زوج استعلام-مستند يَتطلّب استدعاءَ نموذجٍ منفصل، فهو أبطأ.

التدفّقُ العملي:

1. الاستعلامُ → embedding → استرجاع top-100 من قاعدة البيانات الشعاعية (10-50 مللي ثانية)
2. Top-100 → نموذجُ الـReranker → درجةٌ لكل زوج (50-300 مللي ثانية لـ100 مستند)
3. Top-5 / top-10 → يُوضَع في سياق الـLLM
4. يُنتج الـLLM الإجابة

أبرزُ الـRerankers:

• Cohere Rerank v3؛ API مُدارة، 0.001-0.002 دولار لكل استعلام، زمنُ انتظار 100 مللي ثانية. منطقةُ الاتحاد الأوروبي لـ KVKK. الأكثرُ شيوعًا في الإنتاج.
• BGE Reranker (مفتوحُ المصدر)؛ self-hosted، 50-150 مللي ثانية على GPU. تحكّمٌ كامل بـ KVKK، بلا كلفةٍ لكل استعلام. متاحٌ في base/large/v2-m3.
• ColBERT v2؛ هندسةُ late-interaction، درجةٌ لكل رمز استعلام مقابل كل رمز مستند. الأكثرُ دقّة، لكنّه معقّدٌ تشغيليًا. لاستخدامات الدقّة العالية جدًا فقط.
• Cross-encoder ms-marco-MiniLM؛ نموذجٌ صغير، سريع (معقولٌ حتى على CPU)، مكسبُ recall محدود.

في AIGENCY نَستخدم Cohere Rerank v3 مع BGE Reranker self-hosted احتياطيًا. والاحتياطُ الآلي عند تعذُّر Cohere يحفظ ميزانيةَ زمن الانتظار.

برهانُ قيمة الـReranker؛ في مقياس مرجعي بـ200 استعلام أَعطى الاسترجاعُ + الـLLM وحدهما دقّةَ 62 بالمئة، فيما ارتفع الاسترجاع + الـrerank + الـLLM إلى 84 بالمئة. وللـRAG الإنتاجي لم يَعد الـReranker اختياريًا، بل صار طبقةً إلزامية.

7. إطارُ التقييم؛ من أين تَعلم أن النظام يعمل فعلًا؟

الخطوةُ الأكثر تجاهلًا في RAG الإنتاجي هي التقييم. يُؤخَذ النظامُ إلى الإنتاج لأن العَرض يعمل؛ وبعد ثلاثة أشهر تبدأ الشكاوى؛ لِمَ يقول نموذجُنا لا أعرف؟. الحلّ؛ تقييمٌ مستمرٌّ ثلاثيُّ الطبقات.

الطبقةُ 1؛ تقييمُ الاسترجاع. تُحضَّر مجموعةُ بياناتٍ ذهبية (50-200 زوج استعلام-positive_doc مُعنوَنة يدويًا)؛ ويُعيد النظامُ top-K لكل استعلام؛ والمقاييس:

• Recall@K؛ هل المستندُ الصحيح ضمن top-K؟
• MRR (Mean Reciprocal Rank)؛ في أيِّ متوسطِ رتبةٍ يقع المستندُ الصحيح؟
• NDCG؛ جودةُ ترتيبٍ مُدرَّجٌ بالملاءمة.

أُتمتةً؛ تُوفّر أُطُر Ragas وTruLens وPhoenix (Arize) وDeepEval أنماطًا جاهزةً لتقييم الاسترجاع والتوليد. والتشغيلُ الآليُّ الأسبوعي مع لوحة قياس هو الحدُّ الأدنى من المعيار في المشاريع المؤسسية.

الطبقةُ 2؛ تقييمُ التوليد. جودةُ إجابة الـLLM:

• Faithfulness؛ هل الإجابةُ وفيّةٌ للسياق المُسترجَع (بلا هلوسة)؟
• Answer Relevance؛ هل تُجيب الإجابةُ عن الاستعلام؟
• Context Precision/Recall؛ هل استُخدم السياقُ اللازم؟

نمطُ LLM-as-judge (سؤالُ GPT-4o أو Claude Opus قيّم وفاءَ هذه الإجابة لهذا المصدر من 1 إلى 5) سريعٌ ويُتيح التوسّع؛ لكنّه ذاتيّ؛ والمعايرةُ البشرية فصليّةٌ إلزامية (50-100 عينة بعنوانٍ يدوي).

الطبقةُ 3؛ مراقبةُ الإنتاج. على استعلامات المستخدمين الحقيقيّين:

• توزيعُ زمن الانتظار (p50، p95، p99)؛ مراحلُ الاسترجاع والـrerank والـLLM منفصلة.
• الكلفةُ لكل استعلام؛ استهلاكُ الرموز وكلفةُ استعلام قاعدة البيانات الشعاعية.
• معدّلُ ردود الإعجاب/عدم الإعجاب؛ ردُّ فعل المستخدم.
• معدّلُ لا أعرف / الاستيضاح؛ هل النموذجُ متشكِّكٌ بإفراط أم عدوانيٌّ بإفراط؟
• فحصُ الهلوسة العشوائي؛ مراجعةٌ يدوية أسبوعية لـ20-50 استعلامًا عشوائيًا.

ودون تشغيل الطبقات الثلاث معًا قد يستغرق اكتشافُ تدهور RAG أشهرًا. فترقيةٌ لنموذج embedding، تعديلٌ في معامل تقطيع، إعادةُ بناءٍ لفهرس قاعدة البيانات الشعاعية؛ كلٌّ منها قد يُخفّض الجودة بصمت. ودمجُ مجموعة eval في خطّ CI/CD (تشغيلُ retrieval eval في كل PR، حظرُ التراجع) يُتيح تطوّرَ RAG منضبطًا.

يُفصّل إطارُ حوكمة الذكاء الاصطناعي لدينا كيف تتشابك طبقاتُ التقييم هذه مع متطلّبات تدقيق المؤسسة. وحين تُدمَج مع التزام مسؤول البيانات بـ KVKK، تُؤدّي هذه الـeval أيضًا دورَ الدليل القانوني؛ جوابٌ موثَّق على كيف يعمل نموذجُنا، ومن أيِّ مصدرٍ هو وفيٌّ.

ملخّصٌ عملي؛ قائمةُ بداية

الترتيبُ الصحيح لأوّل مشروع RAG إنتاجي:

1. هل RAG هو الصحيحُ فعلًا؟؛ إن لم تتحدّث المعرفة كثيرًا، فالأقربُ Fine-Tuning؛ وإن لم يكن السلوكُ ممّا يُتعلَّم، فالأقربُ RAG؛ وإن كان كلاهما، فالأقربُ هجين.
2. مستودعُ المستندات؛ ابدأ بـ pgvector (<500 ألف embedding)؛ هاجِر إلى Qdrant مع نمو الحجم. ولا تختر الخدمةَ المُدارة إلا بعد توفّر KVKK DPA.
3. التقطيع؛ مصنّفُ نوع المستند + مُقطّعٌ خاصٌّ بكل نوع. ثابتُ الحجم للنصوص الحرّة فقط. والمُدرِكُ للبنية افتراضًا كلّما أمكن.
4. Embedding؛ ابدأ بـ OpenAI/Cohere (للـPoC)؛ وللإنتاج فكّر في BGE-M3 self-hosted أو المُعدَّل مجاليًا.
5. البحثُ الهجين؛ BM25 + Vector + RRF. خارج الـPoC دائمًا.
6. Reranker؛ Cohere Rerank أو BGE Reranker. إلزاميٌّ في الإنتاج.
7. التقييم؛ مجموعةُ بياناتٍ ذهبية ← تقييمُ استرجاع ← LLM-judge ← مراقبةُ إنتاج. ثلاثتها، بأتمتةٍ أسبوعية.
8. البياناتُ الوصفية؛ ألصِق بكل chunk عنوانَ المستند والقسمَ والنوعَ وعنوانَ المصدر والتاريخَ واللغة. ذهبٌ للفلترة ونسب المصدر.
9. KVKK؛ مكانُ البيانات (النموذج، قاعدةُ البيانات الشعاعية، السجلّات)، DPA، سياسةُ الاحتفاظ، تتبُّعُ البيانات المُشتقَّة من المستخدم.
10. تحسينٌ مستمر؛ أغلِق حلقةَ الـfeedback؛ حلّل استعلامات الإنتاج ذات التقييم المنخفض، حدِّث مجموعةَ البيانات الذهبية، كرّر على الـchunker والـembedding والـReranker.

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

استوعب فريقُنا في شانلي أورفا قرة كوبرو هذا الانضباط من خلال تشغيل منصّتنا AIGENCY v4 على هندسةٍ مكثّفة الـRAG، وتقديم خدمة هندسة أنظمة RAG المؤسسية. ولأجل تجربة RAG مؤسسية أو اختيار قاعدة بيانات شعاعية أو تقييمٍ معماري لـRAG بدرجة إنتاج، يمكنكم التواصل عبر نموذج الاتصال؛ والمكالمةُ الأولى للتقييم مجانية.

---

eCloud Tech — فريقٌ مقرّه شانلي أورفا في تركيا، يعمل في البرمجيات المؤسسية والذكاء الاصطناعي والبلوكتشين والأمن السيبراني. Building Tomorrow.