لقد قمت ببناء بوت للأسئلة والأجوبة البرمجية باستخدام RAG: ما الذي نجح وما الذي فشل
أمضى مطورونا أياماً في البحث عبر Slack والوثائق القديمة لفهم الخدمات المصغرة (microservices) الخاصة بنا. لذا قررت بناء روبوت دردشة للإجابة على هذه الأسئلة باستخدام تقنية RAG.
لقد ارتكبتُ العديد من الأخطاء خلال هذه الرحلة. إليكم ما تعلمته.
الإخفاقات
- حاولتُ وضع جميع الوثائق في مطالبة (prompt) واحدة. أدى ذلك إلى تجاوز حدود الرموز (token limits)، وتسبب في حدوث هلوسات (hallucinations)، وكلف الكثير من المال.
- استخدمتُ فهرس TF-IDF بسيطاً. وقد فشل عندما استخدم المستخدمون مرادفات أو مصطلحات مختلفة.
- حاولتُ استخدام تقسيمات (chunks) بسيطة بطول 500 حرف. كانت النتائج عشوائية لأن التقسيمات كانت غالباً ما تنقطع في منتصف الجملة.
الحل
توقفتُ عن التعامل مع الـ LLM كمحرك بحث، وحولته إلى محرك قراءة لفهرس بحث مخصص.
إليكم مسار العمل (pipeline) الذي نجح:
- تقسيم الوثائق إلى قطع بحجم 300 رمز (token) مع تداخل (overlap) قدره 50 رمزاً.
- تحويل كل قطعة إلى متجه (vector) عبر عملية الـ embedding.
- تخزين المتجهات في فهرس بحث عن التشابه.
- عند الاستعلام، يتم العثور على أفضل 5 قطع الأكثر تشابهاً.
- تغذية هذه القطع فقط إلى الـ LLM لتوليد الإجابة.
قلل هذا التغيير من الهلوسة بنسبة 80% وخفض التكاليف إلى أقل من 0.01 دولار لكل استعلام.
الدروس المستفادة الرئيسية
- حجم التقسيم (chunk size) أمر حيوي. 150 رمزاً توفر سياقاً قليلاً جداً، و1000 رمز تسبب ضجيجاً كبيراً، أما 300 رمز فهي النقطة المثالية.
- التداخل (overlap) أمر إلزامي؛ فهو يمنع فقدان السياق بين القطع.
- استخدم نماذج صغيرة من أجل السرعة. لقد عمل نموذج embedding صغير بشكل جيد لاحتياجاتنا الداخلية.
- اختبر عملية الاسترجاع (retrieval). لا تعتمد على الفحوصات اليدوية، بل قم ببناء مجموعة اختبار لقياس الدقة.
تقنية RAG ليست سحراً، بل هي لغز هندسي. إذا كانت تقسيماتك سيئة، فسيكون استرجاعك سيئاً. وإذا كان استرجاعك سيئاً، فستكون إجاباتك سيئة.
نحن الآن نجيب على 80% من أسئلة التهيئة (onboarding) بشكل صحيح، وهذا أسرع بكثير من انتظار رد بشري على Slack.
كيف تبني مساعدين يعملون بالذكاء الاصطناعي لتوثيقك البرمجي؟
Optional learning community: https://t.me/GyaanSetuAi