Software Engineering22 يناير 20268 min read

التوليد المعزز بالاسترجاع (RAG)، شرح موجه للمطورين

RAG هو الأسلوب الذي يجعل نموذج اللغة يجيب انطلاقا من بياناتك بدلا من التخمين. يستعرض هذا الدليل مسار المعالجة، والمفاضلات، والأجزاء التي تخطئ فيها الفرق.

بقلم Innovation T Team


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

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

ما هو RAG ولماذا يتفوق على الضبط الدقيق (fine tuning) في معظم الحالات

الحلقة الأساسية قصيرة. عندما يطرح المستخدم سؤالا، تحول ذلك السؤال إلى متجه، وتبحث في مخزن من محتواك الخاص عن أكثر المقاطع صلة، ثم تحقن تلك المقاطع في التوجيه (prompt) بوصفها سياقا. عندئذ يجيب النموذج باستخدام ما استرجعته بدلا من التخمين من ذاكرته البارامترية.

كثيرا ما يلجأ الناس إلى الضبط الدقيق أولا، لكنه في العادة الأداة الخطأ عندما يتعلق الأمر بإرساء النموذج على الحقائق. الضبط الدقيق يعلّم الأسلوب والنبرة والتنسيق. أما RAG فيعلّم المعرفة المتغيرة. تأمل الفرق:

  • الضبط الدقيق يدمج المعلومة في الأوزان. وتحديث حقيقة واحدة يعني إعادة التدريب أو تشغيل مهمة ضبط أخرى.
  • RAG يبقي المعرفة في قاعدة بيانات يمكنك تحديثها في ثوان. غيّر وثيقة، وأعد فهرستها، فتعكس الإجابة التالية التغيير.
  • RAG يمنحك استشهادات. يمكنك عرض المقطع المصدر، ما يعزز الثقة ويسهل اكتشاف الهلوسات.

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

مسار المعالجة، مرحلة بمرحلة

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

1. الاستيعاب والتقسيم إلى مقاطع

لا يمكنك تضمين ملف PDF من 40 صفحة بوصفه متجها واحدا وتتوقع استرجاعا دقيقا. أنت تقسم الوثائق إلى مقاطع (chunks)، وطريقة تقسيمها تهم أكثر من أي شيء آخر تقريبا.

التقسيم بحجم ثابت (لنقل 500 إلى 800 token مع تداخل بنسبة 10 إلى 15 بالمئة) قيمة افتراضية مقبولة. لكن التقسيم الساذج يقطع الجمل في منتصفها ويفصل العنوان عن الجدول الذي يصفه. تأتي النتائج الأفضل من تقسيم واع بالبنية يحترم عناوين markdown والفقرات وكتل الشيفرة وحدود القوائم. من واقع خبرتنا، غالبا ما يكون الانتقال من التقسيم المستند إلى الأحرف إلى التقسيم الواعي بالبنية أكبر مكسب مفرد في الجودة ضمن بناء RAG مبكر، متقدما على أي ترقية للنموذج.

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

2. التضمينات (Embeddings)

يحوّل نموذج التضمين النص إلى متجه بحيث تحط المعاني المتشابهة قريبة بعضها من بعض في الفضاء المتجهي. ويتلخص اختياره في بضع مفاضلات:

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

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

3. التخزين والبحث المتجهيان

تقيم التضمينات في فهرس متجهي يدعم البحث عن الجار الأقرب التقريبي. خياراتك الواقعية في 2026:

  • Postgres مع pgvector إن كنت تشغّل Postgres أصلا وتريد قاعدة بيانات واحدة تديرها. إنها القيمة الافتراضية العملية لمعظم الفرق.
  • قاعدة بيانات متجهية مخصصة مثل تلك المبنية حول فهارس HNSW حين تحتاج إلى التوسع والبحث الهجين وترشيح البيانات الوصفية جاهزة من الصندوق.
  • خدمة بحث مُدارة إن أردت الاسترجاع بوصفه API ولم ترغب في تشغيل بنية تحتية.

النصيحة الصادقة: لا تندفع إلى الخيار الأكثر غرابة أولا. تتعامل نسخة Postgres واحدة مع pgvector مع ملايين المقاطع بأريحية وتوفر عليك نظاما كاملا لصيانته.

4. الاسترجاع والبحث الهجين وإعادة الترتيب

