- Tính năng Text-to-SQL dựa trên Gemini đang được dùng trên toàn bộ Google Cloud để nâng cao năng suất cho cả nhà phát triển lẫn người dùng không chuyên kỹ thuật
- Trong môi trường thực tế, việc tạo SQL chính xác gặp khó do thiếu ngữ cảnh nghiệp vụ, khó diễn giải ý định người dùng và khác biệt giữa các phương ngữ SQL
- Để giải quyết, Google đã áp dụng các kỹ thuật như truy xuất dữ liệu thông minh, học theo ngữ cảnh và phân tầng ngữ nghĩa
- Giới hạn của chính mô hình được khắc phục bằng các cách như tạo nhiều phương án rồi chọn phương án tối ưu (self-consistency), kiểm tra rồi prompt lại, và huấn luyện theo từng phương ngữ SQL
- Đánh giá và đo lường cải thiện bao gồm benchmark nội bộ và kỹ thuật dùng LLM làm giám khảo, giúp tăng khả năng áp dụng trong môi trường thực tế
Techniques for improving text-to-SQL
Chuyển từ văn bản sang SQL: hiện trạng tại Google Cloud
- Các tổ chức sử dụng SQL để có được insight dữ liệu nhanh chóng và chính xác
- Gemini cung cấp tính năng text-to-SQL để tạo trực tiếp SQL từ ngôn ngữ tự nhiên
- Tính năng này hữu ích không chỉ với nhà phát triển mà còn với cả người dùng không chuyên kỹ thuật
- Hiện tính năng này đã có trong BigQuery Studio, Cloud SQL Studio, AlloyDB Studio, Vertex AI và các sản phẩm khác
Những thách thức chính của công nghệ Text-to-SQL
1. Khó cung cấp ngữ cảnh nghiệp vụ
- Để viết SQL chính xác, cần cung cấp đủ ngữ cảnh cho LLM, chẳng hạn như cấu trúc cơ sở dữ liệu, ý nghĩa của cột và nội dung dữ liệu thực tế
- Ngữ cảnh bao gồm cả thông tin tường minh (schema, thông tin cột, v.v.) lẫn thông tin ngầm định (như ý nghĩa nghiệp vụ của dữ liệu cụ thể)
- Cách liên tục huấn luyện (fine-tuning) LLM để theo kịp cấu trúc cơ sở dữ liệu, biến đổi dataset hay thay đổi schema là không thực tế vì chi phí cao
- Tri thức nghiệp vụ hay thông tin ngữ nghĩa thường không được sắp xếp bài bản, và việc chuyển chúng thành dữ liệu huấn luyện cũng khó khăn
- Ví dụ: nếu DBA không biết
cat_id2 = 'Footwear' trong bảng pcat_extension có ý nghĩa gì thì cũng không thể viết SQL để truy vấn doanh số giày dép — LLM cũng tương tự, nếu thiếu ngữ cảnh thì có nguy cơ tạo ra truy vấn không chính xác
2. Vấn đề diễn giải ý định người dùng
- Truy vấn ngôn ngữ tự nhiên thường thiếu độ rõ ràng so với SQL
- Trong thực tế, nhà phân tích dữ liệu hoặc kỹ sư có thể làm rõ câu hỏi bằng cách hỏi thêm, nhưng LLM có xu hướng tạo câu trả lời ngay từ câu hỏi được đưa vào nên có nguy cơ tạo thông tin sai (hallucination)
- Với câu hỏi như “Loại giày nào bán chạy nhất?”, các tiêu chí chi tiết như ‘bán chạy nhất’ dựa trên số đơn hàng hay doanh thu, và cần trả về bao nhiêu kết quả, đều khá mơ hồ
- Người dùng có năng lực kỹ thuật có thể dùng SQL sơ bộ làm điểm khởi đầu, nhưng với người không chuyên, SQL chạy chính xác mới là điều quan trọng hơn
- Để hoạt động hiệu quả, LLM cần hỗ trợ câu hỏi tiếp theo, giải thích suy luận và hướng dẫn người dùng để nắm rõ ý định của họ
3. Giới hạn trong khả năng sinh của LLM
- LLM mạnh ở các tác vụ như tóm tắt tài liệu, trích xuất thông tin, nhưng lại có điểm yếu với cú pháp SQL chính xác hoặc các tính năng SQL ít phổ biến
- Cú pháp khác nhau giữa các phương ngữ SQL, và ngay cả khác biệt nhỏ cũng đòi hỏi độ chính xác cao
- Ví dụ: trong BigQuery dùng
EXTRACT(MONTH FROM timestamp_column), còn trong MySQL phải dùng MONTH(timestamp_column)
- Việc liên tục tạo SQL tuân thủ đặc tả phức tạp là một thách thức không nhỏ với LLM
Các kỹ thuật Google Cloud dùng để cải thiện Text-to-SQL
Vấn đề: schema và ngữ cảnh nghiệp vụ
- Tìm kiếm và xếp hạng dựa trên ngữ nghĩa
- Học trong ngữ cảnh
- Lấy mẫu và liên kết dữ liệu
- Xây dựng tầng ngữ nghĩa
- Phân tích mẫu sử dụng và lịch sử
Vấn đề: diễn giải ý định người dùng
- Làm rõ bằng LLM
- Nhận diện thực thể, kiểm tra thông tin liên quan rồi dẫn dắt bằng câu hỏi tiếp theo phù hợp
Vấn đề: vượt qua giới hạn của LLM
- Dùng self-consistency để tạo nhiều truy vấn rồi chọn truy vấn tốt nhất
- Kiểm tra tính hợp lệ và re-prompt
- Học theo ngữ cảnh với các ví dụ theo từng phương ngữ SQL
- Fine-tuning mô hình
Ví dụ áp dụng các kỹ thuật chính
Mô hình hiểu SQL
- Gemini sử dụng nhiều phiên bản fine-tuning khác nhau để tạo SQL chất lượng cao
- Để đảm bảo độ chính xác theo từng phương ngữ SQL, Google thực hiện phối hợp nhiều phiên bản mô hình và tinh chỉnh tùy biến
Làm rõ câu hỏi người dùng (Disambiguation)
- Khi câu hỏi mơ hồ, hệ thống sẽ tạo câu hỏi làm rõ
- Ví dụ: "Giày bán chạy nhất?" → “Theo số đơn hàng hay theo doanh thu?”
Tìm kiếm ngữ nghĩa và xây dựng ngữ cảnh
- Dùng tìm kiếm vector dựa trên đối sánh ngữ nghĩa nhiều tầng để xác định bảng và cột liên quan
- Prompt được xây dựng có tính đến lịch sử truy vấn của người dùng, ví dụ về quy tắc nghiệp vụ, v.v.
- Hỗ trợ cửa sổ ngữ cảnh dài giúp xử lý schema quy mô lớn
Kiểm tra và sinh lại
- Dùng parsing, dry-run và các cách khác để phát hiện lỗi tường minh trong truy vấn do LLM sinh ra
- Khi phát hiện lỗi, hệ thống sẽ prompt lại để hướng dẫn sửa
Self-consistency
- Thay vì chỉ một truy vấn, hệ thống sinh nhiều truy vấn theo các cách khác nhau
- Nếu nhiều mô hình cùng đề xuất một truy vấn giống nhau thì độ chính xác sẽ tăng
Đánh giá và đo lường hiệu năng
- Các benchmark hiện có (như BIRD-bench) hữu ích, nhưng vẫn có giới hạn trong việc phản ánh schema thực tế
- Google đã xây dựng một bộ benchmark tổng hợp nội bộ
Chiến lược đánh giá
- Bao quát phương ngữ SQL và tính năng theo từng engine: không chỉ truy vấn mà còn gồm DDL, DML và cả tác vụ quản trị
- Chỉ số đánh giá: phản hồi từ người dùng, chỉ số offline, LLM-as-a-judge
- Đánh giá liên tục: cho phép nhanh chóng xác minh hiệu quả của mô hình mới và kỹ thuật prompt mới
Kết luận
1 bình luận
Ý kiến trên Hacker News
Có suy nghĩ về mục tiêu cuối cùng của việc chuyển từ văn bản sang SQL: là tạo ra trợ lý cho nhà phân tích dữ liệu, hay là nhằm lấy insight kinh doanh mà không cần qua nhà phân tích. Nếu là mục tiêu thứ hai, thì dù có tinh vi đến đâu, người không chuyên cũng không thể đánh giá được độ chính xác và tính đầy đủ của SQL. Những câu hỏi như “Tại sao giao dịch thương mại điện tử hôm qua chỉ đạt 80%?”, “Tại sao chi phí thu hút khách hàng lại tăng?”, “Tại sao chiến dịch ở New York hoạt động kém hơn so với San Francisco?” đều là những câu hỏi vượt ra ngoài phạm vi của text2sql
Thực tế thì có vẻ gần với mục tiêu thứ hai hơn, nhưng kết quả vẫn chưa đáp ứng kỳ vọng. Trong kinh doanh, người ta thường muốn thay đổi báo cáo vào phút chót nhưng lại không có đủ nhà phân tích để nhận được thông tin mong muốn đúng lúc. Họ cố giải quyết bằng “tốc độ vô hạn”, nhưng vấn đề thật ra nằm ở chỗ chưa suy nghĩ đủ kỹ về metric. Dữ liệu phức tạp, tri thức kinh doanh được lưu trữ ngầm ở bên ngoài, và hạ tầng dữ liệu còn yếu nên việc phân tích mất nhiều thời gian. Những lãnh đạo phân tích thông minh đang tận dụng làn sóng AI để đầu tư vào hạ tầng nền tảng
Tôi cho rằng ngay từ đầu những câu hỏi trên vốn không phải loại vấn đề có thể giải bằng SQL. SQL chủ yếu trả lời câu hỏi “cái gì (what)”, chứ không trả lời “tại sao (why)”. Mục tiêu của text2sql là rút ngắn thời gian để nhà phân tích xử lý phần “cái gì” nhanh hơn, từ đó tập trung vào “tại sao” nhiều hơn
Điều đó đúng, nhưng theo tôi văn bản ngôn ngữ tự nhiên có thể trở thành đầu vào phổ quát cho các hệ thống LLM. text2sql có thể đóng vai trò là nền tảng truy xuất thông tin để cấu thành câu trả lời cho những câu hỏi phức tạp hơn. Trong ngắn hạn đó là tính năng hỗ trợ công việc, nhưng về dài hạn mục tiêu là xây nền cho tự động hóa, so sánh kết quả, và tích hợp vào các workflow lớn hơn. Mấu chốt là tạo ra nền tảng để trả lời được những câu hỏi kiểu này. Vẫn còn rất nhiều việc phải làm
Bất kỳ thuật toán nào mà con người có thể làm thì đều có thể xây dựng và kiểm thử được. Nếu có 10 nhà phân tích, thì mức độ hiểu biết về cơ sở dữ liệu, về kinh doanh, và năng lực của họ đều khác nhau. Tự động hóa mang lại một tiêu chuẩn bảo đảm mức năng lực và kiến thức tối thiểu. Ngay cả nhà phân tích mới cũng có thể đạt hiệu quả tốt hơn ngay lập tức. Phát triển hệ thống cùng với chuyên gia, kiểm thử nó, và để AI diễn giải các trade-off, bug, cũng như so sánh với kết quả kỳ vọng là một mục tiêu hữu ích. Insight hay “gu” thì khó tự động hóa, nhưng nếu chuyên gia lĩnh vực có hệ thống tự động hóa được thiết kế tốt và có cảm nhận về kết quả hợp lý, thì có thể đi rất xa. Không hoàn hảo, nhưng đó là mục tiêu của tôi
Chia sẻ trải nghiệm dùng mô hình OpenAI 4o: tôi đưa cả hướng dẫn nghiệp vụ, thuật ngữ ngành, mô tả bảng và foreign key vào prompt. Khi đó nó có thể tạo cả những truy vấn join phức tạp và trả về kết quả. Mục tiêu là cung cấp kết quả cho người dùng không biết SQL, nhưng tôi cũng hiển thị luôn cả SQL để tham khảo
AI không nhất thiết phải tạo ra SQL hoàn hảo. Trong trường hợp của tôi, dù đầu ra có thể được kiểm chứng bằng code, tôi vẫn không copy dùng luôn vì rủi ro sai lệch ngữ nghĩa rất nhỏ. Thay vào đó, AI gợi ý cách tiếp cận, rồi tôi dựa vào đó tự viết lại SQL từ đầu
Chia sẻ trải nghiệm dùng Gemini mới nhất trong Google AI Studio: thực sự ấn tượng và mang tính đột phá đến mức khó tin. Kết quả code từ Claude và ChatGPT có cảm giác như đến từ một thế kỷ khác. Mới chỉ một tháng trước tôi còn thấy Claude rất xuất sắc, nhưng giờ thì không biết làm sao có thể tiếp tục code mà không có Google Gemini. Gemini AI Studio là một bước nhảy vọt lớn cho lập trình
Tôi ngạc nhiên vì vẫn còn nhiều người chưa nhận ra sự thay đổi này. Claude vẫn xử lý tốt các tác vụ nhỏ, nhưng khi phát triển thành vấn đề phức tạp thì Gemini vượt trội hẳn. Khả năng xử lý ngữ cảnh đặc biệt ấn tượng. Tôi không chỉ dùng nó như coding agent mà còn dùng Gemini để beta reading cho một bản thảo 85.000 từ, và nhận được báo cáo phản hồi gần như theo thời gian thực ở cấp độ chuyên gia
Tuần này tôi có cảm giác họ đã tắt reasoning mode trên Gemini Pro miễn phí. Nếu ngăn nó dừng lại ngay trước khi viết code hoặc đừng để nó khái quát hóa quá mức thì nó khá hữu ích. Tuy vậy Gemini có xu hướng viết code quá đà. Cách tôi chủ yếu sử dụng là không bị mắc kẹt vào chuyện triển khai code, mà dùng Gemini để khám phá thiết kế. Ví dụ như khi xây dịch vụ thuê bao với Stripe, tôi có thể nhận được dữ liệu hiện có phù hợp với stack kỹ thuật và tình huống của mình theo đúng ngữ cảnh, và thay đổi hướng thiết kế trước cả khi viết một dòng code nào
Câu trả lời là “dùng semantic layer”. Đây là cách hiệu quả nhất để truyền đúng ngữ cảnh và cũng là điểm tối ưu để con người can thiệp trực tiếp. Nếu con người định nghĩa rõ mọi chỉ số cốt lõi, thì LLM có thể dùng chúng bất kỳ lúc nào. Ví dụ, nếu đã định nghĩa MAU thì LLM sẽ tạo truy vấn dựa trên định nghĩa đó. Nếu viết truy vấn bằng JSON thay vì SQL thì LLM cho kết quả nhất quán hơn nhiều. Chúng tôi dùng cube, đây là semantic layer mã nguồn mở tốt nhất. Ngoài ra còn có các lựa chọn mã nguồn đóng từ Naver. Trước đây công ty tôi từng viết blog liên quan, nhưng hiện chủ sở hữu đã ngừng host
Dùng AI để tạo SQL trong công việc thực tế thì rất rủi ro. Người không biết SQL có thể viết truy vấn sai và gây ảnh hưởng nghiêm trọng đến server. Cơ sở dữ liệu của nhóm tôi xét theo tiêu chuẩn của phần lớn developer thì là lớn, nhưng không phải cực kỳ khổng lồ. Thỉnh thoảng tôi có nhờ AI tối ưu thêm một truy vấn vốn đã được tối ưu, nhưng chưa bao giờ AI đưa ra đáp án tốt hơn. Có lúc AI nói linh tinh hoặc đưa ra những gợi ý thực tế vô dụng. Cảm giác như một con vẹt ngốc nghếch đang lặp lại chuyện nó từng nghe đâu đó
Tôi nghĩ nếu có tính năng AI chuyển văn bản sang biểu thức chính quy thì sẽ cực kỳ tiện
Trong tất cả công cụ AI tôi từng dùng, thứ gây thất vọng nhất là Gemini tích hợp trong BigQuery. Tên cột đã rất rõ ràng, mô tả cũng được viết tốt, vậy mà nó vẫn không hề tiến gần đến việc giải được vấn đề
Ngôn ngữ mà tôi đã viết truy vấn nhiều nhất từ trước đến nay là SQL. Mỗi khi nhờ AI viết truy vấn, tôi lại mất nhiều thời gian chỉnh sửa kết quả hơn là tự viết từ đầu. Nhân tiện, tôi ước có một tính năng giúp viết SQL nhanh hơn nhiều. DSL của công ty tôi có toán tử tự động join theo foreign key nên cực kỳ tiện. Phiền nhất khi viết SQL là phải tự tay viết 10, 20 hoặc hơn các câu join; những phần khác thì không khó bằng
Theo kinh nghiệm của tôi, nếu có ràng buộc rõ ràng và foreign key được thiết lập tốt thì gần như mọi thứ đều được giải quyết. Mỗi bảng cần có ràng buộc rõ ràng để AI có thể hiểu chính xác toàn bộ cấu trúc liên kết. SQL có một đặc tả rất chính xác, nhưng chính vì vậy nếu constraint và foreign key không được định nghĩa tốt thì AI không thể đưa ra câu trả lời chính xác
Với mọi foundation model thì việc này giờ đã khá đơn giản. Chỉ cần schema bảng có comment đầy đủ là yêu cầu tạo truy vấn đã trở nên dễ dàng
Nếu dựng scaffolding quanh model bằng thư viện smolagents thì khá tiện. Cũng có bài viết nói rằng text2sql nhìn đơn giản khi demo, nhưng để áp dụng vào các trường hợp thực tế phức tạp thì rất khó
Bước 1: schema có hàng nghìn bảng và gần như không có chú thích. Bước 2...
Tôi thực sự nghĩ đúng là như vậy. Giờ đây không còn mấy yếu tố ma thuật nữa. DDL tạo bảng thực chất gần như đã là mô tả chính xác của bảng, nên thật ra không cần thêm nhiều. Chỉ cần mô tả chi tiết truy vấn cần lấy là hầu hết LLM đều có thể dễ dàng sinh truy vấn
Trong bài viết "Show HN: We open sourced our entire text-to-SQL product" (2024), có nhắc tới những tài liệu tham khảo rất tốt như awesome-Text2SQL và Awesome-code-llm > Benchmarks > Text to SQL