Lò Luyện Đo Lường

Cần biết trước: bạn đã từng train hoặc fine-tune ít nhất một model Dựng nên: cách đặt câu hỏi trước mọi phép đo Dẫn tới: Module 01 — BLEU và họ metric n-gram

1. Ba câu hỏi phải trả lời trước khi chạy phép đo đầu tiên

Bạn đã ra hàng chục quyết định kỹ thuật dựa trên một con số trần trụi. Chọn checkpoint nào để đem đi distil. Kết luận rằng lượng tử hoá int8 "không làm hỏng gì". Bỏ một nhánh kiến trúc vì nó thua vài điểm. Tin rằng phiên bản mới thắng vì bảng số nhìn đẹp hơn.

Mỗi lần như thế, bạn đã ngầm ký một giả định: con số kia ổn định. Rằng nếu đổi bộ test, đổi seed, đổi cách tokenize, nó vẫn thế. Giả định đó gần như luôn sai, và quyển này tồn tại để chỉ ra nó sai bao nhiêu.

Luận đề xuyên suốt gói trong một câu: một con số không kèm sai số là một tin đồn. Không phải nói dối — tin đồn, tức là thứ có thể đúng, nhưng bạn không có quyền hành động dựa trên nó. Module 03 sẽ dạy cách tính sai số. Module này dạy thứ đến trước cả sai số: hỏi cho đúng.

Trước mọi phép đo, viết ba dòng vào sổ. Ba dòng, không phải ba trang.

1. Đo cho ai. Ai đọc con số này, và họ tin nó tới mức nào. Con số bạn tự nhìn để chọn hướng debug được phép ồn ào. Con số dán vào README cho người khác dùng thì không.
2. Quyết định gì. Con số này sẽ đổi hành động nào của bạn. Nếu cả hai kết quả có thể xảy ra đều dẫn tới cùng một hành động, phép đo đó vô ích — đừng tốn GPU cho nó.
3. Sai thì mất gì. Hai chiều sai lệch gần như không bao giờ tốn bằng nhau, và chính sự bất đối xứng đó — chứ không phải con số — quyết định ngưỡng của bạn.

Câu thứ ba là câu hay bị bỏ qua nhất, nên hãy làm nó bằng số ngay tại đây. Gọi $C_{\text{ship}}$ là cái mất khi bạn ship một bản thật ra tệ hơn, $C_{\text{miss}}$ là cái mất khi bạn giữ lại một bản thật ra tốt hơn, và $p$ là mức tin của bạn rằng bản mới tốt hơn — một con số chủ quan bạn tự đặt trước khi đo, không phải p-value mà Module 04 sẽ nói tới. Ship có lợi khi

Giả sử ship nhầm tốn 30 ngày-người (phát hiện, rollback, dịch lại những chương đã đẩy đi), còn bỏ lỡ tốn 5 ngày-người (chờ thêm một chu kỳ). Nếu bạn tin ở mức $p = 0.6$: kỳ vọng mất khi ship là $0.4 \times 30 = 12$; khi không ship là $0.6 \times 5 = 3$. Không ship, dù bạn nghiêng về phía tin rằng nó tốt hơn.

2. Mục tiêu thật và cái bóng của nó

Mục tiêu thật (true objective) là điều bạn thật sự muốn xảy ra ngoài đời. Proxy (proxy metric) là thứ bạn đo được thay cho nó. Trong dự án dịch web novel zh→vi, mục tiêu thật là độc giả đọc hết truyện rồi quay lại. Không ai đo được thứ đó lúc 2 giờ sáng khi job train vừa xong.

Nên bạn tụt xuống một bậc. Rồi một bậc nữa. Mỗi bậc rẻ hơn, nhanh hơn — và mù thêm một chút.

Điểm mấu chốt: tương quan giữa bậc ④ và bậc ① là một quan sát thực nghiệm trong vùng bạn đã đo, không phải một định luật. Nó đúng cho các model bạn từng thấy. Nó không hứa gì về model tiếp theo, nhất là model được sinh ra bằng cách tối ưu chính bậc ④.

3. Chạy tay: proxy lên 4.85 điểm, mục tiêu thật mất gần bốn phần năm

Trừu tượng đủ rồi. Đây là một ca cụ thể, tính hết bằng máy tính bỏ túi.

Phản xạ đầu tiên của hầu hết mọi người là "vậy phạt nặng hơn đi". Thử phạt nặng nhất có thể: cho hẳn 0 điểm cho mọi câu sai tên riêng.

$\Delta = +2.975$. Vẫn dương. B vẫn thắng. Muốn $\Delta$ về 0, mức phạt phải là 166.7 điểm trên thang 0–100 — tức là không tồn tại mức phạt nào trong thang điểm cứu được phép trung bình này. Lý do rất đơn giản: 5 điểm nền cộng cho cả 200 câu là 1000 điểm-câu, trong khi hình phạt chỉ tạo ra chênh lệch trên $9 - 3 = 6$ câu mà B sai nhiều hơn A — phạt kịch trần 100 điểm cũng mới được 600 điểm-câu, vẫn thua 1000.

# Bộ test 200 câu, trong đó 30 câu có tên riêng nhân vật.
# Sai một tên riêng = hỏng 1 token trên khoảng 20 -> metric chỉ trừ 5 điểm.
N, NAME, PEN = 200, 30, 5

def proxy(diem_nen, so_cau_sai_ten):
    """Điểm tự động trung bình trên toàn bộ test."""
    return ((N - so_cau_sai_ten) * diem_nen
            + so_cau_sai_ten * (diem_nen - PEN)) / N

def chuong_sach(so_cau_sai_ten, cau_ten_moi_chuong=6):
    """Xác suất một chương 40 câu không dính lỗi tên riêng nào."""
    r = so_cau_sai_ten / NAME
    return (1 - r) ** cau_ten_moi_chuong

A = proxy(60, 3)                    # 59.925
B = proxy(65, 9)                    # 64.775
print(round(B - A, 3))              # 4.85     -> bảng báo cáo nói "ship!"
print(chuong_sach(3))               # 0.531441 -> 53.1% chương sạch
print(chuong_sach(9))               # 0.117649 -> 11.8% chương sạch
print(round(chuong_sach(9) / chuong_sach(3), 4))   # 0.2214   -> còn 22.1%

4. Luật Goodhart: metric tốt chết vì được chọn làm mục tiêu

