Granite 4 در برابر Needle2؛ پیروزی مدل‌های کوچک در موارد لبه‌ای

اگر قصد دارید یک دستیار هوشمند محلی بسازید که دستورات شما به عملیات سیستمی تبدیل کند، احتمالاً به دنبال مدل‌های تخصصی هستید؛ اما واقعیت این است که مدل‌های کوچک‌تر و عمومی گاهی بسیار قابل‌اعتمادتر عمل می‌کنند. در ۱ سپتامبر ۲۰۲۶، آزمایش‌های یک توسعه‌دهنده روی یک پوسته معنایی (Semantic Shell) ثابت کرد که مدل Granite 4 350M در فراخوانی ابزارهای محلی، عملکردی پایدارتر از مدل تخصصی Needle2 دارد. در حالی که Needle2 برای استخراج ساختاریافته و استفاده از ابزارها بازاریابی می‌شود، زمانی که کتابخانه ابزارها از چند مثال ساده به ده‌ها تابع واقعی گسترش یافت، دچار مشکل شد.

ادغام هوش مصنوعی در سطح محلی معمولاً با وعده «نصب و اجرای سریع» (Plug-and-Play) عرضه می‌شود. اما شکاف میان دموهای صیقل‌خورده‌ی API و سیستم‌های عملیاتی معمولاً در بخش‌های «خسته‌کننده» نهفته است: اینکه مدل چگونه شکست می‌خورد، چگونه مقیاس‌پذیر می‌شود و با چه سهولتی به سخت‌افزارهای مختلف منتقل می‌گردد. برای یک پوسته معنایی — جایی که مدل باید قصد کاربر را به یک ابزار خاص مانند filesystem.copy متصل کند — قابلیت اطمینان و ثبات بسیار مهم‌تر از هوش خام است.

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

تله‌ی بازیابی

به نقل از مستندات فنی این آزمایش، مدل Needle2 برای مدیریت فهرست‌های بزرگ ابزار از یک فرآیند دو مرحله‌ای استفاده می‌کند. ابتدا از بازیابی (Retrieval) — شبیه به جست‌وجوی سریع در فهرست کتابخانه برای یافتن چند کاندیدای مرتبط — استفاده می‌کند تا مجموعه‌ای کوچک از ابزارها را انتخاب کند. در مرحله دوم، ابزار نهایی را از میان آن لیست کوتاه برمی‌گزیند.

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

• filesystem.copy
• filesystem.move
• filesystem.delete
• filesystem.create_file
• filesystem.create_directory
• filesystem.list_directory
• filesystem.navigate
• filesystem.current_directory
• filesystem.find

برای دور زدن این ریسک بازیابی، توسعه‌دهنده بررسی کرد که آیا می‌توان ابزارها را به گروه‌های پنج‌تایی تقسیم کرد و تمام گروه‌ها را به صورت متوالی اجرا نمود (گروه ۱ $\rightarrow$ نتیجه، گروه ۲ $\rightarrow$ نتیجه و غیره) تا قوی‌ترین کاندیدا پیدا شود. با این حال، این کار مشکل جدیدی را ایجاد کرد: آیا امتیازات اطمینان (Confidence Scores) از گروه‌های مختلف کاندیدا، به صورت جهانی کالیبره شده و قابل مقایسه هستند؟ بدون وجود مستنداتی در این باره، تکیه بر لیست کوتاه بازیابی ریسکی به نظر می‌رسید. این چالش‌ها نشان می‌دهد که چرا برخی سازمان‌ها برای کاهش خطاهای احتمالی، جایگزینی فراخوانی ابزار با جریان‌های کاری ایستا را به عنوان یک راهکار جایگزین بررسی می‌کنند.

حساسیت مدل‌های کوچک

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

برای اینکه سیستم به‌درستی کار کند، توصیفات باید شبیه به یک مجموعه داده طبقه‌بندی (Classification Dataset) نوشته شوند، نه یک دفترچه راهنما یا مستندات فنی. برای مثال، ابزار «move» باید صراحتاً ذکر کند که آیتم اصلی از منبع حذف می‌شود تا از عملیات «copy» متمایز گردد. همچنین باید شفاف شود که جابه‌جایی یک فایل با تغییر دایرکتوری فعلی پوسته (Shell) یکسان نیست.

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

اصطکاک سخت‌افزاری و ادغام

استقرار عملی در محیط واقعی با موتور اجرای Cactus Engine (که Needle2 از آن استفاده می‌کند) به بن‌بست رسید. توسعه‌دهنده می‌خواست یک ادغام بومی (Native) داشته باشد تا از داشتن یک فرآیند پایتون در کنار برنامه، یک سرویس اضافی یا مدیریت دشوار چرخه حیات (Lifetime Management) اجتناب کند. کتابخانه C++ ایده‌آل به نظر می‌رسید، اما یک مشکل بزرگ در قابلیت حمل (Portability) ایجاد کرد.

