Khi AI viết SQL: Ai là 'trùm cuối' trong thế giới dữ liệu lớn?
Lê Lân0
Đánh Giá Khả Năng Viết SQL Phân Tích Của Các Mô Hình Ngôn Ngữ Lớn (LLM) Trên Bộ Dữ Liệu 200 Triệu Dòng
Mở Đầu
Khả năng tự động sinh các truy vấn SQL từ ngôn ngữ tự nhiên bởi các mô hình ngôn ngữ lớn (LLM) đang ngày càng trở nên quan trọng trong phân tích dữ liệu quy mô lớn. Tuy nhiên, việc đánh giá độ chính xác và hiệu quả của các truy vấn này vẫn còn là thách thức.
Trong nghiên cứu lần này, chúng tôi đã yêu cầu 19 mô hình LLM phổ biến cùng 1 kỹ sư con người viết các truy vấn SQL phân tích, để lọc và tổng hợp một bộ dữ liệu chứa 200 triệu dòng sự kiện GitHub công khai. Kết quả tạo nên phiên bản đầu tiên của LLM SQL Generation Benchmark, một bộ tiêu chuẩn nhằm đánh giá khả năng viết SQL chính xác và hiệu quả của các mô hình so với con người.
Bài viết sẽ giới thiệu tổng quan về bộ dữ liệu, các câu hỏi phân tích, hệ thống đánh giá và kết quả chính của nghiên cứu, đưa ra cái nhìn sâu sắc về ưu - nhược điểm của từng mô hình trong thực tế ứng dụng.
Bộ Dữ Liệu: GitHub Archive
Nguồn Dữ Liệu
GitHub Archive là tập dữ liệu công khai chứa toàn bộ sự kiện diễn ra trên GitHub từ năm 2011, bao gồm thông tin về stars, forks, issues, pull requests, comment, push và nhiều hoạt động khác.
Đặc Điểm Bộ Dữ Liệu
- Bộ dữ liệu dùng trong benchmark được lấy mẫu ngẫu nhiên gồm 200 triệu dòng.
- Lưu trữ dưới dạng bảng MergeTree trên Tinybird.
- Schema bao gồm enums, chuỗi phân loại thấp, timestamp và các trường mảng.
- Toàn bộ dữ liệu và schema được cung cấp cho mô hình dưới dạng ngữ cảnh để hỗ trợ việc sinh truy vấn chính xác.
Các Câu Hỏi Phân Tích
Đặc Điểm Câu Hỏi
- Bao gồm 50 câu hỏi ngôn ngữ tự nhiên về hoạt động công khai trên GitHub.
- Ví dụ câu hỏi: "Top 10 repositories by stars over the past 7 days."
- Mỗi mô hình phải chuyển đổi câu hỏi tự nhiên này thành truy vấn SQL chạy trên bảng.
Yêu Cầu Đối Với Mô Hình
- Phân tích ngữ nghĩa câu hỏi.
- Viết câu truy vấn SQL hợp lệ, đúng cấu trúc (cột, nhóm, điều kiện).
- Truy vấn phải cho kết quả chính xác khi chạy trên dữ liệu thực.
Hệ Thống Prompt và Quy Định
Prompt Hệ Thống
Mỗi mô hình nhận cùng một prompt hệ thống chi tiết hướng dẫn:
- Cấm tạo ra trường dữ liệu không có trong schema.
- Hạn chế dùng
SELECT *trừ khi bắt buộc.
- Không được dùng
LIMITmà không cóORDER BY.
- Tối ưu truy vấn để giảm lượng dữ liệu phải đọc, tăng hiệu quả.
Thông Tin Hỗ Trợ
- Cung cấp đầy đủ schema và danh sách hàm hỗ trợ (countIf, multiIf, arrayJoin,...).
- Yêu cầu output chỉ gồm truy vấn SQL, không giải thích.
Việc chuẩn hóa prompt giúp đảm bảo so sánh công bằng các mô hình và tập trung vào chất lượng query SQL.
Các Mô Hình Được Thử Nghiệm
Danh Sách Mô Hình
- 19 mô hình từ Anthropic (Claude 3.5 & 3.7 Sonnet), OpenAI (GPT-4 Turbo), Google (Gemini), Meta (LLaMA 3 & 4), DeepSeek, Mistral...
- 1 kỹ sư con người tạo truy vấn để làm chuẩn so sánh.
- Mục tiêu mở rộng thử nghiệm, cập nhật khi có mô hình mới ra mắt.
Tiêu Chuẩn Đánh Giá
Chỉ số | Mô tả |
|---|---|
Valid Query Rate | Tỷ lệ truy vấn SQL hợp lệ, có thể chạy thành công. |
First Attempt Rate | Tỷ lệ truy vấn hợp lệ ngay lần thử đầu tiên. |
Execution Time | Thời gian thực thi truy vấn (ms). |
LLM Gen Time | Thời gian sinh truy vấn của mô hình. |
Attempts | Số lần thử lại để có truy vấn hợp lệ. |
Rows Read | Số lượng dòng dữ liệu được đọc khi chạy truy vấn. |
Data Read (bytes) | Dung lượng dữ liệu đọc (byte) khi chạy truy vấn. |
Query Length | Số token trong truy vấn. |
Các Điểm Số Chỉ Đạo
- Efficiency Score: Đo lường tốc độ, số lần thử và hiệu năng truy vấn.
- Exactness Score: Mức độ gần với kết quả truy vấn do con người viết.
- Overall Score = (Efficiency + Exactness) / 2.
Đo Lường Hiệu Quả Kết Quả Truy Vấn
Output Efficiency
- Tính toán dựa trên tiêu hao tài nguyên thực thi + độ nhanh trong sinh truy vấn.
- Điểm hiệu quả được bình thường hóa từ 0-100, điểm cao cho truy vấn ít đọc dữ liệu, nhanh, ít retry.
Output Exactness
- So sánh tập kết quả truy vấn so với truy vấn con người bằng:
- Jaccard Distance (so sánh tập dữ liệu kết quả)
- RMSE trên giá trị số
- F-Score về độ chính xác và bao phủ kết quả
Điểm exactness trung bình cao nhất của mô hình tốt nhất cũng chỉ khoảng 56/100, cho thấy một khoảng cách so với truy vấn con người.
Kết Quả Nổi Bật
Claude Chiếm Ưu Thế Về Độ Chính Xác
- Claude 3.7 đứng đầu bảng tổng hợp.
- 100% truy vấn hợp lệ, 90% thành công ngay lần đầu.
- Giải mã chậm (~3.2 giây) và đọc dữ liệu trung bình 37-40 triệu dòng/truy vấn.
OpenAI Các Model o3/o4 Là Người Chơi Đa Năng
- Đạt 100% truy vấn hợp lệ, thành công lần đầu trên 88-92%.
- Thời gian thực thi và số dòng đọc hợp lý.
- Độ chính xác từ 51–55 điểm, cải thiện khá tốt.
LLaMA 3 Gặp Khó, LLaMA 4 Có Sự Cải Thiện
- LLaMA 3.3 70B đạt tỷ lệ hợp lệ thấp (66%), chính xác thấp (35.56).
- LLaMA 4 Maverick, Scout cải thiện đáng kể, 96-100% hợp lệ, đạt 44-48 điểm exactness.
Gemini Chậm Hơn Do Thời Gian Sinh Truy Vấn Dài
- Gemini 2.5 Pro chính xác cao (91.8%) nhưng sinh truy vấn mất đến 40 giây.
- Phiên bản flash nhanh hơn nhưng chính xác giảm.
Trí Tuệ Nhân Tạo Vẫn Chưa Vượt Qua Trí Tuệ Con Người
- Truy vấn của con người đọc dữ liệu hiệu quả hơn (31 triệu dòng).
- Phần lớn mô hình đọc nhiều hơn từ 1.5 đến 2 lần so với truy vấn chuẩn.
Những Bài Học Quan Trọng
Độ Chính Xác Không Chỉ Dựa Vào Việc Chạy Được Truy Vấn
Nhiều truy vấn do LLM tạo ra có thể chạy nhưng lại sai logic:
- Lọc sai điều kiện, nhóm sai trường.
- Ví dụ về truy vấn tìm nhãn liên quan “bugs hoặc features” không sử dụng đúng hàm
arrayJoin, làm thiếu dữ liệu.
SQL Vẫn Là Kỹ Năng Cần Thiết
- Ngôn ngữ tự nhiên thường thiếu chi tiết, gây nhầm lẫn trong việc diễn giải.
- Việc hiểu và tái kiểm tra truy vấn vẫn cần chuyên môn.
Mô Hình Khó Nắm Bắt Ngữ Cảnh Sâu
- Mô hình thường nhầm lẫn về định nghĩa trường và liên kết dữ liệu.
- Ví dụ: số issue không toàn cục duy nhất, hoặc
repo_namebao gồm cả tổ chức và dự án.
Phân Tích Thời Gian Thực Khác Với Text-to-SQL Thông Thường
- Hệ thống phân tích thời gian thực như Tinybird cần truy vấn nhanh, hiệu quả.
- Nhiều mô hình bỏ qua yếu tố tối ưu thực thi theo thời gian và quy mô.
Mô Hình Có Xu Hướng Dự Đoán Quá Mức
- Khi không chắc chắn, mô hình thường viết truy vấn đọc nhiều dữ liệu hơn, truy vấn phức tạp hơn.
- Con người thường kiểm soát chặt chẽ hơn để giảm sai số.
Độ Phơi Bày Dữ Liệu Là Vấn Đề Chưa Có Giải Pháp
- Việc cho mô hình truy cập dữ liệu thật giúp tăng độ chính xác nhưng tiềm ẩn nguy cơ lộ thông tin nhạy cảm.
Một Số Khuyến Nghị Khi Ứng Dụng LLM Sinh SQL
- Cung cấp đầy đủ ngữ cảnh về schema, types, quan hệ bảng.
- Kiểm tra và lint truy vấn tự động để phát hiện lỗi, tối ưu truy vấn.
- Cân bằng trọng số giữa hiệu quả, độ chính xác và tốc độ sinh truy vấn tùy theo ứng dụng.
- Dùng vòng phản hồi dựa trên kết quả thực thi để cải thiện truy vấn.
- Kết hợp nhiều mô hình chuyên biệt cho từng bước pipeline.
- Đưa ra định dạng phản hồi có cấu trúc để dễ xử lý tự động.
- Xây dựng prompt tùy chỉnh dựa trên lịch sử người dùng và domain cụ thể.
Kết Luận
Nghiên cứu benchmark này cho thấy mặc dù các mô hình LLM hiện đại có thể tạo ra truy vấn SQL chạy được, nhưng độ chính xác và hiệu quả truy vấn vẫn chưa đạt đến bậc thầy con người viết. Việc đánh giá truy vấn phải dựa trên kết quả thực tế, không chỉ dựa trên khả năng chạy thành công. SQL vẫn là kỹ năng quan trọng, và công nghệ LLM cần tiếp tục hoàn thiện để hỗ trợ tốt hơn trong bối cảnh phân tích dữ liệu lớn và thời gian thực.
Nếu bạn đang xây dựng các công cụ phân tích sử dụng LLM, hãy cân nhắc kỹ các chiến lược tối ưu, giảm thiểu tử lỗi và nâng cao hiệu quả nhằm đảm bảo trải nghiệm người dùng tốt nhất.
Tham Khảo
- Benchmark Result Validator: result-validator.ts
June 10, 2024
1
100%
Loading...