Luật Goodhart (Goodhart's law), đặt theo tên nhà kinh tế Charles Goodhart, ở dạng phát biểu quen thuộc nhất: khi một chỉ số trở thành mục tiêu, nó thôi là một chỉ số tốt.

Cơ chế thì thẳng thừng. Proxy = phần trùng với mục tiêu thật + phần thừa. Trong vùng dữ liệu bạn từng quan sát, phần trùng chiếm ưu thế nên hai thứ đi cùng nhau. Tối ưu hoá là một cái máy tìm kiếm không có đạo đức: nó sẽ tìm ra hướng nào làm proxy tăng nhanh nhất, và hướng đó gần như luôn nằm trong phần thừa — vì phần thừa rẻ hơn để khai thác. Càng tối ưu mạnh, bạn càng bị đẩy ra khỏi vùng mà tương quan từng đúng.

Ca B ở mục 3 chính là cơ chế đó chạy đúng một bước. Phần thừa ở đây là điểm nền của mọi câu: cộng 5 điểm vào đó mua được ngay +4.85 điểm proxy, rẻ hơn hẳn việc dịch tên riêng cho đúng. Phần trùng — tỉ lệ chương đọc trót lọt — trả giá 41.38 điểm phần trăm. Hai đại lượng đã đi ngược chiều ngay ở bước tối ưu thứ nhất, không cần chờ tới bước thứ mười.

Trong đúng công việc bạn đang làm, Goodhart hiện ra ở ba chỗ, xếp theo mức khó nhận ra:

1. Nhiễm dữ liệu. Câu test lọt vào tập train, dù chỉ ở dạng gần trùng. Proxy tăng, năng lực không đổi. Dễ nhận ra nhất, và cũng thường bị bỏ qua nhất. Module 08 đưa cách đo.
2. Chỉnh decode để chiều metric. Sửa beam size, length penalty, ngưỡng lặp cho tới khi con số đẹp. Bạn không cải thiện model — bạn dịch chuyển bản dịch về phía dạng câu mà metric ưa. Điểm lên, người đọc không thấy khác.
3. Lấy chính teacher đã distil ra student để chấm student. Đây là vòng lặp tự khen khép kín: bạn tối ưu student cho khớp teacher, rồi hỏi teacher xem student có tốt không. Câu trả lời được biết trước. Đây là một ca Goodhart, không phải một bug — Module 07 mổ xẻ.

Cách phòng vệ không phải là "tìm một metric hoàn hảo". Không có. Cách phòng vệ là: giữ ít nhất một tầng đo mà bạn không tối ưu vào, và ngó nó định kỳ. Bậc ① và ② trong hình trên tồn tại chính vì lý do đó. Ở ca mục 3, tầng không bị tối ưu vào chỉ cần nhỏ bằng bộ 30 câu tên riêng: nó nói ngay B sai 9/30 câu, tức 30%, trong khi điểm chính vẫn khoe +4.85.

Kéo thử ở phòng thí nghiệm dưới đây trước khi đọc tiếp: tối ưu proxy từng bước và xem chỗ mục tiêu thật quay đầu.

5. Bốn tầng eval và chỗ đứng của từng tầng

Mọi câu hỏi về chất lượng đều trả lời được ở một trong bốn tầng. Việc của bạn là chọn tầng rẻ nhất còn trả lời được câu hỏi đang có — không phải tầng quen tay nhất.

Bảng dưới dùng một tình huống chuẩn để chi phí so sánh được: một vòng eval trên bộ 500 câu. Giả định, dùng chung đúng bộ đơn giá với Module 07 và Module 10: giải mã 12 câu/giây; GPU thuê 0.4 USD/giờ; tỉ giá 25 500 đ/USD; người chấm 45 giây/câu, hai người chấm độc lập, 204 000 đ/giờ (đúng 8 USD/giờ). Thêm một giả định nữa về lịch làm việc, vì chính nó quyết định cột độ trễ: mỗi người chỉ dành được 2 giờ mỗi ngày cho việc chấm, nên 6.25 giờ của mỗi người rải ra khoảng 3 ngày.

Con số 57 900 ở tầng 3 không rơi từ trên trời: nó lấy thẳng từ ca chạy tay ở mục 3. Giả sử 20 000 lượt đọc chương mỗi ngày, chia đôi cho hai nhánh, nhánh B kéo tỉ lệ chương sạch từ 53.14% xuống 11.76%. Mỗi ngày mất $10\,000 \times (0.531441 - 0.117649) = 4\,138$ lượt đọc trót lọt; chạy A/B đủ 14 ngày là 57 931 lượt. Đó là học phí thật của việc để tầng 1 tự quyết một mình.

Khoảng cách giữa hai tầng đầu đáng để cảm nhận bằng con số: với các giả định trên, một vòng tầng 2 đắt hơn một vòng tầng 1 khoảng 21 600 lần (2 550 000 đ so với 118 đ) và chậm hơn khoảng 6 200 lần (3 ngày so với 41.7 giây). Đó là lý do bạn không chấm người mỗi commit — và cũng là lý do bạn không được phép chỉ chạy tầng 1 suốt sáu tháng.

6. Vòng lặp cải tiến và khâu yếu nhất của nó

Toàn bộ công việc kỹ thuật của bạn là một vòng lặp bốn khâu, chạy đi chạy lại. Tốc độ tiến bộ của dự án bằng tốc độ vòng lặp này nhân với lượng thông tin thu được mỗi vòng. Hầu hết mọi người chỉ tối ưu vế đầu.

Làm rõ ý "khâu yếu nhất" bằng số. Giả sử một can thiệp điển hình của bạn tạo ra chênh lệch thật khoảng 0.4 điểm, còn phép đo hiện tại có sai số ±1.1 điểm (Module 03 dạy cách tính con số đó, Module 05 dạy cách thu nhỏ nó). Tỉ số tín hiệu trên nhiễu là $0.4/1.1 = 0.36$ — tín hiệu chỉ bằng khoảng một phần ba nhiễu.

Trong hai tuần, bạn chạy 12.2 vòng như thế. Mười hai lần bạn nhìn một con số, mười hai lần bạn tin rằng mình vừa học được điều gì đó về model. Thực tế bạn vừa quan sát nhiễu mười hai lần và kể cho mình nghe mười hai câu chuyện. Đó không phải lỗi kỷ luật — đó là lỗi độ phân giải, và không có sự chăm chỉ nào chữa được nó.

7. Bảy từ cả đội phải hiểu giống nhau

Phần lớn tranh cãi về kết quả eval thật ra là tranh cãi về từ vựng. Bảng này chốt nghĩa cho cả quyển; từ đây trở đi các module dùng đúng những nghĩa này.

Bảy từ này cộng lại thành một câu duy nhất mà phần còn lại của quyển sẽ khai triển: một score, sinh bởi một metric đã nêu tên, trên một eval set không bị nhiễm, so với một baseline đo cùng đợt, kèm sai số, và không vi phạm guardrail nào. Thiếu bất kỳ mảnh nào, thứ bạn có vẫn chỉ là một tin đồn có dấu thập phân.

Cần biết trước: Module 00 — ba câu hỏi trước mọi phép đo Dựng nên: khả năng đọc một con số BLEU và biết chính xác nó đo gì Dẫn tới: Module 02 — metric học được

1. Bài toán: nén một bản dịch thành một con số

Một câu nguồn tiếng Trung có vô số bản dịch tiếng Việt đúng. Bạn thì chỉ có một câu tham chiếu (reference) do người viết ra. Toàn bộ họ metric bề mặt sinh ra từ một thoả hiệp thô bạo: coi bản dịch là tốt nếu nó dùng lại nhiều đoạn chuỗi của tham chiếu.

Thoả hiệp đó phải trả giá, và bạn nên biết trước cái giá là gì. Nhưng nó mua được ba thứ mà không cách nào khác mua nổi: chi phí gần bằng không (chấm 800 câu mất dưới một giây), tất định (deterministic — chạy lại ra đúng số cũ), và không cần GPU. Đó là lý do metric n-gram vẫn sống sau hai mươi năm bị chê.

Cặp câu sau sẽ đi theo bạn suốt module. Ta cố tình chọn một câu web novel ngắn, đã tách token bằng khoảng trắng, đã viết thường, không dấu câu — để mọi phép đếm làm được bằng mắt.

Tham chiếu $y$ · hắn chậm rãi rút thanh kiếm ra khỏi vỏ · $r = 9$ token.
Bản dịch máy $\hat{y}$ · hắn rút thanh kiếm ra khỏi vỏ kiếm · $c = 8$ token.

Bản máy làm rơi chậm rãi, và thừa ra một chữ kiếm ở cuối — đúng kiểu lỗi lặp đuôi mà model NAR hay decode tham lam vẫn mắc. Hai lỗi đó sẽ bị hai cơ chế khác nhau của BLEU bắt: một cái bởi clipping, một cái bởi brevity penalty.

2. Precision n-gram, và bệnh "the the the"

Một n-gram là một cửa sổ $n$ token liên tiếp. Câu 8 token có 8 unigram, 7 bigram, 6 trigram, 5 four-gram — công thức là $\max(0,\, L - n + 1)$ với $L$ là độ dài câu.

Ý tưởng đầu tiên, ngây thơ: precision $=$ tỉ lệ n-gram của bản dịch có xuất hiện trong tham chiếu. Ý tưởng này hỏng ngay lập tức. Lấy tham chiếu con mèo ngồi trên tấm thảm và một bản dịch rác:

trên trên trên trên trên trên. Precision thô cho 6/6 = 100.0%. Precision có clipping cho 1/6 = 16.7%.

Sáu lần chữ trên đều "có trong tham chiếu", nên precision thô cho điểm tuyệt đối cho một câu vô nghĩa. Cách chữa gọi là clipping (cắt trần): mỗi n-gram chỉ được tính công tối đa bằng số lần nó xuất hiện trong tham chiếu. Tham chiếu có trên đúng một lần, nên năm lần còn lại là công cốc.

Áp vào cặp câu chính. Bản máy có kiếm hai lần, tham chiếu có một lần, nên $\min(2,1) = 1$: chữ kiếm thứ hai bị clip. Bảy unigram còn lại đều khớp.

3. Brevity penalty: vì sao BLEU cố tình không có recall

Nếu mẫu số luôn là bản dịch, thì cách gian lận hiển nhiên là dịch ít đi. Chỉ xuất ra kiếm — một token, chắc chắn có trong tham chiếu — và bạn được $p_1 = 100\%$.

Cách chữa "đúng" là thêm recall. BLEU không làm thế, vì thời nó ra đời người ta chấm với nhiều tham chiếu cùng lúc, và recall trên nhiều tham chiếu không có định nghĩa tự nhiên: bản dịch nên phủ tham chiếu nào? Thay vào đó BLEU dùng một hình phạt thô: nếu tổng độ dài bản dịch ngắn hơn tổng độ dài tham chiếu, nhân điểm với một hệ số nhỏ hơn 1.

Vài giá trị đáng thuộc lòng, để bạn ước lượng nhẩm được thiệt hại khi nhìn dòng ratio trong output của sacreBLEU:

4. Ghép lại — chạy tay trọn vẹn một ví dụ

Công thức đầy đủ, với $N = 4$ và trọng số đều $w_n = 1/4$:

Hãy nhìn kỹ bốn con số 87.5/71.4/66.7/60.0. Chúng luôn giảm dần khi $n$ tăng, và tốc độ giảm nói cho bạn biết nhiều hơn con số tổng: giảm chậm nghĩa là bản dịch giữ được cụm dài, giảm dốc nghĩa là nó chỉ nhặt đúng từ vựng mà đảo lộn trật tự.

Trước khi đọc tiếp, hãy tự gõ vài cặp câu vào bàn mổ dưới đây — đặc biệt là thử thêm/bớt một token ở cuối và xem bốn mức $p_n$ đổ theo kiểu gì.

5. corpus-BLEU không phải trung bình của sentence-BLEU

Đây là chỗ nhiều người báo cáo sai mà không biết. corpus-BLEU gộp tử số và mẫu số của toàn bộ corpus trước, rồi mới chia một lần. Nó không phải là trung bình cộng của điểm từng câu. Ba câu ngắn sau cho thấy khoảng cách:

Kiểm lại dòng cuối bằng tay: $p_1 = 19/22 = 0.8636$, $p_2 = 12/19 = 0.6316$, $p_3 = 9/16 = 0.5625$, $p_4 = 7/13 = 0.5385$. Trung bình nhân $= 0.6375$. $\text{BP} = e^{\,1-25/22} = 0.8725$. Tích $= 0.5563$, tức 55.63.

Trung bình cộng ba điểm câu thì ra $(62.40 + 0 + 75.06)/3 = \mathbf{45.82}$ — lệch gần 10 điểm. Thủ phạm là câu 2: nó nhận điểm 0 tuyệt đối chỉ vì không có nổi một trigram nào trùng, và trong trung bình cộng thì cái 0 đó đè nặng như một câu thật, trong khi ở corpus-BLEU nó chỉ đóng góp 5 trên tổng 22 unigram.

Vì thế mới cần smoothing khi bạn buộc phải chấm từng câu (để xếp hạng câu, để lọc data, để làm paired test ở Module 04). Phương pháp mặc định của sacreBLEU là exp: mức $n$ đầu tiên có tử số 0 thì thay $p_n$ bằng $\dfrac{1}{2^{k} \cdot \text{total}_n}$, với $k$ tăng dần 1, 2, 3… cho các mức 0 kế tiếp.

Áp cho câu 2: $p_3 = \dfrac{1}{2 \times 3} = 0.1667$ và $p_4 = \dfrac{1}{4 \times 2} = 0.125$. Trung bình nhân của $(0.8,\, 0.25,\, 0.1667,\, 0.125)$ là $0.2541$; nhân với $\text{BP} = e^{-0.4} = 0.6703$ ra 17.03. Trung bình cộng ba câu lúc này là 51.50 — vẫn khác 55.63, nhưng đã hết vô lý.

6. chrF: đếm n-gram ký tự thay vì n-gram từ

chrF đổi đơn vị đếm từ token sang ký tự, và khác BLEU ở ba điểm: nó bỏ hết khoảng trắng trước khi cắt n-gram, nó dùng tới 6 mức thay vì 4, và nó có recall. Điểm cuối quan trọng nhất: chrF là F-score, nên không cần brevity penalty.

Vì sao chrF hợp tiếng Việt hơn BLEU? Ba lý do rất cụ thể, minh hoạ bằng số:

Cả ba hàng đều là sentence-BLEU với smoothing exp. Hàng 2 có $p_4 = 0/5$, nên tắt smoothing thì nó bằng đúng 0.00 — chính là trường hợp mục 5 vừa dựng. Hai hàng còn lại không có mức nào bằng 0, bật hay tắt smoothing cũng ra cùng con số.

• Thanh điệu. Đổi kiếm thành kiêm là một lỗi rất nhỏ về mặt ký tự nhưng phá huỷ hoàn toàn một token. BLEU rơi từ 100 xuống 50.00, vì token đó nằm trong 1 unigram, 2 bigram, 3 trigram và 4 four-gram — bốn precision tụt còn 87.5/71.4/50.0/20.0. chrF2 chỉ xuống 86.32, vì kiếm và kiêm chung ba trong bốn ký tự.
• Từ ghép và ranh giới từ. Tiếng Việt viết rời âm tiết, nên thanh kiếm và trường kiếm với BLEU là hai token hoàn toàn khác nhau, còn với chrF chúng chia sẻ chuỗi kiếm. Điều này cũng khiến chrF gần như miễn nhiễm với chuyện bạn có chạy word segmentation hay không — trong khi BLEU thì nhảy vài điểm, xem mục 8.
• Hình vị Hán-Việt. Rất nhiều lỗi zh→vi là chọn sai một trong hai âm tiết Hán-Việt của một từ ghép. chrF cho điểm bán phần cho phần đúng; BLEU cho 0.

7. TER: đếm số thao tác sửa

TER (Translation Edit Rate) đo theo hướng ngược lại: một biên tập viên phải sửa bao nhiêu nhát để biến bản máy thành bản tham chiếu?

với $E$ là số thao tác tối thiểu và $|y|$ là số token của tham chiếu. Điểm thấp là tốt — ngược chiều BLEU và chrF, một nguồn nhầm lẫn kinh điển khi đọc bảng kết quả.

Bốn loại thao tác, mỗi cái tính giá 1 bất kể dài ngắn:

• Insertion — chèn một token còn thiếu. Trên cặp câu chính: chèn chậm, chèn rãi sau hắn → 2 thao tác.
• Deletion — bỏ một token thừa: xoá kiếm ở cuối → 1 thao tác.
• Substitution — đổi một token thành token khác. Không có trong ví dụ này.
• Shift — dời nguyên một khối liền kề sang vị trí khác, giá vẫn là 1. Không có trong ví dụ này.

Vậy $E = 2 + 1 = 3$, tham chiếu có 9 token, $\text{TER} = 3/9 = 0.3333$ → 33.33. sacreBLEU cho đúng con số đó.

Thao tác shift là thứ khiến TER khác hẳn khoảng cách Levenshtein thông thường, và cũng là thứ khiến nó đắt để tính (tìm tổ hợp shift tối ưu là bài toán NP-khó, mọi cài đặt đều dùng heuristic tham lam). Hình dưới cho thấy sự khác biệt:

8. Tokenization làm BLEU nhảy vài điểm — và sacreBLEU signature

BLEU đếm token. Ai định nghĩa token? Bạn. Và mọi lựa chọn đều cho ra một con số khác. Đây là cùng một cặp câu (lần này có dấu chấm và viết hoa), chấm bằng bốn cách tách token:

Từ 47.75 tới 69.54 trên đúng một cặp câu, chỉ vì đổi cách cắt chữ. Chênh lệch giữa hai dòng đầu là 8.7 điểm — lớn hơn mọi cải tiến kiến trúc mà bạn từng vất vả giành được. Đây là lý do tuyệt đối không được so con số BLEU của bạn với con số trong một bài báo khác, trừ khi hai bên dùng cùng một pipeline chấm.

sacreBLEU tồn tại để chấm dứt chuyện đó: nó nhận vào bản dịch chưa tách token, tự tách theo một chuẩn cố định, và in kèm một signature mô tả toàn bộ cấu hình. Ba signature thật, lấy từ sacreBLEU 2.6.0:

BLEU   nrefs:1|case:mixed|eff:no|tok:13a|smooth:exp|version:2.6.0
chrF2  nrefs:1|case:mixed|eff:yes|nc:6|nw:0|space:no|version:2.6.0
TER    nrefs:1|case:lc|tok:tercom|norm:no|punct:yes|asian:no|version:2.6.0

Đọc từng trường của dòng BLEU: nrefs:1 — một tham chiếu; case:mixed — phân biệt hoa thường; eff:no — không dùng effective order (mức $n$ nào không có n-gram thì vẫn tính là 0, chứ không bỏ qua); tok:13a — tokenizer; smooth:exp — smoothing dùng khi cần. Hai chữ ký khác nhau ở bất kỳ trường nào cũng đủ để hai con số không so được.

# ref.vi và hyp.vi: mỗi dòng một câu, KHÔNG tách token trước, UTF-8
$ sacrebleu ref.vi -i hyp.vi -m bleu chrf ter --format text
        BLEU|nrefs:1|case:mixed|eff:no|tok:13a|smooth:exp|version:2.6.0 = 56.5 88.9/62.5/57.1/50.0 (BP = 0.895 ratio = 0.900 hyp_len = 9 ref_len = 10)
      chrF2|nrefs:1|case:mixed|eff:yes|nc:6|nw:0|space:no|version:2.6.0 = 67.6
TER|nrefs:1|case:lc|tok:tercom|norm:no|punct:yes|asian:no|version:2.6.0 = 44.4

# chỉ lấy con số, 2 chữ số thập phân, để nhét vào script CI.
# Một metric thì -b in số trần; nhiều metric cùng lúc thì nó in một danh sách có ngoặc vuông và dấu phẩy.
$ sacrebleu ref.vi -i hyp.vi -m bleu -b -w 2
56.48

# chrF++ : thêm 2-gram TỪ vào bên cạnh n-gram ký tự, thường bám điểm người sát hơn
$ sacrebleu ref.vi -i hyp.vi -m chrf --chrf-word-order 2 --format text

# JSON để log lại cùng commit hash — luôn lưu cả signature, không chỉ score
$ sacrebleu ref.vi -i hyp.vi -m bleu --format json

Cần biết trước: Module 01, và khái niệm embedding (quyển Mạng Nơ-ron đã dựng) Dựng nên: tiêu chí chọn metric, và cách đo chất lượng của chính metric Dẫn tới: Module 03 — sai số của một con số

1. Bốn chỗ mù của n-gram

Module 01 để lại một khoảng trống rất lớn: BLEU chỉ biết đếm chuỗi ký tự trùng nhau. Nó không có khái niệm "nghĩa". Bốn hệ quả, kèm ví dụ thật của thể loại tiên hiệp:

1. Đồng nghĩa. Tham chiếu hắn lạnh lùng mỉm cười, bản dịch gã cười nhạt một cách lạnh lẽo. Hai câu gần như cùng nghĩa. Số 1-gram trùng sau clipping: đúng 2 trên 7 token của bản dịch, tức precision 1-gram $= 2/7 = 0.286$. Số 2-gram trùng: 0. Vì BLEU lấy trung bình nhân qua 4 mức n, một mức bằng 0 kéo cả tích về 0. Một bản dịch tốt bị chấm 0 điểm.
2. Trật tự tự do. Tiếng Việt cho phép đảo trạng ngữ: sáng hôm sau, hắn xuống núi và hắn xuống núi vào sáng hôm sau. Cùng nghĩa, cùng bộ 1-gram, nhưng bộ 3-gram và 4-gram lệch hẳn.
3. Một câu có nhiều bản đúng. Bạn thường chỉ có một tham chiếu. Mọi cách diễn đạt đúng khác đều bị tính là sai. Đây là lỗi hệ thống, không phải nhiễu: nó luôn kéo điểm xuống, không bao giờ kéo lên.
4. Lỗi nặng nhẹ như nhau. Dịch ba nghìn lạng bạc thành hai nghìn lạng bạc làm sai một token. Dịch hắn thành gã cũng sai một token. BLEU trừ điểm y hệt nhau, dù lỗi thứ nhất phá vỡ cốt truyện còn lỗi thứ hai thì người đọc không nhận ra.

Metric học được (learned metric) ra đời để vá ba lỗi đầu. Cần nói thẳng ngay từ đây: chúng gần như không vá được lỗi thứ tư — mục 5 sẽ tính ra con số cụ thể cho chuyện đó.

2. BERTScore: ghép tham lam trên ma trận cosine

Ý tưởng ngắn gọn tới mức có thể viết trong một câu: thay vì so token với token bằng phép bằng nhau, hãy so vector với vector bằng cosine, rồi mỗi token đi tìm bạn giống mình nhất ở phía bên kia.

Cụ thể, cho câu tham chiếu $r$ có $|r|$ token và bản dịch $\hat{c}$ có $|\hat{c}|$ token. Đưa cả hai qua một encoder (BERT, XLM-R, PhoBERT…) để lấy vector ngữ cảnh $v_i$ cho từng token. Rồi:

# hàng j = token bản dịch, cột i = token tham chiếu
M = [[0.86, 0.22, 0.14],
     [0.18, 0.71, 0.20],
     [0.21, 0.95, 0.17]]

P  = sum(max(hang) for hang in M) / len(M)          # cực đại theo hàng
R  = sum(max(cot) for cot in zip(*M)) / len(M[0])   # cực đại theo cột
F1 = 2 * P * R / (P + R)
print(f"P={P:.3f}  R={R:.3f}  F1={F1:.3f}")         # P=0.840  R=0.670  F1=0.745

w = [0.9, 0.4, 1.7]                                 # idf của hắn / cười / lạnh
R_idf = sum(wi * max(cot) for wi, cot in zip(w, zip(*M))) / sum(w)
print(f"R_idf={R_idf:.3f}")                         # R_idf=0.498

Phần khó của BERTScore không nằm ở công thức — nó nằm ở việc chọn encoder nào và lấy vector ở tầng nào. Đó là hai siêu tham số ẩn, và đổi chúng là đổi luôn thang điểm.

3. COMET: hồi quy thẳng lên điểm người

BERTScore vẫn là một công thức do người viết ra: nó giả định rằng cosine trung bình là thứ tương ứng với chất lượng. COMET bỏ hẳn giả định đó và hỏi một câu khác: nếu ta đã có hàng chục nghìn câu được người chấm điểm, sao không huấn luyện thẳng một model dự đoán điểm đó?

Đầu vào có ba phần chứ không phải hai: câu nguồn $s$ (tiếng Trung), bản dịch máy $h$, và bản tham chiếu $r$. Ba câu đi qua cùng một encoder đa ngữ, thành ba vector, rồi được ghép thành đặc trưng và đưa qua một MLP nhỏ cho ra một số thực. Đặc trưng đó chứa cả tích và hiệu của $h$ với $s$ chứ không chỉ với $r$ — đúng chỗ đó là thứ BERTScore không có: nó không bao giờ nhìn câu nguồn. Hàm mất mát là bình phương sai lệch so với điểm người:

Điểm người $y$ đến từ hai nguồn quen thuộc: DA (direct assessment — người kéo thanh trượt 0–100) và MQM (multidimensional quality metrics — người đánh dấu từng lỗi kèm mức độ nặng nhẹ rồi quy ra điểm phạt). Module 06 sẽ dựng hai thang này tử tế; ở đây chỉ cần biết chúng là nhãn của bài toán hồi quy.

Bỏ ô ref đi thì được bản QE (quality estimation, ước lượng chất lượng không tham chiếu): chỉ cần câu nguồn và bản dịch. Đây là thứ duy nhất trong cả module này dùng được trên dữ liệu production — toàn bộ kho chương web novel bạn đã dịch ra và không hề có bản người dịch để đối chiếu (giả sử kho đó cỡ 40 nghìn chương). Đổi lại, nó dễ bị lừa bởi bản dịch trôi chảy nhưng sai nghĩa, vì không có gì neo nó vào nội dung đúng.

BLEURT đứng giữa hai họ trên: cũng là hồi quy lên điểm người, nhưng thêm một giai đoạn tiền huấn luyện trên hàng triệu cặp câu tổng hợp — lấy câu gốc rồi cố tình làm hỏng (xoá từ, đảo chữ, dịch vòng) và gán nhãn bằng chính BLEU/ROUGE. Nhờ đó nó bớt đói dữ liệu người. Về mặt sử dụng, bạn đối xử với BLEURT hệt như COMET: một model, có miền huấn luyện, có ngày hết hạn.

4. Đo chính metric: Pearson, Spearman, Kendall

Đây là mục quan trọng nhất module, và là mục hầu hết người dùng metric bỏ qua. Một metric học được không tự nhiên đúng. Nó là một ước lượng, và bạn phải kiểm nó y như kiểm một model: lấy một bộ câu đã có điểm người, chạy metric, rồi đo xem hai dãy số bám nhau tới đâu.

Có ba hệ số, và chúng trả lời ba câu hỏi khác nhau:

• Pearson $r$ — hai dãy có quan hệ tuyến tính tới đâu. Nhạy với dạng hàm và với điểm ngoại lai.
• Spearman $\rho$ — chính là Pearson tính trên hạng thay vì trên giá trị. Chỉ quan tâm thứ tự.
• Kendall $\tau$ — đếm tỉ lệ cặp được xếp đúng chiều. Gần nhất với câu hỏi thực tế của bạn.

Ba hệ số phản ứng rất khác nhau trước cùng một thay đổi dữ liệu. Hai thí nghiệm trên đúng bộ 6 câu ở trên:

• Biến đổi đơn điệu. Thay điểm metric bằng lập phương của nó (thứ tự giữ nguyên tuyệt đối): Pearson nhảy từ $0.7027$ lên $\mathbf{0.7966}$, còn $\rho$ và $\tau$ không đổi một chút nào. Tức là bạn có thể "cải thiện" Pearson bằng cách calibrate lại metric mà không làm nó thông minh hơn một tí nào.
• Một điểm ngoại lai. Chỉ hạ điểm metric của s5 từ 0.35 xuống 0.05 (thứ tự vẫn nguyên): Pearson rơi từ $0.7027$ xuống $\mathbf{0.5189}$, mất $0.184$ — vì một câu. $\rho$ và $\tau$ lại không đổi.

Kết luận thực dụng: để chọn metric, dùng $\tau$ hoặc accuracy trên cặp. Chỉ dùng Pearson khi bạn thật sự quan tâm tới giá trị tuyệt đối của điểm, ví dụ khi đặt ngưỡng "COMET dưới 0.6 thì chuyển cho người biên tập". Nhắc lại phạm vi: $\tau$ giúp bạn chọn metric, còn chọn checkpoint thì vẫn phải chạy kiểm định ghép cặp ở Module 04 trên chính bộ test của bạn.

Kéo thử cụm điểm ba chiều dưới đây — xoay nó để thấy ba hệ số cùng thay đổi khi bạn kéo một câu ra khỏi đám mây, trước khi đọc tiếp.

5. Khi metric học được gãy

Bây giờ tới chỗ khó chịu. Hãy quay lại chỗ mù thứ tư của mục 1 và tính ra con số.

Đây không phải lỗi cài đặt mà là hệ quả trực tiếp của thiết kế: BERTScore trung bình hoá trên token, nên mọi lỗi đều bị pha loãng theo $1/n$, và encoder được huấn luyện để đặt các con số gần nhau trong không gian vector. COMET đỡ hơn vì nó học từ MQM (thang MQM có severity, nên critical error bị phạt nặng trong nhãn), nhưng chỉ đỡ hơn theo mức mà dữ liệu huấn luyện của nó đã dạy.

Danh sách các chỗ metric học được thường gãy, xếp theo mức nguy hiểm với dự án web novel zh→vi:

• Tên riêng và danh xưng. Diệp Phàm vs Diệp Phong — hai vector rất gần, người đọc thì mất mạch truyện ngay. Phải bắt bằng luật riêng, không giao cho metric.
• Con số, đơn vị, ngày tháng. Như vừa tính: chi phí gần bằng 0.
• Câu quá ngắn. Với câu 3 token, một token hỏng chiếm $1/3$ trọng số; phương sai của điểm câu tăng vọt. Đối thoại web novel đầy câu 2–4 âm tiết.
• Ngoài miền huấn luyện. COMET được train chủ yếu trên tin tức và văn bản chung. Tiên hiệp có hệ thuật ngữ riêng (cảnh giới tu luyện, pháp bảo, xưng hô sư huynh/đạo hữu) mà model chấm chưa từng thấy trong dữ liệu DA.
• Ngôn ngữ ít tài nguyên. Tiếng Việt có mặt trong các encoder đa ngữ nhưng với tỉ trọng nhỏ hơn hẳn tiếng Anh hay tiếng Đức. Chất lượng biểu diễn kém hơn kéo theo metric kém hơn — và bạn không nhìn thấy điều đó từ bên trong.
• Không truy ngược được. BLEU sai thì bạn xem được n-gram nào trượt. COMET cho 0.42 thì bạn không biết vì sao. Debug bằng một số vô hướng là debug mù.

6. Chọn metric nào cho zh→vi

Bảng dưới đây tổng hợp bốn họ metric theo năm tiêu chí quyết định. Cột chi phí là con số minh hoạ, tính từ giả định thông lượng cho một bộ test 2000 câu: BLEU 2000 câu/s và chrF 1200 câu/s trên CPU, BERTScore 300 câu/s và COMET 40 câu/s trên một GPU, COMET 2.5 câu/s nếu chỉ có CPU. Máy của bạn sẽ khác, nhưng bậc độ lớn thì đúng.

Đọc bảng theo cột chi phí: COMET trên GPU đắt hơn BLEU 50 lần, còn COMET trên CPU đắt hơn 800 lần. Con số 800 mới là con số quyết định kiến trúc: nó là ranh giới giữa "chạy được mỗi commit" và "chạy được mỗi tuần".

Từ đó ra một cách bố trí ba tầng, mỗi tầng một mục đích:

1. Vòng lặp nhanh (mỗi commit, mỗi eval trong lúc train). chrF làm metric chủ — rẻ, không cần GPU, hợp tiếng Việt hơn BLEU vì bắt được thanh điệu và từ ghép. Thêm BLEU chỉ để so với số cũ trong sổ.
2. Nghiệm thu một checkpoint ứng viên (vài lần mỗi tuần). COMET có reference trên bộ test cố định, cộng chrF. 50 giây GPU là chấp nhận được. Nếu hai metric mâu thuẫn nhau, đó là tín hiệu bắt buộc phải mở mắt người ra xem.
3. Giám sát production (dữ liệu không có bản người dịch). COMET-QE trên một mẫu ngẫu nhiên các chương đã dịch, cộng một bộ luật cứng bắt tên riêng và con số. Metric ở tầng này không dùng để chấm điểm, nó dùng để xếp hàng đợi cho biên tập viên.

Và một quy tắc chung, đúng cho cả ba tầng: báo cáo ít nhất hai metric thuộc hai họ khác nhau — một metric bề mặt và một metric học được. Khi cả hai cùng lên, bạn có bằng chứng. Khi chúng lệch nhau, bạn có một câu hỏi hay, và câu hỏi hay đáng giá hơn một con số đẹp.

Cần biết trước: Module 01 (BLEU, chrF) Dựng nên: khoảng tin cậy cho mọi con số bạn báo cáo Dẫn tới: Module 04 — so hai hệ thống

1. Con số bạn báo cáo là một biến ngẫu nhiên

Bạn chạy eval, ra chrF = 54.29. Chạy lại lần nữa với đúng model đó, đúng bộ test đó, ra đúng 54.29. Cảm giác chắc chắn đó là ảo giác: bạn vừa lặp lại một phép đo, không phải lặp lại thí nghiệm.

Có ít nhất ba nguồn phương sai (variance) làm con số ấy lung lay, và chỉ nguồn thứ nhất là thứ hầu hết mọi người từng nghĩ tới:

1. Chọn mẫu test. 500 câu của bạn là một mẫu bốc ra từ biển web novel. Bốc 500 câu khác, điểm khác.
2. Seed khởi tạo và thứ tự data. Cùng công thức, đổi seed, model ra khác. Đây là phương sai của quy trình huấn luyện, không phải của bộ test.
3. Ngẫu nhiên khi giải mã. Sampling, nucleus, thậm chí thứ tự batch khi inference và sai số dấu phẩy động của kernel int8 cũng đủ làm vài câu đổi.

Ba nguồn cộng theo phương sai chứ không theo độ lệch chuẩn. Với bộ test 500 câu mà ta sẽ dùng suốt module này, phần do chọn mẫu tính được là $0.564$ điểm chrF. Giả sử thêm phần seed là $0.30$ và phần giải mã là $0.15$ — hai con số này là giả định để minh hoạ, không phải đo được — thì:

Tức là chỉ tính nguồn (1) bạn báo ±1.10; tính đủ ba nguồn thì phải báo ±1.29. Bỏ qua seed và decode làm khoảng của bạn hẹp đi 14.1% — nó khiến bạn tự tin hơn thực tế. Đóng góp phương sai: chọn mẫu 73.8%, seed 20.9%, decode 5.2%.

2. Bạn đang đo mẫu, không đo tổng thể

Cần tách bạch hai thứ hay bị gọi chung một tên:

• $\theta$ — tham số tổng thể (population parameter): điểm chrF trung bình mà model của bạn sẽ đạt trên toàn bộ văn bản web novel zh→vi trên đời. Bạn không bao giờ biết nó.
• $\hat{\theta}$ — ước lượng (estimate): điểm đo trên 500 câu bạn có. Bạn biết nó chính xác tới từng chữ số, và nó gần như chắc chắn khác $\theta$.

Để nhìn thấy khoảng cách đó, cả module này dùng một tổng thể giả lập nhưng đã biết trước: điểm chrF từng câu tuân theo phân phối Beta$(7.9,\,6.7)$ nhân 100. Ta biết chắc $\theta = 54.11$ và $\sigma = 12.62$. Bốc ra 500 câu bằng np.round(100*default_rng(109).beta(7.9, 6.7, 500), 2) được bộ test dùng suốt bài — bạn tái tạo lại y hệt được:

Ở đây $s$ là độ lệch chuẩn mẫu (sample standard deviation) của 500 điểm câu — căn bậc hai của $\frac{1}{n-1}\sum (x_i - \bar{x})^2$. Nó đo độ tản mát của từng câu, chưa nói gì về độ tản mát của điểm corpus. Lệch $0.18$ điểm so với sự thật, và bạn sẽ không bao giờ biết độ lệch đó nếu đây là dữ liệu thật. Điểm câu trải từ $17.75$ tới $85.91$ — độ tản mát ở cấp câu khổng lồ so với chênh lệch giữa hai bản model mà bạn thường tranh cãi.

3. Chạy tay: chia 500 câu thành 5 khối 100 câu

Trước khi động tới công thức nào, làm việc này bằng tay. Cắt 500 câu theo thứ tự thành 5 khối 100 câu, tính điểm trung bình mỗi khối. Không lấy mẫu lại, không thống kê — chỉ chia và cộng.

Đọc bảng này chậm lại một chút. Cùng một model, cùng một domain, không đổi một dòng code nào: điểm nhảy từ 52.75 tới 56.08 — biên độ 3.33 điểm chrF. Nếu khối 2 là bộ test của đối thủ và khối 1 là bộ test của bạn, bạn "thắng" 3.33 điểm mà không làm gì cả.

So sánh với thứ người ta hay khoe: "bản mới hơn 0.4 điểm". Chênh lệch 0.4 chỉ bằng 1/8 biên độ dao động thuần tuý do đổi 100 câu test ($3.33 / 0.4 = 8.3$). Đó là toàn bộ luận đề của quyển sách này, gói trong một bảng.

Trung bình 5 điểm khối đúng bằng 54.29 (hiển nhiên, vì các khối bằng nhau). Giờ đọc cột thứ hai theo chiều dọc: năm con số ấy có độ lệch chuẩn $1.378$, trong khi độ tản mát của từng câu là $s = 12.60$ — nhỏ hơn $12.60/1.378 = 9.14$ lần. Mỗi khối gồm 100 câu, và $\sqrt{100} = 10$. Quy luật $1/\sqrt{n}$ không phải thứ bạn phải tin vì có ai đó bảo thế: nó vừa rơi thẳng ra khỏi bảng bạn tự cộng. Trung bình của $n$ câu tản mát ít hơn một câu đơn lẻ chừng $\sqrt{n}$ lần, và đại lượng $s/\sqrt{n}$ ấy có tên riêng — sai số chuẩn (standard error) của ước lượng.

Khớp tới đâu thì phải nói thẳng: công thức cho $s/\sqrt{100} = 1.260$, số đo được là $1.378$, tỉ số $1.378/1.260 = 1.09$ — lệch 9%. Với vỏn vẹn 5 quan sát thì 9% là mức chênh hoàn toàn bình thường, nhưng nó cũng nói luôn rằng con số $1.378$ quá nhiễu để đem ra làm sai số. Năm điểm khối đó là một mẫu bé xíu rút từ phân phối mẫu (sampling distribution) của $\hat{\theta}$: phân phối của điểm corpus khi bạn lặp đi lặp lại việc bốc một bộ test mới cùng cỡ rồi chấm lại. Đó đúng là thứ bạn cần biết, và cũng đúng là chỗ bí — dựng nó cho tử tế cần hàng nghìn bộ test, mà bạn chỉ có một.

4. Bootstrap: bốc lại có hoàn lại từ chính mẫu của bạn

Mục này chế ra đúng thứ vừa thiếu: một bản xấp xỉ của phân phối mẫu, dựng từ vỏn vẹn một bộ test. Ý tưởng của bootstrap (bootstrap resampling) gọn tới mức thấy vô lý: nếu 500 câu của bạn là ảnh đại diện tốt của tổng thể, thì bốc lại từ chính 500 câu đó gần giống bốc một bộ test mới từ tổng thể. Bốc $n$ lần có hoàn lại (with replacement) để mỗi mẫu bootstrap vẫn có đúng $n$ câu, nhưng câu này lặp hai lần, câu kia vắng mặt.

Con số làm việc đó cụ thể: xác suất một câu không được bốc lần nào là $(1 - 1/500)^{500} = 0.3675$. Nên mỗi mẫu bootstrap chỉ chứa khoảng 316 câu khác nhau trong 500 — đúng 63.2%, phần còn lại là bản sao. Đo thật trên 5 vòng đầu: 311, 316, 322, 313, 309 câu khác nhau. Riêng vòng 1 có 189 câu vắng mặt và một câu bị bốc trúng 5 lần.

Viết lại thành thuật toán cho bộ 500 câu — sáu dòng, chạy được nguyên văn:

import numpy as np
rng = np.random.default_rng(0)                        # cố định seed để lặp lại được
x = np.loadtxt("diem_cau.txt")                        # 500 điểm chrF, mỗi câu một dòng
idx = rng.integers(0, len(x), size=(1000, len(x)))    # B=1000 vòng, mỗi vòng bốc lại n chỉ số
means = x[idx].mean(axis=1)                           # 1000 điểm corpus giả lập
print(round(x.mean(), 2), np.round(np.percentile(means, [2.5, 97.5]), 2))
# 54.29 [53.21 55.35]

Dòng 4 là toàn bộ linh hồn: ma trận chỉ số $1000 \times 500$, mỗi hàng là một bộ test giả lập. Dòng 5 biến nó thành 1000 điểm corpus. Dòng 6 cắt hai đầu.

Kéo thử ở phòng thí nghiệm dưới đây trước khi đọc tiếp — bấm từng vòng một để thấy histogram mọc dần.

5. Khoảng tin cậy percentile 95% — và cách đọc nó cho đúng

Có 1000 điểm bootstrap $\hat{\theta}^{*(1)},\dots,\hat{\theta}^{*(B)}$. Sắp xếp tăng dần, cắt bỏ 2.5% mỗi đầu:

Giờ tới phần mà gần như ai cũng đọc sai. Câu SAI là:

"Có 95% xác suất giá trị thật $\theta$ nằm trong đoạn [53.21, 55.35]."

Sai ở đâu? Trong khung tần suất, $\theta$ là một hằng số — ở đây ta còn biết nó bằng đúng $54.11$. Một hằng số hoặc nằm trong một đoạn cố định, hoặc không. Xác suất của mệnh đề đó là 0 hoặc 1, không bao giờ là 0.95. Đoạn $[53.21, 55.35]$ này chứa $54.11$: xác suất bằng 1.

Con số 95% thuộc về quy trình, không thuộc về đoạn. Nói cho đúng: nếu lặp lại toàn bộ thí nghiệm rất nhiều lần — mỗi lần bốc một bộ test 500 câu mới và tính lại khoảng theo đúng cách này — thì khoảng 95% số khoảng thu được sẽ chứa $\theta$. Đoạn cụ thể bạn đang cầm trong tay chỉ là một vé trong lô vé đó.

Đây là loại khẳng định kiểm chứng được, nên hãy kiểm. Mô phỏng 2000 lần thí nghiệm, mỗi lần bốc 500 câu mới từ tổng thể đã biết rồi chạy bootstrap $B = 1000$: 1901/2000 = 95.05% số khoảng chứa $\theta = 54.11$, bề rộng trung bình $2.20$. Đúng như hứa hẹn.

6. Bao nhiêu vòng $B$ là đủ

Có hai nguồn sai số chồng lên nhau, và người mới hay lẫn:

• Sai số thống kê — do bạn chỉ có 500 câu. Giảm nó phải tăng $n$. Đây là nửa bề rộng $1.07$.
• Sai số Monte Carlo — do bạn chỉ chạy $B$ vòng bốc lại thay vì vô hạn. Giảm nó chỉ tốn CPU.

Sai số Monte Carlo của một biên là sai số của một phân vị mẫu, xấp xỉ bằng

Ta có thể vừa dùng công thức vừa đo thẳng: lặp lại toàn bộ bootstrap nhiều lần trên cùng 500 câu và xem hai biên nhảy bao nhiêu.

Cột "đo" lấy từ 4000 lần lặp cho $B = 100$ và $B = 1000$, và 800 lần cho $B = 10\,000$. Ba điều đáng nhớ:

1. Quy luật $1/\sqrt{B}$. Tăng $B$ gấp 10 chỉ giảm nhiễu $\sqrt{10} \approx 3.16$ lần — đo được $0.047/0.015 = 3.13$, khớp. Riêng nhịp $100 \to 1000$ chỉ được $0.134/0.047 = 2.85$: ở $B = 100$ công thức tiệm cận đã hết chuẩn (nó dự đoán $0.150$, thực tế $0.134$), vì phân vị lúc đó chỉ tựa lên vài phần tử rời rạc.
2. $B$ nhỏ làm khoảng hẹp giả. Bề rộng kỳ vọng ở $B=100$ là $2.113$, ở $B=10\,000$ là $2.205$ — thiếu 4.2%. Với $B = 100$, biên 2.5% là nội suy giữa phần tử nhỏ thứ 3 và thứ 4 ($0.025 \times 99 = 2.475$); toàn bộ biên dưới của bạn đang tựa lên đúng hai con số. Với $B = 1000$ thì là giữa phần tử 25 và 26 — vẫn ít, nhưng đuôi đã đủ dày.
3. Chạy thật $B = 100$ với sáu seed khác nhau trên cùng 500 câu cho sáu khoảng: $[53.22, 55.30]$, $[53.26, 55.37]$, $[53.33, 55.46]$, $[53.28, 55.10]$, $[53.20, 55.57]$, $[53.12, 55.33]$. Biên trên nhảy từ $55.10$ tới $55.57$ — 0.47 điểm chỉ vì đổi seed của thư viện random.

Khuyến nghị vận hành: $B = 1000$ cho vòng lặp phát triển hằng ngày, $B = 10\,000$ cho con số đưa vào báo cáo hay bài viết. Bootstrap 10000 vòng trên 500 câu chỉ là 5 triệu phép cộng — dưới một giây. Không có lý do gì để tiết kiệm ở đây.

7. Báo cáo cho đúng: 54.3 ± 1.1 chứ không 54.2935

Quy tắc làm tròn rút gọn thành hai bước: (1) làm tròn nửa bề rộng khoảng về một hoặc hai chữ số có nghĩa; (2) làm tròn ước lượng về đúng hàng đó. Ở đây nửa bề rộng $1.0741 \to 1.1$, nên $54.2935 \to 54.3$.

Một mẹo kiểm tra nhanh cho mọi bảng kết quả bạn sắp gửi đi: che cột điểm lại, hỏi "nếu tôi bốc bộ test khác thì con số này còn giữ được mấy chữ số?". Với $n = 500$ và $s \approx 12.6$, câu trả lời là ba chữ số — hàng chục, hàng đơn vị, và một chữ số thập phân đã là ranh giới. Muốn thêm một chữ số nữa thì phải tăng $n$ gấp 100 lần. Muốn chỉ giảm một nửa sai số thôi cũng cần $n = 2000$ (nửa bề rộng còn $0.55$).

Cần biết trước: Module 03 — phương sai, bootstrap, khoảng tin cậy Dựng nên: câu trả lời có căn cứ cho "bản mới có hơn không" Dẫn tới: Module 05 — cỡ mẫu và power

1. "Hơn 0.4 BLEU" là một câu không có nội dung

Bạn train xong bản mới. Bộ test 500 câu. Bản cũ 33.8 BLEU, bản mới 34.2 BLEU. Bạn viết vào changelog: "cải thiện 0.4 BLEU". Câu đó có nội dung không?

Module 03 đã cho bạn công cụ trả lời. Giả sử hiệu điểm theo từng câu có độ lệch chuẩn $\sigma_d = 8$ điểm (con số này bạn phải tự đo trên bộ test của mình, đừng chép của ai). Sai số chuẩn của trung bình hiệu là:

Chênh lệch quan sát 0.4 chia cho 0.358 được 1.118 — chưa tới hai lần sai số. Khoảng tin cậy 95% của chênh lệch là $0.4 \pm 1.96 \times 0.358$, tức [−0.30, 1.10]. Khoảng này chứa số 0. Nói cách khác: dữ liệu của bạn hoàn toàn tương thích với giả thuyết "hai bản như nhau", và cũng tương thích với "bản mới hơn 1.1 điểm". Bạn không biết gì cả.

Với đúng bộ test 500 câu đó, chênh lệch quan sát được nhỏ nhất còn cho $p < 0.05$ là $1.96 \times 0.358 = 0.70$ điểm. Mọi con số dưới ngưỡng đó là tiếng ồn được đặt tên. Nhưng đây mới là ngưỡng ý nghĩa, chưa phải ngưỡng nhìn thấy được: một chênh lệch thật đúng bằng 0.70 chỉ bị bắt 50% số lần — đúng bằng tung đồng xu. Chênh lệch nhỏ nhất bắt được 80% số lần là 1.00 điểm, nó có tên là MDE và Module 05 lo.

2. Ghép cặp là vũ khí rẻ nhất và mạnh nhất

Đây là ý quan trọng nhất của cả module. Hai hệ thống dịch cùng một bộ câu nguồn. Câu nào khó thì khó cho cả hai; câu nào có tên riêng lạ thì cả hai cùng vấp. Phần lớn dao động của điểm là do câu, không phải do hệ thống.

Nên đừng so hai đống điểm. Hãy so hiệu ghép cặp (paired difference): với câu thứ $i$, đặt $d_i = b_i - a_i$, rồi làm việc trên dãy $d_1, \dots, d_n$. Phương sai của hiệu là:

Dưới đây là dữ liệu ta sẽ dùng suốt phần còn lại của module: sáu câu trích từ một chương truyện tu tiên, chấm bằng chrF điểm câu. Sáu câu là quá ít cho một quyết định thật — nhưng vừa đủ để chạy tay mọi phép tính đến chữ số cuối cùng.

Độ lệch chuẩn mẫu: hệ A là 12.73, hệ B là 10.14, còn dãy hiệu chỉ 2.89. Tương quan Pearson giữa hai cột điểm là $r_{AB} = 0.994$ — hai hệ gần như xếp hạng độ khó y hệt nhau. Đó chính là thứ ghép cặp đem ra tiêu.

3. Paired bootstrap resampling

Module 03 đã dựng bootstrap cho một con số. Ở đây chỉ đổi đúng một chi tiết: đơn vị được lấy mẫu lại là câu, không phải điểm. Bốc chỉ số câu có hoàn lại, và mỗi lần bốc thì cặp (điểm A, điểm B) của câu đó đi cùng nhau. Nhờ vậy cấu trúc ghép cặp được giữ nguyên qua từng vòng.

import random
from statistics import mean

diem_a = [31.4, 42.0, 18.6, 55.3, 27.9, 39.5]   # he A, chrF tung cau
diem_b = [35.0, 41.2, 25.1, 54.0, 30.4, 41.8]   # he B tren DUNG nhung cau do
d = [y - x for x, y in zip(diem_a, diem_b)]     # hieu theo tung cau
obs = mean(d)

random.seed(4)
n, B = len(d), 10000
vong = []
for _ in range(B):
    # boc lai co hoan lai THEO CHI SO CAU -> cap (A,B) luon di cung nhau
    mau = [d[random.randrange(n)] for _ in range(n)]
    vong.append(mean(mau))

vong.sort()
lo, hi = vong[int(0.025 * B)], vong[int(0.975 * B)]
thua = sum(1 for m in vong if m <= 0) / B

print(f"hieu quan sat   = {obs:+.3f}")     # +2.133
print(f"CI 95%          = [{lo:+.3f}, {hi:+.3f}]")   # [+0.100, +4.200]
print(f"ti le vong <= 0 = {thua:.4f}")     # 0.0161

Kết quả: chênh lệch +2.133, khoảng tin cậy 95% là [+0.100, +4.200], và chỉ 1.61% số vòng bootstrap cho hệ B thua hoặc hoà. Nhân đôi cho hai phía được $p \approx 0.032$. Nghe như đã thắng.

Giữ con số 0.032 đó trong đầu. Mục sau sẽ tính chính xác cùng một câu hỏi và ra một đáp án khác hẳn.

4. Permutation test: đếm hết 64 khả năng

Bootstrap mô phỏng "nếu ta lấy một bộ test khác thì sao". Permutation test (bản liệt kê đủ gọi là exact randomization test; bản bốc ngẫu nhiên ở cuối mục này mới là approximate randomization) hỏi một câu khác và sắc hơn: nếu hai hệ thật ra như nhau, thì dữ liệu trông sẽ thế nào?

Nếu hai hệ như nhau thì nhãn "A" và "B" gắn lên hai bản dịch của một câu là tuỳ tiện — đổi chỗ chúng, thế giới không đổi. Đổi chỗ hai nhãn ở câu $i$ chính là đổi dấu $d_i$. Với 6 câu có $2^6 = 64$ cách gán dấu, mỗi cách xác suất bằng nhau là $1/64$. Đó là toàn bộ phân phối rỗng (null distribution), liệt kê được hết, không cần giả định gì về hình dạng phân phối.

from itertools import product
from statistics import mean

d = [3.6, -0.8, 6.5, -1.3, 2.5, 2.3]
obs = mean(d)
dem = sum(1 for s in product([+1, -1], repeat=len(d))
          if abs(mean([si * di for si, di in zip(s, d)])) >= abs(obs) - 1e-9)
print(dem, "/", 2 ** len(d), "=", dem / 2 ** len(d))   # 8 / 64 = 0.125

Khi $n$ lớn, liệt kê hết là bất khả: $2^{500} \approx 3.3 \times 10^{150}$. Thay bằng Monte Carlo — đây mới đúng là approximate randomization: bốc ngẫu nhiên $R = 10000$ vector dấu, đếm $b$ lần cực đoan, và báo cáo $\hat{p} = (b+1)/(R+1)$ (cộng 1 để p không bao giờ ra 0). Sai số của ước lượng này quanh mức 0.05 là $\sqrt{0.05 \times 0.95/10000} = 0.0022$ — đủ nhỏ để không ai tranh cãi.

5. Vì sao không dùng t-test hai mẫu độc lập

Cám dỗ lớn nhất là đổ hai cột điểm vào scipy.stats.ttest_ind. Hãy thử ngay trên bảng 6 câu ở trên và xem chuyện gì xảy ra:

• t ghép cặp trên dãy hiệu: $t = 2.1333/1.1800 = 1.808$, bậc tự do 5, hai phía $p = 0.130$ — sát với permutation (0.125).
• t hai mẫu độc lập (Welch) trên hai cột điểm: $t = 0.321$, $p = 0.755$. Mù hoàn toàn.

Sai số chuẩn của chênh lệch: ghép cặp 1.180, không ghép cặp 6.643 — gấp 5.63 lần. Muốn phép đo không ghép cặp đạt cùng độ chính xác, bạn cần $5.63^2 \approx 32$ lần số câu. Nghĩa là tội lớn nằm ở chữ "độc lập", không phải ở chữ "t". Nhưng vẫn còn ba lý do nữa để nghiêng về permutation và bootstrap:

1. Điểm câu không chuẩn. chrF và sentence-BLEU bị chặn trong [0, 100], lệch mạnh, và câu ngắn hay dính đúng 0. Định lý giới hạn trung tâm cứu được ở $n$ vài trăm, nhưng nó không cứu ở $n = 20$.
2. Câu trong corpus không độc lập với nhau. Cùng một chương thì cùng nhân vật, cùng bộ tên riêng, cùng lối hành văn. Một cái tên dịch sai xuất hiện ở 40 câu là một lỗi, không phải 40 quan sát. Cỡ mẫu hiệu dụng nhỏ hơn $n$, mọi p-value đều bị thổi cho đẹp. Cách chữa: bootstrap theo cụm — bốc lại nguyên chương chứ không bốc lại từng câu.
3. Metric mức corpus không phải trung bình của metric mức câu. BLEU corpus gộp bộ đếm n-gram của cả bộ test rồi mới chia, nên không tồn tại "điểm câu" hợp lệ để đổ vào t-test (Module 01 đã mổ chỗ này). Bootstrap và permutation không vướng: chúng lấy mẫu lại câu, rồi tính lại metric từ đầu trên mẫu đó.

6. p-value nghĩa là gì — và bốn thứ nó không nghĩa là

Định nghĩa duy nhất đúng, đọc chậm: p là xác suất — trong một thế giới giả định nơi hai hệ thống như nhau — quan sát được chênh lệch xa 0 ít nhất bằng cái bạn đã thấy. Ở mục 4 nó là con số hoàn toàn cụ thể: trong 64 thế giới rỗng có thể có, đúng 8 thế giới cho kết quả bằng hoặc đậm hơn của bạn.

Chú ý thứ tự điều kiện: p tính dữ liệu với điều kiện giả thuyết. Bốn hiểu lầm dưới đây đều sinh ra từ việc đảo ngược thứ tự đó, hoặc từ việc quên rằng p tự nó cũng là một biến ngẫu nhiên.

Hệ quả thực hành: đừng bao giờ báo cáo p một mình. Luôn đi kèm cỡ hiệu ứng và khoảng tin cậy. "$+2.13$ chrF, CI 95% [+0.10, +4.20], permutation $p = 0.125$, $n = 6$" là một câu có nội dung. "Có ý nghĩa thống kê" là một câu không có nội dung.

7. So nhiều hơn hai: mỗi lần so là một tấm vé số

Ngưỡng $\alpha = 0.05$ nghĩa là: khi hai hệ thật sự như nhau, bạn vẫn tuyên bố thắng 5% số lần. Mua một vé thì 5% là chấp nhận được. Vấn đề là bạn không mua một vé.

Bạn eval 12 checkpoint và so mỗi cái với baseline. Nếu 12 phép so độc lập và giả thuyết không đúng ở cả 12, xác suất không lần nào báo động giả là $0.95^{12} = 0.5404$. Vậy xác suất có ít nhất một kết quả $p < 0.05$ là:

45.96%. Gần một nửa. Bạn sẽ tìm thấy "người thắng", và cảm giác vui mừng sẽ hoàn toàn chân thật. Cùng công thức đó: 2 phép so cho 9.75%, 5 phép so cho 22.62%, 20 phép so cho 64.15%.

Hai cách chữa, cùng một mục tiêu là giữ xác suất sai lầm toàn họ (family-wise error rate) ở mức 5%:

• Bonferroni: so mọi p với $\alpha/m$. Với $m = 12$ thì ngưỡng là $0.05/12 = 0.00417$. Đúng đắn nhưng thô — nó khắt khe đều với mọi phép so nên bạn mất nhiều power.
• Holm: sắp p tăng dần rồi so $p_{(i)}$ với $\alpha/(m-i+1)$. Gặp cái đầu tiên không đạt thì dừng, mọi cái còn lại giữ nguyên giả thuyết không. Holm bảo vệ đúng bằng Bonferroni nhưng luôn bác bỏ được nhiều hơn hoặc bằng.

Đọc bảng: nhìn thô thì có ba biến thể "có ý nghĩa"; Bonferroni chỉ bác bỏ được một; Holm bác bỏ được hai. Chi phí của việc thử nhiều thứ là bạn phải khắt khe hơn với từng thứ — không có bữa trưa miễn phí.

Trước khi đọc tiếp, hãy tự tay kéo cho hai hệ thống thật sự bằng nhau rồi xem bao nhiêu lần bạn vẫn tuyên bố có người thắng.

Cần biết trước: Module 04 (paired bootstrap, p-value) Dựng nên: biết bộ test của bạn phát hiện được chênh lệch nhỏ tới đâu Dẫn tới: Module 06 — đánh giá bằng người

1. Hai kiểu sai — và kiểu thứ hai mới đang giết dự án của bạn

Module 04 dạy bạn không tuyên bố thắng nhầm. Đó mới là một nửa. Bảng dưới liệt kê cả bốn ô có thể xảy ra khi bạn so hai bản dịch.

Để ý sự bất đối xứng. $\alpha$ là con số bạn chọn và kiểm soát chặt: 0.05, ai cũng biết, ai cũng báo cáo. Còn $\beta$ thì không ai chọn cả — nó là hệ quả bị động của cỡ bộ test, và trong đa số dự án dịch máy nó lớn hơn 0.80. Nghĩa là bạn đang chạy một máy dò mà bốn lần trên năm nó im lặng khi có tín hiệu.

Ngay cả quy ước "power 80%" cũng là một lựa chọn giá trị chứ không phải định luật: nó chấp nhận $\beta = 0.20$ trong khi $\alpha = 0.05$, tức bạn khoan dung với sai lầm loại II gấp 4 lần loại I. Với một ablation nội bộ không ai công bố, khoan dung ngược lại có khi hợp lý hơn.

2. Power và MDE: bốn núm xoay, không phải một

Power (statistical power) là xác suất kiểm định của bạn bác bỏ $H_0$ khi cải tiến thật sự tồn tại và có độ lớn $\Delta$. Nó không phải một thuộc tính của bộ test. Nó là một hàm bốn biến:

trong đó $\Phi$ là hàm phân phối tích luỹ chuẩn, $n$ là số câu, $\sigma_d$ là độ lệch chuẩn của hiệu ghép cặp (paired difference) theo từng câu giữa hai hệ, và $z_{\alpha/2} = 1.9600$ với $\alpha = 0.05$ hai phía.

Đảo ngược câu hỏi cho hữu dụng hơn: với bộ test đang có, chênh lệch nhỏ nhất tôi nhìn thấy được là bao nhiêu? Đó là MDE (minimum detectable effect):

3. Công thức cỡ mẫu cho hiệu ghép cặp

Đặt power mục tiêu rồi giải ngược ra $n$:

Năm hạng tử, đọc từng cái:

• $z_{\alpha/2} = 1.9600$ — ngưỡng báo động tính bằng số sai số chuẩn. Bạn chọn nó khi chọn $\alpha = 0.05$ hai phía.
• $z_\beta = 0.8416$ — khoảng cách phụ trội để phân phối thật đứng đủ xa ngưỡng, sao cho $1-\beta = 80\%$ khối lượng của nó rơi vào vùng bác bỏ.
• $(z_{\alpha/2}+z_\beta)^2 = 2.8016^2 = 7.8489$ — hằng số của bài toán. Với 5% / 80% nó luôn là con số này, không phụ thuộc dữ liệu. Nhớ nó đi.
• $\sigma_d^2$ — phương sai của hiệu ghép cặp $d_i = b_i - a_i$. Đại lượng duy nhất bạn phải đo, và cũng là đại lượng duy nhất bạn can thiệp kỹ thuật được.
• $\Delta^2$ — bình phương chênh lệch muốn bắt. Bình phương: muốn nhạy gấp đôi phải trả gấp bốn.

Bảng dưới là toàn bộ mục 3 gói lại. Đọc theo hàng để thấy giá của phương sai, đọc theo cột để thấy giá của tham vọng.

Ba điều đọc ra ngay. Một: đường chéo bằng nhau — gấp đôi $\sigma_d$ tương đương chia đôi $\Delta$, cả hai đều nhân $n$ lên 4. Hai: cột 2 BLEU rẻ đến buồn cười (126 câu) — nếu cải tiến của bạn to như vậy thì bạn chẳng cần thống kê. Ba: cột 0.25 BLEU là vùng gần như không ai đủ tiền vào; những con số "hơn 0.2 BLEU" trong báo cáo nội bộ hầu hết là nhiễu.

4. Vì sao bộ test 200 câu gần như mù

Thay số vào công thức power ở mục 2 với $n = 200$, $\Delta = 0.5$, $\sigma_d = 8$:

Số hạng đầu là $\Phi(-1.0761) = 0.1410$; số hạng sau là $0.0022$. Cộng lại: power = 0.1432, tức 14.3%.

Dịch sang tiếng người: bạn có một cải tiến thật, đúng 0.5 BLEU. Bạn chạy thí nghiệm trên 200 câu. Cứ 7 lần chạy thì gần 6 lần bạn kết luận "không khác biệt đáng kể" và ném bỏ một cải tiến có thật. $1/0.1432 = 6.98$.

Nhìn từ phía MDE thì rõ hơn nữa: $\Delta_{\min} = 2.8016 \times 8/\sqrt{200} = \mathbf{1.585}$ điểm BLEU. Bộ test 200 câu của bạn không có khả năng nhìn thấy bất cứ thứ gì nhỏ hơn 1.6 điểm. Mọi ablation bạn từng chạy trên nó, mọi lần "thử LoRA rank 8 vs 16 thấy không khác gì", đều là kết quả rỗng chứ không phải kết quả âm.

Bốn núm xoay này dễ nói hơn là dễ cảm. Kéo thử ở phòng thí nghiệm dưới đây trước khi đọc tiếp — mặt power là một mặt cong, và trực giác của bạn về nó gần như chắc chắn đang sai ở vùng $n$ nhỏ.

5. Giảm $\sigma_d$ rẻ hơn tăng $n$ rất nhiều

Vì $n \propto \sigma_d^2$, cắt $\sigma_d$ đi một nửa chia bốn số câu cần thiết. Còn muốn giảm $n$ đi 4 lần bằng cách khác thì bạn chỉ có mỗi cách tăng $\Delta$ — mà $\Delta$ là thứ trời cho. Vậy phương sai là mặt trận duy nhất.

5.1 Ghép cặp — vũ khí lớn nhất, và nó đã miễn phí sẵn

Module 04 đã nói ghép cặp làm phương sai nhỏ hơn. Đây là con số. Với hai hệ chấm trên cùng bộ câu:

Ở đây $r$ là tương quan Pearson giữa hai cột điểm câu (tương quan giá trị, không phải hạng). Nếu không ghép cặp (mỗi hệ chấm trên một mẫu riêng), $r = 0$ và $\sigma_d = \sigma\sqrt{2}$. Hệ số tiết kiệm $n$ đúng bằng $1/(1-r)$ — Module 04, mục 2 đã chạy ca $r = 0.9$ (cắt 10 lần); ở đây ta cần con số đó để xếp ghép cặp cạnh ba can thiệp còn lại ở mục 5.2.

Hai bản checkpoint cách nhau vài nghìn bước có $r$ rất cao — câu nào khó với bản cũ thì cũng khó với bản mới. Đó là lý do ghép cặp thường tiết kiệm cỡ một bậc độ lớn.

5.2 Ba cách còn lại, xếp theo giá

Tách phương sai của hiệu thành hai phần: phần do hệ thống khác nhau thật và phần do ngẫu nhiên khi giải mã, $\sigma_d^2 = \sigma_{\text{sys}}^2 + \sigma_{\text{dec}}^2$. Giả sử trong $\sigma_d = 8$ có $\sigma_{\text{dec}} = 4$ (sampling với temperature). Khi đó $\sigma_{\text{sys}} = \sqrt{64-16} = 6.93$.

Dòng thứ hai đáng nhớ nhất: cố định seed và dùng greedy decode cho mọi bản so sánh cắt được một phần tư số câu cần thiết, không tốn một xu. Dòng thứ ba là bài học ngược: lặp lại decode để lấy trung bình nghe có vẻ khoa học, nhưng nó chỉ đánh vào $\sigma_{\text{dec}}$ và đánh theo kiểu $1/k$ — bốn lần decode chỉ đổi được 19%, trong khi bỏ hẳn sampling đổi được 25%.

6. Ngân sách eval: đừng chia đều một cách ngây thơ

Giả sử ngân sách của bạn là 4 000 lượt decode (mỗi lượt = một câu, một hệ thống). Bạn có thể tiêu nó theo nhiều cách:

Đó mới là một nửa của cái giá. Nửa còn lại: nhiều hệ thống thì phải hiệu chỉnh đa so sánh (Module 04 đã giải thích vì sao), mà hiệu chỉnh làm $z_{\alpha/2}$ to ra và $n$ cần thiết to theo.

Với Bonferroni, $z_{\alpha/2}$ leo từ 1.960 ($m=1$) lên 2.241 ($m=2$), 2.394 ($m=3$), 2.638 ($m=6$), 2.807 ($m=10$). Số câu cần cho $\Delta = 0.5$, $\sigma_d = 8$ leo theo: 2 010 → 2 434 → 2 681 → 3 101 → 3 409, tức đắt thêm 21%, 33%, 54%, 70%.

Hai gọng kìm ép cùng lúc: thêm một hệ thống vừa lấy bớt câu của mỗi arm, vừa đòi thêm câu vì phải hiệu chỉnh. Bốn hệ thống trong cùng ngân sách 4 000 lượt cho bạn 1 000 câu mỗi arm trong khi bài toán đòi 3 101 — thiếu ba lần.

Ba nguyên tắc rút ra:

1. Chọn MDE trước, tính $n$ sau. Không bao giờ chọn $n$ bằng cảm giác rồi hy vọng. Câu hỏi đúng là: "chênh lệch nhỏ nhất mà tôi sẽ hành động theo là bao nhiêu?" Nếu bạn chỉ ship khi hơn 1 điểm, đừng trả tiền cho bộ test 4 000 câu.
2. Lọc thô rồi mới đo tinh. Sàng 12 checkpoint trên 300 câu là hợp lệ — bạn chỉ đang loại bỏ những cái tệ rõ ràng. Nhưng khi còn 2 ứng viên, phải chạy lại trên bộ test đủ lớn. Đừng bao giờ để một quyết định ship dựa trên vòng sàng.
3. Bộ test lớn là chi phí một lần. Xây 2 000 câu tham chiếu tốn công một lần rồi dùng lại cho mọi thí nghiệm về sau; chi phí biên mỗi lần chạy chỉ là decode. So với việc chạy mù suốt sáu tháng, nó rẻ.

Cần biết trước: Module 03 (khoảng tin cậy), Module 05 (cỡ mẫu) Dựng nên: một phiên chấm người cho ra số dùng được Dẫn tới: Module 07 — LLM-as-judge

1. Khi nào bắt buộc phải có người

Không phải lúc nào cũng cần. Metric tự động rẻ hơn hàng nghìn lần và bạn nên xài nó cho 95% số lần đo. Người chỉ bắt buộc khi metric mù đúng cái bạn đang sửa.

Ba tình huống mù điển hình trong dịch web novel zh→vi:

• Lỗi hiếm nhưng chết người. Giả sử bộ test 500 câu, 1% (tức 5 câu) có lỗi đảo nghĩa. Bạn sửa được cả 5, điểm câu của chúng nhảy từ 5 lên 55. Trung bình điểm câu tăng $5 \times 50 / 500 = 0.5$ điểm. Đây là so sánh ghép cặp nên phải nhìn phân phối của hiệu, không phải phương sai của một hệ: hiệu gồm 5 giá trị 50 và 495 giá trị 0, cho $\sigma_d = 4.98$, $\mathrm{SE}_d = 4.98/\sqrt{500} = 0.22$ và $t = 2.25$ — trung bình có nhúc nhích thật. Nhưng toàn bộ tín hiệu nằm trên đúng 5 câu: paired bootstrap 20 000 vòng cho khoảng 95% là $[0.10, 1.00]$, cận trên gấp mười lần cận dưới, còn sign test chỉ cho $p = 0.0625$. Quan trọng hơn, con số 0.5 không nói được 5 câu đó nặng cỡ nào — metric cân một câu đảo nghĩa đúng bằng một câu văn vụng. 5 câu đó là 5 độc giả bỏ truyện.
• Thứ vượt quá một câu. Xưng hô nhân vật nhất quán xuyên 300 chương, tên riêng ổn định, giọng kể không đổi. BLEU và chrF đọc từng câu độc lập, chúng không có khái niệm "chương trước gọi là sư tỷ".
• Thứ mà reference không đại diện. Một câu Trung có mười bản dịch Việt đều hay. Reference chỉ có một bản. Bạn sửa cho bản dịch tự nhiên hơn nhưng xa reference hơn — metric bề mặt trừ điểm bạn.

Còn một lý do nền tảng hơn: COMET và BLEURT là hồi quy trên điểm người. Gốc của mọi thang đo, kể cả thang tự động, cuối cùng vẫn là người. Nếu bạn không bao giờ chấm tay, bạn không có cách nào biết metric của mình còn đúng trên miền dữ liệu của bạn.

2. Ba thang đo và cái giá của từng thang

Ba lựa chọn thực dụng: DA/Likert (direct assessment — cho điểm tuyệt đối), so cặp (pairwise comparison — chọn bản nào hơn), MQM (Multidimensional Quality Metrics — đánh dấu từng span lỗi kèm mức nặng nhẹ). Chúng khác nhau ở thứ chúng trả về, chứ không phải ở "cái nào chính xác hơn".

3. Rubric zh→vi: minor · major · critical

Rubric là thứ quyết định $\kappa$ của bạn, chứ không phải chất lượng người chấm. Một rubric mơ hồ khiến hai dịch giả giỏi bất đồng; một rubric có quy tắc phân xử khiến hai sinh viên năm hai đồng thuận. Quy tắc phân xử của ta chỉ có một câu hỏi:

Người đọc chưa từng xem bản gốc có hiểu sai một sự kiện nào không?

Không → minor. Có, nhưng cục bộ, mạch truyện vẫn theo được → major. Có, và đoạn văn hỏng hoặc nghĩa bị đảo → critical.

minor — hiểu đúng hết, chỉ thấy văn vụng

Thông tin nguyên vẹn. Người đọc chỉ cảm thấy câu cứng, thừa chữ, hoặc quá "convert". Không ai phải đọc lại.

• Ví dụ 1 · dịch sát cấu trúc. Nguồn: 他没有回答，只是把剑收了回去。
  Bản dịch: "Hắn không có trả lời, chỉ là đem kiếm thu trở về."
  Vì sao minor: nghĩa đúng 100% — hắn im lặng và cất kiếm. "Không có + động từ", "chỉ là", "đem … thu trở về" là khung tiếng Trung bê nguyên. Bản gọn: "Hắn không đáp, chỉ tra kiếm vào vỏ."
• Ví dụ 2 · Hán-Việt sống sượng. Nguồn: 她快步走进丹房。
  Bản dịch: "Nàng khoái bộ tẩu tiến đan phòng."
  Vì sao minor: độc giả web novel lâu năm vẫn giải mã được "khoái bộ tẩu tiến" là "bước nhanh vào". Không mất thông tin nào. Nhưng nếu 30% câu như thế thì bản dịch không đọc được với người mới — đó là lý do minor vẫn phải đếm, chỉ là trọng số 1.

major — sai hoặc mất một chi tiết, mạch vẫn theo được

Người đọc tiếp nhận một thông tin sai, nhưng không sai tới mức hỏng chương. Đây là mức đông nhất, và cũng là mức hai người chấm hay cãi nhau nhất — nên nó cần nhiều ví dụ nhất trong tài liệu hướng dẫn của bạn.

• Ví dụ 1 · đảo vai vế xưng hô. Nguồn: 师姐，你先走。
  Bản dịch: "Sư muội, muội đi trước đi."
  Vì sao major: 师姐 là sư tỷ — vai trên. Bản dịch lật ngược quan hệ hai nhân vật. Người đọc hiểu sai thứ bậc, và nếu lỗi này lặp lại thì cả tuyến quan hệ lệch. Chưa tới critical vì cảnh vẫn diễn ra đúng: một người bảo người kia đi trước.
• Ví dụ 2 · sai con số. Nguồn: 他闭关了三百年。
  Bản dịch: "Hắn bế quan ba nghìn năm."
  Vì sao major: sai một chi tiết định lượng cụ thể, và con số này thường được nhắc lại ở chương sau nên sẽ tạo mâu thuẫn nội tại. Vẫn không đảo nghĩa sự kiện: hắn có bế quan.
• Ví dụ 3 · rơi một mệnh đề. Nguồn: 他握紧了拳头，却终究没有出手。
  Bản dịch: "Hắn siết chặt nắm đấm."
  Vì sao major: mất vế "nhưng rốt cuộc không ra tay" — mất một quyết định của nhân vật. Câu còn lại vẫn đúng, không tự mâu thuẫn, nên chưa phải critical.

critical — đoạn hỏng, nghĩa đảo, hoặc nội dung bịa

Người đọc bị dẫn tới một kết luận sai về cốt truyện, hoặc phải bỏ đoạn. Đây là mức đáng để bạn dừng ship. Trong dữ liệu thật của một hệ dịch web novel, mức này thường hiếm — vài phần trăm — và chính vì hiếm nên nó biến mất khỏi mọi con số trung bình.

• Ví dụ 1 · nuốt phủ định. Nguồn: 他并没有杀死那个孩子。
  Bản dịch: "Hắn đã giết chết đứa bé đó."
  Vì sao critical: nghĩa bị đảo hoàn toàn. Nhân vật chính từ người tha mạng thành kẻ giết trẻ con. Một câu này làm hỏng cả arc nhân vật, và độc giả không có cách nào tự sửa vì bản dịch đọc rất trôi chảy.
• Ví dụ 2 · ảo giác, sinh thêm nội dung. Nguồn: 外面下起了雨。
  Bản dịch: "Bên ngoài trời đổ mưa. Nàng biết rằng sư phụ mình đã chết."
  Vì sao critical: câu thứ hai không tồn tại trong nguồn. Model bịa ra một sự kiện cốt lõi. Đây là loại lỗi mà BLEU trừ rất ít (câu đầu khớp reference) nhưng độc giả thì mất niềm tin ngay lập tức.
• Ví dụ 3 · sập kỹ thuật. Bản dịch trả về "Nàng nói nàng nói nàng nói nàng nói…" hoặc một chuỗi rỗng.
  Vì sao critical: đoạn không dùng được. Đừng gộp mức này vào major chỉ vì nó "rõ ràng quá" — bạn cần đếm được nó tách riêng để đặt guardrail trong bộ hồi quy.

4. Thiết kế một phiên chấm mù

Một phiên chấm cẩu thả không cho ra số nhiễu — nó cho ra số lệch, và lệch thì không bootstrap nào cứu được. Bốn thứ bắt buộc: mù nhãn hệ thống, ngẫu nhiên hoá vị trí trái/phải theo từng câu, chèn câu mồi, và giới hạn độ dài phiên.

Vài chi tiết dễ bỏ sót nhưng làm hỏng phiên:

• Chuẩn hoá hiển thị trước khi trộn. Nếu hệ B luôn xuống dòng sau dấu chấm còn hệ A thì không, người chấm nhận ra nhãn sau 5 câu và mọi thứ mù đều vô nghĩa. Chuẩn hoá khoảng trắng, dấu câu, viết hoa, ký tự đặc biệt về cùng một dạng.
• Hai loại câu mồi. Loại một: bản dịch cố tình phá (đảo phủ định hoặc cắt nửa câu) — người tỉnh táo phải chấm thấp. Loại hai: cặp giống hệt nhau — người tỉnh táo phải chọn "hoà". Loại hai bắt được người luôn bấm bên trái, loại một bắt được người bấm bừa.
• Lưu bảng ánh xạ ra ngoài. Ánh xạ vị-trí → hệ-thống phải nằm ở file khác, không nằm trong giao diện chấm. Nghe hiển nhiên, nhưng lỗi phổ biến là để tên hệ thống trong thuộc tính HTML rồi tự hỏi vì sao κ cao bất thường.
• Giới hạn phiên. 92 mục × 25 giây ≈ 38 phút. Ba mục đầu phiên đều là câu mồi — chúng không bao giờ đóng góp vào tỉ lệ thắng, nên mất đúng $3/92 = 3.3\%$ thời gian phiên chứ không đụng vào 80 cặp thật, đổi lấy việc khử được hiệu ứng neo ở đầu phiên.

5. Năm thiên vị của người chấm

Người chấm không phải cảm biến. Họ là hệ thống có trạng thái, có mệt mỏi, có kỳ vọng. Năm thiên vị (bias) dưới đây đều đã đủ mạnh để tự mình tạo ra một "kết quả có ý nghĩa thống kê".

6. Đo đồng thuận: agreement thô nói dối, $\kappa$ nói thật

Bạn có hai người chấm cùng một tập câu. Câu hỏi đầu tiên phải là: họ có đang đo cùng một thứ không? Nếu $\kappa$ thấp thì mọi con số phía sau chỉ là ý kiến của một người, và người kia không tái tạo được.

Cám dỗ là báo cáo agreement thô (raw agreement) — tỉ lệ câu hai người cho cùng nhãn. Nó luôn nghe hay, vì nó tính cả phần trùng nhau do may rủi. Cohen $\kappa$ trừ phần đó đi:

Cùng một agreement thô, năm giá trị $\kappa$ khác nhau

Đây là chỗ phản trực giác nhất của module này, nên nói thẳng: agreement thô không so sánh được giữa hai bộ dữ liệu có tần suất nhãn khác nhau. Bảng dưới giữ agreement thô cố định ở đúng 90% (270/300 câu trùng, 30 câu bất đồng, chia đều 15/15), chỉ thay đổi độ hiếm của lớp cần bắt.

Hàng đầu là trường hợp thật của bạn: gắn cờ lỗi critical trên 300 câu, lớp hiếm. Người A gắn cờ 20 câu, người B cũng gắn cờ 20 câu, nhưng chỉ trùng nhau 5 câu. Kiểm tra: $p_e = (280/300)^2 + (20/300)^2 = 0.8756$, nên

Agreement thô 90% — nghe như xuất sắc. Nhưng hai người dán nhãn ngẫu nhiên với đúng tần suất đó đã đạt 87.6% rồi. Bạn chỉ hơn may rủi 2.4 điểm phần trăm trên dư địa 12.4 điểm. Một cách nhìn khác cùng dữ liệu: positive specific agreement $= 2 \times 5 / (20 + 20) = 0.25$ — khi một người đã gắn cờ critical, người kia chỉ gắn cờ theo trong 25% số lần. Đọc kiểu thứ ba cũng trên đúng dữ liệu đó: có $5 + 15 + 15 = 35$ câu bị ít nhất một người gắn cờ, và chỉ 5 câu trong đó — 14.3% — được cả hai đồng ý. Rubric critical của bạn chưa tồn tại; nó chỉ đang ở trong đầu từng người một cách khác nhau.

Kéo thử bảng chéo ở phòng thí nghiệm dưới đây trước khi đọc tiếp — đổi vài ô rồi xem hai con số rời nhau ra sao.

$\kappa$ cũng là một ước lượng, nên nó cũng phải có sai số

Đây là chỗ luận đề của cả quyển này quay lại cắn bạn. $\kappa = 0.4898$ ở trên được tính từ 100 câu. Xấp xỉ sai số chuẩn thường dùng:

Khoảng tin cậy 95% là $0.49 \pm 1.96 \times 0.0884 = 0.49 \pm 0.173$, tức [0.32, 0.66]. Khoảng này trải từ "tạm được" sang "khá tốt" theo mọi thang quy ước. Nói cách khác, với 100 câu bạn không biết rubric của mình tốt hay xoàng. Muốn nửa khoảng còn một nửa thì cần gấp 4 lần số câu: $n = 400$ cho $\pm 0.087$.

Ba mốc đáng nhớ, tất cả quanh $\kappa = 0.49$: với $n = 78$ câu chồng lấn thì $\mathrm{SE}(\kappa) = 0.1001$, khoảng 95% là [0.29, 0.69] — chỉ đủ phát hiện thảm hoạ ($\kappa$ gần 0); $n = 120$ cho 0.0807 và [0.33, 0.65] — vẫn không phân biệt được 0.4 với 0.6; $n = 400$ cho 0.0442 và [0.40, 0.58] — đủ để nói rubric ở mức trung bình chứ không tốt.

import random
from collections import Counter

def cohen_kappa(cap):
    """cap: danh sach cac cap nhan (a, b) cua hai nguoi cham."""
    n = len(cap)
    po = sum(1 for a, b in cap if a == b) / n
    fa = Counter(a for a, _ in cap)
    fb = Counter(b for _, b in cap)
    nhan = set(fa) | set(fb)
    pe = sum((fa[k] / n) * (fb[k] / n) for k in nhan)
    return (po - pe) / (1 - pe)

# dung lai bang cheo 45 / 10 / 15 / 30 o tren
du_lieu = ([("OK", "OK")] * 45 + [("OK", "FIX")] * 10
           + [("FIX", "OK")] * 15 + [("FIX", "FIX")] * 30)

print(round(cohen_kappa(du_lieu), 4))          # 0.4898

# khoang tin cay: bootstrap tren chinh cac cau, dung ky thuat cua Module 03
rng = random.Random(0)
mau = [cohen_kappa(rng.choices(du_lieu, k=len(du_lieu))) for _ in range(2000)]
mau.sort()
print(round(mau[50], 3), round(mau[1949], 3))  # hai duoi 2.5% va 97.5%

Bootstrap ở đây tốt hơn công thức xấp xỉ, vì phân phối của $\kappa$ lệch khi lớp mất cân bằng. Kỹ thuật y hệt Module 03, chỉ đổi thống kê được tính lại trong mỗi vòng.

7. Tiêu ngân sách human eval cho khôn

Human eval đắt theo cách mà metric tự động không bao giờ đắt: chi phí tuyến tính theo số câu, và không tái sử dụng được khi bạn đổi checkpoint. Nên mọi quyết định là quyết định phân bổ.

Trước hết, tính xem bạn cần bao nhiêu

Dùng công thức cỡ mẫu cho một tỉ lệ so với 0.5 (Module 05), với $\alpha = 0.05$ hai phía và power 80%:

• Tỉ lệ thắng thật 55% → $n = 783$. Chênh lệch nhỏ nhưng thật. Đây là mức bạn hay gặp sau một lần fine-tune.
• 60% → $n = 194$. Chênh lệch rõ. Một buổi chiều là xong.
• 65% → $n = 85$. Nếu bạn chấm hết 85 phán quyết mà vẫn không thắng, chênh lệch không tới 65%.

Chú ý một chỗ dễ hụt ngân sách: công thức trên là công thức cho một tỉ lệ nhị phân, nên $n$ là số phán quyết không hoà, không phải số cặp bạn phải chấm. Nếu tỉ lệ hoà là $t$ thì số cặp phải chấm là $n/(1-t)$ — với $t = 0.40$ thì 783 thành 1305.

Giả sử bạn đã lọc bỏ những câu hai hệ ra bản dịch giống hệt nhau và tỉ lệ hoà còn lại là $t = 0.20$: cần $783/0.8 = 979$ cặp, lấy tròn 980. Thêm 147 cặp chấm lần hai (15%) để đo $\kappa$, thành 1127 phán quyết. Chèn câu mồi theo tỉ lệ 12/80 thì có thêm 169 mục mồi, tổng 1296 mục. Ở 25 giây/mục, đó là 9.0 giờ công, chia thành 15 phiên. Chín giờ để trả lời một câu hỏi mà chrF trả lời trong ba giây — nhưng chrF không trả lời được câu hỏi này.

Bốn cách tiêu tiền thông minh

• Chỉ chấm câu hai hệ khác nhau. Nếu 40% số câu hai hệ cho ra bản dịch giống hệt nhau, chấm chúng là ném tiền: chúng đóng góp đúng 0 vào hiệu. Lọc trước rồi chấm 300 câu khác biệt thì lượng thông tin tương đương $300/0.6 = 500$ câu lấy ngẫu nhiên. Cảnh báo: bạn đã đổi đại lượng đang ước lượng — nó là "tỉ lệ thắng trong số câu có khác biệt". Muốn quay về mức toàn corpus thì tính hoà bằng nửa điểm: $0.6\,p_{\mathrm{diff}} + 0.4 \times 0.5$. Với $p_{\mathrm{diff}} = 0.60$ thì mức toàn corpus là 0.56 chứ không phải 0.60 — và mốc null vẫn là 0.5, đừng nhân 0.6 rồi so với 0.5, làm thế hệ đang thắng biến thành hệ đang thua.
• Chấm đơn nhiều câu thắng chấm đôi ít câu. Mô hình: điểm = giá trị thật của câu + nhiễu người, với $\sigma_{\text{item}} = 15$ và $\sigma_{\text{rater}} = 10$. Cùng ngân sách 600 lượt chấm:
  • 300 câu × 2 người: $\mathrm{SE} = \sqrt{(225 + 100/2)/300} = 0.957$
  • 600 câu × 1 người: $\mathrm{SE} = \sqrt{(225 + 100)/600} = 0.736$
  Chấm đơn cho sai số nhỏ hơn 23%. Phản trực giác, nhưng logic đơn giản: nhiễu người trung bình hoá qua nhiều câu cũng tốt như trung bình hoá qua nhiều người, mà nhiễu câu thì chỉ có thêm câu mới giảm được.
• Vẫn giữ một phần chồng lấn — nhưng vì lý do khác. Chấm đôi không phải để giảm sai số của trung bình, mà để đo được $\kappa$. Với 600 lượt và 15% chồng lấn: 521 câu tổng, trong đó 78 câu chấm đôi, hết 599 lượt. Đừng ảo tưởng: 78 câu chỉ cho $\mathrm{SE}(\kappa) = 0.10$, đủ để phát hiện rubric hỏng, không đủ để khoe rubric tốt.
• Đừng để dữ liệu chết sau một lần dùng. Mỗi phán quyết người là một dòng dữ liệu vàng: nó là golden set để kiểm định LLM-as-judge (Module 07), là hạt giống cho bộ hồi quy (Module 08), và là căn cứ để chọn metric tự động nào tương quan tốt nhất với người trên miền của bạn (Module 02). Lưu kèm mã câu, mã người chấm, thời điểm, và vị trí trong phiên — thiếu trường cuối là bạn không bao giờ đo được độ trôi mệt mỏi.

Cần biết trước: Module 06 — rubric, thiết kế phiên chấm mù, Cohen $\kappa$ Dựng nên: một judge có bằng chứng là đáng tin Dẫn tới: Module 08 — golden set và nhiễm dữ liệu

1. Vì sao judge hấp dẫn — và cái giá thật của nó

Module 06 vừa cho bạn thấy human eval đắt tới mức nào. Judge tự động là câu trả lời hiển nhiên. Hãy tính ra con số thay vì nói "rẻ hơn nhiều".

Giả sử: 500 câu, người chấm mất 45 giây mỗi câu, trả 8 USD/giờ. Judge dùng 1200 token vào và 300 token ra mỗi câu, giá 0.30 USD/1M token vào và 1.50 USD/1M token ra.

• Người: $500 \times 45 = 22500$ giây $= 6.25$ giờ $\to$ 50.00 USD, và bạn phải chờ hết ngày.
• Judge: $0.6$M token vào $\times\,0.30 = 0.18$ USD, cộng $0.15$M token ra $\times\,1.50 = 0.225$ USD $\to$ 0.405 USD. Với 8 luồng song song, 4 giây mỗi lần gọi: 250 giây.

Tỉ lệ: rẻ hơn 123 lần ($50 / 0.405 = 123.5$) và nhanh hơn 90 lần ($22500 / 250$). Đó là lý do judge chạy được ở mỗi commit còn người thì không. Nhưng chú ý ngay: con số 123 lần chỉ là chi phí chạy. Chi phí kiểm định judge — mục 6 — vẫn phải trả bằng tiền người, và không được bỏ.

2. Ba dạng judge, và dạng nào mở cửa cho thiên vị nào

• Pointwise — "cho bản dịch này mấy điểm trên thang 0–100". Một lần gọi mỗi bản, xếp hạng $k$ hệ tốn $O(k)$, so được với kết quả tháng trước. Yếu: thang trôi giữa các phiên, và judge dồn điểm vào một dải hẹp nên chênh lệch nhỏ bị nuốt.
• Pairwise — "A hay B tốt hơn". Nhiệm vụ dễ hơn cho model nên nhạy hơn với chênh lệch nhỏ, hợp đúng câu hỏi "bản mới có hơn không". Yếu: tốn $O(k^2)$ khi so nhiều hệ, và mở toang cửa cho thiên vị vị trí.
• Không tham chiếu (QE) — chỉ đưa nguồn và bản dịch. Dùng được trên dữ liệu production không có bản dịch chuẩn. Yếu: judge phải tự đọc hiểu tiếng Trung, và với zh→vi đây đúng là chỗ nó yếu nhất.

Trong dự án dịch web novel, câu hỏi thường trực là "checkpoint mới có hơn checkpoint cũ không" — đó là câu hỏi pairwise. Nên phần còn lại của module tập trung vào pairwise, nơi thiên vị nguy hiểm nhất.

3. Bốn thiên vị đã đo được, không phải bốn nỗi lo

Bốn thứ dưới đây không phải "judge đôi khi thiếu chính xác". Chúng là sai lệch có hướng: lặp lại bao nhiêu lần cũng lệch về cùng một phía. Đó là khác biệt sống còn — xem mục 4.

Same-teacher: vòng lặp tự khen của chính bạn

Đây là cái bẫy được thiết kế riêng cho tình huống của bạn, nên nói thẳng ra từng bước.

Bạn có một teacher $T$ mạnh. Bạn làm sequence-level KD: cho $T$ dịch cả kho song ngữ, rồi train student $S$ trên chính bản dịch của $T$. Mục tiêu huấn luyện của $S$, viết cho đúng, là tái tạo phân phối đầu ra của $T$ — không phải "dịch hay". Sau đó bạn cần biết $S$ có hơn baseline không, và bạn gọi... $T$ ra chấm.

Vòng đã khép. $S$ được thưởng vì giống $T$; $T$ chấm cao cho thứ giống mình. Cái bạn đo được gọi đúng tên là khoảng cách tới $T$, đội lốt "chất lượng dịch".

Nó thổi điểm theo hướng nào — nói cho chính xác. Ba hướng, không phải một:

1. Thổi điểm tuyệt đối của $S$ lên. $S$ dùng đúng lối diễn đạt, đúng lối ngắt câu, đúng cách xưng hô mà $T$ ưa. Judge thấy quen, chấm cao.
2. Thổi mạnh hơn nữa khi so với baseline không distil từ $T$. Giả sử tỉ lệ thắng thật của $S$ trước baseline là 46% — tức $S$ đang thua 4 điểm phần trăm. Thiên vị same-teacher 12 pp đẩy tỉ lệ quan sát lên $46 + 12 = 58\%$. Judge báo cáo "$S$ thắng 58–42", tức thắng 8 pp, trong khi sự thật là thua 4 pp. Đổi dấu. Và chỉ cần 151 cặp là cái tỉ lệ 58% quan sát được đó tách khỏi mốc 50% ở mức "có ý nghĩa thống kê" — đại lượng phải kiểm là độ lệch 8 pp so với 50%, không phải 12 pp, nên con số cỡ mẫu là đúng con số ở mục 4.
3. Thổi mù đúng chỗ nguy hiểm nhất. $T$ có lỗi hệ thống — rớt Hán-Việt ở một số cấu trúc, dịch tên nhân vật không nhất quán giữa các chương. $S$ học thuộc cả những lỗi đó vì chúng nằm sẵn trong data distil. Khi $T$ chấm, nó không thấy đó là lỗi: đấy là đầu ra bình thường của chính nó. Nghĩa là đúng loại lỗi bạn cần bắt nhất lại là loại judge này mù nhất.

4. Thiên vị không co lại theo $n$ — và đó là toàn bộ vấn đề

Nhiễu và thiên vị trông giống nhau trên một lần chạy, nhưng cư xử ngược nhau khi bạn tăng cỡ mẫu. Gọi $h$ là nửa rộng khoảng tin cậy 95% cho một tỉ lệ thắng, lấy trường hợp xấu nhất $p = 0.5$:

Thiên vị thì không có $n$ trong công thức. Nó là một hằng số. Đặt hai thứ đó cạnh nhau và câu chuyện tự kể.

Điều kiện để một hiệu ứng biên độ $b$ vượt dải nhiễu, tức tuyên bố được "khác 50% một cách có ý nghĩa" ở $\alpha = 0.05$ hai phía:

• Thiên vị vị trí $b = 0.08$: $\ (0.98/0.08)^2 = 12.25^2 = 150.06 \to$ $n = 151$ cặp.
• Chênh lệch thật $b = 0.03$: $\ (0.98/0.03)^2 = 32.67^2 = 1067.1 \to$ $n = 1068$ cặp.

Trả lời câu hỏi của mục này: chỉ cần 151 cặp là thiên vị vị trí 8 pp trở thành "kết quả có ý nghĩa thống kê", trong khi chênh lệch thật 3 pp phải đợi tới 1068 cặp. Tỉ số là $(8/3)^2 = 7.11$ — thiên vị về đích nhanh gấp 7.1 lần sự thật. Giữa 151 và 1068 có 917 cỡ mẫu mà bạn sẽ nhận một câu trả lời tự tin và sai.

Nói cho chặt về chữ "đủ". Ngưỡng $n > (0.98/b)^2$ là chỗ nửa rộng CI vừa bằng hiệu ứng, tức chỗ bạn tuyên bố được đúng một nửa số lần chạy — power 50%, bằng tung đồng xu. Tính lại chính xác: tại $n = 151$ với tỉ lệ thật 58%, xác suất bác bỏ được $H_0$ là $0.502$; tại $n = 1068$ với 53% là $0.500$. Muốn power 80% như quy ước ở Module 05 (dùng $z_{\alpha/2}+z_\beta = 2.8016$ thay cho $1.96$) thì cần 305 cặp cho 8 pp và 2178 cặp cho 3 pp. Mọi con số cỡ mẫu trong module này là ngưỡng dễ dãi nhất — và ngay ở ngưỡng dễ dãi nhất, thiên vị vẫn về đích trước sự thật 7.1 lần.

Cụ thể tại $n = 800$ — cỡ bộ test điển hình: sai số chuẩn là $0.5/\sqrt{800} = 0.0177$, nên thiên vị 8 pp đứng ở $4.53\sigma$ còn chênh lệch thật 3 pp mới ở $1.70\sigma$. Cái rác thì "chắc chắn tuyệt đối", cái thật thì chưa đủ ngưỡng.

Bật từng loại thiên vị lên và xem tỉ lệ quyết định sai nhảy thế nào trước khi đọc tiếp.

5. Năm cách hiệu chỉnh, xếp theo tỉ lệ hiệu quả trên chi phí

1. Hoán vị vị trí rồi lấy trung bình. Rẻ nhất, hiệu quả nhất, triệt tiêu thiên vị vị trí đúng bằng đại số như phép tính ở trên. Giá: gấp đôi số lần gọi. Phần thưởng kèm theo: tỉ lệ lật — số cặp mà judge đổi phán quyết khi đổi chỗ — là chỉ số sức khoẻ tốt nhất bạn có. Ví dụ trên 300 cặp: 96 cặp lật (32%), trong đó 72 lật theo hướng ủng hộ ô thứ nhất và 24 theo hướng ngược. Ước lượng thiên vị $\hat{b} = (72-24)/(2 \times 300) = 0.08$, $\mathrm{SE} = 0.0157$, CI 95% $= [4.9;\ 11.1]$ pp. Kiểm định McNemar cho $z = 4.90$, $p = 9.6 \times 10^{-7}$: thiên vị có thật, không phải tưởng tượng.
2. Ép rubric có severity và tính điểm cơ học. Đừng hỏi "bản nào hay hơn". Bắt judge liệt kê lỗi, gán mức critical/major/minor, rồi bạn cộng điểm bằng công thức cố định. Judge còn quyền quyết định về sự kiện, không còn quyền quyết định về thang điểm. Cắt gần hết thiên vị độ dài.
3. Bắt trích dẫn bằng chứng. Mỗi lỗi phải kèm đoạn nguyên văn trích từ bản dịch. Lỗi không trích được thì không tồn tại. Đây cũng là bộ lọc rác duy nhất bạn kiểm được bằng máy: chuỗi trích dẫn phải là substring của bản dịch, sai thì loại cả phán quyết.
4. Dùng logprob thay vì chữ. Với pairwise, lấy log-xác suất của token "A" và "B" ở vị trí trả lời rồi so — được một con số liên tục thay vì nhãn nhị phân, nên phương sai nhỏ hơn và phát hiện được cả những cặp judge lưỡng lự. Điều kiện: API phải trả logprob.
5. Chấm mù nguồn gốc. Không bao giờ để tên hệ thống, tên checkpoint, hay bất cứ dấu vết nào lọt vào prompt. Nghe hiển nhiên, nhưng chuỗi kiểu ckpt_v3_lora_r16 lọt vào field metadata là chuyện xảy ra thật.

Bạn là giám khảo dịch thuật Trung sang Việt cho tiểu thuyết mạng.
Chấm MỘT bản dịch. Không so sánh với bản nào khác.

[NGUỒN]      {src_zh}
[THAM CHIẾU] {ref_vi}
[BẢN DỊCH]   {hyp_vi}

RUBRIC — xếp mỗi lỗi vào đúng một mức:
  critical : sai nghĩa khiến người đọc hiểu ngược; mất hoặc thêm cả một
             mệnh đề; sai tên nhân vật; sai con số hoặc đơn vị.
  major    : sai nghĩa cục bộ nhưng còn đoán ra; sai xưng hô giữa hai
             nhân vật; rớt Hán-Việt thô ("đích", "liễu", "ngã tại");
             đảo ngược phủ định.
  minor    : đúng nghĩa nhưng vụng: lặp từ, sai dấu câu, trạng ngữ đặt
             sai chỗ, thiếu tự nhiên.

QUY TẮC BẮT BUỘC:
  1. Mỗi lỗi phải chép NGUYÊN VĂN đoạn sai của [BẢN DỊCH] vào trường
     "trich_dan". Không chép được nguyên văn thì lỗi đó không tồn tại.
  2. Không phạt vì diễn đạt khác [THAM CHIẾU]. Chỉ phạt khi sai so với
     [NGUỒN]. [THAM CHIẾU] là một cách dịch đúng, không phải cách duy nhất.
  3. Không thưởng và không phạt vì bản dịch dài hơn hay ngắn hơn.
  4. Không suy đoán model nào sinh ra bản dịch. Không nhắc tới model.
  5. Điểm tính cơ học: bắt đầu 100; trừ 25 mỗi critical, 8 mỗi major,
     2 mỗi minor; sàn 0. Cấm cho điểm khác kết quả của phép trừ này.

TRẢ VỀ đúng một khối JSON, không kèm chữ nào khác:
{
  "loi": [
    {"muc": "major", "trich_dan": "...", "ly_do": "...", "sua_thanh": "..."}
  ],
  "diem": 84,
  "do_tin": "cao"
}
Trường "do_tin" nhận một trong ba giá trị: cao, trung binh, thap.
Ghi "thap" khi [NGUỒN] mơ hồ hoặc thiếu ngữ cảnh chương trước.

Ví dụ trong khối JSON kiểm được bằng tay: một lỗi major và bốn lỗi minor cho $100 - 8 - 4 \times 2 = 84$. Nếu judge trả về điểm không khớp phép trừ, bạn bỏ điểm của nó và tự cộng lại từ danh sách lỗi — đó chính là điểm mạnh của cách tính cơ học.

6. Quy trình kiểm định judge — chín bước, có ngưỡng để loại

Coi judge như một người chấm mới vào nghề. Bạn sẽ không cho người mới ký quyết định ship khi chưa đo đồng thuận của họ; judge cũng vậy. Công thức Cohen $\kappa$ đã có ở Module 06, ở đây chỉ dùng lại.

1. Chốt quyết định mà judge sẽ phục vụ. "Chọn 1 trong 12 checkpoint" và "gác cổng regression mỗi commit" là hai bài toán khác nhau, ngưỡng chấp nhận khác nhau.
2. Dựng golden người: 200–300 câu, ít nhất hai người chấm độc lập bằng rubric của Module 06, mù nguồn gốc.
3. Đo mốc người: tính $\kappa_{hh}$ giữa hai người, trên toàn bộ golden. Giả sử đo được $\kappa_{hh} = 0.68$. Đây là mốc để chia tỉ lệ, không phải một trần tuyệt đối — đọc cảnh báo dưới bảng ngưỡng.
4. Chốt nhãn tham chiếu từ các câu hai người đồng thuận; câu bất đồng thì người thứ ba xử, hoặc loại và ghi lại đã loại bao nhiêu.
5. Chạy judge trên chính golden đó, mù, hoán vị vị trí, nhiệt độ 0, ghi lại phiên bản model và toàn văn prompt.
6. Tính $\kappa_{jh}$ giữa judge và nhãn tham chiếu, kèm khoảng tin cậy bootstrap. Tính thêm một lần nữa trên đúng tập mục của bước 3 — toàn bộ, kể cả câu hai người bất đồng — với nhãn của một người chấm cố định. Chỉ con số thứ hai này mới đặt cạnh $\kappa_{hh}$ được.
7. Áp ngưỡng (bảng dưới). Đây là bước có quyền nói "không".
8. Đo từng thiên vị riêng: vị trí bằng thí nghiệm hai chiều (76 cặp cho thiên vị 8 pp theo cận trên không ghép cặp, khoảng 45 nếu tính theo SE ghép cặp ở mục 5 — cả hai ở power 50%, nhân $(2.8016/1.96)^2 = 2.04$ nếu muốn power 80%), độ dài bằng các cặp mà người chấm ngang nhau, tự khen bằng cách trộn output của chính judge vào bộ chấm.
9. Đóng băng và niêm phong: phiên bản model + prompt + nhiệt độ + seed là một artifact có số hiệu. Đổi một dấu phẩy trong prompt là một judge mới, phải kiểm định lại từ bước 5. Chạy lại toàn bộ quy trình mỗi quý, hoặc ngay khi nhà cung cấp đổi model.

Vì sao cần cả hai vế? Nếu $\kappa_{hh} = 0.85$ mà judge chỉ đạt $\kappa_{jh} = 0.62$, tỉ lệ là $0.62/0.85 = 0.73$ — judge mới với tới 73% trần người, dù $0.62$ nghe rất ổn. Ngược lại nếu chính hai người của bạn chỉ đồng thuận $\kappa_{hh} = 0.55$ thì rubric mới là thứ hỏng, không phải judge, và đòi judge đạt 0.60 là đòi vô lý — quay về Module 06 sửa rubric trước.

Cảnh báo 1 — hai con số tuyệt đối là quy ước. Module 06 đã nói thẳng rằng các mốc kiểu "0.41–0.60 là moderate" là quy ước tiện tay, không phải ngưỡng có cơ sở. Ở đây 0.40 và 0.60 được dùng làm cổng vận hành chỉ vì luôn đi kèm vế thứ hai — tỉ lệ với $\kappa_{hh}$ — và chính vế đó mới là vế có cơ sở. Hai con số tuyệt đối chỉ là sàn tối thiểu.

Cảnh báo 2 — $\kappa_{hh}$ không phải cái trần mà judge không thể vượt. Bước 4 loại hoặc phân xử đúng những câu hai người bất đồng, nên nếu bạn tính $\kappa_{jh}$ trên golden đã lọc đó thì nó đang chấm một tập dễ hơn tập đã sinh ra $\kappa_{hh}$. Mô phỏng 20000 mục, ba nhãn, chạy đúng bước 3 → 4 → 6: người nhiễu 22%, judge nhiễu 35% — judge dở hơn người rõ ràng — vẫn cho $\kappa_{hh} = 0.61$ và $\kappa_{jh} = 0.63$ trên golden đã lọc (còn lại 74% số mục). Judge "vượt trần" trong khi thực chất kém hơn. Tính lại trên toàn bộ mục với nhãn của một người chấm cố định thì $\kappa_{jh}$ tụt về $0.50$, thấp hơn mốc người đúng như phải thế. Tỉ số $\kappa_{jh}/\kappa_{hh}$ chỉ có nghĩa khi hai vế đo trên cùng một tập mục.

Áp bảng ngưỡng lên một judge thật

Golden 200 cặp, ba nhãn: bản A thắng / hoà / bản B thắng.

Bảng này cho $p_o = 0.63$ và $p_e = 13728/40000 = 0.3432$, nên Cohen $\kappa$ không trọng số $= \mathbf{0.437}$ (cách tính từng bước ở Module 06, mục 6). Bootstrap 20000 vòng trên chính 200 mục này cho SD $= 0.051$ và CI 95% $= [0.334;\ 0.535]$.

Nhưng A thắng / hoà / B thắng là thang thứ bậc, đúng cái bẫy Module 06 vừa dựng: nhầm "A thắng" thành "hoà" nhẹ hơn hẳn nhầm "A thắng" thành "B thắng", mà $\kappa$ không trọng số phạt hai lỗi đó như nhau. Ở bảng trên, 65 trong 74 cặp bất đồng chỉ lệch một ô ($14+18+16+17$), chỉ 9 cặp lệch cực đoan ($4+5$). Nên con số đúng để báo cáo là $\kappa$ trọng số tuyến tính — lệch một ô tính nửa lỗi: $p_o^{w} = 0.7925$, $p_e^{w} = 0.5581$, $\kappa_w = \mathbf{0.530}$. Đọc $0.437$ như chặn dưới, $0.530$ như con số chính thức.

Đọc ra quyết định: cả $0.437$ lẫn $0.530$ đều rơi vào ô thứ hai của bảng — chuông báo, không phải trọng tài. So với mốc người $\kappa_{hh} = 0.68$ thì $0.530/0.68 = 78\%$, vẫn dưới vế $0.80$. Hai cách tính cho cùng một quyết định, nhưng nếu bạn lỡ dùng trọng số bình phương thì ra $0.62$ và bảng lật sang ô "nhận" — nên trọng số phải chốt trước khi nhìn số, đúng như Module 06 dặn.

Còn CI rộng $0.20$ thì đừng suy ra "vậy không so được hai judge". Đó là kiểu lập luận "khoảng tin cậy chồng nhau nên không khác nhau" mà Module 04 dành cả module để đập bỏ. Hai judge chấm chung một golden là bài toán ghép cặp: cách đúng là bootstrap lại chính 200 mục đó và lấy CI của hiệu $\kappa_A - \kappa_B$. Với $\mathrm{SE} = 0.051$ mỗi bên và tương quan $\rho = 0.95$ giữa hai judge, $\mathrm{SE}$ của hiệu chỉ còn $0.016$, nên chênh $0.04$ cho $z = 2.48$ — phân biệt được hẳn hoi. Cái CI rộng $0.20$ chỉ nói rằng con số tuyệt đối $0.437$ chưa chắc tới chữ số thứ hai.

7. Ba tình huống KHÔNG được dùng judge

• Judge chính là thứ bạn đang tối ưu. Nếu bạn chọn checkpoint theo điểm judge, rồi lại báo cáo điểm judge như bằng chứng, đó là Goodhart ở Module 00 đội lốt kỹ thuật. Điểm dùng để chọn và điểm dùng để báo cáo phải đến từ hai nguồn khác nhau.
• Judge yếu ở chính ngôn ngữ đó. Judge đọc tiếng Trung tàm tạm và viết tiếng Việt tàm tạm thì nó không phát hiện được rớt Hán-Việt hay sai xưng hô — đúng hai lỗi bạn quan tâm nhất. Cách kiểm: chèn vào golden 30 câu có lỗi cấy sẵn thuộc đúng loại đó và đếm judge bắt được bao nhiêu.
• Lỗi tinh vi, hiếm, và đắt. Một tên nhân vật dịch lệch ở chương 214 so với chương 12 là lỗi giết trải nghiệm đọc, nhưng judge chấm từng câu độc lập không bao giờ thấy nó. Loại lỗi xuyên tài liệu phải bắt bằng luật và bằng người, không bằng judge câu lẻ.

Cần biết trước: Module 00 (bốn tầng eval), Module 05 (MDE và cỡ mẫu) Dựng nên: một bộ test đáng tin và sống lâu Dẫn tới: Module 09 — kỷ luật thí nghiệm

1. Năm cái kho, và năm mũi tên không được phép tồn tại

Câu "bộ test của tôi là 1000 câu lấy ngẫu nhiên từ corpus" nghe có vẻ khách quan. Thực ra nó nói đúng một điều: bạn chưa quyết định bộ test dùng để trả lời câu hỏi gì.

Một dự án dịch zh→vi nghiêm túc có năm kho dữ liệu tách rời, mỗi kho trả lời một câu hỏi khác nhau. Con số dưới đây là thiết kế mẫu ta sẽ dùng suốt module (giả định, nhưng nhất quán từ đầu tới cuối):

• train — 10.4M cặp câu. Câu hỏi: model học được gì?
• dev (validation) — 4 000 câu. Câu hỏi: dừng ở checkpoint nào, chọn siêu tham số nào?
• test — 600 câu, thiết kế theo ma trận phủ. Câu hỏi: bản này có hơn bản trước không?
• golden set — 300 câu, có điểm người theo rubric MQM. Câu hỏi: metric tự động có đang nói thật không?
• bộ hồi quy (regression suite) — 120 câu "không được sai". Câu hỏi: commit vừa rồi có làm hỏng thứ đã từng đúng không?

Năm kho này chỉ có giá trị khi không có dòng dữ liệu nào chảy ngược. Hình dưới vẽ các mũi tên rò rỉ (leakage) đã thật sự xảy ra trong các dự án dịch — bằng nét đứt đỏ.

Golden set: kho duy nhất không bao giờ được dùng để tối ưu

Bốn kho kia đo model. Golden set đo chính cái thước: 300 câu có điểm người theo rubric MQM (Module 06), dùng để trả lời "chrF, COMET hay judge có đang nói thật không" (Module 02 và Module 07).

Chọn câu nào. Lấy mẫu con phân tầng từ đúng ma trận phủ ở mục 2 — 10 hiện tượng × 30 câu = 300 — để mỗi tầng còn đủ câu mà nói, thay vì bốc 300 câu ngẫu nhiên rồi phát hiện tầng thơ chỉ có một câu.

Vì sao 300 chứ không 100. Việc của golden set là ước lượng tương quan giữa metric và người. Với $r = 0.60$, khoảng tin cậy 95% (Fisher, Module 03) trên 100 câu là $[0.46\,;\,0.71]$ — rộng 0.26, không đủ để nói "COMET bám người tốt hơn chrF". Trên 300 câu nó co còn $[0.52\,;\,0.67]$, rộng 0.15.

Hai luật cứng. Một: golden set không bao giờ tham gia chọn checkpoint, chọn siêu tham số hay chỉnh prompt của judge — nó nằm ngoài mọi vòng lặp tối ưu, vì đó là cái thước dùng để kiểm những thước khác. Hai: chỉ chấm lại khi metric hoặc judge đổi, không chấm lại mỗi commit; điểm người là thứ đắt nhất trong cả hệ eval.

2. Ma trận phủ: thiết kế theo hiện tượng, không theo tần suất

Lấy ngẫu nhiên nghĩa là bạn để tần suất tự nhiên của corpus quyết định bộ test. Với web novel, tần suất tự nhiên rất lệch: thoại ngắn chiếm phần lớn, còn thơ và câu đối thì hiếm.

Giả sử thơ/câu đối chiếm 0.3% corpus. Lấy ngẫu nhiên 600 câu, bạn được $600 \times 0.003 = 1.8$ câu — làm tròn là 2. Mà 2 mới chỉ là kỳ vọng: xác suất bốc trúng không câu thơ nào là $0.997^{600} = 16.5\%$, tức cứ sáu lần dựng bộ test thì một lần tầng đó rỗng sạch.

Với 2 câu và $\sigma_d = 8$ điểm câu, MDE của tầng đó (công thức Module 05) là 15.85 điểm. Con số đó còn là bản lạc quan: công thức dùng $z$ nên giả định $n$ lớn; tính lại bằng $t$ với $df = 1$ thì MDE thật là 79.7 điểm. Nghĩa là: model có thể dịch thơ tệ đi 15 điểm mà bạn vẫn không có quyền nói gì. Bạn không phải "đo kém" — bạn hoàn toàn mù với hiện tượng đó.

Ma trận phủ đảo ngược logic: quyết định trước mỗi hiện tượng cần bao nhiêu câu để nhìn thấy một mức tụt đáng lo, rồi mới đi lấy câu.

Tầng thơ/đối bây giờ có 40 câu, không phải 2. MDE của nó tụt từ 15.85 xuống 3.54 điểm — vẫn thô, nhưng đã đủ nhìn thấy một cú gãy thật sự. Số câu đi từ 2 lên 40, tức 20 lần; MDE cải thiện đúng $\sqrt{20} = 4.47$ lần ($15.85/3.54 = 4.48$, lệch chữ số cuối do làm tròn) — luật căn bậc hai, không hơn.

3. Nhiễm dữ liệu: đo trùng lặp bằng hai đại lượng

Nhiễm (contamination) là khi câu trong bộ test, hoặc một bản gần giống nó, đã có mặt trong dữ liệu huấn luyện. Model không dịch nữa — nó nhớ lại. Với web novel thì chuyện này gần như chắc chắn xảy ra: cùng một bộ truyện có nhiều bản dịch trôi nổi trên mạng, và bạn cào cả hai.

Muốn dò thì phải định nghĩa "gần giống" bằng số. Hai đại lượng, đừng lẫn.

Jaccard — đo mức giống nhau của hai tập hợp. Với hai tập $A$ và $B$:

n-gram overlap (containment) — đo phần của câu test đã nằm sẵn trong kho train. Gọi $G_n(x)$ là tập n-gram bậc $n$ của chuỗi $x$, và $G_n(S)$ là hợp mọi n-gram của cả kho $S$:

Chọn bậc $n$ là chọn đánh đổi. Bậc thấp bắt được cả trùng lặp lỏng nhưng báo động giả tràn lan (mọi câu tiếng Việt đều chia nhau từ trong, của). Bậc cao thì sạch nhưng để lọt bản viết lại. Với zh→vi, một cấu hình chạy được: overlap 8-gram trên token đích làm cờ chính, cộng Jaccard 5-gram ký tự (bỏ khoảng trắng) làm cờ phụ để bắt trường hợp tách từ khác nhau.

Không thể duyệt vét cạn — MinHash và LSH

So 600 câu test với 10.4 triệu câu train theo kiểu tất cả với tất cả là $600 \times 1.04{\cdot}10^7 = 6.24$ tỉ phép so tập hợp. Không chạy nổi mỗi lần bạn đổi dữ liệu.

MinHash nén mỗi tập n-gram thành $k$ số nguyên bằng $k$ hàm băm, rồi ước lượng Jaccard bằng tỉ lệ vị trí khớp nhau:

Đây là trung bình của $k$ phép thử Bernoulli với xác suất đúng bằng $J$, nên sai số chuẩn là $\sqrt{J(1-J)/k}$. Với $J = 0.8$: $k = 128$ cho sai số chuẩn 0.0354 và nửa khoảng 95% là ±0.069; muốn xuống ±0.049 phải trả gấp đôi, $k = 256$. Đừng đặt ngưỡng ở 0.80 rồi tin từng chữ số — bản thân ước lượng đã ±0.07.

LSH banding cắt $k$ chữ ký thành $b$ băng, mỗi băng $r$ dòng ($k = br$), rồi chỉ so những cặp rơi trùng ít nhất một băng. Xác suất một cặp trở thành ứng viên:

Với $b=32$, $r=4$, mỗi câu test chỉ cần 32 lần tra bảng băm. Cả bộ test là $600 \times 32 = 19\,200$ lần tra thay vì 6.24 tỉ phép so — nhanh hơn 325 000 lần về số phép toán cấp cao.

4. Nhiễm 10% thổi điểm lên bao nhiêu?

Đây là chỗ phải tính bằng số, vì trực giác của hầu hết mọi người sai theo hướng đánh giá thấp.

Gọi $f$ là tỉ lệ câu test bị nhiễm, $S_c$ là điểm trung bình trên phần sạch, $S_m$ là điểm trên phần bị nhiễm. Điểm bạn báo cáo là trung bình có trọng số:

Kéo thử ở phòng thí nghiệm dưới đây trước khi đọc tiếp: chỉnh ngưỡng overlap, xem bao nhiêu câu bị bắt và điểm bị thổi thay đổi ra sao.

5. Phân tầng: vì sao trung bình che mất cú gãy

Đây là kết quả so hai bản trên đúng bộ 600 câu ở mục 2. Giả định $\sigma_d = 8$ điểm câu cho mọi tầng, hiệu ghép cặp $\Delta = B - A$ (số dương nghĩa là B tốt hơn):

Đọc bảng này ba lần. Con số tổng thể $+0.62 \pm 0.64$ là con số bạn định đưa vào báo cáo, và nó không nói được gì. Nhưng phía dưới, tầng thơ/đối tụt 4.20 điểm với khoảng tin cậy hoàn toàn nằm dưới 0, sống sót cả sau hiệu chỉnh Bonferroni cho 10 phép so. Trung bình đã hoà tan một cú gãy thật vào chín tầng không có gì.

Vì sao nó hoà tan được: tầng thơ chỉ có 40/600 câu, tức trọng số 6.7%. Cú tụt 4.2 điểm đóng góp $40 \times (-4.2)/600 = -0.28$ vào trung bình — bị nuốt gọn bởi $+0.90$ mà chín tầng kia cộng lại.

6. Taxonomy lỗi zh→vi và máy dò tự động

Điểm số nói "tệ đi 4.2 điểm". Taxonomy nói "tệ ở đâu". Mỗi loại lỗi cần một máy dò tự động chạy được trên toàn bộ output — không chờ người đọc.

Chú ý phân biệt hai loại máy dò. Loại tất định (số/đơn vị, glossary, lặp) cho ra đúng/sai, không cần ngưỡng, dùng làm điều kiện chặn cứng trong CI. Loại thống kê (tỉ lệ độ dài, QE) cho ra một điểm số và bạn phải chọn ngưỡng — mỗi ngưỡng là một đánh đổi báo động giả. Ở $\mu \pm 2s$ tỉ lệ báo động giả là 4.55%, trên 600 câu là 27.3 câu người phải đọc; đẩy lên $\mu \pm 3s$ còn 1.6 câu. Đừng đặt máy dò thống kê làm cổng chặn cứng.

7. Bộ hồi quy chạy mỗi commit

Bộ hồi quy không phải bộ test thu nhỏ. Nó là danh sách những thứ đã từng sai và không được sai lại. Mỗi mục sinh ra từ một bug thật, và mang theo số hiệu bug đó.

- id: NAME-0007              # id cố định vĩnh viễn, không đổi kể cả khi sửa câu
  src: "叶凡缓缓睁开眼睛。"
  ref: "Diệp Phàm chậm rãi mở mắt."
  tags: [ten-rieng, xung-ho]  # trùng nhãn của ma trận phủ
  bucket: kho                 # de | vua | kho
  origin: "bug #412 — model dịch 叶凡 thành 'Lá Phàm' từ chương 3"
  added: 2025-11-04
  assert:
    - kind: must_contain        # chặn cứng
      value: "Diệp Phàm"
    - kind: must_not_contain
      value: ["Lá Phàm", "Ye Fan"]
    - kind: numbers_match       # tập số nguồn phải bằng tập số đích
    - kind: no_repeat_4gram
    - kind: chrf_at_least       # chặn mềm, có ngưỡng
      value: 55

Phần ngưỡng để riêng, một chỗ duy nhất, có ghi lý do:

gates:
  hard_assert_pass_rate: 1.00   # 120/120. Một mục hỏng là đỏ CI, không thương lượng.
  chrf_drop_max: 2.5            # so với baseline đang chạy production
  length_ratio_range: [1.25, 3.95]   # mu ± 3s, hiệu chuẩn trên 5 000 cặp
  repeat_4gram_max: 2
decode:                         # cố định để loại phương sai giải mã (Module 03)
  seed: 1234
  beam: 4
  batch: 32
  temperature: 0.0

Vì sao ngưỡng chrF là 2.5 chứ không 1.0. Bộ hồi quy chỉ có 120 câu. Với $\sigma_d = 8$ điểm câu, sai số chuẩn của hiệu là $8/\sqrt{120} = 0.730$. Chú ý cổng này chỉ đỏ khi điểm tụt — trường ở trên tên là chrf_drop_max, không có ngưỡng nào cho chiều tăng — nên mọi xác suất báo động giả dưới đây là một phía.

Đặt ngưỡng 1.0 tức là $1.0/0.730 = 1.37$ lần sai số chuẩn, cho xác suất báo động giả mỗi lần chạy là 8.55%. Với 30 commit một tuần, đó là 2.6 lần đỏ giả mỗi tuần — sau hai tuần cả đội sẽ bỏ qua CI đỏ, và bộ hồi quy chết.

Đặt ở 2.5 tức là 3.42 sai số chuẩn: xác suất báo động giả tụt còn 0.031%, tức khoảng một lần đỏ giả mỗi 108 tuần. Đổi lại, bạn mất khả năng phát hiện những cú tụt nhỏ hơn 2.5 điểm — nhưng đó không phải việc của bộ hồi quy. Việc của nó là phần hard_assert: 120 khẳng định tất định, phương sai bằng 0, không có báo động giả nào cả.

#!/usr/bin/env bash
set -euo pipefail

# 1. Kiểm tra vệ sinh: bộ hồi quy KHÔNG được rò vào train
python -m eval.leakcheck \
  --suite tests/regression/zhvi.yaml \
  --against data/train.manifest.jsonl \
  --ngram 8 --max-overlap 0.30      # vượt là hỏng build, không phải cảnh báo

# 2. Dịch 120 câu với tham số giải mã đã cố định
python -m eval.regress \
  --suite  tests/regression/zhvi.yaml \
  --gates  tests/regression/gates.yaml \
  --model  ckpt/current --baseline ckpt/production \
  --report out/regress.json

# Mã thoát: 0 = xanh · 1 = hard_assert hỏng · 2 = chrF tụt quá ngưỡng

Chi phí: giả sử CTranslate2 int8 chạy 12 câu mỗi giây trên máy CI, 120 câu mất 10 giây. Ba mươi commit một tuần là 300 giây, tức 5 phút máy mỗi tuần. Đây là thứ rẻ nhất trong toàn bộ hệ eval — không có lý do gì để không có nó.

Bước 1 trong script không phải trang trí. Nó chính là mũi tên ④ trong hình ở mục 1: cách sửa bug tự nhiên nhất là thêm câu bị lỗi vào train, và như thế bạn vừa xoá luôn khả năng của bộ hồi quy trong việc phát hiện bug đó tái phát.

8. Bảo trì: test set cũng già đi

Một bộ test không tự hỏng, nhưng nó bị bào mòn theo ba cách.

Một — bạn nhìn nó quá nhiều lần. Mỗi lần bạn thử một thay đổi và giữ lại nếu điểm test lên, bạn đang chọn cực đại của nhiễu: với bộ 600 câu và $\sigma_d = 8$, thử 10 thay đổi hoàn toàn vô dụng vẫn cho +0.50 điểm ở cái tốt nhất. Con số đó không tồn tại ngoài đời — nó là tiền lãi bạn tự trả cho mình. Module 09 đo đầy đủ cơ chế này.

Hai — miền dữ liệu trôi. Bạn bắt đầu với truyện tu tiên, sáu tháng sau người dùng đọc đô thị và trọng sinh. Bộ test cũ vẫn đo đúng thứ nó đo, chỉ là thứ đó không còn quan trọng.

Ba — làm mới thì mất khả năng so. Nếu bạn thay 20% bộ test mỗi 6 tháng thì sau 4 vòng, tức 2 năm, chỉ còn $0.8^4 = 40.96\%$ câu gốc. Tệ hơn: nếu 20% câu mới khó hơn trung bình 5 điểm, điểm tổng tụt $0.2 \times 5 = 1.0$ điểm — từ 34.0 xuống 33.0 — mà model không hề đổi một tham số nào.

Cách xử lý là tách bộ test làm hai phần với hai luật khác nhau:

• Phần neo (anchor), 70% — đóng băng, không bao giờ đổi, chỉ dùng để so theo thời gian. Chấp nhận nó sẽ dần bão hoà.
• Phần luân chuyển, 30% — làm mới mỗi 6 tháng theo phân bố người dùng hiện tại, dùng để đo chất lượng hôm nay.

Khi công bố, luôn báo cáo hai con số riêng và ghi rõ phiên bản bộ test (testset-v3.2, neo v1.0). Một điểm số không kèm phiên bản bộ test cũng vô nghĩa như một điểm số không kèm sai số.

Cần biết trước: Module 04 (p-value, đa so sánh) và Module 05 (power, MDE) Dựng nên: quy trình chạy thí nghiệm không tự lừa Dẫn tới: Module 10 — từ số ra quyết định

1. Preregister ba dòng: viết kết luận trước khi có số

Tám module trước dạy bạn đo. Module này nói về kẻ đứng chen giữa phép đo và kết luận: chính bạn.

Không ai gian lận có ý thức. Cái xảy ra tinh vi hơn nhiều. Bạn nhìn số, số hơi xấu, bạn nghĩ ra một lý do chính đáng để nhìn lại theo cách khác — bỏ mấy câu quá dài, đổi sang chrF, lấy checkpoint kế bên. Lần này số đẹp. Bạn dừng. Từng bước một đều hợp lý; sản phẩm cuối là rác.

Thuốc giải rẻ tiền nhất là đăng ký trước (preregistration): viết ra bạn sẽ kết luận gì với kết quả nào, trước khi có kết quả. Ba dòng là đủ.

GIA THUYET   Them 40k cau song ngu the loai tu tien vao tap train se nang chrF2
             tren tang "tu tien" cua testset-v3, khong lam hong cac tang con lai.

QUYET DINH   Ship neu KTC 95% cua delta chrF2 (paired bootstrap, B=1000) nam tron
             tren +0.30 VA moi tang khac co can duoi KTC khong thap hon -0.40.
             Moi ket qua khac: giu baseline, ghi la that bai, khong chay lai.

KHOA TRUOC   Bo test testset-v3 (600 cau, 10 tang, hash 4f9c...). Metric chinh chrF2,
             ghi kem sacreBLEU signature. Guardrail: ti le sai ten rieng.
             n = 600 co dinh. alpha = 0.05 hai phia. Nhin ket qua DUNG 1 LAN, sau
             khi train xong. Checkpoint = buoc co val-loss thap nhat trong 5 lan eval.
             Ngan sach: 2 nhanh x 6 gio GPU = 12 gio; qua 15 gio thi huy.

Dòng hai là dòng đắt nhất, và cũng là dòng người ta hay bỏ. Nếu bạn không viết ngưỡng trước, bạn sẽ chọn ngưỡng sau khi thấy số. Mục 6 đo giá của thói quen đó: chỉ sáu lối rẽ nhỏ vô hại như vậy đã đẩy tỉ lệ tuyên bố thắng nhầm từ 5.0% lên 17.9%.

2. Mẫu hai nhánh và chốt chặn ngân sách

Mẫu chuẩn của một thí nghiệm dùng được: hai nhánh (arm) khác nhau đúng một thứ. Cùng seed khởi tạo, cùng thứ tự data, cùng cấu hình decode, cùng quy tắc chọn checkpoint, cùng bộ test, cùng phiên bản thư viện. Đổi một biến, giữ nguyên phần còn lại.

Vì sao khắt khe thế? Giả sử bạn đổi cùng lúc ba thứ (thêm data, tăng LoRA rank, đổi learning rate) và nhánh mới thắng. Có $2^3 = 8$ giả thuyết về nguyên nhân — kể cả giả thuyết "không cái nào cả, chỉ là nhiễu".

Tách chúng ra thì có hai đường. Thiết kế giai thừa (factorial design) $2^3$ = 8 nhánh, 6 giờ mỗi nhánh là 48 giờ GPU: đắt, nhưng nó trả về cả ba hiệu ứng chính lẫn bốn tương tác, và mỗi hiệu ứng chính lấy từ 4 run mỗi mức nên sai số chuẩn nhỏ hơn 2 lần so với so 1-vs-1. Rẻ hơn là OFAT — baseline cộng ba nhánh, 4 run, 24 giờ — nhưng mù hoàn toàn với tương tác. Thứ không được làm là đổi ba biến trong một nhánh rồi kết luận: 6 giờ, và trả lời đúng 0 câu hỏi.

Kèm theo là chốt chặn ngân sách (budget guard) — ba con số viết ra trước khi chạy:

• Trần giờ GPU. Quá thì hủy, không "chạy nốt xem sao".
• Trần số lần eval checkpoint, ký hiệu $n$. Đây không phải chuyện tiết kiệm tiền — nó là tham số của một công thức thống kê ở Mục 4: eval 20 checkpoint thổi điểm lên 0.75; eval 5 checkpoint chỉ thổi 0.47.
• Trần số lần nhìn p. Mặc định là 1. Mục 5 cho biết giá của con số này.

Thêm một mẹo rẻ mà ít người làm: chạy một nhánh đối chứng âm (A/A) — lặp lại chính baseline, chỉ đổi seed, chấm trên đúng bộ câu cũ. Vì hai nhánh dùng chung bộ test nên phần phương sai do chọn mẫu test bị triệt tiêu hoàn toàn trong hiệu — đúng cơ chế ghép cặp ở Module 04. Thứ còn lại là nhiễu run-to-run: seed khởi tạo, thứ tự batch, ngẫu nhiên khi giải mã. Nó độc lập giữa hai nhánh, nên $\operatorname{Var}(d) = 2\sigma^2$.

Đó là đại lượng bạn phải tự đo, và nó là đầu vào của mọi thứ còn lại trong module. Giả sử đo được $\sigma = 0.4$ điểm mỗi nhánh: hiệu hai baseline giống hệt nhau vẫn có kỳ vọng trị tuyệt đối $\mathbb{E}|d| = \sigma\sqrt{2}\cdot\sqrt{2/\pi} = 0.45$ điểm, và xác suất lệch quá 0.6 điểm là 28.9%. 95% các hiệu A/A nằm dưới $1.96\,\sigma\sqrt{2} = 1.11$ điểm — đó mới là sàn đo của bạn, không phải một lần chạy lẻ.

3. Loss và eval không trả lời cùng một câu hỏi

Đường loss trên train trả lời: model có đang khớp thêm dữ liệu train không. Đường eval trên val trả lời: thứ bạn thật sự quan tâm có tăng không. Hai câu hỏi khác nhau thì hai đường được phép mâu thuẫn, và chúng mâu thuẫn theo đúng bốn kiểu.

① Khớp tốt. Eval leo rồi bão hoà, loss vẫn bò xuống. Đây là dáng bạn muốn thấy, và điều nó nói là: hết rồi. Train thêm không mua được gì; tiền nên chuyển sang data hoặc kiến trúc.

② Overfit kinh điển. Loss train tiếp tục giảm còn eval quay đầu — ở hình trên, tụt 1.9 điểm khỏi đỉnh. Phản xạ đúng là dừng ở đỉnh. Nhưng nhớ kỹ: chính cái đỉnh đó là con số bị thổi nhiều nhất trong cả run, và Mục 4 sẽ đo thổi bao nhiêu.

③ Loss giảm mà eval đứng. Dáng khó chịu nhất vì trông như đang tiến bộ. Loss giảm 3.1 trong khi eval nhúc nhích đúng 0.6 điểm. Model đang khớp thêm thứ gì đó trong train mà metric của bạn không nhìn thấy — hoặc là chi tiết vô nghĩa, hoặc là chất lượng thật mà BLEU mù. Việc phải làm không phải train tiếp, mà là đọc 20 bản dịch bằng mắt.

④ Cả hai đều nhiễu. Eval nhảy biên độ 5.3 điểm với độ lệch chuẩn 1.3. Chú ý: điểm cao nhất rơi vào mốc thứ 2 trên 26 — nếu đỉnh của bạn nằm ở đầu run thì gần như chắc chắn nó là nhiễu. Ở dáng này mọi câu chuyện bạn kể về đường cong đều là bịa; việc phải làm là tăng cỡ bộ val, cố định seed decode, hoặc eval thưa hơn nhưng lặp lại.

4. Best-checkpoint bias: chọn đỉnh là đã thổi điểm

Đây là chỗ phản trực giác nhất module, nên nói thẳng: chỉ riêng thao tác lấy giá trị lớn nhất trong một dãy số có nhiễu đã tạo ra một khoản thổi dương, ngay cả khi mọi checkpoint tốt như nhau. Bạn không cần overfit gì cả. Bạn chỉ cần chọn max.

Đặt bài toán bằng số. Bạn eval $n$ checkpoint. Chất lượng thật của mọi checkpoint bằng nhau, gọi là $\mu$. Mỗi lần eval cho ra $\hat{\theta}_i = \mu + \varepsilon_i$ với $\varepsilon_i \sim N(0, \sigma^2)$, $\sigma = 0.4$ điểm — đúng con số nhiễu run-to-run đo bằng nhánh A/A ở Mục 2. Bạn báo cáo $\max_i \hat{\theta}_i$. Kỳ vọng của nó là

Hằng số $a_n$ không có dạng đóng gọn với $n$ bất kỳ, nhưng xấp xỉ Blom cho sai số dưới $0.001$ ở $n = 20$:

Đọc bảng cho đau: với 500 câu và $\sigma_d = 8$ — độ lệch chuẩn hiệu ghép cặp theo câu, đúng con số Module 05 đo được — MDE ở power 80% là $2.80 \times 8/\sqrt{500} = 1.00$ điểm.

Hai con số dựng từ hai nguồn phương sai khác nhau — một cái là nhiễu giữa các lần eval, một cái là phương sai của hiệu giữa hai hệ — nhưng cùng đơn vị điểm và cùng trả lời một câu: bao nhiêu điểm thì đáng tin. Độ thổi 0.75 bằng 75% của ngưỡng đó; thao tác chọn đỉnh một mình nó đã sinh ra gần trọn cái "cải tiến" mà bộ val của bạn có khả năng nhìn thấy.

Một sắc thái quan trọng, đo bằng mô phỏng 400 nghìn lần với $n = 20$, $\sigma = 0.4$: nếu các checkpoint thật sự khác nhau, độ thổi co lại. Với độ lệch chuẩn của chất lượng thật $\sigma_{\text{true}} = 0.4$ (bằng đúng nhiễu), độ thổi từ 0.75 xuống 0.53; với $\sigma_{\text{true}} = 1.6$ chỉ còn 0.18.

Nhưng đổi lại xuất hiện thiệt hại thứ hai: bạn chọn nhầm checkpoint. Ở $\sigma_{\text{true}} = 0.4$, checkpoint bạn chọn kém checkpoint tốt nhất thật trung bình 0.22 điểm. Nhiễu vừa thổi phồng con số vừa lấy mất của bạn model tốt nhất.

Bốn cách chữa, theo thứ tự nên làm:

• Chọn trên val, báo cáo trên test. Bộ test chưa từng tham gia chọn lựa nên điểm trên nó không bị thiên vị. Đây là cách khử triệt để mà vẫn giữ được quyền chọn checkpoint theo số, và nó miễn phí.
• Khoá quy tắc chọn trước. "Checkpoint cuối" hoặc "bước 40k" là quy tắc không nhìn số — độ thổi bằng 0.
• Giảm $n$. Eval 5 lần thay vì 20 cắt độ thổi 37.7% (0.75 → 0.47).
• Nếu buộc phải báo điểm val, ghi kèm $n$ và trừ $\sigma a_n$ ra khỏi con số. Đó là lý do sổ run ở Mục 7 bắt buộc lưu $n$.

Kéo thử ở phòng thí nghiệm dưới đây trước khi đọc tiếp: chỉnh tần suất eval, xem đỉnh val và điểm test tương ứng tách nhau ra sao.

5. Peeking: nhìn p nhiều lần thì 5% không còn là 5%

Tình huống quen: bạn đang chấm dần một bộ test, hoặc đang chạy eval trên tập val lớn dần. Cứ thêm 100 câu bạn lại chạy paired test và liếc p. Thấy $p < 0.05$ thì dừng, tuyên bố thắng, đi ăn trưa.

Mô phỏng đúng tình huống đó dưới giả thuyết không: hai hệ thống bằng nhau tuyệt đối, hiệu điểm câu $d_i \sim N(0, 8^2)$, 20 mốc mỗi mốc thêm 100 câu (tối đa 2000 câu), paired t-test hai phía $\alpha = 0.05$ tại mỗi lần nhìn, 400 nghìn lần chạy.

Ba điều đáng nhớ trong bảng này. Thứ nhất, cột "độc lập" là chặn trên chứ không phải đáp án: các lần nhìn dùng dữ liệu chồng lên nhau nên tương quan mạnh, 20 lần nhìn cho 24.9% chứ không phải 64.2%. Thứ hai, một phần tư số run sẽ tuyên bố thắng khi không có gì để thắng. Thứ ba, cột cuối là lối thoát nếu bạn thật sự cần nhìn nhiều lần: hạ ngưỡng xuống 0.0075 thì mức 5% được giữ nguyên — đó là ý tưởng của biên tuần tự kiểu Pocock, và giá phải trả là power thấp hơn.

6. Vườn của những lối rẽ

Peeking là bậc tự do theo thời gian. Còn một loại nữa, âm thầm hơn: bậc tự do theo cách phân tích. Bạn không nhìn lại nhiều lần, bạn chỉ nhìn một lần — nhưng theo sáu góc khác nhau, rồi kể lại góc đẹp nhất.

Mô phỏng: một bộ test 500 câu, hiệu điểm câu $d_i \sim N(0, 8^2)$ tức không có chênh lệch thật. Mỗi câu gắn thêm một độ dài ngẫu nhiên 5–60 token và một nhãn domain A/B ngẫu nhiên, cả hai độc lập với điểm. Sáu lối rẽ hoàn toàn "chính đáng": toàn bộ · chỉ câu ngắn (≤ 20 token) · chỉ câu dài · chỉ domain A · chỉ domain B · cắt 2% đuôi hai bên rồi test như thường. 200 nghìn lần chạy.

Tỉ lệ có ít nhất một lối rẽ báo $p < 0.05$ leo lên theo từng lối bạn thử: 4.97% → 8.96% → 11.38% → 14.13% → 16.82% → 17.87%. Sáu lát cắt vô hại biến mức 5% thành gần 18%. Riêng lối rẽ "cắt 2% đuôi" tự nó đã ăn gian: một mình nó cho 7.48%, vì ngưỡng cắt được chọn từ chính dữ liệu.

Con số 6 còn là rất khiêm tốn. Một dự án dịch thật có bao nhiêu lối rẽ? Ba metric (BLEU, chrF, COMET) × bốn quy tắc chọn checkpoint × hai kiểu tokenize khi chấm × năm cách lọc tập test — đó là 120 lối rẽ. Nếu chúng độc lập thì xác suất có ít nhất một lối cho $p < 0.05$ là 99.8%. Chúng không độc lập nên con số thật thấp hơn, nhưng thông điệp không đổi: với đủ lối rẽ, mọi dữ liệu đều biết nói điều bạn muốn nghe.

Cách chữa không phải là tính toán tinh vi hơn. Nó là ba dòng ở Mục 1, cộng thêm một thói quen: báo cáo cả những lối rẽ bạn đã thử và bỏ đi. Một dòng "đã thử thêm lát cắt theo độ dài, không có ý nghĩa" làm người đọc — kể cả chính bạn ba tháng sau — hiệu chỉnh được kỳ vọng.

7. Sổ ghi run: tối thiểu phải lưu gì

Mọi thứ ở trên vô nghĩa nếu ba tháng sau bạn không dựng lại được run. Tiêu chuẩn đúng không phải "tôi nhớ đại khái" mà là: một người khác, chỉ đọc sổ, chạy lại ra cùng con số. Đây là danh sách tối thiểu — 14 trường, tất cả đều là văn bản; dump ra JSON có thụt lề thì một run đầy đủ nặng 1.8 KB, tức 1000 run vẫn chưa tới 2 MB.

Cần biết trước: cả bốn phần trước — metric (m01–m02), khoảng tin cậy (m03), so hai hệ thống (m04), power (m05), người và judge (m06–m07), bộ test (m08), kỷ luật thí nghiệm (m09) Dựng nên: quyết định cuối cùng, viết ra được bằng số Dẫn tới: Sổ tay thuật ngữ

1. Quyết định là hàm của khoảng tin cậy, không phải của điểm số

Chín module trước dạy bạn đo. Module này dạy bạn dừng đo và làm một việc. Điểm mấu chốt: đầu vào của quyết định không phải con số $\hat{\Delta}$, mà là cả khoảng tin cậy của nó đặt cạnh một ngưỡng thực dụng (practical threshold) $\delta^{*}$ mà bạn đã cam kết trước khi nhìn kết quả.

Đặt bối cảnh số một lần, dùng cho cả module. Giả sử: bộ test phân tầng $n = 1200$ câu zh→vi — đã nới từ 600 câu của m08, đúng vì lý do ở ô CHƯA KẾT LUẬN ĐƯỢC bên dưới; metric chủ là COMET có tham chiếu; độ lệch chuẩn của hiệu điểm câu giữa hai hệ thống đo được là $\sigma_d = 0.055$.

Khi đó sai số chuẩn của hiệu là $0.055/\sqrt{1200} = 0.00159$, nửa rộng khoảng tin cậy 95% là $1.96 \times 0.00159 = 0.00311$, và chênh lệch nhỏ nhất bộ test nhìn thấy được ở power 80% là $(1.96+0.84)\times 0.055/\sqrt{1200} = 0.00445$ (m05). Ngưỡng thực dụng phải nằm trên nền đó: chọn $\delta^{*} = +0.005$.

Đọc bảng từ trên xuống, ô đầu tiên khớp thì dừng. Các điều kiện có chỗ chồng lấn: một CI hoàn toàn nằm trên $\delta^{*}$ đo trên 300 câu vẫn có nửa rộng $0.0062 > \delta^{*}$, tức khớp cả ô SHIP lẫn ô CHƯA KẾT LUẬN ĐƯỢC. Thứ tự đọc là một phần của luật, không phải chi tiết trình bày.

2. Một metric chủ, sáu guardrail, khoá trước khi chạy

Sáu metric nhìn cùng một cặp hệ thống sẽ kể sáu câu chuyện. Nếu bạn được quyền chọn metric sau khi thấy kết quả, bạn luôn thắng: với 6 phép so độc lập ở mức $\alpha = 0.05$, xác suất có ít nhất một cái "thắng" ngay cả khi hai hệ thống bằng hệt nhau là $1 - 0.95^{6} = 26.5\%$. Với 12 phép so (4 metric × 3 checkpoint) con số đó là $46.0\%$ — đúng cơ chế vé số ở Module 04, mục 7.

Một chú thích quan trọng: $46.0\%$ là cận trên, vì công thức $1-0.95^{m}$ giả định $m$ phép so độc lập. Bốn metric chấm trên cùng 1200 câu và ba checkpoint của cùng một run thì tương quan mạnh, nên tỉ lệ thật thấp hơn — m09 đo được 24.9% cho 20 lần nhìn chồng dữ liệu, thay vì 64.2% của công thức độc lập.

Cách chặn duy nhất: metric chủ (primary metric) đúng một cái, chọn trước, có quyền tuyên bố thắng. Mọi thứ còn lại là guardrail — chúng chỉ có quyền phủ quyết, không có quyền tuyên bố thắng. Một guardrail đi lên không phải tin vui đáng báo cáo; nó chỉ là chưa có tin xấu.

Cột cuối là cột quan trọng nhất và cũng là cột hầu như không ai viết. Một ngưỡng nhỏ hơn nền nhiễu của nó là đồ trang trí. Ví dụ sống: guardrail "tỉ lệ lỗi critical không tăng quá 0.5 điểm phần trăm" nghe rất nghiêm túc, nhưng sai số chuẩn của một tỉ lệ 2% trên 300 câu đã là $\sqrt{0.02 \times 0.98/300} = 0.81$ điểm phần trăm. Ngưỡng đó nhỏ hơn nhiễu — nó sẽ kêu bừa hoặc im bừa, tuỳ may rủi.

3. Online eval: A/B, interleaving, và vì sao offline không bao giờ đủ

Bộ test offline đo bản dịch. Người đọc web novel không tiêu thụ bản dịch, họ tiêu thụ một buổi đọc: tốc độ đọc, số lần phải dừng lại đoán nghĩa, số lần bỏ chương giữa chừng. Không metric offline nào chạm tới mấy thứ đó. Offline là bộ lọc để không ship rác; online là bằng chứng để tin rằng đã ship đúng.

A/B: mỗi người một hệ thống

Chia người đọc làm hai nhánh, nhánh A dùng model cũ, nhánh B dùng model mới, so trung bình. Vấn đề: phương sai bạn phải chiến đấu là phương sai giữa người đọc và giữa chương, thứ chẳng liên quan gì tới model. Giả sử tỉ lệ "bấm báo lỗi dịch" trung bình mỗi phiên là 6.0%, độ lệch chuẩn giữa các phiên $\sigma = 0.050$, và bạn muốn phát hiện mức giảm $\Delta = 0.004$ (6.0% → 5.6%). Số phiên cần cho mỗi nhánh:

Tổng 4906 phiên. Ở lưu lượng 400 phiên/ngày, đó là 12.3 ngày.

Interleaving: mỗi người nhận cả hai

Trộn đầu ra của hai hệ thống trong cùng một chương: chia đoạn theo team-draft cân bằng, một nửa số đoạn do A dịch, một nửa do B, thứ tự ưu tiên hoán đổi ngẫu nhiên. Mỗi phiên đọc giờ cho ra một hiệu ghép cặp: tỉ lệ báo lỗi trên đoạn của A trừ tỉ lệ trên đoạn của B, trong cùng một người, cùng một chương, cùng một tâm trạng.

Thay số: $n_{\text{int}} = 7.849 \times 0.014142^2 / 0.004^2 = 98.1 \to$ 99 phiên. So với 4906 phiên của A/B: ít hơn 49.6 lần, và $2/(1-0.96) = 50$ đúng như công thức. Ở 400 phiên/ngày, interleaving xong sau 5.9 giờ thay vì 12.3 ngày.

4. Sau khi ship: canary, trôi, và khiếu nại thành case eval

Ship không phải điểm kết thúc của phép đo, nó là điểm bắt đầu của phép đo rẻ nhất bạn từng có: dữ liệu thật, miễn phí, chảy liên tục.

Canary và luật ba. Canary không phải để đo chất lượng — nó quá ít lưu lượng cho việc đó. Nó để bắt sự cố nhị phân: câu rỗng, lặp vô hạn, tràn bộ nhớ. Ở đây có một quy tắc gọn đáng thuộc: nếu bạn quan sát 0 sự cố trong $n$ lần, giới hạn trên 95% của tỉ lệ sự cố xấp xỉ $3/n$. Với $n = 1000$: giới hạn trên $0.30\%$ (giá trị chính xác $1 - 0.05^{1/1000} = 0.2991\%$). Với $n = 5000$: $0.060\%$.

Ngược lại: muốn nhìn thấy ít nhất một sự cố có tỉ lệ thật 2% với xác suất 95%, bạn cần $n = \ln(0.05)/\ln(0.98) = 148.3 \to 149$ đoạn. Đó là lý do cổng canary 1000 đoạn đủ rộng để bắt lỗi thảm hoạ, nhưng hoàn toàn vô dụng để phân biệt 2% với 4%.

Phát hiện trôi. Dữ liệu vào thay đổi: truyện mới đổi thể loại, tác giả mới, độ dài câu khác. Cách rẻ nhất là chạy một metric không cần tham chiếu (COMET-QE) trên chính lưu lượng thật rồi đặt biểu đồ kiểm soát.

Với 2000 câu mỗi tuần và độ lệch chuẩn điểm QE mỗi câu là $0.12$, sai số chuẩn của trung bình tuần là $0.12/\sqrt{2000} = 0.00268$; ngưỡng $3\sigma$ là 0.0080 điểm QE. Báo động giả của ngưỡng $3\sigma$ hai phía là $0.27\%$ mỗi lần kiểm — kiểm hằng tuần thì trung bình 370 tuần (7.1 năm) mới kêu nhầm một lần; kiểm hằng ngày thì 370 ngày, tức một lần mỗi năm. Tần suất kiểm là một tham số bạn phải chọn có ý thức, không phải để mặc định.

Khiếu nại là dữ liệu vàng. Mỗi báo lỗi của người đọc là một câu mà bạn biết chắc đã sai và biết chắc có người quan tâm. Ở 400 phiên/ngày với tỉ lệ khiếu nại 1 trên 500 phiên, bạn nhận 0.8 case/ngày — sau một chu kỳ 8 tuần là khoảng 45 case. Ném chúng vào taxonomy lỗi zh→vi (m08), giữ lại những cái tái lập được, và bộ hồi quy của bạn lớn lên bằng đúng những lỗi mà thế giới thật quan tâm.

5. Eval ngốn bao nhiêu ngân sách

Câu trả lời làm nhiều người khó chịu: nhiều hơn tiền train, rất nhiều. Bảng dưới dùng đơn giá giả định rõ ràng cho một chu kỳ 8 tuần, một người, để bạn thay số của mình vào.

Đọc ra ba con số:

• Eval chiếm 87.8% tổng ngân sách ($693.29/789.29$) khi tính cả công người. Không phải vì eval đắt, mà vì GPU rẻ đến vô lý so với người.
• Nếu chỉ tính tiền máy, eval chiếm 18.2% ($21.29/117.29$). Đây là con số dùng để tranh luận với người quản chi phí hạ tầng, và 15–25% là vùng lành mạnh: dưới 10% nghĩa là bạn đang bay mù, trên 40% nghĩa là bạn đang đo nhiều hơn làm.
• Judge rẻ hơn người 80.8 lần ($240.00/2.97$). Tỉ số 123 lần ở m07 còn cao hơn vì ở đó judge là model rẻ và người chấm theo thang nhanh 45 giây/câu. Dù là 80 hay 123, đó vẫn là lý do judge tồn tại — và cũng chính là lý do phải kiểm định nó bằng $\kappa$ trước khi tin (m07). Nếu chấm người ở mọi run, tức 8 lần đúng theo cột "Số lần" của hàng Train, thì hoá đơn là 1920 USD, gấp 20 lần toàn bộ chi phí train.

Kết luận thực dụng: chạy eval tự động mỗi commit (6 xu một lần; riêng 120 câu hồi quy chỉ mất 10 giây GPU ở tốc độ 12 câu/giây), judge ở mỗi mốc lớn, người chỉ ở cổng ship. Đừng phân bổ ngược lại.

6. Checklist 14 điểm trước khi công bố một con số

Chạy từ trên xuống. Mỗi dòng là một hành động có kết quả nhìn thấy được, không phải một lời tự nhủ.

1. Ghi vào một dòng log duy nhất: commit hash của code, hash của checkpoint, signature sacreBLEU, seed. Dán nguyên dòng đó vào báo cáo.
2. Chạy lại toàn bộ pipeline eval từ đầu trên môi trường sạch. Hai lần chạy phải trùng nhau tới chữ số thập phân thứ ba; nếu không, truy ra nguồn ngẫu nhiên trước khi làm tiếp.
3. Đo nhiễm: tỉ lệ câu test có 8-gram trùng với dữ liệu train phải dưới 0.5%. In ra danh sách câu vi phạm và tự đọc, đừng chỉ đọc con số.
4. Đếm số câu thực sự được chấm rồi so với số dòng trong file test. Lệch một dòng nghĩa là có câu decode rỗng bị lặng lẽ bỏ qua.
5. So hash hai file output của hai hệ thống. Trùng hash nghĩa là bạn đang so một model với chính nó — lỗi này xảy ra thường xuyên hơn bạn nghĩ.
6. Tính CI 95% bằng paired bootstrap với $B = 10\,000$ — $B = 1000$ chỉ đủ cho vòng lặp phát triển hằng ngày (m03). Báo cáo đầy đủ theo mẫu của m03: 34.2, CI 95% [33.1, 35.3], bootstrap percentile, B=10^4, n=500 — 34.2 ± 1.1 trọn lỏn không đủ, và không bao giờ báo cáo bốn chữ số thập phân.
7. Viết cạnh kết quả: nửa rộng CI và MDE của bộ test. Nếu hiệu bạn khoe nhỏ hơn MDE, viết thẳng câu "bộ test này mù với chênh lệch đó".
8. Đếm tổng số phép so đã làm trong cả chu kỳ (mọi checkpoint × mọi metric) và ghi con số đó ngay cạnh p-value. Với 12 phép so độc lập, xác suất có ít nhất một cái "thắng" nhầm lên tới 46.0% — cận trên, xem m04.
9. Mở bản preregister ba dòng viết trước khi train và đối chiếu. Nếu kết luận lệch khỏi nó, ghi rõ chỗ lệch — tuyệt đối không sửa lại preregister.
10. Chạy đủ cả 6 guardrail và dán nguyên bảng kết quả, kể cả những ô không đạt.
11. Báo cáo phân tầng ít nhất 4 tầng (thể loại, độ dài, có/không hội thoại, có/không tên riêng). Nếu một tầng tụt, con số trung bình mất quyền làm kết luận.
12. Đọc tay 20 câu mà bản mới dịch tệ hơn bản cũ nhiều nhất. Nếu không giải thích được ít nhất 15 trong 20, bạn chưa hiểu chuyện gì đã xảy ra.
13. Ghi chi phí đã tiêu để có con số này: giờ GPU, số câu chấm người, tiền judge. Một cải thiện phải chia được cho chi phí của nó.
14. Ghi ngày hết hạn của kết luận: sau bao nhiêu tuần, hoặc sau bao nhiêu lần thay đổi dữ liệu, thì con số này phải được đo lại mới được trích dẫn tiếp.

7. Bốn dự án luyện tay

Dự án 1 — Bảng quyết định của chính bạn

• Đầu vào: 3 checkpoint gần nhất, bộ test hiện có, log train của cả ba.
• Việc phải làm: tính $\sigma_d$ thật của metric chủ trên bộ test hiện có (độ lệch chuẩn của vector hiệu điểm câu); từ đó ra SE, nửa rộng CI 95%, MDE 80%; chọn $\delta^{*}$ nằm trên MDE; viết ra bảng 6 ô ở mục 1 với ngưỡng số của riêng bạn; ghi ngày và commit hash.
• Xong khi: bảng nằm trong repo dưới dạng file văn bản, và bạn đã chạy nó ngược trên 3 quyết định ship gần nhất — nếu không có quyết định cũ nào bị bảng này bác, ngưỡng của bạn đang quá lỏng.

Dự án 2 — Đo nền nhiễu của mọi guardrail

• Đầu vào: danh sách guardrail bạn đang dùng; nếu chưa có, lấy 6 dòng ở bảng mục 2.
• Việc phải làm: với từng guardrail, tính sai số chuẩn trên đúng cỡ mẫu bạn đang dùng (tỉ lệ thì $\sqrt{p(1-p)/n}$, điểm liên tục thì $\sigma_d/\sqrt{n}$); đặt ngưỡng bạn đang khai cạnh $1.96 \times \mathrm{SE}$; đánh dấu mọi ngưỡng nhỏ hơn nền nhiễu.
• Xong khi: mỗi guardrail hoặc có ngưỡng $\geq 2 \times \mathrm{SE}$, hoặc bị hạ cấp thành "cảnh báo" không có quyền phủ quyết. Mốc để tự kiểm: với 300 câu và tỉ lệ nền 2%, mọi ngưỡng dưới 1.58 điểm phần trăm là đồ trang trí.

Dự án 3 — Một vòng interleaving thật

• Đầu vào: hai hệ thống đã chạy được, một kênh có người đọc thật (30 người cũng đủ để bắt đầu).
• Việc phải làm: chia đoạn theo team-draft cân bằng và ghi nhật ký bên nào được ưu tiên đoạn đầu; thu ít nhất một tín hiệu (báo lỗi, sửa tay, bỏ chương); tính hiệu ghép cặp theo từng phiên; đo tương quan $\rho$ giữa hai nhánh trong cùng phiên; chạy thêm một nhánh A-vs-A để biết nhiễu nền của thiết kế.
• Xong khi: bạn có $\rho$ đo được (không phải đoán) và tính ra lợi $2/(1-\rho)$ của chính mình; tỉ lệ ưu tiên đoạn đầu nằm trong khoảng 45–55%; và nếu $\rho < 0.8$ thì bạn đã tìm ra, ghi lại nguyên nhân (trộn xuyên chương, đơn vị trộn quá to, độ dài đoạn lệch).

Dự án 4 — Biến 30 khiếu nại thành bộ hồi quy

• Đầu vào: 30 phản hồi hoặc khiếu nại gần nhất từ người đọc (ở tỉ lệ 0.8 case/ngày thì đó là khoảng 5 tuần thu thập).
• Việc phải làm: gán mỗi cái vào taxonomy lỗi zh→vi; giữ lại những cái tái lập được và viết bản dịch đúng do người viết; chấm model hiện tại trên 30 câu đó; đánh dấu câu nào thuộc mức critical và đặt luật "không được sai".
• Xong khi: 30 câu nằm trong bộ hồi quy chạy mỗi commit (120 câu ở 12 câu/giây chỉ mất 10 giây GPU), CI được cấu hình chặn merge khi bất kỳ câu critical nào hỏng, và bạn đã kiểm bằng cách cố tình đẩy một commit làm hỏng một câu để xem CI có chặn thật không.

8. Khép vòng: ba quyển nói chuyện với nhau

Bảng quyết định ở mục 1 không kết thúc ở đây — ba trong sáu ô của nó là cửa dẫn sang hai quyển kia. Ô thêm data và ô đổi kiến trúc đưa bạn về Lò Luyện Chọn Model: pipeline dữ liệu, tokenizer, distillation, DPO, quantization, scaling — mọi can thiệp bạn có thể thực hiện sau khi con số đã chỉ đúng chỗ đau.

Còn khi guardrail chỉ ra một lỗi mà bạn không giải thích nổi bằng dữ liệu — attention nhìn sai chỗ, tokenizer băm nát tên riêng, embedding không tách nổi hai cách xưng hô — thì cửa còn lại là Lò Luyện Mạng Nơ-ron, nơi mổ cơ chế bên trong.

Ba quyển là một vòng lặp chứ không phải một hàng dọc: cơ chế → quyết định khi train → đo lường → quay lại cơ chế. Quyển này giữ vai trò cái đồng hồ. Nếu đồng hồ sai, hai quyển kia chỉ giúp bạn chạy nhanh hơn về phía sai hướng.

Câu cuối cùng, đúng bằng câu mở đầu quyển: một con số không kèm sai số là một tin đồn. Sau mười module, bạn đã có đủ công cụ để không phải phát tán tin đồn nào nữa — bootstrap cho khoảng, ghép cặp cho phép so, power cho cỡ mẫu, $\kappa$ cho người chấm, guardrail cho quyền phủ quyết, và một bảng sáu ô để cái miệng không chạy trước cái khoảng tin cậy.

Tra nhanh khi đọc tài liệu tiếng Anh. Số trong ngoặc là module giải thích kỹ.