كانت لدى Farah Rahman مشكلة مألوفة في Doha: تقرير خطأ من عميل، وخيط Slack عند منتصف الليل، وقاعدة شيفرة تضم 1.8 مليون سطر موزعة عبر 43 مستودعًا. طلبت من وكيل تتبع فشل في عملية دفع. في المحاولة الأولى، استهلكت العملية هذا العدد الكبير من الرموز المميزة لدرجة أن النموذج فقد الخيط. ثم عاد بإجابة صحيحة جزئيًا فقط، لكنها قُدمت بثقة مفرطة.
هذا هو النوع من الفوضى الذي تحاول Semble إصلاحه. ففكرتها - البحث في الشيفرة للوكلاء باستخدام رموز مميزة أقل بنسبة 98% من grep - تبدو، بصراحة، شبه جريئة. لكن خلف هذا العنوان يوجد تحول حقيقي: لم يعد البحث في الشيفرة مجرد إيجاد النص بسرعة. بل صار يتعلق بإطعام الآلات فقط بالجزء الضئيل من المصدر الذي تحتاجه، وبصيغة يمكنها الاستدلال عليها دون استنزاف الميزانية أو السياق.
بصراحة، هذا مهم لأن سير العمل القديم كان مصممًا للبشر الذين يفتشون في النوافذ الطرفية. الوكلاء لا يكتفون بالمسح السريع. إنهم يبتلعون المحتوى. وعندما يكون الاستيعاب سيئًا، تصبح كل خطوة لاحقة أكثر اضطرابًا: توليد التصحيحات، وتحليل السبب الجذري، واختيار الاختبارات، وإصلاح التوثيق، وحتى المراجعة الأمنية.
لماذا يهم هذا الآن
تغير أمران تقريبًا في الوقت نفسه. أولًا، بدأت الفرق تضع LLMs مباشرة في سير العمل الهندسي، من مساعدين داخل IDE إلى روبوتات فرز ذاتية التشغيل. ثانيًا، أصبحت تكلفة السياق واضحة بشكل مؤلم. هل يبدو هذا منطقيًا؟ المطالبات الطويلة ليست فقط مكلفة؛ إنها هشة أيضًا. إذا احتاج وكيل إلى فحص monorepo، فإن بضع خطوات سيئة في الاسترجاع قد تهدر تشغيلًا كاملًا.
وفي الوقت نفسه، تغيرت توقعات البحث. لا يزال المطورون يريدون دقة شبيهة بـ grep، لكن الوكلاء يحتاجون إلى أكثر من مطابقة نصية حرفية. إنهم يحتاجون إلى تضييق دلالي، وتجميع واعٍ بالرموز، وبنية كافية لتجنب الهلوسة من المقاطع غير ذات الصلة. Semble تقع مباشرة في هذه الفجوة.
الفكرة الأساسية: ابحث من أجل النموذج، لا من أجل المهندس فقط
grep التقليدي ممتاز في شيء واحد: مطابقة النص. لكنه أيضًا حرفي إلى حدٍّ قاسٍ. إذا كان الخطأ لديك معبرًا عنه بدالة أعيدت تسميتها، أو ملف مولد، أو رمز يعيش داخل خمس طبقات من الغلافات، فقد يكون grep أعمى ما لم يعرف الإنسان الإبرة الصحيحة التي يجب البحث عنها.
يجب أن يتصرف البحث في الشيفرة للوكلاء بشكل مختلف. ينبغي أن يحول مستودعًا ضخمًا إلى أدلة موجزة وعالية الإشارة. وهذا يعني الترتيب بحسب الاحتمال الأكبر للصلة، وإرجاع البنية المحيطة، وتقليل التكرار والعبارات الجاهزة التي قد يتجاهلها البشر لكن النموذج سيستهلك عليها الرموز المميزة بسعادة.
والنقطة الأعمق هي أن الرموز المميزة أصبحت الآن موردًا هندسيًا نادرًا. ليس بشكل مجازي. بل حرفيًا. كل مقطع ملف إضافي تطعمه للوكيل يمكن أن يغير زمن الاستجابة، والتكلفة، وجودة الإجابة. لهذا السبب، فإن أداة تدعي أنها تستخدم رموزًا مميزة أقل بنسبة 98% من grep تثير الاهتمام: ليس لأن grep سيئ، بل لأن grep لم يُصمم يومًا ليكون خطة غذائية للـ LLM.
عمليًا، يميل النظام الأفضل للبحث في الشيفرة المخصص للوكلاء إلى القيام ببضعة أمور بشكل جيد:
- يفهرس الرموز لا الأسطر فقط. الدوال، والفئات، وعمليات الاستيراد، والمراجع أسهل على الوكلاء تلخيصًا من كتل النص الخام.
- يرتب حسب السياق، لا حسب عدد المطابقات فقط. قد تكون نتيجة واحدة عالية القيمة قرب اختبار فاشل أهم من 27 ظهورًا في وثائق مولدة.
- يضغط بشكل عدواني. عناوين التراخيص المتكررة، والشيفرة المضمنة من طرف ثالث، والقيم الثابتة المكررة لا ينبغي أن تهيمن على المطالبة.
- يعيد مقاطع منظمة. مسار الملف، واسم الرمز، والنطاق، وتلميحات الاعتماد تساعد النموذج على الاستدلال دون إعادة قراءة الشجرة كلها.
- يحافظ على قابلية التتبع. البحث الجيد للوكلاء قابل للتدقيق. يجب أن تتمكن من معرفة سبب اختيار مقطع معين.
- يتكامل بسلاسة مع الأدوات. أفضل طبقة بحث تندمج مع CI، وIDEs، وسير العمل الطرفي بدلًا من أن تفرض طقسًا منفصلًا.
إذا لم يستطع النموذج شرح سبب اختياره لملف ما، فغالبًا لا تثق به بما يكفي لتعديل ذلك الملف.
هناك أيضًا مكسب دقيق على مستوى سهولة الاستخدام. البشر يستخدمون البحث لتحديد الاتجاه. أما الوكلاء فيستخدمون البحث لتوليد الفعل. وهذان ليسا نفس المهمة. يستطيع المطور إلقاء نظرة على 12 نتيجة ضوضائية ومع ذلك يعرف إلى أين يذهب. أما الوكيل، فعلى العكس، قد ينشر افتراضًا خاطئًا بثقة عبر تصحيح كامل إذا كانت طبقة الاسترجاع رديئة.
لذلك ينبغي قراءة ادعاء Semble بشأن تقليل الرموز المميزة باعتباره مؤشرًا لشيء أكبر: نظافة استرجاع أفضل. ضوضاء أقل تعني مساحة أقل للهلوسة. والضوضاء الأقل تعني أيضًا مساحة أكبر للنموذج ليرى الثوابت الحقيقية في الشيفرة. وهذا هو مصدر التغييرات المفيدة.
كيف يبدو هذا عمليًا
كان Kenji Silva، وهو محلل بيانات في Krakow، Poland، يساعد فريقه في تشخيص خط أنابيب تسعير يلامس 14 خدمة و9 نماذج SQL. البحث التقليدي أعاد 311 تطابقًا لسلسلة خطأ واحدة. أما سير عمل بحث واعٍ بالرموز المميزة فقلّص مجموعة العمل إلى 18 مقطعًا وخفض حجم مطالبة الوكيل بنسبة 91%. وقال إن أول تشخيص مفيد وصل بعد 4 دقائق بدلًا من 29.
استخدمت Rina Popescu، وهي قائدة عمليات في Tallinn، Estonia، وكيلًا لفحص أدلة التعامل مع الحوادث عبر 6 مستودعات داخلية. كان الوكيل يختلط عليه الأمر مرارًا بسبب markdown القالبية ودفاتر التشغيل المكررة. وبعد أن انتقل فريقها إلى طبقة بحث في الشيفرة تزيل التكرار عن العبارات الجاهزة، انخفضت حالات التصعيد الخاطئة من 17 في أسبوع إلى 3، وتوقف فريق المناوبة عن تجاهل نصف التنبيهات.
أما Farah Rahman، في Doha، فأجرت تجربة أولية على خدمة دفع شهدت 248 فشلًا في الاختبارات خلال شهر. طلب فريقها من وكيل تجميع الفشل بحسب السبب الجذري. ومع طبقة بحث أفضل، نجح الوكيل في تجميع 193 منها في 5 أنماط، وأظهر المسارات الدقيقة للملفات التي تغيرت. لم يُلغِ ذلك الحكم البشري، لكنه أزال قدرًا كبيرًا من البحث الأعمى.
أخطاء شائعة يجب تجنبها
-
اعتبار توفير الرموز المميزة هو الهدف الكامل. خفض استخدامها رائع، لكنه ليس المنتج ذاته. إذا أعاد البحث سياقًا أقل وأدلة أسوأ، فأنت لم تفعل سوى ضغط الخطأ. الهدف ليس مطالبات أصغر؛ بل قرارات أكثر موثوقية.
-
استخدام التفكير بالمطابقة الحرفية لمهام دلالية. grep ممتاز عندما تعرف السلسلة أو الرمز أو مسار الاستيراد. لكن الوكلاء غالبًا لا يعرفون ذلك. إذا كانت استراتيجية الاسترجاع لديك مجرد نسخة من grep بغلاف أنحف، فستفوت الشيفرة المعاد تسميتها، والاعتماديات الضمنية، والمواد المولدة.
-
تجاهل بنية المستودع. تعريف دالة في helper للاختبارات والدالة نفسها في شيفرة الإنتاج ليسا متساويين. يحتاج الوكلاء إلى تلميحات حول الملكية، وحدود الوحدات، واتجاه الاستدعاء. من دون ذلك، قد يصلحون الطبقة الخاطئة بوجه لا يشي بشيء.
-
إطعام الكثير من العبارات الجاهزة. كتل التراخيص، وحزم الطرف الثالث، وJavaScript المصغر، ومقاطع الإعدادات المكررة يمكن أن تلتهم السياق بسرعة. غالبًا ما تتجاهلها الفرق لأن البشر يقفزون ذهنيًا فوق الفوضى. أما النماذج فلا تقفز؛ إنها تمتص.
-
تخطي التقييم. قد يبدو مستوى البحث ذكيًا في عرض تجريبي، لكنه قد يفشل في الأعمال الفعلية التي تتضمن أسماء نادرة، أو مستودعات متعددة اللغات، أو اختبارات فوضوية. قِس جودة الاسترجاع عبر مهام ملموسة: تحديد مكان الخطأ، وترتيب الملفات، وصحة الإجابة، لا مجرد زمن استجابة الاستعلام.
-
افتراض أن الوكيل سيصحح نفسه بنفسه. غالبًا لن يفعل. إذا أشارت خطوة الاسترجاع إلى مجموعة ملفات خاطئة، فقد يبني النموذج قصة متقنة لكنها زائفة فوقها. البحث الجيد هو أول خط دفاع، لا تحسين اختياري.
قائمة مراجعة عملية
-
ابدأ بسير عمل واحد مؤلم. اختر مهمة مثل فرز الأخطاء، أو تحليل فشل الاختبارات، أو تتبع الاعتماديات. لا تحاول حل كل شيء قبل أن تعرف أي ألم في البحث هو الأهم.
-
قِس حجم المطالبة قبل وبعد. تتبع رموز الإدخال، وجودة المخرجات، والوقت حتى أول إجابة قابلة للاستخدام. إذا لم تستطع تسمية خط الأساس، فلن تستطيع إثبات التحسن.
-
سجل سبب إرجاع كل مقطع. احتفظ بمسار الملف، والرمز، وإشارة الصلة. قابلية التصحيح مهمة عندما يقفز النموذج قفزة غريبة.
-
أزل الوزن الميت مبكرًا. استبعد الأدلة المضمّنة من طرف ثالث، ومخرجات البناء، والملفات المولدة المكررة. هذا رخيص وغالبًا ما يؤتي ثماره فورًا.
-
فضّل الاسترجاع المنظم على تفريغ النص الخام. امنح الوكيل حزمة موجزة: اسم الرمز، والأسطر المحيطة، وتلميحات الاعتماد. هذا غالبًا أفضل من لصق الملفات كاملة.
-
اختبر باستعلامات قبيحة. جرّب الدوال المعاد تسميتها، ورسائل الخطأ الجزئية، والوصف الغامض مثل “الشيء الخاص بالدفع يفشل بعد إعادة المحاولة”. الوكلاء الحقيقيون يرون الفوضى، لا الكلمات المفتاحية المثالية.
-
قارن بـ grep بإنصاف. لا يزال grep يتفوق في كثير من المهام البشرية. انظر أين يفيد البحث الجديد الوكيل وأين تظل الأداة القديمة أسرع وأبسط.
-
راقب الثقة الزائفة. إذا أصبح الوكيل أكثر طلاقة لكنه أقل دقة، فشدّد الاسترجاع واطلب الاستشهاد بالمقاطع الأصلية.
متى لا ينبغي فعل ذلك
ليس كل فريق يحتاج إلى طبقة بحث موجهة للوكلاء أولًا. إذا كان مستودعك صغيرًا، ومكدسك البرمجي مرتبًا، ومهامك تقودها العقول البشرية في الغالب، فقد يكون grep مع بحث جيد داخل IDE كافيًا. يمكن للاسترجاع المتقدم أن يتحول إلى استعراض فارغ عندما تكون العقبة الحقيقية هي فهم المنتج، لا العثور على الملف.
كما أنه القرار الخاطئ إذا لم تكن لديك انضباطية تشغيلية كافية لتقييم المخرجات. محرك بحث موفر للرموز المميزة يمكنه أن يجعل التجارب أرخص، وهذا جيد، لكنه قد يجعل أيضًا سلوك الوكيل السيئ أرخص. إذا لم يكن أحد يراجع جودة الاسترجاع، فقد تكون ببساطة تؤتمت الارتباك بتكلفة أقل.
أين تتعلم المزيد
- https://owasp.org/www-project-top-ten/ - للأساسيات الأمنية التي تظل مهمة عندما تلامس الوكلاء الشيفرة
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions - تذكير جيد بما يفعله البحث على طريقة grep فعليًا في الخلفية
- https://en.wikipedia.org/wiki/Information_retrieval - المجال الأوسع وراء الترتيب، والصلة، وتقييم البحث
بالمناسبة، الجزء المثير في Semble ليس الرقم التسويقي، حتى لو كان “98% أقل من الرموز المميزة” عنوانًا جميلًا. بل الإشارة إلى أن البحث في الشيفرة يُعاد بناؤه أولًا للقراء الآليين، وثانيًا للبشر، وأن هذا التغيير سيعيد تشكيل الطريقة التي تُشخّص بها الفرق أخطاء برمجياتها، وتُصلحها، وتؤتمتها. لم يعد السؤال هو ما إذا كان الوكلاء قادرين على البحث في الشيفرة - بل ما إذا كانت طبقة البحث لديك تساعدهم على التفكير بوضوح أم أنها لا تطعمهم سوى المزيد من الضوضاء.
