การประเมิน LLM: จาก public benchmarks สู่ golden set ของคุณ

แทบทุกข้อถกเถียงเรื่องการประเมิน คือคนสองคนกำลังวัดคนละสิ่งกัน มีสามโปรเจกต์ และมันไม่ได้ใช้เครื่องมือเดียวกัน

ความสับสนนี้แพงในทิศทางหนึ่ง leaderboard บอกคุณได้ว่าโมเดลเก่งด้านการให้เหตุผลระดับบัณฑิตศึกษา แต่มันบอกไม่ได้ว่าจะ route ticket ซัพพอร์ตของคุณได้หรือไม่ และการประเมินแอปพลิเคชันที่ให้คะแนนหนึ่งคำตอบต่อหนึ่ง input มองไม่เห็น agent เลย เพราะ agent มีการกระจายของ trajectories และหนึ่งคำตอบคือ sample เดียวจากการกระจายนั้น บทที่ 22 ตั้งชื่อแถวที่สามนั้นไว้แล้วและปล่อยให้ว่าง: performance measure ซึ่งเป็นส่วนหนึ่งของ specification ของ agent ที่ทีมมักเขียนทีหลังสุด หรือไม่เขียนเลย

ลำดับก็สำคัญเช่นกัน และผู้ขายโมเดลให้คุณก็พูดแบบนั้น คู่มือ agent ของ OpenAI ลดการเลือกโมเดลเหลือสามขั้นตอนตามลำดับนี้: “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”.¹ การประเมินมาก่อน เพราะขั้นที่สองและสามไม่มีความหมายถ้าไม่มีตัวเลข

golden set คือรายการของ inputs โดยแต่ละรายการมีคำตอบเขียนไว้ และมี grader ที่ตัดสินว่า output ตรงกันหรือไม่ มันน่าเบื่อ มันเล็ก และมันเป็น artefact เดียวในบทนี้ที่เป็นของคุณ ชุดที่สร้างตรงนี้มีงานยี่สิบงานบนไดเรกทอรีที่มีห้าไฟล์ — ไม่ใช่สามไฟล์ของบทที่ 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 มีอยู่เพราะโมเดลที่ตั้งชื่อไฟล์สามไฟล์รวมถึงไฟล์ที่ถูกต้องนั้นยังไม่ได้ตอบคำถาม และ answer ถูกเขียนเป็นร้อยแก้วเช่นเดียวกับ pattern เพราะทั้งมนุษย์และ judge จะต้องใช้มันภายหลัง — และการเขียนข้อเท็จจริงเดียวกันสองครั้งในสอง notation คือวิธีที่ทำให้คุณค้นพบว่าคุณยังไม่เห็นตรงกับตัวเองว่างานคืออะไร

ทีนี้คือตารางที่ตัดสิน ระบบผู้สมัครสี่ระบบ งานยี่สิบงานเดียวกัน accuracy พร้อมช่วง และสองคอลัมน์ที่ตาราง accuracy อย่างเดียวมักซ่อนไว้เสมอ:

อ่านช่วงก่อนอ่านผู้ชนะ arm B มีช่วงตั้งแต่ 11 % ถึง 47 %; arm A ตั้งแต่ 3 % ถึง 30 % มันทับซ้อนกันเกือบตลอดความยาว ซึ่งก็คือข้อค้นพบของบทที่ 4 มาถึงตรงที่สัญญาไว้พอดี: ยี่สิบเคสจัดอันดับสี่ระบบไม่ได้ บทที่ 15 ทำให้คมขึ้นด้วยการถามคำถามแบบ paired แทน — ในเคสที่สอง arm ไม่เห็นตรงกัน การแบ่งเอียงไปข้างใดมากแค่ไหน? — เพราะความยากร่วมของชุดจะหักล้างกัน นี่คือทุกคู่:

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

ไม่มีการเปรียบเทียบใดในหกคู่ที่พิสูจน์ได้แน่ชัด arm ที่ดีที่สุดชนะ arm ที่ไม่มี tools เลยสิบห้าจุด และสิ่งนั้นตั้งอยู่บน discordant cases เพียงสามเคส ยี่สิบเคสแสดงกลไกได้ แต่เลือก supplier ไม่ได้ การพูดเป็นอย่างอื่นในที่ประชุมคือวิธีที่โมเดลแย่ ๆ ถูกซื้อเข้ามา

