چرا ترکیب مدل‌های کوچک، رفتارهای انسانی‌تر از مدل‌های غول‌پیکر می‌سازد؟

اگر در حال توسعه‌ی عامل‌های هوش مصنوعی هستید، بزرگ‌ترین اشتباه این است که تصور کنید تنها راه رسیدن به پویایی‌های اجتماعی پیچیده، استفاده از یک مدل غول‌پیکر است. در ۶ ژوئن ۲۰۲۶، یک گزارش فنی جزئیات ساخت «Thousand Token Wood v2» را منتشر کرد؛ شبیه‌سازی مالی که در آن عامل‌هایی از چهار آزمایشگاه مختلف در یک اقتصاد مجازی با هم رقابت کرده و همکاری می‌کنند.

نسخه‌ی اول Thousand Token Wood یک «سندباکس خدای آب‌وهوا» بود که از پنج موجود جنگلی روی یک مدل ۰.۵ میلیارد پارامتری تنظیم‌شده (fine-tuned) استفاده می‌کرد. اگرچه آن نسخه حباب‌های اقتصادی و سقوط‌های بازار را نشان می‌داد، اما بیشتر شبیه به تماشای یک آکواریوم بود تا یک بازی واقعی. اما در نسخه‌ی دوم، این محیط به بازی‌ای تبدیل شده که بازیکن آن را هدایت می‌کند. شما در نقش «حامی جنگل» (Patron of the Wood) وارد می‌شوید؛ یک تامین‌کننده‌ی مالی در سایه که وام می‌دهد، رشوه می‌گیرد، اتحادها را مدیریت می‌کند و روی بازار شرط‌بندی (shorting) می‌کند. شما می‌توانید اطلاعاتی را نجوا کنید که ممکن است واقعی باشند یا صرفاً کاشته شده باشند، در حالی که یک دادگاه (magistrate) به دنبال شماست تا معاملات بر اساس دانش غیرقانونی را شناسایی کند.

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

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مدیریت جریان داده در مدل‌های کوچک چالش‌برانگیز است. این شبیه‌سازی روی چهار مدل مجزا اجرا می‌شود:

• gpt-oss-20b (OpenAI): که با کوانتیزاسیون بومی MXFP4 روی یک GPU L4 با حافظه ۲۴ گیگابایت اجرا می‌شود. این مدل از فرمت کانالی استفاده می‌کند که پاسخ‌ها را در یک مقدمه‌ی تحلیلی می‌پیچد و مصرف‌کننده باید کانال نهایی را استخراج کند.
• MiniCPM3-4B (OpenBMB): که نیاز به پیکربندی trust_remote_code داشت.
• Nemotron-Mini-4B (NVIDIA): که بدون مشکل و به‌صورت پاک بارگذاری شد.
• یک مدل Qwen 0.5B که به‌صورت اختصاصی تنظیم دقیق (Fine-tuning) — شبیه وقتی که به یک پزشک عمومی، تخصص پوست می‌دهیم تا روی یک حوزه دقیق شود — شده است.

اصطکاک در لایه‌ی سرویس‌دهی

بر اساس مستندات فنی، فرآیند مهندسی نشان داد که اصلی‌ترین اصطکاک در لایه‌ی سرویس‌دهی (serving layer) بود، نه در لایه‌ی مدل‌سازی. تیم متوجه شد که vLLM (نسخه‌ی ۰.۲۲.۱) در تمام مدل‌ها شکست می‌خورد؛ دلیل آن این بود که vLLM برای کامپایل JIT کرنل‌ها در لحظه‌ی بارگذاری، به CUDA toolkit (nvcc) نیاز دارد. این وابستگی در ایمیج‌های پایه و سبک وجود نداشت و باعث می‌شد هر چهار مدل با خطای «could not find nvcc» متوقف شوند. تغییر به یک ایمیج CUDA devel کل مسیر را باز کرد.

پایداری و تجزیه داده‌ها

برای حفظ پایداری شبیه‌سازی، نویسنده یک لایه‌ی «تجزیه و ترمیم JSON» (tolerant JSON parse-and-repair) طراحی کرد. چون توکنایزرهای مختلف و عادت‌های فرمت‌بندی متفاوت، باعث ایجاد نقص‌های مختلف در خروجی می‌شوند، این لایه داده‌های غیرقابل نجات را حذف می‌کند. این یعنی شبیه‌سازی هرگز کرش نمی‌کند، فارغ از اینکه کدام مدل در حال صحبت است. ساخت این لایه در یک مرحله باعث شد که اضافه کردن مدل جدید تنها یک تغییر ساده در تنظیمات (config entry) باشد، نه یک بازنویسی کامل کد.

دیوار آتش اطلاعات

یکی از مکانیک‌های اصلی بازی، «نکات داخلی» (insider tips) است که توسط بازیکن داده می‌شود. شما می‌توانید یک پیش‌بینی واقعی (پیش‌بینی واقعی از مانیای بعدی بازار) یا یک طعمه‌ی جعلی بدهید. عمل بر اساس نکات واقعی، «میزان حساسیت» (Heat) شما را بالا می‌برد و در صورت عبور از یک حد مشخص، تحقیقات دادگاه را فعال می‌کند که می‌تواند منجر به جریمه، مسدود شدن دارایی‌ها یا تبعید شود.

برای جلوگیری از لو رفتن این اسرار توسط عامل‌ها، نویسنده با این مشکل نه به عنوان یک مسئله‌ی پرامپت، بلکه به عنوان یک حفره‌ی امنیتی (security vulnerability) برخورد کرد. مدل‌های کوچک مستعد تکرار هر چیزی هستند که در پرامپت آن‌ها قرار دارد. برای حل این موضوع:

• «پرچم حقیقت» (truth flag) یک نکته، کاملاً خارج از پرامپت و در دفتر کل (ledger) بازیکن ذخیره می‌شود.
• این پرچم هنگام ساخت رکورد رویدادهای عمومی، از متن حذف می‌شود.
• راوی فقط رویدادهای عمومی را خلاصه می‌کند.

برای تایید این سازوکار، سیستمی طراحی شده که هر نوبت، تمام پرامپت‌های کامل هر موجود را برای یافتن توکن‌های ممنوعه اسکن می‌کند. این مهم‌ترین تست در کل مجموعه است که ثابت می‌کند اطلاعات محرمانه نمی‌توانند نشت کنند.

حل مشکل تورم پرامپت

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

این خلاصه از امتیازات عددی احساسات (integer sentiment scores) استخراج شده و فقط به چند مورد از قوی‌ترین احساسات محدود می‌شود. در حالی که یادداشت‌هایی برای ردیابی نگه داشته می‌شوند، اما این یادداشت‌ها محدود هستند و هرگز به مدل نشان داده نمی‌شوند. این رویکرد مکانیکی باعث می‌شود سوگیری‌های رفتاری — مثل اینکه یک موجود خشمگین به‌صورت قطعی درخواست وام را رد کند یا موجودات متحد مانند یک کارتل رفتار کنند — قابل مشاهده و تست باشد، نه یک ویژگی تصادفی و امیدوارکننده.

نتایج و دستاوردهای کلیدی

اجرای یک شورای نمونه روی Modal نتایج زیر را نشان داد:

• قابلیت اعتماد مدل ۰.۵ میلیاردی: صفر درصد خرید خودکار (self-buys) و ۱۰۰٪ پیشنهادهای معتبر، که حتی از مدل معلم ۳ میلیارد پارامتری خود بهتر عمل کرد.
• دیوار آتش حقیقت: صفر مورد نشت پرچم مخفی یک نکته در تمام اسکن‌های پرامپت.
• مزیت اطلاعات داخلی: پیش‌بینی‌های درست منجر به سود و زیان (P&L) مثبت شد، در حالی که نکات جعلی چنین اثری نداشتند.
• مکانیک حساسیت: دو پیروزی مشکوک با موفقیت خط قرمز دادگاه را رد کردند.
• ورشکستگی: فراخوان‌های حاشیه (Margin calls) و نکول وام‌ها باعث اخراج موجودات شد که یک فصل بعد بازگشتند.

برای توسعه‌دهندگان، این پروژه ثابت می‌کند که مدل‌های کوچک تولیدکننده‌ی فرمت‌های قابل‌اعتماد هستند اما استدلال‌گران (reasoners) ضعیفی‌اند. این شکاف نه با بزرگ‌تر کردن مدل، بلکه با پیاده‌سازی ساختارهای سخت داده، پرامپت‌های دقیق و مقدار کمی تنظیم دقیق پر می‌شود.

این معماری نشان می‌دهد که یک شورای ناهمگون از مدل‌های کوچک، جذاب‌تر و از نظر محاسباتی بهینه‌تر از یک مدل غول‌پیکر است. تمرکز را از «مهندسی پرامپت» به «مهندسی جریان داده» منتقل می‌کند. اکنون می‌توانید تمام شورا و ردهای اجرایی (execution traces) را بررسی کنید تا ببینید این «ذهن‌های» مختلف چگونه در لحظه با هم تعامل می‌کنند.

گام بعدی شما

• اگر عامل‌های AI می‌سازید، به جای یک مدل بزرگ، ترکیبی از مدل‌های کوچک (مثل Qwen و Phi) را برای نقش‌های مختلف امتحان کنید.
• برای مدیریت حافظه در مدل‌های کوچک، از «خلاصه‌سازهای عددی» به جای ارسال کل تاریخچه گفتگو استفاده کنید.
• لایه‌ی اعتبارسنجی JSON را به عنوان یک استاندارد در خروجی مدل‌های کوچک قرار دهید تا پایداری سیستم تضمین شود.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.