Báo Cáo Phân Tích Dataset Text2SQL & Đánh Giá Chất Lượng Sinh SQL Tự Động

Ngày báo cáo: 04/05/2026
Hệ thống: IntelliReport — Text2SQL Dataset Builder
Cơ sở dữ liệu mục tiêu: TKB_refine (Quản lý Thời Khóa Biểu, 19 bảng, 126 cột, MSSQL Server)

Phần I — Tổng Quan Dataset

1.1. Giới thiệu

Dataset Text2SQL của hệ thống IntelliReport được xây dựng với mục tiêu huấn luyện và đánh giá khả năng chuyển đổi câu hỏi tiếng Việt tự nhiên thành truy vấn SQL (T-SQL) trên hệ quản trị cơ sở dữ liệu Microsoft SQL Server. Cơ sở dữ liệu mục tiêu là TKB_refine — hệ thống quản lý thời khóa biểu của một học viện, bao gồm 19 bảng dữ liệu thuộc 3 schema (dbo, DTao, TKB) với tổng cộng 126 cột.

1.2. Quy trình thu thập dữ liệu

Dataset được thu thập theo mô hình crowdsourcing có kiểm duyệt:

Đặt câu hỏi: Các annotator (học viên, quản trị viên) đăng nhập hệ thống và đặt câu hỏi bằng tiếng Việt tự nhiên về dữ liệu trong database.
Sinh SQL tự động: Hệ thống sử dụng mô hình AI (Gemini) để tự động sinh câu truy vấn SQL (generated_sql) tương ứng với câu hỏi, dựa trên schema database được cung cấp.
Đánh giá tự động: Hệ thống đánh giá chất lượng câu hỏi (mức độ khó, tính hợp lệ) và SQL sinh ra (thực thi thử trên database thật).
Duyệt thủ công: Quản trị viên xem xét từng cặp (câu hỏi, SQL) và quyết định approve hoặc reject. Khi approve, generated_sql trở thành ứng cử viên cho golden_sql (đáp án chuẩn).

1.3. Quy mô dataset

Chỉ số	Giá trị
Tổng số câu hỏi đã gửi	2,381
Số câu được approved	1,054 (44.3%)
Số câu bị rejected	1,327 (55.7%)
Khoảng thời gian thu thập	07/04/2026 — 03/05/2026 (~27 ngày)
Số annotator tham gia	40 người

[!NOTE] Tỉ lệ reject khá cao (55.7%), cho thấy quy trình kiểm duyệt nghiêm ngặt. Các câu bị reject chủ yếu do: câu hỏi trùng lặp, câu hỏi không rõ nghĩa, hoặc SQL sinh ra không hợp lệ. Trong số 1,327 câu bị reject, có đến 646 câu (48.7%) không được phân loại mức độ khó (difficulty = null) — cho thấy chúng bị loại ngay từ giai đoạn đánh giá tự động trước khi đến bước duyệt thủ công.

1.4. Phân bổ theo mức độ khó (Difficulty)

Mức độ khó được hệ thống AI tự động phân loại dựa trên độ phức tạp của câu truy vấn SQL tương ứng:

Mức độ	Approved	Rejected	Tổng	Tỉ lệ Approve
Easy	376	188	564	66.7%
Medium	437	167	604	72.4%
Hard	200	218	418	47.8%
Extra Hard	41	108	149	27.5%
(Chưa phân loại)	0	646	646	0%

[!IMPORTANT] Insight: Tỉ lệ approve giảm mạnh theo độ khó — từ 66.7% (Easy) xuống chỉ 27.5% (Extra Hard). Điều này phản ánh hai vấn đề song song: (1) câu hỏi phức tạp khó đặt đúng ngữ cảnh, và (2) mô hình AI khó sinh SQL chính xác hơn cho truy vấn phức tạp, dẫn đến tỉ lệ reject cao hơn.

1.5. Phân bổ đóng góp theo Annotator

Dữ liệu được đóng góp bởi 40 annotator với mức độ tham gia khác nhau:

Nhóm	Số người	Tổng câu	Tỉ lệ Approve TB
Top contributor (>100 câu)	5	1,010 (42.4%)	44.0%
Trung bình (30–100 câu)	19	1,014 (42.6%)	43.5%
Ít đóng góp (<30 câu)	16	357 (15.0%)	47.6%

Annotator đóng góp nhiều nhất: Học viên 075 (388 câu, tỉ lệ approve 78.9%). Annotator có tỉ lệ reject cao nhất: Học viên 097 (104 câu, tỉ lệ approve chỉ 1.9%) — cho thấy sự chênh lệch lớn về chất lượng câu hỏi giữa các annotator.

Phần II — Phân Tích Độ Chính Xác Của AI Trong Việc Sinh SQL

2.1. Bối cảnh & Mục tiêu

Khi một câu hỏi được approve, hệ thống gán generated_sql (SQL do AI sinh) làm golden_sql (đáp án chuẩn). Tuy nhiên, SQL do AI sinh không phải lúc nào cũng đúng — có thể sai cú pháp T-SQL, sai schema prefix, hoặc sai ngữ nghĩa so với câu hỏi gốc.

