NaturalSQL-7B - mô hình mạnh mẽ chuyển đổi ngôn ngữ tự nhiên thành SQL

• Đạt 76.5% trên SQL-Eval, cho thấy hiệu năng tốt nhất trong cùng quy mô mô hình
  • Dù chưa bằng GPT-4(83%), nhưng vượt GPT-3.5-Turbo(65%) / Claude-2(64.5%)
  • Cao hơn sqlcoder-7b(71%) và gần tương đương sqlcoder-15b(78%)
• ChatDB, một công cụ giúp tạo dashboard no-code mà không cần viết SQL, đã được phát triển

Ví dụ

• Câu hỏi: Xác định khách hàng có tổng giá trị đơn hàng lớn nhất trong tháng trước, và liệt kê tất cả sản phẩm cùng số lượng mà họ đã đặt.
• Đầu ra:

  WITH LastMonthOrders AS (  
    SELECT o.customerid, o.orderid, op.productid, op.quantity, p.productname, op.quantity * p.unitprice AS total_order_value  
    FROM orders o  
    JOIN order_details op ON o.orderid = op.orderid  
    JOIN products p ON op.productid = p.productid  
    WHERE o.orderdate >= date_trunc('month', CURRENT_DATE) - INTERVAL '1 month'  
    AND o.orderdate < date_trunc('month', CURRENT_DATE)  
  ),  
  CustomerTotalOrderValue AS (  
    SELECT customerid, SUM(total_order_value) AS total_value  
    FROM LastMonthOrders  
    GROUP BY customerid  
    ORDER BY total_value DESC  
    LIMIT 1  
  )  
  SELECT c.customerid, c.companyname, lm.productid, lm.productname, lm.quantity  
  FROM CustomerTotalOrderValue ctov  
  JOIN LastMonthOrders lm ON ctov.customerid = lm.customerid  
  JOIN customers c ON c.customerid = lm.customerid;  
  

• NaturalQuery xử lý rất tốt các câu hỏi phức tạp như trên, subquery và tỷ lệ.

[xguru]

Ý kiến trên Hacker News

• Điểm hiệu năng trên SQL-Eval là 76,5%, hơi kém hơn GPT-4 với 83% và sqlcoder-15b với 78%.

  • Những lĩnh vực ứng dụng nào có thể hữu ích cho kiểu thực tập sinh khoa học dữ liệu AI này? Có thể xây dựng gì với một AI có độ chính xác 75%?
  • Với tư cách là một lập trình viên thường xuyên phải tra cứu tài liệu khi làm việc với SQL, có vẻ có thể dùng AI kiểu này để viết bản nháp truy vấn đầu tiên.
  • Các mô hình lớn có thể cho kết quả tốt hơn trong từng trường hợp đơn lẻ, nhưng vẫn có thể dễ dàng chạy mô hình 15b trên máy m1 64GB.
  • Trong môi trường doanh nghiệp, đôi khi không muốn làm lộ thông tin schema vào dữ liệu huấn luyện của OpenAI và cũng muốn chạy truy vấn ngoại tuyến.
  • Khi muốn thực hiện nhiều truy vấn, một mô hình nhỏ và chạy cục bộ sẽ hữu ích hơn về mặt chi phí.
  • Một "nhà khoa học dữ liệu mini" để cả người không có nền tảng kỹ thuật cũng có thể đặt truy vấn thì sẽ rất tuyệt, nhưng tôi tự hỏi làm sao để biết truy vấn đó có rơi vào 25% trường hợp “không chính xác” hay không.
  • Có lẽ có thể tăng tỷ lệ thành công tổng thể bằng một thuật toán đồng thuận kiểu RAID, nơi nhiều AI kiểm chứng câu trả lời của nhau.
  • Phần lớn đây chỉ là quá trình sắp xếp suy nghĩ của tôi, nhưng có thể người khác sẽ có thêm ý tưởng. Chúc mừng OP ra mắt sản phẩm!

