ادعای پشت تیتر
موجی از مدل‌های تصمیم فشرده از راه رسیده است. Microsoft-Decision-1 و Drex 1.5 از Nace AI هر دو تصمیم‌گیری را به‌جای تولید، به‌صورت امتیازدهی صورت‌بندی می‌کنند: با گرفتن مجموعه‌ای از گزینه‌ها و یک هدف، مدل یک امتیاز یا رتبه‌بندی برمی‌گرداند. این تغییر مفیدی است. امتیازدهی یک عملیات کراندار است. به مجموعه گزینه‌های ثابت و هدف ثابت نیاز دارد. آن هدف باید از جایی بیاید، و آن جا یک سند سیاست است، نه وزن‌ها.
فشرده‌سازی همان نکته اصلی است. یک مدل ۹B که گزینه‌ها را امتیاز می‌دهد، فشرده‌سازی سیاستی است که شما قبلاً نوشته‌اید. اگر یکی از این مدل‌ها را بدون دفترچه تصمیم نسخه‌بندی‌شده عرضه کنید، مسئله حکمرانی را حذف نکرده‌اید. آن را به یک checkpoint منتقل کرده‌اید.
در نظر بگیرید که checkpoint چه چیزی در خود دارد. یک تابع آموخته‌شده از (context، گزینه، هدف) به امتیاز دارد. این تابع بر روی نمونه‌ها برازش شده است. آن نمونه‌ها انتخاب‌هایی را رمزگذاری می‌کنند که کسی، تحت سیاستی، در زمانی انجام داده است. checkpoint متن سیاست را حمل نمی‌کند. خلاصه آماری آن را حمل می‌کند. وقتی سیاست تغییر می‌کند، خلاصه خودش را به‌روز نمی‌کند. وقتی سیاست ساکت است، خلاصه همچنان یک عدد تولید می‌کند.
این همان حالت شکست است. یک مدل امتیازدهی به‌حکم ساختار مطمئن است. برای هر گزینه‌ای که به آن بدهید یک امتیاز برمی‌گرداند. اگر سیاست شما قاعده تساوی‌شکن را تعریف نکرده باشد، مدل یکی از توزیع آموزشی خود اختراع می‌کند. این اختراع در خروجی قابل مشاهده نیست. تنها در گزارش تصمیم قابل مشاهده است، اگر یکی نگه داشته باشید، و تنها اگر گزارش شامل مجموعه گزینه‌ها و هدفی باشد که امتیاز را تولید کرده است.
یک تصمیم امتیازدهی‌شده واقعاً شما را به چه چیزی متعهد می‌کند
هر امتیاز دلالت بر یک کلاس مقایسه و یک قاعده تساوی‌شکن دارد. کلاس مقایسه همان مجموعه گزینه‌هاست. اگر مجموعه گزینه‌ها ثبت نشده باشد، امتیاز بی‌معناست. امتیاز ۰٫۸۲ برای گزینه A بدون دانستن اینکه B، C و D چه بودند هیچ معنایی ندارد. همچنین بدون دانستن هدف هم بی‌معناست: ۰٫۸۲ برای بهره‌وری هزینه تصمیمی متفاوت از ۰٫۸۲ برای حفظ مشتری است.
قاعده تساوی‌شکن جایی است که بیشتر حوادث agent در آن زندگی می‌کنند. مدل مطمئن است، سیاست ساکت. دو گزینه در باندی باریک امتیاز می‌گیرند. مدل گزینه بالاتر را انتخاب می‌کند. سیاست هرگز نگفته بود وقتی امتیازها نزدیک‌اند کدام بُعد غالب است. گزارش حادثه می‌گوید agent انتخاب غیرمنتظره‌ای کرده است. علت ریشه‌ای یک سطر گمشده در یک دفترچه است.
امتیازی بدون مجموعه گزینه‌های ثبت‌شده را نمی‌توان پس از واقعه بازپخش کرد. بازپخش به همان ورودی‌ها نیاز دارد: همان schema گزینه، همان هدف، همان آستانه. اگر schema گزینه بین تصمیم و حسابرسی تغییر کرده باشد، امتیاز بازتولیدپذیر نیست. اگر هدف در یک قالب prompt ویرایش شده باشد، امتیاز بازتولیدپذیر نیست. اگر آستانه یک hyperparameter باشد که در حین evaluation تنظیم شده، امتیاز بازتولیدپذیر نیست.
این مسئله مدل نیست. مسئله artifact است. مدل یک runtime است. دفترچه همان artifact است.
دفترچه artifact است، مدل runtime
دفترچه تصمیم یک سابقه نسخه‌بندی‌شده از تصمیم‌هایی است که یک agent مجاز به گرفتن آن‌هاست. سه بخش دارد که باید جدا از checkpoint نسخه‌بندی شوند:
- schema گزینه: چه گزینه‌هایی وجود دارند، چگونه شناسایی می‌شوند، و هر گزینه چه فیلدهایی حمل می‌کند.
- هدف: ابعادی که امتیاز می‌گیرند، وزن‌های نسبی آن‌ها، و جهت ترجیح.
- تساوی‌شکن: قاعده‌ای که تساوی‌های نزدیک را حل می‌کند، از جمله آستانه‌ای که تساوی نزدیک را تعریف می‌کند.
نسخه‌بندی جداگانه این‌ها اهمیت دارد چون با نرخ‌های متفاوتی تغییر می‌کنند. checkpoint وقتی دوباره آموزش می‌دهید یا مدل را عوض می‌کنید تغییر می‌کند. schema گزینه وقتی کسب‌وکار یک رده محصول جدید اضافه می‌کند تغییر می‌کند. هدف وقتی تیم سیاست وزن هزینه را در برابر حفظ مشتر.jpg)یر می‌کند.
آستانه‌های امتیاز را به‌عنوان پیکربندی با یک مالک رفتار کنید، نه به‌عنوان hyperparameter. آستانه یک بیانیه سیاست است: زیر این امتیاز، به انسان ارجاع بده؛ بالای آن، عمل کن. آن بیانیه به یک نام، یک نسخه، و یک شخص یا نقش پاسخگو نیاز دارد. اگر آستانه در یک اسکریپت آموزش زندگی کند، با مدل جابه‌جا می‌شود. اگر در یک فایل config با یک مالک زندگی کند، می‌تواند بازبینی شود.
مجموعه گزینه‌ها را در کنار امتیاز ثبت کنید تا یک حسابرس بتواند تصمیم را بازسازی کند. رکورد گزارش باید شامل نسخه دفترچه، شناسه‌های گزینه، نسخه هدف، نسخه آستانه، و امتیازهای خام باشد. با آن رکورد، حسابرس می‌تواند تصمیم را در برابر همان دفترچه بازپخش کند و ببیند آیا خروجی مدل با سیاست سازگار بوده است. بدون آن، حسابرس تنها می‌تواند مدل را بازرسی کند، که به او می‌گوید مدل چه کاری ممکن است بکند، نه اینکه چه کرد.
یک سازوکار مشخص: یک schema گزارش تصمیم که hash دفترچه را با هر تصمیم ذخیره می‌کند. hash شامل schema گزینه، هدف، و تساوی‌شکن است. وقتی دفترچه تغییر می‌کند، hash تغییر می‌کند. تصمیم‌های گرفته‌شده تحت دفترچه قدیمی تحت hash قدیمی قابل پرس‌وجو باقی می‌مانند. این یک قطعه کوچک مهندسی است. تفاوت بین یک تصمیم بازپخش‌پذیر و یک روایت باورپذیر است.
یک قاعده طراحی
اگر یک تصمیم نتواند به‌صورت یک سطر در یک دفترچه بیان شود، یک مدل امتیازدهی آن را قابل‌حکمرانی نخواهد کرد. آن سطر همان آزمون است. شما را مجبور می‌کند گزینه‌ها، هدف، و تساوی‌شکن را نام ببرید. اگر نمی‌توانید نام ببرید، سیاستی ندارید. امیدی دارید که توزیع آموزشی مدل با قصد شما مطابقت دارد.
مدل‌های تصمیم باید پشت دفترچه باشند، نه به‌جای آن. دفترچه فضای تصمیم را تعریف می‌کند. مدل درون آن امتیاز می‌دهد. runtime آستانه را اعمال می‌کند و نتیجه را ثبت می‌کند. این ترتیب سیاست را قابل مشاهده و مدل را قابل تعویض نگه می‌دارد. می‌توانید یک امتیازدهنده ۹B را با یک امتیازدهنده ۹B دیگر، یا با یک مدل بزرگ‌تر عوض کنید، بدون بازنویسی سیاست. می‌توانید سیاست را بدون دوباره آموزش دادن مدل به‌روز کنید.
مبادله واقعی است. نگهداری دفترچه کار است. به یک schema، یک فرایند بازبینی، و یک خط لوله logging نیاز دارد. اولین استقرار را کند می‌کند. تیم‌هایی که آن را رد می‌کنند سریع‌تر عرضه می‌کنند و بدهی نامرئی جمع می‌کنند: تصمیم‌هایی که بازپخش نمی‌شوند، آستانه‌هایی که مالک ندارند، تساوی‌شکن‌هایی که تنها در وزن‌های مدل زندگی می‌کنند. بدهی در حین بازبینی حادثه یا حسابرسی سررسید می‌شود، وقتی پرسش این نیست که مدل چه می‌تواند بکند بلکه چه کرد.
مدل‌های امتیازدهی بهبودی واقعی نسبت به تولید آزاد برای تصمیم‌های کراندار هستند. خروجی را قابل مقایسه و عملیات را ارزان‌تر می‌کنند. سیاست را ناپدید نمی‌کنند. آن را فشرده می‌کنند. فشرده‌سازی اتلافی است. دفترچه جایی است که اتلاف ثبت می‌شود.