Model SQL nên hỏi trước khi viết

Model SQL nên hỏi trước khi viết

SQRL đáng chú ý không vì benchmark, mà vì đổi cách nhìn text-to-SQL: model tốt phải biết kiểm tra dữ liệu trước khi tự tin viết query.

Có lần mình thấy một dashboard nội bộ báo doanh thu theo tỉnh nhìn rất sạch: SQL chạy được, biểu đồ lên đẹp, sếp gật gù. Đến lúc finance hỏi vì sao Hà Nội bị tách thành Ha Noi, Hà Nội, HN, cả phòng im như phòng đọc thư viện sau giờ đóng cửa.

Lỗi không nằm ở cú pháp SQL. Lỗi nằm ở chuyện model, hoặc người viết query, tưởng schema đã kể đủ sự thật.

Đó là lý do SQRL của Feyn AI đáng mổ xẻ. Không phải vì thêm một model text-to-SQL mới lên Hugging Face, cũng không chỉ vì Feyn báo SQRL-35B-A3B đạt 70,6% execution accuracy trên BIRD Dev, nhỉnh hơn Claude Opus 4.6 ở mức 68,77% trong cùng đánh giá. Điểm đáng bàn là hướng thiết kế: trước khi viết SQL, model có thể inspect database bằng truy vấn read-only.

Nói gọn: text-to-SQL không còn là bài dịch câu hỏi sang câu lệnh. Nó là bài điều tra dữ liệu trước khi trả lời.

Sơ đồ minh họa cho bài Model SQL nên hỏi trước khi viết

Sơ đồ tóm tắt ý chính của bài viết.

Thứ đang diễn ra: model bắt đầu được quyền nhìn quanh

Text-to-SQL lâu nay hay bị đóng khung thành bài toán dịch thuật: người dùng hỏi bằng tiếng tự nhiên, model trả về SQL. Nghe hợp lý, nhưng builder làm hệ thống BI nội bộ sẽ thấy ngay cái bẫy.

Schema chỉ cho bạn biết có bảng orders, cột province, kiểu dữ liệu text. Nó không nói trong cột đó có Alameda, Alameda County, hay ALAMEDA. Nó cũng không nói join bảng khách hàng với bảng đơn hàng có làm nhân đôi dòng hay không.

Schema giống thẻ mục lục trong thư viện: biết sách nằm khu nào, tên gì, phân loại ra sao. Nhưng nếu muốn chắc trang 57 có đoạn bạn cần, bạn vẫn phải kéo sách khỏi kệ và mở ra xem.

SQRL đi theo logic đó. Nó nhận câu hỏi, schema, và có thể nhận thêm evidence về database. Nếu ngữ cảnh đủ rõ, nó viết query ngay. Nếu còn mơ hồ, nó chạy các truy vấn read-only để xem dữ liệu thật rồi mới tạo SQL cuối.

Đây là một thay đổi nhỏ trên slide, nhưng lớn trong production. Vì nhiều lỗi SQL nguy hiểm nhất không nổ error. Chúng trả kết quả sai một cách rất ngoan.

Mổ xẻ: inspect khác gì prompt dài hơn?

Đừng nhầm inspect database với nhét thêm schema vào prompt.

schema linking — nối câu hỏi với bảng/cột phù hợp — chỉ giải quyết lớp bản đồ. Còn database inspection — kiểm tra dữ liệu thật bằng truy vấn chỉ đọc — giải quyết lớp thực địa.

Ví dụ cụ thể: user hỏi, doanh thu quý này của khách hàng enterprise ở miền Nam là bao nhiêu?

Một hệ text-to-SQL thông thường có thể nhìn schema và đoán:

SELECT SUM(revenue)
FROM orders
WHERE customer_segment = 'enterprise'
  AND region = 'South'
  AND order_date >= '2026-04-01';

Query hợp lệ. Nhưng có thể sai vì:

Nếu model được inspect, nó có thể hỏi database trước:

SELECT DISTINCT customer_segment FROM customers LIMIT 20;
SELECT DISTINCT region FROM orders LIMIT 20;
SELECT column_name FROM information_schema.columns WHERE table_name = 'orders';

Sau đó nó mới quyết định query cuối. Với builder, khác biệt nằm ở quyền được xác minh giả định.

Benchmark BIRD quan trọng vì nó đo execution result, tức chạy SQL và so kết quả trả về với đáp án tham chiếu. Nhưng khi đưa vào hệ thống thật, mình sẽ không chỉ hỏi model đạt bao nhiêu điểm. Mình sẽ hỏi: model có biết lúc nào nên dừng lại để kiểm tra không?

Framework quyết định: khi nào chọn model biết inspect?

Nếu team bạn đang cân nhắc text-to-SQL cho dashboard, analytics bot, hay trợ lý dữ liệu nội bộ, mình sẽ dùng khung 4 câu này trước khi chọn model.

1. Dữ liệu của bạn có nhiều ambiguity không?

Chọn hướng inspect nếu database có nhiều giá trị lộn xộn, tên trường lịch sử, mã nghiệp vụ nội bộ, hoặc nhiều bảng gần nghĩa.

Bỏ qua nếu database nhỏ, naming chuẩn, semantic layer đã được quản lý tốt, và câu hỏi chỉ xoay quanh vài metric cố định.

2. Bạn có cho model quyền read-only an toàn không?

Inspect chỉ hợp lý khi bạn dựng được quyền truy cập chỉ đọc, giới hạn bảng, giới hạn số dòng, timeout, và audit log — nhật ký để biết model đã hỏi database cái gì.

