HarnessDev: مدل‌های زبانی بزرگ (LLMها) در حال ساخت زیرساخت‌های خود

ByteDance و گروهی از دانشگاه‌ها HarnessDev را معرفی کردند؛ چارچوبی که به مدل‌های زبانی بزرگ (LLMها) اجازه می‌دهد «سیستم‌عامل‌های عامل» (agent operating systems) خود را که Agent Harnesses نامیده می‌شوند، بنویسند. این تیم یک کیت شروع اولیه و سبک به LLM می‌دهد و اجازه می‌دهد تا بقیه موارد را تکمیل کند؛ این کار نشان می‌دهد که چگونه هوش مصنوعی می‌تواند لایه کنترلی را بسازد که حلقه‌های استفاده از ابزار، مراحل تأیید و مدیریت خطا را بدون نیاز به تایپ تک‌تک خطوط توسط انسان، اجرا می‌کند.

چرا یک Harness خودساخته اهمیت دارد

عامل‌های هوش مصنوعی از دستیارهای تک‌دستوری به کارگران چندمرحله‌ای تبدیل شده‌اند که APIها را فراخوانی می‌کنند، در پایگاه‌های داده جستجو می‌کنند و نتایج را به هم پیوند می‌دهند. تا به امروز، توسعه‌دهندگان کدهای هماهنگ‌سازی (orchestration) را به صورت دستی می‌نوشتند تا به مدل بگویند چه زمانی یک ابزار جستجو را فراخوانی کند، چگونه وضعیت میانی را ذخیره کند و چگونه پاسخ نهایی را تأیید نماید. HarnessDev این مدل را تغییر می‌دهد: یک seed harness فقط داربست‌های اولیه را فراهم می‌کند — توابع پایه برای حلقه‌زنی، انتخاب ابزارها و ردیابی وضعیت — و سپس LLM آن را به یک محیط اجرایی (runtime) با قابلیت‌های کامل گسترش می‌دهد.

در بنچمارک این مقاله، مدل ۱۸ Harness متمایز تولید کرد و بیش از ۱۷,۰۰۰ خط کد به هسته اولیه (seed) اضافه نمود. هر Harness چرخه کامل حیات یک وظیفه را مدیریت می‌کرد: اجرای حلقه‌ها، انتخاب ابزار مناسب، حفظ بافتار (context)، ردیابی وضعیت، تأیید نتایج و بازیابی از خطاها.

هزینه‌های پنهانی که این مطالعه فاش کرد

اعداد و ارقام چشمگیر به نظر می‌رسند، اما نویسندگان هشدار می‌دهند که پیاده‌سازی خام لزوماً به معنای کاربرد عملی نیست.

  • اجزای استفاده نشده – بخش قابل توجهی از کدهای تولید شده در طول اجرای واقعی وظیفه هرگز اجرا نشدند. LLM توابعی را نوشت که عامل هرگز آن‌ها را فراخوانی نکرد، که باعث حجیم شدن پایگاه کد بدون ایجاد ارزش شد.
  • وابستگی به مدل (Model lock-in) – Harnessها تمایل داشتند برای همان LLM خاصی که آن‌ها را ساخته بود، تنظیم شوند. وقتی همان Harness به مدل دیگری داده شد، عملکرد به طور محسوسی کاهش یافت؛ این نشان می‌دهد که منطق کنترلیِ خودکار تولید شده، ویژگی‌های خاص آن مدل را در خود جای داده است.
  • شکاف‌های تأیید – یک Harness آزمایشی نرخ موفقیت ۹۹٪ (۹۹ مورد از ۱۰۰ اجرا) را گزارش کرد، اما تنها در ۴۸٪ موارد پاسخ صحیح داد. بدون تأیید قدرتمند، یک عامل می‌تواند با اطمینان پاسخ‌های غلط را ارائه دهد.
  • سربار توکن (Token overhead) – میزان مصرف توکن — که معیاری برای هزینه محاسباتی است — به شدت متغیر بود. یک Harness برای رسیدن به همان نتیجه، به هفت برابر توکن بیشتری نسبت به دیگری نیاز داشت که نگرانی‌هایی را در مورد مقیاس‌پذیری در محیط‌های عملیاتی ایجاد می‌کند.

این یافته‌ها بر نیاز به طراحی منضبط تأکید می‌کنند، حتی زمانی که کد از یک LLM استخراج می‌شود.

نکاتی که توسعه‌دهندگان باید در نظر داشته باشند

  1. با طراحی Harness مانند معماری برخورد کنید – به این تکیه نکنید که مدل «فقط کار خواهد کرد». قبل از اینکه اجازه دهید LLM آن‌ها را تکمیل کند، ماژول‌های مشخصی برای کنترل حلقه، انتخاب ابزار، مدیریت وضعیت و تأیید تعریف کنید.
  2. تأیید قدرتمند بسازید – بررسی‌های صریحی را اضافه کنید که ادعای عامل را با حقیقتِ موجود (ground truth) یا یک مدل ثانویه مقایسه کند. دقت ۴۸ درصدی این مطالعه با وجود نرخ موفقیت خوداظهاری ۹۹ درصدی نشان می‌دهد که تأیید نمی‌تواند یک موضوع جانبی و فراموش‌شده باشد.
  3. مراقب بودجه توکن باشید – Harnessهای پیچیده‌تر می‌توانند تعداد توکن‌ها را به شدت افزایش دهند. انواع مختلف Harness را در مراحل اولیه بررسی (profile) کنید تا از انفجار هزینه‌های پنهان جلوگیری شود.
  4. روی مدل‌های مختلف تست کنید – همان Harness را با چندین زیرساخت (back-end) مختلف از LLM اجرا کنید. اگر عملکرد به شدت افت کرد، ممکن است به یک طراحی مستقل از مدل (model-agnostic) یا Harnessهای جداگانه برای هر مدل نیاز داشته باشید.

خلاصه کلام: HarnessDev ثابت می‌کند که LLMها می‌توانند کدهای کنترلی مشابه سیستم‌عامل خود را پیش‌نویس کنند.