ارزیابی LLM: از benchmarkهای عمومی تا مجموعه طلایی شما

تقریباً هر بحثی درباره ارزیابی، دو نفرند که چیزهای متفاوتی را اندازه می‌گیرند. سه پروژه وجود دارد و هیچ ابزار مشترکی ندارند.

این سردرگمی در یک جهت پرهزینه است. leaderboard به شما می‌گوید یک model در استدلال سطح تحصیلات تکمیلی قوی است؛ نمی‌تواند بگوید آیا ticketهای پشتیبانی شما را route می‌کند یا نه. و ارزیابی اپلیکیشنی که برای هر ورودی یک پاسخ را score می‌کند اصلاً agent را نمی‌بیند، چون agent توزیعی از مسیرها دارد و یک پاسخ فقط یک نمونه از آن است. Chapter 22 آن ردیف سوم را نام‌گذاری کرد و خالی گذاشت: معیار عملکرد، همان بخشی از مشخصات agent که تیم‌ها آخر از همه می‌نویسند یا هرگز نمی‌نویسند.

ترتیب هم مهم است، و فروشنده model هم همین را می‌گوید. راهنمای agentهای OpenAI انتخاب model را به سه گام، با همین ترتیب، کاهش می‌دهد: «Set up evals to establish a performance baseline»، «Focus on meeting your accuracy target with the best models available»، «Optimize for cost and latency by replacing larger models with smaller ones where possible».¹ ارزیابی اول می‌آید، چون گام‌های دو و سه بدون عدد بی‌معنی‌اند.

مجموعه طلایی فهرستی از ورودی‌هاست که پاسخ هرکدام نوشته شده، و یک grader که تصمیم می‌گیرد خروجی مطابق است یا نه. کسل‌کننده است، کوچک است، و تنها artefact این فصل است که مال شماست. مجموعه‌ای که اینجا ساخته شده بیست کار روی دایرکتوری پنج‌فایلی دارد — نه سه فایل Chapter 23، پس پاسخ‌ها همان پاسخ‌ها نیستند — و grader قبل از اجرای agent نوشته می‌شود:

export type Task = {
  id: string;
  prompt: string;
  answer: string;          // the fact, in words, for a human and for a judge
  must: RegExp[];          // ALL must match the final answer
  mustNot?: RegExp[];      // NONE may match
};

export const GOLDEN: Task[] = [
  { id: "t04", prompt: "Which file is the largest?", answer: "access.log",
    must: [/access\.log/i], mustNot: [/errors\.log/i, /notes\.txt/i] },       
  { id: "t12", prompt: "Which HTTP status codes appear in access.log? List all of them.",
    answer: "200, 429 and 500", must: [/200/, /429/, /500/] },                
  // ...eighteen more
];

دو ویژگی بار اصلی را می‌کشند. فهرست mustNot وجود دارد چون modelی که سه فایل را نام می‌برد و یکی‌شان درست است، پاسخ نداده. و answer هم در نثر نوشته شده هم در patternها، چون بعداً هم انسان و هم judge به آن نیاز دارند — و نوشتن یک واقعیت در دو notation، راهی است برای فهمیدن اینکه خودتان هم درباره چیستی کار با خودتان توافق نداشته‌اید.

حالا جدول تصمیم‌گیرنده. چهار سیستم نامزد، همان بیست کار، accuracy با بازه‌اش، و دو ستونی که جدول‌های صرفاً accuracy همیشه پنهان می‌کنند:

قبل از برنده، بازه‌ها را بخوانید. اجراهای بازوی B از 11٪ تا 47٪ می‌روند؛ بازوی A از 3٪ تا 30٪. در بیشتر طولشان هم‌پوشانی دارند، که یافته Chapter 4 دقیقاً همان‌جایی می‌رسد که وعده داده شده بود: بیست مورد نمی‌تواند چهار سیستم را رتبه‌بندی کند. Chapter 15 این را با پرسش جفتی تیزتر کرد — در مواردی که دو بازو اختلاف دارند، تقسیم چقدر یک‌طرفه است؟ — چون دشواری مشترک مجموعه حذف می‌شود. این همه جفت‌هاست:

