تصور کنید برنامه‌نویسی هستید که می‌خواهد تمام ابزارهای کدنویسی خود را از فضای ابری به یک سخت‌افزار کوچک در میز کارش منتقل کند تا دیگر نگران اشتراک‌ها یا محدودیت‌های API نباشد. این رویای «حاکمیت محاسباتی» در تجربه اخیر یک توسعه‌دهنده با مدل Gemma 4 2B روی سخت‌افزار Jetson Orin Nano به چالشی جدی برخورد کرد. این توسعه‌دهنده ده روز تمام را صرف این کرد که مدل Gemma 4 2B را برای نوشتن کدهای واقعی در محیط عملیاتی به چالش بکشد و در نهایت کشف کرد که شکست اصلی مدل نه در منطق درونی آن، بلکه در «هارنس» (Harness) یا همان چارچوب محیطی است که مدل را احاطه کرده است.
طبق گزارشی که در ۲ ژوئیه ۲۰۲۶ در وب‌سایت dev.to منتشر شد، هدف این آزمایش ایجاد یک جایگزین محلی با هزینه نهایی صفر (zero-marginal-cost) بود تا جایگزین ابزارهای متکی به ابر مانند Claude Code شود. این تلاش برای حذف هزینه‌های اشتراکی، در راستای رویکردهایی است که پیش‌تر برای بهینه‌سازی هزینه‌های تحلیل تصویر در محیط‌های محلی نیز دیده شده بود. هدف نهایی ساخت سیستمی بود که برای همیشه روی سخت‌افزاری باشد که کاربر مالک آن است و هرگز اجازه استفاده از مدل‌های ابری به عنوان پشتیبان (fallback) را نداشته باشد؛ در این معماری، اگر یک مدل کوچک شکست می‌خورد، کار باید تجزیه می‌شد یا به کد قطعی (deterministic) تبدیل می‌گشت، نه اینکه سطح مسئله به یک مدل بزرگ‌تر ارتقا یابد.
این رویکرد در حالی مطرح می‌شود که صنعت به سمت هوش مصنوعی حاکمیتی (Sovereign AI) — یعنی مالکیت کامل پشته فناوری برای دوری از هزینه‌های اشتراکی و محدودیت‌های نرخ درخواست (rate limits) — حرکت می‌کند. پروژه‌هایی مانند little-coder و تحقیقات انویدیا روی مدل‌های کوچک، همگی بر سر یک شرط‌بندی مشابه هستند: مدل‌های کوچک اغلب در کارهای عامل‌محور (agentic) ضعیف عمل می‌کنند، اما نه به دلیل ناتوانی ذاتی مدل، بلکه چون هارنس‌های آن‌ها بیش از حد ساده و نازک است. برای بسیاری، انتقال از مدل‌های عظیم پیشرو (Frontier Models) به مدل‌های زبانی کوچک (SLM) به عنوان حرکتی به سمت کارایی دیده می‌شود، هرچند این انتقال اغلب یک «آستانه توانمندی» پنهان ایجاد می‌کند که الگوهای استاندارد عامل‌محور را می‌شکند.
شکاف کارایی در لایه‌ی اجرا
پژوهشگر دریافت که لایه‌ی اجرا (Harness) — یعنی همان چارچوبی که مدل را در بر می‌گیرد و ورودی/خروجی را مدیریت می‌کند — اغلب پاسخ‌های درست را دور می‌اندازد. به نقل از این گزارش، حدود ۶۰٪ شکست‌های اولیه مدل نه به‌دلیل منطق غلط، بلکه به‌خاطر مشکل «تورفتگی» (Indentation) در کد بود. چون ماژول کد به‌درستی وارد (import) نمی‌شد، سیستم آن را شکست تلقی می‌کرد، حتی اگر منطق برنامه در پس‌زمینه کاملاً درست بود و پاسخ صحیح در متن وجود داشت.
برای حل این مشکل، توسعه‌دهنده قانونی تعریف کرد: فقط زمانی که خروجی مدل قابل تجزیه (Parse) نباشد، هارنس از مدل بخواهد که کد خود را دوباره از نظر تورفتگی اصلاح کند، در حالی که منطق کد کاملاً دست‌نخورده باقی بماند. نتایج این تغییر بسیار چشم‌گیر بود:
- نرخ موفقیت در تست‌ها از ۶۴ مورد به ۷۶ مورد از ۱۰۰ رسید.
- در ۵۰ مسئله‌ای که مدل هرگز روی آن‌ها تنظیم نشده بود (held-out problems)، نرخ موفقیت از ۳۱ به ۳۸ مورد افزایش یافت.
برنامه‌ریزی در برابر اجرا
یک یافته حیاتی این است که «برنامه‌ریزی باز» (Open-ended planning) ضعیف‌ترین نقطه مدل‌های ۲ میلیارد پارامتری است. پژوهشگر مشاهده کرد که مدل 2B در انجام یک وظیفه چندمرحله‌ای شکست می‌خورد؛ در حالی که مدل در واقعیت می‌توانست کد اصلاحی لازم را بنویسد، اما برنامه‌ریزی‌اش اصلاً شامل مرحله‌ی «اصلاح» نمی‌شد؛ مدل در واقعیت دورِ کار اصلی برنامه‌ریزی می‌کرد و آن را نادیده می‌گرفت.
تضاد شدیدی میان دو نوع وظیفه وجود داشت:
- کم‌اعتمادترین: برنامه‌ریزی باز (مثلاً پرسیدن «چه مراحلی را باید طی کنم؟»).
- معتمدترین: پر کردن جاهای خالی محدود (مثلاً «این تابع ناقص را طوری بنویس که تست را پاس کند»).
برای رفع این نقص، توسعه‌دهنده تصمیم گرفت که دیگر به‌طور کلی از مدل نخواهد که برنامه‌ریزی کند. اکنون جریان کنترل توسط یک برنامه قطعی (deterministic program) مدیریت می‌شود و مدل فقط وظیفه پر کردن شکاف‌ها (slots) را دارد. در سناریوهای چندمرحله‌ای، این تغییر استراتژیک نرخ موفقیت را از ۲/۳ به ۳/۳ رساند. علاوه بر این، اکنون تنها «کد خروج تست» (test exit code) به عنوان داور نهایی پذیرفته می‌شود و جملاتی نظیر «به نظر خوب می‌رسد» که مدل در مورد کار خود می‌گوید، کاملاً نادیده گرفته می‌شود.
شکست «مدل به‌مثابه داور»
الگوهای استاندارد بازتاب (Self-reflection) — جایی که مدل کار خودش را بررسی می‌کند — در این مقیاس نتیجه معکوس داشت و باعث کاهش عملکرد شد. مدل Gemma 4 2B بارها کدی را که تست‌هایش پاس شده بود می‌گرفت، به اشتباه ادعا می‌کرد که شکافی در پاسخ وجود دارد و آن را بازنویسی می‌کرد، به‌طوری که در نهایت کد جدید شکست می‌خورد.
این موضوع نشان می‌دهد که الگوی «بررسی و سپس ثبت» (review-then-commit) در حالی که برای مدل‌های بزرگ کاربرد دارد، در مدل‌های 2B با یک «آستانه توانمندی» برخورد می‌کند. این یعنی مدل‌به‌مثابه-داور یک الگوی جهانی نیست که در هر مقیاسی درست باشد، بلکه برای اثرگذاری به حداقل اندازه مشخصی از مدل نیاز دارد. چون مدل 2B زیر این آستانه قرار دارد، مرحله بازتاب به جای کمک، به یک بدهی (liability) و عامل شکست تبدیل شد.
آزمون و خطای مهندسی پرامپت
همه بهینه‌سازی‌های بصری و شهودی نتیجه ندادند. چندین ایده که در ظاهر «خوب» به نظر می‌رسیدند، روی داده‌های آزمونی اثر منفی یا خنثی داشتند:
- افزایش مطلق حجم متن زمینه (Context): هیچ بهبودی ایجاد نکرد.
- نمونه‌های اندک (Few-shot): روش بدون نمونه (Zero-shot) در واقعیت عملکرد بهتری داشت.
- تولید نمونه‌های بازیابی-افزا (RAG): نتایج کاملاً تخت و خنثی بود.
- نمونه‌گیری Best-of-N: تنها منجر به تولید نویز خالص شد.
نویزهای موجود در اجراهای متوالی (run-to-run noise) یک بار باعث شد که یک تغییر منفی در پرامپت، به اشتباه شبیه به یک پیروزی ۶ درصدی (+6%) به نظر برسد. این اتفاق باعث شد توسعه‌دهنده یک سیستم ارزیابی قطعی با دمای (Temperature) صفر روی داده‌های آزمونی ساخته تا مطمئن شود هر ادعایی از نظر فنی صحت دارد و در برابر تست‌های سخت‌گیرانه دوام می‌آورد.
برخورد با دیوار واقعیت
در حالی که هارنس در توابع تک‌منظوره (سبک HumanEval) عالی عمل می‌کرد (که احتمالاً به دلیل آلودگی داده‌های بنچمارک در داده‌های آموزشی مدل است)، مخازن واقعی کد (real-world repositories) ورق را برگرداندند. پژوهشگر یک سیستم «بازپخش کامیت» (commit-replay eval) ساخت: تاریخچه گیت یک پروژه واقعی را گرفت، تنها کامیت‌هایی را که تست‌ها را از وضعیت قرمز (شکست) به سبز (پاس) تغییر داده بودند جدا کرد و از هارنس خواست فقط با خواندن «پیام کامیت»، آن تغییر را بازسازی کند. این ارزیابی در محیط Docker با تست‌های پنهان انجام شد تا از هرگونه نشت داده جلوگیری شود.
در ۴۰۰ کامیت یک کتابخانه، تنها ۳۷ مورد به‌طور کامل قابل بررسی بودند و روند موفقیت به شرح زیر بود:
- نتیجه تک‌مرحله‌ای (One-shot): ۱ مورد از ۳۷ (حدود ۳٪).
- اصلاح ساختاری: اعمال تمام توابی که کامیت تغییر داده بود (نه فقط اولین تابع)، موفقیت را به ۴ از ۳۷ (حدود ۱۱٪) رساند.
- جریان مشخصات-محور (Spec-first flow): مدل ابتدا یک مشخصه رفتاری (behavior spec) بر اساس هدف می‌نویسد، سپس تست‌ها را بر اساس آن مشخصه می‌سازد و در نهایت کد را بر اساس تست‌ها می‌نویسد؛ این روش موفقیت را به ۶ از ۳۷ (حدود ۱۶٪) رساند.
بررسی ۷ مورد سخت نشان داد که حتی با ۲۰ نمونه‌گیری در دمای مناسب، هیچ پاسخ صحیحی تولید نشد. این یعنی پاسخ درست اصلاً در توزیع احتمالات مدل نیست؛ این یک «دیوار تولید» است و نه مشکل مهندسی پرامپت. این موضوع یک شکاف عظیم ایجاد می‌کند: موفقیت ۸۰ درصدی در توابع ساده در برابر موفقیت حدود ۱۰ درصدی در کامیت‌های واقعی.
مسیریابی میان مدل‌ها
برای پوشش نقاط کور، مدل Qwen 3B Coder وارد میدان شد تا مشخص شود آیا مدل‌های کوچک مختلف می‌توانند نقاط ضعف یکدیگر را بپوشانند. این مدل در کنار ابزارهایی مانند Ollama، امکان استقرار یک پشته کدنویسی کاملاً محلی و خصوصی را فراهم می‌کند. در تولید توابع مستقل با استفاده از محک MBPP (که به‌طور خاص برای دوری از آلودگی HumanEval انتخاب شده بود)، کوئن واقعاً برتری داشت:
- Qwen 3B Coder: ۶۵٪ موفقیت.
- Gemma 4 2B: ۴۸٪ موفقیت (که بدون گیت استدلال به ۲۵٪ می‌رسید).
اما در کلاس پیچیده مخازن واقعی، کوئن هم دقیقاً در همان جاهایی شکست خورد که گما شکست خورده بود. این نشان می‌دهد که مدل‌های مشابه، شکست‌های همبسته (correlated failures) دارند و افزودن مدل‌های هم‌اندازه کمکی به عبور از «دیوار» نمی‌کند. برای این منظور، متنوع کردن معماری‌ها ضروری است. پژوهشگر اکنون در حال ارزیابی مدل Phi-4 است و از یک گیت تست قطعی برای انتخاب برنده استفاده می‌کند، به‌جای اینکه اجازه دهد یک مدل درباره مدل دیگر قضاوت کند.
این آزمایش تمرکز را از «آیا مدل‌های کوچک می‌توانند جایگزین مدل‌های عظیم شوند؟» به «کدام بخش‌های توسعه واقعاً قابل تفویض به آن‌ها هستند؟» تغییر داد. هرچند مدل‌های کوچک در پیشرفت هستند، اما تحلیل‌های مقایسه‌ای نشان می‌دهد که مدیریت مخازن کد پیچیده همچنان حوزه‌ی تسلط مدل‌های پیشرونماینده است. این نتایج پیشنهاد می‌کند که در حالی که می‌توانیم «جای خالی‌های محدود» در کدنویسی را خودکار کنیم، سنتز معماری در سطح بالا همچنان یک توانمندی در سطح مدل‌های پیشرو (Frontier-tier) باقی مانده است. هدف نهایی این است که بدانیم آیا سخت‌افزاری با قیمت چند صد دلار می‌تواند جایگزینی پذیرفتنی برای «اجاره تفکر» از چند شرکت بزرگ باشد.
گام بعدی شما
- اگر از مدل‌های کوچک برای کدنویسی استفاده می‌کنید، برنامه‌ریزی (Planning) را از مدل بگیرید و آن را به صورت یک برنامه قطعی در لایه بیرونی پیاده کنید.
- برای ارزیابی مدل‌ها، به جای اعتماد به توصیفات مدل («به نظر درست است»)، یک سیستم تست خودکار (CI) در محیط Docker راه اندL ازی کنید.
- در صورت شکست مدل‌های 2B، به جای مهندسی پرامپت، سعی کنید وظیفه را به «جای خالی‌های» کوچک‌تر و محدودتر تقسیم کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو