Đánh giá LLM: từ benchmark công khai đến golden set của bạn

Hầu như mọi cuộc tranh luận về đánh giá đều là hai người đang đo hai thứ khác nhau. Có ba dự án và chúng không dùng chung công cụ đo.

Sự nhầm lẫn này đắt đỏ theo một hướng. Leaderboard nói với bạn rằng một model mạnh về suy luận cấp sau đại học; nó không thể nói liệu model đó có định tuyến ticket hỗ trợ của bạn hay không. Và một đánh giá ứng dụng chấm một câu trả lời cho mỗi input hoàn toàn không nhìn thấy agent, vì agent có một phân phối các trajectory còn một câu trả lời chỉ là một mẫu đơn từ phân phối đó. Chương 22 đã đặt tên cho hàng thứ ba đó và để trống: thước đo hiệu năng, phần duy nhất trong đặc tả agent mà các team viết xuống sau cùng hoặc không bao giờ viết.

Thứ tự cũng quan trọng, và vendor bán model cho bạn cũng nói vậy. Hướng dẫn agent của OpenAI rút gọn việc chọn model thành ba bước, theo thứ tự này: “Thiết lập evals để xác lập baseline hiệu năng”, “Tập trung đạt mục tiêu độ chính xác bằng những model tốt nhất hiện có”, “Tối ưu chi phí và độ trễ bằng cách thay model lớn bằng model nhỏ hơn khi có thể”.¹ Đánh giá đi trước, vì bước hai và ba vô nghĩa nếu không có một con số.

Golden set là một danh sách input, mỗi input có câu trả lời được ghi sẵn, và một grader quyết định output có khớp hay không. Nó nhàm chán, nó nhỏ, và nó là artefact duy nhất trong chương này thuộc về bạn. Bộ được xây ở đây có hai mươi tác vụ trên một thư mục năm tệp — không phải ba tệp của Chương 23, nên câu trả lời không phải cùng các câu trả lời — và grader được viết trước khi agent chạy:

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
];

Hai thuộc tính là trụ chịu lực. Danh sách mustNot tồn tại vì một model nêu tên ba tệp trong đó có tệp đúng thì chưa trả lời. Và answer được viết bằng văn xuôi cũng như bằng pattern, vì cả con người lẫn judge đều sẽ cần nó sau này — và viết cùng một sự thật hai lần bằng hai ký pháp là cách bạn phát hiện ra mình chưa thống nhất với chính mình về tác vụ là gì.

Giờ đến bảng quyết định. Bốn hệ thống ứng viên, cùng hai mươi tác vụ, accuracy với khoảng của nó, và hai cột mà một bảng chỉ có accuracy luôn che giấu:

Hãy đọc các khoảng trước khi đọc người thắng. Nhánh B chạy từ 11 % đến 47 %; nhánh A từ 3 % đến 30 %. Chúng chồng lấn trên phần lớn độ dài, chính là kết luận của Chương 4 xuất hiện đúng nơi đã hứa: hai mươi case không thể xếp hạng bốn hệ thống. Chương 15 làm sắc hơn bằng cách hỏi câu hỏi ghép cặp — trong các case mà hai nhánh bất đồng, độ lệch nghiêng về bên nào đến mức nào? — vì độ khó chung của bộ dữ liệu được triệt tiêu. Đây là mọi cặp:

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

Không một so sánh nào trong sáu so sánh được xác lập. Nhánh tốt nhất hơn nhánh không dùng công cụ nào mười lăm điểm, và kết luận đó tựa lên ba case discordant. Hai mươi case cho thấy một cơ chế chứ không thể chọn nhà cung cấp; nói ngược lại trong cuộc họp là cách một model tệ được mua.

Có một điều bảng này thật sự xác lập, và đó là cột chẳng ai đưa vào. Nhánh D tốn mười ba lần nhánh B trên mỗi tác vụ giải được, vì sampling ba trajectory rồi lấy câu trả lời modal làm hóa đơn tăng gấp ba dù accuracy có tăng gấp ba hay không. Các bảng accuracy bỏ qua chi phí khiến trade-off đó trở nên vô hình.

Giờ đến phát hiện sẽ thay đổi cách bạn đọc mọi benchmark từ nay về sau. Lấy cùng hai trăm transcript — hai mươi tác vụ, mười lần chạy, không tái tạo một token nào — và chấm chúng theo ba cách:

Không, mười ba, hai mươi sáu. Hệ thống không đổi. Grader đổi. Exact match trả về không không phải vì agent vô dụng mà vì không câu trả lời free-text nào từng byte-identical với reference: nó đo định dạng và báo cáo điều đó như năng lực.

Đó không phải chuyện lạ, đó là một cơ chế, và nó có tên. Một hard-cutoff metric chấm tác vụ theo kiểu được-ăn-cả-ngã-về-không trên nhiều sub-fact, nên nó nhân dồn. Tác vụ t12 hỏi ba status code cùng lúc. Qua mười lần chạy:

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

Mỗi fact đúng khoảng ba phần tư số lần; yêu cầu cả ba cùng lúc làm điểm giảm một nửa, và $0.77^3 = 0.457$ đủ gần với 0.50 đo được để cho thấy cú giảm đến từ đâu. Khái quát hóa:

Đọc hàng 0.90 so với hàng 0.95 tại $k = 10$: cải thiện năm điểm trên mỗi fact trở thành hai mươi lăm điểm trên conjunction. Không có gì gián đoạn xảy ra với model. Một đường cong mượt khi đọc qua metric được-ăn-cả-ngã-về-không trông như một cú nhảy — chính là lập luận Schaeffer, Miranda và Koyejo đưa ra về emergent abilities, và là điều Chương 10 để dành đến đây.² Kiểm toán của họ phát hiện tối đa 5 trong 39 metric ưu tiên của BIG-Bench thể hiện emergence, với hai metric gián đoạn chiếm hơn 92 % các trường hợp được tuyên bố.

Vậy kỷ luật, trong một câu: một cú nhảy trên biểu đồ là bằng chứng về metric cho đến khi chứng minh được điều ngược lại. Trước khi tin rằng một năng lực vừa xuất hiện, hãy plot cùng các lần chạy bằng một metric cho điểm một phần và xem vách đá có còn không.

Có một phiên bản bậc hai của chuyện này mà Kalai và cộng sự cho rằng đang gây hại từ thượng nguồn: benchmark chấm đúng-sai thưởng cho việc đoán thay vì nói “Tôi không biết”, nên một model được tối ưu theo chúng học cách đoán. Cách sửa họ đề xuất không phải một benchmark hallucination khác mà là “sửa cách chấm điểm của các benchmark hiện có vốn bị lệch nhưng thống trị leaderboard”.³ Golden set của bạn có cùng đòn bẩy đó, và chỉ là một dòng: quyết định abstention được tính là failure hay là hạng mục riêng. Hầu hết mọi người không bao giờ quyết định, nên nó âm thầm bị tính là failure, và hệ thống họ ship sẽ đoán.

Mọi thứ đến đây chấm một attempt cho mỗi tác vụ. Một agent không phải một attempt. Chương 17 đã xác lập rằng bạn không có determinism ngay cả ở temperature zero, nên cùng một input tạo ra một phân phối các trajectory và một benchmark chạy mỗi tác vụ một lần chỉ báo cáo một mẫu từ phân phối đó.

Đóng góp của τ-bench là metric cho việc đó. Paper định nghĩa rất rõ: “chúng tôi đề xuất một metric mới – pass^k (pass hat k), được định nghĩa là xác suất tất cả k thử nghiệm tác vụ i.i.d. đều thành công, trung bình trên các tác vụ.”⁴ Chạy mỗi tác vụ $n$ lần, đếm $c$ lần thành công, và các ước lượng không chệch là:

Cái thứ hai là pass@k quen thuộc từ sinh code: xác suất ít nhất một trong $k$ attempt thành công. Đặt chúng cạnh nhau trên cùng các count đã đo và chúng đi ngược chiều nhau:

Cùng các lần chạy, cùng grader, cùng hai mươi tác vụ. Một cột nói hệ thống cải thiện khi có thêm attempt, cột kia nói nó tệ đi, và cả hai đều đúng, vì chúng trả lời hai câu hỏi khác nhau. pass@k là metric đúng khi có con người lọc output — sinh code, bản nháp, brainstorming — và các attempt bổ sung rẻ. pass^k là metric đúng khi agent hành động không qua bộ lọc, đó chính là nghĩa của “agent”. Công bố cái thứ nhất ở nơi cái thứ hai mới phù hợp là cách phóng đại phổ biến nhất trong lĩnh vực này, và headline của chính τ-bench là phiên bản trung thực: gpt-4o ở khoảng 61 % pass^1 trên retail rơi xuống khoảng 25 % tại pass^8.⁴

