Để LLM viết SQL đáng tin hơn: 5 lớp kiểm soát cho team BI
LLM có thể hỗ trợ chuyển câu hỏi tiếng Việt thành SQL, nhưng schema thôi là chưa đủ. Từ điển nghiệp vụ, view chuẩn hoá, giải thích dễ đọc, kiểm thử và quyền đọc giới hạn giúp giảm rủi ro sai KPI hoặc JOIN nhầm.
“Doanh thu tháng 9 theo khu vực” nghe như một câu hỏi BI đơn giản. Nhưng chỉ riêng từ doanh thu đã có thể có nhiều cách hiểu: có tính hàng trả lại không, theo ngày tạo đơn hay ngày thanh toán, có loại đơn huỷ không?
Vì vậy, LLM có thể tạo ra SQL chạy được nhưng vẫn trả lời sai câu hỏi. Rủi ro tăng thêm khi mô hình phải tự đoán quan hệ giữa những bảng có tên gần giống nhau.
Câu trả lời ngắn cho thảo luận này: dùng được, nhưng không nên chỉ đưa schema rồi để LLM tự suy luận toàn bộ. Nếu muốn business tự hỏi dữ liệu bằng tiếng Việt, team data vẫn cần kiểm soát định nghĩa KPI, nguồn dữ liệu và quyền truy cập.
Dưới đây là 5 lớp kiểm soát có thể bắt đầu ngay.
1. Chốt nghĩa KPI trước khi yêu cầu viết SQL
Schema cho LLM biết tên bảng, cột và kiểu dữ liệu. Schema không tự nói rõ KPI của doanh nghiệp được tính như thế nào.
Ví dụ, dữ liệu có thể có các bảng orders, payments, returns. Nhưng mô hình không thể tự biết doanh thu cần lấy từ bảng nào, trạng thái nào được tính, hay khoản hoàn tiền được xử lý ra sao nếu những quy tắc này không được cung cấp.
Vì vậy, hãy chuẩn bị một từ điển nghiệp vụ. Đây cũng là cách một thành viên cộng đồng cho biết đã giúp giảm lỗi hiểu sai định nghĩa.
Một mẫu ngữ cảnh tối thiểu:
text
Vai trò: Bạn là trợ lý phân tích dữ liệu.
Không tự suy đoán định nghĩa KPI.
<TỪĐIỂNNGHIỆPVỤ>
KPI: <tên KPI>
Định nghĩa: <công thức đã được phê duyệt>
Nguồn dữ liệu được phép: <view hoặc bảng>
Điều kiện loại trừ: <trạng thái / loại giao dịch>
Trường ngày dùng để phân tích: <cột ngày>
Cách hiểu “tháng”: <quy ước lịch>
</TỪĐIỂNNGHIỆPVỤ>
Nếu câu hỏi thiếu thông tin để chọn đúng định nghĩa, hãy hỏi lại.
Không được tự tạo tên bảng, cột hoặc KPI.
Điểm quan trọng: JOIN đúng nhưng dùng sai định nghĩa doanh thu thì dashboard vẫn sai. Và lỗi này dễ lọt qua hơn lỗi cú pháp, vì con số có thể vẫn trông hợp lý.
2. Chỉ cho LLM query các view đã chuẩn hoá
Một gợi ý rất thực tế từ cộng đồng là tạo sẵn view chuẩn hoá cho các chỉ số chính, thay vì mở toàn bộ warehouse cho LLM.
View đóng vai trò lớp trung gian: team data đóng gói sẵn logic JOIN, điều kiện lọc và cách tính đã thống nhất. Khi đó, LLM tập trung vào việc chọn bộ lọc, chiều phân tích và cách nhóm dữ liệu, thay vì tự nối các bảng nghiệp vụ.
| View được phép | Phù hợp để hỏi | Không nên để LLM tự xử lý |
|---|---|---|
| <viewdoanhthu> | Doanh thu theo thời gian, khu vực, kênh | Tự JOIN đơn hàng với hoàn tiền |
| <viewkhachhang> | Phân khúc khách hàng | Tự đoán khoá liên kết CRM |
| <viewhieusuat> | Báo cáo vận hành | Tự diễn giải trạng thái nghiệp vụ |
Cách này giảm “bề mặt lỗi”: thay vì liên tục vá prompt khi LLM JOIN nhầm, team data chuẩn hoá mô hình dữ liệu ở một nơi.
Với chỉ số phức tạp, hãy ưu tiên đưa logic vào metric hoặc view đã được kiểm duyệt. Text-to-SQL phù hợp hơn với việc truy vấn trên nền ngữ nghĩa đã chuẩn hoá, không phải thay thế semantic layer.
3. Hiển thị cả SQL lẫn lời giải thích dễ đọc
Một thành viên diễn đàn chia sẻ rằng team của họ hiển thị SQL kèm phần giải thích bằng lời: đang tính theo điều kiện nào, dùng trường ngày nào và nhóm theo đâu.
Đây là một lớp kiểm tra hữu ích vì người dùng business thường không đọc được JOIN, nhưng vẫn có thể phát hiện điều bất thường qua mô tả như:
“Đang tính doanh thu theo ngày <cột ngày>.”
“Đã loại trừ <trạng thái>.”
“Kết quả được nhóm theo <chiều phân tích>.”
“Dữ liệu lấy từ <view được phép>.”
Có thể yêu cầu LLM trả về theo cấu trúc cố định:
text
Với câu hỏi: "<câu hỏi tiếng Việt>"
Chỉ trả về:
SQL
Danh sách view hoặc bảng đã dùng
Giải thích ngắn bằng tiếng Việt về:
KPI đang tính
bộ lọc áp dụng
trường ngày sử dụng
cách nhóm dữ liệu
Các giả định hoặc điểm cần người dùng xác nhận
Nếu không tìm thấy cột hoặc định nghĩa trong ngữ cảnh được cấp, không viết SQL.
Lời giải thích không thay thế việc review SQL. Nhưng nó tạo thêm một điểm kiểm tra bằng ngôn ngữ nghiệp vụ trước khi con số được dùng trong báo cáo.
4. Xem SQL do LLM sinh ra là bản nháp cần xác minh
Bài viết liên quan của NVIDIA nói về việc dùng agent để chuyển đổi Spark UDF sang dạng có thể tăng tốc GPU. Đây không phải hướng dẫn text-to-SQL, nhưng nguyên tắc đáng tham khảo là: mã do agent tạo ra không nên được xem là đúng chỉ vì nó chạy; cần có kiểm thử và xác minh trước khi chấp nhận.
Áp dụng cho text-to-SQL, một vòng kiểm tra ngắn có thể gồm:
Kiểm tra schema: bảng, view và cột có tồn tại không?
Chạy trong môi trường phù hợp: phát hiện lỗi cú pháp, cột không tồn tại hoặc kiểu dữ liệu không khớp.
Đối chiếu tổng: so với dashboard hoặc truy vấn đã được analyst kiểm tra.
Review JOIN: kiểm tra nguy cơ nhân bản dòng, nhất là khi nối bảng giao dịch với bảng chi tiết.
Kiểm tra điều kiện lọc: xác nhận kỳ báo cáo, giá trị rỗng và các điều kiện loại trừ.
Khi review, đừng chỉ hỏi “con số có đúng không?”. Hãy hỏi thêm:
Tổng theo khu vực có khớp tổng KPI không?
Có khu vực nào bị mất vì dữ liệu rỗng không?
Một giao dịch có bị tính lặp sau JOIN không?
Câu truy vấn có đúng với định nghĩa KPI đã công bố không?
Các câu hỏi quen thuộc, dùng view rõ ràng và KPI chuẩn hoá có thể được tự động hoá nhiều hơn. Với KPI mới, nhiều ngoại lệ hoặc truy vấn nhiều bảng chi tiết, nên có bước analyst review.
5. Giới hạn quyền và tài nguyên truy vấn
Cộng đồng cũng nhắc đến một rủi ro vận hành: một câu hỏi tưởng như vô hại có thể quét bảng lớn hoặc chạm vào dữ liệu không cần thiết.
Tối thiểu, tài khoản phục vụ text-to-SQL nên là read-only và chỉ được truy cập các view hoặc bảng đã chọn. Nên đặt giới hạn thời gian chạy và số dòng kết quả để kiểm soát chi phí cũng như tải hệ thống.
Checklist triển khai:
Chỉ cấp quyền đọc cho các view đã chuẩn hoá.
Không cho phép thao tác ghi hoặc thay đổi cấu trúc dữ liệu.
Giới hạn thời gian chạy truy vấn.
Giới hạn lượng dữ liệu trả về.
Ghi log câu hỏi, SQL được sinh ra và trạng thái thực thi.
Bắt đầu từ một phạm vi hẹp
Không cần đặt mục tiêu để LLM “hiểu toàn bộ data warehouse” ngay từ đầu.
Hãy bắt đầu bằng một nhóm câu hỏi lặp lại, chẳng hạn doanh thu, số đơn, phân tích theo khu vực hoặc kênh. Chuẩn bị từ điển nghiệp vụ, một số view đáng tin cậy, rồi yêu cầu LLM tạo SQL kèm giải thích. Analyst review kết quả ban đầu để bổ sung định nghĩa và nhận diện các mẫu lỗi thường gặp.
Mục tiêu thực tế là: business tự trả lời được các câu hỏi quen thuộc, còn team data vẫn kiểm soát KPI, quan hệ dữ liệu và quyền truy cập.