มีสิ่งหนึ่งที่ตารางนี้พิสูจน์ได้ และมันคือคอลัมน์ที่ไม่มีใครใส่ arm D มีต้นทุนต่อ task ที่แก้สำเร็จสูงกว่า arm B สิบสามเท่า เพราะการ sample สาม trajectories แล้วเอาคำตอบฐานนิยมทำให้บิลเพิ่มสามเท่า ไม่ว่า accuracy จะเพิ่มสามเท่าหรือไม่ ตาราง accuracy ที่ละต้นทุนทำให้ trade-off นี้ล่องหน

ทีนี้คือข้อค้นพบที่จะเปลี่ยนวิธีที่คุณอ่าน benchmark ทุกตัวที่คุณจะเห็นต่อจากนี้ นำ transcript ชุดเดิม สองร้อยรายการ — ยี่สิบงาน สิบรัน ไม่ regenerate token แม้แต่ตัวเดียว — แล้วให้คะแนนสามวิธี:

ศูนย์ สิบสาม ยี่สิบหก ระบบไม่ได้เปลี่ยน grader เปลี่ยน exact match ให้ศูนย์ไม่ใช่เพราะ agent ไร้ประโยชน์ แต่เพราะไม่มีคำตอบ free-text ใดที่ byte-identical กับ reference เสมอไป: มันวัด formatting แล้วรายงานเป็น capability

นี่ไม่ใช่เรื่องน่าสงสัยเล็ก ๆ แต่เป็นกลไก และมันมีชื่อ hard-cutoff metric ให้คะแนนงานแบบได้ทั้งหมดหรือไม่ได้เลยเหนือ sub-facts หลายข้อ ดังนั้นมันจึงทบต้น งาน t12 ขอ status codes สามตัวพร้อมกัน ในสิบรัน:

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

แต่ละ fact ถูกต้องประมาณสามในสี่ของเวลา การบังคับให้ถูกทั้งสามพร้อมกันทำให้คะแนนลดครึ่งหนึ่ง และ $0.77^3 = 0.457$ ก็ใกล้กับ 0.50 ที่วัดได้พอจะชี้ให้เห็นว่าการลดลงมาจากไหน ทำให้ทั่วไปได้ดังนี้:

อ่านแถว 0.90 เทียบกับแถว 0.95 ที่ $k = 10$: การปรับปรุง per-fact ห้าจุดกลายเป็นยี่สิบห้าจุดบน conjunction ไม่มีอะไรแบบไม่ต่อเนื่องเกิดขึ้นกับโมเดล เส้นโค้งเรียบที่ถูกอ่านผ่าน metric แบบได้ทั้งหมดหรือไม่ได้เลยจะดูเหมือนการกระโดด — ซึ่งเป็นข้อโต้แย้งที่ Schaeffer, Miranda และ Koyejo ทำไว้เรื่อง emergent abilities และที่ บทที่ 10 เลื่อนมาไว้ตรงนี้² การตรวจสอบของพวกเขาพบว่าใน 39 metrics ที่ BIG-Bench ชอบ มีมากที่สุด 5 ตัวเท่านั้นที่แสดง emergence โดย metrics แบบไม่ต่อเนื่องสองตัวอธิบายกรณีที่ถูกอ้างมากกว่า 92 %

ดังนั้นวินัยในหนึ่งบรรทัดคือ: การกระโดดในกราฟเป็นหลักฐานเกี่ยวกับ metric จนกว่าจะพิสูจน์เป็นอย่างอื่น ก่อนเชื่อว่า capability ปรากฏขึ้น ให้ plot รันเดียวกันด้วย metric ที่ให้ partial credit แล้วดูว่าหน้าผายังอยู่ไหม

มีเวอร์ชันลำดับที่สองของเรื่องนี้ที่ Kalai และคณะโต้แย้งว่ากำลังสร้างความเสียหายตั้งแต่ต้นน้ำ: benchmarks ที่ให้คะแนนถูกหรือผิดให้รางวัลการเดามากกว่าการพูดว่า “ผมไม่รู้” ดังนั้นโมเดลที่ optimize กับมันจึงเรียนรู้ที่จะเดา วิธีแก้ที่พวกเขาเสนอไม่ใช่ hallucination benchmark อีกตัว แต่คือ “modifying the scoring of existing benchmarks that are misaligned but dominate leaderboards”.³ golden set ของคุณมีคันโยกเดียวกัน และมันเป็นแค่หนึ่งบรรทัด: ตัดสินใจว่า abstention นับเป็นความล้มเหลวหรือเป็นหมวดหมู่ของมันเอง คนส่วนใหญ่ไม่เคยตัดสินใจ ดังนั้นมันจึงถูกนับเป็นความล้มเหลวอย่างเงียบ ๆ และระบบที่พวกเขา ship ก็เดา

