Làm hỏi đáp trên tài liệu tiếng Việt bằng tìm kiếm tăng cường (RAG) vấp nhiều nhất ở khâu trước mô hình: PDF scan nhận dạng sai dấu, cắt đoạn chặt đôi điều khoản, câu hỏi gõ không dấu hoặc viết tắt, văn bản hết hiệu lực vẫn nằm trong kho, tên đơn vị hành chính cũ và mới lẫn lộn sau đợt sắp xếp năm 2025. Sửa được các khâu này thì một mô hình trung bình cũng trả lời khá; bỏ qua chúng thì mô hình mạnh nhất vẫn trả lời sai một cách tự tin.
Cơ chế chung của RAG, tức là tìm đoạn tài liệu liên quan rồi đưa vào câu lệnh để mô hình trả lời dựa trên đó, đã được giải thích ở các trang phổ thông. Bài này đi theo đường ống của một hệ thống thật trên tài liệu tiếng Việt: chuẩn bị nguồn, cắt đoạn theo cấu trúc văn bản Việt, tìm kiếm, viết câu lệnh sinh câu trả lời, kiểm và tìm chỗ hỏng, cuối cùng là phân quyền và dữ liệu cá nhân.
Vì sao tài liệu tiếng Việt cần thêm công
Kho tài liệu điển hình của một cơ quan hay doanh nghiệp Việt Nam là hỗn hợp: văn bản quy phạm tải từ cổng chính thức, công văn scan có dấu đỏ, quy trình nội bộ soạn bằng trình soạn thảo, bảng biểu trong tệp bảng tính, hướng dẫn chụp màn hình phần mềm. Mỗi loại đặt ra một vấn đề khác khi chuyển thành văn bản sạch để tìm kiếm.
Văn bản hành chính Việt Nam lại có cấu trúc rất chặt và văn phong đặc thù: câu dài, nhiều mệnh đề, viện dẫn chéo kiểu "theo quy định tại khoản 2 Điều này", danh sách điểm a, b, c. Người hỏi thì dùng ngôn ngữ đời thường, gõ trên điện thoại, nhiều khi không dấu. Khoảng cách giữa cách viết của tài liệu và cách hỏi của người dùng lớn hơn so với nhiều thứ tiếng khác.
Cuối cùng là tính thời sự. Văn bản được sửa đổi, thay thế, hết hiệu lực liên tục. Từ ngày 1/7/2025, Việt Nam còn 34 đơn vị hành chính cấp tỉnh và bỏ cấp huyện, kéo theo hàng loạt hướng dẫn, biểu mẫu, thẩm quyền thay đổi. Một kho tài liệu chưa dọn sẽ chứa song song quy trình cũ qua cấp huyện và quy trình mới, và hệ thống không tự biết cái nào đang áp dụng.
Chuẩn bị nguồn: phần việc quyết định
Trước khi nghĩ tới mô hình, hãy dành thời gian cho kho tài liệu. Những việc dưới đây thường chiếm nhiều công nhất nhưng mang lại nhiều cải thiện nhất.
- Ưu tiên bản có chữ thật thay vì bản scan. Văn bản quy phạm thường có bản điện tử trên cổng chính thức; lấy bản đó thay vì nhận dạng lại từ ảnh chụp. Chỉ OCR khi không còn cách nào khác.
- Kiểm chất lượng OCR trên mẫu. Chữ Việt nhận dạng sai dấu như "quyết định" thành "quyêt đinh", số hiệu văn bản sai một ký tự là đủ làm hỏng tìm kiếm. Lấy ngẫu nhiên vài trang mỗi lô, đọc so với bản gốc, ghi tỷ lệ lỗi. Quy trình số hoá chi tiết nằm ở danh mục OCR chữ Việt của trang.
- Chuẩn hoá Unicode về NFC cho toàn bộ văn bản, kể cả văn bản chép từ PDF, vì PDF hay trả về dạng tổ hợp.
- Chuyển bảng biểu thành dạng đọc được. Bảng trong PDF khi trích ra thường thành chuỗi số rời rạc. Chuyển mỗi dòng bảng thành một câu có tên cột, ví dụ "Hồ sơ: đơn đề nghị; Số lượng: 01 bản chính; Nơi nộp: bộ phận một cửa cấp xã".
- Gắn siêu dữ liệu cho từng tài liệu: số hiệu, ngày ban hành, ngày hiệu lực, tình trạng còn hay hết hiệu lực, cơ quan ban hành, phạm vi áp dụng. Không có siêu dữ liệu thì không lọc được văn bản cũ.
- Lập bảng đối chiếu tên đơn vị hành chính cũ và mới cho địa bàn liên quan, dùng để mở rộng câu hỏi và để cảnh báo khi đoạn tìm được nhắc tới cấp huyện.
Một kho năm trăm tài liệu được dọn kỹ thường cho hệ thống tốt hơn một kho năm nghìn tài liệu đổ vào nguyên trạng. Người dùng không phân biệt được lỗi do tìm sai hay do tài liệu sai; họ chỉ thấy hệ thống trả lời sai.
Cắt đoạn theo cấu trúc văn bản Việt
Văn bản quy phạm và văn bản hành chính Việt Nam có thứ bậc rõ: phần, chương, mục, điều, khoản, điểm. Đơn vị cắt hợp lý nhất thường là điều, hoặc khoản nếu điều quá dài. Mỗi đoạn nên mang theo phần đầu gồm tên văn bản, số hiệu, tên chương và tiêu đề điều, để khi đứng một mình nó vẫn đủ nghĩa. Một khoản chỉ ghi "Thời hạn giải quyết là 05 ngày làm việc" mà không kèm tiêu đề điều thì không ai biết đó là thời hạn của thủ tục nào.
Viện dẫn chéo là chỗ khó riêng. Câu "trừ trường hợp quy định tại khoản 3 Điều 12" chỉ có nghĩa khi đọc cùng khoản 3 Điều 12. Có hai cách xử lý thường dùng: khi tìm được một đoạn có viện dẫn, tự động lấy thêm đoạn được viện dẫn đưa vào câu lệnh; hoặc khi cắt đoạn, chèn tóm tắt ngắn của đoạn được viện dẫn ngay sau câu viện dẫn. Cách đầu đơn giản hơn và giữ nguyên văn bản gốc.
Với quy trình nội bộ và tài liệu hướng dẫn, cắt theo tiêu đề mục và giữ các bước đánh số trong cùng một đoạn. Với hỏi đáp thường gặp có sẵn, mỗi cặp hỏi–đáp là một đoạn. Tránh cắt cứng theo số ký tự cố định, vì câu tiếng Việt hành chính dài, cắt cứng rất dễ tách chủ ngữ khỏi vị ngữ hoặc tách điều kiện khỏi kết quả.
Tìm kiếm: làm cho câu hỏi đời thường gặp được văn bản hành chính
Tìm kiếm lai. Kết hợp tìm theo nghĩa với tìm theo từ khoá. Nhánh từ khoá bắt số hiệu văn bản, số điều, tên riêng, mã thủ tục; nhánh nghĩa bắt câu hỏi diễn đạt khác chữ. Với tài liệu hành chính tiếng Việt, bỏ một trong hai nhánh thường làm mất một nhóm câu hỏi đáng kể.
Viết lại câu hỏi trước khi tìm. Dùng mô hình để khôi phục dấu, mở rộng viết tắt, chuyển câu hỏi đời thường sang cách nói hành chính. "lam lai cccd o dau" có thể thành "cấp lại thẻ căn cước ở đâu, cơ quan nào giải quyết". Giữ cả câu gốc và câu viết lại, tìm bằng cả hai.
Lọc theo siêu dữ liệu. Mặc định chỉ tìm trong văn bản còn hiệu lực, đúng phạm vi địa bàn. Cho phép người dùng chủ động hỏi về văn bản cũ khi cần, nhưng câu trả lời phải ghi rõ văn bản đó đã hết hiệu lực.
Xếp hạng lại. Lấy vài chục đoạn từ bước tìm, dùng một mô hình chuyên chấm độ liên quan để sắp lại, chỉ đưa năm đến mười đoạn tốt nhất vào câu lệnh. Bước này giảm đáng kể tình trạng mô hình bị nhiễu bởi đoạn gần chữ mà khác ý.
Giới hạn ngữ cảnh. Đưa quá nhiều đoạn vào câu lệnh không làm câu trả lời tốt hơn; mô hình có xu hướng bỏ sót thông tin nằm giữa ngữ cảnh dài. Với tiếng Việt tốn mảnh, mười đoạn đã có thể chiếm phần lớn cửa sổ của mô hình nhỏ.
Câu lệnh sinh câu trả lời bằng tiếng Việt
Phần sinh câu trả lời cần một câu lệnh hệ thống rõ ràng. Dưới đây là các ý nên có, viết bằng tiếng Việt, để bạn điều chỉnh theo tổ chức của mình. Đây là ví dụ, không phải mẫu bắt buộc.
- Vai và đối tượng: "Bạn là trợ lý tra cứu thủ tục của bộ phận một cửa, trả lời người dân bằng tiếng Việt dễ hiểu, xưng "bộ phận một cửa", gọi người hỏi là "ông/bà" hoặc "anh/chị" theo cách họ tự xưng."
- Phạm vi: "Chỉ trả lời dựa trên các đoạn tài liệu được cung cấp bên dưới. Nếu tài liệu không có thông tin, nói rõ là chưa tìm thấy trong tài liệu và gợi ý liên hệ bộ phận phụ trách."
- Dẫn nguồn: "Sau mỗi ý, ghi tên văn bản và số điều, khoản lấy thông tin. Không ghi số điều nếu đoạn tài liệu không có."
- Văn bản cũ: "Nếu đoạn tài liệu nhắc tới cấp huyện hoặc tên đơn vị hành chính đã thay đổi, nói rõ thông tin có thể đã cũ và cần kiểm lại với cơ quan hiện hành."
- Hình thức: "Trả lời ngắn gọn, liệt kê giấy tờ cần chuẩn bị thành danh sách, không dùng từ ngữ pháp lý khi có cách nói thông thường tương đương."
- Giới hạn: "Không đưa ra ý kiến pháp lý cho trường hợp cụ thể, không suy đoán thời hạn hay lệ phí nếu tài liệu không ghi."
Câu lệnh tốt không thay được tài liệu tốt, nhưng câu lệnh thiếu phần "nói không biết khi không có thông tin" gần như chắc chắn dẫn tới câu trả lời bịa. Đó là hành vi mặc định của mô hình ngôn ngữ khi bị hỏi điều nó không thấy.
Kiểm và tìm chỗ hỏng: tách lỗi tìm với lỗi sinh
Khi hệ thống trả lời sai, câu hỏi đầu tiên là sai ở khâu nào. Chuẩn bị một bộ vài chục đến vài trăm câu hỏi thật kèm đáp án và đoạn nguồn đúng, chạy định kỳ, phân loại từng câu sai theo bảng dưới.
| Loại lỗi | Dấu hiệu | Sửa ở đâu |
|---|---|---|
| Tài liệu không có | Không đoạn nào trong kho chứa câu trả lời | Bổ sung tài liệu, hoặc dạy hệ thống nói không biết |
| Tìm trượt | Kho có đoạn đúng nhưng không lọt vào các đoạn đưa cho mô hình | Cắt đoạn, viết lại câu hỏi, tìm kiếm lai, xếp hạng lại |
| Tìm nhầm văn bản cũ | Đoạn đưa vào thuộc văn bản hết hiệu lực | Siêu dữ liệu hiệu lực và bộ lọc |
| Sinh sai dù đoạn đúng | Đoạn đúng có trong câu lệnh nhưng mô hình hiểu sai, bỏ sót, thêm thắt | Câu lệnh, giảm số đoạn, đổi mô hình |
| Bịa nguồn | Ghi số điều không có trong đoạn được cung cấp | Kiểm tự động số điều trong câu trả lời so với đoạn nguồn |
| Văn phong, xưng hô | Nội dung đúng nhưng giọng cứng, xưng hô sai | Câu lệnh hệ thống, ví dụ mẫu |
Trong thực tế, phần lớn lỗi thường rơi vào hai dòng đầu, tức là khâu tài liệu và khâu tìm. Nhiều nhóm mất thời gian đổi mô hình sinh trong khi vấn đề nằm ở chỗ đoạn đúng chưa bao giờ được đưa tới mô hình.
Phân quyền tài liệu và dữ liệu cá nhân
Hệ thống hỏi đáp nội bộ dễ trở thành đường rò thông tin nếu không phân quyền ở tầng tìm kiếm. Nhân viên phòng kinh doanh hỏi một câu vô tình khớp với đoạn trong bảng lương của phòng nhân sự, và mô hình trả lời luôn. Phân quyền phải áp dụng khi tìm kiếm, tức là chỉ tìm trong những tài liệu người hỏi được phép đọc, chứ không phải nhờ câu lệnh dặn mô hình đừng tiết lộ.
Tài liệu chứa dữ liệu cá nhân như hồ sơ khách hàng, danh sách nhân viên, đơn thư của người dân cần được che hoặc loại khỏi kho chung. Nếu dùng dịch vụ mô hình bên ngoài, mọi đoạn đưa vào câu lệnh đều được gửi ra ngoài; hãy kiểm hợp đồng dịch vụ về việc lưu trữ và sử dụng dữ liệu, đối chiếu với quy định bảo vệ dữ liệu cá nhân hiện hành của Việt Nam. Các vấn đề này được bàn kỹ hơn ở trang AI Bảo Mật.
Cuối cùng, ghi nhật ký câu hỏi và câu trả lời có kiểm soát: đủ để tìm lỗi và cải thiện, nhưng không giữ lâu hơn cần thiết và không mở cho nhiều người xem. Nhật ký câu hỏi của người dân hay khách hàng thường chứa thông tin cá nhân họ tự gõ vào mà không nghĩ tới.
Câu hỏi thường gặp
RAG có làm chatbot hết bịa với tài liệu tiếng Việt không?
Giảm đáng kể nhưng không hết. Mô hình vẫn có thể hiểu sai đoạn tài liệu, gộp hai đoạn thành một ý sai, hoặc thêm chi tiết không có. Yêu cầu dẫn nguồn theo từng ý và kiểm tự động số điều trong câu trả lời giúp phát hiện phần lớn trường hợp.
Có cần mô hình tiếng Việt chuyên biệt để làm RAG không?
Không bắt buộc. Phần sinh câu trả lời cần mô hình viết tiếng Việt tốt và làm theo hướng dẫn chặt; nhiều mô hình đa ngôn ngữ làm được. Phần tìm kiếm thì cần mô hình nhúng xử lý tiếng Việt tốt, đáng đầu tư đo kỹ hơn.
Làm sao xử lý văn bản đã hết hiệu lực trong kho?
Gắn siêu dữ liệu tình trạng hiệu lực cho từng văn bản, mặc định lọc bỏ văn bản hết hiệu lực khi tìm, và yêu cầu mô hình nêu rõ khi buộc phải dùng văn bản cũ. Cập nhật siêu dữ liệu là việc định kỳ, cần người chịu trách nhiệm.
Câu hỏi không dấu có làm RAG kém đi nhiều không?
Thường có, nhất là ở nhánh tìm theo nghĩa. Bước viết lại câu hỏi để khôi phục dấu và mở rộng viết tắt trước khi tìm giúp cải thiện rõ. Nên có một nhóm câu không dấu riêng trong bộ kiểm để theo dõi.
Có nên đưa toàn bộ văn bản dài vào câu lệnh thay vì tìm từng đoạn không?
Với mô hình có cửa sổ ngữ cảnh rất dài, đưa cả văn bản đôi khi được, nhưng tốn chi phí, chậm, và mô hình vẫn có thể bỏ sót chi tiết ở giữa. Với kho nhiều văn bản thì không khả thi. Tìm đúng đoạn vẫn là cách tiết kiệm và kiểm soát được hơn.
Hệ thống hỏi đáp thủ tục có thay được cán bộ một cửa không?
Không. Nó giúp người dân tra nhanh giấy tờ cần chuẩn bị và giúp cán bộ đỡ trả lời câu hỏi lặp lại, nhưng không thay việc thụ lý, thẩm định, xử lý trường hợp đặc biệt. Câu trả lời của hệ thống nên luôn kèm gợi ý liên hệ cơ quan khi cần xác nhận.