طبّق رايفايزن بنك مساعد RAG مبنيًا على Kotlin من دون Python ومن دون كفاءات جديدة

فريق بنك رايفايسن بناء مساعد RAG على لغة Kotlin و Spring Boot — ولم يكتبوا سطراً واحداً من Python. تُظهر تجربتهم أن مجموعة JVM تتعامل مع مهام الذكاء الاصطناعي بنفس جودة مجموعة Python، إذا كان الفريق يعمل فيها بالفعل ولا يريد إضافة كفاءات جديدة.

من أين جاءت المهمة

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

لماذا JVM وليس Python

Python هو المعيار الفعلي لتطوير الذكاء الاصطناعي. LangChain و LlamaIndex و HuggingFace Transformers — نمت كل النظم البيئية الناضجة للذكاء الاصطناعي على Python وتشعر بالارتياح هناك. قد يبدو أنه الخيار المنطقي لمشروع الذكاء الاصطناعي. لكن فريق المنتج بالبنك يعيش على JVM: Kotlin و Java و Spring Boot. الانتقال إلى Python يعني استقدام متخصصين جدد وبناء مجموعة جديدة حول منتج واحد ومجالات مسؤولية جديدة ومخاطر دعم إضافية. اختار الفريق بطريقة مختلفة — البقاء في بيئة مألوفة. بشكل متعمد وليس بالقصور. الحجج الرئيسية لصالح JVM:

• الدعم والقابلية للتوسع تبقى داخل الفريق الموجود
• لا حاجة لتوظيف مطوري Python أو إعادة تدريب الموجودين
• يوفر Spring Boot بنية تحتية جاهزة — الأمان والتسجيل والنشر
• يتصل النموذج اللغوي عبر API — لا يتطلب النموذج اللغوي وجود Python على الخادم
• النظام البيئي JVM لديه مكتبات فعالة للتضمينات والمستودعات المتجهة

النتيجة: خط أنابيب RAG كامل على Kotlin، بدون الحاجة لإدراج كفاءات جديدة لأداة داخلية واحدة.

الوثائق كمشكلة مخفية

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

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

ذهب جزء من الجهد ليس إلى التطوير بل إلى ترتيب المصادر. هذا مكون غير واضح لكنه عملياً حتمي في أي تطبيق RAG.

ماذا يعني هذا

فرق JVM لا يضطرون للانتقال إلى Python من أجل الذكاء الاصطناعي. إذا تم بناء الخبرة والبنية التحتية بالفعل — يمكن استخدامها مباشرة. يتم تجميع خط أنابيب RAG على Kotlin و Spring Boot بدون خسائر أساسية في الوظيفة، ولكن مع السيطرة الكاملة ضمن المجموعة المألوفة. بالنسبة للبنوك وشركات التكنولوجيا المالية حيث JVM هو المعيار الفعلي، فإن تجربة بنك رايفايسن تشكل سابقة مهمة: مهام الذكاء الاصطناعي قابلة للحل بدون تغيير الأدوات.