ทุกอย่างที่ผ่านมาให้คะแนนหนึ่ง attempt ต่อ task agent ไม่ใช่หนึ่ง attempt บทที่ 17 ยืนยันว่าคุณไม่มี determinism แม้ที่ temperature ศูนย์ ดังนั้น input เดียวกันจึงสร้างการกระจายของ trajectories และ benchmark ที่รันแต่ละ task หนึ่งครั้งรายงาน sample เดียวจากมัน

ผลงานของ τ-bench คือ metric สำหรับเรื่องนั้น paper นิยามไว้ชัดเจน: “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.”⁴ รันแต่ละ task $n$ ครั้ง นับ successes $c$ และ unbiased estimators คือ:

ตัวที่สองคือ pass@k ที่คุ้นเคยจาก code generation: โอกาสที่ อย่างน้อยหนึ่ง ใน $k$ attempts สำเร็จ วางสองตัวนี้ข้างกันบน counts ที่วัดได้ชุดเดียวกัน แล้วมันเคลื่อนไปคนละทิศ:

รันเดียวกัน grader เดียวกัน งานยี่สิบงานเดียวกัน คอลัมน์หนึ่งบอกว่าระบบดีขึ้นเมื่อมี attempts มากขึ้น อีกคอลัมน์บอกว่ามันแย่ลง และทั้งคู่ถูกต้อง เพราะตอบคนละคำถาม pass@k คือ metric ที่ถูกต้องเมื่อมีมนุษย์กรอง output — code generation, drafts, brainstorming — และ attempts เพิ่มเติมราคาถูก pass^k คือ metric ที่ถูกต้องเมื่อ agent ทำงานโดยไม่มีตัวกรอง ซึ่งเป็นความหมายของ “agent” การเผยแพร่ตัวแรกในที่ที่ควรใช้ตัวที่สองคือการพูดเกินจริงที่พบบ่อยที่สุดในวงการนี้ และ headline ของ τ-bench เองคือเวอร์ชันที่ซื่อสัตย์: gpt-4o ที่ประมาณ 61 % pass^1 บน retail ตกลงมาเหลือประมาณ 25 % ที่ pass^8.⁴

ทีนี้คือหนามในตัวเลขของผมเอง pass^10 บนงานยี่สิบงานของผมคือ 5.0 %: มี task เดียวในยี่สิบที่แก้สำเร็จครบทั้งสิบรัน task นั้นคือ t19, “Did deploy 42 succeed?”, และนี่คือสองในสิบคำตอบที่ rubric ให้คะแนนว่าถูก:

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."

คำตอบแรกไม่เคยตอบ คำตอบที่สองเพิ่ม claim ที่เป็นเท็จ — deploy 41 ถูก rollback ทั้งคู่ตรงกับ /succe|yes/ task เดียวที่พยุง pass^10 ให้อยู่เหนือศูนย์คือ artefact ของ grader ดังนั้นตัวเลขจริงคือ ศูนย์ และ aggregate ใด ๆ จะไม่แสดงเรื่องนี้ให้ผมเห็น การสุ่มอ่าน transcripts เบื้องหลัง task ที่ได้คะแนนดีที่สุดของคุณคือที่ที่ graders ไปตาย

และอีกหนึ่งตัวเลข ตัวที่เป็นชื่อของส่วนนี้ การประเมินเหมือนกันสิบครั้ง — ระบบเดิม งานยี่สิบงานเดิม โค้ดเดิม ไม่มีอะไรเปลี่ยนยกเว้น seeds:

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

ช่วงกว้างสามสิบจุดบนระบบที่ไม่ได้เปลี่ยน ถ้าคุณรัน suite ครั้งหนึ่งก่อน release และอีกครั้งหลัง release “การปรับปรุง” แปดจุดอยู่ใน spread นั้น และคุณจะ ship มันโดยเชื่อว่าคุณเป็นคนทำให้เกิดขึ้น นี่คือเหตุผลที่ pooled interval ข้างบน — 26.0 % [20.4, 32.5] — แคบเกินไป ที่จะ quote เดี่ยว ๆ: มันปฏิบัติต่อ trials ที่ correlated กันสองร้อยครั้งเหมือนเป็นอิสระกันสองร้อยครั้ง สรุปที่ซื่อสัตย์ของการประเมิน agent คือ mean และ spread ข้าม repeats และแทบไม่มีใครเผยแพร่ตัวที่สอง

