«تحلیل شکست‌خورده‌ها»؛ استراتژی جدید SEED برای اصلاح مسیر یادگیری عامل‌ها

سوابق شکست عامل‌های هوش مصنوعی را به‌عنوان گزارش‌های دورریز نادیده نگیرید. چارچوب SEED (Self-Evolving On-Policy Distillation) که جزئیات آن در مقاله‌ای در arXiv منتشر شده است، هرج‌ومرج یک اجرای شکست‌خورده را به یک سیگنال آموزشی متراکم تبدیل می‌کند تا مدل‌ها بتوانند به‌طور فعال از اشتباهات خود درس بگیرند.

آموزش عامل‌های خودمختار مدت‌هاست از مشکل «تخصیص اعتبار» (Credit Assignment) رنج می‌برد. در یادگیری تقویتی (RL) سنتی، یک عامل ممکن است پنج، ده یا حتی پنجاه اقدام در یک مرورگر یا شل (Shell) انجام دهد، اما تنها در لحظه آخر یک سیگنال واحد «شکست» دریافت کند. طبق مستندات این پژوهش، این پاداش پراکنده (Sparse Reward) باعث می‌شود مدل نتواند تشخیص دهد خطا دقیقاً در کجا رخ داده است؛ آیا مشکل در پرس‌وجوی اولیه جستجو بوده، یا در یک عملیات خاص روی فایل، یا به دلیل اعتماد به دستوری نادرست، و یا خطایی در مراحل نهایی اجرا؟ یک پاداش نهایی (Terminal Reward) صرفاً می‌گوید «این اجرا بد بود»، اما مشخص نمی‌کند که عامل در کدام نقطه مسیر را اشتباه رفت.

زمینه و چالش پاداش‌های پراکنده

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

این موضوع باعث می‌شود تخصیص اعتبار بسیار دشوار و «زشت» شود. برای مثال، اگر یک عامل در تسک WebShop شکست بخورد، نمره نهایی نشان می‌دهد که خرید اشتباه بوده است، اما نمی‌تواند لحظه دقیقی را که عامل سه صفحه قبل فیلتر اشتباهی برای یک ویژگی (Attribute) اعمال کرد، شناسایی کند. به‌طور مشابه، اگر یک عامل در ALFWorld نتواند شیئی را در جای درست قرار دهد، این شکست ممکن است ریشه در یک فرض اولیه غلط درباره مکان احتمالی اشیاء داشته باشد، نه لزوماً در دستور نهایی. RL مبتنی بر نتیجه (Outcome-only RL) همچنان می‌تواند رفتار را بهبود بخشد، اما بسیاری از اجراها را تلف می‌کند تا چیزهایی را بیاموزد که یک انسان با خواندن ساده‌ی گزارش اجرا (Transcript)، فوراً متوجه آن‌ها می‌شود. در بسیاری از موارد، این شکست‌ها ریشه در عدم آمادگی محیط دارند، شبیه به آنچه در بررسی تاثیر مخازن کد نامنظم بر شکست عامل‌های برنامه‌نویس مشاهده شده است.

سازوکار SEED

SEED با پیاده‌سازی یک حلقه دو بخشی، مدل را مجبور می‌کند تا به‌عنوان منتقد خودش عمل کند. هدف این است که بخش‌های «بعد از حادثه بدیهی» (Obvious-after-the-fact) یک شکست را به‌صورت خودکار استخراج کند:

