یک ایده این روزها همه‌جا تکرار می‌شه و آن‌قدر منطقی به نظر می‌رسه که کمتر کسی زحمت آزمودنش رو به خودش داده. به عامل هوش مصنوعی یک دفترچه بده تا هر چیزی که جواب داد رو توش بنویسه، و دفعه‌ی بعد که کار مشابهی پیش اومد سراغ همون دفترچه بره. اسمش رو گذاشته‌ن دفترچه‌ی مهارت، و فرض پشتش اینه که عامل با هر کاری که انجام می‌ده یک‌ذره تواناتر می‌شه. چهار مقاله در یک هفته همین فرض رو سنجیدن، و نتیجه‌شون آن چیزی نیست که انتظار داری.
چند هفته پیش نوشتم که بین دو نوع سامانه باید مرز گذاشت. در یکی، هر چیزی که سامانه رو کارآمد می‌کنه در کد خودمون نشسته. در دیگری، همون کارآمدی از خود مدل میاد. آن بحث مفهومی بود. دفترچه‌ی مهارت دقیقاً شرط‌بندی روی سمت اوله، چون داریم تلاش می‌کنیم توانایی رو بیرون از مدل و در چیزی که خودمون ساخته‌ایم انبار کنیم. حالا برای اولین بار می‌شه دید این شرط‌بندی چقدر جواب داده.
اول ببینیم واقعاً چه چیزی بهتر شده
ContinualSkillBench رو دانشگاه پکن برای همین یک پرسش ساخته. پنج حوزه، در هر کدام صد کار که از آسان شروع می‌شه و سخت‌تر می‌شه، و عمداً طوری چیده شده که چیزی که در یک کار یاد می‌گیری به کار بعدی بخوره. اگه قرار باشه دفترچه جایی به درد بخوره، همین‌جاست.
تا حدی هم به درد می‌خوره، چون عامل هرچه جلوتر می‌ره بهتر کار می‌کنه و نمودارش بالا می‌ره. ولی بعد یک آزمایش ساده انجام دادن که همه‌چیز رو عوض کرد. دفترچه رو کاملاً برداشتن و فقط گذاشتن عامل چند کار آخری رو که انجام داده جلوی چشمش داشته باشه. نتیجه تقریباً همون بود.
یک لحظه روی این بایست، چون حرف کوچکی نیست. آن پیشرفتی که به حساب دفترچه می‌گذاشتیم، بیشترش از این می‌اومد که عامل چند کار قبلی رو تازه دیده بود. دفترچه پر می‌شد و بزرگ‌تر می‌شد؛ ولی کاری که می‌کرد بیشتر به حافظه‌ی کوتاه‌مدت شبیه بود تا به مهارت.
یادداشت‌ها کلاً بی‌فایده نیستن و آنجا که کار یک رویه‌ی مشخص و تکراری داره یا خروجی باید دقیق باشه واقعاً کمک می‌کنن. ولی یافته‌ی بعدی از این هم بدتره. مدل‌های ضعیف‌تر دفترچه‌های بزرگ‌تری می‌سازن، پر از یادداشت‌های ریز و پراکنده که هر کدام فقط به درد یک کار خاص می‌خورن. یعنی دفترچه دقیقاً جایی تندتر پر می‌شه که کمتر به کار میاد، و این وارونگی رو هر کسی که با مدل ارزان‌تر سامانه ساخته یک‌جا حس کرده.
اما این به معنی شکست ایده نیست
اگه همین‌جا بایستیم، نتیجه می‌گیریم کل ایده اشتباه بوده. مقاله‌ی دوم نشون می‌ده این‌طور نیست، ولی برای اینکه بشه با اطمینان حرف زد اول باید یک مشکل قدیمی رو حل کرد.
مشکل اینه که وقتی عاملی بعد از تمرین بهتر عمل می‌کنه، از کجا بدونیم بهتر شدنش از تجربه اومده و نه از اینکه کار آزمون شبیه کار تمرین بوده. GDPevo این رو با یک ترفند تمیز حل می‌کنه. یک جریان کاری واقعی در یک شرکت رو برمی‌دارن و به قاعده‌های کوچک و مستقل خردش می‌کنن. بعد این قاعده‌ها رو تکه‌تکه بین کارهای تمرینی پخش می‌کنن، و سر آزمون همون قاعده‌ها رو جور دیگری کنار هم می‌چینن. حالا اگه عامل در آزمون بهتر عمل کرد، خیالت راحته که کار رو قبلاً ندیده بوده و فقط اجزایش رو دیده.
معیار رو روی جریان‌های واقعی CRM و ERP و مالی و درمانی و حقوقی ساخته‌ن و نسخه‌ی اولش ۱۲۰ کار داره در ۱۲ گروه؛ و چون کل ساختش خودکاره، در دو روز به ۲۴۰ کار رسوندنش. این خودش جواب یک مسئله‌ی مهمه، چون وقتی مدل‌ها کم‌کم خود معیار رو حفظ می‌کنن تو یک معیار تازه می‌سازی و کار تمام است.
نتیجه هر دو طرف رو نشون می‌ده. تجربه واقعاً کمک می‌کنه و روی کارهایی که عامل قبلاً ندیده دقت رو ۱۶٫۴۴ واحد درصد بالا می‌بره. ولی اگه همون قاعده‌ها رو از اول به عامل بدی به ۹۱٫۶ درصد می‌رسه، و بهترین عامل‌ها هنوز خیلی از این عدد فاصله دارن.
عددها رو دنبال کن چون شهود اینجا گمراهت می‌کنه. آن ۱۶٫۴۴ واحد شنیدنش خوبه و آدم فکر می‌کنه یعنی سامانه دارد یاد می‌گیرد. ولی سقفی که همین معیار نشون می‌ده ۹۱٫۶ است، و این سقف رو نه با تمرین بلکه با در دست داشتن خود قاعده‌ها از اول به دست آورده‌ن. یعنی تجربه بخشی از راه رو می‌ره، ولی هنوز فاصله‌ی زیادی هست تا جایی که همان دانش، بدون کشف دوباره، در اختیار عامل باشه. پس سوال درست این نیست که تجربه کمک می‌کنه یا نه؛ سوال اینه که چرا این‌قدر گران و این‌قدر کم.
پس چه چیزی یک یادداشت رو به‌دردبخور می‌کنه
SKILL-KD از دانشگاه ژجیانگ سراغ همین رفته، و جوابش با کاری که بیشتر سامانه‌ها می‌کنن فرق داره.
روش معمول اینه که وقتی عامل کاری رو درست انجام داد، از آن اجرا یک خلاصه بردارن و ذخیره کنن. مشکلش اینه که وقتی یک عامل ضعیف شکست می‌خوره، از روی شکستش نمی‌شه فهمید دقیقاً چه چیزی کم داشته؛ و از آن طرف مسیر عامل قوی هم آن‌قدر چیزها رو ناگفته می‌ذاره که عامل ضعیف نمی‌تونه چیزی ازش برداره. هر کدام به تنهایی گنگ‌ان.
کاری که SKILL-KD می‌کنه اینه که شکست و موفقیت رو روی یک کار واحد کنار هم می‌ذاره و دقیقاً همون نقطه‌ای رو بیرون می‌کشه که باید عوض بشه، و آن رو به شکل یک دستور می‌نویسه. تا اینجا خیلی روش‌ها همین کار رو می‌کنن. کاری که بقیه نمی‌کنن مرحله‌ی بعدیه، چون عامل ضعیف رو با همون دستور دوباره اجرا می‌کنه تا ببینه واقعاً مشکل حل شد یا نه، و اگه نشد دستور رو عوض می‌کنه. یعنی هیچ یادداشتی بدون آزمون وارد دفترچه نمی‌شه.
یک مسئله‌ی دیگر هم هست. وقتی این دستورها یکی‌یکی اضافه می‌شن، بعد از مدتی قاعده‌های قدیمی با تازه‌ها نمی‌خونن. برای همین هر تغییر با سابقه‌اش نگه داشته می‌شه و هر بار تصمیم می‌گیرن این دستور تازه باید قاعده‌ای اضافه کنه، قاعده‌ای رو عوض کنه، قاعده‌ای رو برداره، یا اصلاً نادیده گرفته بشه. روی پنج معیار مختلف امتحانش کرده‌ن و همیشه بهتر از روش‌های رایج جواب داده، آن هم بدون اینکه دست به خود مدل بزنن.
چرا این ماجرا از دل برنامه‌نویسی درآمد
مقاله‌ی چهارم یک مروره و کل حوزه رو مرتب می‌کنه. اینکه دقیقاً چه چیزی عوض می‌شه، از چارچوب و حافظه و یادداشت‌ها گرفته تا ابزارها و خود مدل و شکل همکاری چند عامل با هم؛ و اینکه این تغییر کی اتفاق می‌افته و چه شاهدی هدایتش می‌کنه.
جواب پرسش آخر توضیح می‌ده چرا این حوزه از برنامه‌نویسی شروع شد. در برنامه‌نویسی بازخورد اجرا می‌شه. تست یا سبز می‌شه یا نمی‌شه، و لازم نیست کسی نظر بده. مخزن کد هم همه‌ی زمینه رو در اختیار می‌ذاره، و هر بار که کسی تلاش می‌کنه اشکالی رو رفع کنه یک رد قابل استفاده جا می‌مونه. هیچ حوزه‌ی دیگری هر سه رو با هم نداره؛ و برای همینه که وقتی همین روش‌ها رو به کارهای اداری و درمانی و حقوقی می‌بری، اولین چیزی که کم میاد همین بازخورد ارزان و بی‌طرفه.
نویسنده‌ها هشدارهاشون رو هم می‌نویسن. بازخوردی که همیشه قابل اعتماد نیست، مدل‌هایی که کم‌کم خود معیار رو حفظ می‌کنن، و بعد ایمنی و نگهداری و هزینه. این فهرست رو کنار یافته‌ی مقاله‌ی اول بذار تا تصویر کامل بشه. سامانه‌ای که یادداشت جمع می‌کنه بدون اینکه بدونه کدام یادداشت واقعاً کار کرده، داره بدهی فنی جمع می‌کنه نه تجربه.
این دفترچه چیزی جز یک کش نیست
اگه بخوام این چهار مقاله رو یک‌جا و به زبان مهندسی بگم، دفترچه‌ی مهارت یک کش است. و هر کشی که در محیط عملیاتی کار می‌کنه دو چیز داره که این دفترچه‌ها ندارن.
اولی قاعده‌ی بیرون انداختنه. کشی که چیزهای بی‌مصرفش رو دور نریزه فقط بزرگ می‌شه و کند می‌کنه، و همون دفترچه‌ی بزرگ و پراکنده‌ای که مقاله‌ی اول در مدل‌های ضعیف دید دقیقاً همینه. آن کاری که SKILL-KD می‌کنه و اسمش رو ساماندهی گذاشته در واقع همینه، یعنی قاعده‌ای که تصمیم می‌گیره چه چیزی وارد بشه و چه چیزی بیرون بره.
دومی اندازه‌گیریه. برای هر کشی می‌سنجیم چند درصد دفعات واقعاً به کار اومده، و بدون این عدد نمی‌شه گفت نگه داشتنش می‌ارزه یا نه. برای دفترچه‌های مهارت کسی چنین عددی گزارش نمی‌کنه، و کاری که GDPevo کرده در عمل ساختن همین عدده.
این رو در کار خودم دیده‌ام. در BLZN.AI که یک راهبرد معاملاتی رو از آزمون روی داده‌ی گذشته تا اجرای واقعی می‌بره، سخت‌ترین بخش هیچ‌وقت ساختن راهبرد نبود. سخت‌ترین بخش این بود که بفهمیم بهتر شدن نتیجه از تغییری اومده که ما دادیم یا از اینکه خود بازار عوض شده. سامانه‌ای که چیزی از گذشته‌اش رو نگه می‌داره، تا وقتی نتونی بهبود رو به همون نگه‌داشته وصل کنی، فقط داره انبار می‌کنه.
برگردیم سر همان مرز
آن تفکیک هنوز سر جایش است. توانایی یا بیرون از مدل و در کد ما جمع می‌شه، یا از خود مدل میاد، و دفترچه جدی‌ترین شرط‌بندی روی راه اول است.
چیزی که این چهار مقاله اضافه می‌کنن اینه که راه اول فقط وقتی جواب می‌ده که هر چیزی رو که به دفترچه اضافه می‌کنی جداگانه آزموده باشی. اگه یادداشتی رو ذخیره کنی بی‌آنکه بدونی عامل رو از شکست به موفقیت رسونده، چیزی که ساخته‌ای دفترچه نیست، انباره.
پس قبل از اینکه برای عامل بعدی چنین دفترچه‌ای بسازی، یک سوال رو جواب بده. اگه همه‌ی یادداشت‌ها رو پاک کنیم و فقط چند کار آخر رو جلوی مدل بذاریم، چقدر از توانایی امروزش می‌مونه؟ تا وقتی جواب این رو نداری، معلوم نیست عاملی ساخته‌ای که یاد می‌گیره یا عاملی که حافظه‌ی خوبی داره.