Giờ đến cú đau trong số liệu của tôi. pass^10 trên hai mươi tác vụ của tôi là 5.0 %: đúng một tác vụ trong hai mươi được giải ở cả mười lần chạy. Tác vụ đó là t19, “Deploy 42 có thành công không?”, và đây là hai trong mười câu trả lời mà rubric chấm là đúng:

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

Câu đầu không bao giờ trả lời. Câu thứ hai thêm một tuyên bố sai — deploy 41 đã bị rollback. Cả hai khớp /succe|yes/. Tác vụ duy nhất giữ pass^10 trên không là một artefact của grader, nên con số thật là không, và không aggregate nào cho tôi thấy điều đó. Sampling transcript phía sau tác vụ có điểm cao nhất của bạn là nơi grader đi chết.

Và thêm một con số nữa, con số đặt tên cho phần này. Mười đánh giá giống hệt nhau — cùng hệ thống, cùng hai mươi tác vụ, cùng code, không đổi gì ngoài seed:

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

Một khoảng ba mươi điểm trên một hệ thống không thay đổi. Nếu bạn chạy suite một lần trước release và một lần sau release, một “cải thiện” tám điểm nằm trong spread đó và bạn sẽ ship vì tin rằng mình đã gây ra nó. Đây là lý do khoảng pooled ở trên — 26.0 % [20.4, 32.5] — là quá hẹp nếu trích dẫn một mình: nó xem hai trăm trial tương quan như hai trăm trial độc lập. Tóm tắt trung thực của một đánh giá agent là mean và spread qua các lần lặp, và gần như không ai công bố cái thứ hai.

Rubric không scale với câu trả lời mở, nên thao tác chuẩn là để một model chấm output. Nó hoạt động đủ tốt ở frontier scale để trở thành mặc định, và có ba failure mode đã được đặt tên: position bias, verbosity bias và self-enhancement bias.⁵

Đo nó trước khi tin nó. Cùng sáu mươi câu trả lời — ba trong mười lần chạy — được gán nhãn theo ba cách. Nhãn con người là của tôi: tôi đọc cả sáu mươi với năm tệp đang mở và áp dụng một quy tắc đã viết, pass khi và chỉ khi câu trả lời nêu sự thật mà câu hỏi yêu cầu và không chứa gì bị các tệp mâu thuẫn.

Judge nói PASS sáu mươi trên sáu mươi lần. Nó sẽ báo cáo agent này đạt 100 % accuracy trên một bộ mà con người chấm 18 %. Một judge không có năng lực phân biệt không phải là công cụ đo nhiễu; nó là một hàm hằng, và hàm hằng cho hệ thống tốt nhất và tệ nhất của bạn cùng một điểm.

Prompting không cứu được nó. Bốn biến thể, cùng sáu mươi item:

Đảo thứ tự hai nhãn trong instruction làm bốn verdict đổi. Đó là hiệu ứng đo được và là loại hiệu ứng sai: judge đang phản hồi hình dạng của prompt thay vì câu trả lời trước mặt nó.

Minh họa sạch là pairwise. Hai mươi câu hỏi, mỗi câu có một candidate rõ ràng đúng và một candidate rõ ràng sai, được trình bày theo cả hai thứ tự:

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 %

Nó chọn vị trí A bốn mươi trên bốn mươi lần. 50 % về correctness không phải năng lực một phần — đó là số học, vì câu trả lời đúng nằm ở vị trí A đúng một nửa số trial. Consistency ở đây được định nghĩa như MT-Bench định nghĩa, “tỷ lệ phần trăm các case trong đó judge đưa ra kết quả nhất quán khi hoán đổi thứ tự hai assistant”, cho phép so sánh táo với táo: GPT-4 đạt 65.0 % trên thước đo đó, và few-shot prompting nâng lên 77.5 %.⁵ Của tôi đạt không.

