Thế giới cơ sở dữ liệu tìm cách xây dựng hệ thống truy vấn ngôn ngữ tự nhiên một lần nữa – với sự trợ giúp của LLM

Trong vài năm qua, các nhà cung cấp giải pháp cơ sở dữ liệu và phân tích đã đổ xó tham gia vào một xu hướng có thể đưa chúng ta đến đích mà ở đó các truy vấn dữ liệu phổ thông không còn bị ràng buộc bởi ngôn ngữ truy vấn chuyên ngành SQL.

Ví dụ, vào đầu tháng này, AWS đã hứa hẹn cung cấp "một giải pháp chuyển đổi văn bản tự nhiên sang SQL... biến các câu hỏi kinh doanh thành truy vấn cơ sở dữ liệu và trả về câu trả lời có thể hành động".

Tuy nhiên, giáo sư Nick Koudas thuộc Khoa Khoa học Máy tính tại Đại học Toronto, người đang nghiên cứu các hệ thống SQL ngôn ngữ tự nhiên, đã cảnh báo rằng mặc dù các công cụ Text-to-SQL có thể giúp các nhà phát triển cơ sở dữ liệu — những người đã biết SQL — tiết kiệm thời gian, các tổ chức nên thận trọng trước khi để người dùng kinh doanh tự do sử dụng các công cụ này.

Rào cản giữa ngôn ngữ tự nhiên và kỹ thuật

Vấn đề cốt lõi, theo ông Koudas, là đối với một người dùng kinh doanh thông thường, hệ thống có thể tạo ra các truy vấn có cú pháp đúng nhưng lại không phản ánh đúng ý định truy vấn thực sự của họ.

Ông Donald Chamberlin, đồng tác giả của ngôn ngữ SQL, từng chia sẻ vào năm 2024 rằng SQL ban đầu được thiết kế để gần gũi với ngôn ngữ tự nhiên nhất có thể. Tuy nhiên, do những hạn chế và tính mơ hồ của tiếng Anh, đã phải có sự thỏa hiệp nhất định trong việc tạo ra ngôn ngữ dữ liệu phổ biến hầu như ubiquitous mà chúng ta thấy ngày nay.

Do số lượng người có kỹ năng SQL bị hạn chế, các nhà cung cấp đã bước vào để lấp đầy khoảng trống này, giả định rằng các Mô hình Ngôn ngữ Lớn (LLM) sẽ là một cách tốt để xây dựng hệ thống dữ liệu ngôn ngữ tự nhiên.

AWS, ví dụ, đã mô tả cách người dùng có thể phát triển một khái niệm chứng minh (proof of concept) Text-to-SQL bằng nền tảng Bedrock của mình để xây dựng các ứng dụng và tác nhân AI tạo sinh.

"Nhiều tổ chức nhận thấy rằng việc tiếp cận thông tin chi tiết từ dữ liệu vẫn là một nút thắt lớn trong quy trình ra quyết định kinh doanh. Phương pháp tiếp cận truyền thống đòi hỏi phải học cú pháp SQL, chờ đợi tài nguyên kỹ thuật, hoặc chấp nhận các bảng điều khiển (dashboard) được xây dựng sẵn có thể không trả lời các câu hỏi cụ thể của bạn", đại diện AWS cho biết.

Các ông lớn công nghệ tham gia cuộc đua

AWS không đơn độc trong tham vọng này. Quay lại năm 2024, nhà cung cấp nền tảng dữ liệu đám mây Snowflake đã xây dựng một dịch vụ mới mà họ tuyên bố sẽ giúp các tổ chức xây dựng các chatbot có thể phục vụ dữ liệu từ hệ thống phân tích của chính họ và các hệ thống bên ngoài nền tảng đám mây. Cách tiếp cận này sử dụng dịch vụ AI do nhà cung cấp quản lý là Cortex.

Công ty sau đó đã giới thiệu Cortex Analyst, đưa vào một mô hình ngữ nghĩa "kết nối các thuật ngữ kinh doanh với lược đồ cơ sở dữ liệu". Theo Snowflake, công cụ này "hướng dẫn LLM xây dựng các truy vấn SQL chính xác hơn bằng cách bao gồm các yếu tố phù hợp, chẳng hạn như các phép nối (joins) và bộ lọc (filters)".

Thậm chí cả MongoDB — một hệ thống cơ sở dữ liệu NoSQL dạng tài liệu — cũng có API truy vấn MongoDB từ văn bản riêng, được xây dựng trên khuôn khổ phần mềm LangChain.

Ngành công nghệ kỹ thuật cũng đã sản xuất các tài nguyên để giúp các nhà phát triển quyết định công cụ nào có thể hỗ trợ trong việc xây dựng hệ thống Text-to-SQL. Tiêu chuẩn BIRD-SQL, ví dụ, tuyên bố cung cấp một tập dữ liệu đa lĩnh vực để kiểm tra tác động của nội dung cơ sở dữ liệu mở rộng đối với việc phân tích Text-to-SQL. Người dẫn đầu hiện tại là một nghiên cứu sử dụng AskData và GPT-4o của OpenAI, với độ chính xác thực thi gần 82%, so với hiệu suất của chuyên gia con người khoảng 93%.