Rubrics ไม่ scale กับคำตอบ open-ended ดังนั้นท่ามาตรฐานคือให้โมเดล grade output มันดีพอในระดับ frontier จนเป็น default และมี failure modes ที่มีชื่อสามอย่าง: position bias, verbosity bias และ self-enhancement bias.⁵

วัดมันก่อนเชื่อมัน คำตอบหกสิบชุดเดียวกัน — สามในสิบรัน — ถูก label สามวิธี human label เป็นของผม: ผมอ่านทั้งหมดหกสิบคำตอบโดยเปิดไฟล์ทั้งห้าไว้ และใช้กฎที่เขียนไว้หนึ่งข้อ ผ่านก็ต่อเมื่อคำตอบระบุ fact ที่คำถามถามหา และไม่มีอะไรที่ขัดแย้งกับไฟล์

judge พูดว่า PASS หกสิบครั้งจากหกสิบครั้ง มันคงรายงาน agent นี้ที่ accuracy 100 % บนชุดที่มนุษย์ให้คะแนน 18 % judge ที่ไม่มี discriminative power ไม่ใช่เครื่องมือที่มี noise; มันคือ constant function และ constant function ให้คะแนนระบบที่ดีที่สุดกับแย่ที่สุดของคุณเท่ากัน

การ prompt ไม่ได้ช่วยมัน สี่ variant รายการหกสิบรายการเดิม:

การสลับลำดับ labels สองตัวใน instruction ขยับ verdicts สี่รายการ นั่นคือ effect ที่วัดได้ และเป็น effect แบบผิดชนิด: judge ตอบสนองต่อรูปร่างของ prompt มากกว่าคำตอบตรงหน้า

การสาธิตที่สะอาดคือ pairwise คำถามยี่สิบข้อ แต่ละข้อมี 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 ไม่ใช่ความสามารถบางส่วน — มันคือเลขคณิต เพราะคำตอบที่ถูกอยู่ใน position A พอดีครึ่งหนึ่งของ trials consistency ที่นี่นิยามตาม MT-Bench ว่า “the percentage of cases where a judge gives consistent results when swapping the order of two assistants” ซึ่งทำให้การเปรียบเทียบเทียบกันได้: GPT-4 ได้ 65.0 % บนมาตรวัดนั้น และ few-shot prompting ยกขึ้นเป็น 77.5 %.⁵ ของผมได้ศูนย์

mitigation มาตรฐานก็มาจาก paper นั้นเช่นกัน: “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 ให้ zero usable verdicts from twenty pairs — ซึ่งเป็นผลลัพธ์ที่ถูกต้อง และดีกว่าความมั่นใจยี่สิบครั้งอย่างไม่มีที่สิ้นสุด

หมายเหตุด้านวิธีวิทยาที่มีค่ากว่าผลลัพธ์ ผมยังรัน verbosity test ด้วย: คำตอบที่ถูกต้องเดียวกัน หนึ่งสำเนาถูกเติมด้วยประโยค 36 คำที่ไม่ได้เพิ่มอะไร judge ชอบเวอร์ชันที่ยาวกว่าใน 50 % ของ trials พอดี — ซึ่งดูเหมือนไม่มี verbosity bias และไม่ใช่แบบนั้นเลย เพราะ judge ที่เลือก position A เสมอจะได้ 50 % บน balanced pairing ใด ๆ ก็ตาม คุณวัด bias ตัวที่สองไม่ได้จนกว่าจะควบคุมตัวแรก การสลับตำแหน่งไม่ใช่ refinement ที่ค่อยเพิ่มทีหลัง; มันคือสิ่งที่ทำให้ measurement อื่น ๆ ตีความได้

