تطبيق الدردشة المعتمد على الذكاء الاصطناعي هو واجهة دردشة نصية يقوم فيها المستخدم بكتابة رسالة، فيرسلها التطبيق إلى خدمة قادرة على استدعاء نموذج ذكاء اصطناعي، ثم يعرض التطبيق رد النموذج للمستخدم.
في العديد من المنتجات، يصل الرد على شكل تدفق بيانات (stream)، بحيث يرى المستخدم أجزاء النص (الرموز أو tokens) تظهر تباعاً بمرور الوقت بدلاً من الانتظار حتى تكتمل الإجابة بالكامل.
لتبسيط الصورة، لنبدأ بفريق داخلي صغير يستخدم تطبيق ويب واحداً يتواصل مع خدمة خلفية (backend) واحدة، والتي بدورها تستدعي مزوداً واحداً للنماذج.
عند استخدام خادم واحد، تسير العملية في حلقة متصلة: يرسل العميل (التطبيق) رسالة المستخدم إلى خادم واجهة برمجة تطبيقات (API) واحد، فيقوم الخادم بتحميل المحادثة لضمان توفر السياق، ثم يستدعي مزود النموذج، وأخيراً يعيد رد المساعد إلى العميل.
يُعد تخزين المحادثة أمراً مهماً حتى في هذا النموذج الأولي، إذ لا ينبغي أن تؤدي إعادة تحميل الصفحة إلى مسح الدردشة. يقوم خادم واجهة برمجة التطبيقات بحفظ كل رسالة من المستخدم ومن المساعد، ثم يستخدم هذه الرسائل المخزنة لمواصلة المحادثة نفسها في الخطوة التالية.
فيما يلي تفاصيل دورة الدردشة الواحدة التي نبنيها لتكون بمثابة النموذج الأولي (الأساس).
يؤدي المخطط أربع وظائف: يجمع العميل (Client) المدخلات ويعرض تدفق البيانات، ويتولى خادم واجهة برمجة التطبيقات (API server) إدارة دورة حياة الطلب، ويحفظ مخزن المحادثات الرسائل لضمان استمرار سلسلة المحادثة بعد تحديث الصفحة، بينما تُنتج واجهة برمجة تطبيقات النموذج (Model API) الرموز (tokens) الخاصة بالمساعد والتي يعيد الخادم إرسالها إلى العميل.
يقتصر النطاق الوظيفي على الدردشة النصية البسيطة فقط؛ إذ لا توجد أدوات أو صور أو عمليات رفع للملفات، وبالتالي فإن المهام الوحيدة المطلوبة في كل دورة تبادل (turn) هي تخزين الرسائل، وتجميع السياق، واستدعاء النموذج.
لنضف الآن رقماً واحداً يضع الخادم الفردي تحت الضغط: مع وجود 2000 مستخدم متزامن بمعدل دورتين في الدقيقة لكل منهم، يواجه النظام الخلفي (backend) ما يقرب من دورة تبادل للمستخدم في الثانية، وهو ما يترجم إلى عدد مماثل من عمليات استدعاء النموذج المتوازية.
يولّد هذا الرقم مؤشرين يتعلقان بالمتطلبات غير الوظيفية (non-functional signals) والتي ستؤثر على بقية جوانب التصميم: تبرز مشكلة زمن الانتقال (latency) لأن استدعاءات النموذج تستغرق الجزء الأكبر من الوقت الإجمالي للمعالجة، وتصبح التكلفة عاملاً حساساً لأن النظام يدفع مقابل كل طلب وكل رمز (token) يتم توليده.
حتى قبل التوسع، يمكن تقسيم التصميم الأساسي بوضوح إلى وحدات قابلة لإعادة الاستخدام، حيث تتولى كل وحدة مسؤولية محددة واحدة.