Kiểm thử một Engine âm vận học khó như thế nào? Bên trong quy trình QA của Quizzman Fanqie Engine

Chuỗi Quizzman Fanqie Engine — Phần 13

• ← Phần 1: Quizzman Fanqie Engine là gì?
• ← Phần 2: Lịch sử phản thiết
• ← Phần 3: Âm Hán Việt hình thành
• ← Phần 4: Tái dựng Middle Chinese
• ← Phần 5: Thuật toán suy diễn Hán Việt
• ← Phần 6: Eight Tone Slot
• ← Phần 7: Hệ thống vận mẫu · 16 nhiếp
• ← Phần 8: Lexical Normalization
• ← Phần 9: Độ chính xác · Benchmark
• ← Phần 10: Không phải từ điển Hán Việt
• ← Phần 11: Hành trình phát triển · V6
• ← Phần 12: MC → Pinyin & Hán Việt
• Chuyên mục: Phiên thiết

Phần mềm thông thường có thể kiểm thử bằng cách so sánh đầu ra với kết quả mong đợi. Nhưng đối với một engine âm vận học lịch sử, bài toán phức tạp hơn rất nhiều. Một chữ Hán có thể có nhiều phản thiết, nhiều lớp đọc, nhiều nguồn tư liệu và nhiều biến thể lịch sử. Nếu chỉ dùng tiêu chí "đúng" hoặc "sai", rất nhiều kết quả sẽ bị đánh giá sai bản chất. Chính vì vậy, Quizzman Fanqie Engine được xây dựng cùng với một hệ thống kiểm thử nhiều tầng, nơi mỗi quyết định của thuật toán đều có thể được kiểm chứng, phân loại và truy vết.

Tại sao kiểm thử một Fanqie Engine lại khó?

Hãy thử tưởng tượng một bài toán rất đơn giản.

國

↓

quốc

Nếu đây là một từ điển điện tử, việc kiểm thử rất dễ.

Expected

↓

quốc

Actual

↓

quốc

Nếu hai kết quả giống nhau, bài kiểm thử thành công.

Nhưng đối với Quizzman Fanqie Engine, mọi thứ không đơn giản như vậy.

Engine không chỉ tạo ra:

quốc

Nó còn phải quyết định:

• phản thiết nào được sử dụng;
• Middle Chinese được phục dựng ra sao;
• thanh mẫu nào được chọn;
• vận nào được chọn;
• thanh điệu phát triển như thế nào;
• vì sao kết quả cuối cùng lại là "quốc".

Chỉ cần một bước trong số đó sai, toàn bộ chuỗi suy luận có thể bị ảnh hưởng.

Một kết quả đúng chưa chắc thuật toán đúng

Giả sử engine trả về:

quốc

Điều này chưa đủ để kết luận thuật toán đúng.

Có thể engine:

• phục dựng sai Middle Chinese;
• chọn nhầm phản thiết;
• áp dụng sai quy luật;
• nhưng vô tình vẫn tạo ra "quốc".

Đây được gọi là đúng do trùng hợp.

Nếu không phát hiện, những lỗi như vậy sẽ lan sang hàng trăm chữ Hán khác.

Đó là lý do Quizzman Fanqie Engine không chỉ kiểm tra đầu ra cuối cùng.

Engine kiểm tra toàn bộ quá trình.

Kiểm thử theo từng tầng

Pipeline của Quizzman Fanqie Engine được chia thành nhiều bước.

Phản thiết

↓

Middle Chinese

↓

Projection

↓

Lexical

↓

Hybrid

Mỗi tầng đều có bộ kiểm thử riêng.

Ví dụ:

• Parser Test
• Middle Chinese Test
• Tone Test
• Rime Test
• Projection Test
• Candidate Ranking Test
• API Test

Nhờ đó, khi xuất hiện lỗi, nhóm phát triển có thể biết chính xác vấn đề nằm ở đâu.

Golden Fixture

Một trong những thành phần quan trọng nhất của hệ thống QA là Golden Fixture.

Đây là tập dữ liệu chuẩn được kiểm chứng thủ công.

Khác với benchmark thông thường, Golden Fixture không cố gắng bao phủ thật nhiều chữ.

Thay vào đó, nó lựa chọn những trường hợp đại diện cho từng quy luật.

Ví dụ:

• Bình thanh;
• Thưởng thanh;
• Khứ thanh;
• Nhập thanh;
• thanh mẫu thanh;
• thanh mẫu trọc;
• nhập thanh kết thúc bằng -p, -t, -c, -ch;
• các ngoại lệ lịch sử.

Nếu một thay đổi làm hỏng chỉ một quy luật nhỏ, Golden Fixture sẽ phát hiện ngay.

Regression Test

Một trong những nỗi lo lớn nhất của bất kỳ Rule Engine nào là:

Sửa đúng một chỗ nhưng làm hỏng mười chỗ khác.

Ví dụ.

Một thay đổi nhằm cải thiện:

江攝

có thể vô tình ảnh hưởng tới:

宕攝

Hoặc:

次濁平

↓

Ngang

có thể làm hỏng hàng trăm chữ khác nếu triển khai sai.

Do đó, sau mỗi thay đổi, toàn bộ bộ kiểm thử đều được chạy lại.

Nếu xuất hiện lỗi hồi quy (Regression), thay đổi sẽ bị xem xét trước khi được đưa vào phiên bản chính thức.

Kiểm thử thanh điệu

Thanh điệu là một trong những thành phần dễ phát sinh lỗi nhất.

Một bài kiểm thử không chỉ xác nhận:

sắc

hay

nặng

Mà còn xác nhận:

• slot lịch sử;
• âm hay dương;
• Bình, Thưởng, Khứ hay Nhập;
• điều kiện thanh mẫu.

Ví dụ.

Một chữ thuộc:

Thứ trọc

+

Bình thanh

phải được kiểm tra xem có rơi vào đúng quy luật phát triển sang ngang hay không.

Điều này giúp tránh việc những thay đổi nhỏ trong thuật toán thanh điệu làm phá vỡ các quy luật lịch sử đã được xác nhận.

Kiểm thử vận mẫu

Tương tự, hệ thống vận mẫu cũng được kiểm thử độc lập.

Ví dụ:

• Thông nhiếp;
• Giang nhiếp;
• Cảnh nhiếp;
• Lưu nhiếp;
• Thâm nhiếp.

Đối với Nhập thanh, engine còn phải kiểm tra:

-p

-t

-c

-ch

Không chỉ đúng âm cuối.

Mà còn đúng điều kiện phát sinh âm cuối đó.

Ví dụ:

-k

↓

-c

khác với:

-k

↓

-ch

dù kết quả đều xuất phát từ cùng một phụ âm cuối của tiếng Hán Trung Cổ.

Candidate Audit

Một chữ Hán có thể tồn tại:

• nhiều phản thiết;
• nhiều nguồn;
• nhiều cách phục dựng.

Do đó, chỉ kiểm thử kết quả cuối cùng là chưa đủ.

Quizzman Fanqie Engine còn kiểm thử:

• thứ tự xếp hạng ứng viên;
• điểm số của từng ứng viên;
• lý do một ứng viên được chọn.

Điều này giúp Candidate Ranking hoạt động ổn định ngay cả khi dữ liệu ngày càng lớn.

Batch Audit

Ngoài các bài kiểm thử đơn lẻ, engine còn được chạy trên những tập dữ liệu lớn.

Ví dụ:

• Random Corpus;
• Benchmark;
• Corpus chuẩn;
• Audit hàng nghìn chữ Hán.

Mục tiêu không chỉ là đo độ chính xác.

Quan trọng hơn là phát hiện:

• quy luật mới bị phá vỡ;
• vùng dữ liệu có nhiều lỗi;
• những thay đổi bất thường sau mỗi bản cập nhật.

Đây là cách nhóm phát triển theo dõi chất lượng của toàn bộ hệ thống theo thời gian.

Phân loại lỗi thay vì chỉ đếm lỗi

Một trong những điểm khác biệt của Quizzman Fanqie Engine là:

Không phải mọi sai khác đều được xem là "lỗi".

Sau khi chạy audit, hệ thống sẽ phân loại.

Ví dụ:

• True Rule Error – thuật toán âm vị thực sự sai.
• Colloquial Variant – khác do lớp khẩu ngữ.
• Polyphonic Character – chữ đa âm.
• Orthographic Difference – khác cách ghi chính tả.
• Historical Variant – biến thể lịch sử.
• Lexical Difference – khác lớp từ vựng.

Nhờ cách phân loại này, nhóm phát triển biết chính xác nên sửa thuật toán hay chỉ cần cập nhật dữ liệu.

Kiểm thử API

Ngoài thuật toán, toàn bộ giao diện lập trình cũng được kiểm thử.

Ví dụ:

• phân tích phản thiết;
• sinh Hán Việt;
• sinh Pinyin;
• truy vấn ngược;
• projection;
• health check.

Mục tiêu là đảm bảo người dùng luôn nhận được kết quả ổn định bất kể họ sử dụng giao diện web, CLI hay API.

Vì sao QA lại quan trọng?

Một engine âm vận học có thể chứa hàng trăm quy luật.

Mỗi quy luật lại tác động đến hàng nghìn chữ Hán.

Nếu không có hệ thống kiểm thử, chỉ một thay đổi nhỏ cũng có thể làm giảm chất lượng của toàn bộ engine mà rất khó phát hiện.

Do đó, QA không phải công việc diễn ra sau khi lập trình xong.

Nó là một phần của kiến trúc.

Mỗi khi một quy luật mới được bổ sung, hệ thống kiểm thử cũng được mở rộng tương ứng.

Kiểm thử để phục vụ nghiên cứu

Mục tiêu cuối cùng của Quizzman Fanqie Engine không chỉ là tạo ra một phần mềm hoạt động ổn định.

Điều quan trọng hơn là xây dựng một nền tảng có thể kiểm chứng các giả thuyết âm vận học.

Khi mỗi bước của pipeline đều có bài kiểm thử riêng, các nhà nghiên cứu có thể:

• thay đổi một quy luật;
• chạy lại toàn bộ corpus;
• quan sát ảnh hưởng của thay đổi đó;
• và đánh giá bằng dữ liệu thay vì cảm tính.

Đó cũng là lý do hệ thống QA của Quizzman Fanqie Engine không chỉ phục vụ phát triển phần mềm, mà còn trở thành một công cụ hỗ trợ nghiên cứu ngôn ngữ học lịch sử.

Bài tiếp theo

Sau khi khám phá kiến trúc, thuật toán, benchmark và hệ thống kiểm thử, chúng ta sẽ khép lại series bằng một góc nhìn rộng hơn: tương lai của Quizzman Fanqie Engine. Từ một engine suy diễn âm Hán Việt, nền tảng này có thể mở rộng sang Hán Nhật, Hán Hàn, các phương ngữ tiếng Hán, xử lý văn bản cổ, OCR và các ứng dụng AI trong nghiên cứu lịch sử ngôn ngữ Đông Á.

→ Phần 14 (kết): Tương lai của Quizzman Fanqie Engine: Từ một engine Hán Việt đến nền tảng nghiên cứu ngôn ngữ Đông Á