Lò Luyện Giải Phẫu

Trong dự án stv-lite v3, bộ Term Verifier đứng sau bộ dò thuật ngữ bằng luật (rule-based detector): detector đề xuất một ứng viên (như 叶凡 hay 方才), còn verifier tính xác suất $p = \sigma(z)$ để ra một trong ba quyết định:

• Giữ tự động (Keep): nếu $p \ge \tau_{\text{keep}}$.
• Đẩy cho người duyệt (Review): nếu $\tau_{\text{review}} \le p < \tau_{\text{keep}}$.
• Bỏ tự động (Reject): nếu $p < \tau_{\text{review}}$ hoặc dính luật chặn cứng (rejectGuards).

1. Phát hiện số 1: 10 bản Logistic Regression chỉ có 4 lần train thật

Khi script tools/extract/term_verifier.py quét toàn bộ 16 bản đã ship và 77 bản nghiên cứu (tổng cộng 93 artifact, lên tới v23), nó tách riêng các trọng số thực sự học từ Gradient Descent khỏi các trọng số nguyên được chèn bằng tay ($\lvert w_i \rvert \ge 5, w_i \in \mathbb{Z}$) rồi so khớp từng phần tử với độ chính xác $10^{-9}$:

Trong Hồi quy Logistic, xác suất được tính từ tổng tuyến tính của các đặc trưng:

Để đạt ngưỡng keepThreshold = 0.98, ứng viên cần đạt điểm logit tối thiểu:

Khi phát hiện các từ tiếng Trung thông dụng (như 方才 - vừa nãy) bị bộ dò thống kê nhầm thành tên nhân vật vì đứng đầu câu, thay vì gom thêm hàng nghìn mẫu và train lại toàn bộ model (dễ làm xáo trộn ranh giới của các tên người thật), tác giả đã chèn thẳng một đặc trưng nhị phân isKnownCommonTerm với trọng số đặt tay $w = -14$ (ở v5–v7) rồi tăng lên $w = -17$ (từ v8 trở đi).

Hãy tính nhẩm: dù toàn bộ 47 đặc trưng học được có cộng dồn cho từ đó một điểm logit rất cao là $+5.0$, chỉ cần isKnownCommonTerm = 1, tổng logit lập tức bị kéo tụt xuống $5.0 - 17.0 = -12.0$, ứng với xác suất $\sigma(-12) \approx 6.1 \times 10^{-6} \ll \tau_{\text{review}}$, đẩy thẳng ứng viên vào thùng Reject!

Khi chuyển sang GBDT (v11–v23): logitOffsets ra đời

Hồi quy tuyến tính không tự bắt được các tương tác bậc cao (ví dụ: một chuỗi 4 chữ có hậu tố công pháp 诀 chỉ đáng tin khi không bị kẹp giữa các hư từ). Từ v11, hệ thống chuyển sang Gradient Boosted Decision Trees (GBDT) với 156–281 cây quyết định và hơn 100 đặc trưng. Nhưng cây quyết định học từ dữ liệu có thể không phạt đủ nặng một từ nằm trong danh sách từ thường nếu từ đó xuất hiện tới 200 lần trong truyện. Giải pháp kỹ thuật cực kỳ thực dụng trong production:

Hai trọng số isKnownCommonTerm: -17 và contextModifierBeforeCount: -8 từ thời Logistic Regression bước nguyên vẹn sang kỷ nguyên GBDT mà không đổi một con số nào!

Khi giải phẫu file config.json của LTP tiny, ta thấy vocab_size = 21128 và hidden_size = 256. Nếu nhân theo thói quen của BERT chuẩn ($V \times H = 21\,128 \times 256 = 5\,408\,768$), bạn sẽ ước lượng sai gấp đôi! Lý do: LTP dùng kiến trúc ELECTRA với bảng nhúng phân tách (Factorized Embedding) embedding_size = 128:

Thay số thật của LTP tiny ($V=21\,128, P_{\max}=512, T=2, E=128, H=256$):

• Bảng nhúng: $(21\,128 + 512 + 2) \times 128 = 2\,770\,176$ tham số.
• Ma trận chiếu lên không gian ẩn: $128 \times 256 = 32\,768$ tham số.
• Tổng khối nhúng chỉ còn $2.80\text{M}$ thay vì $5.54\text{M}$ (tiết kiệm gần $50\%$ dung lượng vocab!).

Cân nặng thật của 6 cái “Đầu” (Task Heads)

Một ngộ nhận phổ biến là “task head chỉ là một lớp Linear mỏng dính ở cuối”. Điều đó chỉ đúng với cws (tách từ, 2 nhãn: $256 \times 2 = 512$ tham số) và pos (từ loại, 27 nhãn: $256 \times 27 = 6\,912$ tham số). Ngược lại:

• Đầu ner (RelTransformerTokenClassifier): Cắm thêm 2 tầng Relative Transformer riêng ($H=256$, 4 heads) trước khi phân loại 13 nhãn — ngốn thêm $1.58\text{M}$ tham số ở bản tiny và $14.17\text{M}$ tham số ở bản base!
• Đầu srl (BiaffineTokenClassifier): Dùng tích song tuyến tính giữa mọi cặp vị trí vị ngữ – đối số với tensor bậc ba kích thước $L \times (d + 1) \times (d + 1)$ ($L = 97$ nhãn ngữ nghĩa). Ở LTP base1 ($d=600$), riêng cái đầu srl này ngốn $35.96\text{M}$ tham số!

