Khi trí tuệ nhân tạo trở nên miễn phí: Tương lai của hệ thống dữ liệu cho AI Agent

... chính phủ của nhân dân, do nhân dân, vì nhân dân ... — Abraham Lincoln, Diễn văn Gettysburg (1863)

Chi phí cho AI đang giảm nhanh chóng. Các khả năng tương đương GPT-4 có giá khoảng 30 USD cho mỗi triệu token vào đầu năm 2023; ngày nay, mức giá này chỉ còn dưới 1 USD, và một số nhà cung cấp đang đẩy chi phí xuống dưới 0,10 USD. Trên các tiêu chuẩn đánh giá, giá suy luận (inference) đã giảm từ 9 đến 900 lần mỗi năm, với mức giảm trung bình gần 50 lần. Ngay cả các mô hình tiên tiến nhất cũng đang trở nên rẻ hơn đáng kể qua từng thế hệ, với các mô hình mã nguồn mở cũng theo sát phía sau. Quan trọng hơn, ngay cả khi trí tuệ "cấp độ thiên tài đoạt giải Nobel" chưa xuất hiện, thì trí tuệ đủ dùng cho phần lớn công việc tri thức đã có mặt ở đây ngày hôm nay và đang rẻ hơn theo từng tháng. Với tốc độ này, chúng ta sắp bước vào kỷ nguyên của trí tuệ gần như miễn phí—loại trí tuệ dư thừa cho các công việc tri thức hàng ngày.

Tiết lộ: Bài viết này là một góc nhìn do Aditya G. Parameswaran—Phó Giáo sư ngành EECS và đồng giám đốc EPIC Data Lab tại UC Berkeley—cùng các cộng sự dẫn dắt. Đây vừa là một khảo sát toàn cảnh vừa là một bài phân tích quan điểm, và một số hướng nghiên cứu được thảo luận dưới đây (bao gồm suy luận tác tử, bộ nhớ có cấu trúc và tổng hợp các hệ thống dữ liệu tùy chỉnh từ đầu) dựa trên công việc đang thực hiện của chính các tác giả.

Vậy, kỷ nguyên mới của trí tuệ gần như miễn phí này có ý nghĩa gì đối với các hệ thống dữ liệu? Chúng tôi tin rằng ba thách thức—và cơ hội—mới sẽ nảy sinh từ chi phí suy luận gần bằng 0:

Hệ thống dữ liệu DÀNH CHO tác tử (Data Systems For Agents). Các tác tử (agents) sẽ sớm trở thành khối lượng công việc chủ đạo cho các hệ thống dữ liệu—với hàng loạt tác tử được khởi chạy để phản hồi mỗi yêu cầu của người dùng cuối. Với sự khác biệt về đặc điểm giữa tác tử và con người—hoặc các ứng dụng hành động thay mặt họ—chúng ta nên thiết kế lại các hệ thống dữ liệu như thế nào cho những người dùng là tác tử này?

Hệ thống dữ liệu CỦA tác tử (Data Systems Of Agents). Khi các tác tử bắt đầu đảm nhận phần lớn công việc tri thức, một nền tảng mới là cần thiết để hàng ngàn tác tử quản lý trạng thái trong các tác vụ chạy dài, phối hợp và đạt được sự đồng thuận, cũng như xử lý các lỗi phát sinh. Các hệ thống dữ liệu vận hành và quản lý các bầy tác tử một cách đáng tin cậy và hiệu quả sẽ trông như thế nào?

Hệ thống dữ liệu BỞI tác tử (Data Systems By Agents). Các tác tử đang nhanh chóng có khả năng tổng hợp toàn bộ hệ thống dữ liệu trong một lần thực hiện—nghĩa là chúng ta có thể xây dựng lại các hệ thống tùy chỉnh cho mỗi khối lượng công việc mới. Việc xác minh rằng các hệ thống như vậy khớp với hành vi mong muốn là một thách thức. Cần những gì để cho phép các tác tử tổng hợp các hệ thống dữ liệu mà chúng ta thực sự có thể tin tưởng?

Hệ thống dữ liệu Dành cho, Của và Bởi tác tử

