DÀN Ý BÁO CÁO NGHIÊN CỨU KHOA HỌC
Thiết kế và phát triển phần mềm thống kê, báo cáo thông minh dựa trên mô hình ngôn ngữ lớn
Sản phẩm thử nghiệm: IntelliReport
Bài toán trọng tâm: Text-to-SQL tiếng Việt trên hạ tầng nội bộ, trong điều kiện tài nguyên hạn chế.
Luận điểm xuyên suốt: Với bài toán Text-to-SQL tiếng Việt trong môi trường yêu cầu bảo mật và giới hạn phần cứng, một mô hình cỡ vừa được đặt trong quy trình suy luận có cấu trúc, kiểm soát được có thể hiệu quả hơn cách sinh SQL trực tiếp hoặc phụ thuộc vào fine-tune.
1. Lý do
1.1. Vấn đề thực tiễn
- Nhu cầu thống kê, tra cứu và lập báo cáo phát sinh thường xuyên, nhưng phần lớn hệ thống hiện tại chỉ đáp ứng các biểu mẫu cố định.
- Khi xuất hiện yêu cầu ngoài biểu mẫu, cán bộ nghiệp vụ phải chuyển yêu cầu cho bộ phận CNTT viết SQL; thời gian chờ có thể kéo dài từ vài giờ đến vài ngày.
- Khảo sát 15 cán bộ, lãnh đạo tại các phòng ban nghiệp vụ cho thấy:
- 85% phản ánh tình trạng “tắc nghẽn thông tin”, phải chờ từ 1 đến 3 ngày đối với báo cáo đột xuất;
- 100% mong muốn có công cụ tự phục vụ bằng tiếng Việt tự nhiên;
- 100% yêu cầu hệ thống hoạt động độc lập để bảo đảm an toàn thông tin.
1.2. Khoảng trống cần giải quyết
- Người dùng nghiệp vụ hiểu câu hỏi cần trả lời nhưng không biết SQL.
- Công cụ BI truyền thống hỗ trợ trực quan hóa tốt nhưng vẫn phụ thuộc vào cấu hình, biểu mẫu và người có chuyên môn dữ liệu.
- Dịch vụ AI thương mại có năng lực cao nhưng không phù hợp với dữ liệu nhạy cảm vì phải truyền dữ liệu ra ngoài.
- Fine-tune mô hình cần dữ liệu gán nhãn chất lượng cao, tốn tài nguyên và khó thích nghi khi lược đồ CSDL thay đổi.
1.3. Ba ràng buộc chi phối đề tài
| Ràng buộc | Yêu cầu đặt ra |
|---|---|
| Bảo mật | Toàn bộ mô hình, câu hỏi, SQL và kết quả phải được xử lý trong mạng nội bộ; không dùng API AI đám mây. |
| Tài nguyên | Giải pháp phải vận hành trong giới hạn GPU 16 GB VRAM; Học viện hiện có GPU NVIDIA A2 dùng chung. |
| Tiếng Việt | Hệ thống phải hiểu câu hỏi tiếng Việt, tên bảng/cột viết tắt hoặc không dấu và giá trị dữ liệu có dấu. |
1.4. Câu hỏi nghiên cứu
- Có thể dùng mô hình ngôn ngữ cỡ vừa để xử lý Text-to-SQL tiếng Việt mà không fine-tune hay không?
- Quy trình suy luận đa giai đoạn có thể bù đắp hạn chế của mô hình cỡ vừa đến mức nào?
- Làm thế nào để SQL do LLM sinh ra có thể được kiểm tra, sửa lỗi và thực thi an toàn?
- Giải pháp có khả thi trên hạ tầng nội bộ với GPU 16 GB VRAM hay không?
2. Tổng quan nghiên cứu
2.1. Bài toán Text-to-SQL trong hệ thống báo cáo thông minh
Text-to-SQL chuyển câu hỏi ngôn ngữ tự nhiên thành truy vấn SQL. Trong IntelliReport, đây là mô-đun nền tảng vì số liệu, biểu đồ và nhận xét chỉ đáng tin cậy khi truy vấn lấy dữ liệu đúng.
Các thách thức chính:
- Sai lệch logic và ảo giác: mô hình có thể chọn sai bảng, cột, phép tổng hợp hoặc điều kiện lọc.
- Khó kiểm chứng: câu trả lời tự nhiên không cho thấy rõ dữ liệu được lấy bằng logic nào.
- Lược đồ lớn và thay đổi: đưa toàn bộ schema vào prompt gây tràn ngữ cảnh; fine-tune lại khi schema đổi không linh hoạt.
- An toàn dữ liệu: LLM không được truy cập trực tiếp CSDL sản xuất hoặc thực thi truy vấn thay đổi dữ liệu.
- Đặc thù tiếng Việt: cách diễn đạt tự nhiên có thể mơ hồ, trong khi tên định danh kỹ thuật thường viết tắt hoặc không dấu.
2.2. Các hướng tiếp cận phổ biến
| Hướng tiếp cận | Ưu điểm | Hạn chế trong bối cảnh đề tài |
|---|---|---|
| Fine-tuning | Có thể thích nghi với miền dữ liệu cụ thể | Cần nhiều cặp câu hỏi–SQL chất lượng cao; tốn GPU; phải cập nhật khi schema đổi |
| RAG / truy xuất ngữ cảnh | Linh hoạt với dữ liệu động | Cần hạ tầng truy xuất; độ chính xác liên kết lược đồ giảm khi schema lớn |
| Mô hình lai | Kết hợp ưu điểm của nhiều kỹ thuật | Kiến trúc và vận hành phức tạp hơn |
| Sinh SQL trực tiếp | Đơn giản, độ trễ thấp | Khó kiểm soát; dễ sai JOIN, WHERE và logic tổng hợp |
| Multi-stage prompting | Phân rã suy luận, kiểm soát từng bước, không cần huấn luyện | Nhiều bước xử lý hơn và cần tối ưu độ trễ |
2.3. Lựa chọn của đề tài
- Chọn Qwen3-8B INT8 vì cân bằng giữa năng lực tiếng Việt, sinh mã/SQL và giới hạn bộ nhớ khoảng 16 GB VRAM.
- Chọn chiến lược training-free:
- không cập nhật trọng số mô hình;
- không dùng dữ liệu nghiệp vụ thật để huấn luyện;
- đưa tri thức lược đồ vào đúng thời điểm trong quy trình.
- Thiết kế pipeline tuần tự tĩnh thay vì agent tự hành để mỗi bước có đầu vào, đầu ra và cơ chế kiểm soát xác định.
2.4. Khoảng trống nghiên cứu
Theo khảo sát tài liệu được trình bày trong báo cáo gốc, đến thời điểm thực hiện đề tài chưa có công trình áp dụng multi-stage prompting cho tập ViText2SQL. Đề tài tập trung kiểm chứng khả năng dùng quy trình suy luận có cấu trúc để khai thác một mô hình 8B trong điều kiện bảo mật và tài nguyên hạn chế.
3. Phương pháp đề xuất
3.1. Ý tưởng cốt lõi
Không yêu cầu LLM giải quyết toàn bộ bài toán trong một lần. Hệ thống phân rã quá trình từ câu hỏi tiếng Việt đến kết quả báo cáo thành bước tiền xử lý và 8 giai đoạn cố định. LLM chỉ suy luận tại các trạm được chỉ định; các lớp dựa trên luật, quyền chỉ đọc và kiểm chứng thực thi kiểm soát đầu ra.
Hình 1. Luồng xử lý Text-to-SQL được vẽ lại từ Hình 2.3 của báo cáo gốc.
3.2. Chi tiết các giai đoạn
| Bước | Chức năng | Cơ chế chính |
|---|---|---|
| Tiền xử lý | Đánh giá độ rõ ràng, làm rõ ý định; phân rã yêu cầu báo cáo thành tối đa 4 câu hỏi con | Heuristic + LLM |
| GĐ1. Rút gọn lược đồ | Chọn tối đa 8 bảng cùng các cột, khóa ngoại liên quan | Đối sánh token + LLM + cache |
| GĐ2. Lập kế hoạch logic | Xác định bảng cần JOIN, điều kiện WHERE, GROUP BY và phép tổng hợp | LLM, bật suy luận sâu |
| GĐ3. Sinh mã SQL | Chuyển kế hoạch logic thành SQL chuẩn chung | LLM, tắt suy luận sâu |
| GĐ4. Tự kiểm tra | Đối chiếu SQL với kế hoạch và schema; tự sửa nếu phát hiện lỗi | LLM, bật suy luận sâu |
| GĐ5. Dịch phương ngữ SQL | Chuyển SQL chuẩn chung sang T-SQL, ví dụ LIMIT → TOP |
Bộ luật chuyển đổi |
| GĐ6. Thực thi và tự sửa lỗi | Thực thi chỉ đọc; chặn từ khóa nguy hiểm; tự sửa tối đa 2 lần khi MSSQL báo lỗi | Thực thi + LLM auto-fix |
| GĐ7. Kiểm định dữ liệu | Phát hiện kết quả rỗng, dòng null/0/rỗng hoặc các dòng giống hệt nhau | Kiểm tra dựa trên luật |
| GĐ8. Phân tích và trực quan | Chọn biểu đồ, phát hiện xu hướng và bất thường, sinh nhận xét | Mô hình lai + LLM |
3.3. Điểm đóng góp kỹ thuật cần nhấn mạnh
- Lập kế hoạch trước khi viết SQL: tách bước hiểu logic khỏi bước sinh cú pháp.
- Bật/tắt suy luận sâu theo giai đoạn: chỉ dùng Chain-of-Thought tại bước cần phân tích phức tạp để cân bằng chất lượng và tài nguyên.
- Kết hợp AI với thành phần xác định: dùng luật cho dịch phương ngữ, kiểm định kết quả và chặn truy vấn nguy hiểm.
- Bảo mật phòng thủ nhiều lớp: kiểm tra truy vấn, tài khoản CSDL chỉ đọc, RBAC và nhật ký truy vấn.
- Khả năng kiểm chứng: người dùng có thể xem SQL, tiến trình xử lý và kết quả trước khi sử dụng trong báo cáo.
3.4. Kiến trúc triển khai
Frontend React/Vite + Socket.IO
-> Backend Node.js/Express
-> NLQ Pipeline 8 giai đoạn
-> Bộ nhớ đệm RocksDB
-> Local LLM API: Qwen3-8B INT8 + TensorRT-LLM
-> CSDL quản lý nội bộ và các CSDL nghiệp vụ MSSQL chỉ đọc
4. Triển khai thực nghiệm và đánh giá
4.1. Thiết lập thực nghiệm
- Tập đánh giá: ViText2SQL, gồm 1.906 mẫu kiểm thử.
- Chỉ số chính: Spider Exact Match (EM).
- Môi trường kiểm thử: NVIDIA RTX A4000, 16 GB VRAM; Qwen3-8B INT8; TensorRT-LLM.
- Phân tích bổ sung: kết quả theo độ khó, theo thành phần SQL, ablation study và phân tích lỗi.
Lưu ý khi trình bày: Báo cáo kiểm thử trực tiếp trên A4000 16 GB. GPU A2 16 GB là hạ tầng mục tiêu được đánh giá tương thích về dung lượng VRAM, nhưng chưa có benchmark hiệu năng trực tiếp trong báo cáo.
4.2. Kết quả tổng thể
| Mô hình | Phương thức | Exact Match |
|---|---|---|
| EditSQL (PhoBERT) | Fine-tuning | 42,2% |
| IRNet (PhoBERT) | Fine-tuning | 53,2% |
| IntelliReport | Training-free, pipeline đa giai đoạn | 58,5% |
IntelliReport cao hơn mô hình cơ sở mạnh nhất IRNet-PhoBERT 5,3 điểm phần trăm, trong khi không dùng dữ liệu gán nhãn để fine-tune.
4.3. Kết quả theo độ khó
| Mức độ | IRNet (PhoBERT) | IntelliReport | Chênh lệch |
|---|---|---|---|
| Dễ | 76,8% | 75,5% | −1,3 |
| Trung bình | 57,5% | 61,6% | +4,1 |
| Khó | 47,2% | 53,4% | +6,2 |
| Cực khó | 24,8% | 33,2% | +8,4 |
Mức cải thiện tăng theo độ phức tạp của truy vấn. Điều này cho thấy pipeline có cấu trúc phát huy giá trị rõ hơn ở câu hỏi cần JOIN, lọc nhiều tầng và suy luận nhiều bước.
4.4. Ablation study: vai trò của lập kế hoạch logic
| Cấu hình | Exact Match |
|---|---|
| Đầy đủ pipeline 8 giai đoạn | 58,5% |
| Bỏ GĐ2 – Lập kế hoạch logic | 48,5% |
Việc bỏ bước lập kế hoạch làm giảm 10,0 điểm phần trăm Exact Match. Đây là bằng chứng thực nghiệm quan trọng nhất cho luận điểm: thiết kế quy trình suy luận có cấu trúc có thể bù đắp đáng kể giới hạn của mô hình cỡ vừa.
4.5. Hạn chế được ghi nhận
GROUP BY + HAVINGđạt 55,5% F1, thấp hơn IRNet-PhoBERT 12,7 điểm.- Các phép toán tập hợp
UNION,INTERSECT,EXCEPT,NOT INchỉ đạt 31,2% F1. - Spider Exact Match có thể đánh giá sai các SQL tương đương ngữ nghĩa nhưng khác cách biểu diễn giá trị tiếng Việt.
- Pipeline nguyên mẫu có độ trễ trung bình khoảng 65 giây/truy vấn, chưa phù hợp để triển khai rộng nếu không tối ưu.
- Kết quả 58,5% chứng minh tính khả thi của hướng nghiên cứu, chưa đủ để tin tưởng và tự động thực thi mọi truy vấn phức tạp.
5. Kết luận
5.1. Kết quả chính
- Đề tài đã đề xuất và hiện thực hóa pipeline Text-to-SQL tiếng Việt training-free gồm 8 giai đoạn.
- Qwen3-8B INT8 đạt 58,5% Exact Match trên ViText2SQL với GPU kiểm thử 16 GB VRAM.
- Pipeline vượt IRNet-PhoBERT 5,3 điểm phần trăm; riêng bước lập kế hoạch logic đóng góp 10,0 điểm phần trăm.
- Hệ thống chứng minh khả năng triển khai nội bộ, bảo vệ dữ liệu và hỗ trợ người dùng nghiệp vụ khai thác CSDL bằng tiếng Việt tự nhiên.
5.2. Ý nghĩa
- Khoa học: cung cấp bằng chứng rằng quy trình suy luận có cấu trúc là hướng khả thi cho Text-to-SQL tiếng Việt khi thiếu dữ liệu huấn luyện.
- Kỹ thuật: kết hợp LLM với lựa chọn schema, self-check, dịch SQL, kiểm soát an toàn, sửa lỗi thực thi và trực quan hóa.
- Thực tiễn: giảm phụ thuộc vào cán bộ biết SQL và tạo nền tảng cho khai thác dữ liệu nội bộ theo mô hình tự phục vụ.
5.3. Hướng phát triển
- Rút gọn prompt, song song hóa GĐ1 và giảm số lần gọi LLM để đưa độ trễ về mức có thể sử dụng thực tế.
- Bổ sung mẫu xử lý chuyên biệt cho
GROUP BY + HAVINGvà các phép toán tập hợp. - Xây dựng thước đo đánh giá phù hợp hơn với tiếng Việt, kết hợp Exact Match với đánh giá ngữ nghĩa và kết quả thực thi.
- Bổ sung cơ chế xác nhận của con người đối với truy vấn phức tạp hoặc có độ tin cậy thấp.
- Chỉ xem xét LoRA/fine-tune khi đã tích lũy đủ dữ liệu nghiệp vụ được gán nhãn và có hạ tầng phù hợp.
Kết luận cần bảo vệ: Trong môi trường tài nguyên hạn chế và yêu cầu bảo mật cao, giá trị của hệ thống không nằm ở việc dùng mô hình lớn nhất, mà ở cách tổ chức quy trình suy luận, kiểm soát đầu ra và kiểm chứng kết quả.