رفتن به محتوای اصلیآرشیو مقالههاهمهی مقالههاموضوعهالابراتوارهاجستجودربارههمهی مقالههاموضوعهالابراتوارهاجستجودرباره
آرشیو کانال تکینگی
همهی مقالهها، از تازه به قدیمی
اینجا هر مقالهای هست که کانال پیدا کرده، در خبرنامه گذاشته یا برای بعد نگه داشته، با خلاصهی فارسی هرجا که نوشته شده.
خبرها، دایجستها و پستهای دیگر کانال اینجا نیستند.
ایجنتی که خودش میفهمد کِی به کدام اسکیل نیاز دارد و فقط همان را بار میکند
ایجنتها برای کارهای پیچیده به اسکیل تکیه میکنند: بستههای دستورالعمل آماده برای یک نوع کار. وقتی کتابخانهی اسکیل بزرگ میشود، دو راه رایج هر دو مشکل دارند. اگر فهرست همهی اسکیلها را به مدل نشان بدهی (روش «افشای تدریجی»)، کانتکست پر از توضیحات بیربط میشو
آموزش یک مدل زبانی برای پیشنهاد دادن بهبودهای واقعی به مدلهای زبانی دیگر، بدون هزینهی سرسامآور آزمایش
مدلهای زبانی را برای خودکار کردن پژوهش هوش مصنوعی به کار میبرند، مثلاً برای پیشنهاد تغییری در معماری یا دادهی یک مدل دیگر. اما یاد دادن این مهارت با یادگیری تقویتی گران است: باید دهها هزار پیشنهاد را امتحان کرد و هر امتحان میتواند یک دور کامل آموزش مدل با
لایهی سبکی که ایجنت را در برابر عوض شدن توضیح و ساختار ابزارها مقاوم میکند، بدون آموزش دوباره
ایجنتی که ابزار صدا میزند، به متن رابط ابزارها تکیه دارد: توضیح هر ابزار، ساختار آرگومانها و فهرست ابزارهایی که در لحظهی اجرا به او نشان داده میشود. این متنها بعد از استقرار سیستم مدام عوض میشوند، مثلاً اسم یک آرگومان تغییر میکند یا ابزارهای مشابه به فه
حافظهی بلندمدت ایجنت: به جای تحویل خام نتایج بازیابی، شواهدِ آمادهی پاسخ بساز
ایجنتی که با کاربر هفتهها گفتوگو کرده، برای جواب دادن به یک سؤال باید تکههای مرتبط را از میان سشنهای مختلف پیدا کند. سیستمهای حافظهی فعلی معمولاً هر چه بازیابی کردهاند را همانطور به مدل پاسخدهنده میدهند. نتیجه کانتکستی است که هم تکراری است و هم گاهی
ابزاری برای برچسب زدن قدمبهقدم ترنسکریپت ایجنتها، با همکاری انسان و مدل
هر پژوهشی که میخواهد بفهمد ایجنتها چرا شکست میخورند، با برچسب زدن دستی ترنسکریپتها شروع میشود و هر تیم برای این کار ابزار یکبارمصرف خودش را میسازد. پلتفرمهای پایش، ترنسکریپت را ذخیره میکنند ولی امکان برچسبگذاری ساختاریافته ندارند. ابزارهای برچسبگذار
موتور جستوجویی برای پیدا کردن اسکیلهای کدنویسی از منابع پراکنده
اسکیلها (دستورالعملهای آماده برای یک نوع کار) کارایی ایجنت را در کارهایی مثل مهندسی نرمافزار و ریاضی بالا میبرند. اما امروز پیدا کردن اسکیل مناسب دستی است: باید در ریپوها و سایتهای مختلف گشت و آنها را مرتب کرد. روشهای بازیابی موجود هم فرض میکنند یک کتا
ایجنتهای خودتکامل از شکستهایشان یاد میگیرند همان کار را درست کنند، ولی نه کارهای تازه را
ایدهی «خودتکاملی» این است که ایجنت از تجربههایش یاد بگیرد و به مرور بهتر شود. اما بیشتر روشها به مسیرهای موفق یا یک ارزیاب بیرونی تکیه دارند. سؤال این مقاله این است: اگر ایجنت از صفر شروع کند و فقط شکستهایش را داشته باشد، بدون هیچ راهنمایی ممتاز، باز هم به
کِی ایجنت باید بخشی از تاریخچهی شکستهایش را فراموش یا خلاصه کند؟
ایجنتهایی که کارهای طولانی انجام میدهند، از شکستهایشان در طول کار یاد میگیرند و این شکستها را در کانتکست نگه میدارند. اما ارزش یک رکورد شکست با جلو رفتن کار عوض میشود: چیزی که اول کار مفید بود، بعدها فقط کانتکست را شلوغ و پرهزینه میکند. سؤال این است که
بنچمارکی برای سنجیدن اینکه ایجنت اصلی کار را چقدر خوب بین سابایجنتها تقسیم میکند
ایجنتها در کار واقعی با ابزارهای تخصصی زیاد و مسئلههایی با چند زیرتسک روبهرو میشوند. اگر همه را پشت سر هم با یک ایجنت انجام دهند، کار کند میشود و کانتکست پر از خروجی ابزارها. الگوی «ایجنت اصلی واگذار میکند، سابایجنتها اجرا میکنند» زیرتسکها را به ساب
ایجنت کدنویسی که هم هارنسش را خودش بهتر میکند و هم مدلش را، به نوبت
کارایی یک ایجنت کدنویسی به دو چیز بستگی دارد: مدل (سیاست) و هارنس، یعنی پرامپتها، ابزارها و قاعدههایی که تعامل مدل با محیط را شکل میدهند. این دو به هم وابستهاند. هارنسی که برای یک نسخه از مدل تنظیم شده، ممکن است ضعفهای نسخهی بعدی را هدف نگیرد؛ و مدلی که
راهنماییهایی که به بنچمارکهای کدنویسی اضافه میشوند، گاهی جواب را لو میدهند
بنچمارکها مسیر پیشرفت هوش مصنوعی را تعیین میکنند، اما تعریف تسک در آنها دو جور خراب میشود. اگر تسک ناقص تعریف شده باشد، راهحل باید حدس بزند (مثلاً اسم تابعی را که تستها انتظار دارند نمیداند) یا حتی به تقلب و دور زدن پاداش رو بیاورد. اگر بیش از حد تعریف
چقدر از بهبودِ «تکامل خودکار هارنس» واقعی است و چقدر بیشبرازش؟
تکامل هارنس یعنی پرامپتها، اسکیلها، ابزارها و کد هماهنگی دور یک مدل ثابت را خودکار و پشت سر هم بهینه کنی تا روی یک مجموعهی جستوجو نمره بالاتر بگیرد، بدون آنکه وزنهای مدل عوض شود. سؤال این است که چه سهمی از این بهبود به خاطر جا افتادن روی همان بنچمارک است
موتور ساخت دادهی شبیهسازی و سیاست ربات که با هم تکامل پیدا میکنند
شبیهسازی مولد میتواند خودکار برای ربات محیط تمرین بسازد، اما محیطی که از نظر فیزیکی درست است لزوماً برای آموزش مفید نیست. مشکل این است که محیطهایی را پیدا کنیم که دقیقاً شکستهای فعلی ربات را هدف بگیرند، و نظارتی بدهیم که کمکش کند از آن شکستها رد شود. در چ
بنچمارکی برای «آخرین مایل» تحویل هوش مصنوعی: کار واقعی با مشتری، نه تسک خوشتعریف
بنچمارکهای ایجنت معمولاً تسکهای خوشتعریف دارند: یک ایشو، یک مشخصات یا یک تیکت. اما تحویل یک سیستم به مشتری واقعی فرق دارد. مهندسی که در محل مشتری کار میکند باید نیازهای مبهم را روشن کند، روی سیستم زنده کار کند و محدودیتهایی را پیدا کند که کسی به زبان نیاو
آموزش یک مدل ایجنتی برای مهندسی یادگیری ماشین، با پاداش دادن به «پنجره»های بین دو آزمایش
وقتی یک ایجنت خودش کار مهندسی یادگیری ماشین را انجام میدهد (داده آماده کند، مدل بسازد، آزمایش اجرا کند و از نتیجه یاد بگیرد)، هر آزمایش گران است و نتیجهاش حاصل چند تصمیم قبلی است. یک اجرای طولانی پر از این آزمایشهای پرهزینه است. پس سخت است بفهمیم کدام تصمیم
پاداش دادن به ایجنت جستوجو بر اساس دانستههایی که هر قدم واقعاً به دست آورده
ایجنتهای جستوجوی عمیق برای جواب دادن به سؤالهای پیچیده دهها بار جستوجو میکنند و صفحه میخوانند. در یادگیری تقویتی معمول، کل این مسیر فقط یک پاداش نهایی میگیرد، پس معلوم نیست کدام جستوجو مفید بوده. روشهای نظارت بر فرایند هم اعتبار هر قدم را به وضعیت ظا
گروهی از ایجنتها که بدون هماهنگکنندهی مرکزی، با «مزایده» یاد میگیرند چه کسی کار را انجام دهد
توانایی یک گروه ایجنت هم به اعضایش بستگی دارد و هم به اینکه چطور هماهنگ میشوند. اما سیستمهای چندایجنتی موجود معمولاً ایجنتها را در یک ساختار هماهنگی ثابت آموزش میدهند؛ مثلاً نقشها از قبل تعیین شدهاند. پس یادگیری مهارتهای فردی از سازماندهی رفتار جمعی ج
چهار ایجنت جمنای ۴ آرگون بازی ماینکرفت را از صفر تا شکست اژدها تمام کردند
ایجنتهای امروزی در کارهای کوتاه خوباند، اما کارهایی که هزاران قدم وابسته به هم دارند و بیش از یک روز طول میکشند هنوز سختاند. تمام کردن ماینکرفت در حالت بقا یک آزمون روشن از همین توانایی است: باید منابع جمع کرد، ابزار ساخت، به بُعد دیگری رفت و در آخر اژدهای
ایجنت ناظری که وسط کار تشخیص میدهد سیستم از هدف دور شده و آن را برمیگرداند
ایجنتها و سیستمهای چندایجنتی در کارهای طولانی با ابزار، کمکم از هدف اصلی دور میشوند؛ مثلاً در یک جستوجو آنقدر دنبال یک جزئیات فرعی میروند که سؤال اصلی فراموش میشود. به این «رانش هدف» میگویند و هم منابع را هدر میدهد و هم نتیجه را خراب میکند. برنامهر
آیا ایجنت کدنویسی عمومی هنوز به هارنس مخصوص هر محیط نیاز دارد؟
انتظار میرود مدلهای قویتر روالهای کار را خودشان بسازند و برتری هارنسهای دستساز توسعهدهنده کم شود. این مقاله میپرسد چرا این برتری هنوز باقی است و آیا میشود یک ایجنت مستقل از محیط را بدون مهندسی مخصوص هر محیط بهتر کرد. نویسنده یک ایجنت مبتنی بر کدکس را
ایجنت ارزانی که فقط وقتی مطمئن نیست کار را به مدل گرانقیمت میسپارد
ایجنتهایی که با کامپیوتر کار میکنند (کلیک، تایپ، باز کردن برنامهها) در کارهای طولانی یا باید در هر قدم یک مدل پیشرفتهی گران اجرا کنند، یا با یک مدل کوچک متنباز کار کنند که اغلب شکست میخورد. راه میانه این است که مدل ضعیف کار کند و فقط وقتی لازم است کنترل
ایجنت کتابدار: پیش از رسیدن سؤالها، اسناد را به یک فضای کاری مرتب از فایلها تبدیل کن
استدلال روی اسناد طولانی برای مدلهای زبانی هنوز سخت است. روشهای بازیابی معمول واکنشیاند: فقط بعد از رسیدن سؤال دنبال تکههای مرتبط میگردند، پس سؤالهایی که به ترکیب چند سند نیاز دارند گیر میکنند. ساختارهای ازپیشساخته مثل گراف دانش هم با قاعدههای خشک ساخ
ادغام چند مدل متخصص در یک مدل، فقط با چند ساعت محاسبهی رو به جلو و بدون آموزش
برای اینکه مهارت چند مدل متخصص (مثلاً یکی برای ریاضی و یکی برای کد) در یک مدل جمع شود، معمولاً از تقطیر روی سیاست استفاده میکنند: مدل شاگرد پاسخ تولید میکند و از هر معلم بازخورد میگیرد. این کار برای هر معلم اجرای مدل، محاسبهی معلم و قدمهای آموزش لازم دار
ایجنتی که برای کار با کامپیوتر هم روی رابط گرافیکی کلیک میکند و هم کد اجرا میکند، و یاد گرفته کِی کدام
خودکارسازی واقعی دسکتاپ نه کاملاً تصویری است و نه کاملاً برنامهنویسی. ایجنت باید رابط کاربری را بفهمد و در عین حال فایلها، اسکریپتها و وضعیت سیستم را سریع دستکاری کند؛ مثلاً برای تغییر نام صد فایل، یک اسکریپت از صد بار کلیک بهتر است. آزمایشهای اولیهی نوی