Mitigation chuẩn cũng đến từ paper đó: “gọi judge hai lần bằng cách hoán đổi thứ tự hai câu trả lời và chỉ tuyên bố thắng khi một câu trả lời được ưu tiên ở cả hai thứ tự.”⁵ Áp dụng ở đây và judge tạo ra không verdict dùng được nào từ hai mươi cặp — đó là kết quả đúng, và tốt hơn vô hạn so với hai mươi verdict tự tin.

Một ghi chú phương pháp đáng giá hơn kết quả. Tôi cũng chạy một bài test verbosity: cùng một câu trả lời đúng, một bản được đệm thêm một câu 36 từ không thêm gì. Judge ưu tiên bản dài hơn đúng 50 % trial — nhìn giống không có verbosity bias nhưng hoàn toàn không phải, vì một judge luôn chọn vị trí A sẽ đạt 50 % trên bất kỳ pairing cân bằng nào. Bạn không thể đo bias thứ hai cho đến khi bias thứ nhất được kiểm soát. Hoán đổi vị trí không phải tinh chỉnh để thêm sau; nó là thứ khiến mọi phép đo khác có thể diễn giải được.

Caveat trung thực: judge này là model nửa tỷ parameter, và không ai nên dùng một model như vậy để chấm. Vấn đề không phải judge là xấu. Vấn đề là các con số ở trên tốn tám phút để tạo ra, và nếu không có chúng thì verdict của judge này cho một quyết định ship sẽ là 100 %.

Đây là panel Python được tuyên bố thứ ba và cuối cùng của khóa học, và lý do nằm ở nơi các con số công khai đến từ. lm-evaluation-harness bao phủ “hơn 60 benchmark học thuật chuẩn cho LLM, với hàng trăm subtask và biến thể được triển khai” và là “backend cho Open LLM Leaderboard phổ biến của Hugging Face”; HELM, SWE-bench và τ-bench là các package Python với entry point Python.⁶ Chạy model của bạn đối chiếu với một con số đã công bố nghĩa là chạy code của họ, và ngày bạn muốn so sánh với một con số ai đó trích dẫn, đây là hệ sinh thái bạn đang ở trong:

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

Lý do thứ hai là một phép đo trong chương này bất khả thi qua HTTP. Contamination — test set bị rò vào dữ liệu training — là failure khiến một benchmark công khai âm thầm vô nghĩa, và probe sắc nhất cho nó cần loss của chính model, thứ không chat API nào trả về. Đó là cross-entropy per token của Chương 8, trỏ vào một câu hỏi về trí nhớ:

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)

Mười cặp câu: năm câu nằm trong mọi crawl web từ khi web tồn tại, năm câu được viết cho chương này sáng nay, mỗi câu ghép với một bản diễn đạt lại mang cùng nội dung.

Model ngạc nhiên gấp bốn lần trước một câu viết sáng nay so với một câu nó đã thấy một triệu lần, và diễn đạt lại tốn gấp đôi trên các câu nổi tiếng — chi phí thêm đó là phần được ghi nhớ thay vì được hiểu. Loss tuyệt đối trộn lẫn ghi nhớ với độ tự nhiên thông thường, nên gap là thống kê tốt hơn và continuation test còn tốt hơn nữa. Cho nó sáu từ đầu:

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

Ba trong năm chuỗi nổi tiếng được tiếp tục chính xác từng từ từ sáu từ; không chuỗi mới nào trong năm chuỗi mới làm được. Đó là một model nửa tỷ parameter đang đọc thuộc MIT License. Nếu benchmark của bạn nằm trên web công khai, hãy giả định nó nằm trong weights. Đây cũng là lập luận cho toàn bộ chương: một golden set bạn viết từ dữ liệu của chính bạn, giữ ngoài mọi repository mà crawler đọc, là test set duy nhất bạn có thể chắc chắn chưa từng được train trên đó.

Chúng vẫn đáng đọc, miễn là bạn đọc thứ mỗi benchmark đo thay vì con số đơn lẻ gắn với nó.

Hãy lấy cả bảng thay vì bất kỳ hàng nào. Các benchmark agentic đều đặt con người cao hơn model rất xa, trái ngược với benchmark kiến thức và là tóm tắt một dòng tốt nhất về vị trí của lĩnh vực này; số liệu của chúng cũ đi trong vài tháng, nên hãy trích dẫn kèm ngày bạn đọc; và mỗi benchmark đều đo một tác vụ không phải của bạn.