توسعه روی یک مک اینتل (Intel Mac) فاش کرد که کد Cactus Engine حاوی دستورات ARM NEON و Intrinsics است که در سراسر کد موتور و هسته پخش شده‌اند. در حالی که این موضوع برای اهدافی مثل iOS، اندروید و اپل سیلیکون منطقی است، اما به این معنی بود که پشتیبانی از x86 صرفاً با فعال کردن یک بک‌اِند متفاوت میسر نمی‌شود. توسعه‌دهنده زمان قابل توجهی را صرف وصله کردن (Patching) موتور کرد تا فقط تعیین کند آیا عملکرد Needle2 اصلاً ارزش هزینه این وابستگی سخت‌افزاری را دارد یا خیر.

جایگزین Granite

استفاده از llama.cpp و مدل Granite 4 350M زیربنای پایدارتری فراهم کرد. این مدل با وجود اینکه یک مدل زبانی کوچک با کاربرد عمومی است، موارد عادی را به‌خوبی مدیریت کرد و مهم‌تر از آن، «با وقار» شکست خورد.

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

طراحی برای عدم قطعیت

این تجربه نشان داد که اگر سیستم پیرامونی ابهامات را مدیریت کند، مدل نیازی به نبوغ ندارد. توسعه‌دهنده جریانی را پیاده کرد که در آن مدل فقط قصد را تشخیص می‌دهد و بقیه کارها بر عهده پوسته است:

• تشخیص قصد (Intent Resolution): مدل ابزار را شناسایی می‌کند (مثلاً filesystem.copy).
• اعتبارسنجی آرگومان‌ها (Argument Validation): پوسته متوجه نبود مسیر منبع یا مقصد می‌شود.
• تعامل با کاربر (User Interaction): پوسته داده‌های ناقص را می‌پرسد یا بین دو ابزار محتمل (مثلاً کپی در برابر جابه‌جایی) گزینه می‌دهد.
• اجرای سیاست (Policy Execution): تایید نهایی پیش از اجرای عملیات.

این معماری تضمین می‌کند که هوش مصنوعی تنها یک قطعه از سیستم است، نه تصمیم‌گیرنده نهایی. با انتقال پیچیدگی اعتبارسنجی آرگومان‌ها و تاییدیه به خارج از مدل، فشار روی LLM برای «بی‌نقص بودن» کاهش یافت.

نیاز به مستندات «لبه‌ای»

این تجربه شکاف بزرگی را در مستندات فعلی هوش مصنوعی آشکار کرد. اکثر مثال‌ها استخراج مبلغ یک فاکتور را نشان می‌دهند، اما نمی‌گویند مدل در مواجهه با مبلغ فرعی (Subtotal)، مالیات، مانده قبلی، خطاهای OCR و تاریخ‌های متعدد در یک صفحه چه می‌کند.

برای یک سیستم تولیدی، توسعه‌دهندگان به پاسخ‌های دقیق برای سوالات «لبه‌ای» (Edge Cases) نیاز دارند:

• نرخ حذف ابزار درست در مرحله بازیابی چقدر است؟
• رفتار امتیاز اطمینان در فراخوانی‌های غلط چگونه است؟
• تنظیم دقیق (Fine-tuning) — شبیه به دادن تخصص پوست به یک پزشک عمومی برای دقیق‌تر شدن در یک حوزه — چقدر در ابزارهای مبهم کمک می‌کند؟
• پشتیبانی بومی واقعی در پلتفرم‌های غیرهدف (فراتر از هدف اصلی) چقدر است؟

این تغییر دیدگاه نشان می‌دهد که برای هوش مصنوعی لبه (Edge AI)، مهم‌ترین معیار، عملکرد در بهترین حالت (Demo) نیست، بلکه «حالت شکست» (Failure Mode) مدل است. مدلی که بداند چه زمانی اشتباه می‌کند، برای اتوماسیون سیستم‌های محلی ارزشمندتر از مدلی است که همیشه جوابی ارائه می‌دهد.

توسعه‌دهندگان اکنون باید فراتر از لیست ویژگی‌ها نگاه کنند و بر این تمرکز کنند که مدل‌ها وقتی کاتالوگ ابزارها رشد می‌کند یا ورودی‌ها عمداً مبهم هستند، چگونه رفتار می‌کنند. تست واقعی یک جزء هوش مصنوعی محلی، هزینه ادغام آن و رفتارش در لبه‌های توانمندی‌هایش است.

گام بعدی شما

• اگر از مدل‌های تخصصی برای Tool Calling استفاده می‌کنید، نرخ «شکست در بازیابی» را در مقیاس بالای ابزارها تست کنید.
• توصیفات ابزارهای خود را از حالت «راهنما» به حالت «داده‌های طبقه‌بندی» تغییر دهید تا تداخلات معنایی کاهش یابد.
• منطق اعتبارسنجی آرگومان‌ها را از پرامپت مدل به کد سیستم (Shell) منتقل کنید تا ریسک عملیات تخریبی کاهش یابد.

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