Không có mô hình tốt nhất, chỉ có mô hình tốt nhất cho bạnMáy nào giỏi nhất? Hỏi vậy là sai rồiThere is no best model, only the best model for you
Chương 3 hỏi “đo bằng cách nào”; chương 4 hỏi “đo cái gì, cho ứng dụng nào của ai”. Huyen mở chương bằng một câu hỏi bà từng nêu tại các hội nghị: cái nào tệ hơn — một ứng dụng chưa bao giờ được triển khai, hay một ứng dụng đã triển khai nhưng không ai biết nó có chạy đúng không? Phần lớn khán giả chọn vế sau: thứ đã triển khai mà không đo được thì vừa tốn tiền duy trì, vừa tốn tiền hơn nữa nếu muốn gỡ xuống.1
Chương trước dạy cách chấm điểm. Chương này hỏi: chấm cái gì, và để chọn máy nào cho việc của mình. Tác giả kể có lần hỏi cả hội trường: cái nào tệ hơn — một ứng dụng chưa bao giờ đem ra dùng, hay một ứng dụng đang chạy mà không ai biết nó đúng hay sai? Hầu hết mọi người chọn cái thứ hai. Nhớ nhé: chạy mà không biết đúng sai thì còn đáng sợ hơn là chưa chạy.
Chapter 3 asked “how do you measure?”; chapter 4 asks “measure what, and for whose application?” Huyen opens with a question she has put to conference audiences: which is worse — an application that has never been deployed, or one that is deployed but nobody knows whether it works? Most people pick the latter: it costs money to maintain, and it may cost even more to take down.1
Huyen viết rằng bà tin đánh giá là nút thắt cổ chai lớn nhất của việc áp dụng AI, và đề xuất một lối làm việc bà gọi là evaluation-driven development — định nghĩa tiêu chí đánh giá trước khi bắt tay xây, phỏng theo test-driven development trong kỹ thuật phần mềm. Từ đó, chọn mô hình không còn là tìm mô hình mạnh nhất thế giới, mà là dựng một bảng xếp hạng riêng cho bài toán của mình.1
Tác giả nói: chuyện khó nhất của AI hiện nay không phải làm ra máy giỏi, mà là biết máy có giỏi không. Nên hãy nghĩ trước xem mình sẽ chấm điểm bằng gì, rồi mới bắt tay làm. Nhớ nhé: viết đề thi trước, làm bài sau.
Huyen writes that she believes evaluation is the biggest bottleneck to AI adoption, and proposes a working style she calls evaluation-driven development — defining your evaluation criteria before you build, by analogy with test-driven development in software engineering. Model selection then stops being a hunt for the world's strongest model and becomes the act of building a private leaderboard for your own problem.1
HỆ THỐNGEVALUATE
AI SYSTEMS
Định nghĩa “tốt” trước khi xâyBiết chấm bằng gì đãDefine “good” before you build
Huyen quan sát rằng những ứng dụng doanh nghiệp phổ biến nhất trong sản xuất đều là những ứng dụng có tiêu chí đánh giá rõ ràng: hệ gợi ý đo bằng mức tăng tương tác hay tỷ lệ mua hàng, hệ phát hiện gian lận đo bằng số tiền chặn được, sinh mã đo bằng tính đúng chức năng. Nhưng bà cũng tự phản biện: chỉ theo đuổi những ứng dụng đo được thì chẳng khác nào tìm chìa khóa dưới cột đèn — dễ tìm hơn, nhưng không có nghĩa là chìa khóa nằm ở đó.1
Những ứng dụng AI sống sót lâu nhất thường là loại dễ chấm điểm: gợi ý hàng thì đếm số người mua, bắt gian lận thì đếm tiền cứu được, viết mã thì cho chạy thử. Nhưng tác giả nhắc: nếu chỉ làm cái dễ chấm, ta giống người đánh rơi chìa khóa ngoài bụi tối mà cứ tìm dưới cột đèn cho sáng. Nhớ nhé: dễ đo không có nghĩa là đúng chỗ.
Huyen observes that the enterprise applications most commonly in production are the ones with clear evaluation criteria: recommender systems measured by engagement or purchase-through rates, fraud detection measured by money saved, code generation measured by functional correctness. But she argues against herself too: focusing only on what can be measured is like looking for the lost key under the lamppost — easier, but it does not mean the key is there.1
Một tiêu chí đánh giá là câu trả lời cụ thể, đo được, cho câu hỏi “ứng dụng này phải làm được gì thì mới gọi là dùng được?”.
Tiêu chí là câu trả lời cho câu hỏi: “làm được tới đâu thì mới gọi là xài được?”
An evaluation criterion is a concrete, measurable answer to the question “what must this application do before we can call it usable?”
Huyen sắp xếp các tiêu chí thành bốn nhóm và minh họa bằng một tình huống duy nhất: bạn yêu cầu mô hình tóm tắt một hợp đồng pháp lý. Năng lực chuyên ngành cho biết mô hình hiểu hợp đồng tới đâu; năng lực sinh cho biết bản tóm tắt có mạch lạc và trung thực không; năng lực tuân lệnh cho biết bản tóm tắt có đúng định dạng và giới hạn độ dài bạn yêu cầu không; chi phí và độ trễ cho biết bản tóm tắt ấy tốn bao nhiêu tiền và bao lâu.1
-
01Evaluation-driven development
Phát triển dẫn dắt bởi đánh giá — viết đề thi trước khi viết bàiRa đề trước, làm bài sauEvaluation-driven development — write the test before the code
Trước khi đổ thời gian, tiền bạc và nhân lực vào một ứng dụng, Huyen khuyên hãy hiểu trước xem ứng dụng ấy sẽ được đánh giá ra sao. Bà đặt tên cho lối làm này theo test-driven development: trong kỹ thuật AI, nó có nghĩa là định nghĩa tiêu chí đánh giá trước khi xây. Bà kể về một kỹ sư học máy ở một hãng xe cũ — mô hình định giá xe chạy được một năm, người dùng có vẻ thích, nhưng anh không hề biết dự đoán của nó có chính xác hay không.1
Trước khi bỏ công làm, hãy nghĩ xem mình sẽ biết nó đúng bằng cách nào. Tác giả kể chuyện một kỹ sư làm máy đoán giá xe cũ; một năm sau khi đưa vào dùng, khách có vẻ thích, nhưng anh vẫn không biết máy đoán đúng hay sai. Nhớ nhé: nếu chưa biết cách chấm thì đừng vội xây.
Before pouring time, money and people into an application, Huyen advises understanding first how it will be evaluated. She names the approach after test-driven development: in AI engineering it means defining evaluation criteria before building. She tells of an ML engineer at a used-car dealership whose price-prediction model had been live for a year — users seemed to like it, but he had no idea whether its predictions were accurate.1
Nhìn thấy ở đâuWhere you see it Ở mọi cuộc họp khởi động dự án AI mà câu hỏi “làm sao biết nó chạy đúng?” bị đẩy xuống cuối danh sách việc cần làm. Ở mọi dự án mà câu “làm sao biết nó đúng?” bị để dành tới cuối cùng. In every AI kickoff meeting where “how will we know it works?” gets pushed to the bottom of the backlog.Phản biện của chính tác giả
Huyen thừa nhận rằng nếu chỉ chọn những ứng dụng đo được thì ta có thể bỏ lỡ nhiều ứng dụng có sức thay đổi cuộc chơi, đơn giản vì chưa ai nghĩ ra cách đo chúng. Bà tin rằng dựng được quy trình đánh giá đáng tin sẽ mở khóa cho cả một lớp ứng dụng mới.1
Vì sao bài toán đóng dễ sống hơn
Dù mô hình nền tảng vốn mở, rất nhiều ca sử dụng của nó lại là bài toán đóng — phân loại ý định, phân tích cảm xúc, dự đoán hành động kế tiếp. Bài toán phân loại dễ đánh giá hơn hẳn bài toán mở, nên cũng dễ được duyệt triển khai hơn.1
-
02Domain-specific capability
Năng lực chuyên ngành — và cái bẫy của trắc nghiệmMáy có biết nghề không — và bẫy của câu hỏi bốn đáp ánDomain-specific capability — and the multiple-choice trap
Năng lực chuyên ngành bị chặn cứng bởi cấu hình và dữ liệu huấn luyện: mô hình chưa từng thấy tiếng Latinh thì sẽ không hiểu tiếng Latinh. Phần lớn benchmark công khai đo nó bằng trắc nghiệm — vào tháng 4 năm 2024, 75% số tác vụ trong lm-evaluation-harness của Eleuther là câu hỏi nhiều lựa chọn, trong đó có MMLU, AGIEval và ARC-C.145 Trắc nghiệm phổ biến vì dễ tạo, dễ chấm và có mốc ngẫu nhiên rõ ràng: bốn đáp án, một đúng, thì mốc đoán mò là 25%.
Máy chỉ biết thứ nó từng được đọc: chưa học tiếng Latinh thì không hiểu tiếng Latinh. Người ta hay chấm bằng câu hỏi bốn đáp án vì dễ chấm — tháng 4 năm 2024, ba phần tư bài thi trong bộ đề phổ biến nhất là kiểu này. Nhưng chọn được đáp án đúng khác với tự viết ra câu trả lời hay. Nhớ nhé: khoanh đúng không có nghĩa là viết hay.
Domain capability is hard-capped by configuration and training data: a model that never saw Latin will not understand Latin. Most public benchmarks measure it with multiple choice — in April 2024, 75% of the tasks in Eleuther's lm-evaluation-harness were multiple-choice questions, including MMLU, AGIEval and ARC-C.145 They are popular because they are easy to create, verify and compare against a random baseline: four options with one correct answer gives a 25% guessing floor.
Nhìn thấy ở đâuWhere you see it Ở mọi bảng điểm mô hình khoe con số MMLU — một bài thi trắc nghiệm 57 môn, đo kiến thức và suy luận, chứ không đo khả năng viết. Ở mọi quảng cáo khoe điểm MMLU — đó là bài trắc nghiệm 57 môn, không phải bài kiểm tra viết văn. In every model card boasting an MMLU number — a 57-subject multiple-choice exam of knowledge and reasoning, not of writing.Dễ vỡ trước những thay đổi vụn vặt
Alzahrani và cộng sự (2024) phát hiện chỉ cần thêm một dấu cách giữa câu hỏi và đáp án, hoặc chèn thêm một cụm chỉ dẫn như “Choices:”, là mô hình có thể đổi câu trả lời — và thứ hạng trên bảng xếp hạng cũng đổi theo.6
Chạy đúng chưa chắc đã dùng được
Với sinh mã, tính đúng chức năng là thước đo chuẩn, nhưng Huyen nhắc rằng hiệu quả cũng đáng đo: BIRD-SQL (Li và cộng sự, 2023) so cả thời gian chạy của truy vấn sinh ra với truy vấn chuẩn, chứ không chỉ so kết quả.7 Còn tính dễ đọc của mã thì không có cách đo chính xác nào — đành nhờ tới giám khảo AI.1
-
03Factual consistency & safety
Nhất quán sự kiện — cục bộ hay toàn cụcMáy có bịa khôngFactual consistency — local or global
Huyen tách tính nhất quán sự kiện làm hai: cục bộ — đầu ra được đối chiếu với một ngữ cảnh cho sẵn, và toàn cục — đầu ra được đối chiếu với tri thức mở. Nếu ngữ cảnh nói trời màu tím, thì câu “trời màu tím” là nhất quán cục bộ, dù nó sai về mặt tri thức chung. Nhất quán cục bộ là thước đo của tóm tắt, chatbot hỗ trợ khách hàng và RAG; nhất quán toàn cục là thước đo của chatbot tổng quát và kiểm chứng tin tức.1
Có hai kiểu “nói đúng”. Kiểu một: đúng với tài liệu vừa đưa cho máy đọc. Nếu tài liệu bảo bầu trời màu tím, máy nói màu tím là đúng theo kiểu này. Kiểu hai: đúng với kiến thức chung của thế giới. Nhớ nhé: trước khi bắt máy nói đúng, phải nói rõ “đúng theo cái gì”.
Huyen splits factual consistency in two: local — the output is checked against a given context, and global — the output is checked against open knowledge. If the context says the sky is purple, then “the sky is purple” is locally consistent even though it is globally false. Local consistency is the metric for summarisation, support chatbots and RAG; global consistency is the metric for general chatbots and fact-checking.1
Bên cạnh tính nhất quán sự kiện, Huyen xếp mọi dạng độc hại và thiên kiến vào một ô chung gọi là an toàn: ngôn từ không phù hợp, hướng dẫn gây hại, phát ngôn thù ghét, bạo lực, khuôn mẫu giới, và thiên kiến chính trị hay tôn giáo. Bà nhận xét rằng nhiều mô hình phát hiện độc hại trong văn bản do người viết vẫn dùng được cho văn bản do máy viết, và chúng thường nhỏ, nhanh, rẻ hơn hẳn giám khảo AI đa dụng. Benchmark thường dùng gồm RealToxicityPrompts — một trăm nghìn prompt xuất hiện tự nhiên, có xu hướng dụ mô hình sinh ra đầu ra độc hại — và BOLD.111
Nhìn thấy ở đâuWhere you see it Ở mọi hệ RAG: câu trả lời phải nhất quán với đoạn văn bản vừa truy xuất, chứ không phải với những gì mô hình “nhớ” từ lúc huấn luyện. Ở mọi trợ lý biết tra tài liệu: nó phải trả lời theo tài liệu vừa đọc, không phải theo trí nhớ cũ. In every RAG system: the answer must be consistent with the retrieved passage, not with what the model “remembers” from training.Ba lối kiểm tra
Giám khảo AI là cách trực tiếp nhất. Tinh vi hơn có tự kiểm chứng — SelfCheckGPT (Manakul và cộng sự, 2023) sinh thêm N câu trả lời và đo mức mâu thuẫn, với giả định rằng câu trả lời bịa thì các lần sinh sẽ đá nhau; cách này hiệu quả nhưng đắt vì tốn nhiều lượt gọi.9 Và kiểm chứng có tăng cường tri thức — SAFE của Google DeepMind (Wei và cộng sự, 2024) tách câu trả lời thành từng mệnh đề, viết lại cho mỗi mệnh đề tự đứng được, đặt câu truy vấn gửi tới Google Search, rồi dùng AI phán xem mệnh đề có khớp kết quả không.10
Suy dẫn văn bản và TruthfulQA
Việc đối chiếu một mệnh đề với ngữ cảnh cũng có thể đóng khung thành bài toán suy dẫn văn bản cũ của xử lý ngôn ngữ: kéo theo, mâu thuẫn, hay trung tính. Benchmark tiêu biểu là TruthfulQA — 817 câu hỏi thuộc 38 chủ đề mà nhiều người sẽ trả lời sai vì niềm tin sai lệch; nó đi kèm một giám khảo chuyên dụng, GPT-judge, mà nhóm tác giả báo cáo đạt độ chính xác 90–96% khi dự đoán con người có coi một câu trả lời là trung thực hay không. Mốc chuyên gia người, theo chính bài báo, là 94%.8
-
04Instruction-following, cost & latency
Nghe lời, và cái giá của mỗi câu trả lờiNghe lời, rẻ và nhanhFollowing instructions, and the price of each answer
Nếu mô hình kém tuân lệnh thì prompt hay đến mấy cũng vô ích. Huyen phân biệt rõ: mô hình hiểu được cảm xúc của một dòng tweet nhưng lại trả về HAPPY và ANGRY thay vì NEGATIVE / POSITIVE / NEUTRAL — đó là năng lực chuyên ngành đủ nhưng năng lực tuân lệnh kém. IFEval của Google chọn 25 loại chỉ dẫn có thể kiểm tra tự động bằng chương trình — chứa từ khóa, giới hạn độ dài, số gạch đầu dòng, định dạng JSON — và chấm bằng tỷ lệ chỉ dẫn được tuân thủ.112
Nếu máy không nghe lời thì dặn hay cỡ nào cũng vô ích. Có máy hiểu đúng câu chuyện nhưng lại trả lời sai kiểu mình dặn — như bảo chọn một trong ba chữ mà nó lại bịa ra chữ thứ tư. Người ta nghĩ ra những bài thi chỉ gồm các mệnh lệnh mà máy tính tự kiểm tra được, ví dụ “trả lời đúng ba đoạn” hay “phải có chữ này”. Nhớ nhé: giỏi mà không nghe lời thì vẫn hỏng việc.
If a model is bad at following instructions, it does not matter how good your prompt is. Huyen draws the line clearly: a model that understands a tweet's sentiment but returns HAPPY and ANGRY instead of NEGATIVE / POSITIVE / NEUTRAL has the domain capability but poor instruction-following. Google's IFEval picks 25 instruction types that a program can verify automatically — keyword inclusion, length constraints, number of bullet points, JSON format — and scores the fraction of instructions followed correctly.112
Một dạng chỉ dẫn rất phổ biến ngoài đời là nhập vai — yêu cầu mô hình đóng một nhân vật hay một nhân cách, hoặc để giải trí, hoặc như một mẹo prompt. Huyen dẫn phân tích một triệu cuộc hội thoại từ demo Vicuna và Chatbot Arena của LMSYS (Zheng và cộng sự, 2023), trong đó nhập vai là ca sử dụng phổ biến thứ tám. Bà khuyên nếu ứng dụng của bạn có nhập vai thì phải kiểm tra mô hình có giữ được vai không, trên cả hai mặt phong cách lẫn kiến thức: nếu mô hình đóng vai Thành Long thì lời nó nói phải mang phong cách Thành Long và dựa trên hiểu biết của Thành Long.114
Nhìn thấy ở đâuWhere you see it Ở Ello, một startup giúp trẻ tập đọc mà Huyen nhắc tới: hệ thống phải sinh truyện chỉ dùng đúng vốn từ đứa trẻ đã biết — một chỉ dẫn mà mô hình buộc phải tuân thủ tuyệt đối. Ở một ứng dụng dạy trẻ tập đọc: máy phải kể chuyện chỉ bằng những chữ đứa trẻ đã biết, không được dùng chữ lạ. At Ello, a startup helping kids read that Huyen mentions: the system must generate stories using only the words that child already knows — an instruction the model has to obey absolutely.INFOBench nới rộng định nghĩa
INFOBench (Qin và cộng sự, 2024) coi tuân lệnh rộng hơn IFEval: ngoài định dạng, nó còn đo ràng buộc nội dung (“chỉ bàn về biến đổi khí hậu”), quy tắc ngôn ngữ (“dùng tiếng Anh thời Victoria”) và giọng điệu. Vì những thứ này không tự kiểm tra được, nhóm tác giả tách mỗi chỉ dẫn thành một danh sách câu hỏi có/không; điểm của một chỉ dẫn là tỷ lệ tiêu chí đạt. Họ kết luận rằng GPT-4 tuy chưa bằng chuyên gia người nhưng chính xác hơn người gán nhãn thuê qua Amazon Mechanical Turk.13
Vì sao nhiều mô hình có 7 hay 65 tỷ tham số
Khi tự vận hành mô hình, chi phí ngoài nhân lực chính là điện toán, nên người ta chọn mô hình lớn nhất vừa khít máy. GPU thường có 16, 24, 48 hay 80 GB bộ nhớ — Huyen nhận xét rằng việc rất nhiều mô hình phổ biến có 7 hay 65 tỷ tham số không phải là ngẫu nhiên. Với API thì chi phí mỗi token gần như không đổi khi mở rộng quy mô; với máy tự nuôi thì càng chạy nhiều, giá mỗi token càng rẻ — nên ở mỗi mức quy mô, bài toán xây-hay-mua phải tính lại.1
Thứ bạn không đổi được, và thứ bạn đổi đượcCái sửa được và cái chịu thuaWhat you cannot change, and what you can
Huyen mở phần này bằng một câu gọn: rốt cuộc bạn không quan tâm mô hình nào tốt nhất, bạn quan tâm mô hình nào tốt nhất cho ứng dụng của bạn. Và việc chọn mô hình không làm một lần: mỗi kỹ thuật thích ứng lại buộc phải chọn lại — prompt thì nên bắt đầu từ mô hình mạnh nhất để thử tính khả thi rồi lùi dần xuống mô hình nhỏ; tinh chỉnh thì nên bắt đầu từ mô hình nhỏ để chạy thử mã rồi tiến dần lên mô hình lớn nhất mà phần cứng chịu được.1
Tác giả nói: đừng hỏi máy nào giỏi nhất, hãy hỏi máy nào hợp nhất với việc của mình. Và chuyện chọn máy làm đi làm lại nhiều lần chứ không chỉ một lần. Nhớ nhé: hợp việc quan trọng hơn giỏi chung chung.
Huyen opens this part bluntly: at the end of the day you do not care which model is best, you care which model is best for your application. And selection is not a one-off: every adaptation technique forces you to choose again — prompt engineering starts from the strongest model to test feasibility and works backwards to smaller ones; finetuning starts from a small model to test your code and works up to the biggest one your hardware fits.1
Thuộc tính cứng là thứ bạn không thể hoặc không đáng đổi; thuộc tính mềm là thứ bạn có thể và sẵn sàng cải thiện. Vạch đúng ranh giới ấy chính là bước lọc đầu tiên.
Có thứ ta sửa được, có thứ ta đành chịu. Biết phân biệt hai loại ấy là xong được nửa việc chọn máy.
Hard attributes are what you cannot or will not change; soft attributes are what you can and are willing to improve. Drawing that line correctly is the first filter.
Huyen nhấn mạnh rằng ranh giới này phụ thuộc vào cả mô hình lẫn ca sử dụng, chứ không cố định. Độ trễ là thuộc tính mềm nếu bạn nắm mô hình trong tay và có thể tối ưu cho nó chạy nhanh hơn; nó là thuộc tính cứng nếu bạn gọi mô hình do người khác vận hành. Bà cũng kể cả hai chiều kinh nghiệm: có lần độ chính xác quanh quẩn 20% ở vài prompt đầu rồi nhảy lên 70% sau khi bà tách bài toán làm hai bước; lại có lần một mô hình vẫn vô dụng sau hàng tuần chỉnh sửa và bà phải bỏ nó.1
-
05Open source, open weight, licences
“Mã nguồn mở” với mô hình nghĩa là gìMáy “mở” là mở tới đâuWhat “open source” means for a model
Huyen giải thích rằng thuật ngữ này đã thành điểm tranh cãi. Có người cho rằng vì năng lực của mô hình phần lớn là hàm của dữ liệu huấn luyện, mô hình chỉ đáng gọi là mở khi dữ liệu huấn luyện cũng công khai. Để phân biệt, người ta dùng open weight cho mô hình chỉ mở trọng số, và open model cho mô hình mở cả dữ liệu. Bà lưu ý rằng tại thời điểm viết sách, tuyệt đại đa số mô hình mở chỉ là mở trọng số — và bản thân bà, cho gọn, vẫn dùng “mã nguồn mở” cho mọi mô hình có trọng số công khai.1
“Mở” có hai mức. Mức một: cho tải máy về dùng. Mức hai: cho xem luôn cả đống sách mà máy đã học. Hầu hết chỉ mở mức một. Nhớ nhé: mở không có nghĩa là muốn làm gì cũng được — còn phải đọc giấy phép.
Huyen explains that the term has become contentious. Some argue that because a model's performance is largely a function of its training data, a model is only open if the data is public too. To mark the difference, open weight is used for models without open data, and open model for those with it. She notes that as of writing, the vast majority of open models are open weight only — and that for simplicity she herself uses “open source” for any model whose weights are public.1
Nhìn thấy ở đâuWhere you see it Ở giấy phép Llama 2 và Llama 3: cho dùng thương mại, nhưng ứng dụng có hơn 700 triệu người dùng hoạt động hàng tháng phải xin giấy phép riêng từ Meta. Ở điều khoản của một số máy nổi tiếng: dùng thoải mái, trừ khi app của bạn quá đông người dùng. In the Llama 2 and Llama 3 licences: commercial use allowed, but applications with more than 700 million monthly active users need a separate licence from Meta.Ba câu hỏi nên hỏi mọi giấy phép
Huyen đề xuất ba câu: giấy phép có cho dùng thương mại không; nếu có thì kèm hạn chế gì; và có cho dùng đầu ra của mô hình để huấn luyện hay cải thiện mô hình khác không. Câu thứ ba quan trọng vì nó chặn hoặc mở đường cho chưng cất mô hình — dạy một mô hình nhỏ bắt chước một mô hình lớn. Bà ghi nhận Mistral ban đầu không cho phép rồi sau đổi giấy phép, còn các giấy phép Llama tại thời điểm viết sách thì vẫn không cho.1
Rừng giấy phép đang bớt rậm
Thế giới mã nguồn mở vốn đã rối với MIT, Apache 2.0, GPL, BSD, Creative Commons; mô hình nền tảng làm nó rối hơn vì nhiều hãng tự viết giấy phép riêng. Huyen bày tỏ hy vọng cộng đồng sẽ hội tụ về vài giấy phép chuẩn, và nêu dấu hiệu tích cực: cả Gemma của Google lẫn Mistral-7B đều phát hành dưới Apache 2.0.1
-
06Data privacy & data lineage
Dữ liệu của bạn đi đâu, dữ liệu của mô hình từ đâuDữ liệu chạy đi đâuWhere your data goes, where the model's data came from
Với công ty có chính sách bảo mật nghiêm, API do bên ngoài vận hành là chuyện không bàn tới. Huyen dẫn sự cố sớm và nổi tiếng nhất: nhân viên Samsung dán thông tin nội bộ vào ChatGPT và vô tình làm lộ bí mật công ty — nghiêm trọng đến mức Samsung cấm ChatGPT vào tháng 5 năm 2023. Ở chiều ngược lại, nguồn gốc dữ liệu huấn luyện của mô hình cũng là rủi ro: nếu bạn dùng một mô hình mở vi phạm bản quyền, bên bị xâm phạm nhiều khả năng sẽ kiện bạn chứ không kiện người làm mô hình.1
Nếu công ty có bí mật, đừng gửi bí mật ấy ra ngoài. Có hãng lớn từng phải cấm nhân viên dùng trợ lý AI vì có người lỡ dán tài liệu mật vào đó. Và ngược lại, cũng phải hỏi: cái máy này học từ sách của ai, có xin phép chưa. Nhớ nhé: dữ liệu đi ra và dữ liệu đi vào, cả hai đều phải hỏi.
For companies with strict privacy policies, externally hosted APIs are out of the question. Huyen cites the best-known early incident: Samsung employees pasted proprietary information into ChatGPT and accidentally leaked company secrets — serious enough that Samsung banned ChatGPT in May 2023. In the other direction, a model's data lineage is a risk too: if you use an open model that infringes copyright, the infringed party is more likely to come after you than after the model's developers.1
Nhìn thấy ở đâuWhere you see it Ở nỗi lo mô hình ghi nhớ dữ liệu huấn luyện: Huyen dẫn phát hiện rằng mô hình StarCoder của Hugging Face ghi nhớ 8% tập huấn luyện của nó. Ở chuyện máy có thể thuộc lòng một phần những gì nó từng đọc, rồi lỡ đọc lại cho người khác nghe. In the worry that models memorise training data: Huyen cites the finding that Hugging Face's StarCoder memorises 8% of its training set.Điều khoản có thể đổi
Dù phần lớn nhà cung cấp API tuyên bố không dùng dữ liệu của bạn để huấn luyện, Huyen nhắc rằng chính sách có thể thay đổi: tháng 8 năm 2023, Zoom vấp phản ứng dữ dội sau khi người ta phát hiện hãng lặng lẽ sửa điều khoản dịch vụ để được dùng dữ liệu phát sinh từ dịch vụ — gồm dữ liệu sử dụng sản phẩm và dữ liệu chẩn đoán — để huấn luyện mô hình AI của họ.1
Minh bạch dữ liệu vẫn là ngoại lệ
Bà nhận xét rằng với đa số mô hình, thông tin về dữ liệu huấn luyện gần như không có. Trong báo cáo kỹ thuật của Gemini, Google đi rất sâu vào hiệu năng nhưng nói về dữ liệu chỉ vỏn vẹn rằng “mọi nhân công làm giàu dữ liệu đều được trả ít nhất mức lương đủ sống tại địa phương”. Mối lo về nguồn gốc dữ liệu vì thế đẩy các công ty theo những hướng trái ngược nhau — có nơi chạy sang mô hình mở hoàn toàn để tự kiểm tra dữ liệu, có nơi chạy sang mô hình thương mại để được hợp đồng che chắn rủi ro pháp lý.1
-
07API cost versus engineering cost
API đắt, nhưng kỹ thuật còn đắt hơnThuê thì tốn tiền, tự nuôi thì tốn ngườiAPIs are expensive, but engineering can be more so
API tính tiền theo mức dùng, nên tới một quy mô nào đó công ty sẽ nghĩ tới chuyện tự vận hành. Nhưng Huyen viết thẳng: tự vận hành đòi hỏi thời gian, nhân tài và công sức kỹ thuật không hề nhỏ — bạn phải tối ưu mô hình, mở rộng và duy trì dịch vụ suy luận, dựng rào chắn quanh mô hình. “API thì đắt, nhưng kỹ thuật có thể còn đắt hơn.” Đổi lại, dùng API của người khác nghĩa là bạn phụ thuộc vào cam kết mức dịch vụ của họ.1
Thuê máy của người khác thì trả tiền theo lượt dùng — dùng nhiều thì tốn. Tự nuôi máy thì khỏi trả lượt, nhưng phải thuê người giỏi để chăm nó, và người giỏi còn đắt hơn. Nhớ nhé: không có lựa chọn nào miễn phí, chỉ có lựa chọn trả bằng tiền hay trả bằng công.
APIs charge per usage, so at a certain scale a company starts thinking about hosting its own models. But Huyen is blunt: self-hosting takes nontrivial time, talent and engineering effort — you have to optimise the model, scale and maintain the inference service, and build guardrails around it. “APIs are expensive, but engineering can be even more so.” In exchange, using someone else's API means depending on their SLA.1
Nhìn thấy ở đâuWhere you see it Ở lời khuyên thực dụng của Huyen: dù chọn mở hay đóng, hãy chọn mô hình theo một API chuẩn — hiện nhiều nhà cung cấp bắt chước API của OpenAI — để sau này còn dễ thay mô hình. Ở mẹo rất thực tế: chọn máy nào dùng chung một kiểu “ổ cắm” với số đông, để sau còn dễ đổi. In Huyen's practical advice: open or closed, pick a model that follows a standard API — many providers currently mimic OpenAI's — so you can swap models later.Chức năng: con dao hai lưỡi
API thường có sẵn những thứ khó tự làm: mở rộng quy mô, gọi hàm, đầu ra có cấu trúc, rào chắn đầu ra. Nhưng bạn bị giới hạn trong những gì API cho. Ví dụ điển hình là logprobs — rất hữu ích cho phân loại, đánh giá và diễn giải mô hình — mà nhiều nhà cung cấp thương mại ngại lộ vì sợ người khác dùng chúng để sao chép mô hình của mình.1
Kiểm soát và nguy cơ mất quyền truy cập
Huyen dẫn một nghiên cứu năm 2024 của a16z cho thấy hai lý do chính khiến doanh nghiệp quan tâm mô hình mở là kiểm soát và khả năng tùy biến. Bà kể Convai — một công ty bà cố vấn, làm nhân vật AI 3D biết cầm nắm đồ vật — liên tục bị mô hình thương mại trả lời “là một mô hình ngôn ngữ, tôi không có khả năng vật lý”, và cuối cùng phải tinh chỉnh mô hình mở. Bà cũng nhắc rằng bạn không thể “đóng băng” một mô hình thương mại như với mô hình mở, rằng lịch sử cho thấy các hãng thương mại thiếu minh bạch về thay đổi phiên bản, và rằng nhà cung cấp có thể ngừng phục vụ ngành hay quốc gia của bạn — như việc Ý từng tạm cấm OpenAI năm 2023.1
-
08Seven axes of build versus buy
Bảy trục để quyết xây hay muaBảy câu hỏi trước khi quyếtSeven axes for build versus buy
Huyen gom cả quyết định vào bảy trục: quyền riêng tư dữ liệu, nguồn gốc dữ liệu, hiệu năng, chức năng, chi phí, kiểm soát, và triển khai trên thiết bị. Về hiệu năng, bà thừa nhận khoảng cách giữa mô hình mở và mô hình độc quyền đang thu hẹp trên MMLU, nhưng lập luận rằng động cơ kinh tế không ủng hộ việc san bằng: nếu bạn có mô hình mạnh nhất, bạn sẽ mở nó cho người khác kiếm tiền, hay tự kiếm tiền từ nó? Vì thế bà dự đoán mô hình mở mạnh nhất sẽ còn đi sau mô hình độc quyền mạnh nhất trong tương lai gần.1
Muốn quyết tự nuôi hay đi thuê, hãy hỏi bảy điều: dữ liệu có bí mật không, máy học từ đâu, mạnh yếu ra sao, có đủ chức năng không, tốn bao nhiêu, mình kiểm soát được bao nhiêu, và có cần chạy ngay trên điện thoại không. Nhớ nhé: không có đáp án chung, chỉ có đáp án của đội mình.
Huyen folds the whole decision into seven axes: data privacy, data lineage, performance, functionality, cost, control, and on-device deployment. On performance she concedes the gap between open and proprietary models is closing on MMLU, but argues the incentives do not favour parity: if you had the strongest model, would you open it for others to capitalise on, or capitalise on it yourself? She therefore expects the strongest open model to lag the strongest proprietary one for the foreseeable future.1
Nhìn thấy ở đâuWhere you see it Ở trục cuối cùng: nếu ứng dụng phải chạy trên thiết bị — vì vùng phủ sóng kém, hoặc vì bạn muốn trợ lý đọc hết dữ liệu của mình mà dữ liệu không rời máy — thì API của bên thứ ba bị loại ngay từ đầu. Ở trục cuối: nếu muốn máy chạy ngay trong điện thoại, không cần mạng, thì buộc phải tự nuôi. In the last axis: if the application must run on-device — poor connectivity, or an assistant that reads all your data without that data leaving the device — third-party APIs are out from the start.Một chi tiết dễ bỏ sót
Cùng một mô hình có thể được phục vụ qua nhiều API khác nhau với tính năng, ràng buộc và giá khác nhau — Huyen lấy ví dụ GPT-4 có mặt trên cả API của OpenAI lẫn của Azure. Bà cảnh báo rằng hiệu năng của cùng một mô hình qua các API khác nhau có thể lệch nhau, vì mỗi bên tối ưu theo một kiểu, nên hãy kiểm thử kỹ khi chuyển nhà cung cấp.1
Vì sao mô hình mở tiến chậm hơn
Ngoài chuyện động cơ kinh tế, Huyen nêu một lý do ít được nhắc: người phát triển mô hình mở không nhận được phản hồi từ người dùng như mô hình thương mại. Một khi mô hình đã mở ra, tác giả của nó không còn biết nó đang được dùng thế nào và chạy tốt tới đâu ngoài đời.1
Benchmark công khai lọc bớt mô hình dở; nó không tìm giúp bạn mô hình hayBài thi chung chỉ loại máy dởPublic benchmarks weed out bad models; they will not find your good one
Đây là câu Huyen lặp lại hai lần trong chương, và nó là bản lề của cả phần cuối: benchmark công khai giúp bạn loại mô hình tệ, nhưng không giúp bạn tìm mô hình tốt nhất cho ứng dụng của bạn. Lý do gồm hai lớp — một là cách chọn và gộp benchmark của các bảng xếp hạng vốn không rõ ràng, hai là dữ liệu của chúng nhiều khả năng đã bị nhiễm vào tập huấn luyện của chính những mô hình đang được chấm.1
Câu quan trọng nhất của phần này: bài thi công khai giúp bạn loại những máy dở, nhưng không chỉ ra được máy nào hợp với việc của bạn. Vì hai lẽ: đề thi được chọn khá tùy hứng, và nhiều máy đã “học tủ” vì đề bị lộ. Nhớ nhé: muốn biết máy nào hợp, phải tự ra đề.
Huyen repeats this line twice in the chapter, and it is the hinge of the closing part: public benchmarks help you filter out bad models, but they will not help you find the best model for your application. For two reasons — how leaderboards select and aggregate benchmarks is not a transparent process, and their data has likely leaked into the training sets of the very models being scored.1
Khi bạn đánh giá mô hình cho một ứng dụng cụ thể, về bản chất bạn đang tạo ra một bảng xếp hạng riêng — xếp các mô hình theo tiêu chí của chính bạn.
Chọn máy cho việc của mình, thực ra là tự lập một bảng xếp hạng riêng, chấm theo đề của mình.
When you evaluate models for a specific application, you are essentially creating a private leaderboard that ranks models by your own criteria.
Cách các bảng xếp hạng công khai làm việc vì thế vẫn đáng học — không phải để tin con số, mà để mượn phương pháp. Huyen cũng cảnh báo rằng chạy benchmark rất tốn: bà dẫn con số Stanford chi khoảng 80.000–100.000 đô-la để đánh giá 30 mô hình trên trọn bộ HELM. Đáng chú ý, đây là con số bà suy ra chứ không phải con số báo cáo gốc: bài báo HELM công bố 38.000 đô-la cho các API thương mại cộng 19.500 giờ GPU cho mô hình mở, và nếu một giờ GPU tốn 2,15–3,18 đô-la thì tổng rơi vào khoảng ấy.115
-
09Benchmark selection & aggregation
Vì sao dừng ở sáu benchmark, mà không phải bảy?Ai quyết bảng xếp hạng gồm những bài nào?Why stop at six benchmarks, and not seven?
Huyen so hai bảng xếp hạng cùng thời: cuối năm 2023, Hugging Face lấy trung bình sáu benchmark — ARC-C, MMLU, HellaSwag, TruthfulQA, WinoGrande, GSM-8K — trong khi HELM của Stanford dùng mười benchmark, mà chỉ hai trong số đó (MMLU và GSM-8K) trùng với Hugging Face. Bà đặt loạt câu hỏi không nhằm chê ai: vì sao HELM Lite có luật và y nhưng không có khoa học tổng quát? Vì sao có hai bài toán nhưng không có bài lập trình? Vì sao cả hai đều không có tóm tắt, dùng công cụ, phát hiện độc hại?11516
Hai bảng xếp hạng nổi tiếng cùng thời chấm bằng hai bộ đề khác hẳn nhau — chỉ trùng nhau đúng hai bài. Vậy ai quyết đề nào được vào, và vì sao dừng ở sáu bài chứ không phải bảy? Nhớ nhé: bảng xếp hạng nào cũng là lựa chọn của một nhóm người, không phải chân lý.
Huyen compares two contemporaneous leaderboards: in late 2023 Hugging Face averaged six benchmarks — ARC-C, MMLU, HellaSwag, TruthfulQA, WinoGrande, GSM-8K — while Stanford's HELM used ten, only two of which (MMLU and GSM-8K) overlapped. Her questions are not meant as criticism: why does HELM Lite include legal and medical but not general science? Why two maths tests and no coding? Why does neither test summarisation, tool use or toxicity detection?11516
Nhìn thấy ở đâuWhere you see it Ở cách gộp điểm: Hugging Face lấy trung bình — coi 80% trên TruthfulQA ngang 80% trên GSM-8K — còn HELM từ chối lấy trung bình mà dùng tỷ lệ thắng trung bình, tức tỷ lệ lần một mô hình đạt điểm cao hơn mô hình khác, bình quân trên các kịch bản. Ở cách cộng điểm: một bên lấy trung bình cộng, một bên đếm số lần thắng. Hai cách cho ra hai thứ hạng khác nhau. In the aggregation: Hugging Face averages — treating 80% on TruthfulQA as equal to 80% on GSM-8K — while HELM shuns averaging in favour of mean win rate, the fraction of times a model scores better than another, averaged across scenarios.Tương quan giữa các benchmark
Một khía cạnh hay bị bỏ qua: nếu hai benchmark tương quan hoàn hảo thì giữ cả hai là thừa, và các benchmark tương quan mạnh có thể khuếch đại thiên lệch. Huyen dẫn bảng hệ số Pearson do Balázs Galambosi tính tháng 1 năm 2024 cho sáu benchmark của Hugging Face: WinoGrande, MMLU và ARC-C tương quan rất mạnh với nhau — MMLU với WinoGrande đạt 0,9011 — hợp lý vì cả ba đều đo suy luận. Ngược lại, TruthfulQA chỉ tương quan vừa phải với phần còn lại, gợi ý rằng cải thiện suy luận và toán không đồng nghĩa với cải thiện tính trung thực.1
Con số “sáu benchmark” có hạn sử dụng
Cần ghi rõ mốc thời gian, vì chính các nguồn cũng không thống nhất: Hugging Face ra mắt bảng xếp hạng năm 2023 với bốn benchmark, cuối năm ấy mở rộng thành sáu, rồi tháng 6 năm 2024 — chưa đầy một năm sau — thay bằng một bộ hoàn toàn mới và khó hơn, trong đó GSM-8K nhường chỗ cho MATH mức 5 và MMLU nhường chỗ cho MMLU-PRO, kèm GPQA, MuSR, BBH và IFEval. Huyen ghi nhận thay đổi này ngay trong sách và nói thẳng rằng bà không nghi ngờ gì chuyện những benchmark mới ấy rồi cũng sẽ bão hòa.116
-
10Data contamination
Nhiễm dữ liệu — học tủ mà không cố ýĐề thi bị lộData contamination — cheating without meaning to
Nhiễm dữ liệu xảy ra khi mô hình được huấn luyện trên chính dữ liệu dùng để chấm nó; khi đó điểm cao có thể chỉ phản ánh trí nhớ. Huyen dẫn một minh chứng châm biếm đúng chỗ: bài báo năm 2023 của Rylan Schaeffer, “Pretraining on the Test Set Is All You Need”, trong đó một mô hình chỉ một triệu tham số, huấn luyện riêng trên dữ liệu của vài benchmark, đạt điểm gần như tuyệt đối và vượt các mô hình lớn hơn nhiều trên tất cả những benchmark ấy.117
Nếu máy đã đọc trước đề thi thì điểm cao chẳng chứng minh điều gì — nó chỉ thuộc bài. Có người đã làm hẳn một thí nghiệm trêu ngươi: lấy một máy rất bé, cho học đúng đề thi, thế là nó vượt cả những máy khổng lồ. Nhớ nhé: điểm cao mà đề đã lộ thì chỉ là học tủ.
Contamination happens when a model is trained on the very data used to score it; a high score may then reflect nothing but memorisation. Huyen cites a nicely pointed demonstration: Rylan Schaeffer's 2023 satirical paper “Pretraining on the Test Set Is All You Need”, in which a one-million-parameter model trained exclusively on several benchmarks' data achieved near-perfect scores and beat much larger models on all of them.117
Nhìn thấy ở đâuWhere you see it Ở phân tích của chính OpenAI về GPT-3: họ tìm thấy 13 benchmark có ít nhất 40% dữ liệu nằm trong tập huấn luyện của mô hình. Ở một báo cáo của chính hãng làm mô hình: 13 bộ đề có ít nhất 40% câu đã nằm trong sách mà máy từng đọc. In OpenAI's own analysis of GPT-3: they found 13 benchmarks with at least 40% of their data inside the training set.Hai cách phát hiện
Chồng lấp n-gram: nếu một chuỗi 13 token trong mẫu đánh giá cũng xuất hiện trong dữ liệu huấn luyện, mẫu ấy bị coi là “bẩn”. Cách này chính xác hơn nhưng tốn thời gian và tiền — phải so từng mẫu với toàn bộ dữ liệu huấn luyện — và bất khả thi nếu không có quyền truy cập dữ liệu ấy. Độ rối: nếu độ rối của mô hình trên dữ liệu đánh giá thấp bất thường, nhiều khả năng nó đã thấy dữ liệu này rồi. Cách này kém chính xác hơn nhưng nhẹ hơn nhiều.1
Phần lớn nhiễm là vô tình — và đôi khi là cố ý có lý
Đa số mô hình ngày nay huấn luyện trên dữ liệu cào từ internet, mà quá trình cào có thể vô tình kéo về cả benchmark công khai. Nhiễm cũng có thể xảy ra gián tiếp khi dữ liệu huấn luyện và dữ liệu đánh giá cùng đến từ một nguồn — bạn đưa sách giáo khoa toán vào để mô hình giỏi toán hơn, người khác lại lấy chính sách ấy ra ra đề. Huyen còn nêu một trường hợp cố ý mà vẫn hợp lý: sau khi đã chọn được mô hình tốt nhất dựa trên benchmark sạch, bạn huấn luyện tiếp nó trên chính dữ liệu benchmark vì dữ liệu chất lượng cao ấy làm mô hình tốt hơn cho người dùng — mô hình phát hành ra bị nhiễm, nhưng đó có thể vẫn là quyết định đúng. Một người bạn của bà đúc kết: “một benchmark hết hữu dụng ngay khi nó được công khai”.118
-
11Evaluate all components
Chấm từng bộ phận, chấm từng lượt, và chấm cả nhiệm vụChấm từng khúc, không chỉ chấm cuốiScore every component, every turn, and the whole task
Bước đầu của việc dựng quy trình là chấm cả đầu ra cuối lẫn đầu ra trung gian của từng bộ phận. Huyen lấy ví dụ một ứng dụng rút tên công ty hiện tại từ hồ sơ PDF, chạy hai bước: trích văn bản từ PDF, rồi rút tên công ty từ văn bản ấy. Nếu kết quả sai mà không chấm riêng từng bước, bạn không biết hỏng ở đâu — bước một đo bằng độ tương đồng với văn bản chuẩn, bước hai đo bằng độ chính xác khi đã cho sẵn văn bản đúng.1
Một hệ thống thường gồm nhiều khúc nối nhau. Nếu chỉ chấm khúc cuối, sai rồi cũng không biết sai ở khúc nào. Ví dụ: đọc chữ từ file PDF là một khúc, tìm tên công ty trong chữ ấy là khúc khác. Nhớ nhé: chấm từng khúc thì mới biết chỗ nào hỏng.
The first step in building the pipeline is scoring both the end-to-end output and each component's intermediate output. Huyen's example is an application that extracts a person's current employer from a resume PDF in two steps: extract text from the PDF, then extract the employer from that text. If the result is wrong and you have not scored each step, you do not know where it broke — step one by similarity with the ground-truth text, step two by accuracy given correctly extracted text.1
Nhìn thấy ở đâuWhere you see it Ở khác biệt giữa chấm theo lượt và chấm theo nhiệm vụ: nó tạo ra khác biệt rất lớn khi một hệ thống giải xong bài toán trong hai lượt thay vì hai mươi lượt. Ở chỗ: giải xong việc trong hai lượt hỏi đáp khác hẳn với giải xong sau hai mươi lượt. In the difference between turn-based and task-based scoring: it matters enormously whether a system solves a problem in two turns or in twenty.Ranh giới giữa các nhiệm vụ rất khó vạch
Huyen thừa nhận chấm theo nhiệm vụ quan trọng hơn — vì người dùng chỉ quan tâm việc của họ có xong không — nhưng khó ở chỗ không biết một nhiệm vụ kết thúc ở đâu. Trong một cuộc trò chuyện với chatbot, khi bạn gửi câu hỏi mới, đó là nối tiếp nhiệm vụ cũ hay đã là nhiệm vụ mới?1
Một benchmark chấm theo nhiệm vụ
Ví dụ của bà là twenty_questions trong bộ BIG-bench, phỏng theo trò chơi Hai Mươi Câu Hỏi: một bản sao của mô hình (Alice) chọn một khái niệm — quả táo, cái xe, cái máy tính — còn bản sao kia (Bob) đặt câu hỏi để đoán ra, và Alice chỉ được trả lời có hoặc không. Điểm dựa trên việc Bob có đoán đúng không và mất bao nhiêu câu hỏi.119
-
12Guidelines, rubrics & evaluation data
Đúng chưa chắc đã tốt — và bao nhiêu mẫu thì đủĐúng chưa chắc là hayCorrect is not the same as good — and how much data is enough
Huyen viết rằng phần khó nhất thường không phải là phán một đầu ra tốt hay không, mà là định nghĩa thế nào là tốt. Bà dẫn bài tổng kết một năm triển khai AI sinh của LinkedIn: rào cản đầu tiên chính là viết hướng dẫn đánh giá. Với ứng dụng đánh giá mức phù hợp công việc của họ, câu trả lời “Bạn hoàn toàn không hợp với vị trí này” có thể đúng nhưng vô ích — một câu trả lời tốt phải chỉ ra khoảng cách giữa yêu cầu công việc và hồ sơ ứng viên, cùng cách thu hẹp khoảng cách ấy.1
Khó nhất không phải là biết câu trả lời đúng hay sai, mà là định nghĩa thế nào là hay. Câu “bạn không hợp đâu” có thể rất đúng mà vẫn rất vô dụng — câu hay phải nói rõ thiếu chỗ nào và nên làm gì. Nhớ nhé: viết rõ tiêu chí trước, rồi hãy chấm.
Huyen writes that the hardest part is usually not judging whether an output is good, but defining what good means. She cites LinkedIn's retrospective on a year of deploying generative AI: the first hurdle was writing the evaluation guideline. For their Job Assessment feature, “You are a terrible fit” might be correct but unhelpful — a good response explains the gap between the job's requirements and the candidate's background, and what they can do to close it.1
Nhìn thấy ở đâuWhere you see it Ở việc buộc chỉ số đánh giá phải nối với chỉ số kinh doanh: nhất quán sự kiện 80% thì tự động hóa được 30% yêu cầu hỗ trợ, 90% thì 50%, 98% thì 90% — đó là kiểu ánh xạ Huyen khuyên nên dựng. Ở chỗ nối điểm số với việc thật: đúng được tới mức nào thì thay được bao nhiêu phần việc của người. In tying evaluation metrics to business metrics: 80% factual consistency automates 30% of support requests, 90% automates 50%, 98% automates 90% — the kind of mapping Huyen advises building.Cắt lát dữ liệu và nghịch lý Simpson
Huyen khuyên chia dữ liệu đánh giá thành từng lát và xem hiệu năng trên từng lát riêng: để tránh thiên lệch với nhóm người dùng thiểu số, để gỡ lỗi, để tìm chỗ cải thiện, và để không sập bẫy nghịch lý Simpson — hiện tượng mô hình A thắng mô hình B trên mọi nhóm con nhưng lại thua trên dữ liệu gộp. Bà đưa hẳn một bảng ví dụ cho trường hợp ấy, và ghi rõ bà đã dùng cùng ví dụ này trong cuốn Designing Machine Learning Systems, với số liệu gốc từ một nghiên cứu y khoa đăng trên British Medical Journal năm 1986. Nguyên tắc của bà gọn một câu: nếu bạn quan tâm điều gì, hãy đặt một tập kiểm thử cho nó.1
Bao nhiêu mẫu là đủ
Huyen dẫn ước lượng thô của OpenAI về số mẫu cần để tin chắc 95% rằng hệ này tốt hơn hệ kia: chênh 30% thì cần khoảng 10 mẫu, chênh 10% cần khoảng 100, chênh 3% cần khoảng 1.000, chênh 1% cần khoảng 10.000 — quy tắc gọn là cứ giảm chênh lệch 3 lần thì số mẫu cần tăng 10 lần. Để tham chiếu, trong lm-evaluation-harness của Eleuther, số mẫu trung vị của một benchmark là 1.000 và trung bình là 2.159. Bà cũng gợi ý phép bootstrap: rút lại 100 mẫu có hoàn lại từ chính 100 mẫu ấy, chấm nhiều lần — nếu lần này 90% mà lần kia 70% thì quy trình đánh giá của bạn chưa đáng tin.14
Ba ngộ nhận thường gặp khi đọc chương nàyThree misconceptions readers bring to this chapter
Chương 4 rất dễ bị đọc thành “danh sách benchmark nên dùng”. Ba hiểu lầm dưới đây là những chỗ bản thân lập luận của Huyen chống lại cách đọc ấy.
Chapter 4 is easy to misread as “a list of benchmarks you should use”. The three misreadings below are exactly where Huyen's own argument pushes back.
“Chọn mô hình đứng đầu bảng xếp hạng là xong.”“Just pick whatever tops the leaderboard.”
Huyen viết rằng một mô hình xếp cao trên bảng công khai có khả năng chạy tốt cho ứng dụng của bạn, nhưng còn xa mới là luôn luôn. Nếu bạn cần sinh mã mà bảng xếp hạng ấy không có benchmark sinh mã nào, nó giúp bạn rất ít. Và như bà nhắc ở đoạn về các bản cập nhật của OpenAI: mô hình tốt nhất nói chung chưa chắc là mô hình tốt nhất cho ứng dụng của bạn.
Huyen writes that a model ranking high on a public leaderboard will likely — but far from always — perform well for your application. If you need code generation and that leaderboard has no code benchmark, it helps you very little. As she notes in the passage on OpenAI's model updates: the best model overall may not be the best model for you.
“Mô hình mở luôn rẻ hơn.”“Open models are always cheaper.”
Chi phí API là con số hiện ra trên hóa đơn; chi phí kỹ thuật thì không. Huyen liệt kê những thứ bạn phải tự gánh khi tự vận hành: tối ưu mô hình, mở rộng và duy trì dịch vụ suy luận, dựng rào chắn — rồi kết luận rằng API đắt, nhưng kỹ thuật có thể còn đắt hơn. Ở mỗi mức quy mô, phép tính này phải làm lại từ đầu.
API cost appears on an invoice; engineering cost does not. Huyen lists what you take on by self-hosting: optimising the model, scaling and maintaining the inference service, building guardrails — and concludes that APIs are expensive but engineering can be more so. At each new scale, the arithmetic has to be redone.
“Điểm benchmark cao nghĩa là mô hình thật sự giỏi việc đó.”“A high benchmark score means the model is really good at that.”
Câu chốt của Huyen về nhiễm dữ liệu: việc một mô hình đạt điểm cao trong kỳ thi luật sư không có nghĩa là nó giỏi tư vấn pháp lý — có thể nó chỉ đã được huấn luyện trên rất nhiều đề thi luật sư. Vì thế bà khuyên các nhà phát triển mô hình nên công bố cả tỷ lệ dữ liệu benchmark nằm trong tập huấn luyện lẫn điểm trên phần mẫu sạch.
Huyen's line on contamination: just because a model scores well on bar exams does not mean it is good at giving legal advice — it may simply have trained on many bar exam questions. Which is why she asks model developers to disclose both the share of benchmark data inside their training set and the score on the clean samples.
Quy trình đánh giá của bạn đã đủ chưa?Bạn đã biết cách chấm chưa?Is your evaluation pipeline good enough?
Mười hai câu hỏi rút từ ba phần của chương, xếp theo đúng thứ tự Huyen dựng lập luận: tiêu chí trước, chọn mô hình sau, quy trình riêng sau cùng.
Mười hai câu để tự hỏi, theo đúng thứ tự trong bài.
Twelve questions drawn from the chapter's three parts, in the order Huyen builds her argument: criteria first, selection next, your own pipeline last.
Benchmark công khai giúp bạn loại bỏ mô hình dở; chỉ quy trình đánh giá của riêng bạn mới tìm ra mô hình hay. Bài thi chung chỉ giúp loại máy dở; muốn biết máy nào hợp việc của mình thì phải tự ra đề. Public benchmarks help you weed out the bad models; only your own evaluation pipeline will find the good one.