پرش به محتوای اصلی

آلودگی بنچمارک یک باگ خط لوله داده است: نسخه‌بندی مجموعه‌های ارزیابی مانند کد

شکست‌های ارزیابی عامل که به ضعف مدل نسبت داده می‌شوند، اغلب شکست‌های بهداشت مجموعه ارزیابی هستند. مجموعه‌های ارزیابی به همان منشأ، نسخه‌بندی و کنترل دسترسی داده‌های آموزشی نیاز دارند.

Detailed view of an Intel i486 DX2 CPU installed on a vintage motherboard with chips and circuits.

نشانه و تشخیص نادرست

یک تیم یک عامل را عرضه می‌کند، مجموعه ارزیابی را اجرا می‌کند و می‌بیند که امتیاز کل برای چند هفته بالا می‌رود و سپس صاف می‌شود. گاهی اوج می‌گیرد، سپس در اجرای بعدی بدون هیچ تغییری در کد افت می‌کند. غریزه به سمت معماری می‌رود: تعویض برنامه‌ریز، افزودن یک عامل منتقد، گسترش پنجره بازیابی، تغییر طرح‌واره فراخوانی ابزار. هفته‌ها مهندسی صرف مشکلی می‌شود که هرگز در مدل نبوده است.

خود مجموعه ارزیابی جابه‌جا شده است. آیتم‌ها بدون افزایش نسخه در جای خود ویرایش شده‌اند. یک قالب پرامپت که با چند مثال تنظیم شده بود، بی‌سروصدا آن مثال‌ها را در بلوک چند-نمونه‌ای خود جذب کرده است. یک نمایه بازیابی که از مستندات داخلی ساخته شده بود، تصادفاً شامل سؤالات ارزیابی و پاسخ‌هایشان بود. امتیاز تغییر کرد چون ابزار اندازه‌گیری تغییر کرد، و هیچ‌کس متوجه نشد چون ابزار هرگز به عنوان یک مصنوع تلقی نشد.

چارچوبی که کمک می‌کند این است: یک مجموعه ارزیابی یک مجموعه‌داده است. دارای نویسندگی، منشأ، محدودیت‌های مجوز، مواجهه با حریم خصوصی، توزیع و چرخه عمر است. برخورد با آن به عنوان پوشه‌ای از JSON که هر کسی می‌تواند ویرایش کند، علت اصلی بیشتر آلودگی‌هاست. راه‌حل یک مدل هوشمندتر نیست. راه‌حل همان نظمی است که برای داده‌های آموزشی اعمال می‌شود، اعمال‌شده بر چیزی که با آن اندازه‌گیری می‌کنید.

مجموعه ارزیابی را به عنوان یک مصنوع نسخه‌بندی‌شده در نظر بگیرید

یک مجموعه ارزیابی باید پس از انتشار تغییرناپذیر باشد. نه «ما سعی می‌کنیم آن را ویرایش نکنیم» — از نظر ساختاری تغییرناپذیر، با هر بازبینی که به صورت محتوا-آدرس‌دهی شده باشد تا یک اجرا بتواند دقیقاً ثبت کند که در برابر چه چیزی امتیاز گرفته است.

یک مکانیزم عملی، مانیفستی است که هر آیتم و کل مجموعه را هش می‌کند:

set: agent-tool-use-core
revision: 2024-11-07.3
items_hash: sha256:9f2c...
item_count: 412
retired:
  - id: tool-0183
    reason: saturated
    superseded_by: tool-0411

Close-up of colorful source code on a monitor, showcasing programming and technology concepts.

هارنس قبل از شروع اجرا، revision را به یک هش محتوا تبدیل می‌کند و آن هش را در رکورد نتیجه می‌نویسد. اگر هش با مانیفست مطابقت نداشته باشد، اجرا متوقف می‌شود. این محدودیت واحد یک کلاس کامل از باگ‌ها را حذف می‌کند: امتیازی که ماه گذشته با آن مقایسه کردید در برابر یک ابزار متفاوت تولید شده بود، و اکنون سیستم اجازه نمی‌دهد خلاف آن را وانمود کنید.