Cảnh báo về sự phụ thuộc quá mức

Mặc dù vậy, ông Koudas cảnh báo về việc phụ thuộc quá mức vào các hệ thống này.

"SQL đã là ngôn ngữ của cơ sở dữ liệu hơn 50 năm qua. Mọi người đã hình dung, thậm chí trước cả LLM, về việc cố gắng làm cho nó dễ tiếp cận hơn bằng cách về cơ bản dịch ngôn ngữ tự nhiên sang SQL. Về mặt nghiên cứu thuần túy, mọi người đã cố gắng làm điều đó và cho thấy nó khó khăn như thế nào. Bây giờ với LLM, nhờ sự hiểu biết ngữ nghĩa sâu sắc của việc huấn luyện trước (pre-training), có sự phát triển nhanh chóng", ông nói.

Ông giải thích rằng cách tiếp cận này thường diễn ra trong hai bước. Đầu tiên là cố gắng ánh xạ ngôn ngữ tự nhiên với lược đồ của cơ sở dữ liệu, để hiểu các bảng và thuộc tính nào liên quan đến một truy vấn. Giai đoạn thứ hai là tạo ra SQL.

"Hầu như mọi nhà cung cấp cơ sở dữ liệu đã triển khai chức năng này dưới một hình thức nào đó. Nếu bạn đến các công ty như Snowflake hoặc Databricks, họ có một số loại giao diện Text-to-SQL nơi mọi người chỉ có thể sử dụng ngôn ngữ tự nhiên để nhận truy vấn SQL", ông Koudas nhận định.

Giới hạn độ chính xác hiện tại khoảng 80% khi sử dụng ngay lập tức (out-of-the-box) xuất phát từ thực tế là hầu hết các tổ chức sử dụng hệ thống với các tập dữ liệu độc quyền và các lược đồ độc quyền có thuật ngữ cụ thể được sử dụng bên trong công ty. Nếu không có thêm huấn luyện, LLM không có quyền truy cập vào các định nghĩa này.

Vai trò của con người trong vòng lặp

Tuy nhiên, các công cụ này vẫn có thể tiết kiệm thời gian cho các nhà phát triển và quản trị cơ sở dữ liệu, vì họ có kỹ năng để kiểm tra SQL do LLM tạo ra và xác minh nó.

"Hãy coi nó như một tiện ích cho nhà phát triển cơ sở dữ liệu biết SQL và có khả năng đánh giá xem truy vấn được trả về từ LLM có đúng không, và nếu có lỗi, họ sẽ sửa chữa nó", ông Koudas gợi ý.

Nhưng sử dụng các hệ thống Text-to-SQL mà không có người hiểu SQL trong vòng lặp có thể rủi ro. Mặc dù một truy vấn tạo ra SQL sai cú pháp có thể vô hại — nó đơn giản là sẽ không chạy được.

"Có luôn luôn khả năng LLM, sau vài lần thử, tạo ra một truy vấn SQL thực sự hoàn toàn đúng về cú pháp nhưng sai về mặt ngữ nghĩa. Nếu bạn tin tưởng nó và nhận lại một cái gì đó không có bất kỳ liên kết nào với [truy vấn], thì bạn có một vấn đề lớn, và tôi nghĩ mọi người hiểu điều đó", ông cảnh báo.

Để cải thiện mức độ chính xác, hoặc ít nhất là giảm thiểu rủi ro khi sử dụng các hệ thống này, nghiên cứu hiện tập trung vào việc đưa con người trở lại vòng lặp, nhưng thay vì là một chuyên gia SQL, đó là người dùng mà từ đó LLM có thể tìm kiếm sự làm rõ thêm.

"Ngôn ngữ tự nhiên là mơ hồ và có nhiều sắc thái. Vì vậy, khi LLM lấy ngôn ngữ tự nhiên và bắt đầu tạo ra SQL, bạn xây dựng một cơ chế bên trong suy luận (inference) của LLM — trong khi tạo ra truy vấn SQL của bạn — hiểu rằng token tiếp theo nó tạo ra sẽ tạo ra sự không chắc chắn cực độ. Vì nó nắm bắt được sự không chắc chắn của chính mình và do ánh xạ lược đồ, khi bạn có một token không chắc chắn, nó có thể lấy token đó, tiếp tục phân tích lược đồ và hỏi lại người dùng bằng ngôn ngữ tự nhiên. Nếu nó không chắc chắn, nó sẽ nói: 'Bạn có ý này hay ý kia trong câu hỏi của mình? hay thuộc tính này có phải là một phần của câu trả lời của bạn?'".

"Với sự cộng hưởng giữa con người và LLM, con người có thể giúp LLM hoàn thành công việc một cách chính xác", ông kết luận.

Nhưng vào thời điểm hiện tại, hầu hết các trường hợp sử dụng Text-to-SQL tương tự như sử dụng LLM để phát triển phần mềm: chúng là công cụ để tăng năng suất chứ không phải thay thế các nhà phát triển, theo ông Koudas.

Mặc dù có lợi ích của các hệ thống LLM Text-to-SQL, cuộc tìm kiếm kéo dài 50 năm để có một cách hoàn toàn tự nhiên để truy vấn và quản lý dữ liệu vẫn chưa kết thúc.