Từ Khang Hy Tự Điển đến thuật toán: Hành trình xây dựng Parser của Quizzman Fanqie Engine

Series 2 · Nền tảng học thuật — Bài 4

• ← Bài 1: Quảng Vận → Nguyễn Tài Cẩn
• ← Bài 2: Phục dựng MC không phải đoán
• ← Bài 3: Vương Lực · Âm hệ không lấy tục đọc
• Chuyên mục: Phiên thiết

Trước khi Quizzman Fanqie Engine có thể suy diễn Hán Việt từ phản thiết, một bài toán khó hơn nhiều đã phải được giải quyết: làm thế nào để máy tính hiểu được cách các học giả thời Thanh ghi chú ngữ âm trong Khang Hy Tự Điển? Khác với dữ liệu hiện đại có cấu trúc rõ ràng, các mục từ trong Khang Hy là sự pha trộn của phản thiết, chú âm, nhiều nguồn vận thư, các ký hiệu âm vận và vô số ngoại lệ được ghi bằng văn ngôn. Quá trình xây dựng parser vì vậy không đơn thuần là viết mã nguồn, mà bắt đầu từ việc khảo sát hàng chục nghìn mục từ để tìm ra những quy luật biên tập mà người xưa sử dụng.

Bài toán đầu tiên: Khang Hy không phải cơ sở dữ liệu

Nhiều người nghĩ rằng Khang Hy Tự Điển chỉ là một "database" khổng lồ.

Thực tế hoàn toàn ngược lại.

Khang Hy là một tác phẩm biên soạn theo văn phong học thuật của thế kỷ XVIII.

Một mục từ có thể đồng thời chứa:

• giải thích nghĩa;
• dị thể;
• chú giải;
• nhiều nguồn vận thư;
• nhiều phản thiết;
• nhiều cách đọc;
• ghi chú của người biên soạn.

Không có một định dạng cố định như XML hay JSON.

Máy tính không thể đọc trực tiếp.

Muốn xây dựng một engine âm vận học, trước hết phải biến những ghi chép này thành dữ liệu có cấu trúc.

Bước đầu tiên: Khảo sát pattern của toàn bộ Khang Hy

Thay vì viết parser ngay, Quizzman dành nhiều thời gian để khảo sát cách Khang Hy trình bày thông tin.

Mục tiêu không phải đọc từng chữ.

Mục tiêu là trả lời:

Người biên soạn Khang Hy thường ghi thông tin ngữ âm theo những mẫu nào?

Sau quá trình khảo sát, có thể nhận thấy phần lớn dữ liệu âm đọc đều xoay quanh một số nguồn quen thuộc:

• 《廣韻》
• 《集韻》
• 《唐韻》
• 《韻會》
• 《正韻》

Trong đó, Quảng Vận và Tập Vận xuất hiện với tần suất đặc biệt cao và trở thành nguồn dữ liệu quan trọng nhất đối với Fanqie Engine.

Điều này giúp parser biết được đâu là phần cần ưu tiên phân tích, đâu chỉ là chú giải bổ sung.

Không phải mọi phản thiết đều giống nhau

Sau khi xác định được vị trí của các mục Quảng Vận và Tập Vận, vấn đề khó hơn mới xuất hiện.

Phản thiết trong Khang Hy không chỉ có một dạng.

Ví dụ đơn giản nhất là:

AB切

Đây là dạng quen thuộc nhất.

Parser chỉ cần tách:

• thượng tự;
• hạ tự.

Tuy nhiên trên thực tế còn rất nhiều biến thể khác.

Ví dụ:

AB切某聲

AB切又音

AB切音某

AB切讀若……

AB切叶某韻

又作……

又與某同

俗作……

Mỗi mẫu mang ý nghĩa học thuật khác nhau.

Nếu parser coi tất cả đều là phản thiết chuẩn, kết quả suy diễn sẽ sai ngay từ đầu.

Khó nhất là nhận diện "override"

Trong số các mẫu xuất hiện trong Khang Hy, nhóm khó xử lý nhất là:

AB切C聲

Thoạt nhìn, nhiều người sẽ nghĩ đây chỉ là:

AB切

kèm một lời chú thích.

Thực tế không phải vậy.

Trong rất nhiều trường hợp, phần:

C聲

không phải lời giải thích.

