Định tuyến truy vấn thông minh cho Trợ lý SQL AI: Cách cắt giảm chi phí mà không ảnh hưởng đến chất lượng

Hãy tưởng tượng trợ lý SQL của bạn là một tên lửa, xuyên qua các truy vấn phức tạp. Sau đó, một ngày nào đó bạn nhận ra rằng bạn đang sử dụng nhiên liệu tên lửa để lấy một danh sách mua sắm.

Nó thú vị, cho đến khi hóa đơn nhiên liệu đến. Bỗng nhiên, nó trở nên rõ ràng rằng những việc đơn giản không cần một tên lửa. Điều tương tự xảy ra khi mọi yêu cầu SQL, từ một truy vấn cơ bản đến phân tích nhiều lược đồ, đều được định tuyến đến cùng một mô hình AI mạnh mẽ.

Quá trình nhận trợ lý SQL AI thường giống nhau. Ban đầu, năng suất tăng lên: các truy vấn được thực hiện nhanh hơn, mã lặp đi đi, và các nhà phát triển dành ít thời gian hơn để viết các truy vấn SQL định kỳ. Khi nhiều đội sử dụng nó, số lượng truy vấn tăng lên. Khi hóa đơn cơ sở hạ tầng đến, nền kinh tế thay đổi.

Vấn đề nằm ở việc xây dựng. Chi phí để chạy các mô hình AI Frontier có thể suy nghĩ về kế hoạch thực hiện, lược đồ và logic truy vấn phức tạp là rất lớn. Giá đó có ý nghĩa đối với các nhiệm vụ khó khăn, vì nó chi phí khoảng 0,03 đô la mỗi truy vấn. Khi sử dụng cho các câu lệnh SELECT đơn giản và các hoạt động CRUD, nó trở thành lãng phí ở quy mô lớn.

Nhưng câu trả lời không phải là giảm mô hình. Đó là gửi các truy vấn đến đúng nơi. Định tuyến truy vấn thông minh sắp xếp từng yêu cầu theo mức độ khó khăn và gửi nó đến tầng mô hình phù hợp. Phương pháp này có thể cắt giảm chi phí suy luận bằng 40-70% trong các khối lượng công việc SQL mà không giảm chất lượng đầu ra.

Bài viết này giải thích cách kiến trúc đó hoạt động: định nghĩa các tầng phức tạp SQL, xây dựng các đường ống phân loại và định tuyến, và đo lường các giao dịch chi phí-chất lượng thực sự khi hệ thống đang chạy. Những mẫu này phản ánh các bài học rút ra trong khi phát triển các khả năng AI nhận thức lược đồ trong dbForge AI Assistant.

Tại sao một mô hình không phù hợp với tất cả các nhiệm vụ SQL

Không tất cả các truy vấn SQL đều giống nhau về mức độ phức tạp. Một truy vấn lấy người dùng theo khóa chính và một truy vấn xây dựng lại các kênh phiên trên nhiều lược đồ với các hàm cửa sổ là cả hai SQL, nhưng lý luận cần thiết để tạo ra chúng rất khác nhau.

Nếu một hệ thống đối xử với chúng giống nhau, kết quả là có thể dự đoán: lãng phí tính toán. Trong hầu hết các khối lượng công việc doanh nghiệp, khoảng hơn một nửa số truy vấn là định kỳ. Các tìm kiếm đơn giản, đọc bảng đơn, chèn cơ bản, sửa lỗi cú pháp. Không có gì phức tạp. Gửi tất cả những truy vấn đó đến một mô hình Frontier là như sử dụng thang máy hàng hóa để mang một cuốn sổ tay.

Một cách để suy nghĩ về vấn đề này là chia các truy vấn thành các tầng phức tạp:

Khoảng cách chi phí giữa các tầng là rất lớn. Một truy vấn Tầng 1 có thể có chi phí khoảng 0,001 đô la trên một mô hình nhẹ. Cùng một truy vấn được gửi đến một mô hình Frontier có thể có chi phí gần 0,03 đô la. Ở 10.000 truy vấn mỗi ngày, đó là 10 đô la so với 300 đô la chi phí hàng ngày. Một sự khác biệt 30 lần, chỉ từ các quyết định định tuyến.

