ACRouter یاد می‌گیرد هر کار را به مدل مناسب هوش‌مصنوعی بسپارد

در دنیای هوش مصنوعی سازمانی، یک وسوسه ساده وجود دارد: هر کار سختی را بدهیم به قوی‌ترین و گران‌ترین مدل. مثل این است که برای هر جابه‌جایی، حتی خرید نان از سر کوچه، کامیون سنگین اجاره کنیم. جواب می‌دهد، اما وقتی تعداد درخواست‌ها زیاد شود، هزینه‌ها بی‌رحمانه بالا می‌رود. اینجاست که ایده «مسیریابی مدل» اهمیت پیدا می‌کند؛ یعنی سیستمی که تصمیم بگیرد هر درخواست باید به کدام مدل سپرده شود: یک مدل ارزان و سریع، یا یک مدل پیشرفته و گران.

مشکل اینجاست که بیشتر مسیریاب‌های فعلی بیش از حد خشک و ثابت‌اند. بعضی با قوانین دستی کار می‌کنند؛ مثلاً اگر در متن درخواست چند کلمه خاص بود، آن را به GPT-۵.۵ بفرستند و اگر نبود، به یک مدل متن‌باز مثل Kimi K۲.۷ بدهند. بعضی دیگر هم با سیاست‌های آموزش‌دیده ثابت کار می‌کنند؛ یعنی بر اساس داده‌های قدیمی یاد گرفته‌اند کدام مدل برای کدام نوع درخواست مناسب است. اما هر دو روش یک ضعف جدی دارند: بعد از اجرا نمی‌فهمند آیا مدل واقعاً موفق شد یا نه.

چارچوب تازه Agent-as-a-Router دقیقاً همین نقطه کور را هدف گرفته است. ایده اصلی ساده اما مهم است: مسیریاب نباید فقط از روی متن ورودی حدس بزند؛ باید مثل یک کارمند باتجربه، از تجربه‌های قبلی‌اش یاد بگیرد. این سیستم با چرخه Context-Action-Feedback یا C-A-F کار می‌کند. اول زمینه درخواست را می‌سنجد، بعد از حافظه‌اش نمونه‌های مشابه گذشته را بیرون می‌کشد، سپس مدل مناسب را انتخاب می‌کند و در نهایت نتیجه واقعی کار را می‌بیند: موفق شد یا شکست خورد؟ همین بازخورد دوباره وارد حافظه می‌شود تا تصمیم بعدی بهتر شود.

برای نمونه، فرض کنید یک سیستم تحلیل داده سازمانی باید یک کوئری SQL تولید کند. مسیریاب ابتدا آن را به یک مدل متن‌باز مثل Kimi می‌دهد، اما مدل نام یک ستون را اشتباه حدس می‌زند و کد اجرا نمی‌شود. در سیستم‌های قدیمی، این شکست شاید هیچ‌وقت به مسیریاب برنگردد. اما در ACRouter، خطای کامپایل یا اجرای کوئری ثبت می‌شود و دفعه بعد، اگر درخواست مشابهی بیاید، سیستم می‌فهمد بهتر است آن را به مدلی قوی‌تر مثل Claude Opus ۴.۸ بسپارد. این همان تفاوت میان «حدس زدن» و «یاد گرفتن از زمین بازی» است.

ACRouter سه بخش اصلی دارد: Orchestrator، Verifier و Memory. بخش Memory حافظه تاریخی سیستم است و با یک پایگاه برداری، تجربه‌های مشابه قبلی را پیدا می‌کند. Orchestrator تصمیم‌گیرنده است و با توجه به درخواست کاربر و حافظه بازیابی‌شده، مدل هدف را انتخاب می‌کند. Verifier هم نقش داور را دارد؛ خروجی مدل را در محیط واقعی مثل مفسر پایتون، سندباکس عامل‌محور یا موتور پایگاه داده اجرا و بررسی می‌کند تا یک سیگنال روشن موفقیت یا شکست بسازد. نکته جذاب این است که خود Orchestrator غول‌پیکر نیست؛ پژوهشگران از یک آداپتر زیر یک میلیارد پارامتر بر پایه Qwen ۳.۵ با ۰.۸ میلیارد پارامتر استفاده کرده‌اند، یعنی می‌تواند روی زیرساخت دلخواه خود شرکت‌ها هم میزبانی شود.

نتایج بنچمارک‌ها نشان می‌دهد چرا ایده «یک مدل برای همه‌چیز» در مقیاس سازمانی شکننده است. در CodeRouterBench، حدود ۱۰,۰۰۰ وظیفه با امتیازهای قابل‌راستی‌آزمایی روی ۸ مدل پیشرفته از جمله Claude Opus ۴.۶، GPT-۵.۴، Qwen۳-Max و GLM-۵ بررسی شد. هیچ مدلی در همه زمینه‌ها بهترین نبود. حتی Claude Opus ۴.۶ که بهترین میانگین عملکرد را داشت، در طراحی الگوریتم از GLM-۵ عقب افتاد و در تولید تست از Qwen۳-Max شکست خورد؛ درحالی‌که Opus تقریباً ۱۲ برابر مدل‌های کوچک‌تری مثل Kimi-K۲.۵ هزینه داشت. در تست درون‌توزیع، ACRouter کل اجرا را با ۱۳.۲۱ دلار انجام داد، درحالی‌که سپردن همه کارها به Opus حدود ۳۴.۰۲ دلار خرج داشت؛ یعنی ۲.۶ برابر صرفه‌جویی.

البته این نسخه جادویی برای همه کارها نیست. ACRouter وقتی می‌درخشد که خروجی قابل راستی‌آزمایی باشد؛ مثل کدنویسی، تولید کوئری، بازیابی داده یا کارهایی که محیط اجرا می‌تواند بگوید «درست بود» یا «اشتباه بود». برای کارهای کم‌حجم یا ساده، ساخت چنین زیرساختی شاید زیادی سنگین باشد. برای حوزه‌های سلیقه‌ای مثل نویسندگی خلاق هم مشکل دارد، چون موفقیت را نمی‌شود به‌راحتی با یک سیگنال استاندارد اندازه گرفت. بااین‌حال، برای شرکت‌هایی که با حجم بالای کارهای فنی و تغییر مداوم مدل‌ها روبه‌رو هستند، این ایده می‌تواند جایگزین نسل قدیمی قوانین خشک و پرهزینه شود.