‏olmo-eval: میز کار ارزیابی مدل‌های زبانی

تو این مقاله که تیم Ai2 نوشته، اومده که وقتی داری یه مدل زبانی بزرگ (LLM) می‌سازی، بارها و بارها بعد از هر تغییر تو داده، معماری یا hyperparameterها مجبوری دوباره ارزیابیش کنی. به گفته‌ی نویسنده، بیشتر ابزارهای موجود برای این کار ساخته نشدن: یا برای اجرای بنچمارک‌های ثابت روی مدل‌های تمام‌شده‌ان، یا مدل رو تو یه sandbox با مسائل چندمرحله‌ای می‌سنجن. این‌ها با مدلی که مدام داره عوض می‌شه جلو نمیان.

پروژه‌ی قبلی این تیم برای حل همین مشکل، OLMES بود؛ یه استاندارد باز که سال ۲۰۲۴ معرفی شد تا نمره‌ی بنچمارک‌ها بین نسخه‌های مختلف قابل‌مقایسه بشه. مشکل این بود که یه مدل رو با روش‌های متفاوت (مثلاً فرمت prompt یا نحوه‌ی صورت‌بندی task) نمره می‌دادن و ادعاها قابل‌بازتولید نبود. حالا olmo-eval روی همون OLMES ساخته شده ولی به بقیه‌ی مراحل توسعه هم گسترش پیدا کرده.

نویسنده olmo-eval رو با Harbor مقایسه می‌کنه. Harbor همه‌چیز رو تو containerهای مهروموم‌شده و قابل‌بازتولید اجرا می‌کنه که سنگینه. ولی olmo-eval بهت اجازه می‌ده برای هر بنچمارک انتخاب کنی چطوری اجرا بشه: بنچمارکی که فقط می‌خواد مدل به سوال جواب بده مستقیم و سریع اجرا می‌شه، و فقط جایی که لازمه (مثلاً اجرای کدی که خود مدل نوشته) سراغ container ایزوله می‌ره. مسیر سبک حالت پیش‌فرضه.

نکته‌ی کلیدی معماری اینه که منطق بنچمارک از runtime policy (یعنی اینکه مدل چطوری اجرا می‌شه تا جواب بده) جدا نگه داشته شده. تو olmo-eval، خود مدل، ابزارهایی که می‌تونه استفاده کنه، محیط container و حتی مدل داور (LLM-as-a-judge) همه قطعه‌های قابل‌تعویض‌ان. تعریف یه بنچمارک با یه task انجام می‌شه که می‌گه دیتاست چیه، درخواست‌ها چطوری ساخته می‌شن و جواب مدل چطوری نمره می‌گیره:

@register("internal_freshqa")
class InternalFreshQA(Task):
    data_source = DataSource(path="s3://evals/internal/freshqa.jsonl", split="test")
    formatter = ChatFormatter()
    sampling_params = SamplingParams(temperature=0.0)
    metrics = (AccuracyMetric(scorer=ExactMatchScorer),)

چون runtime policy تو harness زندگی می‌کنه نه تو تعریف task، همون بنچمارک رو می‌شه راحت زیر اجراهای مختلف دوباره اجرا کرد؛ مثلاً یه بار به‌صورت baseline و یه بار با ابزار و جستجوی فعال، فقط با عوض‌کردن --harness. این جداسازی باعث می‌شه بدون دست‌زدن به اینکه چی داره اندازه‌گیری می‌شه، شرایط اجرا عوض بشه.

به گفته‌ی نویسنده مفیدترین قابلیت، نمایشگر مقایسه‌ی جفتیه: olmo-eval نمره‌ی کلی هر مدل رو با خطای استاندارد و حداقل اثر قابل‌تشخیص (کوچیک‌ترین تفاوتی که می‌شه مطمئن از نویز جداش کرد) گزارش می‌ده، ولی همین سوال‌ها رو هم سوال‌به‌سوال بین دو checkpoint کنار هم می‌ذاره. این‌جوری می‌فهمی یه تغییر ۲.۴ درصدی تو میانگین، بهبود واقعیه یا فقط نویز.

نکات کلیدی:

• olmo-eval یه میز کار باز برای ارزیابی LLM در حین توسعه‌ست، نه فقط نمره‌دادن یه‌باره به مدل تمام‌شده
• ادامه‌ی استاندارد OLMES هست و ارزیابی agentic و چندمرحله‌ای رو درجه‌یک پشتیبانی می‌کنه
• منطق بنچمارک (task) از نحوه‌ی اجرا (harness) جدا شده، پس مدل، ابزارها، container و مدل داور همه قابل‌تعویض‌ان
• مسیر سبک پیش‌فرضه و فقط بنچمارک‌هایی که لازم دارن سراغ container ایزوله می‌رن
• نمایشگر مقایسه‌ی سوال‌به‌سوال بین دو checkpoint کمک می‌کنه بفهمی تغییر واقعیه یا نویز