Nhận thức lược đồ cũng quan trọng ở đây. Các truy vấn Tầng 3 không chỉ cần nhiều tính toán hơn. Chúng cần ngữ cảnh: mối quan hệ giữa các bảng, khóa ngoại, chỉ mục, cú pháp cụ thể của cơ sở dữ liệu. Ngữ cảnh đó phải được tiêm vào trong quá trình suy luận.

Chạy một truy vấn Tầng 1 đơn giản qua cùng một đường dẫn nặng lãng phí token, thêm độ trễ và không cải thiện kết quả.

Một kiến trúc thực tế cho việc chọn mô hình

Một hệ thống định tuyến thường có bốn giai đoạn: phân loại, định tuyến, thực hiện và xác thực. Mỗi giai đoạn thực hiện một công việc khác nhau và mỗi giai đoạn có thể thất bại theo các cách khác nhau. Nó giúp suy nghĩ về chúng một cách riêng biệt trước khi đưa toàn bộ đường ống lại với nhau.

Phân loại là bước quan trọng nhất. Bộ phân loại nhận truy vấn SQL thô hoặc lời nhắc ngôn ngữ tự nhiên sẽ tạo ra truy vấn đó và gán nó vào một tầng phức tạp. Có ba cách phổ biến để xây dựng bộ phân loại này.

Phân loại dựa trên quy tắc dựa trên các mẫu regex và phân tích cây cú pháp trừu tượng (AST) để phát hiện các tín hiệu cấu trúc: những thứ như số bảng, độ sâu lồng, hàm cửa sổ, truy vấn con hoặc toán tử tổng hợp. Cách tiếp cận này nhanh và có thể dự đoán, với hầu như không có chi phí. Nó hoạt động tốt cho các trường hợp rõ ràng: các câu lệnh SELECT đơn giản và CRUD cơ bản thường có thể được xác định mà không cần liên quan đến mô hình. 

Mô hình phân loại nhẹ sử dụng một mô hình ngôn ngữ nhỏ được đào tạo để ước tính độ phức tạp của SQL. Điều này thêm một bước, nhưng đó là một trong những quyết định ROI cao nhất trong toàn bộ đường ống. Một cuộc gọi phân loại có thể có chi phí khoảng 0,0001 đô la, điều này dễ dàng biện minh cho việc tránh một cuộc gọi mô hình Frontier có chi phí 0,03 đô la. 

Trong nhiều thiết lập, các mô hình nhẹ này cũng có thể chạy cục bộ, hiệu quả loại bỏ chi phí cho các truy vấn người dùng đơn giản. Chúng cũng có thể phân loại lời nhắc ngôn ngữ tự nhiên trước khi SQL được tạo, điều này hữu ích trong các công việc trợ lý nơi truy vấn không tồn tại. 

Phân loại kết hợp kết hợp cả hai cách tiếp cận. Logic dựa trên quy tắc xử lý các trường hợp rõ ràng với chi phí zero, trong khi bộ phân loại xử lý các trường hợp mơ hồ: các truy vấn trông có vẻ trung bình nhưng có thể yêu cầu lý luận nhận thức lược đồ để tạo ra chính xác. 

Định tuyến xảy ra sau khi phân loại. Nhưng tầng alone không phải là yếu tố duy nhất. Một số yếu tố khác ảnh hưởng đến nơi một truy vấn nên đi. Những yếu tố này bao gồm: 