Tiếp theo, chúng tôi sẽ thảo luận chi tiết hơn về từng mục, sau đó thảo luận về tương lai đan xen giữa các hệ thống dữ liệu và tác tử, đặc biệt là khi ba thách thức này giao thoa với nhau.

Một tác tử truy vấn cơ sở dữ liệu không hoạt động giống như một con người hay một công cụ BI. Nó thực hiện cái mà chúng tôi gọi là suy luận tác tử (agentic speculation): một luồng công việc khối lượng lớn, không đồng nhất, bao gồm việc nội quan lược đồ (schema introspection), khám phá cột (columnar exploration), xây dựng truy vấn từng phần và sau đó là toàn phần. Với nhiều tác tử cùng khám phá các phần của không gian giả thuyết, mỗi yêu cầu của người dùng có thể lên tới hàng ngàn truy vấn SQL riêng lẻ. Giờ đây, người dùng có thể đưa ra các tác vụ dữ liệu 'cấp cao', ví dụ: phân tích nguyên nhân gốc rễ—ví dụ: 'tại sao doanh số cà phê ở Berkeley lại giảm trong năm nay'—hoặc phân tích nhóm khám phá—ví dụ: 'phân khúc người dùng nào có khả năng rời bỏ cao nhất vào quý tới'—mỗi tác vụ liên quan đến một không gian tổ hợp của các phép nối (joins), tổng hợp (aggregations) và kết hợp bộ lọc tiềm năng.

Các hệ thống dữ liệu được thiết kế lại để hỗ trợ hiệu quả hơn cho suy luận tác tử

Các yêu cầu từ những tác tử này có nhiều cơ hội để tối ưu hóa. Ví dụ, trên một tiêu chuẩn đánh giá text-to-SQL với nhiều tác tử cùng thực hiện mỗi tác vụ, chỉ 10-20% các kế hoạch con (sub-plans) là khác biệt. Do đó, 80-90% các truy vấn con thực hiện công việc trùng lặp. Các thí nghiệm tương tự cho thấy tỷ lệ thành công của tác vụ tăng đáng kể với nhiều nỗ lực tác tử hơn—vì vậy sự dư thừa thực sự lại hữu ích. Nhưng từ góc độ hệ thống dữ liệu, đó là công việc lãng phí.

Một hệ thống dữ liệu ưu tiên tác tử (agent-first) có thể khai thác các đặc tính này để giúp tác tử tiến bộ nhanh hơn. Nó có thể tái sử dụng kết quả từ các kế hoạch con chồng chéo, dựa trên các ý tưởng từ tài liệu hàng thập kỷ về tối ưu hóa đa truy vấn và quét chia sẻ (shared scans). Hoặc hệ thống dữ liệu có thể cố gắng thỏa mãn (satisfice), trả về các câu trả lời xấp xỉ đủ tốt để tác tử tiến triển, tận dụng công việc từ tài liệu AQP (Approximate Query Processing)—hoặc truyền phát kết quả của các toán tử cuối cùng hoặc trung gian để giúp tác tử quyết định xem việc xem phần còn lại có cần thiết hay hữu ích hay không.

Một cơ hội khác ở đây là suy nghĩ lại hoàn toàn về giao diện truy vấn: thay vì các tác tử đưa ra từng truy vấn SQL một lúc, chúng có thể đưa ra một loạt truy vấn, mỗi truy vấn có các yêu cầu xấp xỉ riêng. Vì việc liệt kê một không gian tìm kiếm theo cấp số nhân (như trong các ví dụ phân tích nguyên nhân gốc rễ hoặc phân tích nhóm ở trên) không phải là cách sử dụng tốt khả năng suy luận của tác tử, có lẽ các hệ thống dữ liệu nên hỗ trợ các nguyên hàm (primitives) cấp cao hơn thay vì yêu cầu tác tử liệt kê rõ ràng từng truy vấn SQL. Một ý tưởng ở đây là tận dụng các macro Jinja kiểu DBT để cung cấp các nguyên hàm dựa trên vòng lặp cho tác tử tương tác với hệ thống dữ liệu.

Một đội quân tác tử đầy năng lượng sẵn sàng hoàn thành các tác vụ dữ liệu của bạn không mệt mỏi

Một cơ hội cuối cùng ở đây là ngừng coi các hệ thống dữ liệu là những thực thể thực thi truy vấn thụ động; các hệ thống dữ liệu có thể chủ động, vì chúng sở hữu nhiều nền tảng hơn về dữ liệu và đặc điểm hệ thống mà các tác tử có thể thiếu từ trước—chúng có thể hướng các tác tử đi theo các hướng khác nhau, cung cấp kết quả cho các truy vấn liên quan và cũng cung cấp phản hồi về hiệu suất (ví dụ: thay vì thực thi một truy vấn đắt đỏ, hệ thống có thể cung cấp cho tác tử ước tính độ trễ trước). Lý do chúng ta có thể làm điều này bây giờ so với trước đây là vì một tác tử có thể chấp nhận bất kỳ hình thức phản hồi văn bản nào và không mong đợi một kết quả truy vấn SQL nghiêm ngặt. Trên thực tế, hệ thống dữ liệu cũng có thể chuẩn bị sẵn cả các view vật chất hóa (materialized views) và view ảo cho tác tử, được cung cấp cho tác tử như một phần của ngữ cảnh, vì điều này có thể rẻ hơn hoặc hiệu quả hơn so với việc để tác tử tự tạo hoặc sử dụng chúng.

Hệ thống dữ liệu CỦA tác tử

Trước đây, chúng tôi tập trung vào cách các tác tử tương tác với hệ thống dữ liệu. Bây giờ, chúng tôi xem xét mọi thứ khác mà các tác tử cần để tiếp tục làm việc: nơi chúng sống, cách chúng ghi nhớ, cách chúng phối hợp với nhau và cách chúng xử lý lỗi của nhau. Nền tảng tác tử (agentic substrate) này tách biệt với ngăn xếp suy luận (inference stack) cung cấp trí tuệ thô. Tuy nhiên, bản thân ngăn xếp suy luận đang được trừu tượng hóa thông qua các API (ví dụ: từ OpenAI hoặc Anthropic), hoặc đối với các mô hình mở (open-weight), thông qua các khung phục vụ (serving frameworks) che giấu các chi tiết cấp thấp. Cho đến nay, nền tảng tác tử đã được quản lý thông qua các bộ khung như Claude Code và Codex, kết hợp với nhiều cơ chế khác nhau để lưu trữ và truy xuất bộ nhớ.

Đầu tiên, về mặt bộ nhớ, quan điểm hiện tại là tệp tin (files) là tất cả những gì bạn cần; các tác tử ghi vào các tệp markdown (MD) không cấu trúc, sau đó có thể được tìm kiếm bằng grep, hoặc thông qua truy xuất dựa trên embedding. Trên thực tế, nhiều người lập luận rằng giải pháp cho việc học liên tục (continual learning) là để các tác tử tiêu thụ rất nhiều (ví dụ: toàn bộ codebase, slack, wiki công ty,...) và sau đó viết những gì chúng học được vào các tệp MD, sau đó được truy xuất có chọn lọc theo yêu cầu. Quả thực, hệ thống tệp, kịch bản bash và tệp MD vẫn và sẽ tiếp tục quan trọng đối với các tác tử. Tuy nhiên, ở quy mô lớn, khi các tác tử thực hiện phần lớn công việc tri thức, cách tiếp cận này sẽ không còn hiệu quả.

Với các cửa sổ ngữ cảnh (context windows) hạn chế, việc truy xuất tất cả các đoạn tệp MD có thể liên quan và nhồi nhét chúng vào ngữ cảnh sẽ bị phá vỡ tại một thời điểm nào đó. Ngay cả khi các cửa sổ ngữ cảnh tiếp tục phát triển, vẫn có những lợi ích về độ trễ khi không đưa tất cả thông tin vào ngữ cảnh—và trong nhiều trường hợp, ví dụ: khi công việc tri thức liên quan đến việc tương tác với các cơ sở dữ liệu hoặc codebase lớn, sẽ không khả thi để tuần tự hóa tất cả dữ liệu liên quan vào ngữ cảnh.

