بنچمارکی که شکست
یک گزارش عمومی تیمی را توصیف می‌کند که ۲۷ مدل با وزن باز را بنچمارک کرده و کشف کرده که خود هارنس ارزیابی، نه مدل‌ها، منبع خطا بوده است. غریزه این است که این را یک مایه شرمساری تلقی کنیم. این‌طور نیست. این حالت عادی است. کد ارزیابی سریع‌تر از کد مدل منحرف می‌شود، چون تحت فشار مهلت نوشته می‌شود، برای تطبیق با خروجی‌های ناهنجار وصله می‌خورد و به‌ندرت به‌عنوان یک سیستم مستقل بازبینی می‌شود.
هزینه پایین‌دستی خاموش و تجمعی است. رتبه‌بندی‌ها در طول هفته‌ها بدون اینکه کسی متوجه شود غیرقابل‌مقایسه می‌شوند. مدلی که در مارس ۷۱ درصد و در آوریل ۶۸ درصد امتیاز گرفته لزوماً پسرفت نکرده است؛ ممکن است استخراج‌کننده تغییر کرده باشد، یا یک وابستگی جابه‌جا شده باشد، یا چند آیتم به یک پیکره آموزشی نشت کرده باشد. عدد حرکت می‌کند، روایت دنبال می‌شود و دستگاه اندازه‌گیری زیرین هرگز حسابرسی نمی‌شود.
سه دسته نقص هارنس
بیشتر شکستهای هارنس در سه سبد می‌گنجند. عجیب و غریب نیستند. آن‌ها حالت‌های شکست معمولی هر خط لوله داده‌ای هستند که متن بدون ساختار را می‌گیرد و یک عدد اسکالر بیرون می‌دهد.
نقص‌های تجزیه
استخراج‌کننده‌ای که بی‌صدا خروجی ناهنجار مدل را می‌پذیرد، نرخ قبولی را متورم می‌کند. ارزیاب‌کننده‌ای که انتظار یک شیء JSON با فیلد answer دارد ممکن است به یک regex عقب‌نشینی کند، سپس به تطبیق زیررشته، و سپس به پیش‌فرض True. هر عقب‌نشینی یک مهربانی کوچک به مدل و یک دروغ کوچک به خواننده است. شکست نامرئی است چون یک عدد تولید می‌کند نه یک استثنا.
مکانیزم ارزش نام‌گذاری دقیق را دارد. یک زنجیره استخراج‌کننده معمولی این‌طور است:
def extract(text):
obj = try_json(text)
if obj is not None:
return obj.get("answer")
m = re.search(r"answer[:\s]+(.+)", text, re.I)
if m:
return m.group(1).strip()
return text.strip() # last resort
آن return text.strip() نهایی جایی است که نرخ‌های قبولی می‌میرند. یک پاسخ غیرقابل‌تجزیه را به رشته‌ای تبدیل می‌کند که ممکن است تصادفاً با مرجع مطابقت کند. راه‌حل یک regex بهتر نیست؛ یک حالت سخت‌گیرانه است که روی خروجی غیرقابل‌تجزیه استثنا پرتاب می‌کند و شکست را به‌عنوان خطای ارزیاب‌کننده ثبت می‌کند، متمایز از خطای مدل.
آلودگی
آیتم‌هایی که به داده آموزشی نشت کرده‌اند با مهندسی پرامپت قابل رفع نیستند. آیتم بنچمارکی که عیناً در پیکره پیش‌آموزش یک مدل ظاهر می‌شود، حافظه را می‌سنجد نه توانایی را. تشخیص آلودگی سخت است، اما اولین قدم رویه‌ای است: یک تقسیم خصوصی نگه دارید، آیتم‌های عمومی را هش کنید و برای نزدیک-تکراری‌ها در برابر هر پیکره‌ای که می‌توانید بازرسی کنید بررسی کنید. جایی که نمی‌توانید بازرسی کنید، ریسک را گزارش دهید نه امتیاز را.
انحراف محیط
نسخه‌های توکنایزر، استاب‌های ابزار و مهلت‌ها بین اجراها تغییر می‌کنند. یک انتشار وصله توکنایزر می‌تواند تعداد توکن‌هایی که یک پرامپت مصرف می‌کند را تغییر دهد، که رفتار برش را تغییر می‌دهد، که امتیازها را روی آیتم‌های زمینه بلند تغییر می‌دهد. یک استاب ابزار که در یک اجرا پاسخ آماده و در اجرای بعدی پاسخ زنده برمی‌گرداند، وظیفه را کاملاً تغییر می‌دهد. مهلتی که در ژانویه ۳۰ ثانیه و در مارس ۱۰ ثانیه بود، مدل‌های استدلال‌محور را به‌طور نامتناسب جریمه می‌کند. هیچ‌کدام از این‌ها تغییرات مدل نیستند. همه‌شان جدول امتیازات را جابه‌جا می‌کنند.
یک هارنس به مجموعه پاسخ‌های شناخته‌شده نیاز دارد
راه‌حل همان چیزی است که برای هر سرویس تولیدی استفاده می‌شود: یک مجموعه تست که روی هر ارزیابی اجرا می‌شود، نه گهگاه.
ارسال‌های عمداً شکستهای که باید شکست بخورند و ارسال‌های بی‌اهمیتی که باید قبول شوند را بگنجانید. ارسالی که رشته خالی برمی‌گرداند باید صفر بگیرد. ارسالی که پاسخ مرجع را عیناً برمی‌گرداند باید یک بگیرد. ارسالی که پاسخ قابل‌قبول‌نما اما غلط برمی‌گرداند باید صفر بگیرد. اگر هر یک از این انتظارات وارونه شود، هارنس شکسته است و اجرا باطل است. این یک کاناری به معنای دقیق کلمه است: یک ورودی شناخته‌شده با یک خروجی شناخته‌شده، که قبل از اعتماد به بار کاری واقعی بررسی می‌شود.
نسخه‌های مدل، توکنایزر، قالب پرامپت و استاب ابزار را در یک مانیفست واحد پین کنید. یک فایل، ثبت‌شده در مخزن، که هر نتیجه به آن ارجاع می‌دهد. اگر مانیفست تغییر کند، اجرا یک اجرای جدید است و نتایج با اجرای قبلی قابل‌مقایسه نیستند. این همان انضباط یک lockfile است، اعمال‌شده بر ارزیابی.
فواصل اطمینان را منتشر کنید، نه برآوردهای نقطه‌ای. یک شکاف دو واحدی روی ۲۰۰ آیتم نویز است. گزارش یک عدد واحد خوانندگان را دعوت می‌کند تا مدل‌هایی را رتبه‌بندی کنند که از نظر آماری غیرقابل‌تفکیک
.
گزارشی که از بازبینی جان سالم به در می‌برد
یک بنچمارک یک ادعاست و ادعاها باید قابل‌حسابرسی باشند.
نتایج هر دسته را با تعداد نمونه گزارش دهید. امتیازهای تجمعی برش‌های نازک را پنهان می‌کنند. مدلی که به‌طور کلی خوب امتیاز می‌گیرد اما ۱۲ آیتم در دسته‌ای دارد که بیشترین ارتباط را با مورد استفاده خواننده دارد، شاهدی برای آن مورد استفاده نیست. تعداد را کنار امتیاز نشان دهید تا خواننده بتواند به‌طور مناسب تخفیف دهد.
متن‌های خام و خروجی‌های ارزیاب‌کننده را نگه دارید. وقتی یک امتیاز مورد اختلاف است، اختلاف باید با بازداوری حل شود، نه با اجرای مجدد و امیدواری. متن کامل، پاسخ استخراج‌شده، مرجع و تصمیم ارزیاب‌کننده را ذخیره کنید. این همچنین امکان بازامتیازدهی اجراهای تاریخی تحت یک ارزیاب‌کننده اصلاح‌شده را فراهم می‌کند، که تنها راه صادقانه مقایسه در سراسر یک اصلاح هارنس است.
مجموعه ارزیابی را مثل کد نسخه‌بندی کنید و هر ویرایش خاموش را به‌عنوان یک تغییر شکننده تلقی کنید. آیتمی که بازنویسی می‌شود، مرجعی که اصلاح می‌شود، آیتمی که حذف می‌شود چون مبهم بود: هر یک از این‌ها معنای هر امتیاز محاسبه‌شده پس از آن را تغییر می‌دهد. مجموعه ارزیابی را برچسب بزنید، برچسب را در مانیفست ثبت کنید و وقتی ویرایشی ضروری است، قبل و بعد را منتشر کنید نه اینکه بی‌صدا بازنویسی کنید.
معامله صادقانه
سخت‌گیری توان عملیاتی را هزینه می‌کند. یک استخراج‌کننده سخت‌گیر که روی خروجی غیرقابل‌تجزیه استثنا پرتاب می‌کند، اجراهای بیشتری را باطل می‌کند و یک مجموعه پاسخ‌های شناخته‌شده به هر ارزیابی سرباری ثابت اضافه می‌کند. تیم‌های تحت فشار زمان وسوسه می‌شوند در حالت آسان‌گیر اجرا کنند و بعداً تمیزکاری کنند. استدلال مخالف این است که یک اجرای آسان‌گیر اعدادی تولید می‌کند که قابل‌اعتماد نیستند و اعداد غیرقابل‌اعتماد بدتر از نبود اعداد هستند چون به تصمیمات منتشر می‌شوند.
سازش عملی این است که به‌طور پیش‌فرض سخت‌گیرانه اجرا کنید و یک حالت آسان‌گیر را مجاز کنید که به‌صراحت در خروجی برچسب‌گذاری شده است. برچسب با نتیجه سفر می‌کند. خواننده‌ای که lenient: true می‌بیند می‌داند که باید امتیاز را تخفیف دهد. خواننده‌ای که lenient: false و یک مجموعه پاسخ‌های شناخته‌شده قبول‌شده می‌بیند می‌داند که دستگاه بررسی شده است.
این چه چیزی را تغییر می‌دهد
برخورد با هارنس به‌عنوان نرم‌افزار تولیدی سه چیز را تغییر می‌دهد. کد ارزیابی را با همان استانداردهای بازبینی کد سرویس‌دهی به کنترل نسخه منتقل می‌کند. مجموعه پاسخ‌های شناخته‌شده را به یک دروازه تبدیل می‌کند نه یک پس‌فکر. و باعث می‌شود هر امتیاز منتشرشده منشأ خود را حمل کند: کدام مانیفست، کدام برچسب مجموعه ارزیابی، کدام تعداد نمونه‌ها، کدام فاصله.
هیچ‌کدام از این‌ها بنچمارک‌گیری را آسان نمی‌کند. آن را صادقانه می‌کند. تیمی که ۲۷ مدل را بنچمارک کرد و سپس بنچمارک خودش را اصلاح کرد، کاری را انجام داد که بیشتر جدول‌های امتیاز منتشرشده از آن می‌گذرند. نتیجه عددی است که می‌توان از آن دفاع کرد، که تنها نوع ارزشمند برای انتشار است.