1. Yêu cầu ngữ cảnh lược đồ. Một số truy vấn cần mô hình hiểu mối quan hệ giữa các bảng, khóa ngoại, chỉ mục hoặc cú pháp cụ thể của cơ sở dữ liệu. Những truy vấn này mang nhiều ngữ cảnh hơn và thường cần được định tuyến đến một mô hình có khả năng cao hơn. 
2. Độ chấp nhận độ trễ. Các tính năng hướng người dùng như tự động hoàn thành hoặc gợi ý trực tuyến có ngân sách độ trễ nghiêm ngặt. Các nhiệm vụ nền thường không. Trong những trường hợp đó, một mô hình chậm hơn nhưng có khả năng hơn có thể được chấp nhận. 
3. Ngưỡng tin cậy. Đôi khi bộ phân loại không chắc chắn về tầng. Trong những trường hợp đó, định tuyến lên thường là lựa chọn an toàn hơn. Một việc hạ cấp sai có thể tạo ra truy vấn xấu và kích hoạt các lần thử lại, điều này thường tốn kém hơn việc sử dụng mô hình mạnh hơn ngay từ đầu. 

Lớp xác thực chạy sau khi mã đã được chạy. Công việc của nó là bắt các lỗi định tuyến trước khi chúng đến người dùng. Sau khi thực hiện, các kiểm tra được thực hiện để đảm bảo rằng cú pháp là chính xác, kết quả là hợp lý (truy vấn có trả về hình dạng hàng đúng không?) và lược đồ là nhất quán. Khi một kết quả không vượt qua xác thực, hệ thống di chuyển lên một cấp và chạy truy vấn lại.

Tại Devart, điều quan trọng nhất để có độ chính xác định tuyến chính xác trong dbForge AI Assistant là xây dựng ngữ cảnh nhận thức lược đồ vào quyết định phân loại. Không có ngữ cảnh lược đồ, các truy vấn sử dụng tên bảng không rõ ràng hoặc dựa vào mối quan hệ ngầm đều bị phân loại sai và gửi đến các mô hình rẻ hơn không thể xử lý chúng. Giải pháp là cung cấp cho bộ phân loại không chỉ cấu trúc truy vấn mà còn một số siêu dữ liệu lược đồ.

Đo lường những gì quan trọng: giao dịch chi phí-chất lượng trong thực tế

Trường hợp kinh doanh cho việc định tuyến chỉ có giá trị nếu chất lượng được duy trì cùng với nó. Giảm chi phí gây ra đầu ra xuống cấp, tăng số lần thử lại hoặc mất niềm tin của nhà phát triển không phải là tiết kiệm, mà là chuyển chi phí từ hóa đơn cơ sở hạ tầng sang thời gian kỹ sư. Ba chỉ số xác định liệu một hệ thống định tuyến có thực sự hoạt động hay không.

Chi phí mỗi truy vấn theo tầng thiết lập đường cơ sở. Theo dõi chi tiêu thực tế tại mỗi tầng riêng biệt, không phải là giá trị trung bình. Việc trộn lẫn che giấu liệu định tuyến có hoạt động hay không, một hệ thống định tuyến 50% truy vấn đến tầng sai sẽ vẫn hiển thị chi phí trung bình thấp hơn, trong khi im lặng tạo ra kết quả kém hơn. 

Điểm chất lượng kiểm tra tính chính xác, tính đầy đủ và tuân thủ các phương pháp hay nhất SQL. Tỷ lệ gia tăng là tín hiệu chất lượng trực tiếp nhất. Nó cho biết bao nhiêu lần một mô hình Tầng 1 hoặc Tầng 2 tạo ra đầu ra không vượt qua xác thực và cần được gửi đến một vị trí khác. Một hệ thống được điều chỉnh tốt nên giữ tỷ lệ gia tăng dưới 5%. Bộ phân loại cần được đào tạo lại trên mức đó. Nó có thể đang đọc sai các tín hiệu cấu trúc hoặc nó có thể không có ngữ cảnh lược đồ cần thiết để phân biệt giữa trung bình và phức tạp. 