• Tôi nghĩ các mô hình text-to-SQL không thực sự giải đúng vấn đề.

  • Phần khó không phải là không biết cú pháp hay không biết viết truy vấn group by, mà là hiểu ý nghĩa của dữ liệu.
  • Nhìn vào một bảng 50 cột trong Snowflake, không thể đoán nó là gì chỉ từ tên cột.
  • Ví dụ, khi một bảng có 10 cột đều được đặt tên kiểu ...price, bạn phải tìm wiki hoặc đọc định nghĩa DBT mới biết ý nghĩa thực sự của chúng.
  • Không thể tin tưởng truy vấn do mô hình tạo ra; mô hình chỉ hiểu cú pháp truy vấn chứ không hiểu dữ liệu.

• Có người chỉ ra rằng đây không phải mã nguồn mở; do có các hạn chế dựa trên cách sử dụng nên có lẽ nên gọi là “source available”.

• Đây là một lĩnh vực thú vị và đúng chỗ tôi quan tâm, nhưng tôi không nghĩ đó là một câu hỏi phức tạp, mà chỉ là một câu hỏi phân tích cơ bản.

  • Phần lớn các analyst có thể viết mấy thứ này ngay cả khi đang ngủ.
  • Tôi đã thử dùng ChatGPT để viết SQL và thấy khá bình thường, nhưng chắc chắn nó sẽ còn cải thiện.

• Cũng như nhiều ứng dụng AI khác, nó rất tốt khi dùng làm "hạt giống" ban đầu, đặc biệt khi gợi ý những ý tưởng như nhóm theo phạm vi.

  • Tuy nhiên, trong hầu hết mọi cơ sở dữ liệu, vấn đề nằm ở chi tiết.
  • Các sản phẩm khác nhau diễn giải “số lượng” theo những cách khác nhau, ví dụ hộp so với đơn vị; coupon và discount được mô hình hóa theo kiểu kỳ quặc; trọng lượng thì lúc giả định là pound, lúc là kilogram và còn bị trộn lẫn mà không ghi đơn vị, v.v.

• Những người nói rằng vì nó chỉ chính xác 75% nên vô dụng cần cân nhắc hai điều sau:

  • Đây là phiên bản đầu tiên, mà đã hữu ích với product owner và analyst gấp nghìn lần bất kỳ Airtable nào bạn có thể tưởng tượng.
  • Ai cũng muốn mọi thứ phải chính xác trước mọi thách thức, nhưng chúng ta vốn đã sống trong một nền kinh tế “đủ tốt”, và nếu cái này đủ gần thì có lẽ đã đủ tốt cho doanh nghiệp.

• Tôi tò mò không biết nó hoạt động thế nào trên Bird, một benchmark phức tạp và thực tế hơn.

• Dựa trên kinh nghiệm làm việc trong lĩnh vực dữ liệu, nhiều người nhận câu hỏi từ cấp quản lý, phải hiểu đủ rõ data warehouse để viết SQL trả lời câu hỏi đó, và đôi khi còn phải trình bày câu trả lời theo cách đẹp mắt.

  • Đôi khi cũng phải đoán trước các câu hỏi tiếp theo từ quản lý như “tại sao con số này thấp thế? Chắc không thể thấp đến vậy được”, rồi nhờ data engineer kiểm tra lỗi.
  • Giống như mọi LLM khác, tôi không chắc điều này sẽ khiến trách nhiệm đó trở nên dễ hơn rất nhiều hay sẽ xóa bỏ hoàn toàn nó.

• Thật sự rất hay, dù giấy phép không phải loại tiêu chuẩn nhưng trông vẫn giống mã nguồn mở.

  • Có thể tìm mô hình thực tế ở đây: NaturalSQL-6.7B-v0
  • Đây có vẻ là một base model tuyệt vời, nhưng tôi tự hỏi text-to-sql có phải là trường hợp sử dụng tốt cho các mô hình nhỏ hay không.
  • Chúng tôi cũng đang phát triển công cụ trong lĩnh vực này và muốn dùng gpt-4 với hy vọng nó hiểu câu trả lời tốt hơn. Ngay cả gpt 3.5 cũng chưa đủ để đưa vào production.

• Rất hay, tôi tự hỏi giấy phép này có thể dùng cùng với Vanna hay không.