Hệ thống dữ liệu như một nền tảng cho các bầy đa tác tử (Multi-Agent Swarms)

Người ta có thể sử dụng biểu diễn đồ thị tri thức (knowledge graph), nhưng các đồ thị tri thức cũng chịu những hạn chế tương tự như bộ nhớ dựa trên MD không cấu trúc do thiếu khả năng tìm kiếm có cấu trúc. Điều cần thiết là khả năng chỉ truy xuất bộ nhớ liên quan đến tác vụ, trên nhiều thuộc tính (hoặc khía cạnh) quan tâm. Ví dụ, một tác tử đang gỡ lỗi một bài kiểm tra không ổn định (flaky test) sẽ có thể chỉ lấy ra các bộ nhớ được gắn thẻ với mô-đun, ngôn ngữ, khung làm việc và chế độ lỗi liên quan—thay vì truy xuất dựa trên từ khóa hoặc độ tương đồng embedding. Một vấn đề riêng biệt là thực sự truy xuất cái gì; các dấu vết (traces) tác tử thô với các sai lầm không hữu ích lắm vì chúng sẽ khiến các tác tử lặp lại cùng một sai lầm—thay vào đó, chúng ta muốn bộ nhớ được truy xuất mang tính chất sửa lỗi.

Gần đây, chúng tôi đã khám phá một khái niệm liên quan về bộ nhớ có cấu trúc, nơi chúng tôi tổ chức bộ nhớ theo nhiều thuộc tính khác nhau, mỗi thuộc tính có thể được đặt là * để chỉ ra khả năng áp dụng phổ quát, hoặc đặt là một danh sách các giá trị để khớp. Đối với một tác tử dữ liệu, các chiều có thể bao gồm các cột và bảng, loại thao tác và cuối cùng là các hướng dẫn sửa lỗi bằng ngôn ngữ tự nhiên mở. Vì vậy, chúng tôi có thể bao gồm bộ nhớ chỉ áp dụng cho một loại thao tác nhất định (ví dụ: 'khi thực hiện các thao tác ngày-giờ, hãy sử dụng quy ước năm tài chính thay vì năm dương lịch'), hoặc một bảng nhất định (ví dụ: 'cột product_cleaned được ưu tiên hơn cột product khi truy vấn theo tên sản phẩm'). Một câu hỏi mở là xác định bộ nhớ có cấu trúc dành riêng cho ứng dụng—hoặc cái mà người khác gọi là mô hình thế giới (world models) cho bộ nhớ. Chúng tôi tin rằng điều này tương tự như việc xác định lược đồ cho mỗi ứng dụng—và có lẽ bản thân các tác tử có thể giúp chúng ta xác định và tinh chỉnh nó theo thời gian.

Một cách khả thi để lưu trữ và truy xuất tri thức có cấu trúc [Từ đây]

Bộ nhớ có cấu trúc cũng sẽ hữu ích cho các khung tiến hóa để quản lý hiệu quả các không gian tìm kiếm. Quả thực, việc lưu trữ, cấu trúc và khai thác khối lượng lớn các dấu vết đơn và đa tác tử có thể giúp các tác tử tương lai trở nên hiệu quả hơn nhiều—có khả năng cho phép tự cải thiện đệ quy hiệu quả thông qua các cơ chế dựa trên bộ nhớ có cấu trúc.

