اگه ارزیابی محصولت سخته، مشکل از محصوله
هوش مصنوعیClaude Opus 4.8خلاصهٔ کاملتر
نویسنده که به گفتهٔ خودش سه ساله تمرکز حرفهایش روی eval محصولات هوش مصنوعیه، میگه رایجترین اعتراضی که میشنوه اینه: «محصول ما سخت ارزیابی میشه». حرف اصلی پست اینه که این جمله یه بوی بد محصولیه (product smell)، نه یه محدودیت اجتنابناپذیر. خروجیای که تو نمیتونی راستیآزماییش کنی، برای کاربر هم سخته؛ تو بدترین حالت کاربر باید کل کارو از اول انجام بده تا مطمئن شه جواب درسته. پس طراحیِ محصول برای راستیآزماییِ آسون باید قبل از ساختن eval بیاد.
مثال اول: ایجنت دادهٔ داخلی. ازش میپرسی «درآمد خالص محصول A تو فصل قبل چقدر بود؟» و یه عدد میده — مثلاً ۴.۲۱ میلیون دلار. مشکل اینه که تنها خروجی، همون عدده و هیچی برای چک کردن وجود نداره. نویسنده میگه بهجاش باید ببینی یه دانشمند داده چطور همین عدد رو تأیید میکنه.
روشهایی که خودش میشمره: مقایسه با یه منبع مورد اعتماد (داشبورد یا تحلیل تأییدشدهٔ یه همکار)، دقیق کردن تعریف متریک (درآمد خالص یعنی ناخالص منهای مرجوعی و تخفیف؟)، چک کردن یه کمیت مرتبط مثل تعداد فروش، شکستن عدد کل به ابعادی مثل منطقه، خوندن خود کوئری SQL، و آخر از همه علامت زدن چیزهایی که اصلاً نشد تأییدشون کرد.
طراحی بهتر همینا رو تو رابط کاربری میآره: جواب میگه از کدوم تحلیل تأییدشده و کارِ کی اقتباس شده، مفروضات و محاسبات میانی رو نشون میده، و صریحاً میگه کدوم عدد منبع معتبر نداشته. کاربر هم میتونه یه نوتبوک کامل رو باز کنه و همون سلولهایی که ایجنت اجرا کرده رو ببینه و دستکاری کنه. این میشه افشای تدریجی (progressive disclosure): جزئیات مهم جلوی چشم، بقیه یه کلیک اونطرفتر.
مثال دوم: ابزاری که برای معلمهای ورزش طرح درس مینویسه. نسخهٔ ضعیف، طرح رو از صفر میسازه و معلم باید کل یه صفحه متن رو قضاوت کنه. نسخهای که نویسنده پیشنهاد میده از یه طرح درسِ تأییدشده و واقعاً استفادهشده تو مدرسهها شروع میکنه، میگه از طرحِ کی برداشته شده، و فقط دیف تغییرات رو نشون میده — مثلاً «گرمکردن از ۱۰ دقیقه به ۸ دقیقه، چون کلاست ۴۵ دقیقهست». معلم بهجای قضاوت کل طرح، دو تا ویرایش کوچیک رو Accept یا Reject میکنه.
مثال سوم و پرریسکترین: ابزاری که از پروندهٔ پزشکی یه بیمار، گزارش کارشناسی ۵۰ صفحهای برای بیمهٔ حوادث کار تولید میکنه. پزشک مسئول اون گزارشه، پس برای اعتماد کردن باید کل پرونده رو دوباره بخونه — یعنی همونقدر وقت که خودش از اول بنویسه. توصیهٔ نویسنده اینه که محصول بهجای «تولیدکنندهٔ گزارش»، مثل یه دستیار پژوهشی کار کنه: از هر سند فکتهای مرتبط رو دربیاره با لینک به شمارهٔ صفحه، تناقضها رو رو کنه (مثلاً یه تست تو یه گزارش مثبت و تو یکی دیگه منفی ثبت شده)، سؤالهای باز رو علامت بزنه، و آخرش گزارش نهایی رو از روی همون فکتهایی بسازه که پزشک تأیید کرده.
برای تعمیم الگو، نویسنده چهار تا سؤال میذاره جلوت: کاربر دقیقاً باید چی رو چک کنه؟ میتونه با چه چیزِ مورد اعتمادی مقایسهاش کنه؟ متخصصها از چه نشونهها و سرنخهایی برای تأیید استفاده میکنن؟ و چه واحدهای کوچیکتری هست که کاربر بتونه جدا جدا قبول، ویرایش یا رد کنه؟ نخ مشترک همهشون منشأ (provenance) ه: نشون بده هر تیکه از خروجی از کجا اومده. ضمناً نیازِ راستیآزمایی با بالا رفتن اعتماد کاربر کم میشه، پس جزئیات میتونن بهمرور جمع شن.
نویسنده تأکید میکنه هیچکدوم از این ایدهها تازه نیستن — ریشهشون تو اصول جاافتادهٔ طراحیه مثل needfinding و sensemaking — ولی تو عصر AI یادآوریشون لازمه. حتی تو کدنویسی که ذاتاً قابلتأییدترین کاره (تست، تایپ، دیف)، ابزارهایی مثل Cursor و Devin یه ویدیوی کوتاه از تغییرات UI ضبط میکنن تا بدون بازسازیِ کار بتونی درستیش رو ببینی. حرف آخر: قبل از AI، راستیآزمایی ضمنِ خودِ کار انجام میشد؛ با AI، راستیآزمایی تبدیل به گلوگاه شده.
نکات کلیدی:
- «محصول ما سخت eval میشه» معمولاً یه ایراد طراحیه، نه یه واقعیت اجتنابناپذیر.
- اگه فقط خروجی نهایی رو نشون بدی (یه عدد، یه طرح، یه گزارش ۵۰ صفحهای)، چیزی برای چک کردن باقی نمیمونه.
- طراحی خوب، منشأ و مفروضات رو رو میکنه و صریحاً میگه چی رو نتونسته تأیید کنه.
- خروجی رو به واحدهای کوچیکِ قابلقبول/رد بشکن (دیف تغییرات بهجای یه متن یکپارچه).
- طراحی برای راستیآزمایی، ساخت eval خودکار رو هم راحتتر میکنه، چون سطح آزمون کوچیکتر میشه.
- با AI، گلوگاه از تولید به راستیآزمایی جابهجا شده.