Để chạy NER trực tiếp trong trình duyệt với ngân sách ~1 triệu tham số và tốc độ trên 7.000–9.500 câu/giây, nhánh Branch-C (branch_c_tiny_span_h128_*) bỏ hoàn toàn Self-Attention bậc hai $O(T^2)$ và thay bằng 8 tầng Tích chập 1D Giãn nở (Dilated TCN) với kích thước nhân $k = 3$, chiều ẩn $H = 128$, và lịch giãn nở (dilation schedule):

Ở mỗi tầng có hệ số giãn $d_\ell$ và nhân $k = 3$ (bán kính $\frac{k-1}{2} = 1$), tầm nhìn mở rộng sang mỗi bên đúng $d_\ell$ ký tự. Sau $L$ tầng chồng lên nhau, trường tiếp nhận (Receptive Field) tính bằng số ký tự là:

Chỉ với $393\,216$ tham số tích chập (nhẹ hơn cả một tầng BERT!), mỗi ký tự đã nhìn bao quát 131 ký tự xung quanh — dư sức bao trọn một câu văn web novel tiếng Trung.

Tại sao Span Sampling là chìa khóa sống còn khi train Span-based NER?

Thay vì gán nhãn BIO cho từng chữ, Branch-C xét mọi đoạn con có độ dài từ min_span = 2 đến max_span = 6 và phân loại vào 4 nhãn: none, Nh (tên người), Ns (địa danh), Ni (tổ chức). Trên 129.203 câu huấn luyện, tổng số đoạn ứng viên được liệt kê lên tới 265.720.290 span, nhưng chỉ có 1.288.620 span dương tính thật ($0.485\%$)!

Nếu đưa cả 265,7 triệu span vào hàm loss, mô hình vừa tốn gấp 5 lần thời gian train vừa bị ngập trong các đoạn rác dễ đoán. Báo cáo huấn luyện trong data/ner-architectures.json cho thấy chiến lược lấy mẫu phân tầng 4 vai trò (Role-based Span Sampling) giữ lại đúng 56.874.420 span ($21.4\%$):

• Positive ($1.29\text{M}$): giữ $100\%$ mọi thực thể thật.
• Boundary ($30.00\text{M}$): các đoạn lệch 1 ký tự ở biên trái/phải của thực thể thật — buộc mô hình học ranh giới sắc nét, không ăn lẹm hư từ liền kề.
• Hard Negative ($12.68\text{M}$): các đoạn không phải thực thể nhưng có điểm dự đoán cao (dễ nhầm).
• Random Negative ($12.90\text{M}$): mẫu nền ngẫu nhiên để giữ hiệu chuẩn xác suất toàn cục.

Manifest data/ner-bakeoff.json trích xuất ba bộ benchmark chạy thực tế trên trình duyệt Chrome với 3 hệ thống NER: ltp_tinyD2b (11.02 MB), uer_tiny (6.10 MB), và minirbt_h256 (19.77 MB). Nếu một kỹ sư chỉ nhìn cột batchMsMedian rồi vội vàng vẽ biểu đồ kết luận “model nào nhanh nhất” hoặc “int8 làm chậm WebGPU”, họ sẽ mắc ngay ba sai lầm phương pháp luận nghiêm trọng mà chính tác giả đã cảnh báo trong trường caveats[]:

Giải mã 3 hiện tượng kỹ thuật đằng sau bảng số

1. Hiện tượng 1 — Khoảng cách giãn gấp 4 lần khi đổi GPU (1.2× → 4.8×): uer_tiny (6.1 MB) và minirbt_h256 (19.77 MB) chạy trên cùng một runtime (onnxruntime-web 1.27.0 WebGPU fp16), nên phép so sánh giữa hai hệ này là hoàn toàn hợp lệ. Ở chế độ Batch 32 câu (996 token), trên card rời RTX 5070 Ti Blackwell, độ trễ là 5.1 ms so với 6.2 ms (chênh 1.22×). Nhưng khi đem nguyên xi sang GPU tích hợp Intel Xe-LPG, uer_tiny mất 8.6 ms còn minirbt_h256 vọt lên 41.1 ms (chênh 4.78×)! Nguyên nhân: ở batch 32, lượng trọng số nearly 20 MB cùng tensor kích hoạt trung gian của minirbt_h256 vượt ngưỡng bộ nhớ đệm (cache) trên iGPU dùng RAM hệ thống băng thông thấp, gây nghẽn băng thông bộ nhớ (memory-bandwidth bound). Bài học: Benchmark trên máy trạm GPU rời không bao giờ được ngoại suy tuyến tính sang máy người dùng cuối chạy iGPU.
2. Hiện tượng 2 — Trộn lẫn Engine với Kiến trúc (Confounding Variable): ltp_tinyD2b chạy trên bộ shader custom WGSL f16 tự viết, trong khi hai hệ kia chạy trên onnxruntime-web. Khi hai hệ thống khác nhau đồng thời cả kiến trúc mô hình lẫn trình thực thi kernel, mọi phép so sánh trực tiếp đều bị nhiễu trộn (confounded).
3. Hiện tượng 3 — Nghịch lý dynamic_q8 chậm gấp 7.6 lần fp16: Trong lượt chạy thứ 3 trên RTX 5070 Ti, minirbt_h256_fp16 chạy mất 7.0 ms, nhưng bản lượng tử hóa minirbt_h256_dynamic_q8 lại mất tới 53.55 ms (chậm hơn 7.6 lần!). Đó không phải lỗi của toán học int8, mà vì trong phiên bản onnxruntime-web thử nghiệm đó, WebGPU Execution Provider chưa hỗ trợ đầy đủ các toán tử lượng tử hóa động (như DynamicQuantizeLinear / MatMulInteger), khiến đồ thị bị cắt vụn: các node lượng tử bị đẩy ngược về CPU/WASM xử lý rồi copy tensor qua lại giữa RAM và VRAM ở mỗi tầng!