Để đảm bảo chất lượng dataset, chúng tôi tiến hành rà soát và chuẩn hóa toàn bộ 1,028 câu approved có golden SQL, nhằm: - Phát hiện và sửa các gold SQL sai lệch - Đo lường chính xác khả năng sinh SQL của AI theo từng mức độ khó

[!NOTE] Có 26 câu approved không có cả generated_sql lẫn golden_sql (do lỗi trong quá trình xử lý), không nằm trong phạm vi phân tích này.

2.2. Phương Pháp Kiểm Tra

Quy trình kiểm tra được tự động hóa hoàn toàn qua một pipeline gồm 3 bước:

Bước 1 — Chuẩn bị dữ liệu

Truy xuất toàn bộ câu approved từ management DB
Export schema đầy đủ của database mục tiêu TKB_refine (19 bảng, 126 cột, bao gồm kiểu dữ liệu và primary key)
Với các câu chưa có golden_sql: gán golden_sql = generated_sql để đưa vào phân tích

Bước 2 — Đối chiếu bằng AI (Gemini 2.5 Pro)

Chia 1,028 câu thành 69 batch, mỗi batch 15 câu
Mỗi batch được gửi đến model Gemini 2.5 Pro (qua Gemini CLI) kèm theo:
Schema đầy đủ của database (tên bảng, tên cột, kiểu dữ liệu, schema prefix)
Bộ tiêu chí đánh giá rõ ràng (KEEP nếu đúng, FIX nếu sai rõ ràng)
Danh sách 15 cặp (câu hỏi tiếng Việt, gold SQL hiện tại)
Model trả về verdict cho từng câu: KEEP (giữ nguyên) hoặc FIX (cần sửa, kèm SQL mới)
Nguyên tắc: Không khắt khe — chỉ đánh dấu FIX khi SQL sai rõ ràng. Nếu câu hỏi mơ hồ và SQL là cách hiểu hợp lý → KEEP.

Bước 3 — Xác thực trên Database thật

Mỗi SQL mới do Gemini đề xuất được chạy thử trực tiếp trên database TKB_refine
Nếu thực thi thành công → chấp nhận fix, cập nhật golden_sql trong database
Nếu thực thi thất bại → từ chối fix, giữ nguyên SQL cũ
Đảm bảo không có regression: SQL mới phải chạy được trước khi thay thế SQL cũ

1,028 câu → 69 batch → Gemini 2.5 Pro review → Parse kết quả
→ Verify trên DB thật → Apply fix hoặc giữ nguyên

2.3. Kết Quả Rà Soát Gold SQL

Metric	Số lượng	Tỉ lệ
Tổng số câu đã rà soát	1,028	100%
KEEP — gold SQL đã đúng, giữ nguyên	644	62.6%
FIX — gold SQL cần sửa	384	37.4%
Fix thành công (verify OK, đã cập nhật)	256	66.7% tổng fix
Fix thất bại (verify lỗi, giữ SQL cũ)	6	1.6% tổng fix
Gemini timeout (default giữ nguyên)	122	—

[!IMPORTANT] 37.4% gold SQL cần sửa — tức hơn 1/3 lượng SQL mà AI sinh ra ban đầu có vấn đề (sai cú pháp, sai schema, hoặc sai logic). Đây là con số quan trọng cho thấy việc duyệt thủ công hoặc kiểm tra tự động gold SQL là bắt buộc để đảm bảo chất lượng dataset.

2.4. Độ Chính Xác Của Generated SQL — Tổng Quan

Sau khi chuẩn hóa gold SQL, chúng tôi so sánh generated_sql (SQL gốc do AI sinh) với golden_sql (đáp án chuẩn sau review):

Metric	Số lượng	Tỉ lệ
`generated_sql` khớp hoàn toàn `golden_sql`	736	71.6%
`generated_sql` sai lệch so với `golden_sql`	292	28.4%

Ý nghĩa: Mô hình AI hiện tại sinh SQL đúng chuẩn cho 71.6% câu hỏi. Gần 3/10 câu cần can thiệp từ con người hoặc AI reviewer để đạt chất lượng gold standard.

2.5. Phân Tích Theo Mức Độ Khó — Insight Chính

Mức độ	Tổng câu	gen == gold	Tỉ lệ đúng	Sai lệch	Tỉ lệ sai
Easy	373	332	89.0%	41	11.0%
Medium	423	277	65.5%	146	34.5%
Hard	192	106	55.2%	86	44.8%
Extra Hard	40	21	52.5%	19	47.5%

xychart-beta
    title "Tỉ lệ sinh SQL chính xác theo mức độ khó"
    x-axis ["Easy", "Medium", "Hard", "Extra Hard"]
    y-axis "Tỉ lệ đúng (%)" 0 --> 100
    bar [89.0, 65.5, 55.2, 52.5]

[!IMPORTANT] Phân tích xu hướng:

Easy (89.0%) — Các truy vấn đơn giản như SELECT COUNT(*), lọc 1 bảng, hoặc JOIN 2 bảng cơ bản. AI xử lý rất tốt ở mức này, chỉ 11% bị sai — chủ yếu do sai schema prefix (dbo. thay vì TKB.).

Medium (65.5%) — Bắt đầu xuất hiện sai lệch đáng kể. Các truy vấn mức này thường yêu cầu JOIN 2-3 bảng, GROUP BY với aggregate function, hoặc WHERE với nhiều điều kiện. Lỗi phổ biến: sai schema prefix, dùng LIMIT thay TOP, thiếu điều kiện lọc.

Hard (55.2%) — Gần nửa số câu bị sai. Các truy vấn cần subquery, HAVING, hoặc logic phức tạp. AI thường sai ở việc chọn sai bảng để JOIN hoặc thiếu mệnh đề GROUP BY cho các cột non-aggregated.

Extra Hard (52.5%) — Chỉ đúng ~50/50. Các truy vấn dạng CTE, nested subquery, so sánh kết quả giữa nhiều bảng. Đây là giới hạn hiện tại của model — cần cải thiện prompt engineering hoặc fine-tuning chuyên biệt.

2.6. Phân Loại Lỗi Thường Gặp

Trong 384 câu gold SQL cần sửa, các loại lỗi phổ biến được phân loại như sau:

Loại lỗi	Số lượng	Tỉ trọng	Mô tả
LIMIT → TOP	107	27.9%	Dùng `LIMIT N` (cú pháp MySQL/PostgreSQL) thay vì `SELECT TOP N` đúng chuẩn T-SQL
Sai schema prefix	76	19.8%	VD: ghi `dbo.tbPhanNam` nhưng bảng thực tế nằm ở schema `TKB.tbPhanNam`
Sai ngữ nghĩa	48	12.5%	SQL trả kết quả không đúng ý câu hỏi (VD: hỏi COUNT nhưng trả danh sách)
Thiếu điều kiện	40	10.4%	Câu hỏi nói "thuộc khoa X" nhưng SQL không có WHERE lọc
Sai cú pháp T-SQL	9	2.3%	Lỗi syntax đặc thù MSSQL
Sai alias/binding	7	1.8%	Alias đã khai báo nhưng vẫn gọi bằng tên bảng gốc
Thiếu Unicode prefix	7	1.8%	So sánh chuỗi tiếng Việt thiếu `N'...'`
Khác	90	23.4%	Các lỗi nhỏ lẻ không thuộc nhóm trên

[!TIP] Ba hướng cải thiện hiệu quả nhất (có thể giảm ~60% lỗi): 1. Bổ sung rule trong prompt: "Đây là MSSQL Server. LUÔN dùng SELECT TOP N thay vì LIMIT N" → giảm 107 lỗi 2. Cung cấp schema prefix mapping rõ ràng: Liệt kê explicit bảng nào thuộc schema nào → giảm 76 lỗi 3. Tăng few-shot examples cho câu phức tạp: Đặc biệt các pattern subquery, HAVING, CTE → giảm lỗi ngữ nghĩa ở Hard/Extra Hard

2.7. Các Câu Hỏi Không Thể Sửa Tự Động (6 câu)

6 câu mà Gemini đề xuất SQL mới nhưng vẫn không thực thi được trên database:

ID	Nguyên nhân
904	Câu hỏi generic dạng "môn cụ thể" → SQL chứa biến `@specific_monhoc_id` chưa khai báo
1976	Tương tự — biến `@IdCTKhung` chưa khai báo
1851	Alias binding sai: `T1.IdNamHoc` không tồn tại trong scope
1963	Cột `IdCTKhung` không tồn tại trong bảng được tham chiếu
1191	Lỗi constraint khi tạo index trong truy vấn
1291	Bảng `dbo.tbDieuKienMonHocChiTiet` không tồn tại trong database

Tóm Tắt & Kết Luận

Chỉ số	Giá trị
Tổng câu hỏi đã gửi	2,381
Tổng câu được approve	1,054 (44.3%)
Tổng câu đã rà soát gold SQL	1,028
Gold SQL đúng từ đầu (KEEP)	62.6%
Gold SQL đã sửa thành công	24.9% (256 câu)
Generated SQL khớp Gold SQL (tổng thể)	71.6%
Accuracy — Easy	89.0%
Accuracy — Medium	65.5%
Accuracy — Hard	55.2%
Accuracy — Extra Hard	52.5%

Mô hình AI hiện tại đạt tỉ lệ sinh SQL chính xác 71.6% trên toàn bộ dataset. Ở mức Easy, tỉ lệ gần 90% — cho thấy model hoạt động tốt với các truy vấn cơ bản. Tuy nhiên, với các truy vấn phức tạp (Hard/Extra Hard), accuracy giảm xuống ~50-55%, cho thấy đây là vùng cần ưu tiên cải thiện thông qua prompt engineering, bổ sung few-shot examples, và refine schema context.