A vs B  +0 / -3   p = 0.2500       B vs C  +4 / -1   p = 0.3750
A vs C  +2 / -2   p = 1.0000       B vs D  +4 / -0   p = 0.1250
A vs D  +2 / -1   p = 1.0000       C vs D  +1 / -0   p = 1.0000

هیچ‌کدام از شش مقایسه تثبیت نشده است. بهترین بازو بازوی بدون ابزار را پانزده امتیاز می‌برد، و این ادعا روی سه مورد discordant بنا شده. بیست مورد یک سازوکار را نشان می‌دهد و نمی‌تواند تأمین‌کننده انتخاب کند؛ گفتن خلافش در جلسه همان‌جایی است که model بد خریداری می‌شود.

یک چیز هست که این جدول ثابت می‌کند، و همان ستونی است که هیچ‌کس نمی‌گذارد. بازوی D به‌ازای هر کار حل‌شده سیزده برابر بازوی B هزینه دارد، چون نمونه‌گیری سه مسیر و گرفتن پاسخ modal صورت‌حساب را سه برابر می‌کند، چه accuracy را سه برابر کند چه نکند. جدول‌های accuracy که هزینه را حذف می‌کنند این trade-off را نامرئی می‌کنند.

حالا یافته‌ای که شیوه خواندن هر benchmark آینده را عوض می‌کند. همان دویست transcript را بگیرید — بیست کار، ده اجرا، بدون بازتولید حتی یک token — و سه جور score کنید:

صفر، سیزده، بیست‌وشش. سیستم تغییر نکرد. grader تغییر کرد. exact match صفر می‌دهد نه چون agent بی‌فایده است، بلکه چون هیچ پاسخ متن‌آزادی هرگز byte به byte با reference یکسان نیست: formatting را اندازه می‌گیرد و آن را capability گزارش می‌کند.

این کنجکاوی نیست، سازوکار است، و نام دارد. یک metric با hard cutoff یک کار را روی چند sub-fact به‌صورت همه‌یا‌هیچ score می‌کند، پس مرکب می‌شود. کار t12 سه status code را هم‌زمان می‌خواهد. در ده اجرا:

per-code presence   200: 9/10    429: 6/10    500: 8/10    (mean 0.77 per fact)
all three at once   5/10

هر fact حدود سه‌چهارم مواقع درست است؛ خواستن هر سه با هم score را نصف می‌کند، و $0.77^3 = 0.457$ آن‌قدر به 0.50 اندازه‌گیری‌شده نزدیک است که نشان دهد افت از کجا آمده. تعمیم دهید:

ردیف 0.90 را کنار ردیف 0.95 در $k = 10$ بخوانید: بهبود پنج‌امتیازی در هر fact، روی conjunction به بیست‌وپنج امتیاز تبدیل می‌شود. هیچ اتفاق ناپیوسته‌ای برای model نیفتاده. یک منحنی نرم که از خلال metric همه‌یا‌هیچ خوانده شود مثل جهش دیده می‌شود — دقیقاً همان استدلالی که Schaeffer، Miranda و Koyejo درباره توانایی‌های emergent مطرح کردند و Chapter 10 به اینجا موکول کرد.² ممیزی آن‌ها نشان داد حداکثر 5 مورد از 39 metric ترجیحی BIG-Bench اصلاً emergence نشان می‌دهند، و دو metric ناپیوسته مسئول بیش از 92٪ موارد ادعایی‌اند.

پس انضباط در یک خط: جهش در نمودار تا وقتی خلافش ثابت نشده، شاهدی درباره metric است. قبل از اینکه باور کنید capability ظاهر شده، همان اجراها را با metricی plot کنید که credit جزئی می‌دهد و ببینید پرتگاه باقی می‌ماند یا نه.

