T-Bank يرفع جودة AI Code Completion بفضل مرشّح يحجب الاقتراحات الزائدة

روى T-Bank كيف أعاد تصميم خدمة AI Code Completion الداخلية لديه، التي يستخدمها 7,5 ألف مطوّر، ورفع نسبة الاقتراحات المقبولة دون تغيير نموذج التوليد الأساسي. وبدل محاولة جديدة لجعل الإكمال «أذكى»، أضاف الفريق مرشّحًا مستقلًا يقرر أصلًا ما إذا كان ينبغي عرض الاقتراح.

أين كان السقف؟

تعمل خدمة الإكمال التلقائي للكود في T-Bank في بيئة الإنتاج منذ عدة سنوات، ويستخدمها يوميًا تقريبًا كل فرق التطوير الداخلية، أي نحو 7,5 ألف مستخدم فريد. وظلّ المقياس الأساسي، Acceptance Rate، قريبًا من 20% لفترة طويلة: أي أن اقتراحًا واحدًا من كل خمسة تقريبًا كان يُقبل، بينما يُتجاهل الباقي.

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

ولاحظ الفريق أثرًا سلوكيًا مهمًا: حين تقلّ الاقتراحات غير المفيدة، يضغط المستخدمون على Tab بإقبال أكبر، ويمنحون فرصة حتى للاقتراحات غير البديهية. وبحسب التقدير الداخلي، كانت كل نقطة مئوية إضافية في AR تضيف مع الوقت نحو 2% إلى عدد الاقتراحات المقبولة. لكن كان هناك قيد تجاري صارم: يجب ألا «يلتهم» المرشّح فورًا أكثر من 5% من الاقتراحات التي كانت تُقبل أصلًا.

مم تألف المرشّح؟

كانت الخطوة الأولى نموذج baseline سريعًا على CatBoost. دُرّب النموذج كمصنّف ثنائي: قبول الاقتراح أو عدمه. واعتُمدت فقط الخصائص التي يمكن احتسابها في الزمن الفعلي دون تخزين سجل الطلبات: بيئة IDE ولغة البرمجة وموضع المؤشر ونوع الاقتراح وحجم البادئة (prefix) واللاحقة (suffix). وحتى هذا الخيار البسيط حقق في الاختبار دون اتصال نحو +2,3 نقطة مئوية في Acceptance Rate، وأكد وجود إشارة قوية فعلًا في هذه المهمة.

ثم انتقل الفريق إلى مرشّح نصي قائم على Qwen2.5-Coder 1.5B. فالنماذج الأكبر لم تلتزم بقيود الإنتاج: المطلوب 30 طلبًا في الثانية على بطاقة Nvidia A100 واحدة، وزمن استجابة p90 لا يتجاوز 50 مللي ثانية. لذلك وقع الاختيار على حل وسط: نموذج مدمج بما يكفي للاستدلال (inference)، لكنه لا يزال مخصصًا للكود. ولكي لا يخلط النموذج بين سياق الملف والاقتراح نفسه، كان لا بد من هيكلة المدخلات بصرامة وإعادة تدريب النموذج على التصنيف بدل التوليد.

• استُبدل رأس التوليد برأس تصنيف ثنائي
• وُسم السياق بوسوم للبادئة والسطر والإجابة واللاحقة
• رُمّزت بيئة IDE واللغة وموضع المؤشر عبر رموز (tokens) خاصة
• أضيفت في المرحلة النهائية عمليات fine-tuning وLoRA وfocal loss بسبب اختلال توازن الفئات

حسّنت هذه السلسلة الجودة على مراحل: بعد الهيكلة الصارمة ارتفع المكسب إلى نحو +3,9 نقطة مئوية، وبعد إضافة الرموز الخاصة إلى +5,1 نقطة مئوية، ثم رفع fine-tuning الكامل النتيجة دون اتصال إلى +6,8 نقطة مئوية. ولم يكن إعادة التدريب وحده هو الأهم، بل أيضًا طريقة تغليف المدخلات: فقد بدأ النموذج يميّز بوضوح أكبر بين سياق الملف والاقتراح الذي ينبغي تقييمه لا إعادة كتابته.

ما الذي تعطّل في الإنتاج؟

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

«الاختبار دون اتصال ضروري، لكن التشغيل الظلي هو المكان الوحيد الذي

يبدأ فيه الواقع.»

بعد ذلك انكشفت طبقة ثانية من المشكلات: تبيّن أن المرشّح شديد العدوانية. ولإبقاء فاقد الاقتراحات المقبولة ضمن حدود 5%، اضطر الفريق إلى إعادة تدريب العتبة (threshold) على نافذة بيانات أسبوعية بدل بضعة أيام. ثم أضاف الفريق فوق LLM نموذج CatBoost آخر، يتلقى درجة النموذج الرئيسي والخصائص الجدولية وإشارات تاريخية مثل الفاصل الزمني بين الطلبات وتغيّر طول البادئة. ولهذا الغرض خُزّنت حالة المستخدم في Redis.

وفي أثناء العمل وقع الفريق في خطأ هندسي شائع: كانت بعض الخصائص تُحتسب في الإنتاج بالبايت، وبعضها الآخر بالمحارف. وبعد توحيد المنطق، أظهر اختبار A/B نسبة 4,7% من الحركة المستبعدة و+5,2 نقطة مئوية في Acceptance Rate دون انحيازات بحسب اللغات أو بيئات IDE.

ماذا يعني ذلك؟

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