RAG 10 min2026-08-04

مخطط البيانات الوصفية (Metadata Schema) لـ Enterprise RAG: التواريخ، التحكم في الوصول، الحالة، والتسلسل

البحث المتجهي (Vector search) يجد النصوص المشابهة، وليس النصوص الصحيحة. أربع مجموعات من حقول البيانات الوصفية تمنع نظام RAG من الاستشهاد بمستندات منتهية الصلاحية، أو مسودات، أو مستندات مقيدة، مع معالجة تحديات الفلترة على نطاق واسع وطريقة لتحديث الفهرس الحالي لديك.

البحث المتجهي لا يمكنه التمييز بين عقد مورد نشط والعقد الذي حل محله. كلاهما يستخدم نفس البنود، ونفس المصطلحات المعرفة، ونفس كتلة التوقيع. تضمين (embeddings) كليهما يقع تقريباً في نفس المكان. اطلب شروط الدفع الحالية، وسيعيد النظام أي مقطع (chunk) يصيغها بشكل أقرب لسؤالك.

هذا هو نقطة الضعف الأساسية في أي استرجاع (retrieval) مبني على التشابه فقط. إنه يجد نصاً مشابهاً، وليس النص الصحيح. النموذج الأذكى لن يحل هذه المشكلة. البيانات المهيكلة المرفقة بكل مقطع ستحل المشكلة، لأنها تسمح للنظام باستبعاد المستندات الخاطئة قبل أن يقوم بترتيب أي شيء.

لماذا يفشل التشابه مع نمو المكتبة

عندما يستوعب نظام RAG مستنداً، يقوم نموذج تضمين بتحويل كل مقطع من النص إلى قائمة من الأرقام التي تلتقط معناه. السؤال يحصل على نفس المعاملة. ثم تعيد قاعدة بيانات المتجهات المقاطع التي تكون أرقامها أقرب لأرقام السؤال.

هذا يعمل بشكل جيد للعثور على الأفكار ذات الصلة. لكنه يفشل عندما تحتوي المكتبة على عدة إصدارات من نفس الشيء.

خذ على سبيل المثال إجراءات التحويلات البنكية الدولية. مسودة 2021، والنسخة المعتمدة في 2023، وتحديث 2026 كلها تناقش حدود الموافقة، وفحوصات المستفيدين، والتوقيعات. بالنسبة لنموذج التضمين، فهي شبه متطابقة. يسأل مسؤول الامتثال: "ما هو حد الموافقة لتحويل مورد؟" قد يعيد النظام رقم 2021.

في مشروع تجريبي يحتوي على 100 مستند، يقوم شخص ما بتنظيم الملفات ونادراً ما يحدث هذا. لكن عند توجيهه إلى محرك مستندات كامل، يحدث هذا باستمرار. هذا أحد أكثر الأسباب شيوعاً لفشل العروض التوضيحية لـ RAG التي أبهرت مجلس الإدارة عند احتكاكها بالبيانات الحقيقية.

الحل هو فلتر صارم يعمل قبل التشابه: المستندات المعتمدة فقط، السارية اليوم فقط، والتي يُسمح لهذا المستخدم برؤيتها فقط. كل واحد من هذه الشروط يحتاج إلى حقل للفلترة بناءً عليه.

مجموعات الحقول الأربع

1. الوقت: ما هو ساري المفعول اليوم

كل مستند مؤسسي له دورة حياة. قم بتخزين effective_date و expiration_date في كل مقطع، بالإضافة إلى superseded_by الذي يشير إلى المستند البديل.

في وقت الاستعلام، يحقن تطبيقك تاريخ اليوم في الفلتر. السياسات المنتهية، وقوائم الأسعار القديمة، والعقود المنقضية تسقط قبل الترتيب. تاريخ انتهاء الصلاحية الفارغ (null) يعني أنه مفتوح، وليس مجهولاً. حافظ على التمييز بين هاتين الحالتين.

احتفظ بالقدرة على الاستعلام "اعتباراً من" تاريخ ماضٍ. يسأل المدققون والمحامون عما كانت عليه السياسة في مارس 2024، ونفس الحقول تجيب على ذلك. نفس الحقول تتعامل أيضاً مع البروتوكولات السريرية المستبدلة وسير عمل النشر الذي يحيلها للتقاعد، حيث تعتبر النسخة القديمة مشكلة تتعلق بسلامة المرضى وليست مجرد إزعاج.