نسخه مرتبه دوم این موضوع، به گفته Kalai و همکاران، بالادست آسیب می‌زند: benchmarkهایی که درست/غلط score می‌کنند حدس‌زدن را بیش از گفتن «نمی‌دانم» پاداش می‌دهند، پس modelی که علیه آن‌ها optimize شده یاد می‌گیرد حدس بزند. راه‌حل پیشنهادی‌شان benchmark hallucination تازه نیست، بلکه «modifying the scoring of existing benchmarks that are misaligned but dominate leaderboards» است.³ مجموعه طلایی شما همین اهرم را دارد، و فقط یک خط است: تصمیم بگیرید abstention شکست حساب می‌شود یا category خودش. بیشتر مردم هرگز تصمیم نمی‌گیرند، پس بی‌صدا شکست حساب می‌شود، و سیستمی که ship می‌کنند حدس می‌زند.

تا اینجا هر کار با یک تلاش score شد. agent یک تلاش نیست. Chapter 17 نشان داد حتی در temperature صفر determinism ندارید، پس همان ورودی توزیعی از مسیرها تولید می‌کند و benchmarkی که هر کار را یک‌بار اجرا می‌کند فقط یک نمونه از آن را گزارش می‌دهد.

مشارکت τ-bench همین metric است. مقاله صریح تعریف می‌کند: «we propose a new metric – pass^k (pass hat k), defined as the chance that all k i.i.d. task trials are successful, averaged across tasks.»⁴ هر کار را $n$ بار اجرا کنید، موفقیت‌های $c$ را بشمارید، و برآوردگرهای unbiased چنین‌اند:

دومی همان pass@k آشنا از code generation است: احتمال اینکه حداقل یکی از $k$ تلاش موفق شود. آن‌ها را کنار هم روی همان شمارش‌های اندازه‌گیری‌شده بگذارید و در جهت‌های مخالف حرکت می‌کنند:

همان اجراها، همان grader، همان بیست کار. یک ستون می‌گوید سیستم با تلاش‌های بیشتر بهتر می‌شود و ستون دیگر می‌گوید بدتر می‌شود، و هر دو درست‌اند، چون به دو سؤال متفاوت جواب می‌دهند. pass@k وقتی metric درست است که انسان خروجی را فیلتر می‌کند — code generation، draftها، brainstorming — و تلاش‌های اضافی ارزان‌اند. pass^k وقتی metric درست است که agent بدون فیلتر عمل می‌کند، و این همان معنای «agent» است. انتشار اولی در جایی که دومی مصداق دارد رایج‌ترین اغراق این حوزه است، و تیتر خود τ-bench نسخه صادقانه است: gpt-4o با حدود 61٪ pass^1 روی retail، در pass^8 به حدود 25٪ سقوط می‌کند.⁴

حالا نیش اعداد خودم. pass^10 روی بیست کار من 5.0٪ است: دقیقاً یک کار از بیست در هر ده اجرا حل شده. آن کار t19 است، «آیا deploy 42 موفق شد؟»، و این دو مورد از ده پاسخی هستند که rubric درست score کرده:

run 2  "To check if 'deploy.log' succeeded in deploying 42, I will list the file
        names in the working directory using the list_files function..."
run 8  "Yes, deploy 42 has successfully deployed. Deploying was successful for 41
        as well."

اولی اصلاً جواب نمی‌دهد. دومی ادعایی اضافه می‌کند که غلط است — deploy 41 rollback شده بود. هر دو با /succe|yes/ match شدند. تنها کاری که pass^10 را بالای صفر نگه داشته artefact grader است، پس عدد واقعی صفر است، و هیچ aggregateی این را نشان نمی‌داد. نمونه‌برداری از transcriptهای پشت بهترین کارتان، جایی است که graderها می‌میرند.

و یک عدد دیگر، همان عددی که این بخش به نامش است. ده ارزیابی یکسان — همان سیستم، همان بیست کار، همان کد، هیچ چیز جز seedها عوض نشده:

per-run correct: 5 2 5 5 8 5 8 5 4 5   ->  10 % .. 40 %,  mean 26.0 %,  sd 8.8 points