• تولید مهارت پس‌نگر (Hindsight Skill Generation): ابتدا مدل آموزش می‌بیند تا مسیرهای تکمیل‌شده را بررسی کرده و «مهارت‌های پس‌نگر» بنویسد. این‌ها درس‌های کوتاهی به زبان طبیعی هستند، مانند گردش‌کارهای قابل استفاده مجدد، مشاهدات تعیین‌کننده یا قوانین خاص برای اجتناب از شکست.
• تقطیر در سطح توکن (Token-Level Distillation): این مهارت‌ها پرامپت‌هایی نیستند که در زمان استنتاج زنده (Live Inference) استفاده شوند. در عوض، آن‌ها به‌عنوان توضیحات ممتاز در زمان آموزش عمل می‌کنند که از روی یک اجرایی که پیش‌تر رخ داده، مشتق شده‌اند. در طول RL، سیاست (Policy) فعلی مدل هر دو نقش را ایفا می‌کند: هم مسیرهای جدید را جمع‌آوری می‌کند و هم همان مسیرها را تحلیل می‌نماید. این رویکرد یادگیری متمرکز، یادآور بحث‌های تخصصی‌تر درباره این است که آیا آموزش یک لایه مجزا برای بهبود عملکرد مدل‌های زبانی کافی است یا خیر.
• تغییر احتمال: سیستم مقایسه می‌کند که احتمال تولید اقدامات نمونه‌برداری شده توسط سیاست فعلی، در دو حالت «با حضور مهارت پس‌نگر در متن» و «بدون آن» چقدر است. این تفاوت در احتمال، به یک سیگنال تقطیر متراکم در سطح توکن تبدیل می‌شود که در کنار هدف RL مبتنی بر نتیجه، آموزش می‌بیند.

به زبان ساده، مدل شکست یا موفقیت خود را تماشا می‌کند، آنچه اهمیت داشته است را یادداشت می‌کند و سپس از تفاوت بین «خودِ معمولی» و «خودِ مجهز به درس»، به‌عنوان نظارت اضافی استفاده می‌کند. از آنجا که این دروس (Hindsight) از مسیرهای On-Policy استخراج می‌شوند، فرآیند به‌صورت تکاملی پیش می‌رود. این یک معلم استاتیک نیست که توصیه‌های کلی می‌دهد؛ بلکه با تغییر سیاست مدل، اشتباهات تغییر می‌کنند و دروس نیز همراه با آن‌ها تغییر می‌کنند. پس از پایان آموزش، این مهارت‌های پس‌نگر حذف می‌شوند. سیاست مستقر شده (Deployed Policy) هیچ یادداشت یا راهنمای اضافی را با خود حمل نمی‌کند، زیرا رفتار مورد نظر درونی شده است.

عملکرد و محک‌ها

به گزارش صفحه پروژه و مقاله، SEED در مقایسه با روش GRPO، بهبودهای قابل‌توجهی در بهره‌وری نمونه‌برداری و تعمیم‌پذیری در تسک‌های تعاملات تجسم‌یافته (Embodied Interaction)، ناوبری وب، پاسخ‌دهی به سوالات مبتنی بر جستجو و برنامه‌ریزی بصری داشته است:

• بهره‌وری ALFWorld: مدل SEED تنها با استفاده از ۶۰٪ داده‌های آموزشی به امتیاز ۸۰.۷ رسید، در حالی که GRPO برای رسیدن به امتیاز ۷۵.۰ به ۱۰۰٪ داده‌ها نیاز داشت.
• تسک‌های دیده‌نشده: در مواجهه با تسک‌های جدید و دیده‌نشده در ALFWorld، امتیاز میانگین از ۷۰.۹ (در GRPO) به ۸۶.۲ ارتقا یافت که نشان‌دهنده یک بهبود ۱۵.۳ واحدی است.
• عملکرد کلی: این مدل با استفاده از Qwen2.5-3B توانست به میانگین ۹۱.۸ در ALFWorld دست یابد.
• برنامه‌ریزی بصری: در تسک‌های برنامه‌ریزی بصری، میانگین ۹۱.۰ برای SEED در مقابل ۷۷.۰ برای GRPO گزارش شده است.

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

تقطیر در برابر حافظه

بسیاری از توسعه‌دهندگان عامل‌ها برای حل شکست‌ها، لایه حافظه (Memory) اضافه می‌کنند تا اشتباهات را ذخیره کنند و امیدوار باشند که این خاطرات با موقعیت‌های بعدی مطابقت یابند. اما این کار یک مشکل عملیاتی جدید ایجاد می‌کند. توسعه‌دهندگان باید تعیین کنند کدام خاطرات هنوز درست هستند، کدام یک اثرات جانبی یک محیط بد بوده‌اند و کدام یک جزئیات خاص یک تسک را به محیط‌های جدید نشت می‌دهند. در نهایت، عامل شبیه کسی می‌شود که یک «کمد بایگانی» سنگین را در هر مسیر اجرا با خود می‌کشاند.