Một thách thức khác là hỗ trợ các chỉnh sửa đồng thời đối với bộ nhớ chia sẻ, và các chỉnh sửa đồng thời nói chung, khi có nhiều tác tử thực hiện các phép biến đổi. Mặc dù đã có một số nỗ lực hữu ích trong việc hỗ trợ đa phiên bản (multiversioning) và ngữ nghĩa copy-on-write, nhưng không rõ liệu các kỹ thuật như vậy có đủ khi hàng ngàn tác tử đang cố gắng chỉnh sửa trạng thái chia sẻ cùng một lúc hay không. Ví dụ, khi các tác tử đang thử các giao dịch tiềm năng khác nhau để phản hồi yêu cầu của người dùng, kết quả của phần lớn các giao dịch này cần được hoàn tác (roll back)—với chỉ kết quả của một giao dịch 'đúng' được duy trì. Công việc hỗ trợ ngữ nghĩa exactly-once có liên quan ở đây, cũng như các kỹ thuật cơ bản dựa trên CRDT và biến đổi vận hành (operational transformation). Đối với các cập nhật cho các cơ chế mờ như bộ nhớ, chúng ta có thể hy sinh tính nhất quán để đạt được sự chính xác hoàn hảo vì lợi ích của độ trễ. Trong khi các tác tử có thể suy luận về ngữ nghĩa để bù đắp hoặc hoàn tác các hành động của chúng để cuối cùng hoàn thành hầu hết các tác vụ, thách thức chính nằm ở mức độ chúng cản trở lẫn nhau trong quá trình này. Một chế độ lỗi quan trọng cần tránh là một dạng "livelock", nơi các hành động bù đắp không ngừng ngăn cản bất kỳ tiến bộ có ý nghĩa nào.

Ngoài trạng thái chia sẻ, các mối quan tâm khác nảy sinh khi cố gắng hỗ trợ một đội quân tác tử, bao gồm việc phải làm gì khi các tác tử thất bại, cách các tác tử nên giao tiếp với nhau (trực tiếp hoặc thông qua trạng thái chia sẻ trung gian) và cách chúng ta nên xử lý các tác tử bị tụt hậu (straggler agents). Đã có một số phát triển trong việc hỗ trợ thực thi đa tác tử bền bỉ, chẳng hạn như Temporal, nhưng vẫn còn phải xem liệu các giải pháp như vậy có áp dụng ở quy mô hàng ngàn tác tử hay không. Về chủ đề giao tiếp, chúng ta cần các cơ chế để cho phép các tác tử thương lượng với nhau. Hãy tưởng tượng bốn tác tử lập trình viên đang cố gắng đạt được sự đồng thuận về một lược đồ chia sẻ, với các mục tiêu riêng biệt nhưng chồng chéo. Trong bối cảnh con người, điều này sẽ bao gồm thảo luận lặp đi lặp lại và thỏa hiệp; đối với các bầy tác tử, chúng ta phải xác định các cơ chế cho phép chúng hội tụ về một thiết kế phản ánh các mục tiêu cơ bản của những người ủy quyền tương ứng của chúng. Hoặc nếu tất cả các tác tử đều yêu cầu quyền truy cập vào một tài nguyên hạn chế, thì việc giao tiếp lại sẽ là cần thiết. Vẫn còn phải xem liệu điều này được thực hiện tốt nhất thông qua phối hợp tập trung, hay liệu một cách tiếp cận phi tập trung là cần thiết.

Hệ thống dữ liệu BỞI tác tử

Cuối cùng, nếu trí tuệ thực sự miễn phí, thì chúng ta có thể sử dụng trí tuệ này để tổng hợp các hệ thống dữ liệu mới từ đầu. Quả thực, trong nhiều bối cảnh, các hệ thống dữ liệu đa năng có thể là quá mức cần thiết, vì chúng phải hỗ trợ mọi lược đồ, truy vấn và mục tiêu phần cứng. Với một khối lượng công việc nhất định, các công việc gần đây, bao gồm Bespoke OLAP và GenDB, đã chỉ ra rằng người ta có thể sử dụng một đường ống tác tử (agentic pipeline) để tổng hợp một công cụ phân tích hoàn chỉnh, dành riêng cho khối lượng công việc—trong vài phút đến vài giờ, với chi phí vài đô la. Các công cụ này là dùng một lần: khi khối lượng công việc thay đổi, người ta chỉ cần tạo lại chúng. Tương tự, công việc của chúng tôi đã chỉ ra rằng người ta có thể tổng hợp các kho lưu trữ khóa-giá trị (key-value stores) tùy chỉnh từ đầu, nhắm mục tiêu vào khối lượng công việc. Trên thực tế, các IDE hiện đại, chẳng hạn như Kiro, nâng tầm các thông số kỹ thuật cho phát triển hệ thống trở thành một công dân hạng nhất.