Tác động độ trễ xem xét thời gian cần thiết để phản hồi di chuyển từ tầng này sang tầng khác, bao gồm bất kỳ thời gian thêm nào cần thiết cho phân loại. Người dùng chỉ nên nhận thấy độ trễ khoảng 50 đến 100 mili giây trong các tương tác đi qua lớp định tuyến. Nếu bản thân phân loại trở thành vấn đề, cách tiếp cận kết hợp (quy tắc cho các trường hợp rõ ràng, bộ phân loại chỉ cho các trường hợp không rõ ràng) sửa nó mà không mất độ chính xác. 

Trong thực tế, một hệ thống định tuyến được điều chỉnh tốt có thể giảm chi phí suy luận bằng 40-60%, giữ tỷ lệ gia tăng dưới 5% và duy trì chất lượng đầu ra cao cho các truy vấn phức tạp. Để tiết kiệm 70% hoặc nhiều hơn, bạn thường phải thực hiện các nhiệm vụ Tầng 1 bằng các mô hình nhỏ hơn. Điều đó có thể hoạt động, nhưng nó cũng làm cho mọi thứ phức tạp hơn, điều mà không phải mọi đội đều muốn đối mặt.

“Thuế gia tăng” là một điều khác cần xem xét. Nếu định tuyến quá khắc nghiệt đối với các mô hình rẻ hơn, hệ thống có thể phải làm việc nhiều hơn tổng thể: cuộc gọi phân loại, cuộc gọi mô hình ban đầu, xác thực không thành công, định tuyến lại và cuộc gọi mô hình thứ hai. Trong một số trường hợp, điều đó tốn kém hơn việc gửi câu hỏi đến mô hình Frontier ngay từ đầu.

Chỉ xem xét chi phí mỗi cuộc gọi bỏ qua hiệu ứng này. Tỷ lệ gia tăng cần được theo dõi cùng với nó.

Lời khuyên chiến lược cho các đội kỹ sư

Định tuyến thông minh không chỉ là một tính năng tốt cho các triển khai AI SQL trưởng thành; đó là một yêu cầu cho các triển khai lâu dài. Các đội bỏ qua nó trao đổi một vấn đề ngân sách không thể giải quyết được với một vấn đề kiến trúc có thể giải quyết được. Các mẫu có ở đó; điều duy nhất còn lại là quyết định mẫu nào để theo dõi trước.

Bắt đầu với bộ phân loại, không phải mô hình. Lớp định tuyến quyết định xem mọi thứ khác có hoạt động hay không. Một bộ phân loại kết hợp được điều chỉnh tốt sẽ mang lại hầu hết tiết kiệm chi phí mà không làm mọi thứ quá phức tạp.

Sử dụng ngữ cảnh lược đồ của nguồn cấp để giúp đưa ra quyết định phân loại. Đối với các khối lượng công việc SQL liên quan đến mối quan hệ giữa nhiều bảng hoặc lý luận cụ thể của lược đồ, cấu trúc truy vấn alone không đủ. Siêu dữ liệu lược đồ một phần tại thời điểm phân loại tăng cường đáng kể độ chính xác của tầng.

Sử dụng tỷ lệ gia tăng làm tín hiệu chất lượng chính. Nó tìm thấy sự phân loại sai nhanh hơn bất kỳ chỉ số nào khác và chỉ ra chính xác nơi bộ phân loại cần cải thiện.

Trước khi bộ phân loại, hãy lên kế hoạch cho lớp xác thực. Biết những gì trông giống như thất bại và những gì gây ra sự gia tăng làm cho logic định tuyến sạch hơn và hệ thống tốt hơn để xử lý các trường hợp biên.

Giá trị của lớp định tuyến tăng lên, không giảm, khi các mô hình mã nguồn mở trở nên tốt hơn và chi phí suy luận cục bộ giảm xuống. Các mô hình Tầng 1 rẻ hơn làm cho sự khác biệt về chi phí giữa các tầng lớn hơn, điều này làm cho việc phân loại chính xác trở nên có giá trị hơn. Kiến trúc định tuyến được xây dựng ngày hôm nay sẽ hữu ích trong một thời gian dài, không chỉ là một giải pháp nhanh chóng.