2. الوصول: من يُسمح له بالرؤية

إذا قمت بتحميل كل مستند في فهرس واحد بدون صلاحيات، فقد دمرت نموذج الأمان الخاص بك. موظف يسأل عن رواتب المديرين قد يسترجع ملفات تخطيط الموارد البشرية السرية.

قم بتخزين allowed_groups على كل مقطع، منسوخة من صلاحيات النظام المصدر. في وقت الاستعلام، ابحث عن مجموعات المستخدم في مزود الهوية الخاص بك وقم بالفلترة بناءً عليها. الرفض هو الافتراضي: المقطع الذي لا يحتوي على مجموعات لا يراه أحد.

قم بتخزين معرفات المجموعات (group IDs)، ولا تقم أبداً بتخزين معرفات المستخدمين الفردية. يغير الأشخاص أدوارهم أسبوعياً. تغيير عضوية المجموعة لا يحتاج حينها إلى أي تحديث للفهرس. مكاتب المحاماة هي أوضح مثال: الجدران الأخلاقية المنقولة من نظام إدارة المستندات (DMS) إلى كل مقطع هي تطبيق عملي لهذا الحقل.

WARNING

افرض الوصول في استعلام قاعدة البيانات، وليس في الموجّه (prompt). إذا قمت باسترجاع مقطع سري وأخبرت النموذج "لا تكشف عن هذا"، فأنت تعتمد على تعليمة لحفظ سر. حقن الموجّه (Prompt injection) وأخطاء النموذج العادية كلاهما سيفشلان ذلك. النص الذي لا يُسمح للمستخدم برؤيته يجب ألا يصل إلى النموذج أبداً. قوانين حماية البيانات، بما في ذلك نظام حماية البيانات الشخصية السعودي (PDPL) و قانون HIPAA الأمريكي، تعتبر الإفصاح غير المصرح به انتهاكاً بغض النظر عن مدى تهذيب الموجّه.

3. الحالة: هل هي سياسة أم مسودة

محركات الأقراص المشتركة مليئة بملفات تحمل أسماء مثل Q3_Pricing_Draft_v4_FINAL.docx. اسم الملف لا يخبرك بشيء. لكن حقل status المقيد بقائمة ثابتة يفعل ذلك.

نحن نستخدم خمس قيم: draft، approved، superseded، archived، و unverified. الاستعلامات الافتراضية تبحث في approved فقط. يمكن للمؤلفين اختيار البحث في المسودات صراحةً. unverified هي حالة الانتظار لأي شيء لم يتمكن خط المعالجة (pipeline) من تصنيفه، ويتم استبعاده من كل استعلام افتراضي.

يجب أن تأتي الحالة من نظام السجلات كلما أمكن ذلك. نظام إدارة المستندات الذي يحتوي على سير عمل للموافقة يعرف الإجابة بالفعل. التخمين من اسم الملف هو الملاذ الأخير.

4. التسلسل: من أين جاءت

المستندات الطويلة تُقسم إلى مقاطع. المقطع 42 من اتفاقية خدمات مكونة من 100 صفحة لا يعني الكثير بدون سياق.

قم بتخزين parent_doc_id، chunk_index، section_title، و source_uri. هذه تمنحك ثلاثة أشياء: استشهادات يمكن للقارئ التحقق منها ("القسم 4.2، اتفاقية الخدمات الرئيسية"). القدرة على جلب المقاطع المجاورة عندما يتم قطع فقرة في منتصف الجملة. ورابط للعودة إلى الملف الأصلي.

قم أيضاً بتخزين version، ingested_at، و extractor_version. عندما تقوم بتحسين منطق الاستخراج، تخبرك هذه الحقول بالضبط أي المقاطع تمت معالجتها بواسطة الإصدار القديم وتحتاج إلى إعادة معالجة.

المخطط كجدول قرارات

الحقل	ما يمنعه	من أين تأتي القيمة	قاعدة الاستعلام الافتراضية
`effective_date`, `expiration_date`	الاستشهاد بسياسة أو تسعير منتهي	ترويسة المستند، بيانات العقد الوصفية، أو الاستخراج	effective ≤ اليوم، و expiration فارغ أو > اليوم
`superseded_by`	نسختان تجيبان في نفس الوقت	سجل الإصدارات في النظام المصدر	استبعاد إذا كان معيناً
`allowed_groups`	وصول نص سري للمستخدم الخطأ	صلاحيات النظام المصدر، متزامنة بجدول زمني	يجب أن تتقاطع مع مجموعات المستخدم؛ فارغ يعني الرفض
`status`	معاملة المسودات كسياسة	سير عمل الموافقة، ثم القواعد، ثم الاستخراج	`approved` فقط
`document_type`	إجابة من نوع مستند خاطئ	المجلد، القالب أو المصنف	اختياري، يُعين حسب حالة الاستخدام
`parent_doc_id`, `chunk_index`, `section_title`, `source_uri`	إجابات غير قابلة للتحقق، سياق مكسور	خط المعالجة (pipeline)	لا تتم فلترته؛ يُستخدم للاستشهادات
`version`, `ingested_at`, `extractor_version`	بيانات قديمة صامتة بعد تغييرات خط المعالجة	خط المعالجة	لا تتم فلترته؛ يُستخدم للصيانة

مثال توضيحي للبيانات (payload) لمقطع واحد:

</>View technical implementation · عرض التفاصيل التقنية

{
  "chunk_id": "chk_8f72b9a1",
  "parent_doc_id": "doc_449102",
  "text": "All vendor wire transfers above the policy threshold require secondary approval from the VP of Finance.",
  "metadata": {
    "document_type": "policy",
    "section_title": "Financial Controls",
    "status": "approved",
    "effective_date": "2026-01-01",
    "expiration_date": null,
    "superseded_by": null,
    "allowed_groups": ["grp_finance", "grp_exec"],
    "chunk_index": 14,
    "source_uri": "dms://policies/finance/wire-transfers",
    "version": 3,
    "extractor_version": "2026.07"
  }
}

حافظ على خفة البيانات: توثق Pinecone حداً أقصى يبلغ 40 كيلوبايت من البيانات الوصفية القابلة للفلترة لكل متجه.

تحدي الفلترة الذي تتجاهله معظم الأدلة

تستخدم قواعد بيانات المتجهات فهرساً يسمى HNSW للبحث في ملايين المتجهات بسرعة. فكر فيه كشبكة طرق تربط المقاطع المتشابهة. البحث يمشي في الطرق نحو سؤالك.

الفلاتر تعقد هذا المشي. عندما يستبعد الفلتر معظم المقاطع، فإن العديد من الطرق تؤدي إلى أماكن محظورة. تتعامل المحركات مع هذا بشكل مختلف.

▸بعضها يطبق الفلتر بعد البحث. الفلتر الانتقائي جداً، مثل مجموعة وصول لقسم صغير، قد يعيد نتائج أقل مما طلبت. تاريخياً، تصرف فهرس HNSW في pgvector بهذه الطريقة. ينص ملف README الخاص به على أن الفلترة تُطبق بعد مسح الفهرس، وأن الشرط الذي يطابق 10% من الصفوف يعيد حوالي 4 صفوف عند الإعداد الافتراضي hnsw.ef_search البالغ 40. أضاف الإصدار 0.8.0 المسح التكراري للفهرس (hnsw.iterative_scan) للتعويض، لكن يجب عليك تشغيله وضبطه.
▸بعضها يطبق الفلتر أثناء المشي. هذا يحافظ على صحة عدد النتائج، لكن الشبكة قد تتجزأ وينخفض معدل الاستدعاء (recall). تعالج Qdrant هذا باستخدام فهارس البيانات (payload indexes) التي تضيف حواف رسم بياني إضافية للقيم المفهرسة، ويتحول المخطط الخاص بها إلى مسح كامل عندما يطابق الفلتر نقاطاً قليلة جداً.

كيفية تعامل pgvector و Qdrant مع الفلاتر الانتقائية عند 10 ملايين متجه هو قرار بحد ذاته، مع حسابات الذاكرة التي تصاحبه.

النتيجة على مستوى الأعمال هي فشل صامت. لا توجد أخطاء. الإجابات تصبح أضعف فقط للمستخدمين الذين لديهم أضيق الصلاحيات.

ثلاثة ضوابط تغطي ذلك. قم بإنشاء فهرس بيانات (payload index) على كل حقل تقوم بالفلترة بناءً عليه. اختبر جودة الاسترجاع باستخدام الفلاتر الحقيقية الأكثر انتقائية، وليس فقط باستخدام حساب مسؤول يرى كل شيء. إذا كان أحد المستأجرين (tenant) أو الأقسام يمثل حدوداً صغيرة وصلبة، فامنحه قسماً (partition) أو مجموعة (collection) خاصة به بدلاً من الفلتر.

ترتيب الاسترجاع الفعال

مع وجود الحقول في مكانها، يتم الاسترجاع في تسلسل ثابت.

▸الفلترة (Filter). تطبيق الحالة، التواريخ، والوصول كشروط صارمة.
▸البحث المتجهي (Vector search) داخل المجموعة المفلترة، للبحث عن المعنى.
▸البحث بالكلمات المفتاحية (BM25) داخل نفس المجموعة. غالباً ما تفوت التضمينات (embeddings) أرقام القطع، والاختصارات، ومراجع البنود. البحث بالكلمات المفتاحية يلتقطها.
▸الدمج (Fuse) لقائمتي النتائج، ثم إعادة ترتيب (rerank) أفضل المرشحين.
▸التوسيع (Expand) باستخدام حقول التسلسل: جلب المقاطع المجاورة وإرفاق الاستشهادات.

الترتيب مهم. الفلترة في النهاية تعني أنه قد تم بالفعل تقديم نص للنموذج لم يكن ينبغي له رؤيته أبداً.

تكلفة الإفراط في الجلب (Over-fetching)

بدون فلاتر، تعوض الفرق ذلك باسترجاع المزيد من المقاطع على أمل أن يكون المقطع الصحيح من بينها. أنت تدفع مقابل كل رمز (token) إضافي، في كل استعلام.

استخدم أرقامك الخاصة:

الهدر السنوي = الاستعلامات يومياً × الرموز الزائدة لكل استعلام × السعر لكل مليون رمز إدخال ÷ 1,000,000 × 365

كمثال توضيحي فقط: 5,000 استعلام يومياً، 4,000 رمز زائد لكل منها، بسعر 3 دولارات لكل مليون رمز إدخال، يصل إلى حوالي 21,900 دولار سنوياً. استبدل هذه الأرقام بحجم عملك والسعر الحالي للنموذج الخاص بك.

التكلفة الأكبر هي الجودة. أعطِ النموذج حدود 2021 و 2026 جنباً إلى جنب، وقد يختار الحد الخاطئ أو يمزج بينهما. الأبحاث المنشورة حول السياقات الطويلة، بما في ذلك دراسة "Lost in the Middle" بواسطة Liu وزملائه، وجدت أن النماذج تستخدم المعلومات المدفونة في منتصف السياق بشكل أقل موثوقية. إدخال المزيد من النصوص لا يعني الحصول على إجابات أفضل.

تحديث البيانات الوصفية (Backfilling) على فهرس موجود

معظم الفرق التي تقرأ هذا لديها بالفعل فهرس ممتلئ ببيانات وصفية ضعيفة. نادراً ما تحتاج إلى البدء من جديد. لكنك تحتاج إلى عملية تحديث (backfill) منضبطة.

▸جرد ما تعرفه الأنظمة المصدرية بالفعل. أنظمة إدارة المستندات، ومكتبات SharePoint، وأدوات العقود تحتفظ بالتواريخ، والمالكين، وحالات الموافقة، والصلاحيات. اسحب هذه أولاً. إنها أدق القيم التي ستحصل عليها.
▸تطبيق القواعد تالياً. مسارات المجلدات، والقوالب، وأنماط أسماء الملفات تحل جزءاً كبيراً من أنواع المستندات وبعض الحالات. القواعد غير مكلفة وقابلة للتدقيق.
▸استخدام استخراج النموذج لما يتبقى. اطلب من النموذج ملء مخطط JSON ثابت من نص المستند، مع قيمة ثقة لكل حقل. تعامل مع مخرجاته كاقتراح، وليس كحقيقة.
▸توجيه المستندات ذات الثقة المنخفضة للأشخاص. أي شيء أقل من الحد الأدنى الخاص بك يحصل على status: unverified ويذهب إلى طابور مراجعة بشري. المستندات غير المتحقق منها تبقى خارج النتائج الافتراضية.
▸تحديث البيانات (payloads)، وليس المتجهات. البيانات الوصفية تجلس بجانب التضمين (embedding). يمكنك إرفاقها دون إعادة التضمين، مما يوفر الوقت والتكلفة. في Qdrant هذا تحديث للبيانات. في pgvector هو تحديث عمود عادي. في Elasticsearch، تغير واجهة برمجة تطبيقات Update by query كل مستند يطابق استعلاماً، في دفعات تمرير (scroll batches) من 1,000 افتراضياً.
▸بناء الفهارس، ثم الاختبار قبل التشغيل. قم بتشغيل مجموعة التقييم الخاصة بك مع إيقاف تشغيل الفلاتر وتشغيلها. قارن الإجابات، خاصة للمستخدمين المقيدين. ثم اجعل الفلاتر هي الافتراضية.
▸الحفاظ على تحديثها. قم بجدولة مزامنة الصلاحيات وإعادة تشغيل الاستخراج عندما تتغير المستندات. المخطط الذي كان صحيحاً عند الإطلاق ينحرف في غضون أشهر بدون ذلك.

ضع قاعدة واحدة مبكراً: بالنسبة للوصول، اجعل الفشل مغلقاً (fail closed). المستند ذو الصلاحيات غير المعروفة يكون مخفياً حتى يقوم شخص ما بحل المشكلة. التاريخ المفقود هو إزعاج. الصلاحية المفقودة هي اختراق.

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

هل نحتاج إلى إعادة تضمين مستنداتنا لإضافة مخطط جديد؟ غالباً لا. التضمينات تصف النص، والنص لم يتغير. أنت تعيد معالجة المستندات المصدرية لاستخراج البيانات الوصفية، ثم ترفقها بالمتجهات الموجودة كتحديث للبيانات (payload) أو تحديث للعمود. تصبح إعادة التضمين ضرورية فقط إذا قمت أيضاً بتغيير كيفية تقسيم المستندات (chunking) أو قمت بتبديل نماذج التضمين.

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

لماذا لا نتخطى البيانات الوصفية ونستخدم نموذجاً بنافذة سياق كبيرة جداً؟ لأنك تدفع مقابل كل رمز (token) في كل استعلام، والدقة لا تتحسن مع الحجم. النافذة الكبيرة لا تزال تحتفظ بالسياسة المنتهية بجانب السياسة الحالية، ولا يزال على النموذج أن يخمن. كما أنها لا تفعل شيئاً للتحكم في الوصول: النص السري في السياق مكشوف بالفعل. الفلترة تقرر ما يُسمح للنموذج برؤيته. حجم السياق يقرر فقط مقدار ما يمكنه استيعابه.

أنظمة المعرفة للشركات →

بحث خاص في مستنداتك الخاصة مع استشهادات على مستوى الصفحة، متوفر محلياً (on-premise) إذا تطلبت سيادة البيانات ذلك. تكلفة ثابتة من 8 آلاف إلى 45 ألف دولار، من 6 إلى 8 أسابيع.

إذا كنت تدير بالفعل مشروع RAG تجريبي يستشهد بالنسخة الخاطئة أو يتجاهل الصلاحيات، فتحقق من المخطط قبل تغيير النموذج. هذا الأسبوع، اختر عشرة مستندات لها نسخة أحدث في مكان ما في محرك الأقراص، واسأل النظام عن كل منها. احسب كم عدد الإجابات التي تأتي من النسخة القديمة. يقوم تدقيق الذكاء الاصطناعي (AI Audit) الخاص بنا بمراجعة مسار الاستيعاب والبيانات الوصفية والاسترجاع مقابل 2,500 دولار بتكلفة ثابتة، مع قائمة مكتوبة بما يجب إصلاحه أولاً.

→ نظام RAG للبروتوكولات السريرية محلياً (On-Prem): البنية التحتية لمستشفيات الخليج → تقنية RAG لشركات المحاماة: استشهادات بمستوى أرقام Bates، وحواجز أخلاقية، ومتى يكون الاستضافة المحلية On-Prem مجدياً → مقارنة بين Qdrant و pgvector و Pinecone عند أكثر من 10 ملايين متجه: الذاكرة، الفلترة، ومتى يجب الانتقال

الخدمات ذات الصلة

Enterprise RAG Engines