SkeletonGraph: A Zero-LLM Structural Retrieval Engine for Coding Agents, and Why Its Gains Land in the Cost Tail, Not the Median
تقدم هذه الورقة SkeletonGraph، وهو محرك استرجاع هيكلي يحسن بشكل كبير تحديد موقع الكود على مستوى الدالة ويقلل التكاليف للوكلاء البرمجيين في ذيل توزيع المهام المكلف، ومع ذلك فإنه يفشل في خفض التكاليف المتوسطة أو تعزيز معدلات الحل لأن فعاليته مقيدة بمعرفة المستودع ولا يمكنه استبدال تعلم الوكيل الخاص من قراءة الكود.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل فريقاً من المساعدين الرقميين ذوي المهارات العالية، كل منهم مجهز بمكتبة ضخمة من الأكواد وعقل قوي قادر على فهم التعليمات المعقدة. هؤلاء المساعدون مكلفون بإصلاح الأخطاء البرمجية في مشاريع برمجية ضخمة، وهي مهمة تتطلب منهم العثور على الجزء المحدد من الكود المعطل، وفهم كيفية ملاءمته للنظام بأكمله، ثم إعادة كتابته بشكل صحيح. لفترة طويلة، اعتقدت الصناعة أن أكبر عائق أمام هؤلاء المساعدين كان ببساطة العثور على الملف الصحيح. كانت النظرية السائدة هي أنه إذا استطعنا بناء خريطة أفضل أو محرك بحث أكثر ذكاءً لتقديم الملف الصحيح للمساعد فوراً، فسنوفر قدراً هائلاً من الوقت والمال. بدا الأمر منطقياً: إذا لم يضطر المساعد للتجول عبر آلاف الملفات للعثور على الملف الذي يحتاجه، فعليه أن ينهي المهمة بشكل أسرع وأرخص.
وقد دفع هذا الاعتقاد موجة من الأدوات الجديدة المصممة لتعمل كمحركات استرجاع هيكلية. وبدلاً من ترك المساعد يقرأ النص سطراً بسطر، تقوم هذه الأدوات بتحليل بنية الكود، وفهم كيفية استدعاء الدوال لبعضها البعض، وتقدم له الدالة التي يحتاج لتعديلها بالضبط. كان الوعد دراماتيكياً: ادعى بعض المطورين أن هذه الأنظمة يمكن أن تخفض التكاليف بنسبة تسعة وتسعين بالمائة. لكن دراسة جديدة تتحدى هذه الرؤية المتفائلة، مشيرة إلى أنه بينما تجد هذه الأدوات الكود بشكل أفضل، إلا أنها لا تجعل المهمة بالضرورة أرخص بالنسبة للمهام المتوسطة. وجد الباحثون أن المدخرات ليست موزعة بالتساوي عبر جميع الوظائف؛ بل تظهر فقط في الحالات الأكثر صعوبة وتكلفة، تاركة المهام العادية بنفس التكلفة السابقة تقريباً.
الدراسة، التي أجراها الباحث المستقل ياش دوكي، وضعت هدفاً لاختبار هذه الادعاءات في بيئة واقعية. قام الفريق ببناء نظام يسمى SkeletonGraph، والذي يعمل كمكتبي متخصص لوكلاء البرمجة. وعلى عكس أدوات البحث القياسية التي تبحث عن الكلمات المفتاحية في النصوص، يفهم SkeletonGraph بنية الكود؛ فهو يعلم أن الدالة هي وحدة عمل محددة ويمكنه تتبع كيفية اتصال الأجزاء المختلفة من البرنامج ببعضها البعض. ولتحديد مدى فعاليته، وضع الباحثون هذا النظام الجديد في مواجهة أداة بحث نصية قياسية مدمجة يستخدمها وكيل برمجي رائد وهو Claude Code. وقاموا بتشغيل كلا النظامين عبر مائة مهمة برمجة من الواقع، مع ضمان اختبار كل إصلاح مقترح فعلياً من خلال تشغيل الاختبارات البرمجية الخاصة بالمشروع للتأكد من نجاحه. كان هذا أمراً حاسماً، لأنه يعني أنهم يقيسون التكلفة الفعلية ونجاح العملية برمتها، وليس مجرد مدى جودة أداء محرك البحث بمعزل عن غيره.
كانت النتائج دقيقة للغاية ولكنها مفاجئة من حيث التأثير المالي. فعندما تعلق الأمر بالعثور على الملف الصحيح للتعديل، كان النظام الهيكلي الجديد أفضل بشكل ملحوظ؛ ففي محاولته الأولى، حدد الملف الصحيح لـ 86% من المهام، بينما وجد البحث النصي القياسي الملف الصحيح بنسبة 66% فقط. وكان الفرق أكثر دراماتيكية عند تحديد الدالة المحددة داخل الملف التي تحتاج إلى تغيير؛ حيث حدد النظام الجديد الدالة الصحيحة حوالي 80% من المرات، بينما لم يتمكن البحث النصي القياسي، المصمم لمطابقة أسطر النصوص بدلاً من الكتل المنطقية للكود، من تسمية دالة واحدة صحيحة. بهذا المعنى، كان الأداة الهيكلية متفوقة بلا شك في مهمتها الأساسية: لقد وجدت الحي الصحيح وأشارت مباشرة إلى المنزل المطلوب.
ومع ذلك، عندما نظر الباحثون إلى التكلفة، تغيرت القصة. توقعوا أنه نظراً لأن النظام الجديد وجد الكود بشكل أسرع بكثير، فإن الفاتورة الإجمالية لكل مهمة ستنخفض بشكل كبير. بدلاً من ذلك، وجدوا أنه بالنسبة للمهام النموذجية متوسطة الصعوبة، ارتففت التكلفة قليلاً بنحو 2%. لم تظهر المدخرات الضخمة في منتصف الطريق؛ بل كانت مخبأة تماماً في نهاية قائمة المهام الأكثر تكلفة وصعوبة. فبالنسبة لأصعب 25% من المهام، خفض النظام الجديد التكاليف بنحو 16%، وبالنسبة لأصعب 5% من المهام، قلص التكاليف بنسبة 42%. بلغ متوسط التوفير عبر جميع المهام حوالي 15%، لكن هذا الرقم كان مضللاً لأنه مدفوع بالكامل من قبل حالات قليلة خرجت عن السيطرة حيث تاه النظام القياسي وأنفق ثروة طائلة. بالنسبة للغالبية العظمى من المهام، لم يجعل النظام الجديد المهمة أرخص؛ بل جعلها في الواقع أكثر تكلفة بالنسبة للمهام الأسهل.
اكتشف الباحثون سبب هذا الانفصال من خلال مراقبة كيفية عمل وكلاء البرمجة. وجدوا أن إجمالي المعلومات التي يتعين على الوكيل الاحتفاظ بها في ذاكرته في أي وقت واحد ظلت كما هي تقريباً، سواء استخدم الأداة الهيكلية الجديدة أو البحث النصي القديم. لا يزال الوكيل بحاجة لفهم نفس القدر من السياق لكتابة الإصلاح. النظام الجديد قام ببسابطة بتسليم ذلك السياق في مرحلة مبكرة من العملية. وبما أن الوكيل كان يتعين عليه إعادة إرسال كل المعلومات التي جمعها حتى الآن مع كل خطوة يتخذها، فإن تقديم الملف الصحيح مبكراً لم يقلل من إجمالي حجم البيانات المعالجة؛ بل قلل فقط من عدد الخطوات التي يتخذها الوكيل للوصول إلى هناك. لا يزال الوكيل مضطراً لقضاء وقت في كتابة الكود وتشغيل الاختبارات، وهو ما يشكل الجزء الأكبر من العمل. لقد وفر النظام الجديد الوقت المستغرق في التجول، لكنه لم يستطع توفير الوقت المستغرق في بناء الحل.
أدى هذا إلى نتيجة غير متوقعة حول كيفية تعلم هؤلاء الوكلاء. فعندما سُمح لنظام البحث النصي القياسي بالبحث وقراءة الملفات بمفرده، انتهى به الأمر غالباً بقراءة ملفات أكثر من النظام الهيكلي، ولكن من خلال القيام بذلك، تعلم المفردات والأنماط الخاصة بذاك الكود البرمدي الخاص. هذا "التعلم من خلال الممارسة" سمح له بالبحث بشكل أكثر فعالية مع تقدم المهمة. النظام الهيكلي، من خلال تقديمه قائمة مرتبة من الملفات فوراً، حال أحياناً دون استكشاف الوكيل للغة فريدة من نوعها للكود. وفي ثلاث من أصل أربع حالات تم اختبارها، وجد النظام القياسي الملفات الصحيحة بنفس قدر النظام الهيكلي بحلول نهاية المهمة، ببساطة لأنه استكشف المزيد. كان النظام الهيكلي أسرع في الوصول إلى خط البداية، لكن خط النهاية كان هو نفسه.
كما اختبرت الدراسة ما إذا كانت جودة وصف المشكلة تؤثر. فقد جردوا الأوصاف من التفاصيل التقنية مثل سجلات الأخطاء ومقتطفات الكود، تاركين فقط شروحات باللغة الإنجليزية البسيطة. توقعوا أن يجعل هذا النظام الهيكلي يعاني، لكنه لم يفعل. ظلت قدرة النظام على العثة على الكود الصحيح مستقرة، مما يشير إلى أنه يعتمد على بنية الكود نفسه بدلاً من الإشارات المحددة في وصف المشكلة. ومع ذلك، وجدوا أن النظام أدى بشكل أسوأ بكثير عندما كان الكود البرمجي جديداً وغير مألوف تماماً للنموذج، حيث انخفض معدل نجاحه من ما يقرب من 88% إلى حوالي 59%. أظهر هذا أن نجاح النظام يعتمد بشدة على المعرفة المسبقة للنموذج بالمستودع (repository)، وليس فقط على جودة أداة البحث.
في النهاية، تخلص الورقة البحثية إلى أن الاسترجاع الهيكلي هو أداة لمنع الكوارث بدلاً من تحسين المتوسط. إنه يعمل كشبكة أمان تمنع المهام الأكثر تكلفة وصعوبة من الخروج عن السيطرة، لكنه لا يجعل المهام الروتينية أرخص. يجادل الباحثون بأن الصناعة تقيس الشيء الخطأ. فمن خلال التركيز على عدد الرموز (tokens) التي يتم توفيرها في عملية بحث واحدة، يتجاهل المطورون حقيقة أن التكلفة الإجمالية تتحدد بعدد الخطوات التي يتخذها الوكيل وحجم السياق الذي يجب أن يحمله. النظام الجديد يختصر الطريق إلى الإجابة، لكنه لا يصغر حجم الإجابة نفسها. بالنسبة للمستخدم العادي، لن تنخفض الفاتورة؛ أما بالنسبة للمستخدم الذي يواجه نظاماً معقداً ومعطلاً، فستكون الفاتلة أقل بكثير. القيمة في هذه التكنولوجيا لا تكمن في جعل الوظائف السهلة أرخص، بل في ضمان ألا تصبح الوظائف الصعبة مستحيلة.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.