تسيطر سير العمل متعددة الوكلاء (Multi-agent workflows) على GitHub في الوقت الحالي. حيث يقوم المطورون بربط نماذج اللغات الكبيرة معاً، وتخصيص تخصص ضيق لكل وكيل، وتنسيق مخرجاتها لمعالجة مهام لا يمكن لنموذج واحد التعامل معها بمفرده. يمكن أن تكون النتائج مبهرة؛ فوكيل يقوم بالبحث، وآخر بالصياغة، وثالث بالتحقق من الحقائق، ورابع بتنسيق المخرج النهائي. ولكن خلف كل هذا التنسيق تكمن تبعية هشة؛ فإذا كانت الخطوة الأولى تماماً، وهي تحويل مدخلات البشر إلى تعليمات قابلة للقراءة آلياً، بطيئة أو غير دقيقة، فإن السلسلة بأكملها تنهار. لا يمكن للوكيل اللاحق إصلاح البيانات غير الصحيحة، بل يمكنه فقط نشرها.
هنا يأتي دور Iflytek/domux لمعالجة عنق الزجاجة هذا. فهو نموذج مفتوح المصدر بُني لمهمة واحدة عالية الأهمية: الفهم السريع للأوامر. وبدلاً من إنشاء مقالات أو إجراء محادثات مفتوحة، يقوم domux بتحليل اللغة الطبيعية وتصدير بيانات هيكلية صارمة يمكن للوكلاء الآخرين استهلاكها على الفور. يمكن لأي نظام يحتاج إلى مدخلات هيكلية في الوقت الفعلي، من مراكز التحكم في المنازل الذكية إلى لوحات التحكم الصناعية، استخدامه كطبقة إدراك.
الحلقة الأضعف في السلسلة
تأمل ما يحدث عندما يعطي المستخدم أمراً بسيطاً مثل "اجعل الإضاءة أقوى هنا". في إعداد متعدد الوكلاء، قد يحتاج هذا القول إلى المرور عبر متحكم في الإضاءة، ومراقب للطاقة، ومسجل أمني. إذا أعاد المحلل الأولي جملة غامضة مثل "المستخدم يريد مزيداً من الضوء"، فسيتعين على كل وكيل لاحق إعادة تفسير المعنى. قد يتوقف البعض بانتظار معايير دقيقة، بينما قد يخمن آخرون الغرفة أو مستوى السطوع ويخطئون في ذلك، مما يؤدي إلى توقف سير العمل تماماً.
يزيد زمن الاستجابة (Latency) من تفاقم المشكلة. فبإضافة بضع مئات من الملي ثانية من تأخير التحليل عند نقطة الدخول، وبحلول الوقت الذي تصل فيه المعلومات إلى الوكيل الثالث، سيكون النظام قد بدا بالفعل وكأنه معطل. فالبيئات التي تعمل في الوقت الفعلي لا تغفر البدايات البطيئة. يكتشف المطورون أن أطر عمل التنسيق تبدو رائعة في مخططات البنية التحتية، لكنها تنهار عندما يتم تغذيتها بمدخلات غامضة أو بطيئة. أنت بحاجة إلى طبقة مخصصة توحد معايير الأوامر قبل أن يبدأ بقية سير العمل في التفكير.
تم تصميم Domux ليكون تلك الطبقة. فهو يستقبل اللغة البشرية غير المنظمة ويحولها إلى مخطط (schema) نظيف يمكن للوكلاء اللاحقين اعتباره المرجع الأساسي.
السرعة، والهيكلية، والدقة
يعلن المشروع عن ثلاث خصائص تؤثر بشكل مباشر على سلوك الإنتاج.
أولاً، يستجيب في أقل من 150 مللي ثانية. هذه العتبة مهمة؛ ففي الإعدادات التفاعلية، تبدو الاستجابة التي تقل عن ربع ثانية فورية، بينما أي شيء يقترب من ثانية كاملة يدفع المستخدمين للتخلي عن الأداة. وسواء كانت المدخلات من الصوت أو من واجهة دردشة، فإن domux يحافظ على استمرارية تدفق العمل.
ثانياً، يقوم بربط المدخلات بمخطط صارم مكون من سبعة حقول. لا يوجد نص حر ليقوم الأنظمة اللاحقة بفك تشفيره، بل يتم وضع كل أمر في أعمدة يمكن التنبؤ بها.
ثالثاً، يدعي دقة تصل إلى 98.37 بالمائة إلى جانب امتثال بنسبة 100 بالمائة للتنسيق. تعني الدقة أن النموذج يفهم المستخدم بشكل صحيح في الغالب، بينما يعني الامتثال للتنسيق أن المخرج يكون صالحاً من الناحية الهيكلية في كل مرة. إن المحلل الذي تبلغ دقته 99 بالمائة ولكنه يسقط حقلاً أحياناً أو يخترع حقلاً جديداً يعد عبئاً في سلسلة مؤتمتة؛ فصف واحد غير صحيح يمكن أن يتسبب في تعطل الوكيل المستهلك.
إليك كيف يبدو المخرج في الواقع. عندما يعالج النموذج أمراً ما، فإنه يعيد سجلاً مفصولاً بعلامة الأنبوب (|):
action|device|attribute|value|unit|room|floor
turnOn|light|brightness|80|percent|living room|ground floor
هذا التنسيق متعمد؛ فالنص المفصول بعلامة الأنبوب يسهل تحليله في أي لغة برمجة دون الحاجة إلى تبعيات ثقيلة. كما أنه يتجنب تضخم JSON وزمن استجابة التسلسل المتداخل (nested serialization). يمكن لوكيل الإضاءة قراءة أعمدة "action" و "device" والتصرف على الفور، ويمكن لوكيل التسجيل استخراج "room" و "floor" دون الحاجة إلى إجراء عملية استدلال أخرى. هذا الهيكل يزيل الغموض عن طريق التصميم.
التعامل مع النوايا البشرية غير المنظمة
الناس الحقيقيون لا يتحدثون مثل وثائق الـ API؛ فهم يقولون أشياء مثل "اجعل الإضاءة أقوى" أو "اجعل هذا المكان دافئاً". المحلل الهش سيفشل في التعامل مع ذلك، لكن Domux يعالج الغموض عن طريق ربط النية بإجراء تعديل، وترك الأمر للأنظمة اللاحقة لتحديد القيمة الدقيقة. إذا قال شخص ما "اجعل الإضاءة أقوى"، يحدد النموذج الإجراء كزيادة في السطوع، ويترك المستوى الرقمي المحدد لوكيل الإضاءة لتحديده بناءً على القراءات الحالية، أو الوقت من اليوم، أو...