النماذج اللغوية الكبيرة فصيحة بشكل لافت، لكن الفصاحة ليست معرفة. فالنموذج المدرَّب على نصوص الإنترنت العامة لا يعرف شيئاً عن عقود شركة معينة، أو كتالوج منتجاتها، أو تاريخ دعمها، أو سياساتها الداخلية. لا يعرف حالة حساب عميل معين، ولا ما تقوله سياسة الاسترجاع هذا الفصل، ولا ما تغيّر في دليل تشغيل داخلي الأسبوع الماضي. ظهر التوليد المعزّز بالاسترجاع، المعروف اختصاراً بـ RAG، كإجابة معيارية على هذه الثغرة: فبدلاً من أن يُطلب من النموذج معرفة كل شيء، تسترجع أنظمة RAG المعلومات ذات الصلة من بيانات المؤسسة الخاصة لحظة طرح السؤال، وتُغذّي تلك المعلومات للنموذج كسياق قبل أن يولّد إجابته.
الجاذبية واضحة — يسمح RAG للفرق بترسيخ إجابات الذكاء الاصطناعي في معلومات حالية وخاصة وقابلة للتحقق دون تكلفة وهشاشة إعادة تدريب النموذج كل مرة تتغير فيها البيانات الأساسية. أما التحدي الهندسي فأقل وضوحاً: نظام RAG هو خط أنابيب بيانات كامل له متطلبات جودة استرجاع وزمن استجابة وصحة يسهل الاستهانة بها عندما يعمل عرض تجريبي بُني في فترة بعد ظهر واحدة بشكل جيد على عدد قليل من الأسئلة المختارة بعناية.
في جوهره، يحتوي نظام RAG على ثلاثة أجزاء متحركة. أولاً، يأخذ خط أنابيب الإدخال المستندات المصدرية — ملفات PDF، وصفحات ويكي، وتذاكر الدعم، وسجلات قواعد البيانات — ويقسّمها إلى أجزاء (chunks)، ثم يحوّل كل جزء إلى تمثيل متجهي (embedding) يلتقط معناه الدلالي، ويخزّن المتجه والنص الأصلي معاً في قاعدة بيانات متجهية أو فهرس بحث يدعم تشابه المتجهات. ثانياً، تأخذ خطوة الاسترجاع سؤال المستخدم الوارد، وتحوّله إلى متجه باستخدام نفس نموذج التمثيل، وتبحث في الفهرس عن الأجزاء الأكثر تشابهاً معه، وتُعيد أفضل المرشحين. ثالثاً، تجمع خطوة التوليد تلك الأجزاء المسترجعة في محث (prompt) إلى جانب السؤال الأصلي وترسل السياق المجمّع إلى نموذج لغوي كبير، الذي يولّد إجابة مرتكزة على المادة المسترجعة بدلاً من الاعتماد بشكل بحت على ما تعلّمه أثناء التدريب.
لكل من هذه المراحل الثلاث أنماط فشل خاصة بها، ونظام RAG بمجمله بجودة أضعف مرحلة فيه. فنموذج لغوي مثالي يُغذّى بأجزاء مسترجعة غير ذات صلة سينتج إجابة خاطئة أو متوهَّمة، لأنه لا طريقة لديه لمعرفة أن الاسترجاع فشل.
كيفية تقسيم المستندات المصدرية إلى أجزاء له تأثير كبير على جودة الاسترجاع، وهو أحد أول القرارات التي تُخطئ فيها الفرق. الأجزاء الكبيرة جداً تُخفّف الإشارة الدلالية للتمثيل المتجهي، لأن جزءاً يغطي خمسة مواضيع غير مرتبطة يُنتج متجهاً هو متوسط باهت لكل تلك المواضيع. الأجزاء الصغيرة جداً تفقد السياق — فجزء جملة عن "الرسوم" دون الفقرة التي تشرح أي رسوم، وبأي شروط، يكون بلا فائدة تقريباً بعد استرجاعه بمفرده.
استراتيجيات التقطيع الفعالة تحترم عادة البنية الطبيعية للمادة المصدرية بدلاً من التقسيم حسب عدد الأحرف. التقسيم حسب العناوين أو الفقرات أو الأقسام المنطقية، مع تضمين قدر صغير من السياق المتداخل بين الأجزاء المتجاورة، يُنتج عادة استرجاعاً أفضل بكثير من التقسيم بطول ثابت. وبالنسبة للمستندات المهيكلة كالعقود أو السياسات، فإن الحفاظ على عناوين الأقسام وتراتبيتها داخل كل جزء يُحسّن بشكل ملموس دقة الاسترجاع وقدرة النموذج على الاستشهاد بمصدره بشكل صحيح.
نموذج التمثيل المتجهي المختار يحدد نوع التشابه الذي يمكن للنظام اكتشافه. تعمل نماذج التمثيل العامة بشكل مقبول للمطابقة الدلالية الواسعة، لكن المفردات الخاصة بمجال معين — المصطلحات القانونية، الرموز الطبية، أسماء المنتجات الداخلية — قد يُمثّلها بشكل ضعيف نموذج مدرَّب في معظمه على نص ويب عام. بعض المؤسسات تضبط بدقة أو تختار نماذج تمثيل مقيَّمة خصيصاً على أزواج الأسئلة والأجوبة الخاصة بمجالها.
للبحث بالتشابه المتجهي البحت نقاط ضعف معروفة أيضاً: فهو جيد في المطابقة الدلالية لكنه قد يفوّت مطابقات كلمات مفتاحية دقيقة تهم، مثل رمز منتج محدد، أو رمز خطأ، أو رقم عقد. لهذا تستخدم كثير من أنظمة RAG في الإنتاج استرجاعاً هجيناً، يجمع بين البحث بالتشابه المتجهي والبحث النصي أو بالكلمات المفتاحية التقليدي ويدمج النتائج. كما أصبحت خطوة إعادة الترتيب، باستخدام نموذج منفصل مدرَّب لتقييم مدى صلة الجزء المسترجع بالاستعلام المحدد، شائعة بشكل متزايد كتمريرة ثانية بعد استرجاع أولي واسع.
نظام RAG المصمم جيداً لا يزيل التوهّم، لكنه يعطي المؤسسة أدوات لاكتشافه والحد منه. توجيه النموذج للإجابة فقط من السياق المسترجع، وقول ذلك بوضوح عندما لا يحتوي السياق على إجابة، يقلّل بشكل ملموس من الإجابات الواثقة ولكن الخاطئة. مطالبة النموذج بالاستشهاد بأي جزء مسترجع يدعم كل زعم — ثم التحقق برمجياً من أن الجزء المستشهد به يحتوي فعلاً على المعلومة المزعومة — يحوّل الاستشهاد من ميزة تجميلية إلى آلية تحقق.
التقييم يستحق استثماراً خاصاً به. الفرق التي تنظر فقط بعينها إلى عدد قليل من أمثلة الإجابات أثناء التطوير تُفاجأ بانتظام بمعدلات فشل بمجرد أن يبدأ المستخدمون الحقيقيون بطرح أسئلة لم يغطها العرض التجريبي أبداً. بناء مجموعة اختبار من الأسئلة التمثيلية مع إجابات صحيحة معروفة، وتشغيلها ضد خط الأنابيب كل مرة تتغير فيها استراتيجية التقطيع أو نموذج التمثيل أو معاملات الاسترجاع، يكشف الانحدارات التي كانت ستظهر فقط كشكاوى مستخدمين في الإنتاج.
على عكس النموذج الثابت، معرفة نظام RAG بقدر حداثة فهرسه فقط، مما يعني أن خط أنابيب الإدخال يحتاج إلى استراتيجية موثوقة لاكتشاف وإعادة فهرسة المستندات المصدرية المتغيرة، وليس فقط تحميلاً أولياً لمرة واحدة. الفهارس القديمة فشل شائع وهادئ: يجيب النظام بثقة بسياسة الفصل الماضي لأن أحداً لم يعد تشغيل الإدخال بعد تغيير السياسة.
التحكم بالوصول مهم بنفس القدر ويُتجاهل بسهولة. إذا كان من المفترض أن يرى مستخدمون مختلفون مستندات معينة فقط، فيجب فرض تلك الحدود عند وقت الاسترجاع، بتصفية الأجزاء التي يُسمح لاستعلام مستخدم معين حتى بالبحث فيها. وفي المنتجات متعددة المستأجرين، ينطبق نفس الانضباط لكل عميل: يجب ألّا تكون مستندات مستأجر واحد قابلة للاسترجاع أبداً استجابة لسؤال مستأجر آخر.
انتشرت قواعد البيانات المتجهية وإضافات البحث المتجهي لقواعد البيانات الموجودة، والاختيار يهم أقل لجودة الاسترجاع الخام وأكثر لكيفية ملاءمة النظام لممارسات المؤسسة التشغيلية القائمة. يجب أن يأخذ تخطيط السعة في الحسبان أن إعادة الفهرسة ليست حدثاً نادراً: فكل مرة تتغير فيها المستندات المصدرية جوهرياً، يحتاج جزء من الفهرس إلى إعادة حساب، وتوليد التمثيلات المتجهية على نطاق واسع له تكلفة حوسبية حقيقية ومستمرة.
تستحق ميزانيات زمن الاستجابة اهتماماً واضحاً مبكراً في التصميم أيضاً. استدعاء استرجاع يضيف ثلاثمائة ميلي ثانية قبل أن يبدأ النموذج اللغوي حتى في التوليد سيُلاحَظ من كل مستخدم لواجهة على طراز المحادثة.
بسبب اعتماد سلوك نظام RAG على فهرس استرجاع ونموذج توليدي معاً، لا تكفي المراقبة القياسية للتطبيقات وحدها. تحتاج الفرق إلى رؤية أي الأجزاء استُرجعت لاستعلام معين، ومدى صلتها الفعلية، وهل كانت الإجابة النهائية مرتكزة عليها أم انحرفت عنها. تسجيل معرّفات الأجزاء المسترجعة مع كل إجابة مولّدة، حتى عندما لا يبدو أن شيئاً خاطئاً، يجعل من الممكن التحقيق في إجابة سيئة بعد وقوعها بدلاً من التخمين فقط.
إشارات ملاحظات المستخدمين — تصويت سلبي، سؤال متابعة يعيد صياغة السؤال الأصلي، تصعيد إلى وكيل بشري — بيانات تدريب قيّمة لتحسين النظام، لكن فقط إذا جُمعت وأُعيد توجيهها إلى الفرق التي تحافظ على خط أنابيب الاسترجاع.
تدور إدارة التكلفة تكميلاً للصورة التشغيلية. لكل استدعاء استرجاع وكل استدعاء توليد تكلفة هامشية، وواجهة محادثة نشطة تعيد الاسترجاع في كل دورة متابعة قد تتراكم تكلفتها أسرع بكثير مما يقترحه تبادل سؤال وجواب واحد. تخزين الأجزاء المسترجعة بشكل متكرر مؤقتاً، وتلخيص تاريخ محادثة طويل قبل إعادة تمثيله، وضبط حدود معقولة لعدد الأجزاء التي تُمرَّر إلى نافذة سياق النموذج، كلها وسائل عملية للحفاظ على استدامة نشر RAG في الإنتاج مالياً مع نمو الاستخدام.
أرادت شركة برمجيات أن يجيب روبوت الدعم التابع لها على أسئلة العملاء باستخدام مقالات مركز المساعدة، وملاحظات الإصدار، وأدلة استكشاف الأخطاء الداخلية. أدمج نموذج أولي مقالات كاملة كأجزاء مفردة وأعاد إجابات واثقة ولكن خاطئة بشكل متكرر، لأن مقالة واحدة من 1500 كلمة كانت تغطي غالباً عدة سيناريوهات استكشاف أخطاء غير مرتبطة في متجه واحد.
أعاد الفريق بناء الإدخال ليقسّم المقالات حسب العنوان، محافظاً على كل جزء يمثّل سيناريو استكشاف أخطاء واحداً مكتملاً بذاته مع عنوان المقالة وعنوان القسم كبيانات وصفية. أضافوا استرجاعاً هجيناً بحيث عندما يكتب عميل رمز خطأ دقيقاً، يظهر مكوّن المطابقة بالكلمات المفتاحية الجزء الصحيح بثقة حتى عندما تكون المطابقة الدلالية ضعيفة. أضافوا أيضاً خطوة تحقق من الاستشهاد: قبل إعادة إجابة، تحقق النظام أن خطوة استكشاف الأخطاء المحددة التي ولّدها تظهر فعلاً في الجزء المسترجع الذي استشهد به. انخفض حجم تذاكر الدعم للمواضيع المغطاة بشكل ملموس، والأهم أن الفريق استطاع قياس ذلك لأنهم بنوا مجموعة تقييم قبل الإطلاق.
أصبح التوليد المعزّز بالاسترجاع الطريقة الافتراضية لربط النماذج اللغوية الكبيرة ببيانات المؤسسة الخاصة، تحديداً لأنه يتجنب تكلفة وقِدَم إعادة تدريب نموذج بشكل مستمر مع الحفاظ على ترسيخ الإجابات في معلومات حقيقية وحالية. لكن نظام RAG مشروع هندسة بيانات حقيقي، لا غلافاً رقيقاً حول واجهة برمجية لنموذج. استراتيجية التقطيع، واختيار التمثيل المتجهي، والاسترجاع الهجين، والتحقق من الاستشهاد، وإدارة الحداثة، والتحكم بالوصول، يجب هندستها جميعاً بشكل متعمد. الفرق التي تعامل RAG كخط أنابيب مستمر يجب قياسه وتحسينه — بدلاً من تكامل لمرة واحدة — هي التي تجده يصمد عندما يصل المستخدمون الحقيقيون وحجم البيانات الحقيقي والحالات الحدّية الحقيقية.
