Yandex Cloud تشرح لماذا يقود الفرونت إند دمج الشبكات العصبية في DataLens في مرحلة الإطلاق

تقترح Yandex Cloud النظر إلى دمج الشبكات العصبية في المنتج لا بوصفه مهمة تخص الباك إند وحده. ففي DataLens تولّى فريق الفرونت إند بناء الطبقة العملية الأولى من «Нейроаналитик» (المحلل العصبي): إذ جمع واجهة المحادثة وطبقة BFF الوسيطة ومنطق التواصل مع النموذج، دون انتظار إعادة هيكلة كبيرة للخوادم. والفكرة أن الأهم عند الإطلاق المبكر لميزات الذكاء الاصطناعي ليس بنية مثالية تصمد لسنوات، بل وصول سريع إلى المنتج مع نطاق مسؤولية واضح.

يدور الحديث عن DataLens، وهو نظام ذكاء الأعمال (BI) من Yandex Cloud لتصوير مجموعات البيانات الكبيرة. وظهر داخل الخدمة «Нейроаналитик»، وهو مساعد يساعد في بناء الرسوم البيانية وكتابة الصيغ وحل المهام التحليلية عبر الحوار. وبدلاً من النموذج التقليدي الذي يتولى فيه الباك إند الدمج مع LLM بالكامل، اقترح الفريق ترتيباً مختلفاً: ظهرت بين العميل والنموذج طبقة BFF يتولى مسؤوليتها الفرونت إند. ويمكن تشغيل هذه الطبقة على Node.js أو Bun أو أي حزمة تقنية مألوفة أخرى، واستخدامها كخادم منفصل موجّه لاحتياجات الواجهة.

ويوضّح المؤلف هذا النهج بمشروع تجريبي على شكل مستودع أحادي (monorepo) يضم Express وReact، حيث تعمل لوحة BI إلى جانب مساعد المحادثة. وفي هذا المخطط لا حاجة إلى إعادة كتابة الباك إند القائم على وجه السرعة. فطبقة BFF تحفظ مفاتيح الوصول إلى النموذج، وتتولى تحديد معدل الطلبات (rate limiting) وCORS والتسجيل والمراقبة، كما تدير بث الردود تدفقياً. وهذه ليست أرضاً غريبة على مطوري الفرونت إند: ففي كثير من فرق المنتجات يعمل هؤلاء منذ زمن مهندسين متكاملين (full-stack)، ويدعمون الشيفرة الخلفية وCI/CD والبنية التحتية المحيطة بتطبيق العميل. لذلك يمكن تنفيذ المرحلة الأولى من الدمج بالقرب من الواجهة، حيث يظهر الأثر على المستخدم بأسرع صورة. وإذا لم تنجح الفرضية، فإن كلفة الخطأ أقل مما لو أُعيد بناء الباك إند الرئيسي بعمق.

يحدد أصحاب النهج أربعة مكونات أساسية لهذا الدمج. الأول هو UI-kit لواجهة المحادثة والعناصر المرتبطة بها: حقول الإدخال والبطاقات وقوائم الإجراءات وبث الرسائل تدفقياً. والثاني هو SDK للعمل مع النموذج عبر API؛ والمهم هنا ليس مزوّداً بعينه بل التوافق، لأن كثيراً من الخدمات تحاكي صيغة OpenAI API. والثالث هو الأدوات (tooling)، أي استدعاء الدوال (function calling) ووصول النموذج إلى الوظائف التطبيقية، مثل جلب البيانات لرسم بياني أو استخراج أفضل 5 منتجات. والرابع هو السياق: سجل الحوار وحالة التطبيق وشيفرة المستخدم ونتائج الحسابات والأخطاء التي يحتاجها النموذج لإعطاء إجابة ذات معنى. وهذه الطبقات الأربع تكفي من حيث الأساس لإطلاق ميزة ذكاء اصطناعي عاملة في الواجهة.

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

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

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