الطريقة الصحيحة لبناء بنية تحتية للذكاء الاصطناعي (AI Architecture)
كنت أعتقد أن جعل مساعد الذكاء الاصطناعي الخاص بي أكثر ذكاءً يعني إضافة المزيد من الأدوات إلى نفس الحلقة (loop). نجح الأمر لفترة من الوقت. ولكن بعد ذلك، كان على مساعدي القيام بمهام المستخدم العادية، مثل استكمال مهمة من الدردشة، أو الإجابة على سؤال حول الحالة، أو تذكر سير العمل (workflow).
لم تكن المشكلة في عدد الأدوات التي يمكن لمساعدي استدعاؤها، بل في بنيته التحتية (architecture). كانت البنية القديمة بسيطة: رسالة المستخدم -> حلقة المساعد -> الأدوات -> الإجابة. هذا جيد للعروض التجريبية (demo)، ولكن ليس لمساعد مقيم (resident assistant).
يحتاج المساعد المقيم إلى معرفة ما إذا كانت الرسالة مهمة جديدة، أو متابعة، أو إلغاء. ويحتاج إلى تجنب الاستحواذ على مساحة العمل من مهمة أخرى وتذكر الإجراءات دون استخدام سجلات المحادثات (transcripts) القديمة.
لذا توقفت عن اعتبار مساعدي مجرد وكيل (agent) واحد، وبدأت في التعامل معه كمستوى تحكم محلي (local control plane). الآن تبدو بنيتي التحتية كالتالي:
- Experience Plane: المسؤول عن مكان تحدث المستخدم
- Assistant Control Plane: يقرر نوع العمل المطلوب
- Runtime Execution Plane: حيث تتم أعمال البرمجة
- Proxy / Model Access Plane: يتولى مهام المزود (provider)
لدي أيضًا Observation Plane و Memory / Policy Plane. تساعد هذه المستويات (planes) مساعدي على البقاء متزنًا ومركزًا على مهامه.
جاء أكبر تحسن من جعل مساعدي يستهلك الملاحظات (observations) بدلاً من السجلات الخام (raw logs). يساعد هذا مساعدي على رؤية حقائق موجزة مثل "المهمة X تنتظر الموافقة" بدلاً من قراءة سجل محادثة ضخم.
تعلمت أن "التذكر" ليس هو نفسه حشو المزيد من تاريخ الدردشة في المطالبة (prompt). بالنسبة لمساعدي، الذاكرة تعتمد على الملفات ومحددة النطاق (scoped). يمكنه تخزين سير عمل، أو حقيقة، أو مرجع واستدعاؤها عند الحاجة.
إذا كنت تبني وكلاء (agents) حول أدوات موجودة، فهل تضع كل شيء داخل حلقة واحدة، أم بدأت في تقسيم التحكم والتنفيذ والملاحظة والذاكرة أيضًا؟
Source: https://dev.to/codekingai/my-ai-assistant-needed-a-control-plane-not-a-bigger-loop-15aa Optional learning community: https://t.me/GyaanSetuAi