دامنه سی‌امتیازی روی سیستمی که تغییر نکرده. اگر suite خود را یک‌بار قبل از release و یک‌بار بعد از آن اجرا کنید، «بهبود» هشت‌امتیازی داخل همین spread است و آن را ship می‌کنید با این باور که شما باعثش شده‌اید. به همین دلیل بازه pooled بالا — 26.0 % [20.4, 32.5] — به‌تنهایی بیش از حد باریک است: با دویست trial هم‌بسته مثل دویست trial مستقل رفتار می‌کند. خلاصه صادقانه ارزیابی agent یک میانگین و spread روی تکرارهاست، و تقریباً هیچ‌کس دومی را منتشر نمی‌کند.

rubricها برای پاسخ‌های open-ended scale نمی‌شوند، پس حرکت استاندارد این است که یک model خروجی را grade کند. در مقیاس frontier آن‌قدر خوب کار می‌کند که default باشد، و سه failure mode نام‌دار دارد: position bias، verbosity bias و self-enhancement bias.⁵

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

judge شصت بار از شصت بار گفت PASS. این agent را روی مجموعه‌ای که انسان 18٪ score می‌کند، با accuracy صددرصد گزارش می‌کرد. judgeی که قدرت تفکیک ندارد ابزار noisy نیست؛ تابع ثابت است، و تابع ثابت به بهترین و بدترین سیستم شما یک score می‌دهد.

Prompting نجاتش نداد. چهار variant، همان شصت item:

جابه‌جایی ترتیب دو label در instruction چهار verdict را جابه‌جا کرد. این اثر قابل اندازه‌گیری است و از نوع غلط: judge به شکل prompt پاسخ می‌دهد نه به پاسخی که جلویش است.

نمایش تمیز، pairwise است. بیست سؤال، هرکدام با یک candidate آشکارا درست و یک candidate آشکارا غلط، در هر دو ترتیب ارائه شده:

picked the FIRST option              40/40 = 100.0 %
order-consistent (same winner both ways)   0/20 = 0.0 %   [Wilson 0.0, 16.1]
picked the CORRECT answer            20/40 = 50.0 %

چهل بار از چهل بار position A را انتخاب کرد. 50٪ روی correctness competence جزئی نیست — حساب است، چون پاسخ درست دقیقاً در نصف trialها در position A قرار دارد. consistency اینجا همان‌طور تعریف می‌شود که MT-Bench تعریف می‌کند: «the percentage of cases where a judge gives consistent results when swapping the order of two assistants»، که مقایسه را apples to apples می‌کند: GPT-4 روی این معیار 65.0٪ می‌گیرد و few-shot prompting آن را به 77.5٪ رساند.⁵ مال من صفر می‌گیرد.

mitigation استاندارد هم از همان مقاله است: «call a judge twice by swapping the order of two answers and only declare a win when an answer is preferred in both orders.»⁵ اینجا اعمالش کنید و judge از بیست جفت صفر verdict قابل استفاده تولید می‌کند — که نتیجه درست است، و بی‌نهایت بهتر از بیست verdict مطمئن.

یک نکته روش‌شناختی که از خود نتیجه بیشتر می‌ارزد. من یک آزمون verbosity هم اجرا کردم: همان پاسخ درست، یک نسخه با جمله 36کلمه‌ای padding شده که چیزی اضافه نمی‌کند. judge دقیقاً در 50٪ trialها نسخه بلندتر را ترجیح داد — که شبیه نبود verbosity bias است و اصلاً چنین نیست، چون judgeی که همیشه position A را انتخاب می‌کند روی هر pairing متوازن 50٪ می‌گیرد. نمی‌توانید bias دوم را بسنجید تا bias اول کنترل نشده باشد. جابه‌جایی positionها refinementی برای بعداً نیست؛ همان چیزی است که هر اندازه‌گیری دیگر را قابل تفسیر می‌کند.

caveat صادقانه: این judge یک model نیم‌میلیاردپارامتری است، و هیچ‌کس نباید با چنین چیزی grade کند. نکته این نیست که judgeها بدند. نکته این است که تولید اعداد بالا هشت دقیقه هزینه داشت، و بدون آن‌ها verdict این judge درباره تصمیم shipping برابر 100٪ می‌شد.

