Tham gia một nhiệm vụ chia sẻ về xử lý tiếng Việt gồm sáu việc chính: đọc kỹ luật và điều khoản dữ liệu, dựng một hệ thống cơ sở chạy được từ đầu đến cuối thật sớm, chia tập và đánh giá nội bộ đúng cách, cải tiến có ghi chép, nộp kết quả đúng định dạng trong khung giờ, rồi viết báo cáo hệ thống trung thực. Đội thắng thường không phải đội có ý tưởng lạ nhất mà là đội ít mắc lỗi quy trình nhất.
Bài này viết cho sinh viên hoặc kỹ sư lần đầu dự một cuộc thi kiểu VLSP hay các cuộc thi tương tự. Không bàn mô hình nào mạnh nhất, vì câu trả lời đổi theo năm. Phần giá trị nằm ở quy trình: những lỗi khiến đội mất điểm hoặc bị loại thường lặp lại y hệt qua các kỳ, ở mọi ngôn ngữ, và hoàn toàn tránh được nếu biết trước.
Chọn nhiệm vụ hợp với đội trước khi đăng ký
Một kỳ hội thảo có thể mở vài nhiệm vụ cùng lúc, và đăng ký hết cho "đủ trải nghiệm" thường dẫn đến không làm tốt cái nào. Trước khi đăng ký, đội nên tự hỏi ba câu. Thứ nhất, bài toán có gần với thứ đội đã biết hay muốn học không: một đội chưa từng làm âm thanh sẽ mất phần lớn thời gian chỉ để hiểu định dạng tệp ghi âm và cách tính tỷ lệ lỗi từ.
Thứ hai, tài nguyên có đủ không. Nhiệm vụ tiếng nói, nhiệm vụ đòi mô hình lớn thường cần máy có card đồ hoạ tốt và nhiều dung lượng lưu trữ; nhiệm vụ phân loại văn bản ngắn thì một máy phổ thông cũng xoay xở được. Thứ ba, thời gian thật sự có là bao nhiêu giờ mỗi tuần, tính cả mùa thi cử ở trường hay hạn chót ở công ty. Một ước lượng thẳng thắn ngay từ đầu giúp đội chọn đúng một nhiệm vụ và đi đến cuối, thay vì bỏ dở giữa chừng.
Tuần đầu: đọc luật như đọc hợp đồng
Phần lớn tranh cãi sau cuộc thi bắt nguồn từ chỗ đội không đọc kỹ luật. Trước khi viết dòng mã nào, cả đội nên ngồi đọc chung và ghi ra câu trả lời cho các câu hỏi sau.
- Đầu vào và đầu ra chính xác là gì, định dạng tệp nộp ra sao, mã hoá ký tự nào. Tiếng Việt đặc biệt nhạy với chuẩn Unicode: nộp chữ tổ hợp khi đáp án dùng chữ dựng sẵn có thể làm hệ chấm coi là sai hết.
- Thước đo chính là gì, có mã chấm điểm công khai không. Nếu có, chạy thử mã chấm trên tập phát triển ngay trong ngày đầu để chắc mình hiểu cách tính.
- Được dùng dữ liệu ngoài không, được dùng mô hình tiền huấn luyện nào, có giới hạn kích thước mô hình hay tài nguyên tính toán không.
- Điều khoản dữ liệu: được lưu ở đâu, được chia cho ai, có phải xoá sau cuộc thi không, có được dùng cho mục đích khác không.
- Lịch: ngày phát tập kiểm tra, khung giờ nộp, số lần nộp tối đa, hạn nộp báo cáo. Ghi vào lịch chung của đội kèm múi giờ.
- Chỗ nào mơ hồ thì hỏi ban tổ chức qua kênh chính thức và lưu câu trả lời. Các đội khác thường cũng có cùng thắc mắc.
Một mẹo nhỏ: viết lại luật thành một trang tóm tắt bằng lời của đội, rồi nhờ một thành viên chưa đọc luật kiểm xem bản tóm tắt có khớp không. Hiểu lầm lộ ra rất nhanh khi một người phải giải thích cho người khác.
Dựng hệ thống cơ sở chạy trọn vòng thật sớm
Sai lầm phổ biến nhất của đội mới là dành ba tuần đầu nghiên cứu mô hình phức tạp, đến tuần cuối mới viết phần đọc dữ liệu và xuất kết quả, rồi phát hiện định dạng sai. Cách làm ngược lại an toàn hơn nhiều: trong vài ngày đầu, dựng một hệ thống đơn giản nhất có thể, đọc dữ liệu, dự đoán, xuất tệp đúng định dạng, chạy mã chấm ra một con số. Hệ thống đó có thể rất dở, như luôn dự đoán nhãn phổ biến nhất, hay tinh chỉnh một mô hình nhỏ có sẵn với tham số mặc định.
Giá trị của hệ thống cơ sở không nằm ở điểm số mà ở chỗ nó chứng minh đường ống thông suốt. Từ đó, mọi cải tiến chỉ là thay một khối trong đường ống và đo lại. Hệ thống cơ sở cũng là mốc để biết mỗi thay đổi giúp được bao nhiêu; không có mốc, đội rất dễ tự lừa mình rằng một ý tưởng hiệu quả trong khi thật ra nó chỉ ngang ngửa cách đơn giản nhất.
Với tiếng Việt, đường ống nên có sẵn một bước chuẩn hoá thống nhất: đưa văn bản về một chuẩn Unicode, thống nhất kiểu đặt dấu, xử lý ký tự lạ. Bước này chạy giống hệt nhau cho tập huấn luyện, tập phát triển và tập kiểm tra. Rất nhiều đội mất điểm vì chuẩn hoá khi huấn luyện nhưng quên chuẩn hoá khi dự đoán, hoặc chuẩn hoá cả đầu ra làm lệch so với đáp án.
Chia tập và đánh giá nội bộ: nơi hay hỏng nhất
Đừng nhìn vào tập phát triển quá nhiều lần. Mỗi lần chọn cấu hình theo điểm trên tập phát triển là một lần "học" tập đó. Sau vài chục lần, điểm trên tập phát triển cao hơn khả năng thật. Nếu dữ liệu đủ, tách thêm một phần nhỏ từ tập huấn luyện làm tập kiểm tra nội bộ và chỉ nhìn nó vài lần.
Coi chừng rò rỉ do trùng lặp. Văn bản tiếng Việt cào từ mạng hay bị lặp: cùng một bình luận đăng ở nhiều nơi, cùng một bản tin được chép lại. Nếu bản sao rơi vào cả tập huấn luyện nội bộ lẫn tập kiểm tra nội bộ, điểm sẽ cao giả. Lọc trùng gần đúng trước khi chia.
Chia theo nhóm, không chia theo câu. Với giọng nói, chia theo người nói: cùng một người không nên có mặt ở cả hai tập. Với văn bản, chia theo tài liệu hay theo nguồn. Chia ngẫu nhiên từng câu khiến mô hình học thuộc giọng, văn phong của người cụ thể.
Dữ liệu ngoài phải kiểm chồng lấn. Khi nhiệm vụ cho dùng dữ liệu ngoài, kiểm xem nguồn ngoài có chứa chính câu trong tập kiểm tra không, nhất là khi tập kiểm tra lấy từ báo chí hay trang công khai. Vô tình đưa đáp án vào huấn luyện là lỗi có thể khiến đội bị loại.
Mô hình lớn đã từng thấy dữ liệu chưa. Nếu dùng mô hình ngôn ngữ lớn, nên nhớ nó có thể đã gặp văn bản công khai giống tập kiểm tra trong quá trình tiền huấn luyện. Điều này khó kiểm hoàn toàn, nhưng nên ghi nhận như một hạn chế trong báo cáo.
Cải tiến có ghi chép, không cải tiến theo cảm hứng
Trong vài tuần thi, một đội ba người dễ chạy cả trăm thí nghiệm. Nếu không ghi lại, đến lúc viết báo cáo không ai nhớ cấu hình nào cho kết quả nào, và đôi khi không tái tạo nổi chính bản đã nộp. Cách tối thiểu là một bảng chung: mỗi dòng một thí nghiệm, ghi ngày, người chạy, phiên bản mã, phiên bản dữ liệu, tham số chính, điểm trên tập nội bộ, nhận xét một câu. Giữ hạt giống ngẫu nhiên cố định và lưu lại mô hình của những lần chạy tốt.
Thay đổi một thứ mỗi lần. Đổi cùng lúc mô hình, cách chuẩn hoá và tham số học thì khi điểm tăng, không ai biết nhờ cái gì. Khi điểm thay đổi rất ít, chạy lại vài lần với hạt giống khác để biết đó là tiến bộ thật hay dao động ngẫu nhiên.
Dành thời gian cho phân tích lỗi thay vì chỉ nhìn tổng điểm. Lấy ngẫu nhiên khoảng một trăm mẫu hệ thống làm sai, đọc từng cái và xếp nhóm: sai vì từ viết tắt, vì không dấu, vì tên riêng lạ, vì nhãn gốc có vấn đề. Phân tích kiểu này thường chỉ ra cải tiến rẻ hơn nhiều so với đổi sang mô hình to hơn, và nó cũng là phần có giá trị nhất của báo cáo hệ thống.
Ngày nộp bài: danh sách kiểm tra
Ngày phát tập kiểm tra là ngày dễ hỏng nhất vì áp lực thời gian. Chuẩn bị trước các bước sau và chạy thử với tập phát triển vài ngày trước đó.
- Có một lệnh duy nhất chạy từ tệp dữ liệu thô đến tệp nộp, không thao tác tay ở giữa. Mọi bước thủ công là một cơ hội làm sai.
- Kiểm định dạng tệp nộp bằng một đoạn mã riêng: đủ số dòng, đúng thứ tự, đúng mã hoá, không dòng trống thừa, đúng chuẩn Unicode mà ban tổ chức yêu cầu.
- Chạy thử toàn bộ quy trình trên tập phát triển, giả làm tập kiểm tra, và chấm bằng mã chấm chính thức.
- Phân công một người chạy, một người kiểm độc lập trước khi bấm nộp.
- Nộp bản an toàn sớm (hệ thống tốt nhất đã kiểm kỹ), sau đó mới dùng các lượt nộp còn lại cho thử nghiệm, nếu luật cho nhiều lượt.
- Lưu lại chính xác mã, mô hình, dữ liệu đã dùng cho từng lượt nộp, phục vụ báo cáo và kiểm tra sau này.
Đừng thử ý tưởng mới trong ngày nộp. Cải tiến nghĩ ra lúc nửa đêm hiếm khi đáng đánh đổi rủi ro làm hỏng bản đã chạy tốt.
Viết báo cáo hệ thống người khác dùng được
Báo cáo hệ thống (system description paper) là phần ở lại lâu nhất sau cuộc thi. Một báo cáo tốt cho người đọc biết đủ để làm lại: dữ liệu nào được dùng (kể cả dữ liệu ngoài), tiền xử lý gì, mô hình nào và từ đâu, tham số chính, tài nguyên tính toán, thời gian huấn luyện. Nếu luật cho phép, công bố mã kèm theo.
Trung thực về những gì không hiệu quả cũng quan trọng như phần hiệu quả. Một bảng "các hướng đã thử nhưng không giúp" tiết kiệm cho đội sau hàng tuần. Phần phân tích lỗi nên có ví dụ cụ thể (đã che thông tin cá nhân nếu dữ liệu có), xếp nhóm lỗi và ước lượng tỷ lệ từng nhóm trên mẫu đã đọc.
Tránh viết quá lời về thứ hạng. Thay vì "hệ thống của chúng em bỏ xa các đội khác", hãy mô tả khoảng cách điểm, điều kiện tài nguyên, và các yếu tố có thể giải thích khác biệt. Bình duyệt viên và người đọc trong nghề đánh giá cao sự chừng mực, và nó giúp báo cáo không lỗi thời nhanh khi các kỳ sau có kết quả khác. Cuối cùng, làm đúng điều khoản dữ liệu sau cuộc thi: xoá hay giữ dữ liệu theo cam kết, không đăng lại dữ liệu lên kho công khai kèm mã.
Câu hỏi thường gặp
Đội nên có mấy người và chia việc thế nào?
Ba đến bốn người là cỡ dễ phối hợp. Cách chia hay dùng: một người lo dữ liệu và chuẩn hoá, một người lo mô hình, một người lo đánh giá, phân tích lỗi và viết báo cáo. Nên có một người chịu trách nhiệm chung về lịch và luật để tránh tình trạng ai cũng tưởng người khác đã đọc.
Không có máy tính mạnh thì có nên tham gia?
Vẫn nên. Nhiều nhiệm vụ giải được khá tốt bằng mô hình nhỏ tinh chỉnh trên một card đồ hoạ phổ thông hoặc dịch vụ tính toán miễn phí có giới hạn. Phân tích lỗi kỹ và chuẩn hoá dữ liệu tốt thường bù được một phần chênh lệch tài nguyên, và báo cáo về hệ thống nhẹ cũng có giá trị riêng.
Dùng chatbot lớn để gán nhãn thêm dữ liệu có được không?
Phụ thuộc luật từng nhiệm vụ. Nếu luật cấm dữ liệu ngoài hay cấm dùng mô hình ngoài danh sách, thì không. Nếu được phép, phải khai báo rõ trong báo cáo, kiểm mẫu nhãn do máy sinh và đọc điều khoản sử dụng của dịch vụ đó về việc dùng đầu ra để huấn luyện mô hình khác.
Xếp hạng thấp thì có nên nộp báo cáo không?
Nên, nếu nhiệm vụ nhận báo cáo của mọi đội. Một báo cáo trung thực về hướng đi không hiệu quả, có phân tích lỗi tốt, vẫn hữu ích cho cộng đồng và là kinh nghiệm viết khoa học quý cho người mới. Nhiều bình duyệt viên đánh giá báo cáo theo chất lượng phân tích chứ không theo thứ hạng.
Có được chia sẻ mã nguồn trong lúc cuộc thi đang diễn ra không?
Tuỳ luật, nhưng thông lệ là không chia sẻ giữa các đội trong lúc thi để giữ công bằng, trừ khi ban tổ chức khuyến khích hợp tác. Sau cuộc thi, công bố mã là việc tốt, miễn là không kèm dữ liệu bị giới hạn chia sẻ và không lộ thông tin cá nhân có trong dữ liệu.
Khi thấy nhãn trong dữ liệu ban tổ chức có lỗi thì làm gì?
Ghi lại các trường hợp cụ thể và báo cho ban tổ chức qua kênh chính thức. Không tự sửa nhãn tập kiểm tra vì bạn không có đáp án. Với tập huấn luyện, nếu tự lọc hoặc sửa nhãn thì ghi rõ cách làm trong báo cáo, vì đó cũng là một quyết định ảnh hưởng tới kết quả.