فرض همه این بوده که وقتی به یک عامل هوش مصنوعی یادداشتی از کار قبلی میدی، داری چیزی یادش میدی که نمیدونست. حالا یک تیم رفته و همین رو اندازه گرفته. سهم «چیزی که نمیدونست» در موفقیتها ۴٫۵ درصده. سهم چیز دیگری ۶۵٫۷ درصد.
آن چیز دیگه اینه که یادداشت جلوی پرت شدن عامل رو میگیره. دانشی اضافه نمیکنه؛ مسیر رو نگه میداره.
این مقاله دقیقاً همون سوالی رو میپرسه که معمولاً ازش رد میشن. همه سنجیدهن که آیا یادداشتها نرخ موفقیت رو بالا میبرن یا نه، ولی کمتر کسی پرسیده چه وقت کمک میکنن، چرا کار میکنن، و کجا خراب میشن.
چطور اندازه گرفتن
هشت هزار و صد و سی و پنج اجرای ثبتشده، روی سه معیار مختلف، با دو چارچوب عامل و دو مدل متفاوت. کارهایی که سنجیدهن از جنس کار واقعی با خط فرمانن، یعنی چیزهایی که یا اجرا میشن یا نمیشن و کسی لازم نیست دربارهشون نظر بده. بعد برای اینکه بفهمن دقیقاً چه اتفاقی میافته، ۵۲۸ سهتایی جفتشده رو جداگانه بررسی کردن؛ یعنی همون کار یک بار با یادداشت، یک بار بدون یادداشت، و یک بار با رد خام تجربهی قبلی.
یک نکتهی روشی هم دارن که ارزش گفتن داره. برچسب زدن به این اجراها رو یک مدل انجام داده، ولی نتیجهاش رو با کدگذاری مستقل انسانی مقایسه کردهن و ۹۵٫۸ درصد توافق دقیق گرفتهن. هر وقت کسی ادعای دستهبندی کرد، همین عدد اولین چیزیه که باید ازش بپرسی.
یادداشت ریل است، نه کتابخانه
نتیجهی اصلی همون تفکیک اول مقالهست.
وقتی یادداشت جواب میده، تقریباً همیشه به این دلیل جواب میده که عامل رو روی یک رویه ثابت نگه میداره. یعنی عامل از قبل هم بلد بود چه کار کنه، ولی وسط کار پرت میشد، مرحلهای رو جا میانداخت، یا زودتر از موعد تمومش میکرد. یادداشت مثل ریل عمل میکنه و نمیذاره از مسیر خارج بشه. سهم این سازوکار ۶۵٫۷ درصده.
اون چیزی که همه فکر میکردن داره اتفاق میافته، یعنی اینکه یادداشت دانشی رو به عامل میده که نداشته، سهمش ۴٫۵ درصده.
این تفاوت فقط یک نکتهی نظری نیست و مستقیم روی طراحی اثر میذاره. اگه یادداشت کتابخانه باشه، منطقیه که هرچه بیشتر بهتر و هرچه کاملتر بهتر. ولی اگه ریل باشه، یادداشت طولانی و پرجزئیات ضرر داره، چون ریل باید کوتاه و روشن باشه.
و دقیقاً همین رو هم دیدن. وقتی بهجای یادداشت تقطیرشده، رد خام تجربهی قبلی رو به عامل دادن، نرخ موفقیت از ۶۱٫۹ به ۵۵٫۹ درصد افتاد. بدتر از اون، عاملهایی که رد خام گرفته بودن در ۱۰٫۶ درصد مواقع وقتشون تموم میشد، در حالی که همین عدد با یادداشت تقطیرشده ۴٫۴ درصد بود. رد خام پر از گشتنهای بینتیجه و اشکالزداییهای ریزه، و عامل همهشون رو با خودش حمل میکنه.
عددها رو دنبال کن
حالا جالبترین بخش، که به نظرم مهمترین چیز کل مقالهست و در چکیده هم نیامده.
سوال ساده بود؛ وقتی مخزن یادداشتها بزرگ بشه چه اتفاقی میافته. مخزن رو از ۵ تا به ۱۰۰ تا رسوندن و دقت بازیابی رو سنجیدن، یعنی اینکه عامل چقدر همون یادداشتی رو برمیداره که واقعاً به این کار مربوطه.
دقت از ۲۹٫۶ درصد به ۳٫۳ درصد افتاد. تقریباً نه برابر بدتر.
حالا حدس بزن نرخ موفقیت چه شد. از ۳۶٫۴ به ۳۹٫۳ درصد رفت. یعنی بالا رفت.
یک لحظه روی این بایست. لایهی بازیابی نه برابر بدتر شد و نتیجهی کار اصلاً تکون نخورد. تنها معنیای که این میده اینه که اون یادداشتی که برداشته میشد، از اول هم کاری رو که فکر میکردیم انجام نمیداد.
عدد سوم تصویر رو کامل میکنه. فراخوانی روی ۵۴ تا ۷۴ درصد موند، یعنی یادداشت درست معمولاً جزو چیزهایی بود که عامل برمیداشت؛ فقط خودش رو بهش محدود نمیکرد. چند تا کاندید برمیداشت، نگاهی میانداخت، و میرفت سراغ کارش.
پیشبینیای که درست از آب درآمد
دو هفته پیش همینجا نوشتم که اگه یادداشتی رو ذخیره کنی بیآنکه بدونی عامل رو از شکست به موفقیت رسونده، چیزی که ساختهای دفترچه نیست، انباره. اون موقع این یک استدلال بود. حالا عددش هم هست.
مخزنی که فقط از اجراهای موفق ساخته شده بود، نرخ موفقیت ۰٫۷۵ داد. همون مخزن وقتی فقط از اجراهای شکستخورده ساخته شده بود، ۰٫۵۲.
ولی عدد گویاتر جای دیگهایه. وقتی اجراهای شکستخورده توی مخزن هستن و برچسب موفق یا ناموفق بودنشون رو نگه داری، نتیجه ۰٫۷۵ میشه. همون مخزن بدون برچسب، ۰٫۴۰.
یعنی صرف دونستن اینکه کدوم تجربه جواب داده، تقریباً نتیجه رو دو برابر میکنه. داده یکیه و تنها تفاوت اینه که میدونی کدوم کدومه.
و حالا اون «تا وقتی که نه»
عنوان مقاله دو تکه داره و تکهی دومش مهمتره.
یادداشتها یک نوع شکست تازه میسازن که قبلاً وجود نداشت. در ۱۰ درصد مواردی که عامل یادداشت داشت، خود یادداشت بد به کار رفت یا نادیده گرفته شد. همین عدد برای عاملی که هیچ یادداشتی نداشت ۰٫۸ درصده، چون طبیعتاً چیزی نبوده که بد به کار بره.
شکلش هم قابل پیشبینیه. عامل رویه رو مکانیکی اجرا میکنه، شرطهایی رو که رویه فقط تحتشون درسته نمیبینه، و فرضهایی رو از کار قبلی با خودش میاره که دیگه برقرار نیستن. یعنی همون ریلی که نمیذاشت پرت بشه، حالا روی مسیر اشتباه هم محکم نگهش میداره.
چه چیزی درست میشه و چه چیزی نه
اینجا یک تفکیک تمیز هست که برای هر کسی که سامانه میسازه به کار میاد.
یادداشتها خطاهای بهداشتی اجرا رو تقریباً پاک میکنن، چون خطاهای محیط و زیرساخت مثل تداخل پورت و وابستگی نصبنشده از ۵٫۳ درصد به ۰٫۲ درصد رسید و رعایت نکردن قالب خروجی هم از ۷٫۴ به ۳٫۲ درصد.
ولی دو دسته خطا اصلاً تکون نخوردن. خطای منطقی در خود الگوریتم بین ۸ تا ۱۱ درصد موند، در هر سه حالت. و اینکه عامل کارش رو بدون اجرای واقعی وارسی کنه و بگه تموم شد، حدود ۱۲ درصد موند، باز هم در هر سه حالت.
خلاصهاش اینه که یادداشت راه رفتن رو مرتب میکنه ولی فکر کردن رو درست نمیکنه، و اگه عامل الگوریتم اشتباهی توی ذهنش داشته باشه هیچ رویهای نجاتش نمیده. این تفکیک برای تصمیم گرفتن به کار میاد؛ اگه مشکل سامانهات از جنس بینظمی اجراست یادداشت جوابه، و اگه از جنس اشتباه در خود راهحله، وقتت رو تلف نکن.
حالا محدودیتهاش
مقاله چند جا خودش رو محدود میکنه و باید خوند.
دستهبندی سازوکارها از یک نمونهی حدود سه درصدی کل رکوردها درآمده و نه از برچسب زدن به همه، پس رفتارهای نادری که کم پیش میان احتمالاً کمنمایی شدهن. معیارها هم همه از جنس ترمینال و کار با ابزارن و کارهای طولانی وب یا همکاری باز رو پوشش نمیدن، و تعداد ترکیبهای مدل و چارچوبی که امتحان شده هم کمه.
و یک نکتهی ریز که خودشون تأکید کردهن؛ آزمایش مربوط به اندازهی مخزن با نسخهی دیگهای از مدل اجرا شده، پس عددهاش رو نباید با عددهای بخشهای دیگه مقایسه کرد. فقط مقایسهی درون همون بخش معتبره.
چیزی که مهندسها باید بردارن
دو چیز از این مقاله برمیدارم.
اول اینکه یادداشت رو مثل ریل طراحی کن و نه مثل مدخل دانشنامه؛ کوتاه باشه، مشروط باشه، و شرطهایی که تحتشون معتبره روی خودش نوشته شده باشه. یادداشتی که نگه چه وقت معتبره و چه وقت نیست، همون چیزیه که اون ۱۰ درصد شکست تازه رو میسازه.
دوم، و مهمتر، اینکه نرخ موفقیت رو بهتنهایی نگاه نکن. توی همین مقاله دقت بازیابی نه برابر بدتر شد و نرخ موفقیت هیچ چیزی نشون نداد. اگه فقط نرخ موفقیت رو پایش میکردی، یک لایهی کاملاً خراب رو ماهها میدیدی و نمیدیدی. در مقالهی قبلی نوشتم برای هر کش باید بسنجیم چند درصد دفعات واقعاً به کار اومده؛ این مقاله همون عدد رو سنجیده و جوابش این بود که تقریباً هیچ.
این رو در کار خودمون هم دیدهام. در BLZN.AI که یک راهبرد معاملاتی رو تا اجرای واقعی میبره، خطرناکترین حالت این نبود که نتیجه بد باشه؛ این بود که نتیجه خوب باشه به دلیلی غیر از اون چیزی که فکر میکردیم. تا وقتی نتونی بهبود رو به همون جزئی وصل کنی که فکر میکنی مسئولشه، عدد خوب فقط داره چشمت رو میبنده.
پس دفترچه مرده؟
نه، و همینجاست که این مقاله از مقالهی قبلی جلوتر میره.
معیار قبلی نشون داد بیشتر اون پیشرفتی که به حساب دفترچه میگذاشتیم از تازه دیدن چند کار قبلی میاومد. این مقاله میگه چرا؛ چون کاری که دفترچه میکرد از اول هم یادآوری رویه بود، و چند کار اخیر همون یادآوری رو رایگان انجام میدن.
پس دفترچه بیفایده نیست، فقط چیز دیگهایه غیر از اون چیزی که اسمش رو روش گذاشتهایم. کتابخانهی مهارت نیست بلکه یک ریله، و ریل رو کوتاه و کم و دقیق میسازن نه بزرگ و کامل. کسانی هم که دنبال فشرده کردن این مخزنها رفتهن، در عمل دارن همین رو میپذیرن.
و اگه یک جمله از این مقاله بمونه، همینه که یادداشت به عامل چیزی یاد نمیده. فقط نمیذاره چیزی رو که بلده فراموش کنه.