AI thay đổi giao diện dữ liệu chứ không thay thế engine truy vấn

Phần mềm22 tháng 10, 2026·5 phút đọc

Bài viết phân tích quy trình phân tích khôi phục sau thảm họa, trong đó AI agent sinh câu lệnh SQL hoặc Python có ràng buộc, DuckDB tính toán các dữ liệu có thể tái lập từ Parquet, còn agent diễn giải kết quả. Tác giả làm rõ sự phân tách giữa yếu tố tất định và phần diễn giải, khả năng phát lại phân tích, cùng bốn dấu hiệu giúp quyết định khi nào engine nhúng là đủ và khi nào cần đến lakehouse được quản lý.

AI thay đổi giao diện dữ liệu chứ không thay thế engine truy vấn

Trong làn sóng AI tạo sinh tràn vào mọi tầng của ngăn xếp dữ liệu, nhiều người kỳ vọng mô hình ngôn ngữ lớn sẽ thay thế luôn cả engine truy vấn. Bài viết của Peihao Yuan trên InfoQ đưa ra một góc nhìn thực tế hơn: AI đang thay đổi giao diện để con người tương tác với dữ liệu, còn engine – nơi phép tính thực sự diễn ra – vẫn cần một lõi tất định, có thể kiểm chứng và tái lập.

Tác giả minh họa ý tưởng này qua một quy trình phân tích phục vụ khôi phục sau thảm họa (disaster recovery), nơi AI agent, DuckDB và dữ liệu Parquet phối hợp theo một cách phân công rõ ràng.

Phân công ba lớp: agent, engine và dữ liệu

Quy trình trong bài được tổ chức thành ba lớp riêng biệt:

  • AI agent sinh mã: Agent tạo ra câu lệnh SQL hoặc Python, nhưng bị giới hạn trong một tập ràng buộc chặt chẽ. Nó không được phép tự do tung ra bất kỳ truy vấn nào, mà chỉ sinh mã nằm trong phạm vi đã định nghĩa trước.
  • DuckDB tính toán dữ liệu: Engine nhúng nhận các truy vấn đã được kiểm soát này, thực thi trên dữ liệu Parquet và trả về những con số cụ thể, xác định được.
  • Agent diễn giải kết quả: Sau khi có kết quả, agent quay lại đóng vai trò giải thích, tóm tắt và đặt kết quả vào ngữ cảnh.

Điểm mấu chốt nằm ở chỗ: phần sinh mã và phần diễn giải đều do AI đảm nhiệm, nhưng phần tính toán thì giao cho engine tất định. AI không được tin tưởng để tự nghĩ ra con số, mà chỉ được tin tưởng để đề xuất cách hỏi và cách hiểu câu trả lời.

Sự phân tách tất định: ranh giới không thể nhập nhằng

Tác giả gọi đây là determinism split – sự phân tách giữa vùng tất định và vùng xác suất. Mô hình ngôn ngữ lớn về bản chất là xác suất: cùng một câu hỏi có thể cho ra những câu trả lời khác nhau. Nhưng dữ liệu phục vụ vận hành và khôi phục sau thảm họa thì không thể "chắc là đúng".

Việc để DuckDB thực thi truy vấn trên Parquet bảo đảm rằng với cùng một tập dữ liệu đầu vào và cùng một câu lệnh, kết quả luôn giống nhau. Đây là nền tảng cho khả năng phát lại phân tích (replayable analysis): bất kỳ ai cũng có thể chạy lại đúng câu lệnh cũ trên đúng dữ liệu cũ và thu được đúng con số cũ, dù AI diễn giải nó theo cách nào.

Sức mạnh thực sự của AI nằm ở việc loại bỏ độ phức tạp của giao diện, chứ không phải ở việc thay thế những phép tính cần độ chính xác tuyệt đối.

Cách làm này cũng thuận lợi cho kiểm toán. Khi mọi phân tích đều là một câu lệnh cụ thể chạy trên engine xác định, đội ngũ có thể lưu lại lịch sử, soát lại từng bước và truy vết nguồn gốc con số – điều mà một câu trả lời do AI "tự nghĩ" không bao giờ làm được.

Khi nào engine nhúng là đủ, khi nào cần lakehouse được quản lý?

Một câu hỏi thực tiễn đặt ra: liệu DuckDB cùng dữ liệu Parquet có đủ cho mọi tình huống, hay sớm muộn cũng phải chuyển lên một lakehouse được quản lý? Tác giả đưa ra bốn dấu hiệu để nhận diện thời điểm nên nâng cấp:

  • Khối lượng và độ phân tán dữ liệu vượt ngưỡng: Khi dữ liệu lớn đến mức không thể xử lý gọn trên một máy, hoặc trải rộng trên nhiều nguồn cần hợp nhất phức tạp.
  • Nhu cầu truy cập đồng thời cao: Nhiều người, nhiều hệ thống cùng truy vấn một lúc đòi hỏi khả năng quản lý tài nguyên và cách ly tải mà engine nhúng không được thiết kế để đáp ứng.
  • Yêu cầu quản trị và kiểm soát tập trung: Khi cần phân quyền chi tiết, ghi nhật ký truy cập, quản lý vòng đời dữ liệu và tuân thủ quy định ở cấp tổ chức.
  • Vận hành và độ tin cậy ở quy mô lớn: Khi việc sao lưu, phục hồi, mở rộng và giám sát cần đến hạ tầng chuyên dụng thay vì một quy trình chạy cục bộ.

Ngược lại, với các phân tích nhỏ, chạy nhanh, phạm vi hẹp, đặc biệt trong bối cảnh sự cố khi cần câu trả lời tức thì mà không phụ thuộc hạ tầng phức tạp, engine nhúng tỏ ra rất phù hợp.

Hàm ý cho đội ngũ dữ liệu tại Việt Nam

Với các đội kỹ thuật trong nước, cách tiếp cận này mang lại vài gợi ý thiết thực. Thứ nhất, có thể thử nghiệm AI agent cho tác vụ phân tích mà không cần đầu tư ngay vào hạ tầng lakehouse đắt đỏ – chỉ cần dựng DuckDB trên Parquet là đủ để kiểm chứng giá trị. Thứ hai, nguyên tắc "AI sinh mã, engine tính toán" giúp giảm rủi ro khi đưa AI vào các quy trình cần độ chính xác, chẳng hạn báo cáo tài chính hay phân tích vận hành.

Điều quan trọng nhất là giữ vững ranh giới: hãy để AI làm cho việc hỏi dữ liệu trở nên dễ dàng, nhưng đừng để nó quyết định sự thật của dữ liệu. Giao diện có thể thay đổi, engine thì vẫn phải đáng tin.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