Chọn cơ sở dữ liệu phù hợp cho các tác nhân AI: SQL do LLM tạo ra

Xuất bản ngày 15 tháng 8 năm 2026 Lựa chọn cơ sở dữ liệu phù hợp cho các tác nhân AI: SQL do LLM tạo ra Tác giả: Jai Twitter: @jkntji Các tác nhân AI đang nhanh chóng phát triển từ những chatbot đơn giản thành các hệ thống có thể cấu hình, thích ứng với nhiều lĩnh vực và nguồn dữ liệu khác nhau. Một trường hợp sử dụng đặc biệt thú vị là tác nhân mà người dùng có thể cấu hình với dữ liệu có cấu trúc của riêng họ. Một tác nhân có thể làm việc với dữ liệu tồn kho cửa hàng cho một người dùng, và với hồ sơ khách hàng, danh mục sản phẩm hoặc các bộ dữ liệu hoàn toàn khác cho người dùng khác. Trong các hệ thống này, cấu trúc dữ liệu không được nhà phát triển định nghĩa trước; nó được người dùng cuối định nghĩa tại thời điểm chạy. Điều này tạo ra một loạt thách thức độc đáo cho cơ sở dữ liệu nền tảng. Hệ thống cần hỗ trợ lược đồ linh hoạt, khả năng đa người thuê mạnh mẽ để dữ liệu của người dùng được cách ly, dễ dàng nhập và truy vấn các tệp như CSV, và ngày càng cần SQL do LLM tạo ra một cách đáng tin cậy. Trong bài viết này, chúng ta sẽ khám phá các yêu cầu này và xem xét các kiến trúc cơ sở dữ liệu phù hợp nhất cho các tác nhân AI có thể cấu hình. Các yêu cầu cốt lõi của tác nhân có thể cấu hình Không giống như các ứng dụng truyền thống, nơi các nhà phát triển định nghĩa lược đồ cơ sở dữ liệu, các tác nhân có thể cấu hình cần làm việc với dữ liệu có cấu trúc do người dùng cuối cung cấp. Điều này tạo ra một số yêu cầu quan trọng: Tính linh hoạt của lược đồ: Các phiên bản khác nhau của cùng một tác nhân phải có khả năng làm việc với các cấu trúc dữ liệu hoàn toàn khác nhau mà không yêu cầu thay đổi mã ứng dụng hoặc di chuyển. Khả năng truy vấn: Dữ liệu phải luôn có thể tìm kiếm và lọc đầy đủ để tác nhân có thể trả lời các câu hỏi hoặc thực hiện các hành động dựa trên dữ liệu đó. Đa người thuê (Multi-tenancy): Dữ liệu thuộc về các người dùng hoặc tổ chức khác nhau phải được cách ly nghiêm ngặt. Nhập dữ liệu dạng bảng: Người dùng có thể tải lên các tệp CSV chứa hàng trăm hoặc hàng nghìn hàng, và các hàng đó cần trở thành các bản ghi có thể truy vấn. Khả năng tương thích với SQL do LLM tạo ra: Nhiều hệ thống tác nhân dựa vào một LLM để tạo ra SQL cần thiết để truy xuất dữ liệu. SQL càng đơn giản và chuẩn hóa thì LLM càng có thể tạo ra nó một cách đáng tin cậy. Các yêu cầu này tạo ra một sự đánh đổi thú vị giữa tính linh hoạt, khả năng cách ly và độ tin cậy của truy vấn. Tại sao lược đồ quan hệ truyền thống có thể khó khăn Một cơ sở dữ liệu quan hệ truyền thống với các cột được định nghĩa trước hoạt động cực kỳ hiệu quả khi nhà phát triển kiểm soát lược đồ. Nó trở nên khó khăn hơn khi người dùng cuối định nghĩa cấu trúc. Bạn không thể định nghĩa trước mọi cột có thể mà người dùng cần. Một bộ dữ liệu có thể chứa giá, danh mục và tồn kho, trong khi một bộ dữ liệu khác chứa tên khách hàng (customer_name), email và trạng thái đăng ký (subscription_status). Đây là lý do tại sao các phương pháp tiếp cận hướng tài liệu và bán cấu trúc như JSONB ban đầu có vẻ hấp dẫn. Postgres + JSONB: Linh hoạt nhưng có hạn chế Kiểu dữ liệu JSONB của PostgreSQL cung cấp một giải pháp trung gian hấp dẫn. Bạn có thể lưu trữ dữ liệu có cấu trúc tùy ý trong một cột JSONB trong khi vẫn hưởng lợi từ hệ sinh thái trưởng thành, các giao dịch, lập chỉ mục và các tính năng bảo mật của Postgres. JSONB hoàn toàn có thể truy vấn bằng cách sử dụng các toán tử như ->, ->> và @>, và nó hỗ trợ các chỉ mục GIN mạnh mẽ. Một thiết kế điển hình có thể trông như sau: CREATE TABLE dataset_rows ( id UUID PRIMARY KEY, tenant_id UUID NOT NULL, dataset_id UUID NOT NULL, row_data JSONB NOT NULL ); Mỗi hàng của tệp CSV do người dùng tải lên sẽ trở thành một hàng trong bảng này, với các cột CSV được lưu trữ bên trong tài liệu JSONB. Tính năng đa người thuê (multi-tenancy) có thể được xử lý bằng cách sử dụng cột tenant_id cùng với Bảo mật cấp hàng (Row Level Security - RLS). Khi được cấu hình chính xác, chính cơ sở dữ liệu có thể thực thi việc cách ly người thuê thay vì hoàn toàn dựa vào việc lọc ở cấp ứng dụng. Kiến trúc này hoạt động tốt từ góc độ lưu trữ. Tuy nhiên, nó làm tăng thêm sự phức tạp khi cách chính để truy vấn dữ liệu là thông qua SQL do LLM tạo ra. Các LLM thường đáng tin cậy hơn khi tạo SQL dựa trên cột thông thường so với khi chúng cần tạo các biểu thức đường dẫn JSONB, chuyển đổi kiểu dữ liệu và các toán tử chứa. Mỗi lớp cú pháp bổ sung mang lại cho mô hình một cơ hội khác để tạo ra một truy vấn không hợp lệ hoặc không chính xác. **Tính năng đa người thuê có thể giải quyết được; các truy vấn động là không thể tránh khỏi** Khả năng dữ liệu từ các người dùng khác nhau bị trộn lẫn trong cùng một bảng là một mối lo ngại chính đáng, nhưng nó có thể giải quyết được. Một cột tenant_id hoặc agent_id kết hợp với Bảo mật cấp hàng là một phương pháp trưởng thành cho các ứng dụng đa người thuê. Các hình thức cách ly mạnh mẽ hơn, chẳng hạn như schema-per-tenant (mỗi người thuê một lược đồ) hoặc database-per-tenant (mỗi người thuê một cơ sở dữ liệu), cũng có thể thực hiện được tùy thuộc vào yêu cầu của ứng dụng. Tuy nhiên, các truy vấn động là không thể tránh khỏi. Vì các trường được định nghĩa bởi người dùng cuối, cả ứng dụng và LLM đều không thể dựa vào một tập hợp cố định các tên cột đã biết tại thời điểm phát triển. Hệ thống cần hiểu lược đồ của từng tập dữ liệu và xây dựng các truy vấn dựa trên đó trong thời gian chạy. Thách thức này tồn tại bất kể dữ liệu cơ bản được lưu trữ trong Postgres JSONB, các bảng quan hệ hay một cơ sở dữ liệu tài liệu. **Xử lý các tệp CSV do người dùng tải lên** Hãy xem xét một người dùng tải lên một tệp CSV chứa 1.000 bản ghi sản phẩm. Hệ thống cần biến dữ liệu dạng bảng đó thành thứ mà tác nhân (agent) có thể truy vấn hiệu quả. Sau khi nhập dữ liệu, tác nhân có thể cần trả lời các câu hỏi như: Những sản phẩm nào có giá dưới 500 ₹? Những sản phẩm điện tử nào hiện đang có hàng? Những thương hiệu nào có hơn 20 sản phẩm? Giá trung bình trong một danh mục cụ thể là bao nhiêu? Tệp CSV của một người dùng khác có thể chứa các cột hoàn toàn khác. Ở quy mô vài nghìn hàng cho mỗi tập dữ liệu, hiệu suất khó có thể là yếu tố quyết định. Hầu hết các cơ sở dữ liệu hiện đại đều có thể xử lý khối lượng đó một cách thoải mái. Các yếu tố quan trọng hơn cần xem xét là tính linh hoạt của lược đồ, khả năng cách ly, sự đơn giản trong vận hành và mức độ dễ dàng mà một LLM có thể tạo ra các truy vấn chính xác đối với dữ liệu. **Yếu tố quyết định: SQL do LLM tạo ra** Khi một LLM chịu trách nhiệm tạo truy vấn, các tiêu chí đánh giá sẽ thay đổi. Hãy xem xét việc yêu cầu một LLM tạo ra truy vấn sau: WHERE (row_data->>'price')::numeric < 500 AND row_data->>'catego