SberDevices تبني وكلاء للواجهات الأمامية على GigaChat لمراجعة طلبات الدمج (merge request)

قررت SberDevices ألا تسلّم شيفرتها البرمجية لخدمات خارجية لمراجعتها، فبنت نظامها الخاص من الوكلاء للواجهات الأمامية. ولم تنسجم الأدوات الجاهزة GitHub Copilot Code Review وGigaCode Agent من GitVerse مع هذا التصور، فكلاهما خارجي، والفريق لا يريد فتح مستودعاته أمامهما. وتحدثت عن البنية المعمارية على هابر (Habr) أورورا (Аврора)، المسؤولة عن البنية التحتية للواجهات الأمامية في الشركة. ولا يتضمن الإعلان أي مقاييس، لذلك يستعرض ما يلي ما هو مؤكد، إضافة إلى المنطق الهندسي وراء القرارات.

لماذا نظام خاص وليس حلًا جاهزًا

لا تتعلق الثقة بالأدوات الخارجية بجودة النموذج، بل بحدود المحيط الأمني. فالمراجع يقرأ فروق التعديلات (diffs) وبنية المشروع والمكتبات الداخلية والاصطلاحات المعتمدة. وبالنسبة لشركة كبيرة، هذه هي الشيفرة التي لا تخرج من نطاقها المغلق. وتصف أورورا المسار المعتاد للفرق الكبيرة بأنه بناء «دراجة خاصة بالعدد المناسب من العجلات والدواسات». وهذا اختيار واعٍ: فالمنتجات الخارجية تحل مهمة عامة، أما المنظومة الداخلية فتُكيَّف مع مستودعات وعمليات بعينها.

يقوم النظام على GigaChat. ويقابل عنوان المادة بين وكلاء «مع GigaChat وبدونه»، أي بين الأتمتة المعتمدة على نموذج والنهج الكلاسيكية.

وضعان في نظام واحد

القرار المعماري الأهم أن الفريق جمع بين نهجين ولم يكتفِ بأحدهما.

• الحلقة الوكيلية. يتلقى النموذج هدفًا ومجموعة أدوات، ثم يقرر بنفسه أي خطوات يتخذ. وهي مرنة، لكن إمكانية التنبؤ بسلوكها أقل.
• الـ workflow الحتمي. ينفّذ النموذج مهام محدودة منفصلة ضمن تسلسل محدد مسبقًا. ومن الأسهل التحقق من نتيجته وإعادة إنتاجها.

يبدو الجمع بين الأسلوبين هنا معقولًا. فمراجعة merge request تتألف من عمليات ضيقة: العثور على خطأ شائع، أو التحقق من اصطلاح معين، أو تقييم مقطع محدد. ومن الأجدى دمج هذه العمليات في سيناريو صارم. أما المهام المفتوحة، مثل «افهم المشكلة واقترح تعديلًا»، فالأفضل إسنادها إلى حلقة تعمل بالأدوات. الأول يمنح الاستقرار، والثاني يمنح الشمولية.

ما الذي وعد به التحليل الكامل

يبرز الكاتب ثلاثة محاور:

• إحصاءات أخطاء مطوري الواجهات الأمامية بحسب بيانات المراجع الآلي، أي أي العيوب تتكرر أكثر من غيرها؛
• محلّل (parser) يضيّق سياق النموذج بحيث لا يرى إلا الشيفرة ذات الصلة؛
• ميزة في النظام أصبحت «على نحو مفاجئ» الأكثر طلبًا.

ويستحق المحلّل الاهتمام. ففي الواجهات الأمامية ضجيج كثير: ترميز وأنماط وملفات إعداد وملفات مولَّدة آليًا. وإذا قُدِّم كل شيء للنموذج دون انتقاء، ترتفع التكلفة ويطول زمن الاستجابة وتنخفض جودة الملاحظات. أما الاستخلاص المسبق وفق بنية الشيفرة فيساعد على صياغة المهمة بدقة أكبر وعلى البقاء ضمن نافذة السياق.

أما أي ميزة بالتحديد أصبحت الأكثر طلبًا، فهذا غير معروف من الإعلان. ولا يبقى إلا انتظار النص الكامل.

ما الذي يمكن الاستفادة منه عمليًا

إذا كنتم تبنون مراجعًا آليًا داخليًا أو وكيلًا للتطوير، فيمكن أخذ عدة أمور من نهج SberDevices.

قسّموا المهام بحسب درجة الحرية. اجعلوا كل ما يخضع لخوارزمية واضحة workflow حتميًا، واتركوا الحلقة الوكيلية للمهام المفتوحة.

لا تغذّوا النموذج بالمستودع كله. ضيّقوا السياق أولًا بمحلّل أو بتحليل ساكن (static analysis)، ثم استدعوا الـ LLM.

اجمعوا إحصاءات ملاحظات المراجع. فهي تُظهر الأخطاء المتكررة لدى الفريق، ومعالجتها عبر linter أو قالب جاهز أجدى غالبًا من التعليق عليها في merge request في كل مرة.

راقبوا ما يستخدمه الناس أكثر من غيره. يعترف الكاتب صراحةً بأن الميزة الأكثر طلبًا لم تكن تلك التي توقعوها. أدرجوا القياس عن بُعد (telemetry) في النظام منذ البداية.

وبالنسبة للسوق، هذا مثال آخر على ابتعاد الشركات الكبرى عن خدمات الذكاء الاصطناعي الخارجية نحو منصات وكلاء داخلية. والأسباب عملية: التحكم في الشيفرة، وإمكانية تكييف السلوك مع عملياتها الخاصة.