این سومین و آخرین پنل Python اعلام‌شده دوره است، و دلیلش جایی است که اعداد عمومی از آن می‌آیند. lm-evaluation-harness شامل «over 60 standard academic benchmarks for LLMs, with hundreds of subtasks and variants implemented» است و «the backend for Hugging Face's popular Open LLM Leaderboard»؛ HELM، SWE-bench و τ-bench packageهای Python با entry pointهای Python هستند.⁶ اجرای model شما در برابر عدد منتشرشده یعنی اجرای کد آن‌ها، و روزی که بخواهید با عددی که کسی cite کرده مقایسه کنید، در این ecosystem هستید:

lm_eval --model hf \
    --model_args pretrained=EleutherAI/gpt-j-6B \
    --tasks hellaswag \
    --device cuda:0 \
    --batch_size 8

دلیل دوم این است که یک اندازه‌گیری در این فصل از طریق HTTP ناممکن است. Contamination — لو رفتن test set به داده training — شکستی است که benchmark عمومی را بی‌صدا بی‌معنا می‌کند، و تیزترین probe برای آن به loss خود model نیاز دارد، چیزی که هیچ chat API برنمی‌گرداند. این همان cross-entropy به‌ازای هر token از Chapter 8 است که به پرسشی درباره حافظه نشانه رفته:

def nll(text: str) -> float:
    """Mean negative log-likelihood per token, in nats."""
    ids = tok(text, return_tensors="pt").input_ids.to(model.device)
    with torch.no_grad():
        out = model(ids, labels=ids)
    return float(out.loss)

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

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