Không có lớp này thì inspect dễ biến thành một nhân viên được thả vào kho lưu trữ mà không có thẻ mượn, không ai biết đã mở tủ nào.

3. Latency có chịu được thêm bước hỏi dữ liệu không?

Một query inspect thêm vài lượt round-trip. Với dashboard tương tác theo giây, đây là tradeoff thật. Với phân tích nội bộ, nơi câu trả lời đúng quan trọng hơn nhanh hơn vài giây, tradeoff này thường đáng cân nhắc.

Đừng chỉ benchmark model. Benchmark cả luồng: user hỏi → model inspect → model viết SQL → query chạy → trả kết quả → log lại.

4. Ai chịu trách nhiệm khi SQL sai?

Nếu câu trả lời dùng cho vận hành nhẹ, bạn có thể cho agent đề xuất SQL rồi con người duyệt. Nếu dùng cho báo cáo tài chính, pricing, hoặc compliance, cần review, test case, và policy rõ ràng.

SQRL mở ra hướng hay, nhưng không miễn trách nhiệm thiết kế guardrail — lớp rào chắn vận hành.

Các release khác đang nói cùng một chuyện

Nhìn rộng hơn, SQRL không đứng một mình. Một loạt release gần đây cho thấy xu hướng chung: model không chỉ sinh chữ, mà được thiết kế để nhìn đúng thứ trước khi hành động.

Mistral OCR 4 không chỉ kéo raw text từ PDF, Word, PowerPoint. Nó còn phân loại block — hiểu phần nào là title, table, equation, signature — và đưa confidence score, tức mức tự tin. Với pipeline RAG, đây là khác biệt lớn: chunk từ một bảng tài chính không nên bị xử như đoạn văn thường.

Nemotron 3 Embed của NVIDIA đi vào tầng retrieval. embedding model — model biến văn bản thành vector để tìm kiếm — quyết định đoạn nào được đưa cho agent đọc. Nếu retrieval sai, model phía sau có giỏi cũng đang đọc nhầm kệ sách. NVIDIA công bố checkpoint 8B đứng đầu RTEB tại thời điểm 17/7/2026, nhưng điểm đáng giữ lại là: tầng tìm kiếm đang được tối ưu như một sản phẩm production, không còn là tiện ích phụ.

Robostral Navigate của Mistral thì ở thế giới robot: model dùng một RGB camera và instruction ngôn ngữ để điều hướng, đạt 76,6% success trên R2R-CE validation unseen theo công bố. Nó không liên quan trực tiếp đến SQL, nhưng cùng logic: hành động tốt hơn khi model gắn với observation — quan sát hiện trường — thay vì chỉ suy luận trong đầu.

Soofi S lại nhắc một chuyện khác: kiến trúc và throughput vẫn là quyết định vận hành. Model 31,6B nhưng chỉ kích hoạt khoảng 3,2B tham số mỗi token cho thấy câu hỏi không chỉ là model to hay nhỏ, mà là chi phí chạy khi context dài và nhiều request song song.

Tóm lại, release ồn ào nhất chưa chắc là lựa chọn đúng. Release đáng quan tâm là release đổi được một quyết định kiến trúc của bạn.

Điều nên giữ, điều nên bỏ qua

Giữ lại: tư duy inspect-before-generate. Với text-to-SQL, hãy coi model như một lớp lập kế hoạch có quyền kiểm tra dữ liệu thật, không phải máy dịch SQL tự động.

Giữ lại: benchmark execution, nhưng đừng thần thánh hóa. BIRD hữu ích vì tạo áp lực lên kết quả thực thi, không chỉ cú pháp. Tuy vậy, dữ liệu công ty bạn có luật nghiệp vụ, dirty values, permission, và latency riêng.

Bỏ qua: cuộc đua model nào thắng model nào nếu bạn chưa có evaluation set nội bộ. Một model hơn vài điểm trên benchmark chưa chắc hiểu được bảng contract_v2_old_backup_final của công ty bạn.

Bỏ qua: ý tưởng cho agent tự query production database ngay ngày đầu. Nếu muốn thử trong một buổi chiều, làm bản sandbox trước:

  1. Chọn 20 câu hỏi analytics hay gặp từ team business.
  2. Tạo database copy đã ẩn dữ liệu nhạy cảm.
  3. Ghi expected answer hoặc SQL chuẩn cho từng câu.
  4. Cho model chạy ở quyền read-only, log toàn bộ inspect query.
  5. Chấm không chỉ đúng/sai, mà cả số lần inspect, latency, và lỗi im lặng.

Sau buổi đó, bạn sẽ biết mình cần model mới, semantic layer tốt hơn, hay chỉ cần dọn lại naming trong database.

Nếu là mình, mình sẽ chọn thế nào?

Nếu team đang build analytics assistant cho dữ liệu thật, nhiều bảng, nhiều thuật ngữ nội bộ, mình sẽ ưu tiên hướng như SQRL: model có khả năng inspect, chạy trong sandbox read-only, có audit log, và có evaluation set riêng.

Nếu use case chỉ là tạo SQL mẫu cho developer, hoặc database đã có metric layer chặt, mình chưa vội đổi. Prompt tốt, schema rõ, và vài template có thể đủ.

Điều mình sẽ nghĩ khác sau khi đọc về SQRL là: model text-to-SQL đáng tin không phải model viết query nhanh nhất, mà là model biết nghi ngờ đúng chỗ trước khi viết.

Trong đời làm dữ liệu, đôi khi người thông minh nhất không phải người trả lời ngay, mà là người chịu đứng dậy đi kiểm tra kệ sách trước khi trích dẫn.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo