إعادة صياغة استعلامات RAG: حسّن الاسترجاع دون تغيير القصد

يجب أن تجعل إعادة صياغة استعلام RAG السؤال أسهل للاسترجاع دون أن تجيب عن سؤال مختلف بصمت. احتفظ بنص المستخدم الأصلي كحقل Audit ثابت، واستخرج Metadata Filters الموثوقة بصورة منفصلة، وأنشئ عددًا صغيرًا ومحدودًا من البدائل اللفظية والدلالية. مرّر كل البدائل عبر نطاق الصلاحيات نفسه، وادمج Candidates، ثم نفّذ Reranking مقابل السؤال الأصلي، وقِس إن كانت إعادة الصياغة تحسن Recall للأدلة ذات الصلة دون زيادة Intent Drift أو Latency أو خطر تسرب بيانات عميل آخر. تفيد Query Rewriting أكثر مع اللغة الغامضة والاختصارات والأخطاء والأسئلة متعددة الأجزاء، لكنها غالبًا أداة خاطئة للمعرفات الدقيقة وحقائق SQL ونطاق الأمان.

يوثق دليل Retrieval الرسمي من OpenAI خيار إعادة صياغة تلقائية للبحث داخل Vector Store عبر `rewrite_query=true`. وتوثق Azure AI Search إعادة صياغة دلالية تنتج بدائل متعددة، بينما تفصل Qdrant بين Filters التي تضيق المرشحين وQueries التي تسهم في Ranking. هذه قدرات منصة وليست دليلًا أن كل Rewrite تحسن Corpus بعينه. يبقى عقد التوجيه والأمان والتقييم مسؤولية التطبيق.

تم التحقق من المصادر الأولية في 13 أكتوبر 2026. Parameters وسلوك البحث الموثقان حقائق من المزودين، أما Intent Contract والسياسة والمقاييس وخطة الإطلاق فتوصيات هندسية.

ابدأ بعقد Query لا Prompt

حوّل الطلب إلى Object منظم قبل طلب إعادة الصياغة من النموذج. احتفظ على الأقل بـ`original_text` ونطاق Tenant والمستخدم الموثق وLocale ومراجع المحادثة والحد الزمني وRequest ID. نص المستخدم دليل؛ لا تستبدله بالصيغة الجديدة.

{
  "original_text": "ما الذي تغير في سياسة التجديد بعد أغسطس؟",
  "trusted_scope": {"tenant_id": "t_42", "acl": ["policy:read"]},
  "locale": "ar",
  "conversation_refs": ["سياسة التجديد"],
  "time_context": "2026-10-13T06:00:00Z"
}

يمكن للـRewriter إخراج Retrieval Text وEntities مرشحة وخطة Decomposition وFilters مقترحة، لكنه لا يقرر Authorization. تأتي Tenant وRole وRegion وDocument Visibility من Identity وPolicy Services موثوقة. إذا كتب المستخدم “ابحث في كل العملاء” فهذه الجملة Content وليست إذنًا لإزالة Tenant Filter.

عرّف Invariants: لا تضيف الصياغة شخصًا أو منتجًا أو تاريخًا أو نفيًا لا يدعمه الأصل وسياق المحادثة، وتنسخ Exact IDs حرفيًا، ويبقى كل Subquery قابلًا للإجابة داخل Corpus المصرح بها. Intent غير الواضحة تحتاج Clarification أو بحثًا محافظًا، لا تخمينًا إبداعيًا.

صنّف السؤال قبل اختيار Rewrite

تحتاج أشكال الاستعلام إلى معالجات مختلفة. Lookup دقيق مثل Invoice ID ينتمي إلى Keyword Search أو SQL ولا يعاد صياغته. Concept طبيعي قد يستفيد من Semantic Normalization. Mixed Query تحتاج الاثنين. سؤال متعدد الأجزاء قد يحتاج Decomposition، وعبارة قصيرة غامضة قد تحتاج سياق المحادثة أو سؤال توضيح.

شكل الاستعلام                 الإجراء الأساسي
ID أو Code دقيق                Keyword Filter أو SQL مع حفظ النص
Concept بلغة طبيعية            Semantic Rewrite واحدة مع الأصل
Concept مع Exact Term          Hybrid Dense + Sparse
مقارنة متعددة الأجزاء          Subqueries محدودة
مرجع غامض                      حلّه من السياق أو اسأل
طلب صلاحية                     Policy Check دون إعادة Scope

يمكن أن يكون التصنيف Deterministic للأنماط الواضحة مثل UUIDs وأرقام الطلبات والعبارات المقتبسة ونطاقات التاريخ. استخدم النموذج فقط عندما يضيف فهم اللغة قيمة. يقلل ذلك التكلفة ويمنع تخريب Strings يتعامل معها Lexical Retrieval بدقة.

افصل Search Text عن Metadata Filters