famous  "Permission is hereby granted, free of"
     -> "charge, to any person obtaining a copy of this software and associated
         documentation files (the "
famous  "All human beings are born free"
     -> "and equal in dignity and rights. The right to life, liberty, and security"
fresh   "All evaluation harnesses are born tiny"
     -> ", and the most common way to measure their size is by using a ruler."

سه مورد از پنج رشته مشهور از شش کلمه به بعد word-perfect ادامه یافتند؛ هیچ‌کدام از پنج مورد تازه چنین نشد. این یک model نیم‌میلیاردپارامتری است که MIT License را از بر می‌خواند. اگر benchmark شما روی وب عمومی است، فرض کنید در weights است. این همچنین استدلال کل فصل است: مجموعه طلایی‌ای که از داده خودتان نوشته‌اید و از هر repository خواندنی برای crawler دور نگه داشته‌اید، تنها test setی است که می‌توانید مطمئن باشید هرگز روی آن train نشده.

هنوز ارزش خواندن دارند، به شرطی که چیزی را بخوانید که هرکدام می‌سنجد، نه عدد واحدی که به آن چسبیده.

جدول را بردارید نه هیچ ردیف منفردی را. benchmarkهای agentic همگی انسان‌ها را بسیار بالاتر از modelها می‌گذارند، که برعکس benchmarkهای دانشی است و بهترین خلاصه یک‌خطی از وضعیت حوزه؛ اعدادشان در چند ماه پیر می‌شود، پس با تاریخ خواندنتان cite کنید؛ و هرکدام کاری را می‌سنجند که کار شما نیست.

Accuracy همان metricی است که درباره‌اش بحث می‌کنید. این‌ها metricهایی‌اند که تعیین می‌کنند چیز ship می‌شود یا نه. هر چهار از همان دویست اجرای اندازه‌گیری‌شده بیرون می‌آیند.

هزینه به‌ازای کار حل‌شده، نه به‌ازای call. agent برای هر تلاش $0.001345 هزینه دارد و برای هر کاری که واقعاً حل شده $0.005172 — یعنی 3.85 برابر بیشتر، چون سه‌چهارم تلاش‌ها هیچ تولید می‌کنند. Latency هم همین رفتار را دارد: 1,213 ms برای هر تلاش، 4,667 ms برای هر کار حل‌شده. هر retry، هر re-ask، هر مسیر رهاشده در عدد دوم است و در اولی نامرئی.

تشخیصی که از accuracy بهتر است. در 123 مورد از 200 تلاش، agent بدون حتی یک tool calling پاسخ داد — حدس زد به‌جای اینکه نگاه کند. با split روی آن:

answered without reading anything   8/123  =  6.5 %  [3.3, 12.3]
answered after reading something   44/77   = 57.1 %  [46.0, 67.6]

بازه‌ها حتی نزدیک لمس هم نمی‌شوند. این از aggregate 26٪ باارزش‌تر است، چون چیزی را که باید درست شود نام می‌برد — model در reasoning شکست نمی‌خورد، در نگاه‌کردن شکست می‌خورد — و fix در harness است نه model. یک caveat مطابق استانداردهای خود این فصل: دو گروه کارهای متفاوت‌اند، نه همان کارها به‌صورت paired، پس بخشی از gap شاید این باشد که درست روی سؤال‌هایی ابزارها را skip می‌کند که سخت می‌یابد. split تشخیصی است، نه ادعای causal.

نرخ مداخله انسانی metricی است که buyer اول از همه می‌پرسد: چه کسری از اجراها در approval، guardrail یا handoff متوقف شدند. interruptionهای typed فصل 23 آن را قابل شمارش می‌کنند، و وقتی به‌ازای نوع کار و هفته شمرده شود همان چیزی است که agentی را که شغلش را یاد می‌گیرد از agentی که بی‌صدا به queue تبدیل می‌شود جدا می‌کند.

Abandonment چیزی است که هیچ suite آفلاینی نمی‌بیند: کاربری که پاسخ را خواند، tab را بست و خودش کار را انجام داد. ارزیابی آفلاین gate است؛ ارزیابی production نمونه‌گیری پیوسته از ترافیک واقعی است، scoreشده با همان grader به‌علاوه این چهار مورد.

و قاعده‌ای به ارث رسیده از Chapter 17: هرگز روی خروجی exact assert نکنید. روی propertyها assert کنید — JSON معتبر، schema درست، tool درست call شده، عددی در tolerance، substring لازم حاضر. ستون exact-match ابتدای این فصل همان اتفاقی است که وقتی این قاعده شکسته شود رخ می‌دهد.

ارزیابی تأمین‌کننده فقط accuracy نیست، و این نیمه دوم ethics این دوره است، با heading خودش نه appendix.

bias را اندازه بگیرید، فرض نکنید. هرچه درباره رفتار model روی نام‌ها، dialectها، genderها یا nationalityها باور دارید، property قابل اندازه‌گیری pipeline شما است، و ابزار همان است که دارید: مجموعه طلایی را بگیرید، فقط attribute را تغییر دهید، paired مقایسه کنید. HELM دقیقاً به این دلیل وجود دارد که accuracy تنها جایی گزارش می‌شد که bias، toxicity، calibration و robustness هم قابل تصمیم‌گیری بودند.⁸ model card فروشنده نقطه شروع است، نه evidence درباره ورودی‌های شما.

Contamination سؤال تأمین‌کننده هم هست. probe بالا دلیل پرسیدن این است که عدد منتشرشده روی چه چیزی اندازه‌گیری شده، و cut داده model چه زمانی بوده.

Retention، training و residency، خوانده‌شده در 7 September 2026. این‌ها تغییر می‌کنند، پس تاریخ را کنار پاسخ ثبت کنید. صفحه policy Anthropic می‌گوید: «By default, we will not use your inputs or outputs from our commercial products (e.g. Claude for Work, Anthropic API, Claude Gov, etc.) to train our models»، با استثنای محتوایی که صراحتاً به‌عنوان feedback ارسال می‌کنید، که «for up to 5 years» ذخیره می‌شود.¹⁶ مستندات data controls OpenAI می‌گوید «data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)»، retention پیش‌فرض سی‌روزه برای abuse-monitoring logs را توضیح می‌دهد، و Zero Data Retention را ارائه می‌کند که «excludes customer content from abuse monitoring logs»، به‌علاوه data residency قابل پیکربندی در چند region.¹⁷

