‏با Claude برای اپلیکیشنت eval بساز و بدون خودفریبی بهترش کن

تو این مقاله Lance Martin می‌نویسه که راهنمای طراحی eval (یعنی مجموعه تستی که می‌گه اپلیکیشن یا اسکیل تو یه کار مشخص چقدر خوب کار می‌کنه) و بهتر کردن نتیجه‌ش به اسکیل claude-api اضافه شده. حالا تو Claude Code با /claude-api build-eval می‌شه داخل خود کدبیس یه مجموعهٔ ارزیابی ساخت و با /claude-api hillclimb اپلیکیشن رو قدم‌به‌قدم روش بهتر کرد.

به گفتهٔ نویسنده یه eval خوب چهار تا نشونه داره. اول اینکه کارهاش شبیه همون چیزی باشه که تو محیط واقعی براتون مهمه، نه چیزی که ساختن یا نمره دادنش راحت‌تره. دوم اینکه مدل قوی‌تر و تلاش بیشتر باید نتیجهٔ بهتری بده، وگرنه یا سؤال‌ها مبهمه یا گریدر خراب. سوم اینکه بهترین مدل هم باید خیلی پایین‌تر از ۱۰۰٪ باشه تا جا برای سنجیدن تغییرها بمونه. چهارم اینکه پراکندگی نتیجه بین اجراها کم باشه.

یه هشدار مهمش دربارهٔ انتخاب نمونه‌هاست: اگه فقط چیزهایی رو بذاری که مدل امروز توشون شکست می‌خوره، داری اثر انگشت خطای همون یه مدل رو اندازه می‌گیری، نه چیزی که ذاتاً سخته. نویسنده می‌گه سخت بودن یه کار باید با قضاوت آدم مشخص بشه و باید بتونی قبلش بگی چرا سخته. خود build-eval هم ورودی‌ها رو به ترتیب از ترنسکریپت‌های واقعی، تیکت‌ها و باگ‌ها، پنج تا ده نمونهٔ دست‌نویس شما و در آخر نمونه‌های ساختگی از روی کدبیس می‌گیره و تا شما تأییدشون نکنید جلو نمی‌ره.

برای نمره دادن هم ارزون‌ترین گزینهٔ ممکن رو پیشنهاد می‌ده: اگه خروجی محدوده، یه چک برنامه‌نویسی‌شده مثل تطابق دقیق یا اسکیمای JSON، و اگه خروجی بازه، LLM-as-judge (یعنی یه مدل دوم که با یه چک‌لیست خروجی رو می‌سنجه، نه با نمرهٔ یک تا پنج)، که نباید همون مدلی باشه که داری تستش می‌کنی. موقع اجرای پایه هم چند تا چک تشخیصی می‌زنه: گریدر رو دو بار روی یه خروجی اجرا می‌کنه ببینه نظرش عوض می‌شه یا نه، دنبال تایم‌اوت و خطای API می‌گرده و اگه امتیاز پایه بالای ۹۵٪ بود هشدار می‌ده که جای پیشرفت کیفی نمونده.

بخش hillclimb هم دور به دور کار می‌کنه: قبل از شروع داده رو تصادفی به train و test تقسیم می‌کنه، هر دور ترنسکریپت‌های دور قبل رو می‌خونه و یه تغییر به شکل پچ پیشنهاد می‌ده که ریشهٔ مشکل رو بگیره، نه اینکه یه جمله رو بازنویسی کنه. اگه فقط train بهتر بشه و test سرجاش بمونه، فرض رو بر overfitting می‌ذاره و پچ رو برمی‌گردونه. اگه امتیاز دو سه دور گیر کنه، به جای تغییر جدید می‌شینه خطاهای باقی‌مونده رو دسته‌بندی می‌کنه تا سؤال مبهم یا باگ خود eval پیدا بشه.

نتیجه‌ها هم مشخصه. روی یه بنچمارک داخلی پشتیبانی مشتری با ۴۴ تیکت (۳۰ تا برای جست‌وجو و ۱۴ تا کنار گذاشته‌شده)، شروع روی Opus 4.8 با تلاش بالا ۷۴.۴٪ دقت و ۴.۶ سنت به ازای هر تیکت بود. بعد از تمیز کردن پرامپت و رفتن سراغ Opus 5.5 با تلاش کم، دقت به ۸۷.۸٪ و هزینه به ۱.۹ سنت رسید و با Sonnet 5 شد ۸۸.۹٪ با حدود ۱ سنت. با چند قاعدهٔ مسیریابی، Sonnet 5 به ۹۸.۹٪ رسید و روی همون ۱۴ تیکت دست‌نخورده نمرهٔ نهایی ۹۰.۵٪ در برابر ۷۸.۶٪ اولیه بود، با حدود یک‌پنجم هزینه.

نکات کلیدی:

• دو دستور جدید اسکیل claude-api: build-eval برای ساخت مجموعهٔ ارزیابی و hillclimb برای بهتر کردن اپلیکیشن روش
• اگه امتیاز پایه بالای ۹۵٪ باشه، ابزار هشدار می‌ده که هدف رو روی هزینه یا تأخیر بذارید نه کیفیت
• گریدر دو بار روی یه خروجی اجرا می‌شه تا ناپایداری نمره‌دهی لو بره
• تقسیم تصادفی داده به train و test و برگردوندن هر پچی که فقط train رو بهتر کرده
• بنچمارک پشتیبانی: از ۷۴.۴٪ و ۴.۶ سنت روی Opus 4.8 به ۹۸.۹٪ و حدود ۱ سنت روی Sonnet 5
• روی ۱۴ تیکت کنارگذاشته‌شده نتیجهٔ نهایی ۹۰.۵٪ بود در برابر ۷۸.۶٪ تنظیمات اولیه
• اسکیل claude-api خودش هم از ۶۶٪ به حدود ۸۸٪ رسید، با پر کردن هشت قابلیت جاافتاده و اصلاح جدول‌های نوع در C# و Java