Chọn mô hình nhúng cho tiếng Việt nên dựa vào kết quả tìm trên chính tài liệu và câu hỏi của bạn, đo bằng một bộ vài chục đến một trăm cặp câu hỏi–đoạn đúng, chứ không dựa vào bảng xếp hạng chung. Các mô hình nhúng đa ngôn ngữ mở hiện nay xử lý tiếng Việt có dấu khá tốt, nhưng dễ vấp ở chữ không dấu, Unicode lẫn hai dạng, viết tắt hành chính, từ Hán Việt đồng nghĩa với từ thuần Việt; thường cần thêm tìm kiếm theo từ khoá để bù.
Khái niệm nhúng và tìm theo nghĩa nói chung đã có ở các trang phổ thông như AI Hiểu. Bài này đi vào phần riêng của tiếng Việt: những thứ làm vectơ lệch, các loại mô hình nhúng và tiêu chí chọn, cắt đoạn văn bản tiếng Việt trước khi nhúng, cách tự đo với chỉ số dễ hiểu, và vì sao tìm kiếm lai giữa từ khoá và nghĩa gần như luôn đáng làm với tiếng Việt.
Nhúng tiếng Việt khác gì nhúng tiếng Anh
Mô hình nhúng biến một câu hay một đoạn thành một dãy số, sao cho hai đoạn cùng ý có dãy số gần nhau. Về nguyên lý không có gì riêng cho tiếng Việt. Khác biệt nằm ở chỗ mô hình đã học được bao nhiêu cặp câu tiếng Việt cùng nghĩa, và văn bản tiếng Việt thực tế có bao nhiêu biến thể bề mặt cho cùng một nội dung.
Tiếng Việt có nhiều biến thể bề mặt hơn người ta tưởng. Cùng một ý có thể viết có dấu hoặc không dấu, bằng mã Unicode dựng sẵn hoặc tổ hợp, theo quy ước "hoà" hoặc "hòa", bằng từ Hán Việt hoặc thuần Việt như "phụ nữ" và "đàn bà", "hôn nhân" và "cưới xin", bằng chữ viết tắt như "CCCD" thay cho "căn cước công dân", "BHXH" thay cho "bảo hiểm xã hội". Người đọc thấy ngay là một, mô hình nhúng thì tuỳ mức độ được huấn luyện.
Ngoài ra, mô hình nhúng đa ngôn ngữ thường được huấn luyện để câu tiếng Việt và câu tiếng Anh cùng nghĩa nằm gần nhau. Đây là lợi thế khi tài liệu trộn hai thứ tiếng, nhưng cũng có nghĩa một phần dung lượng dành cho việc căn chỉnh xuyên ngôn ngữ thay vì phân biệt tinh các sắc thái trong tiếng Việt.
Những thứ làm hỏng kết quả tìm kiếm tiếng Việt
Bảng dưới liệt kê các nguồn lỗi hay gặp nhất khi làm tìm kiếm theo nghĩa trên tài liệu tiếng Việt, cùng cách xử lý thường dùng.
| Nguồn lỗi | Ví dụ | Cách xử lý |
|---|---|---|
| Unicode hai dạng | Tài liệu chép từ PDF dùng dạng tổ hợp, câu hỏi gõ từ điện thoại dùng dạng dựng sẵn | Chuẩn hoá NFC cho cả tài liệu lẫn câu hỏi trước khi nhúng |
| Câu hỏi không dấu | Người dùng gõ "thu tuc cap lai the bao hiem" | Khôi phục dấu trước, hoặc nhúng thêm bản không dấu của tài liệu, hoặc dựa vào phần từ khoá |
| Viết tắt | "GPLX", "CCCD", "HĐLĐ", "UBND" | Lập bảng mở rộng viết tắt, thêm dạng đầy đủ vào câu hỏi hoặc vào đoạn |
| Từ đồng nghĩa khác gốc | "thôi việc" và "nghỉ việc", "phụ cấp" và "trợ cấp" (không hoàn toàn cùng nghĩa) | Đo xem mô hình có kéo gần không; bổ sung từ đồng nghĩa nếu cần |
| Tên đơn vị hành chính cũ và mới | Tài liệu năm 2023 nhắc huyện đã bỏ, câu hỏi dùng tên xã mới sau 2025 | Thêm siêu dữ liệu ngày ban hành, bảng đối chiếu tên cũ–mới |
| Đoạn quá dài hoặc quá ngắn | Cả một chương luật thành một vectơ, hoặc từng câu rời | Cắt theo cấu trúc văn bản, giữ tiêu đề mục gắn vào đoạn |
Ba dòng đầu xử lý được hoàn toàn bằng tiền xử lý đơn giản, không cần đổi mô hình. Nhiều hệ thống kém chỉ vì bỏ qua bước chuẩn hoá Unicode, lỗi rất khó thấy vì trên màn hình hai dạng chữ trông y hệt nhau.
Các loại mô hình nhúng và tiêu chí chọn
Mô hình nhúng đa ngôn ngữ mã nguồn mở. Các dòng như multilingual E5 hay BGE-M3 hỗ trợ hơn một trăm thứ tiếng trong đó có tiếng Việt, tự chạy được trên máy chủ riêng, dữ liệu không rời tổ chức. Phù hợp khi tài liệu nhạy cảm hoặc khối lượng lớn. Kiểm tra giới hạn độ dài đầu vào và yêu cầu tiền tố câu hỏi, vì một số mô hình cần thêm chữ đánh dấu "query" hay "passage" mới cho kết quả đúng.
Mô hình nhúng qua dịch vụ của nhà cung cấp lớn. Gọi qua giao diện lập trình, không cần hạ tầng, chất lượng tiếng Việt thường khá. Đổi lại, nội dung tài liệu phải gửi ra ngoài để nhúng, chi phí tính theo lượng mảnh, và nếu nhà cung cấp ngừng hay đổi mô hình thì phải nhúng lại toàn bộ kho.
Mô hình nhúng tinh chỉnh riêng cho tiếng Việt. Một số nhóm trong nước công bố mô hình nhúng tiếng Việt, có cái xây từ PhoBERT nên yêu cầu tách từ đầu vào. Có thể tốt hơn ở văn bản thuần Việt, nhưng cần đọc kỹ dữ liệu huấn luyện, giấy phép và cách tiền xử lý.
Kích thước vectơ và tốc độ. Vectơ càng dài càng tốn chỗ lưu và tốn thời gian so sánh. Với kho vài trăm nghìn đoạn, chênh lệch này đáng kể về chi phí lưu trữ. Một số mô hình cho phép cắt ngắn vectơ mà mất ít chất lượng.
Độ dài đầu vào tối đa. Đoạn dài hơn giới hạn bị cắt bỏ phần đuôi mà không báo, nên thông tin ở cuối đoạn không bao giờ tìm thấy. Với tiếng Việt tốn mảnh hơn, giới hạn này đến sớm hơn bạn nghĩ.
Tự đo trong một buổi chiều
Không cần bộ điểm chuẩn phức tạp. Một bộ đo nhỏ, làm từ dữ liệu thật, cho bạn câu trả lời đáng tin hơn mọi bảng xếp hạng. Các bước dưới đây áp dụng cho bất kỳ mô hình nào.
- Chọn 50 đến 100 câu hỏi người dùng thật hay hỏi, đã che thông tin cá nhân. Gồm cả câu có dấu, không dấu, có viết tắt, có lỗi chính tả, đúng như người dùng gõ.
- Với mỗi câu, đánh dấu một hoặc vài đoạn tài liệu chứa câu trả lời đúng. Việc này cần người hiểu tài liệu và là phần tốn công nhất.
- Nhúng toàn bộ kho tài liệu bằng từng mô hình ứng viên, với cùng cách cắt đoạn và cùng tiền xử lý.
- Với mỗi câu hỏi, lấy ra năm đoạn gần nhất. Đếm tỷ lệ câu hỏi có đoạn đúng nằm trong năm đoạn đó, gọi là tỷ lệ trúng trong top 5. Đếm thêm tỷ lệ đoạn đúng đứng đầu.
- Tách kết quả theo nhóm câu: có dấu, không dấu, có viết tắt. Một mô hình có thể tốt ở nhóm đầu và rất kém ở nhóm hai.
- Đọc tay những câu trượt ở mọi mô hình. Thường lỗi nằm ở cách cắt đoạn hay tài liệu thiếu, không phải ở mô hình.
Ví dụ giả định: mô hình A trúng top 5 ở 86 trên 100 câu có dấu nhưng chỉ 52 trên 100 câu không dấu; mô hình B lần lượt là 82 và 71. Nếu người dùng của bạn hay gõ không dấu, B có thể là lựa chọn tốt hơn dù tổng điểm trên câu chuẩn thấp hơn.
Cắt đoạn và tìm kiếm lai cho tiếng Việt
Cách cắt đoạn ảnh hưởng tới kết quả không kém việc chọn mô hình. Với văn bản hành chính, pháp quy, quy trình nội bộ của Việt Nam, cấu trúc thường rất rõ: chương, mục, điều, khoản, điểm. Cắt theo đơn vị điều hoặc khoản, và gắn tiêu đề điều cùng tên văn bản vào đầu mỗi đoạn, giúp vectơ mang đủ ngữ cảnh. Với bài báo, cắt theo đoạn văn và gắn tiêu đề bài. Tránh cắt cứng theo số ký tự vì dễ chặt đôi một câu, nhất là câu tiếng Việt dài nhiều mệnh đề.
Tìm theo nghĩa giỏi việc khớp ý khác chữ nhưng yếu việc khớp chính xác: số hiệu văn bản như "Nghị định 13/2023", mã sản phẩm, tên riêng hiếm. Tìm theo từ khoá kiểu BM25 làm tốt đúng những việc đó. Với tiếng Việt, tìm theo từ khoá cần chú ý cách tách: tách theo âm tiết thì "sinh viên" khớp với cả "phát sinh" và "nhân viên", tách theo từ thì chính xác hơn nhưng phụ thuộc công cụ tách từ. Nhiều hệ thống dùng chỉ mục âm tiết kèm cụm hai âm tiết liền nhau để cân bằng.
Tìm kiếm lai chạy cả hai cách rồi trộn kết quả, ví dụ bằng cách cộng thứ hạng. Trên tài liệu tiếng Việt có nhiều số hiệu, viết tắt, tên riêng, cách này thường cải thiện rõ so với chỉ dùng nghĩa. Có thể thêm một bước xếp hạng lại bằng mô hình chuyên chấm độ liên quan giữa câu hỏi và đoạn, chạy trên vài chục đoạn đứng đầu; bước này tốn thêm thời gian nhưng thường đáng với câu hỏi khó.
Một ví dụ giả định cho thấy giá trị của tìm kiếm lai: người dùng hỏi "mức hưởng theo Điều 45 là bao nhiêu". Nhánh nghĩa trả về các đoạn nói chung về mức hưởng trợ cấp, có khi của điều khác; nhánh từ khoá bắt đúng đoạn có cụm "Điều 45". Ngược lại, câu hỏi "bị đuổi việc có được đền bù không" không chứa chữ nào trùng với "đơn phương chấm dứt hợp đồng lao động" và "trợ cấp thôi việc", chỉ nhánh nghĩa mới tìm ra. Hai nhánh bù đúng chỗ yếu của nhau.
Chi phí, cập nhật và dữ liệu cá nhân
Nhúng một kho lớn là chi phí một lần, nhưng không phải chỉ một lần. Mỗi khi đổi mô hình nhúng, kể cả lên phiên bản mới của cùng nhà cung cấp, toàn bộ kho phải nhúng lại vì vectơ của hai mô hình không so được với nhau. Hãy lưu văn bản gốc đã cắt đoạn cùng vectơ, ghi tên và phiên bản mô hình, để việc nhúng lại chỉ là chạy lại một tác vụ.
Tài liệu thay đổi thì vectơ phải cập nhật theo. Văn bản hết hiệu lực nên được đánh dấu hoặc loại khỏi kết quả, nếu không hệ thống sẽ trả về quy định cũ rất tự tin. Với kho văn bản hành chính Việt Nam, đợt sắp xếp đơn vị hành chính năm 2025 là ví dụ điển hình: nhiều tài liệu hướng dẫn cấp huyện vẫn nằm trong kho nhưng không còn áp dụng.
Nếu dùng dịch vụ nhúng bên ngoài, nội dung tài liệu được gửi đi. Tài liệu chứa dữ liệu cá nhân của khách hàng, nhân viên cần được che trước khi nhúng, hoặc dùng mô hình chạy nội bộ. Vectơ nhúng cũng không phải dạng ẩn danh tuyệt đối: đã có nghiên cứu cho thấy có thể khôi phục một phần văn bản từ vectơ, nên kho vectơ cần được bảo vệ như chính tài liệu gốc.
Câu hỏi thường gặp
Có mô hình nhúng nào tốt nhất cho tiếng Việt không?
Không có câu trả lời chung. Mô hình tốt nhất là mô hình cho kết quả tìm tốt nhất trên tài liệu và câu hỏi của bạn, với chi phí và ràng buộc dữ liệu bạn chấp nhận được. Bảng xếp hạng chung chỉ nên dùng để chọn hai ba ứng viên đem đi thử.
Có nên bỏ dấu toàn bộ tài liệu cho dễ khớp với câu hỏi không dấu không?
Không nên bỏ hẳn, vì mất dấu làm mất nghĩa và giảm chất lượng tìm cho câu hỏi có dấu. Cách tốt hơn là khôi phục dấu cho câu hỏi, hoặc giữ cả bản có dấu và bản không dấu trong chỉ mục từ khoá để hai nhánh bù cho nhau.
Mô hình nhúng cần tách từ tiếng Việt không?
Phần lớn mô hình nhúng đa ngôn ngữ nhận văn bản thô, không cần tách từ. Một số mô hình xây từ PhoBERT thì cần tách từ đúng kiểu đã huấn luyện. Đọc thẻ mô hình để biết; đưa sai dạng đầu vào sẽ làm kết quả kém mà không báo lỗi.
Đoạn văn nên dài bao nhiêu khi nhúng tài liệu tiếng Việt?
Thường từ vài câu đến khoảng một hai trăm chữ, nhưng nên theo cấu trúc tự nhiên của tài liệu như một điều luật hay một đoạn văn trọn ý. Thử hai ba cách cắt trên bộ đo của mình rồi chọn cách cho tỷ lệ trúng cao nhất.
Tìm kiếm lai có làm hệ thống chậm đi nhiều không?
Tìm theo từ khoá rất nhanh nên thêm nhánh này thường chỉ tăng độ trễ chút ít. Bước xếp hạng lại bằng mô hình chấm mới là phần tốn thời gian; có thể chỉ bật nó cho câu hỏi khó hoặc giới hạn số đoạn đưa vào xếp hạng.
Vectơ nhúng có phải là dữ liệu cá nhân không?
Nếu được tạo từ văn bản chứa dữ liệu cá nhân thì nên đối xử như dữ liệu cá nhân, vì về nguyên tắc có thể suy ngược một phần nội dung. Bảo vệ kho vectơ bằng phân quyền và mã hoá như kho tài liệu gốc, và xoá vectơ khi xoá tài liệu tương ứng.