ข้อสงวนที่ซื่อสัตย์: judge นี้เป็นโมเดลครึ่งพันล้าน parameters และไม่มีใครควรใช้โมเดลแบบนั้น grade ประเด็นไม่ใช่ว่า judges แย่ แต่คือว่าตัวเลขข้างบนใช้เวลาแปดนาทีในการสร้าง และถ้าไม่มีมัน verdict ของ judge นี้ต่อการตัดสินใจ ship คงเป็น 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 เป็น Python packages ที่มี Python entry points.⁶ การรันโมเดลของคุณเทียบกับตัวเลขที่เผยแพร่ หมายถึงการรันโค้ดของพวกเขา และวันที่คุณอยากเปรียบเทียบกับตัวเลขที่ใครบางคนอ้างถึง นี่คือ ecosystem ที่คุณอยู่:

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

เหตุผลที่สองคือ measurement หนึ่งในบทนี้ทำผ่าน HTTP ไม่ได้ Contamination — test set รั่วเข้า training data — คือ failure ที่ทำให้ public benchmark ไร้ความหมายอย่างเงียบ ๆ และ probe ที่คมที่สุดสำหรับมันต้องใช้ loss ของโมเดลเอง ซึ่งไม่มี chat API ใดส่งคืน มันคือ cross-entropy ต่อ token ของ บทที่ 8 ที่ชี้ไปยังคำถามเรื่อง memory:

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 ของเว็บตั้งแต่มันมีอยู่ อีกห้าคู่เขียนขึ้นสำหรับบทนี้เมื่อเช้านี้ แต่ละคู่จับกับเวอร์ชันที่เรียบเรียงใหม่แต่มีเนื้อหาเดียวกัน

โมเดลประหลาดใจกับประโยคที่เขียนเมื่อเช้านี้มากกว่าประโยคที่มันเห็นมาหนึ่งล้านครั้งถึงสี่เท่า และการ rewording มีต้นทุนมากกว่าสองเท่าบนประโยค famous — ต้นทุนส่วนเกินคือส่วนที่ถูกจดจำมากกว่าเข้าใจ absolute loss ปน memorisation กับ naturalness ธรรมดาเข้าด้วยกัน ดังนั้น gap จึงเป็นสถิติที่ดีกว่า และ continuation test ยังดีกว่า ให้หกคำแรกแก่มัน:

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."

สามในห้าของ famous strings ต่อได้ตรงทุกคำจากหกคำแรก; fresh ones ทั้งห้าไม่มีตัวใดทำได้ นั่นคือโมเดลครึ่งพันล้าน parameters กำลังท่อง MIT License ถ้า benchmark ของคุณอยู่บน public web ให้ถือว่ามันอยู่ใน weights นี่คือข้อโต้แย้งของทั้งบทเช่นกัน: golden set ที่คุณเขียนจากข้อมูลของคุณเอง และเก็บให้พ้น repository ใด ๆ ที่ crawler อ่าน คือ test set เดียวที่คุณมั่นใจได้ว่าไม่เคยถูก train มาก่อน

มันยังคุ้มที่จะอ่าน ตราบใดที่คุณอ่านว่าแต่ละตัววัดอะไร แทนที่จะอ่านตัวเลขเดียวที่ติดอยู่กับมัน

อ่านทั้งตารางแทนที่จะอ่านแถวใดแถวหนึ่ง agentic benchmarks ทั้งหมดวางมนุษย์ไว้สูงกว่าโมเดลมาก ซึ่งตรงข้ามกับ knowledge benchmarks และเป็นสรุปหนึ่งบรรทัดที่ดีที่สุดว่าสาขานี้อยู่ตรงไหน ตัวเลขของมันแก่ภายในไม่กี่เดือน ดังนั้น cite พร้อมวันที่คุณอ่าน และทุกตัววัดงานที่ไม่ใช่งานของคุณ

Accuracy คือ metric ที่คุณถกเถียงกัน ต่อไปนี้คือ metric ที่ตัดสินว่าสิ่งนั้นจะ ship หรือไม่ ทั้งสี่ตัวได้มาจากรันสองร้อยครั้งที่วัดไว้แล้ว

ต้นทุนต่อ task ที่แก้สำเร็จ ไม่ใช่ต่อ call agent มีต้นทุน $0.001345 ต่อ attempt และ $0.005172 ต่อ task ที่แก้สำเร็จจริง — แพงกว่า 3.85 เท่า เพราะ attempts สามในสี่ไม่ก่อผลอะไร Latency ก็เป็นแบบเดียวกัน: 1,213 ms ต่อ attempt, 4,667 ms ต่อ solved task ทุก retry ทุก re-ask ทุก trajectory ที่ถูกทิ้ง อยู่ในตัวเลขที่สองและล่องหนในตัวเลขแรก

