جریانهای کاری چندعاملی (Multi-agent workflows) در حال حاضر در GitHub بسیار پرطرفدار شدهاند. توسعهدهندگان در حال زنجیرهسازی مدلهای زبانی بزرگ هستند، به هر عامل یک تخصص محدود اختصاص میدهند و خروجیهای آنها را برای انجام وظایفی که هیچ مدل واحدی به تنهایی قادر به انجام آنها نیست، هماهنگ میکنند. نتایج میتواند خیرهکننده باشد. یک عامل تحقیق میکند، دیگری پیشنویس مینویسد، سومی حقایق را بررسی میکند و چهارمی خروجی نهایی را قالببندی میکند. اما در پس تمام این هماهنگیها، یک وابستگی شکننده نهفته است. اگر اولین قدم، یعنی تبدیل ورودی انسان به دستورالعملهای قابل خواندن برای ماشین، کند یا نادقیق باشد، کل زنجیره از هم میپاشد. یک عامل پاییندست نمیتواند دادههای بیارزش (garbage) را اصلاح کند؛ او فقط میتواند آنها را منتشر کند.
این گلوگاه دقیقاً همان جایی است که Iflytek/domux وارد عمل میشود. این یک مدل متنباز است که دقیقاً برای یک وظیفه حساس ساخته شده است: درک سریع دستورات. domux به جای تولید مقالات یا انجام گفتگوهای باز، زبان طبیعی را تجزیه کرده و دادههای ساختاریافته و صلب (rigid) را صادر میکند که سایر عوامل میتوانند بلافاصله از آنها استفاده کنند. هر سیستمی که به ورودی ساختاریافته در لحظه (real-time) نیاز دارد، از هابهای خانه هوشمند گرفته تا پانلهای کنترل صنعتی، میتواند از آن به عنوان یک لایه ادراکی استفاده کند.
ضعیفترین حلقه در زنجیره
تصور کنید وقتی کاربر یک دستور ساده مانند «اینجا را روشنتر کن» میدهد، چه اتفاقی میافتد. در یک ساختار چندعاملی، این عبارت ممکن است نیاز داشته باشد از یک کنترلکننده روشنایی، یک مانیتور انرژی و یک ثبتکننده امنیتی عبور کند. اگر تجزیهکننده (parser) اولیه، جملهای مبهم مانند «کاربر نور بیشتری میخواهد» را برگرداند، هر عامل بعدی مجبور است معنا را دوباره تفسیر کند. برخی ممکن است در انتظار پارامترهای دقیق متوقف شوند، و برخی دیگر ممکن است اتاق یا سطح روشنایی را حدس بزنند و اشتباه کنند. در این صورت، جریان کار از حرکت باز میایستد.
تأخیر (Latency) مشکل را بدتر میکند. اگر چند صد میلیثانیه تأخیر در تجزیه در نقطه ورود اضافه شود، تا زمانی که اطلاعات به عامل سوم برسد، سیستم از قبل خراب به نظر میرسد. محیطهای بیدرنگ (Real-time) شروعهای کند را نمیبخشند. توسعهدهندگان در حال کشف این هستند که چارچوبهای هماهنگسازی (orchestration frameworks) در نمودارهای معماری بسیار زیبا به نظر میرسند، اما وقتی با ورودیهای مبهم یا کند مواجه میشوند، فرو میپاشند. شما به یک لایه اختصاصی نیاز دارید که دستورات را قبل از اینکه بقیه جریان کار حتی شروع به فکر کردن کنند، استانداردسازی کند.
Domux برای تبدیل شدن به همان لایه طراحی شده است. این مدل زبان نامنظم انسانی را میپذیرد و آن را به یک طرحواره (schema) تمیز تبدیل میکند که عوامل پاییندست میتوانند آن را به عنوان حقیقت پایه (ground truth) در نظر بگیرند.
سرعت، ساختار و دقت
این پروژه سه ویژگی را تبلیغ میکند که مستقیماً بر عملکرد در محیط عملیاتی تأثیر میگذارند.
اول، در کمتر از ۱۵۰ میلیثانیه پاسخ میدهد. این آستانه بسیار مهم است. در تنظیمات تعاملی، پاسخی که کمتر از یکچهارم ثانیه طول بکشد، آنی به نظر میرسد، در حالی که هر چیزی که به یک ثانیه نزدیک شود، کاربران را عادت میدهد که ابزار را رها کنند. چه ورودی از طریق صدا باشد و چه از طریق رابط چت، domux جریان کار را روان نگه میدارد.
دوم، ورودیها را به یک طرحواره سختگیرانه با هفت فیلد نگاشت میکند. هیچ متن آزادی برای سیستمهای پاییندست جهت رمزگشایی وجود ندارد. هر دستور در ستونهای قابل پیشبینی قرار میگیرد.
سوم، ادعا میکند که دقت ۹۸.۳۷ درصدی در کنار انطباق ۱۰۰ درصدی با فرمت دارد. دقت یعنی مدل معمولاً کاربر را به درستی درک میکند. انطباق با فرمت یعنی خروجی در هر بار، از نظر ساختاری معتبر است. تجزیهکنندهای که ۹۹ درصد دقیق است اما گاهی یک فیلد را حذف میکند یا فیلد جدیدی از خود میسازد، در یک زنجیره خودکار یک عامل خطر محسوب میشود. یک ردیف بدشکل میتواند یک عامل مصرفکننده را از کار بیندازد.
در اینجا ظاهر واقعی خروجی آمده است. وقتی مدل یک دستور را پردازش میکند، یک رکورد جدا شده با کاراکتر | (pipe-delimited) را برمیگرداند:
action|device|attribute|value|unit|room|floor
turnOn|light|brightness|80|percent|living room|ground floor
این فرمت عامدانه انتخاب شده است. متن جدا شده با | در هر زبان برنامهنویسی بدون نیاز به وابستگیهای سنگین، به راحتی قابل تجزیه است. این روش از حجیم شدن JSON و تأخیر ناشی از سریالسازیهای تو در تو جلوگیری میکند. یک عامل روشنایی میتواند ستونهای action و device را بخواند و بلافاصله عمل کند. یک عامل ثبت وقایع (logging) میتواند اتاق و طبقه را بدون اجرای یک مرحله استنتاج (inference) دیگر استخراج کند. این ساختار به گونهای طراحی شده که ابهام را از بین ببرد.
مدیریت قصد و نیت مبهم انسان
انسانهای واقعی مانند مستندات API صحبت نمیکنند. آنها چیزهایی مثل «اینجا را روشنتر کن» یا «اینجا را گرمتر کن» میگویند. یک تجزیهکننده شکننده در برابر این جملات شکست میخورد. Domux با نگاشت نیت (intent) به یک اقدام اصلاحی و اجازه دادن به سیستمهای پاییندست برای تعیین مقدار دقیق، این ابهام را مدیریت میکند. اگر کسی بگوید «اینجا را روشنتر کن»، مدل اقدام را به عنوان «افزایش روشنایی» شناسایی میکند. سطح عددی دقیق بر عهده عامل روشنایی گذاشته میشود تا بر اساس خوانشهای فعلی، زمان روز یا... تعیین کند.