Nó ghi đè (override) thanh điệu của phản thiết.

Điều này cực kỳ quan trọng.

Nếu parser chỉ lấy:

AB切

engine sẽ suy luận theo thanh điệu của hạ tự.

Trong khi người biên soạn Khang Hy lại muốn nói:

Vần và thanh mẫu lấy theo phản thiết, nhưng thanh điệu phải đổi sang C聲.

Đây là một trong những quy tắc khó phát hiện nhất khi xây dựng parser.

Chữ 好 là một ví dụ điển hình

Một trong những trường hợp khiến parser phải được thiết kế lại nhiều lần là chữ:

好

Nếu chỉ nhìn phản thiết, engine sẽ thu được một hồ sơ Middle Chinese.

Nhưng trong Khang Hy, mục từ còn kèm theo ghi chú về thanh điệu.

Điều này khiến parser phải hiểu rằng:

• phản thiết vẫn hợp lệ;
• nhưng thanh điệu không còn hoàn toàn do phản thiết quyết định;
• phần "某聲" đóng vai trò ghi đè thuộc tính thanh.

Nếu không xử lý đúng mẫu này, toàn bộ pipeline phía sau sẽ phục dựng sai Middle Chinese.

Đây cũng là lý do Quizzman không xem parser là một bộ tách chuỗi ký tự, mà là một bộ phân tích ngữ pháp (grammar parser) dành riêng cho văn bản âm vận học.

"讀若" không phải phản thiết

Một nhóm pattern khác cũng cần được xử lý riêng là:

讀若……

Đây không phải phản thiết.

Người biên soạn chỉ muốn nói:

Đọc gần giống chữ...

Điều đó có nghĩa:

• đây là dữ liệu tham khảo;
• không đủ để xây dựng hồ sơ Middle Chinese chuẩn;
• không nên được đưa vào pipeline phản thiết như Quảng Vận.

Parser vì vậy phải nhận diện chính xác đây là phonetic hint chứ không phải fanqie record.

"叶韻" không mô tả phát âm chuẩn

Một trường hợp khác rất dễ gây nhầm lẫn là:

叶某韻

hay:

協韻

Đây là những ghi chú dùng trong thơ ca.

Mục đích của chúng là:

Điều chỉnh cách đọc để hiệp vần.

Điều đó không đồng nghĩa với phát âm chuẩn trong hệ thống âm vị.

Nếu parser coi đây là cách đọc chính thức, engine sẽ đưa rất nhiều ngoại lệ không đúng vào dữ liệu.

Do đó Quizzman tách riêng nhóm rhyme note khỏi nhóm phonological evidence.

Parser không chỉ đọc, mà còn phân loại

Sau quá trình khảo sát, parser của Quizzman không còn đơn giản là:

Regex

↓

Fanqie

Thay vào đó, mỗi đoạn chú giải đều được phân loại trước.

Ví dụ:

Chỉ sau khi biết một đoạn thuộc loại nào, engine mới quyết định cách xử lý.

Parser quyết định chất lượng của toàn bộ engine

Rất nhiều người nghĩ rằng phần khó nhất của Fanqie Engine là thuật toán suy diễn Hán Việt.

Thực tế, điều đó chỉ đúng một nửa.

Nếu parser phân loại sai ngay từ đầu, thì:

• Middle Chinese sẽ sai;
• Projection sẽ sai;
• Tone Resolver sẽ sai;
• Candidate Ranking cũng sẽ sai.

Nói cách khác, mọi thuật toán phía sau đều phụ thuộc vào chất lượng của parser.

Đó là lý do Quizzman dành rất nhiều thời gian nghiên cứu cấu trúc học thuật của Khang Hy Tự Điển trước khi viết bất kỳ dòng mã nào. Thay vì xem Khang Hy là một văn bản cần "đọc", Quizzman xem đây là một hệ thống quy ước cần được mô hình hóa. Chính quá trình khảo sát pattern, phân loại các dạng phản thiết và nhận diện những trường hợp đặc biệt như AB切某聲, 讀若 hay 叶韻 đã đặt nền móng cho toàn bộ Quizzman Fanqie Engine sau này.

→ Series 2 · Bài 5: Vì sao Quizzman Fanqie Engine không hardcode hơn 50.000 chữ Hán?