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

صنعت هوش مصنوعی مدت‌ها درگیر مسابقه‌ای ساده بود: چه کسی «بهترین مدل» را دارد؟ اما برای شرکتی که هزاران یا میلیون‌ها درخواست واقعی را اجرا می‌کند، سؤال اقتصادی‌تر کمی متفاوت است. آیا واقعاً لازم است یک سؤال ساده، یک کوئری SQL معمولی و یک مسئله پیچیده برنامه‌نویسی همگی به گران‌ترین مدل موجود فرستاده شوند؟ همین مسئله باعث شده «مسیریابی مدل» به بخشی مهم از زیرساخت هوش مصنوعی سازمانی تبدیل شود؛ سیستمی که تلاش می‌کند هر کار را به سریع‌ترین، ارزان‌ترین یا توانمندترین مدل مناسب آن کار بسپارد. مشکل اینجاست که بسیاری از مسیریاب‌های امروزی هنوز مثل مأموری رفتار می‌کنند که فقط ظاهر بسته را می‌بیند و بدون اینکه بفهمد ارسال قبلی موفق بوده یا نه، تصمیم می‌گیرد مقصد بعدی کجا باشد.

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

چارچوب Agent-as-a-Router می‌خواهد این رابطه را شبیه یادگیری یک مدیر باتجربه کند. این سیستم از چرخه‌ای به نام Context-Action-Feedback یا «زمینه، اقدام، بازخورد» استفاده می‌کند. وقتی یک وظیفه جدید می‌رسد، مسیریاب علاوه بر خود درخواست، اطلاعاتی مثل زبان برنامه‌نویسی یا میزان دشواری را بررسی می‌کند و در حافظه‌اش می‌گردد تا ببیند وظایف مشابه قبلاً با کدام مدل موفق یا ناموفق بوده‌اند. سپس یک مدل را انتخاب می‌کند، نتیجه در محیط واقعی اجرا می‌شود و موفقیت یا شکست دوباره به حافظه برمی‌گردد. فرض کنید یک مدل متن‌باز برای تولید SQL انتخاب شود اما نام ستونی را از خودش بسازد و کوئری کامپایل نشود. مسیریاب این شکست را ثبت می‌کند و دفعه بعد، برای مسئله‌ای مشابه شاید سراغ مدلی قدرتمندتر برود. تفاوت اصلی همین‌جاست: سیستم فقط از متن سؤال یاد نمی‌گیرد؛ از عاقبت تصمیم خودش هم درس می‌گیرد.

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

برای آزمایش این ایده، پژوهشگران CodeRouterBench را با حدود ۱۰,۰۰۰ وظیفه و امتیازهای تأییدشده روی ۸ مدل پیشرفته ساختند. آزمون‌ها هم وظایف معمول کدنویسی مانند طراحی الگوریتم و تولید تست را پوشش می‌دادند و هم وظایف عامل‌محور متفاوتی که نیازمند برنامه‌ریزی چندمرحله‌ای، جابه‌جایی میان فایل‌ها و اشکال‌زدایی تکرارشونده بودند. نتیجه یک نکته مهم را برجسته کرد: هیچ مدل واحدی در همه کارها پادشاه نیست. Claude Opus ۴.۶ بالاترین عملکرد متوسط را داشت، اما در طراحی الگوریتم GLM-5 عملکرد نسبی ۸۶ درصد بهتر و در تولید تست Qwen3-Max عملکرد نسبی ۱۱۱ درصد بهتر ثبت کردند. در عین حال، Opus تقریباً ۱۲ برابر مدل‌های کوچک‌تری مانند Kimi-K2.5 هزینه داشت. به زبان ساده، خرید گران‌ترین چاقوی آشپزخانه تضمین نمی‌کند که برای باز کردن هر پیچ هم بهترین ابزار را در دست داشته باشید.

اعداد اقتصادی شاید مهم‌ترین بخش داستان باشند. در مجموعه آزمون درون‌توزیع، هزینه ACRouter برای اجرای کامل وظایف ۱۳.۲۱ دلار بود، در حالی که سپردن همه کارها به Opus هزینه را به ۳۴.۰۲ دلار می‌رساند؛ یعنی حدود ۲.۶ برابر صرفه‌جویی. پژوهشگران همچنین می‌گویند ACRouter در سناریوهای معمول و وظایف پیچیده خارج از توزیع، کمترین «پشیمانی تجمعی» را داشت؛ معیاری برای سنجش اینکه مسیریاب در طول زمان چند بار انتخابی ضعیف‌تر از گزینه مناسب انجام داده است. البته این سیستم داروی همه دردها نیست. بیشترین ارزش آن در کارهایی است که موفقیت را می‌توان به‌طور عینی سنجید؛ مثل اجرای کد یا بازیابی داده. برای کارهای ساده، حجم پایین یا حوزه‌هایی مانند نویسندگی خلاق که پاسخ درست واحدی ندارند، هزینه مهندسی چنین معماری‌ای ممکن است توجیه نداشته باشد. کد این پروژه به‌صورت متن‌باز منتشر شده، وزن‌های مدل Orchestrator نیز تحت مجوز Apache ۲.۰ در دسترس قرار گرفته‌اند و مسیریاب با Claude Code، Codex و OpenCode سازگار است.