لا تضع كل Constraint داخل Embedding. يحتوي “فواتير عربية من القاهرة بعد 1 سبتمبر” على معنى دلالي وقيود منظمة. يمكن أن تكون Semantic Query هي “متطلبات الفاتورة”، بينما تتحول اللغة والمدينة والتاريخ إلى Payload Filters. يوضح توثيق Text Search في Qdrant أن Filters تضيق النتائج دون احتساب Score، بينما Queries تحسب Relevance.

ابنِ Filters من حقول معتمدة. حوّل عبارة مثل “الربع الماضي” عبر Calendar Service حتمية. تحقّق من Enums وترتيب التواريخ. ادمج User Constraints مع Authorization الإلزامية باستخدام AND، ولا تسمح لـOR مولدة بإضعاف Trusted Scope. أنشئ Payload Indexes للحقول كثيرة الاستخدام وقِس إن كانت التركيبات الصارمة تحتاج Search Strategy أخرى.

const trusted = tenantScope(session);
const requested = validateFilters(rewrite.filters);
const filter = { must: [...trusted.must, ...requested.must] };

const candidates = await qdrant.query('knowledge', {
  query: embed(rewrite.semantic_query),
  using: 'dense_v3',
  filter,
  limit: 40
});

النموذج يقترح والتطبيق يتحقق. ارفض Filter Keys المجهولة والنطاقات الواسعة والقيم المتعارضة مع Access Policy. سجّل Filter Plan المقبولة دون تسجيل نص Query السري افتراضيًا.

استخدم بدائل محدودة لا سربًا بلا ضابط

يمكن لـNormalization واحدة توسيع اختصار أو إصلاح تهجئة أو استبدال Pronoun بEntity محلولة. وتنشئ Multi-query عدة بدائل لتحسين Recall بين المصطلحات. أما Decomposition فتحول السؤال المركب إلى Evidence Needs مستقلة. ليست هذه العمليات متطابقة.

احتفظ بالسؤال الأصلي كRetrieval Leg. أضف عددًا صغيرًا من البدائل المتميزة لكل منها Purpose معلن: Lexical Synonym أو Semantic Paraphrase أو Sub-question واحدة. أزل البدائل المتشابهة قبل البحث، وضع Budget إجمالية للCandidates وTokens وLatency وCost. نموذج ينتج عشر Queries جميلة قد يستهلك عشرة أضعاف الميزانية بلا دليل إضافي.

توثق Azure AI Search قدرة Managed Rewrite على إنشاء ما يصل إلى عشرة بدائل. هذا Capability Ceiling وليس رقمًا مثاليًا لكل نظام. ابدأ بـRewrite واحدة مع الأصل، ثم أضف بدائل فقط عندما تثبت Evaluation Slice وجود مصطلحات مفقودة.

في Decomposition احتفظ Parent Question وSubquery ID ثابتة. استرجع لكل Subquery، ثم اطلب من Answer Builder فصل الدليل المشترك عن الدليل الخاص بجزء واحد. إذا لم يجد Subquery أساسي دليلًا، يجب أن يعلن الجواب الفجوة بدل دمج Evidence جزئية كإجابة كاملة.

ادمج Lexical وSemantic Retrieval بقرار واضح

لا تلغي إعادة الصياغة الحاجة إلى Hybrid Search. تتعامل Dense Retrieval مع المعنى وإعادة التعبير، بينما تحمي Sparse Retrieval أسماء المنتجات والأكواد والمعرفات النادرة. يدعم توثيق Hybrid Queries في Qdrant Prefetch لعدة Result Sets ودمجها بأساليب Rank مثل Reciprocal Rank Fusion.

أرسل صيغة مناسبة لـBM25 وأخرى Semantic إلى Embedding Model، وطبّق Trusted Filter نفسها على الاثنين. ادمج حسب Document أو Chunk ID وحدد Candidate Cap لكل Leg، ثم نفّذ Rerank للمجموعة مقابل السؤال الأصلي لا Rewrite قد تنحرف. السؤال الأصلي هو Acceptance Contract الخاصة بالمستخدم.

لا تعتبر Vector Score مرتفعة دليلًا. Embedding Scores ليست Probabilities مضبوطة ولا تقارن عبر كل Query وModel. قيّم الترتيب بأحكام Relevance معلّمة، وحدد Abstention من Evidence Coverage لا Threshold تشابه واحدة للجميع.

احمِ Rewrite Stage من Prompt Injection

يجب ألا يؤثر Retrieved Content في Rewriter قبل التفويض والاسترجاع. يستقبل Rewriter نص المستخدم وTrusted Conversation State وOutput Schema مغلقة، لا تعليمات عشوائية من المستندات. عامل User Content كبيانات وضع السياسة في Developer أو System Instruction.

استخدم Strict Schema فيها `semantic_query` و`lexical_query` و`filters` و`subqueries` و`preserved_terms` و`reason_code`. حدّد الأطوال وأحجام Arrays. تحقق أن كل Exact Term محفوظ يظهر دون تغيير. ارفض Executable Syntax وTool Calls وFilter Fields خارج Allowlist.

