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

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

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

تتكوّن الأنظمة الداخلية في أي بنك كبير من طبقات من الوثائق والجداول والاتفاقات غير المجمّعة في مكان واحد. ملّاك المنتجات (Product Owners) والقادة التقنيون (Tech Leads) والمديرون التقنيون (CTO) ومديرو المستوى B-1 وموظفو إدارة التكاليف: جميعهم يقضون وقتهم لا في العمل داخل النظام نفسه، بل في البحث عن المعلومة المطلوبة، بين ملفات Excel والرسائل البريدية والملاحظات المحلية والاتصالات بالزملاء. وهذا احتكاك مزعج للموظفين ذوي الخبرة، لكنه حاجز حقيقي أمام الموظفين الجدد.

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

لماذا JVM وليس Python

تُعدّ Python المعيار الفعلي لتطوير الذكاء الاصطناعي. فمنظومة الذكاء الاصطناعي الناضجة بأكملها، من LangChain وLlamaIndex إلى HuggingFace Transformers، نمت على Python وتعمل على أفضل وجه فيها. وقد يبدو ذلك خيارًا منطقيًا لمشروع ذكاء اصطناعي.

لكن فريق المنتج في البنك يعمل على JVM: Kotlin وJava وSpring Boot. وكان الانتقال إلى Python يعني استقطاب مختصين جدد، وبناء حزمة تقنية جديدة حول منتج واحد، واستحداث مجالات مسؤولية جديدة، وتحمّل مخاطر إضافية عند الصيانة. اختار الفريق غير ذلك: البقاء في البيئة المألوفة. وكان قرارًا واعيًا، لا استسلامًا للعادة.

أبرز الحجج لصالح JVM:

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

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

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

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

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

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

ماذا يعني ذلك

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

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