RAG في الإنتاج: لماذا يستغرق الاسترجاع وقتًا طويلاً_
العقبات التي تؤثر فعليًا على أنظمة RAG الإنتاجية، من التجزئة وحركة المرور عبر المناطق إلى إعادة الترتيب والفهارس غير المحدثة.
معظم عروض RAG السريعة تتجنب الأجزاء التي تجعل الاسترجاع في الإنتاج مكلفًا.
مجموعة البيانات صغيرة. فقاعات البيانات نظيفة. استدعاء التضمين قريب. فهرس المتجهات دافئ. لا توجد مرشحات أذونات، ولا مرحلة إعادة ترتيب، ولا حاجة لشرح سبب اختيار نتيجة معينة.
الأنظمة الحقيقية أبطأ لأن الاسترجاع ليس خطوة واحدة. إنها خط أنابيب.
ميزانية الكمون ليست مجرد بحث عن المتجهات
عندما يسأل المستخدم سؤالًا، غالبًا ما تشمل عملية استرجاع الإنتاج:
- تطبيع الاستعلام
- توليد التضمين
- تصفية البيانات الوصفية
- البحث عن المتجهات
- البحث اللغوي
- إعادة الترتيب
- تجميع التعليمات
- استدعاء النموذج النهائي
غالبًا ما تلقي الفرق اللوم على قاعدة بيانات المتجهات لأنها العنصر الأكثر وضوحًا. في الواقع، غالبًا ما يكون الجزء الأكثر بطئًا في مكان آخر.
حركة المرور عبر المناطق هي مثال شائع. إذا كانت تطبيقك يعمل في منطقة واحدة، وكان موفر التضمين في منطقة أخرى، وكانت قاعدة المتجهات في منطقة ثالثة، قد يبدو النظام بطيئاً حتى عندما يكون كل عنصر فردي "سريعاً" في عزلة.
جودة التجزئة تحدد جودة الاسترجاع
الكتل السيئة تنتج استرجاعًا سيئًا.
سيقوم مقسم ثابت العرض بشكل ساذج بتجزئة العناوين، وكتل الكود، والجداول، والفقرات دون فهم أي منها. الف embeddings الناتجة صحيحة تقنيًا وضعيفة دلاليًا.
إذا كانت المحتويات منظمة، قم بالتجزئة مع الهيكل:
- احترم عناوين Markdown
- احتفظ بكتل الكود كما هي
- احفظ عناوين الأقسام مع محتوياتها
- احتفظ بالبيانات الوصفية مثل معرف الوثيقة، ومسار القسم، واللغة، ونطاق الوصول
لا تحتاج إلى مقسم مثالي. أنت بحاجة إلى واحد يتجنب كسر معنى المادة المصدر بوضوح.
الاسترجاع الهجين هو في الغالب الافتراضية الأفضل
الاسترجاع الكثيف جيد في التشابه الدلالي. الاسترجاع اللفظي جيد في المصطلحات الدقيقة، والمعرفات، وأسماء الملفات، وأكواد الخطأ، وأسماء المنتجات.
تحتاج الأنظمة الإنتاجية عادةً إلى كليهما.
شكل عملي يبدو هكذا:
type RetrievalResult = {
id: string;
score: number;
source: "dense" | "lexical";
};
async function retrieve(query: string) {
const [dense, lexical] = await Promise.all([
vectorIndex.search(query),
bm25Index.search(query),
]);
return mergeAndDedupe([...dense, ...lexical]);
}
هذا لا يجعل النظام أبسط، ولكنه عادةً ما يجعله أكثر موثوقية.
إعادة الترتيب مكلفة وغالبًا ما تكون تستحق العناء
تعمل الفهارس القريبة تقريبًا على تحسين السرعة، وليس الترتيب المثالي. هذا مقبول لمرحلة توليد المرشحين. غالبًا ما لا يكون كافيًا لمرحلة الإجابة النهائية.
تحسن إعادة الترتيب الدقة من خلال أخذ مجموعة مرشحة أصغر وتسجيل كل نتيجة مقابل الاستعلام الفعلي باستخدام نموذج أقوى.
التجارة المتبادلة واضحة:
- تحسين الملاءمة
- المزيد من الكمون
- المزيد من التكلفة
لهذا السبب تنتمي إعادة الترتيب بعد الاسترجاع، وليس قبله. دع النظام السريع يجد المرشحين. دع النظام الأبطأ يتحسن في تنقيحهم.
الجديد هو مشكلة أنظمة
تعتبر الكثير من إحباطات RAG في الواقع مشكلة فهرسة.
يتغير مصدر الحقيقة، ولكن فهرس الاسترجاع يتأخر. ثم يحصل المستخدم على إجابة من كتل قديمة وتلقي الفريق اللوم على نموذج اللغة.
عامل الفهرسة كخط أنابيب خاص به:
- التقط تغييرات الوثيقة
- قم بإدراج عمل إعادة التضمين في قائمة الانتظار
- أدخل الكتل الجديدة
- قم بإزالة أو وضع علامات على الكتل القديمة
- تتبع إصدار الفهرس أو مراجعة الوثيقة
إذا تخطيت هذا، فلن يكون لديك نظام استرجاع. لديك لقطة.
المرشحات تغير شكل المشكلة
البحث المؤسسي نادرًا ما يعني "البحث عن كل شيء". عادةً ما يعني "البحث فقط عما يُسمح لهذا المستخدم برؤيته".
هذا يعني أن تصميم البيانات الوصفية مهم تقريبًا مثل جودة التضمين.
يجب أن تحمل الكتلة عادة ما يكفي من البيانات الوصفية لدعم:
- عزلة المستأجر
- مرشحات نوع الوثيقة
- مرشحات نظام المصدر
- نوافذ التحديث
- استرجاع يدرك الأذونات
هذا أيضًا حيث تصبح بعض معايير قواعد بيانات المتجهات أقل فائدة. لا تبدو المعايير بدون مرشحات حقيقية وقيود الوصول مثل عبء عمل إنتاج.
وضع إنتاجي أفضل
إذا شعرت أن ميزة RAG لديك بطيئة، تحقق من هذه الأمور قبل إلقاء اللوم على التضمينات:
- هل الخدمات في نفس المنطقة؟
- هل تقوم بجلب مرشحين أكثر من اللازم؟
- هل تقوم بإعادة ترتيب عدد كبير جدًا من الكتل؟
- هل الكتل سليمة هيكليًا؟
- هل الفهرس مُحدث؟
- هل يتم فرض الأذونات في طبقة الاسترجاع؟
جودة RAG ليست مجرد جودة نموذج. إنها هندسة الاسترجاع.
مزيد من القراءة
مقالات ذات صلة.
تابع القراءة مع مقالات مرتبطة عن هندسة البرمجيات والمعمارية ومقايضات التنفيذ.
تغيير توليد الشيفرة بواسطة الذكاء الاصطناعي للعمل أكثر مما يزيل المهندس
تعد نماذج اللغة الكبيرة هي الأقوى في التسريع والبنية التحتية. ولا تزال أضعف في الحكم والهندسة والمسؤولية عن عواقب الإنتاج.
تحسين واجهة المستخدم التوليدية عندما تختار النماذج المكونات، وليس النص فقط
تصبح الواجهات المدفوعة بنماذج اللغة الكبيرة أكثر فائدة عندما تساعد في اختيار أو تكوين مكونات واجهة مستخدم موثوقة بدلاً من الرد دائماً بفقرات.