البحث المتجهي الصرف قوي في المعنى وضعيف في المصطلحات الدقيقة. فقد يفوته رمز خطأ محدد، أو رقم منتج (SKU)، أو اسم عائلة، لأن هذه الرموز تحمل إشارة دلالية ضئيلة. العلاج هو البحث الهجين: دمج التشابه المتجهي مع البحث الكلاسيكي بالكلمات المفتاحية (BM25) وصهر النتائج.

ثم أضف مُعيد ترتيب (reranker). يسترجع تمريرك الأول 20 إلى 50 مرشحا بكلفة زهيدة. يقرأ مُعيد ترتيب من نوع cross encoder الاستعلام وكل مرشح معا ويعيد ترتيبها بحسب الصلة الحقيقية، بحيث تكون الخمسة الأولى التي ترسلها إلى النموذج هي الأفضل خمسة، لا مجرد أقرب المتجهات. هذا النمط ذو المرحلتين، الاسترجاع ثم إعادة الترتيب، من أعلى الترقيات مردودا التي يمكنك إجراؤها، وهو يتناغم طبيعيا مع انضباط تصميم API الذي نتناوله في تصميم واجهات API يحبها المطورون.

5. التوليد

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

التقييم، أو كيف تعرف أنه يعمل

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

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

جودة التوليد تسأل عما إذا كانت الإجابة أمينة للسياق المسترجع وعما إذا كانت تعالج السؤال فعلا. الأمانة تلتقط الهلوسة: ادعاءات لا تسندها المقاطع. وصلة الإجابة تلتقط انحراف النموذج عن الموضوع.

فيما يلي قائمة تحقق نستخدمها عند إرساء التقييم لنظام RAG جديد:

  1. ابنِ مجموعة مرجعية (golden set) من 50 إلى 100 سؤال حقيقي بإجابات صحيحة معروفة ومقاطع مصدرية.
  2. قِس استدعاء الاسترجاع ودقته بمعزل عن جودة الإجابة، كي تعرف أي مرحلة تصلح.
  3. استخدم LLM قاضيا للأمانة والصلة، لكن دقّق أحكامه بالمعاينة مقابل مراجعة بشرية.
  4. أضف حالات خصامية: أسئلة بلا إجابة في المدونة النصية، وصياغات غامضة، ووثائق شبه مكررة.
  5. أعد تشغيل المجموعة كاملة عند كل تغيير في التقسيم أو التضمينات أو التوجيهات أو النموذج.
  6. راقب استعلامات الإنتاج بحثا عن أسئلة لا تسترجع شيئا مفيدا وأعد إدخالها في المجموعة المرجعية.

عامل هذه الأرقام كما تعامل سرعة الصفحة. فالتراجعات الصغيرة تتراكم، وتنطبق العقلية نفسها المدفوعة ببيانات الميدان من دليلنا الميداني لمؤشرات Core Web Vitals: قِس الاستخدام الحقيقي، لا المسار المثالي وحده.

المفاضلات التي لا يحذرك منها أحد

بضعة قرارات تشكّل الكلفة والكمون والثقة أكثر من الإطار (framework) الذي تختاره.

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

كيف يمكن لـ Innovation T المساعدة

RAG سهل النمذجة الأولية وصعب فعلا أن تجعله موثوقا وسريعا وآمنا على نطاق واسع. تلك الفجوة بين عرض توضيحي عامل ونظام يمكنك وضعه أمام العملاء هي بالضبط حيث نعمل.

نساعد الفرق على تصميم استراتيجية الاستيعاب والتقسيم لوثائقها الحقيقية، واختيار تضمين وتخزين متجهي يناسبان نطاقها وميزانيتها، وبناء استرجاع هجين مع إعادة ترتيب يعيد السياق الصحيح بدلا من المجرد المتشابه. ندمج التقييم منذ اليوم الأول كي تكون الجودة رقما يمكنك تتبعه، ونتولى الأجزاء غير البراقة التي تهم في الإنتاج: الاسترجاع الواعي بالصلاحيات، والمراقبة، والتخزين المؤقت، وضبط الكلفة عبر بيئتك السحابية. وإن كنت توازن البنية الأوسع حول نظام كهذا، فإن أفكارنا حول اختيار حزمة تقنية للـ SaaS في 2026 تتلاءم جيدا مع بناء RAG.

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

#RAG#LLM#البحث المتجهي#الذكاء الاصطناعي

جاهز للبناء مع Innovation T؟

سواء كان الأمر يتعلق بالأمن أو النمو أو الهندسة، يمكن لفريقنا مساعدتك على تنفيذه بإتقان.