diagnostic ที่ชนะ accuracy ใน 123 จาก 200 attempts agent ตอบ โดยไม่เรียก tool แม้แต่ตัวเดียว — มันเดาแทนที่จะดู แยกตามนั้น:

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 % เพราะมันตั้งชื่อสิ่งที่ต้องแก้ — โมเดลไม่ได้ล้มเหลวในการ reasoning แต่มันล้มเหลวในการดู — และ fix อยู่ใน harness ไม่ใช่โมเดล ข้อสงวนหนึ่งที่บทนี้ติดค้างมาตรฐานของตัวเอง: สองกลุ่มเป็น tasks คนละชุด ไม่ใช่ tasks เดียวกันแบบ paired ดังนั้นส่วนหนึ่งของ gap อาจเป็นเพราะมันข้าม tools ในคำถามที่มันเห็นว่ายากพอดี การ split นี้เป็น diagnostic ไม่ใช่ causal claim

Human intervention rate คือ metric ที่ buyer ถามก่อน: สัดส่วนของ runs ที่หยุดที่ approval, guardrail หรือ handoff typed interruptions ของบทที่ 23 ทำให้มันนับได้ และเมื่อถูกนับต่อ task type และต่อสัปดาห์ มันคือสิ่งที่แยก agent ที่กำลังเรียนรู้งานของมันออกจาก agent ที่ค่อย ๆ กลายเป็น queue เงียบ ๆ

Abandonment คือสิ่งที่ offline suite มองไม่เห็น: ผู้ใช้ที่อ่านคำตอบ ปิด tab แล้วไปทำงานเอง Offline evaluation เป็น gate; production evaluation คือ sample ต่อเนื่องของ traffic จริง ให้คะแนนด้วย grader เดียวกันบวกสี่ตัวนี้

และกฎที่สืบมาจากบทที่ 17: อย่า assert บน exact output assert บน properties — valid JSON, schema ถูกต้อง, tool ที่ถูกต้องถูกเรียก, ตัวเลขอยู่ใน tolerance, substring ที่ต้องการปรากฏ คอลัมน์ exact-match ตอนต้นบทนี้คือสิ่งที่เกิดขึ้นเมื่อกฎนั้นถูกทำลาย

การประเมิน supplier ไม่ได้เกี่ยวกับ accuracy เท่านั้น และนี่คือครึ่งหลังของจริยธรรมในคอร์สนี้ พร้อม heading ของตัวเองแทนที่จะเป็น appendix

วัด bias อย่าสันนิษฐาน ไม่ว่าคุณเชื่ออะไรเกี่ยวกับพฤติกรรมของโมเดลต่อชื่อ dialects เพศ หรือสัญชาติ มันคือ property ที่วัดได้ของ pipeline ของคุณ และเครื่องมือก็คือสิ่งที่คุณมีอยู่แล้ว: นำ golden set ของคุณ เปลี่ยนเฉพาะ attribute แล้วเปรียบเทียบแบบ paired HELM มีอยู่ก็เพราะ accuracy อย่างเดียวถูกนำไปรายงานในที่ที่ bias, toxicity, calibration และ robustness ก็ decidable เช่นกัน⁸ model card ของ vendor เป็นจุดเริ่มต้น ไม่ใช่หลักฐานเกี่ยวกับ inputs ของคุณ

Contamination ก็เป็นคำถามสำหรับ supplier เช่นกัน probe ข้างบนคือเหตุผลที่ต้องถามว่าตัวเลขที่เผยแพร่วัดบนอะไร และข้อมูลของโมเดลถูกตัด ณ เมื่อใด

Retention, training และ residency อ่าน ณ 7 กันยายน 2026 สิ่งเหล่านี้เปลี่ยนได้ ดังนั้นบันทึกวันที่ไว้ข้างคำตอบ หน้านโยบายของ 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” โดยมีข้อยกเว้นคือเนื้อหาที่คุณ submit เป็น 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” รวมถึง configurable data residency ในรายชื่อ regions.¹⁷

คำถามสี่ข้อที่ต้องได้เป็นลายลักษณ์อักษรก่อน production call แรก เพราะแต่ละข้อมี owner คนละคน: ข้อมูลของผมถูกใช้สำหรับ training หรือไม่; ถูก retain นานแค่ไหนและโดยใคร; ถูก process และ store ที่ไหน; และทั้งหมดนั้นจะเกิดอะไรขึ้นถ้าผมใช้ reseller, gateway หรือ aggregator แทนที่จะใช้ provider โดยตรง ข้อสุดท้ายนี่แหละที่ surprise ส่วนใหญ่อยู่ และไม่มี benchmark ใดบอกคุณได้

