اگر در حال حاضر برای آموزش عاملهای هوش مصنوعی با محدودیت حافظه یا خطاهای پیشبینینشده در محیطهای صلب دستوپنجه نرم میکنید، باید بدانید که مدلهای قدیمی آموزش در حال تغییر هستند. دادهها، منطق و زیرساخت دیگر نبلاً به صورت یکدیگر بسته نیستند و این یعنی پایان عصر محیطهای یکپارچه و سخت. آموزش عاملهای خودمختار معمولاً زمانی شکست میخورد که داده، منطق و زیرساخت در یک محیط صلب و واحد بستهبندی شده باشند. Prime Intellect این مشکل را از طریق عرضه Verifiers v1 (که با نسخه ۰.۲.۰ عرضه شده است) حل کرده است. آنها با تفکیک گردشکار عامل به سه بخش ترکیبپذیر شامل تسکستها، هارنسها و رانتایمها، هسته اصلی سیستم را بازنویسی کردهاند که اکنون تحت فضای نام جدید verifiers.v1 منتشر شده است.
بسیاری از توسعهدهندگان امروز با پدیده سوءاستفاده از پاداش (Reward Hacking) — شبیه به دانشآموزی که به جای یادگیری درس، فقط راه میانبر برای گرفتن نمره کامل را پیدا میکند — و رشد تصاعدی مصرف حافظه در گفتگوهای طولانی مواجهاند. Verifiers v1 برای استانداردسازی نحوه ارزیابی عاملهای کدنویسی که در مقیاس بالا از ابزارها، فشردهسازی (Compaction) و زیر-عاملها استفاده میکنند، طراحی شده است. این ابزار یک محیط یکپارچه (Monolithic) را به یک سیستم «پلاگ-اند-پلی» تبدیل میکند که در آن هر تسکست میتواند تحت هر هارنس سازگار اجرا شود. این رویکرد با تلاشهایی برای جایگزینی بازخوردهای انسانی با تستهای واحد و دقیق همسو است، مشابه آنچه در پژوهش RLVR برای مقیاسبندی یادگیری کدنویسی و ریاضیات مشاهده شده است.
به گزارش marktechpost.com، قلب این سیستم یک سرور رهگیر (Interception Server) است که بین رانتایم (Runtime) عامل و سرور استنتاج (Inference) — لحظهای که مدل واقعاً جواب تولید میکند — قرار میگیرد. این سرور درخواستها را پروکسی کرده و ردپاهای (Traces) عملیاتی را بهصورت زنده ضبط میکند. این مکانیزم از طریق استفاده از یک گراف ردپای پیام خطی (Linear Message-Graph Trace)، از رشد درجه دوم (Quadratic Growth) که در نسخه v0 مشاهده میشد، جلوگیری میکند.
طبق مستندات فنی، سرور رهگیر فراتر از یک پروکسی ساده عمل میکند. این سرور توابع حیاتی را بر عهده دارد؛ از جمله تنظیم پارامترهای نمونهبرداری (Sampling Parameters) و قابلیت بازنویسی پاسخهای ابزاری. این مکانیسم بهطور خاص برای کاهش سوءاستفاده از پاداش در طول فرآیند آموزش طراحی شده است. ارتباطات در این سیستم از طریق دو کلاینت تخصصی مدیریت میشود: یک EvalClient که در زمان ارزیابی مانند یک پروکسی HTTP کور (Blind HTTP Proxy) عمل میکند و یک TrainClient که رندرهای مربوطه را در بر میگیرد تا از دقت توکنها در آموزش یادگیری تقویتی (RL) اطمینان حاصل شود.
به دلیل تفاوت در «گویش» یا زبانهای مختلف هارنسها، این سیستم شامل یک «آداپتور گویش» (Dialect Adapter) است. این آداپتور فرمتهای انتقال داده را به استانداردهای کانونی vf.types نرمالسازی میکند. هدف این است که منطق امتیازدهی (Scoring Logic) کاملاً از نوع مدل یا عامل خاص مورد آزمایش مستقل بماند.
جزئیات فنی این معماری شامل موارد زیر است:
- تسکست (Taskset): تعریف دقیق کار، شامل دادهها، ابزارهای مورد نیاز و الزامات امتیازدهی.
- هارنس (Harness): بخشی که تسک را برای تولید یک خروجی (Rollout) حل میکند؛ نمونههایی از آن شامل حلقههای ریاکت (ReAct)، عاملهای CLI، Codex یا Terminus 2 است.
- رانتایم (Runtime): محیط اجرای عملیات که میتواند بهصورت محلی (Local) یا ایزوله (Sandboxed) باشد.
- پشتیبانی از گویش: سازگاری بومی با OpenAI Chat Completions، OpenAI Responses و Anthropic Messages.
- مقیاسپذیری: هر سرور تعداد ثابتی از خروجیها — بهطور پیشفرض ۳۲ مورد — را مالتیپلکس میکند و یک استخر (Pool) دارد که بر اساس همزمانی مشاهده شده، بهصورت الاستیک مقیاس مییابد.
تفاوتهای کلیدی نسخه v1 نسبت به v0 در جدول زیر خلاصه میشود:
- مدل محیطی: در v0 داده، منطق و زیرساخت یکپارچه بودند؛ اما v1 آنها را به تسکست، هارنس و رانتایم تقسیم کرده است.
- رشد ردپا: در v0 رشد حافظه در هر نوبت بهصورت تصاعدی (جفتهای تکراری) بود، در حالی که در v1 رشد بهصورت خطی (گرههای منحصربهفرد) است.
- خروجیها (Rollouts): نسخه v0 خروجیهای خطی را فرض میکرد، اما v1 بهطور بومی از فشردهسازی و زیر-عاملها از طریق شاخهبندی (Branches) پشتیبانی میکند.
- مدیریت رانتایم: در v0 یک Builder برای مدیریت چرخه حیات مسئول بود؛ اما v1 از عملیات run/read/write مدیریتشده توسط چارچوب استفاده میکند.
- دادههای آموزشی: نسخه v0 برای prime-rl نیاز به بازمحاسبه (Recomputation) داشت، اما v1 دادهها را مستقیماً از ردپای عملیات مصرف میکند.
در آزمایشهای داخلی، Verifiers v1 عملکردی مشابه Harbor در تسکهای مشترک داشت. در حال حاضر Harbor اولین فرمت Third-party است که بهطور کامل پشتیبانی میشود و NeMo Gym و OpenEnv نیز پشتیبانی نسخه آلفا را دریافت کردهاند. برای اثبات پایداری در آموزش عاملمحور، مدل GLM-4.5-Air روی مجموعهداده ScaleSWE در ۶ گره H200 طی دو روز آموزش دید و سپس در SWE-Bench-Verified ارزیابی شد.
این تغییر به معنای گذار از کدهای قدیمی و «منجمد» به یک چارچوب منعطف است. جداسازی «چیستی» (تسکست) از «چگونگی» (هارنس) و «کجا» (رانتایم)، اصطکاک انتقال مجموعهدادهها را از بین میبرد. برای مثال، پورت کردن Terminal Bench 2 به نسخه v1 تنها با استفاده از یک کلاس کوچک امکانپذیر شد. این پیشرفت در استانداردسازی محیطها، مکمل بحثهای مربوط به تأثیر مستندات ماشینخوان بر ارتقای بهرهوری ابزارهای عاملمحور است که بر اهمیت ساختارهای دادهای منظم تاکید داشت.
برای یک توسعهدهنده، این یعنی میتوان مدل Nemotron 3 Ultra را روی Terminal-Bench 2 و با هارنس Codex اجرا کرد، بدون اینکه نیاز باشد منطق پاداش را از ابتدا بازنویسی کند. این رویکرد، فرض کلی میدان را از «آموزش وابسته به محیط» به یک «رابط عاملمحور جهانی» (Universal Agentic Interface) تغییر میدهد.
تیمها اکنون میتوانند این محیطها را مستقیماً به prime-rl برای آموزش متصل کنند. کاربران میتوانند یک اجرا را با یک پیکربندی ساده TOML — با تعیین مدل، شناسه تسکست و نسخه هارنس — و یک دستور CLI مانند uv run eval راهاندازی کنند. این امر مانع ورود برای تست رفتارهای عاملمحور پیچیده و طولانیمدت (Long-horizon) را کاهش میدهد.
گام بعدی شما
- بررسی مستندات
verifiers.v1برای جایگزینی محیطهای یکپارچه با ساختار تفکیکشده. - تست مدلهای استدلالی روی بنچمارکهای SWE-Bench با استفاده از هارنسهای جدید.
- ارزیابی هزینه استنتاج در حالت رشد خطی ردپاهای عملیاتی.
اما اثر این معماری بر کاهش تأخیر در پاسخهای مدلهای چندوجهی حتی چشمگیرتر است — به تحلیل ما درباره بهینهسازی استنتاج در مدلهای VLM مراجعه کنید.
گفتگو