AI Agent cần tìm kiếm vector hơn bao giờ hết, RAG chỉ là bước khởi đầu

Vai trò của cơ sở dữ liệu vector trong thế giới của các tác tử AI (AI Agent) là gì? Đây là câu hỏi mà nhiều tổ chức đã phải đối mặt trong những tháng gần đây. Một luồng quan điểm đã thu hút được nhiều sự chú ý: khi các mô hình ngôn ngữ lớn (LLM) mở rộng cửa sổ ngữ cảnh lên đến hàng triệu token, các kiến trúc sư doanh nghiệp cho rằng tìm kiếm vector chuyên dụng chỉ là một giải pháp tạm thời, không phải là hạ tầng cốt lõi. Họ tin rằng bộ nhớ của AI Agent sẽ giải quyết bài toán truy xuất thông tin, và cơ sở dữ liệu vector chỉ là một di sản của thời đại RAG (Retrieval-Augmented Generation).

Tuy nhiên, thực tế triển khai lại đang đi theo một hướng hoàn toàn khác.

Qdrant, công ty tìm kiếm vector mã nguồn mở có trụ sở tại Berlin, vừa công bố vòng gọi vốn Series B trị giá 50 triệu USD vào thứ Năm, hai năm sau vòng Series A 28 triệu USD. Thời điểm này không phải là ngẫu nhiên. Công ty cũng đồng thời phát hành phiên bản 1.17 của nền tảng. Cả hai sự kiện này cùng phản ánh một lập luận đanh thép: Bài toán truy xuất thông tin không hề thu nhỏ khi AI Agent xuất hiện. Ngược lại, nó còn mở rộng và trở nên phức tạp hơn.

"Con người thực hiện vài truy vấn trong vài phút," Andre Zayarni, CEO và đồng sáng lập của Qdrant, chia sẻ với VentureBeat. "Trong khi đó, các AI Agent thực hiện hàng trăm, thậm chí hàng nghìn truy vấn mỗi giây, chỉ để thu thập thông tin nhằm đưa ra quyết định."

Sự thay đổi này đã định hình lại các yêu cầu về hạ tầng theo cách mà các hệ thống thời RAG chưa bao giờ được thiết kế để xử lý.

Tại sao AI Agent cần một lớp truy xuất mà bộ nhớ không thể thay thế

Các AI Agent hoạt động dựa trên những thông tin mà chúng chưa bao giờ được huấn luyện: dữ liệu độc quyền của doanh nghiệp, thông tin thời sự, và hàng triệu tài liệu thay đổi liên tục. Cửa sổ ngữ cảnh chỉ quản lý trạng thái của một phiên làm việc. Chúng không thể cung cấp khả năng tìm kiếm với độ phủ cao (high-recall) trên toàn bộ dữ liệu đó, duy trì chất lượng truy xuất khi dữ liệu thay đổi, hay đáp ứng khối lượng truy vấn khổng lồ do quá trình ra quyết định tự động tạo ra.

"Phần lớn các framework bộ nhớ AI hiện nay đều đang sử dụng một dạng lưu trữ vector nào đó," Zayarni cho biết.

Hàm ý rất rõ ràng: ngay cả những công cụ được định vị là giải pháp thay thế cho bộ nhớ cũng phải dựa vào một hạ tầng truy xuất bên dưới.

Ba kịch bản lỗi thường xuất hiện khi lớp truy xuất đó không được xây dựng chuyên dụng để chịu tải. Ở quy mô hàng triệu tài liệu, một kết quả bị bỏ lỡ không chỉ là vấn đề độ trễ — đó là vấn đề về chất lượng quyết định, và sai sót này sẽ tích tụ qua mỗi vòng truy xuất trong một lượt hoạt động của agent. Dưới áp lực ghi dữ liệu liên tục, độ liên quan của kết quả sẽ suy giảm vì dữ liệu mới được đưa vào nằm trong các phân đoạn chưa được tối ưu hóa, khiến việc tìm kiếm trên dữ liệu mới nhất trở nên chậm và kém chính xác hơn đúng vào lúc thông tin cập nhật là quan trọng nhất. Trên một hạ tầng phân tán, chỉ một bản sao (replica) chạy chậm cũng sẽ đẩy độ trễ lên cao trong mỗi lệnh gọi công cụ song song của agent — một sự chậm trễ mà người dùng có thể coi là bất tiện, nhưng một agent tự hành thì không thể chấp nhận.

Bản phát hành 1.17 của Qdrant giải quyết trực tiếp từng vấn đề này. Một truy vấn phản hồi độ liên quan (relevance feedback query) giúp cải thiện độ phủ bằng cách điều chỉnh điểm tương đồng trong lần truy xuất tiếp theo dựa trên các tín hiệu nhẹ do mô hình tạo ra, mà không cần huấn luyện lại mô hình nhúng (embedding model). Tính năng fan-out có độ trễ (delayed fan-out) sẽ truy vấn một bản sao thứ hai khi bản sao đầu tiên vượt quá ngưỡng độ trễ có thể cấu hình. Một API đo lường từ xa toàn cụm (cluster-wide telemetry) mới thay thế việc khắc phục sự cố trên từng nút bằng một giao diện duy nhất cho toàn bộ cụm máy chủ.

Tại sao Qdrant không còn muốn được gọi là cơ sở dữ liệu vector

Gần như mọi cơ sở dữ liệu lớn hiện nay đều hỗ trợ vector như một kiểu dữ liệu — từ các nhà cung cấp siêu quy mô (hyperscaler) đến các hệ thống quan hệ truyền thống. Sự thay đổi này đã làm thay đổi bản chất của cuộc cạnh tranh. Hỗ trợ kiểu dữ liệu vector giờ đây đã trở thành tiêu chuẩn cơ bản. Điều còn lại mang tính chuyên biệt chính là chất lượng truy xuất ở quy mô sản xuất.

Sự khác biệt này là lý do tại sao Zayarni không còn muốn Qdrant được gọi là một cơ sở dữ liệu vector.

"Chúng tôi đang xây dựng một lớp truy xuất thông tin cho kỷ nguyên AI," ông nói. "Cơ sở dữ liệu là để lưu trữ dữ liệu người dùng. Nếu chất lượng kết quả tìm kiếm là quan trọng, bạn cần một cỗ máy tìm kiếm."

Lời khuyên của ông cho các đội ngũ mới bắt đầu: hãy sử dụng bất kỳ tính năng vector nào có sẵn trong hệ thống của bạn. Các đội ngũ chỉ chuyển sang giải pháp truy xuất chuyên dụng khi quy mô bắt buộc họ phải làm vậy. "Mỗi ngày, chúng tôi đều thấy các công ty tìm đến và nói rằng họ đã bắt đầu với Postgres và nghĩ rằng nó đủ tốt — nhưng thực tế thì không."

Kiến trúc của Qdrant, được viết bằng Rust, mang lại hiệu quả sử dụng bộ nhớ và khả năng kiểm soát hiệu năng ở cấp thấp mà các ngôn ngữ bậc cao hơn không thể sánh được ở cùng một mức chi phí. Nền tảng mã nguồn mở càng làm tăng thêm lợi thế đó — phản hồi từ cộng đồng và sự chấp nhận của các nhà phát triển là yếu tố cho phép một công ty ở quy mô của Qdrant có thể cạnh tranh với các nhà cung cấp có nguồn lực kỹ thuật lớn hơn nhiều. "Nếu không có nó, chúng tôi sẽ không thể có được vị thế như ngày hôm nay," Zayarni khẳng định.

Hai câu chuyện thực tế về giới hạn của cơ sở dữ liệu đa dụng

Các công ty đang xây dựng hệ thống AI trên Qdrant đều đưa ra cùng một lập luận từ những góc độ khác nhau: AI Agent cần một lớp truy xuất, và bộ nhớ đàm thoại hay ngữ cảnh không thể thay thế cho nó.

GlassDollar giúp các doanh nghiệp lớn như Siemens và Mahle đánh giá các công ty khởi nghiệp. Tìm kiếm là sản phẩm cốt lõi của họ: người dùng mô tả nhu cầu bằng ngôn ngữ tự nhiên và nhận lại một danh sách rút gọn đã được xếp hạng từ một kho dữ liệu hàng triệu công ty. Kiến trúc của họ thực hiện mở rộng truy vấn (query expansion) cho mỗi yêu cầu - một câu lệnh duy nhất sẽ được phân tách thành nhiều truy vấn song song, mỗi truy vấn tìm kiếm ứng viên từ một góc độ khác nhau, trước khi kết quả được kết hợp và xếp hạng lại. Đây là một mẫu truy xuất của AI Agent, không phải mẫu RAG, và nó đòi hỏi một hạ tầng tìm kiếm chuyên dụng để duy trì hoạt động ở khối lượng lớn.

Công ty đã chuyển từ Elasticsearch khi quy mô tiến tới 10 triệu tài liệu được lập chỉ mục. Sau khi chuyển sang Qdrant, họ đã cắt giảm khoảng 40% chi phí hạ tầng, loại bỏ một lớp bù trừ dựa trên từ khóa mà họ phải duy trì để khắc phục những thiếu sót về độ liên quan của Elasticsearch, và chứng kiến mức độ tương tác của người dùng tăng gấp 3 lần.

"Chúng tôi đo lường thành công bằng độ phủ," Kamen Kanev, trưởng bộ phận sản phẩm của GlassDollar, cho biết. "Nếu những công ty tốt nhất không có trong kết quả, mọi thứ khác đều vô nghĩa. Người dùng sẽ mất niềm tin."

Bộ nhớ của AI Agent và cửa sổ ngữ cảnh mở rộng cũng không đủ để xử lý khối lượng công việc mà GlassDollar yêu cầu.

"Đó là một vấn đề về hạ tầng, không phải là một tác vụ quản lý trạng thái hội thoại," Kanev nói. "Đó không phải là thứ bạn có thể giải quyết bằng cách mở rộng cửa sổ ngữ cảnh."

Một người dùng khác của Qdrant là &AI, công ty đang xây dựng hạ tầng cho các vụ kiện tụng bằng sáng chế. Tác tử AI của họ, Andy, thực hiện tìm kiếm ngữ nghĩa trên hàng trăm triệu tài liệu kéo dài hàng thập kỷ và thuộc nhiều khu vực pháp lý khác nhau. Các luật sư về bằng sáng chế sẽ không hành động dựa trên văn bản pháp lý do AI tạo ra, điều đó có nghĩa là mọi kết quả mà agent đưa ra đều phải có nguồn gốc từ một tài liệu thực tế.

"Toàn bộ kiến trúc của chúng tôi được thiết kế để giảm thiểu nguy cơ ảo giác (hallucination) bằng cách đặt việc truy xuất làm nguyên tắc cốt lõi, chứ không phải việc tạo sinh nội dung," Herbie Turner, người sáng lập và CTO của &AI, chia sẻ.

Đối với &AI, lớp agent và lớp truy xuất được thiết kế tách biệt một cách có chủ đích.

"Andy, tác tử bằng sáng chế của chúng tôi, được xây dựng trên nền tảng Qdrant," Turner nói. "Agent là giao diện. Cơ sở dữ liệu vector là nguồn chân lý (ground truth)."

Ba tín hiệu cho thấy đã đến lúc nâng cấp hệ thống của bạn

Điểm khởi đầu thực tế là: hãy sử dụng bất kỳ khả năng vector nào đã có sẵn trong hệ thống của bạn. Câu hỏi cần đánh giá không phải là có nên thêm tìm kiếm vector hay không — mà là khi nào hệ thống hiện tại của bạn không còn đủ đáp ứng. Ba tín hiệu sau đây đánh dấu thời điểm đó:

1. Chất lượng truy xuất liên quan trực tiếp đến kết quả kinh doanh.
2. Các mẫu truy vấn trở nên phức tạp, bao gồm mở rộng truy vấn, xếp hạng lại đa tầng, hoặc gọi các công cụ song song.
3. Khối lượng dữ liệu vượt qua con số hàng chục triệu tài liệu.

Tại thời điểm đó, việc đánh giá sẽ chuyển sang các câu hỏi về vận hành: hệ thống hiện tại của bạn cung cấp bao nhiêu khả năng quan sát về những gì đang xảy ra trên một cụm máy chủ phân tán, và nó còn bao nhiêu dư địa về hiệu năng khi khối lượng truy vấn của agent tăng lên.

"Hiện tại có rất nhiều tranh luận về việc cái gì sẽ thay thế lớp truy xuất," Kanev nói. "Nhưng đối với bất kỳ ai đang xây dựng một sản phẩm mà chất lượng truy xuất chính là sản phẩm, nơi mà việc bỏ lỡ một kết quả sẽ gây ra hậu quả kinh doanh thực sự, bạn cần một hạ tầng tìm kiếm chuyên dụng."