Accuracy là metric bạn tranh luận. Đây là những metric quyết định liệu thứ đó có được ship không. Cả bốn đều rơi ra từ hai trăm lần chạy đã đo.

Chi phí trên mỗi tác vụ giải được, không phải mỗi call. agent tốn $0.001345 mỗi attempt và $0.005172 cho mỗi tác vụ thật sự giải được — cao hơn 3.85 lần, vì ba phần tư attempt không tạo ra gì. Latency cũng như vậy: 1,213 ms mỗi attempt, 4,667 ms mỗi tác vụ giải được. Mỗi retry, mỗi lần hỏi lại, mỗi trajectory bị bỏ rơi nằm trong con số thứ hai và vô hình trong con số thứ nhất.

Một diagnostic tốt hơn accuracy. Trong 123 trên 200 attempt, agent trả lời mà không gọi một công cụ nào — nó đoán thay vì nhìn. Tách theo đó:

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

Các khoảng không đến gần nhau. Điều đó đáng giá hơn aggregate 26 %, vì nó gọi tên thứ cần sửa — model không thất bại trong suy luận, nó thất bại trong việc nhìn — và cách sửa nằm trong harness, không phải model. Một caveat chương này nợ chính tiêu chuẩn của nó: hai nhóm là các tác vụ khác nhau, không phải cùng tác vụ được ghép cặp, nên một phần gap có thể là nó bỏ qua công cụ chính ở những câu nó thấy khó. Phân tách này là diagnostic, không phải tuyên bố nhân quả.

Tỷ lệ can thiệp của con người là metric buyer hỏi đầu tiên: tỷ lệ run dừng ở approval, guardrail hoặc handoff là bao nhiêu. Typed interruptions của Chương 23 khiến nó đếm được, và khi đếm theo loại tác vụ và theo tuần, nó là thứ phân biệt một agent đang học việc với một agent âm thầm biến thành hàng đợi.

Abandonment là thứ không offline suite nào nhìn thấy: user đọc câu trả lời, đóng tab và tự làm tác vụ. Đánh giá offline là cổng; đánh giá production là mẫu liên tục từ traffic thật, chấm bằng cùng grader cộng bốn metric này.

Và một quy tắc kế thừa từ Chương 17: đừng bao giờ assert trên output chính xác. Assert trên thuộc tính — JSON hợp lệ, schema đúng, công cụ đúng được gọi, một số nằm trong tolerance, substring bắt buộc có mặt. Cột exact-match ở đầu chương này là điều xảy ra khi quy tắc đó bị phá.

Đánh giá nhà cung cấp không chỉ là accuracy, và đây là nửa sau của phần đạo đức trong khóa học này, có heading riêng thay vì phụ lục.

Đo bias, đừng giả định nó. Bất kể bạn tin gì về hành vi của model trên tên gọi, phương ngữ, giới tính hay quốc tịch, đó là một thuộc tính đo được của pipeline của bạn, và công cụ là thứ bạn đã có: lấy golden set, chỉ thay đổi thuộc tính, so sánh ghép cặp. HELM tồn tại chính vì accuracy đơn lẻ được báo cáo ở nơi bias, toxicity, calibration và robustness cũng có thể quyết định được.⁸ Model card của vendor là điểm bắt đầu, không phải bằng chứng về input của bạn.

Contamination cũng là câu hỏi dành cho nhà cung cấp. Probe ở trên là lý do để hỏi một con số đã công bố được đo trên gì, và dữ liệu của model được cắt ở thời điểm nào.

Retention, training và residency, đọc ngày 7 tháng 9 năm 2026. Những thứ này thay đổi, nên hãy ghi ngày bên cạnh câu trả lời. Trang policy của Anthropic nêu: “Theo mặc định, chúng tôi sẽ không sử dụng input hoặc output của bạn từ các sản phẩm thương mại của chúng tôi (ví dụ Claude for Work, Anthropic API, Claude Gov, v.v.) để train model của chúng tôi”, ngoại trừ nội dung bạn chủ động gửi làm feedback, được lưu “tối đa 5 năm”.¹⁶ Tài liệu kiểm soát dữ liệu của OpenAI nêu rằng “dữ liệu gửi đến OpenAI API không được dùng để train hoặc cải thiện model OpenAI (trừ khi bạn chủ động opt in chia sẻ dữ liệu với chúng tôi)”, mô tả retention mặc định ba mươi ngày cho log giám sát lạm dụng, và cung cấp Zero Data Retention, thứ “loại trừ nội dung khách hàng khỏi log giám sát lạm dụng”, cộng với data residency có thể cấu hình trên một danh sách vùng.¹⁷