چهار سؤال را قبل از اولین call در production مکتوب بگیرید، چون هرکدام owner متفاوتی دارد: آیا داده من برای training استفاده می‌شود؛ چه مدت نگهداری می‌شود و توسط چه کسی؛ کجا پردازش و ذخیره می‌شود؛ و اگر به‌جای provider مستقیم از reseller، gateway یا aggregator استفاده کنم چه بر سر همه این‌ها می‌آید. آخری همان‌جایی است که بیشتر غافلگیری‌ها زندگی می‌کنند، و هیچ benchmarkی به شما نمی‌گوید.

حالا ابزار را دارید: مجموعه طلایی متعلق به خودتان، بازه روی هر عدد، آزمون paired برای هر مقایسه، pass^k برای اجراهایی که به کسی نشان ندادید، judge اندازه‌گیری‌شده، و probeی برای اینکه score عمومی اصلاً معنایی دارد یا نه. ادعای پایانی Chapter 23 حالا به‌جای assertion قابل check است — harness یک agent را قابل اداره می‌کند، نه درست — و check کردنش دویست اجرا و هشت دقیقه زمان برد.

یک ویژگی agent هست که هیچ‌کدام از این‌ها اندازه نمی‌گیرد، و همان چیزی است که آدم‌ها را اخراج می‌کند.

هر کاری در مجموعه طلایی این فصل را من نوشتم، و هر فایلی که agent خواند را من نوشتم. هیچ چیز در آن دایرکتوری تلاش نمی‌کرد کاری انجام دهد. یک خط را در یکی از فایل‌هایی که به agent گفته شده بخواند عوض کنید — خطی که با instruction خطاب به هر چیزی که بعداً آن را می‌خواند تمام می‌شود — و agentی که 26٪ score گرفت با همان ابزارها، همان permissionها و همان trace تمیز از آن پیروی می‌کند، و همه اعداد این فصل دقیقاً همان‌جا می‌مانند. suite ارزیابی اندازه می‌گیرد سیستم چند وقت یک‌بار به هدف شما می‌رسد. اندازه نمی‌گیرد که دیگری چقدر آسان می‌تواند هدف خودش را جایگزین کند.

Chapter 30 همین است: prompt injection، سه‌گانه مرگبار داده خصوصی، محتوای untrusted و ارتباط خارجی، و هزینه دادن permission واقعی به agent. با مشاهده‌ای باز می‌شود که این فصل از آن طفره رفته — اینکه همان passing score با agentی سازگار است که دقیقاً همان کاری را می‌کند که attacker در فایلی نوشته که به آن گفته شده بخواند.

همه اعداد بالا روی یک ماشین تولید شد و هیچ‌کدام endpoint پولی را لمس نکرد. agent همان حلقه Chapter 23 با دو ابزار از چهار ابزارش روی دایرکتوری پنج‌فایلی است؛ model پشت port برابر Qwen/Qwen2.5-0.5B-Instruct است، از طریق server کوچکی با همان شکل chat completions endpoint مثل Chapter 23 expose شده، اما در half precision روی یک GPU مصرفی به‌جای CPU آن فصل. هزینه‌ها از نرخ‌های Chapter 16 استفاده می‌کنند — $2.00 به‌ازای هر میلیون input token و $12.00 به‌ازای هر میلیون output — اعمال‌شده روی شمارش tokenهای اندازه‌گیری‌شده. اجراهای تکراری از temperature 0.7 با seedهای ثابت استفاده می‌کنند تا کل مجموعه reproducible باشد؛ جدول چهار‌بازویی greedy است. بازه‌ها ویلسون 95٪ هستند، مقایسه‌های paired آزمون علامت exact دوطرفه روی جفت‌های discordant؛ بازه ویلسون مال Chapter 4 است و آزمون exact paired sign مال Chapter 15، هر دو بدون تغییر reuse شده‌اند. labelهای انسانی مال من‌اند، اعمال‌شده روی شصت پاسخ طبق قاعده نوشته‌شده‌ای که در متن quote شد. هر magnitude اینجا را property یک model نیم‌میلیاردپارامتری بخوانید و هر روش را transferable: model بزرگ‌تر همه اعداد را بالا می‌برد و هیچ‌کدام از ابزارها را جابه‌جا نمی‌کند.