رفع T-Bank جودة AI Code Completion باستخدام فلتر وأزال الاقتراحات الزائدة

شرحت تي-بانك كيف أعادت بناء AI Code Completion الداخلي الخاص بها لـ 7500 مطور ورفعت نسبة الاقتراحات المقبولة دون تغيير نموذج الإنشاء الأساسي. بدلاً من محاولة أخرى لجعل الإكمال التلقائي "أكثر ذكاءً"، أضافت الفريق مرشحاً منفصلاً يقرر ما إذا كان يجب عرض الاقتراح أم لا.

حيث كان الحد

كانت خدمة الإكمال التلقائي للكود في تي-بانك تعمل في الإنتاج منذ عدة سنوات وتُستخدم يومياً من قبل ما يقرب من جميع فريق التطوير الداخلي—حوالي 7500 مستخدم فريد. ظلت المقياس الأساسي، معدل القبول، يحوم حول 20% لفترة طويلة: تقريباً واحد من كل خمسة اقتراحات تم قبوله، والباقي تم تجاهله. حاول الفريق إطالة الاقتراحات، وتغيير استراتيجية الإنشاء، وتوسيع عدد الأماكن التي تظهر فيها الاقتراحات، لكن هذا أدى إلى المزيد من الضوضاء.

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

وفقاً للتقييم الداخلي، أضاف كل نقطة مئوية إضافية من معدل القبول مع مرور الوقت حوالي 2% إلى عدد القبولات. لكن كان هناك حد تجاري صارم: لا يجب أن يزيل المرشح فوراً أكثر من 5% من الاقتراحات المقبولة بالفعل.

كيف بنوا المرشح

كانت الخطوة الأولى خط أساس سريع على CatBoost. تم تدريب النموذج كمصنف ثنائي: قبول الاقتراح أم لا. استخدموا فقط تلك الميزات التي يمكن حسابها في الوقت الفعلي دون تخزين سجل الطلبات: IDE، لغة البرمجة، موضع المؤشر، نوع الاقتراح، حجم البادئة واللاحقة.

حتى هذا المتغير البسيط أعطى حوالي +2.3 نقطة مئوية لمعدل القبول خارج الإنترنت وأكد أن المهمة لديها إشارة قوية. بعد ذلك، انتقل الفريق إلى مرشح نصي يعتمد على Qwen2.

5-Coder 1.5B. لم تتسع النماذج الأكبر حجماً ضمن قيود الإنتاج: الهدف هو 30 طلب في الثانية على وحدة Nvidia A100 واحدة وكمون p90 لا يتجاوز 50 ميلي ثانية.

اختاروا إذاً توازناً: مدمج بما يكفي للاستدلال، لكن لا يزال مصمماً للكود. لمنع النموذج من الخلط بين سياق الملف والاقتراح نفسه، كان يجب تنظيم الإدخال بشكل صارم وضبطه ليس للإنشاء بل للتصنيف.

• استبدلت رأس الإنشاء بالتصنيف الثنائي
• وسمت السياق للبادئة والسطر والإجابة واللاحقة
• رمزت IDE واللغة وموضع المؤشر برموز خاصة
• في المرحلة النهائية، أضافت الضبط الدقيق، LoRA وخسارة focal بسبب عدم التوازن في الفئات

حسّن هذا الخط الأنابيب الجودة بالتدريج: بعد التنظيم الصارم، نما الربح إلى حوالي +3.9 نقطة مئوية، بعد إضافة الرموز الخاصة—إلى +5.1 نقطة مئوية، والضبط الدقيق الكامل أحضر النتيجة خارج الإنترنت إلى +6.8 نقطة مئوية. اتضح أن الأهم ليس فقط الضبط الدقيق، بل كيفية حزم الإدخال: بدأ النموذج يميز بشكل أفضل حيث كان سياق الملف وأين كان الاقتراح المراد تقييمه، بدلاً من إعادة الكتابة.

ما انكسر في الإنتاج

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

"الإنترنت الخارجي ضروري، لكن التشغيل الظلي هو المكان الوحيد حيث تبدأ الواقع."

بعد ذلك، كُشف عن طبقة ثانية من المشاكل: اتضح أن المرشح عدواني جداً. للحفاظ على الارتفاع في الاقتراحات المقبولة ضمن 5%، كان يجب إعادة تدريب العتبة على نافذة بيانات أسبوعية بدلاً من بضعة أيام. ثم فوق LLM، تمت إضافة CatBoost آخر، الذي تلقى درجة النموذج الرئيسي والميزات الجدولية والإشارات التاريخية مثل الفاصل الزمني بين الطلبات والتغييرات في طول البادئة. لهذا تم تخزين حالة المستخدم في Redis. في الطريق، قبض الفريق على خطأ هندسي نموذجي: كانت جزء من الميزات في الإنتاج محسوبة بالبايتات والجزء بالأحرف. بعد محاذاة المنطق، أظهر اختبار A/B 4.7% من حركة المرور المسقطة و+5.2 نقطة مئوية لمعدل القبول بدون انحيازات حسب اللغة و IDE.

ماذا يعني هذا

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