ตอนนี้คุณมีเครื่องมือแล้ว: golden set ที่คุณเป็นเจ้าของ ช่วงบนทุกตัวเลข paired test สำหรับทุก comparison, pass^k สำหรับ runs ที่คุณไม่ให้ใครดู judge ที่วัดแล้ว และ probe สำหรับดูว่า public score มีความหมายหรือไม่ claim ปิดท้ายของบทที่ 23 ตอนนี้ตรวจสอบได้แทนที่จะ assert — harness ทำให้ agent อยู่ภายใต้การกำกับได้ ไม่ได้ทำให้ถูกต้อง — และการตรวจสอบนั้นใช้สองร้อยรันกับแปดนาที

มี property หนึ่งของ agent ที่ทั้งหมดนี้วัดไม่ได้ และมันคือสิ่งที่ทำให้คนถูกไล่ออก

ทุก task ใน golden set ของบทนี้ถูกเขียนโดยผม และทุกไฟล์ที่ agent อ่านก็ถูกเขียนโดยผม ไม่มีอะไรในไดเรกทอรีนั้นพยายามทำอะไร เปลี่ยนหนึ่งบรรทัดในไฟล์หนึ่งที่ agent ถูกสั่งให้อ่าน — บรรทัดที่ลงท้ายด้วย instruction ที่ส่งถึงอะไรก็ตามที่จะอ่านมันถัดไป — แล้ว agent ที่ได้คะแนน 26 % จะทำตามมันด้วย tools เดิม permissions เดิม และ trace ที่สะอาดเหมือนเดิม และตัวเลขทุกตัวในบทนี้จะอยู่ที่เดิมเป๊ะ evaluation suite วัดว่าระบบไปถึงเป้าหมายของคุณบ่อยแค่ไหน มันไม่ได้วัดว่าคนอื่นสามารถแทนที่เป้าหมายของเขาได้ง่ายแค่ไหน

บทที่ 30 คือเรื่องนั้น: prompt injection, lethal trifecta ของ private data, untrusted content และ external communication และต้นทุนของการให้ permissions จริงแก่ agent มันเปิดด้วยข้อสังเกตที่บทนี้หลบมาตลอด — ว่า passing score เดียวกันเข้ากันได้กับ agent ที่ทำสิ่งที่ attacker เขียนไว้ในไฟล์ที่มันถูกสั่งให้อ่านทุกประการ

ตัวเลขทั้งหมดข้างบนถูกสร้างบนเครื่องเดียว และไม่มีส่วนใดแตะ paid endpoint agent คือ loop ของบทที่ 23 โดยใช้สองในสี่ tools บนไดเรกทอรีห้าไฟล์ โมเดลหลัง port คือ Qwen/Qwen2.5-0.5B-Instruct เปิดผ่าน server ขนาดเล็กที่มีรูปร่างเหมือน chat completions endpoint ตามบทที่ 23 ทุกประการ แต่ใช้ half precision บน consumer GPU หนึ่งตัว แทน CPU ของบทนั้น ต้นทุนใช้ rates ของ บทที่ 16 — $2.00 ต่อหนึ่งล้าน input tokens และ $12.00 ต่อหนึ่งล้าน output — นำไปใช้กับ token counts ที่วัดได้ repeated runs ใช้ temperature 0.7 พร้อม fixed seeds เพื่อให้ทั้งชุด reproduce ได้; ตาราง four-arm เป็น greedy intervals เป็น Wilson ที่ 95 %, paired comparisons เป็น two-sided exact sign tests บน discordant pairs; Wilson interval เป็นของบทที่ 4 และ exact paired sign test เป็นของบทที่ 15 ทั้งคู่ reuse โดยไม่เปลี่ยน human labels เป็นของผม ใช้กับคำตอบหกสิบชุดตามกฎที่เขียนไว้และ quote ในข้อความ อ่าน magnitude ทุกตัวตรงนี้เป็น property ของโมเดลครึ่งพันล้าน parameters และอ่าน method ทุกอย่างว่า transferable: โมเดลที่ใหญ่ขึ้นจะยกตัวเลขทั้งหมดขึ้น แต่ไม่ย้ายเครื่องมือใด ๆ