تصور کنید یک برنامه‌نویس بتواند تمام اشتباهات گذشته‌اش در یک دفترچه یادداشت ثبت کند و هر بار پیش از شروع کدنویسی، آن را بخواند تا دوباره همان خطاها را تکرار نکند. WikiSkill دقیقاً همین سازوکار را برای عامل‌های هوش مصنوعی (AI Agents) پیاده‌سازی می‌کند تا محدودیت یادگیری مستمر را دور بزنند.
این چارچوب جدید از گوگل به عامل‌ها اجازه می‌دهد حافظه‌ای دائمی از شکست‌ها و موفقیت‌های خود داشته باشند. با مستندسازی تجربیات در یک ویکی ساختاریافته، عامل‌ها می‌توانند دستورالعمل‌های عملیاتی خود را در طول چندین بار اجرا اصلاح کنند. طبق اعلام پژوهشگران، این فرآیند باعث می‌شود عملکرد آن‌ها در وظایف پیچیده استدلالی به‌طور چشم‌گیری افزایش یابد.
این رویکرد گره‌ای بنیادی در هوش مصنوعی عامل‌محور را باز می‌کند: ناتوانی مدل‌ها در «یادگیری» واقعی از یک اشتباه در لحظه، بدون نیاز به تنظیم دقیق (Fine-tuning) هزینه‌بر. همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه چگونه Co-Scientist در گوگل دیپ‌مایند نرخ ساختگی بودن داده‌ها (Fabrication) را کاهش داد اشاره کردیم، WikiSkill تمرکز را از «کاهش خطا» به «تکامل سیستماتیک مهارت‌های مورد نیاز برای پیشگیری از خطا» تغییر می‌دهد. این تلاش برای خود-بهبودی در واقع بخشی از موج جدیدی است که در آن عامل‌های خود-بهبودبخش ممکن است نیاز به کتابخانه‌های ابزار سنتی را به کلی از بین ببرند.
مبانی مفهومی و ساختار
این چارچوب بر اساس دیدگاهی از آندری کارپاتی در مورد مفهوم «ویکیِ مدل زبانی» (LLM Wiki) طراحی شده است. این نظریه استدلال می‌کند که تجربیات باید به جای تکیه بر حافظه موقت و گذرا (Transient Context)، در قالب یک دانش تجمعی و دائمی تدوین شوند. WikiSkill این تفکر را در زمینه توسعه خودکار مهارت‌ها به کار می‌گیرد. این رویکرد در واقع پاسخی به چالش‌های مدیریت حافظه است؛ موضوعی که در بررسی نبرد میان ذخیره‌سازهای معنایی و حافظه خطی برای حفظ دستورات اولیه AI به تفصیل به آن پرداختیم.
در حالی که عامل (مدل) در معنای فنی کلمه «یادگیری مستمر» نمی‌کند — که همچنان یک مسئله حل‌نشده در هوش مصنوعی است — اما پس از هر بار اجرا، دستورالعمل‌های بهتری برای خودش می‌نویسد. اگرچه پژوهشگران اعتراف می‌کنند که این روش ظریف نیست و ممکن است نسبت به یادگیری واقعی مستعد خطای بیشتری باشد، اما مطالعه ثابت می‌کند که این یک راهکار جایگزین (Workaround) بسیار مؤثر است.
بر اساس گزارش ۲۹ اوت ۲۰۲۶ از وب‌سایت the-decoder.com، سیستم WikiSkill فضای کاری عامل را به سه لایه مجزا تقسیم می‌کند:
- لایه خام (Raw Layer): مخزنی تغییرناپذیر از تمام ردپاهای کامل اجرا، شامل هر فراخوانی ابزار و نتیجه حاصل از آن. این لایه به عنوان ماده اولیه برای تمام بهبودهای بعدی عمل می‌کند.
- لایه ویکی (Wiki Layer): یک پایگاه دانش دائمی که در آن داده‌های خام به بینش‌های ساختاریافته تقطیر می‌شوند؛ مواردی مانند الگوهای مستند شده شکست و استراتژی‌های موفق. این لایه هرگز ریست نمی‌شود و با هر تکرار رشد می‌کند.
- لایه مهارت (Skill Layer): دستورالعمل‌های رویه‌ای فعالی که عامل دنبال می‌کند. برخلاف ویکی، اگر یک به‌روزرسانی باعث افت عملکرد شود، این لایه قابل بازگشت (Rollback) است.
جزئیات فنی و مکانیزم تکامل
این سیستم برای ارتقای توانمندی‌های عامل از یک چرخه چهارمرحله‌ای استفاده می‌کند:
۱. اجرا: یک عامل استنتاج با استفاده از مهارت‌های فعلی، وظایف را انجام داده و ردپاهای اجرا را تولید می‌کند (لایه خام).
۲. تقطیر (Distillation): یک «نگهدارنده ویکی» این ردپاها را تحلیل کرده، الگوهای شکست و استراتژی‌های موفق را شناسایی می‌کند و یافته‌ها را در ویکی می‌نویسد.
۳. پیشنهاد: یک «پیشنهاددهنده مهارت» با استفاده از ویکی به‌روز شده و داده‌های اجرا، تغییرات هدفمندی را برای مهارت‌ها پیشنهاد می‌دهد.
۴. اعتبارسنجی: یک مکانیزم کنترلی (Gating)، تغییرات پیشنهادی را روی یک مجموعه اعتبارسنجی مجزا تست می‌کند تا تأیید شود که این تغییر واقعاً به بهبود عملکرد کمک می‌کند.
اگر پیشنهادی در تست اعتبارسنجی شکست بخورد، مهارت به حالت قبل برمی‌گردد اما اطلاعات در ویکی باقی می‌ماند. حتی پیشنهادات شکست‌خورده نیز حفظ می‌شوند، زیرا ویکی مستند می‌کند که چه چیزی امتحان شد و چرا شکست خورد؛ این امر به پیشنهاددهنده مهارت اجازه می‌دهد در تکرارهای بعدی بر اساس آن دانش پیش برود.
پژوهشگران این چارچوب را روی پنج محک مختلف آزمایش کردند: استدلال ریاضی (LiveMath)، جستجوی وب (SealQA)، مدیریت صفحات گسترده (SpreadSheet)، پاسخ‌دهی به سوالات اسناد (OfficeQA) و وظایف تعاملی در یک محیط مجازی (ALFWorld). مدل‌های مورد استفاده شامل Qwen (نسخه‌های 4B، 9B و 27B)، Gemma-4-31B و Gemini-3.5-Flash بودند.
نتایج نشان می‌دهد که WikiSkill به‌طور مداوم از سایر روش‌های تکامل مهارت مانند Trace2Skill، EvoSkill و SkillOpt بهتر عمل می‌کند.
داده‌ها نشان می‌دهند که مدل‌های بزرگ‌تر بیشترین بهره را از معماری می‌برند. برای مثال، صحت عملکرد Gemini-3.5-Flash به‌طور میانگین از ۴۹.۵٪ به ۶۸.۱٪ رسید. در محک LiveMath، این مدل جهشی خیره‌کننده از ۳۳.۰٪ به ۷۲.۶٪ داشت و در SpreadSheet از ۵۰.۵٪ به ۷۶.۶٪ رسید. مدل Qwen-3.6-27B نیز رشد قابل‌توجهی داشت و میانگین عملکردش از ۳۹.۴٪ به ۶۳.۳٪ رسید.
نکته جالب این است که مدل‌های کوچک‌تر مانند Qwen-3.5-4B توانستند با WikiSkill به عملکرد مدل‌های بزرگ‌تری برسند که از این چارچوب استفاده نمی‌کردند. با این حال، مدل‌های کوچک در وظایفی با زمینه متنی طولانی (مانند OfficeQA) همچنان دچار مشکل هستند و اغلب به جای اجرای استراتژی‌های جستجوی چندمرحله‌ای تکامل‌یافته، به رفتارهای پیش‌فرض بازمی‌گردند.
از منظر فنی، این دستاورد فرضیه نیاز به پنجره‌های متنی بزرگ‌تر یا پارامترهای بیشتر برای بهبود عامل‌ها را به چالش می‌کشد. در واقع، «شناخت بیرونی» — یعنی تبدیل تجربه به یک پایگاه دانش تجمعی — جایگزینی عملی برای نبود به‌روزرسانی وزن‌ها در مدل‌های زبانی است.
این سازوکار عملاً تاریخچه عامل را به یک مجموعه داده آموزشی برای پرامپت‌های خودش تبدیل می‌کند. گوگل با جداسازی سوابق تغییرناپذیر (Raw) از بینش‌های تقطیر شده (Wiki) و دستورالعمل‌های فعال (Skill)، یک شیر اطمینان ایجاد کرده که اجازه می‌دهد مدل بدون ریسک افت عملکرد دائمی، دست به تجربه بزند.
توسعه‌دهندگان باید بررسی کنند که آیا این مهارت‌های تکامل‌یافته بین خانواده‌های مختلف مدل‌ها قابل انتقال هستند یا خیر. پژوهشگران اشاره کرده‌اند که مهارت‌های توسعه‌یافته توسط یک مدل، اغلب به مدل دیگر منتقل می‌شوند و گاهی حتی بهتر از مهارت‌هایی عمل می‌کنند که مدل مقصد خودش ساخته است؛ اما این قابلیت انتقال باید مورد به مورد بررسی شود.
گام بعدی شما
- اگر از عامل‌های AI برای کارهای تکراری استفاده می‌کنید، یک «دفترچه یادداشت خطاها» دستی برای پرامپت‌های خود ایجاد کنید تا الگوهای شکست را مستند کنید.
- در طراحی سیستم‌های عامل‌محور، لایه «دستورالعمل» را از لایه «دانش تجربی» جدا کنید تا امکان بازگشت به نسخه‌های پایدار را داشته باشید.
- بررسی کنید که آیا مدل‌های کوچک‌تر با دسترسی به یک پایگاه دانش ساختاریافته می‌توانند جایگزین مدل‌های گران‌قیمت در گردش‌کارهای شما شوند؟
اما تأثیر این رویکرد بر کاهش هزینه‌های استنتاج در مقیاس صنعتی حتی جذاب‌تر است — به تحلیل ما درباره بهینه‌سازی هزینه‌های GPU مراجعه کنید.
گفتگو