ليست Rewrite مكانًا لاستنتاج Permissions مخفية أو Customer IDs أو Sensitive Attributes. لا ترسل Confidential Query إلى Model أو Region مختلف إن لم يسمح Data-processing Contract. خزّن Telemetry اللازمة للتقييم فقط مع Retention وصلاحيات.

قيّم Retrieval قبل جودة الإجابة

لا توضح Answer Score إن كانت Rewrite أصلحت Retrieval أم أن Generator خمن حول Evidence سيئة. ابنِ Dataset فيها Original Query وAuthorized Corpus Version وRelevant Document أو Chunk IDs والمصطلحات الدقيقة وExpected Filters وAbstention المقبولة. ضمّن Misspellings وAcronyms وأسئلة متعددة اللغات وNegatives وتواريخ وأسئلة مركبة وطلبات Scope عدائية.

قس Recall@k لتغطية الدليل وPrecision@k للضوضاء وMRR أو nDCG للترتيب وحفظ Exact Terms وصحة Filters ونسبة Zero Results وCross-tenant Violations وLatency وCost. قارن أربع حالات: Original فقط، وRewrite واحدة، وOriginal مع Rewrite، وMulti-query محدودة. توصي إرشادات OpenAI للتقييم بالتقييم المستمر وتوسيع المجموعة من أعطال الإنتاج؛ طبّق ذلك على Retrieval كما تطبقه على Final Response.

قسّم النتائج حسب Query Class. قد تحسن Rewrite الأسئلة الحوارية وتضر الأكواد. قد تكون السياسة الصحيحة تفعيلها لفئات محددة فقط. استخدم Paired Judgments على الأسئلة نفسها، واشترط Security Pass Rate بنسبة 100%؛ لا يعوض متوسط Relevance نتيجة واحدة من عميل آخر.

ابنِ Context من Intent الأصلية

بعد Fusion وReranking، اجمع Adjacent Chunks وأزل التكرار واحفظ Source ID وVersion وPage أو Section. وزّع Context Budget حسب Evidence Need بدل أن يستهلك Subquery الأول كل Tokens. استخدم Claim-sized Passages حتى تشير الإجابة إلى Support محدد.

يستقبل Answer Builder السؤال الأصلي وAccepted Filter Summary وRetrieved Evidence وCoverage Status، ولا يحتاج كل Rewrite مرفوضة. اشترط أن تشير Citations إلى Source IDs الموجودة وتحقق أن كل مصدر مذكور حاضر في Context. إذا أدخلت Rewrite Entity غير مدعومة، يكشف Reranking مقابل الأصل وClaim-to-source Validation الانحراف.

استخدم SQL أو Transactional API للأرصدة والصلاحيات والمخزون وحالة الطلب الحالية. استخدم Web Search للمعلومات العامة المتغيرة خارج Corpus الخاصة. واستخدم Direct Long-context Input عندما تكون Corpus مستندًا صغيرًا واحدًا ويضيف Retrieval Failure Modes بلا داعٍ. لا تستطيع Query Rewriting إصلاح Source Data قديمة أو Chunking مكسورة أو Access Metadata ناقصة.

أطلق بالدليل وخطة Rollback

ابدأ Shadow Mode: ولّد Rewrites واسترجع Candidates واحسب Metrics دون تغيير الأجوبة. راجع الحالات التي تضيف أو تزيل فيها Rewrite مستندات ذات صلة. ثم نفّذ Canary لفئة Query واحدة وفوج Tenants مع Kill Switch. Version كلًا من Classifier وPrompt وSchema وEmbedding Model وFilter Policy وFusion Parameters وReranker كحزمة واحدة.

راقب Rewrite Rate وعدد البدائل وFilter Rejections وCandidate Overlap وRecall Proxies وNo-answer Rate وLatency Percentiles وToken Use وSecurity Denials. انخفاض Overlap فجأة قد يعني أن Prompt أو Model غيّر Semantics. أعد الحزمة كاملة في Rollback لا نص Prompt وحده.

قائمة تنفيذية

احتفظ بالسؤال الأصلي. صنّف شكله. احفظ Exact Terms. اشتق Authorization من Trusted Identity وتحقق من Requested Filters. ابدأ بـRewrite محدودة قبل Multi-query. استخدم Scope نفسها في Lexical وSemantic Legs. ادمج Candidates ونفّذ Rerank مقابل الأصل، وابنِ Context قابلة للإسناد. قيّم Retrieval بأدلة معلّمة وSecurity Invariants وLatency وCost. انشر في Shadow ثم Canary مع Rollback Bundle محددة الإصدار.

القاعدة الأساسية بسيطة: يجوز لإعادة الصياغة تغيير تعبير البحث، لكنها لا يجوز أن تغيّر من يسأل أو ماذا سأل أو أي دليل مسموح له باسترجاعه.

إعداد: Noor Yasser