Bốn câu hỏi cần có bằng văn bản trước production call đầu tiên, vì mỗi câu có một owner khác nhau: dữ liệu của tôi có được dùng để training không; nó được giữ bao lâu và bởi ai; nó được xử lý và lưu ở đâu; và điều gì xảy ra với tất cả những điều đó nếu tôi dùng reseller, gateway hoặc aggregator thay vì trực tiếp provider. Câu cuối là nơi hầu hết bất ngờ trú ngụ, và không benchmark nào sẽ nói cho bạn.

Giờ bạn có công cụ đo: một golden set bạn sở hữu, một khoảng trên mọi con số, một kiểm định ghép cặp cho mọi so sánh, pass^k cho các run bạn không cho ai xem, một judge đã được đo, và một probe để biết một điểm công khai có nghĩa gì không. Tuyên bố kết thúc của Chương 23 giờ có thể được kiểm tra thay vì khẳng định — một harness khiến agent có thể được quản trị, không khiến nó đúng — và việc kiểm tra đó tốn hai trăm run cùng tám phút.

Có một thuộc tính của agent mà không thứ nào trong đó đo, và đó là thuộc tính khiến người ta mất việc.

Mọi tác vụ trong golden set của chương này đều do tôi viết, và mọi tệp agent đọc đều do tôi viết. Không có gì trong thư mục đó đang cố làm gì cả. Thay một dòng trong một tệp agent được yêu cầu đọc — một dòng kết thúc bằng instruction gửi tới bất cứ thứ gì đọc nó tiếp theo — và agent đạt 26 % sẽ làm theo nó với cùng công cụ, cùng quyền hạn và cùng trace sạch, còn mọi con số trong chương này vẫn nằm đúng chỗ. Một evaluation suite đo tần suất hệ thống đạt mục tiêu của bạn. Nó không đo mức độ dễ dàng để người khác thay mục tiêu của họ vào.

Chương 30 là chuyện đó: prompt injection, lethal trifecta của dữ liệu riêng tư, nội dung không đáng tin và giao tiếp bên ngoài, cùng chi phí của việc trao quyền thật cho một agent. Chương đó mở bằng nhận xét mà chương này đã né tránh — rằng cùng một điểm pass tương thích với một agent làm đúng những gì attacker viết trong một tệp nó được yêu cầu đọc.

Mọi con số ở trên được tạo trên một máy và không đụng tới paid endpoint nào. agent là vòng lặp của Chương 23 với hai trong bốn công cụ của nó trên một thư mục năm tệp; model phía sau port là Qwen/Qwen2.5-0.5B-Instruct, được expose qua một server nhỏ có cùng hình dạng với chat completions endpoint y như Chương 23, nhưng ở half precision trên một GPU consumer thay vì CPU của chương đó. Chi phí dùng rate của Chương 16 — $2.00 trên một triệu input tokens và $12.00 trên một triệu output — áp vào token count đã đo. Các lần chạy lặp dùng temperature 0.7 với seed cố định để toàn bộ bộ có thể tái lập; bảng bốn nhánh là greedy. Khoảng là Wilson ở 95 %, so sánh ghép cặp là kiểm định dấu exact hai phía trên các cặp discordant; khoảng Wilson là của Chương 4 và kiểm định dấu exact ghép cặp là của Chương 15, cả hai được dùng lại không đổi. Nhãn con người là của tôi, áp vào sáu mươi câu trả lời theo quy tắc đã viết được trích trong text. Hãy đọc mọi độ lớn ở đây như thuộc tính của một model nửa tỷ parameter và mọi phương pháp như thứ có thể chuyển giao: model lớn hơn đẩy mọi con số lên và không đẩy công cụ đo nào đi.