SEED مسیر پاک‌تری را انتخاب کرده و مسیر تکمیل‌شده را به‌عنوان داده‌ی آموزشی می‌بیند، نه یک وابستگی دائمی در زمان اجرا. با تقطیر درس‌ها در سیاست مدل، مدل به‌طور ذاتی کمتر به آن یادداشت‌ها نیاز پیدا می‌کند. حافظه در زمان اجرا (Runtime Memory) یک ویژگی محصول (Product Feature) است، اما پس‌نگری در زمان آموزش (Training-time Hindsight) یک مکانیسم یادگیری است.

ریسک خود-تصحیحی

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

مقاله تلاش می‌کند با نگه داشتن سیگنال‌ها در حالت On-Policy و مقایسه احتمالات عادی در برابر احتمالات تقویت‌شده با مهارت، این ریسک را کاهش دهد. با این حال، این یک رفتار انسانی شناخته‌شده نیز هست؛ ما اغلب گزارش‌های پس از حادثه (Postmortems) را به‌گونه‌ای می‌نویسیم که دلیل قطعی یک خرابی را بسیار تمیز توضیح دهد، اما در حادثه بعدی غافلگیر می‌شویم. هدف این نیست که از گزارش‌های پس از حادثه دوری کنیم، بلکه باید با آن‌ها به‌عنوان سیگنال‌های آموزشی برخورد کنیم، نه به‌عنوان متون مقدس. پس‌نگری زمانی مفید است که رفتار را تغییر دهد و در تسک‌های جدید دوام بیاورد، اما زمانی خطرناک است که تنها نامی زیباتر برای «بیش‌برازش» (Overfitting) باشد. برای مقابله با چنین خطاهایی در سیستم‌های پیچیده، می‌توان از استراتژی‌های لایه بندی شده بهره برد، مشابه روشی که AgentForge برای جلوگیری از خطاهای زنجیره‌ای به کار می‌برد.

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

به‌جای چسباندن کورکورانه این یادداشت‌ها به تمام پرامپت‌های آینده، از آن‌ها به‌عنوان متریال بازبینی برای سیستم ارزیابی، تست‌ها و سیاست‌های تلاش مجدد (Retry Policies) استفاده کنید. اگر یک یادداشت پس‌نگر مشابه سه بار تکرار شد، آن نکته متعلق به «طراحی سیستم» است، نه یک توده‌ی حافظه در حال رشد. بهبود عامل‌ها فقط به «اجراهای بیشتر» یا «مدل‌های بزرگتر» نیست؛ بلکه به استفاده بهتر از شواهد خسته‌کننده‌ای است که پیش‌تر هزینه آن‌ها پرداخت شده است: یعنی ردپای کامل آنچه عامل انجام داده است.

گام بعدی شما

• تحلیل ردپاهای (Traces) عامل‌های خود را به‌جای حذف، به عنوان داده‌های نظارتی برای تنظیم دقیق (Fine-tuning) مدل استفاده کنید.
• در طراحی سیستم‌های Agentic، تفکیک کنید که چه اطلاعاتی باید در «حافظه زمان اجرا» بماند و چه درس‌هایی باید در «سیاست مدل» تثبیت شوند.
• بررسی کنید آیا مدل‌های کوچک‌تر (مانند Qwen-3B) با استفاده از تقطیر SEED می‌توانند جایگزین مدل‌های غول‌پیکر در تسک‌های خاص شوند.

این تنها آغاز ماجراست؛ اثر موج‌گونه‌ی این روش بر کاهش هزینه‌های استنتاج در عامل‌های پیچیده را در گزارش بعدی بررسی خواهیم کرد.