Các tác tử có thể tổng hợp các hệ thống dữ liệu tùy chỉnh từ đầu

Tuy nhiên, vấn đề chính là các thông số kỹ thuật thường không hoàn hảo và không bao gồm tất cả các trường hợp biên (corner cases). Các tác tử ngày nay sẽ khai thác các thông số kỹ thuật còn thiếu để "hack phần thưởng" nhằm đạt được chỉ số hiệu suất cao. Trong công việc về kho lưu trữ khóa-giá trị tùy chỉnh của chúng tôi, chúng tôi nhận thấy rằng một cách để giảm bớt điều này là có các tác tử xác minh phụ trợ cố gắng tạo ra các trường hợp kiểm thử nhằm bắt lỗi việc khai thác các trường hợp biên, về cơ bản là mở rộng thông số kỹ thuật. Một cách tiếp cận khác là vừa tạo ra một hệ thống vừa tạo ra bằng chứng cho tính đúng đắn của nó cùng nhau, mà chúng tôi đã thấy một số thành công ban đầu, nhưng cần làm nhiều hơn nữa để củng cố cách tiếp cận này. Hơn nữa, vẫn còn phải xem cách tốt nhất để thu thập các thông số kỹ thuật do con người viết cho một hệ thống là gì—liệu điều này có thể được thực hiện theo cách lặp đi lặp lại, có sự tham gia của con người (human-in-the-loop), thay vì một lần duy nhất và không đầy đủ. Quả thực, các thông số kỹ thuật do con người viết vẫn không đầy đủ ngay cả đối với phần mềm được viết thủ công, vì vậy người ta có thể mong đợi rằng các tác tử tương lai được căn chỉnh tốt hơn sẽ ngày càng thực hiện phán đoán tốt hơn khi đưa ra các quyết định thiết kế.

Một đường ống tổng hợp hệ thống dữ liệu khả thi [Từ đây]

Các câu hỏi khác ở đây bao gồm việc kiểm tra xem liệu việc bắt đầu từ một hệ thống trưởng thành (ví dụ: Postgres) và loại bỏ các thành phần/chức năng có thể dẫn đến hiệu suất cao hơn hoặc sự tin tưởng của người dùng hơn hay không. Một cách riêng biệt, liệu có cơ hội để làm cho thiết kế có thể kết hợp (composable), bao gồm nhiều thành phần đã được xác minh được trộn lẫn và kết hợp dựa trên khối lượng công việc hay không? Ví dụ, có lẽ khối lượng công việc chưa thay đổi đủ để lớp lưu trữ cần cập nhật, nhưng có lẽ bộ tối ưu hóa truy vấn yêu cầu thay đổi. Một đề xuất có lẽ khả thi hơn liên quan đến việc sử dụng các tác tử kết hợp với các hệ thống chứng minh để nhắm mục tiêu vào các phần quan trọng của mã liên quan đến các bằng chứng hình thức, thay vì làm như vậy cho toàn bộ hệ thống.

Một cơ hội cuối cùng ở đây là rời xa ngăn xếp hệ thống dữ liệu truyền thống với các giao diện được xác định rõ ràng (ví dụ: trình phân tích cú pháp, bộ tối ưu hóa truy vấn, trình quản lý lưu trữ,...)—mà mỗi giao diện phần lớn là đặc quyền của một nhóm người quản lý. Thay vào đó, các tác tử có thể tìm ra những cách mới để "trộn" các thành phần này lại với nhau, có lẽ xác định các cơ hội tối ưu hóa mới. Các tác tử cũng có thể lấp đầy các khoảng trống chức năng còn thiếu để làm cho các hệ thống hiện có hoàn thiện hơn về tính năng, hoặc đạt được sự ngang bằng về tính năng với các hệ thống cạnh tranh khác—hoặc tương tự, liên tục tinh chỉnh các hệ thống mã nguồn mở để phản hồi các yêu cầu tính năng hoặc vấn đề (có lẽ được các tác tử khác gửi đến!). Làm như vậy theo cách ưu tiên tính đúng đắn, bảo trì lâu dài và khả năng diễn giải của con người sẽ là một thách thức.