تغییرناپذیری هزینه دارد. وقتی یک آیتم واقعاً اشتباه است — جمله‌بندی مبهم، امضای API قدیمی در ردپای فراخوانی ابزار، پاسخ واقعی که از آن زمان تغییر کرده است — نمی‌توانید آن را وصله کنید. آن را بازنشسته می‌کنید و یک جایگزین اضافه می‌کنید، که به این معنی است که مجموعه یک تبار رشد می‌کند و مقایسه‌های تاریخی شما باید جایگزینی را در نظر بگیرند. تیم‌هایی که این نظم را نادیده می‌گیرند، سری‌های زمانی تمیزتری به دست می‌آورند که بی‌سروصدا بی‌معنی هستند. این معاوضه واقعی است و ارزش نام بردن دارد: شما راحتی را با توانایی اعتماد به خط روند خود معاوضه می‌کنید.

نظم هولداوت

یک آیتم ارزیابی نباید در هیچ پرامپت، نمایه بازیابی، مجموعه تنظیم دقیق، یا مثال چند-نمونه‌ای که در طول توسعه استفاده می‌شود ظاهر شود. این بدیهی به نظر می‌رسد و به طور معمول نقض می‌شود، معمولاً از طریق بازیابی.

وقتی یک عامل یک مرحله بازیابی روی مستندات داخلی دارد، و مجموعه ارزیابی در همان مخزن یا همان مخزن برداری ذخیره شده است، پرسشی که از نظر معنایی نزدیک به یک سؤال ارزیابی است، آیتم ارزیابی را نمایان می‌کند. سپس عامل از مجموعه ارزیابی پاسخ می‌دهد نه از توانایی. هیچ چیز در خروجی اشتباه به نظر نمی‌رسد؛ فقط امتیاز بالا می‌رود.

کنترلی که این را می‌گیرد یک کاناری است. نمایه ارزیابی را با آیتم‌هایی که پاسخ‌های صحیحشان مشخص است و به عنوان کاناری علامت‌گذاری شده‌اند، بکارید. آن‌ها را جدا از مجموعه اصلی امتیازدهی کنید و نرخ برخورد کاناری را به عنوان نرخ آلودگی گزارش دهید. اگر کاناری‌ها با نرخی بالاتر از تصادف بازیابی یا پاسخ داده شوند، نمایه در حال نشت است و عدد اصلی مشکوک است.

کاناری‌ها ارزان و ناقص هستند. آن‌ها نشت از مسیر بازیابی و از طریق ساخت پرامپت را تشخیص می‌دهند، اما حفظ کردن پخته‌شده در وزن‌های مدل در طول پیش‌آموزش را تشخیص نمی‌دهند. برای آن، تنها سیگنال‌های قابل اعتماد زمانی هستند: آیتم‌هایی که پس از مهلت آموزشی یک مدل نوشته شده‌اند، یا آیتم‌هایی که در یک استخر خصوصی نگهداری می‌شوند و هرگز منتشر نشده‌اند. هر دو محدود می‌کنند آنچه را که می‌توانید اندازه‌گیری کنید، زیرا یک استخر خصوصی را نمی‌توان با تابلوی امتیازات عمومی مقایسه کرد. این همان معاوضه است — قابلی

هر آیتم باید منبع و نویسندگی خود را حمل کند. نه برای اعتبار، بلکه برای اینکه محدودیت‌های مجوز و حریم خصوصی بتوانند هنگام تغییر دوباره ارزیابی شوند. مجموعه‌داده‌ای که دو سال پیش مجاز به استفاده بود ممکن است امروز نباشد، و مجموعه‌ای که از رونوشت‌های مشتری خزش‌شده جمع‌آوری شده است ممکن است حاوی داده‌های شخصی باشد که هرگز برای استفاده در ارزیابی پاک‌سازی نشده است. بدون منشأ هر آیتم، تنها اصلاح موجود دور انداختن کل مجموعه است.

A person working on a graph analysis on a laptop for data monitoring and research.

کنترل دسترسی نیمه دوم است. مجموعه ارزیابی باید توسط هارنس و تقریباً هیچ چیز دیگری قابل خواندن باشد. مهندسانی که روی پرامپت‌ها تکرار می‌کنند نیازی به دسترسی خواندن به آیتم‌های ارزیابی ندارند؛ آن‌ها به نتایج تجمیعی و تفکیک‌های هر برش نیاز دارند. اعطای دسترسی خواندن به افرادی که شغلشان بهبود امتیاز است، انگیزه آشکاری برای بیش‌برازش ایجاد می‌کند، حتی با نیت خوب.

