حداقل ارزیابی برای فرستادن فیچر AI یک حلقه قابل تکرار است، نه تیم پلتفرم
خیلی از تیم‌ها ارزیابی را عقب می‌اندازند چون تصویرشان یک رشته بالغ است: داشبورد، کارت امتیاز، داور مدل، و زیرساخت قشنگ. بعد هیچ‌چیز ارزیابی نمی‌شود و بحث کیفیت می‌شود سلیقه در چت. برای فرستادن فیچر لازم نیست آن تصویر را بسازی. لازم است حلقه‌ای داشته باشی که رگرسیون آشکار را بگیرد و حافظه تیم را عوض پرامپت نکند.
حداقلی که خودم نگه می‌دارم کوچک است. یک مجموعه مورد نماینده. چند انتظار رد یا قبول. همان موردها را هر بار که پرامپت، مدل، اسکیما، یا منطق بازیابی عوض می‌شود اجرا می‌کنم. اگر فیچر مهم است، موردها را مثل رفتار عادی اپ نسخه‌بندی می‌کنم. حافظه شفاهی «دفعه قبل بهتر بود» ارزیابی نیست.
چه چیزی را اندازه بگیر
«حس هوشمند بودن جواب» اندازه گرفته نمی‌شود و دعوا می‌سازد. اجزایی که واقعاً تکان می‌خورند قابل اندازه‌گیری‌ترند: دقت مسیریابی، معتبر بودن اسکیما، کیفیت ارجاع، تأخیر، و تمام شدن خود کار. وقتی گردش کار را به جزء بشکنی، ارزیابی از حالت عرفانی درمی‌آید و شکل مهندسی می‌گیرد.
مرز را قبل از مورد اول بنویس. کار در یک جمله. شکل ورودی. شکلی که خروجی باید داشته باشد. کدام بخش مال مدل است و کدام در کد معمولی می‌ماند. اگر فیچر به صورتحساب، مجوز، داده پروداکشن، یا گذار وضعیت قابل دیدن کاربر دست می‌زند، آن بخش‌ها با اعتبار سخت مال اپ باشند. مدل جایی کمک کند که کار مبهم است. پیامد را اپ مالک شود. مورد آزمون هم باید همین قرارداد را چک کند، نه لحن یک پاراگراف نمونه.
اگر استفاده هنوز مبهم است، دامنه را تنگ کن. زیرساخت عمومی دور مسئله حل‌نشده، انعطافی است که هیچ کاربری هنوز از آن سود نبرده. سریع‌ترین مسیر معمولاً یک گردش کار تیز است با ورودی صریح و تعریف «به اندازه کافی خوب» برای نسخه اول.
مسیر کد را کسل نگه دار
ارزیابی جای نمایش ارکستراسیون نیست. یک اسکریپت یا job، اعتبار خروجی تایپ‌دار، و لاگ دور گام گران یا شکست‌خور معمولاً کافی است. نسخه اول باید بتواند صادقانه خراب شود. حالت ناقص روشن بهتر از نمره‌ای است که همیشه سبز می‌ماند چون معیارش شل است.
موردها را نماینده شکست واقعی انتخاب کن، نه فقط مسیر خوشحال. یک مورد که اسکیما خراب است، یک مورد که ابزار غلط صدا زده می‌شود، یک مورد که باید امتناع کند، یک مورد که ارجاع باید به سند مشخص برسد. اگر فقط سؤال‌های آسان را نگه داری، تغییر پرامپت همیشه «بهتر» به نظر می‌رسد.
نسخه‌بندی مهم است چون مدل و پرامپت بدون کامیت هم عوض می‌شوند. اگر مورد و انتظار کنار کد نباشند، هفته بعد کسی نمی‌داند این شکست تازه است یا همیشه بوده. من مورد را مثل تست رفتار اپ می‌بینم: وقتی کاربر واقعی یک جور خراب شدن را نشان داد، همان روز به مجموعه اضافه می‌شود.
بازبینی سبک را حذف نکن
چک خودکار لازم است و تمام تصویر نیست. یک گذر دستی کوچک روی نمونه خروجی، هفته‌ای یک بار، رانش لحن، الگوی شکست عجیب، و مسئله محصول را می‌گیرد که متریک دودویی از دست می‌دهد. لازم نیست هیئت داوری باشد. لازم است کسی خروجی را بخواند و بگوید این دیگر به درد کاربر نمی‌خورد حتی اگر اسکیما معتبر باشد.
پروداکشن را هم در همان حلقه ببین. مهلت، صف، محدودیت نرخ، هزینه تقریبی هر مورد، و اینکه پشتیبانی چطور فیچر را وقتی ناقص رفتار می‌کند توضیح می‌دهد. اگر گردش کار می‌تواند کند، گران، یا ناسازگار شود، ارزیابی باید همان را هم نشان دهد نه فقط «جواب شبیه نمونه طلایی بود».
آموزش تیم جدا از اجرای حلقه است. اگر فقط یک نفر می‌داند موردها کجا هستند، با رفتن او ارزیابی هم می‌رود. رانر باید آن‌قدر کسل باشد که هر توسعه‌دهنده فیچر بتواند محلی اجرا کند و شکست را بخواند.
اشتباه‌هایی که حداقل را خراب می‌کنند
اشتباه اول بزرگ ساختن نسخه اول است. انتزاع پهن برای کاربردهایی که هنوز وجود ندارند، هفته‌ها نگهداری انعطاف می‌سازد. اشتباه دوم تعریف نکردن موفقیت است. اگر کیفیت خروجی، تأخیر، و قابلیت اطمینان قابل قبول معلوم نباشد، فیچر هدف متحرک می‌شود و هیچ شکستی رسمی نیست. اشتباه سوم فراموش کردن دست انسان است. حتی گردش کار خودکار به نقطه بازبینی، فرض قابل دیدن، و زمینه کافی نیاز دارد تا هم‌تیمی بدون مهندسی معکوس کل سیستم دخالت کند.
متریک واحد بدون نمونه هم عادت نمی‌سازد. «امتیاز ۰٫۸» اگر کسی خروجی واقعی را نبیند، فقط عدد است. شکست را با خروجی و دلیل نشان بده.
قبل از کاربر واقعی
یک استفاده محدود و قرارداد خروجی صریح. نتیجه را قبل از اینکه کد پایین‌دست به آن تکیه کند اعتبار کن. کمترین دید برای دیدن تأخیر، شکست، و هزینه به تفکیک گردش کار. کاربر واقعی را وقتی بیاور که می‌دانی رفتار سیستم وقتی کمی خراب می‌شود چیست.
اگر بعد از یک تغییر بتوانی همان موردها را دوباره اجرا کنی و توضیح بدهی چه بهتر شد یا چه برگشت، استک ارزیابی مفیدی داری. هدف کمال نیست. هدف حافظه است. تیمی که حافظه ندارد هر هفته از نو کشف می‌کند که پرامپت جدید همان باگ قدیمی را با لحن مطمئن‌تر برگردانده.
ارزیابی را به دروازه انتشار گره بزن، نه به اسلاید
حلقه وقتی زنده می‌ماند که عوض کردن پرامپت بدون اجرای موردها به پروداکشن نرسد. لازم نیست همه چیز در CI بلاک‌کننده باشد. کافی است موردهای کلیدی همان‌جا اجرا شوند و شکست، خروجی واقعی را نشان دهد. نمره سبز بدون نمونه، عادت را نمی‌سازد و کسی بعد از دو هفته نگاهش نمی‌کند.
مجموعه را کوچک نگه دار تا اجرا کردنش ارزان و قابل فهم بماند. ده مورد که شکست واقعی را نمایندگی می‌کنند بهتر از دویست موردی است که کسی جرات پاک کردنش را ندارد. وقتی موردی دیگر نماینده محصول نیست، حذفش کن. ارزیابی کهنه به اندازه نداشتن ارزیابی گمراه‌کننده است، چون تیم فکر می‌کند پوشش دارد.
اگر دو گردش کار داری، دو مجموعه داشته باش. قاطی کردنشان فقط برای اینکه «یک رانر» داشته باشی، سیگنال را گل‌آلود می‌کند. حداقل ارزیابی یعنی حافظه قابل اجرا، نه پلتفرم واحد برای همه فیچرهای آینده.