در کنار کنترل دسترسی، هر بازیابی که در طول توسعه به نمایه ارزیابی دست زده است را ثبت کنید. یک گزارش بازیابی که نشان می‌دهد یک آیتم ارزیابی در یک جلسه توسعه ظاهر شده است، یک رویداد آلودگی است، خواه تصمیمی را تغییر داده باشد یا نه. گزارش این رویداد را پس از واقع قابل حسابرسی می‌کند نه نامرئی.

معاوضه صادقانه در اینجا سرعت است. محدود کردن دسترسی خواندن ارزیابی حلقه اشکال‌زدایی را کند می‌کند، زیرا مهندسی که به یک حالت شکست خاص مشکوک است نمی‌تواند به سادگی آیتم را باز کند و بخواند. جبران آن یک مجموعه توسعه جداگانه و آشکارا قابل خواندن است که صراحتاً برای گزارش‌دهی استفاده نمی‌شود. دو مجموعه، دو هدف، یکی قفل شده.

رویه گزارش‌دهی

یک عدد اصلی بدون بازبینی و نرخ آلودگی یک اندازه‌گیری نیست. یک ادعاست. هر امتیاز منتشرشده باید بازبینی مجموعه، هش محتوا، و نرخ آلودگی مشتق‌شده از کاناری را در کنار خود حمل کند. اگر نرخ آلودگی غیرجزئی است، امتیاز باید با آن هشدار گزارش شود نه به عنوان یک رقم واحد.

تجمیع‌ها همچنین رگرسیون را پنهان می‌کنند. یک میانگین واحد روی یک مجموعه مختلط، توانایی‌ای را که تنزل یافته در حالی که دیگری بهبود یافته، پنهان می‌کند. برش‌های هر توانایی را گزارش دهید — انتخاب ابزار، ساخت آرگومان، بازیابی چند مرحله‌ای، رفتار امتناع — و آن‌ها را با همان نظم بازبینی تجمیع گزارش دهید. برشی که با مقدار کمی روی مجموعه‌ای از چند ده آیتم حرکت می‌کند یک سیگنال نیست؛ تعداد آیتم را گزارش دهید و بگذارید خواننده قضاوت کند.

در نهایت، آیتم‌های اشباع‌شده را طبق برنامه بازنشسته کنید. آیتمی که هر مدل فعلی آن را پاس می‌کند چیزی جز یک خط پایه چاپلوسانه و یک میانگین رقیق‌شده کمک نمی‌کند. انباشتن آیتم‌های اشباع‌شده باعث می‌شود مجموعه جامع به نظر برسد در حالی که تجمیع را هر سه ماه کمتر آموزنده می‌کند. آن‌ها را بازنشسته کنید، بازنشستگی را در مانیفست ثبت کنید، و آن‌ها را با آیتم‌هایی که تمایز قائل می‌شوند جایگزین کنید.

هیچ یک از این‌ها جذاب نیست. این مهندسی داده است که بر ابزار اندازه‌گیری اعمال می‌شود، و تفاوت بین امتیازی است که معنی دارد و امتیازی که حرکت می‌کند چون خط لوله حرکت کرده است.

اشتراک‌گذاریXLinkedInپیوند یکتا5 دقیقه مطالعه

خواندن مرتبط

پرسش‌هایی که این پاسخ می‌دهد

What is benchmark contamination in agent evaluation?

It is the condition where an eval set has drifted, leaked into prompts or retrieval indexes, or been partly memorised by the model, so the score reflects exposure to the items rather than the capability the set claims to measure.

Why version an eval set instead of just editing items in place?

An immutable, content-hashed revision lets a run record exactly which instrument produced a score. Editing in place makes historical comparisons meaningless, because the set and the score both changed with no traceable link.

How do canary items detect leakage?

Canaries are known-answer items seeded into the eval index and scored separately. If they are retrieved or answered above chance, the index is leaking and the headline number should be treated as contaminated.

Should engineers who tune prompts have read access to the eval set?

No. Read access should be limited to the harness, with aggregate and per-slice results exposed to engineers. A separate, openly readable development set covers debugging without creating overfitting pressure on the reported set.