Vượt qua RAG vector truyền thống: Kiến trúc mới cho bộ nhớ AI Agent

RAG (Retrieval-Augmented Generation) đã trở thành một trong những cách chuẩn để kết nối mô hình ngôn ngữ với thông tin bên ngoài. Cách tiếp cận quen thuộc gồm các bước: chia tài liệu thành từng đoạn nhỏ, tạo embedding, lưu vector vào cơ sở dữ liệu và truy xuất các đoạn gần nhất trước khi yêu cầu mô hình trả lời.

Kiến trúc đó giải quyết một vấn đề quan trọng thời kỳ đầu. Nhưng AI Agent đang thay đổi ý nghĩa của việc truy xuất. Agent không chỉ trả lời câu hỏi — chúng chọn công cụ, so sánh nguồn, kiểm tra kết quả trung gian, thực hiện các quy trình nhiều bước và quyết định khi nào đã có đủ thông tin để hành động.

RAG cho AI Agent là gì?

RAG cho AI Agent là hệ thống cung cấp cho agent quyền truy cập thông tin bên ngoài trong khi nó suy luận và hành động. RAG truyền thống thường tuân theo một trình tự cố định. Agentic RAG thay đổi trình tự đó để agent tự quyết định khi nào cần truy xuất.

RAG truyền thống: Câu hỏi người dùng → Embed câu hỏi → Tìm kiếm vector database → Truy xuất các đoạn → Gửi cho mô hình → Sinh câu trả lời.

Agentic RAG: Nhiệm vụ người dùng → Agent phân tích nhiệm vụ → Agent quyết định thông tin cần thiết → Agent gọi công cụ truy xuất hoặc xử lý tài liệu → Agent đánh giá kết quả → Gọi công cụ khác nếu cần → Hành động hoặc phản hồi.

Điểm khác biệt quan trọng: truy xuất không còn là bước tiền xử lý vô hình mà trở thành một năng lực mà agent có thể sử dụng. Tài liệu của LangChain mô tả trực tiếp nguyên tắc này: agent có thể dùng một hoặc nhiều công cụ để lấy kiến thức bên ngoài, bao gồm document loader, API và truy vấn cơ sở dữ liệu, thay vì phụ thuộc hoàn toàn vào một chuỗi truy xuất dựng sẵn.

RAG truyền thống so với Agentic RAG

RAG truyền thống	Agentic RAG
Truy xuất xảy ra trước khi sinh	Agent quyết định khi nào truy xuất
Thường dùng một pipeline truy xuất	Có thể dùng nhiều công cụ và nguồn
Truy xuất các đoạn tương tự	Truy xuất thông tin cần cho nhiệm vụ
Thường trả về một câu trả lời	Có thể tiếp tục qua nhiều bước
Luồng truy vấn-ngữ cảnh cố định	Lập kế hoạch và lặp động
Thiết kế chủ yếu cho hỏi đáp	Thiết kế cho suy luận và hành động
Ngữ cảnh chọn theo độ tương tự	Ngữ cảnh chọn theo mức độ liên quan nhiệm vụ
Truy xuất là tầng hạ tầng	Truy xuất là năng lực của agent

Agentic RAG do đó không đơn thuần là RAG có thêm agent. Đó là cách thiết kế khác về mối quan hệ giữa agent, tài liệu và công cụ bên ngoài.

Những hạn chế của RAG vector cố định

RAG dựa trên vector vẫn hữu ích, đặc biệt với các bộ sưu tập văn bản lớn, lâu dài. Nhưng pipeline tiêu chuẩn có một số điểm yếu khi trở thành giải pháp mặc định cho mọi agent.

Chunking có thể phá hủy cấu trúc tài liệu

Chunking chia tài liệu thành các đoạn nhỏ để đánh index và truy xuất. Nhưng tài liệu không tự nhiên là tập hợp các mảnh văn bản tùy ý. Ý nghĩa có thể phụ thuộc vào tiêu đề mục, header bảng, chú thích, đoạn trước, tham chiếu trang, mối quan hệ giữa các hàng, một điều khoản và phần sửa đổi của nó, hoặc vị trí của một giá trị trong biểu mẫu.

Một hàng bảng không có header cột không tương đương với bảng hoàn chỉnh. Một điều khoản hợp đồng không có phần định nghĩa có thể gây hiểu lầm.

Embedding đo độ tương tự, không đo mức liên quan nghiệp vụ

Embedding biểu diễn quan hệ ngữ nghĩa. Chúng có thể nhận diện văn bản giống truy vấn, nhưng tương tự không đồng nghĩa với liên quan đến nhiệm vụ nghiệp vụ. Một agent được hỏi liệu hóa đơn có khớp với đơn mua hàng cần nhà cung cấp, sản phẩm, số lượng, đơn giá, thuế, tổng tiền và tiền tệ. Vector search có thể truy xuất văn bản về cả hai tài liệu, nhưng nó không tự động thực hiện việc so sánh.

Một lần truy xuất có thể không đủ

Một chuỗi RAG cố định giả định rằng một thao tác truy xuất có thể cung cấp ngữ cảnh cần thiết. Agent thường cần nhiều bước: tìm hợp đồng, tìm phần sửa đổi mới nhất, kiểm tra điều khoản gia hạn, so sánh ngày, xác định có cần thông báo không, rồi tạo nhắc nhở.

Vector database làm tăng hạ tầng

• Nạp tài liệu, phân tích cú pháp, chunking và tạo embedding.
• Lưu vector, lọc metadata, cập nhật index và xóa tài liệu.
• Quản lý phiên bản, kiểm soát truy cập và đánh giá truy xuất.
• Xử lý trích dẫn và xử lý lại khi cách phân tích cú pháp thay đổi.

Các framework như LlamaIndex và LangChain đơn giản hóa một phần quy trình này, nhưng không loại bỏ các quyết định kiến trúc bên dưới. Câu hỏi không phải là liệu những công cụ này có giá trị hay không, mà là liệu mọi agent có nên bắt đầu bằng một stack truy xuất vector đầy đủ hay không.

Chunking, embedding và vector database không phải toàn bộ tương lai

Quá đơn giản khi nói rằng vector database, embedding và chunking đã lỗi thời. Chúng vẫn có giá trị cho thư viện tài liệu lớn, cơ sở tri thức doanh nghiệp lâu dài, tìm kiếm ngữ nghĩa, khám phá tương tự, hệ thống gợi ý, bộ sưu tập dài hạn và truy vấn lặp lại khối lượng lớn.

Sự thay đổi thực sự mang tính kiến trúc. Truy xuất vector đang trở thành một công cụ bên trong hệ thống thông tin agentic, không còn là nền tảng phổ quát cho mọi AI agent. Agent sẽ dùng công cụ phù hợp nhất cho từng nhiệm vụ: trích xuất có cấu trúc cho hóa đơn, SQL cho hồ sơ tài chính, API cho dữ liệu kinh doanh trực tiếp, xử lý toàn bộ tài liệu cho file ngắn, so sánh tài liệu cho workflow hồ sơ, knowledge graph cho quan hệ, search index cho truy vấn từ khóa, truy xuất vector cho khám phá ngữ nghĩa, và con người review cho trường hợp mơ hồ.

Agentic RAG là gì?

Agentic RAG là kiến trúc truy xuất trong đó AI agent kiểm soát khi nào và bằng cách nào truy cập thông tin bên ngoài. Agent có thể quyết định liệu truy xuất có cần thiết không, chọn nguồn, đặt câu hỏi con chính xác hơn, truy xuất từ nhiều nguồn, đánh giá kết quả, hỏi tiếp, so sánh đầu ra, phát hiện bằng chứng chưa đủ và dừng lại trước khi thực hiện hành động không được hỗ trợ.

Hướng dẫn về agentic RAG của Microsoft mô tả mẫu này là lập kế hoạch truy vấn động, suy luận nhiều bước và thu thập thông tin tự chủ thay vì một lần truy xuất cố định.

Truy xuất trở thành công cụ

• search_documents() và query_document()
• process_multiple_documents() và compare_documents()
• extract_fields() và query_database()
• search_web(), get_contract_amendment() và request_human_review()

Khi được hỏi liệu hóa đơn có khớp với đơn mua hàng, agent có thể xử lý cả hai file cùng lúc, so sánh nhà cung cấp và tổng tiền, trả về ngoại lệ nếu chúng khác nhau, và yêu cầu review nếu kết quả không rõ ràng.

Sự tiến hóa của RAG cho agent

Giai đoạn một: truy xuất và sinh Truy vấn → Vector search → Các đoạn → Câu trả lời LLM

Giai đoạn hai: truy xuất và xếp hạng lại Truy vấn → Vector search → Reranking → Các đoạn tốt hơn → Câu trả lời LLM

Giai đoạn ba: truy xuất kết hợp Truy vấn → Vector + từ khóa + metadata → Ngữ cảnh kết hợp → Câu trả lời LLM

Giai đoạn bốn: truy xuất agentic Nhiệm vụ → Agent lập kế hoạch → Chọn công cụ → Truy xuất hoặc xử lý → Đánh giá → Lặp → Hành động

Hệ thống không còn xoay quanh một cơ sở dữ liệu. Nó xoay quanh khả năng của agent trong việc sử dụng các công cụ thông tin.

Các giải pháp thay thế RAG dựa trên vector

Cụm từ "giải pháp thay thế RAG" thường gây hiểu lầm vì nhiều giải pháp vẫn cung cấp ngữ cảnh bên ngoài cho mô hình — chúng chỉ dùng cơ chế truy xuất hoặc xử lý khác.

Trích xuất có cấu trúc

Trích xuất có cấu trúc chuyển tài liệu thành các trường agent có thể dùng trực tiếp: nhà cung cấp, tổng tiền, thuế và ngày đến hạn, rồi kiểm tra hợp lệ và tạo bản ghi kế toán. Cách này thường tốt hơn truy xuất đoạn khi workflow phụ thuộc vào các trường đã biết.

Truy vấn tài liệu trực tiếp

Thay vì đánh index tài liệu trước, ứng dụng gửi tài liệu và đặt câu hỏi về nó. Cách này hiệu quả cho file dùng một lần, file người dùng tải lên, hồ sơ tạm thời, tài liệu ngắn và workflow động.

Xử lý đa tài liệu

Nhiều tài liệu có thể được xử lý cùng nhau và so sánh trong một thao tác: hóa đơn, đơn mua hàng và phiếu giao hàng trả về khớp hoặc không khớp. Đây không phải RAG truyền thống mà là thao tác xử lý tài liệu được thiết kế để hiểu quan hệ giữa các file.

Truy xuất dựa trên công cụ, tài liệu đầy đủ, graph và SQL

Agent có thể gọi công cụ truy vấn cơ sở dữ liệu SQL, CRM, API, hệ thống nội bộ, document store, web search và knowledge graph. Tài liệu truy xuất của LangChain làm rõ sự khác biệt: một cơ sở dữ liệu hoặc hệ thống nội bộ hiện có có thể được kết nối như công cụ agent mà không cần xây dựng lại thành cơ sở tri thức vector.

Với tài liệu nhỏ hoặc vừa, gửi biểu diễn tài liệu đầy đủ có cấu trúc có thể đáng tin cậy hơn việc chia thành các đoạn, đặc biệt khi quan hệ giữa các mục quan trọng, bảng cần giữ nguyên, hoặc agent phải so sánh nhiều file. Knowledge graph biểu diễn thực thể và quan hệ mà truy xuất tương tự không nắm bắt tự nhiên. Nhiều câu hỏi doanh nghiệp — hóa đơn quá hạn, hạn mức nhà cung cấp, onboarding chưa hoàn tất — chính xác hơn khi dùng SQL.

RAG trên tài liệu cho agent

RAG trên tài liệu thường bị đồng nhất với việc đưa PDF vào vector database. Đó chỉ là một cách triển khai. Một agent làm việc với tài liệu có thể cần đọc file, trích xuất trường, hỏi tiếp, so sánh tài liệu, theo dõi bằng chứng nguồn, hiểu bảng, phát hiện file thiếu, duy trì ngữ cảnh, tạo nhiệm vụ và chuyển lên khi không chắc chắn.

• extract_document() và query_document()
• process_multiple_documents() và compare_documents()
• get_source_evidence() và detect_missing_information()
• retain_context() và request_review()

Mô hình này gần với cách agent làm việc trong workflow thực tế. Agent được cấp một tập năng lực tài liệu và quyết định cách kết hợp chúng.

Claix và thế hệ RAG tài liệu tiếp theo

Claix có thể được định vị là tầng tài liệu cho agent, dành cho những ai không muốn tự xây dựng mọi thành phần RAG. Thay vì buộc mọi workflow đi qua parse, chunk, embed, store và retrieve, Claix cung cấp các năng lực tài liệu: file sang Markdown có cấu trúc cho ngữ cảnh agent, file sang JSON có cấu trúc cho lệnh gọi công cụ, nhiều file sang so sánh chéo tài liệu, và tài liệu sang ngữ cảnh lâu dài cho câu hỏi tiếp theo.

Ý tưởng cốt lõi không phải là mọi vector database đều lỗi thời, mà là agent thường có thể bắt đầu bằng thao tác tài liệu trực tiếp hơn.

Markdown làm ngữ cảnh agent

Claix có thể chuyển PDF, Excel và CSV, tài liệu Word, hình ảnh, âm thanh, và TXT, HTML hoặc XML thành Markdown có cấu trúc. Markdown có thể giữ tiêu đề, mục, danh sách, bảng, nội dung phiên âm, thứ tự tài liệu và cấu trúc dễ đọc cho con người.

JSON cho hành động, Markdown cho ngữ cảnh

Một kiến trúc thực tế thường dùng cả hai định dạng. Markdown hữu ích khi agent cần hiểu tài liệu. JSON hữu ích khi agent cần gọi hàm hoặc cập nhật hệ thống. Điều này tránh buộc mọi workflow tài liệu phải chọn giữa văn bản phi cấu trúc và schema cứng nhắc ngay từ đầu.

Các giải pháp thay thế LlamaIndex cho agentic RAG

LlamaIndex là framework hữu ích để kết nối mô hình với dữ liệu, xây dựng index và tạo workflow truy xuất. Nó không phải lựa chọn duy nhất và có thể không phải abstraction phù hợp cho mọi agent.

• Gọi công cụ trực tiếp từ mô hình, khi bạn muốn kiểm soát định nghĩa công cụ, trạng thái, quyền, retry và khả năng quan sát.
• LangChain và LangGraph, cho agent graph, workflow phân nhánh, trạng thái lâu dài và node phê duyệt của con người.
• Mastra, cho các nhóm TypeScript xây dựng agent, workflow và truy xuất trong hệ sinh thái JavaScript.
• Haystack, cho xử lý tài liệu Python mô-đun, truy xuất và pipeline agent.
• DSPy, khi thách thức chính là cải thiện prompt, mô-đun suy luận hoặc chiến lược truy xuất một cách có hệ thống.
• Runtime agent tùy chỉnh cộng API tài liệu được quản lý, khi bạn muốn ít tầng abstraction hơn quanh trích xuất, Markdown, JSON và xử lý chéo tài liệu.

Khi nào vector database vẫn hợp lý

Vector database có thể vẫn phù hợp khi bạn có hàng triệu đoạn tài liệu, bộ sưu tập tri thức vĩnh viễn lớn, khối lượng truy vấn cao, tìm kiếm ngữ nghĩa lặp lại, nhiều người dùng truy vấn cùng dữ liệu, lọc phức tạp và chính sách truy cập, yêu cầu đánh index dài hạn, hoặc trải nghiệm tìm kiếm là sản phẩm chính.

Câu hỏi tốt hơn không phải là dùng vector hay agent, mà là nhiệm vụ cần thao tác thông tin nào. Dùng truy xuất vector cho khám phá ngữ nghĩa, trích xuất có cấu trúc cho các trường, xử lý đa tài liệu cho so sánh, SQL cho bản ghi có cấu trúc, API cho dữ liệu trực tiếp và knowledge graph cho quan hệ. Agent có thể điều phối tất cả.

Kiến trúc tốt hơn cho agent tài liệu

Tầng một: trích xuất nhận biết định dạng PDF, Excel, Word, hình ảnh, âm thanh, HTML → Markdown dễ đọc hoặc JSON có cấu trúc.

Tầng hai: thao tác tài liệu Truy vấn, so sánh, trích xuất, kiểm tra hợp lệ, tìm thông tin thiếu, lấy bằng chứng.

Tầng ba: suy luận agent Lập kế hoạch, chọn công cụ, đánh giá kết quả, hỏi tiếp, quyết định có tiếp tục không.

Tầng bốn: hành động nghiệp vụ Tạo bản ghi, phê duyệt, từ chối, thông báo, mở ticket, cập nhật CRM, yêu cầu review.

Tài chính, pháp lý và onboarding

Một pipeline vector cố định có thể phân tích hóa đơn, chunk, embed và hỏi mô hình tổng tiền. Nó không tự động xác minh hóa đơn. Cách tiếp cận tài liệu agentic xử lý hóa đơn cùng đơn mua hàng và phiếu giao hàng, so sánh nhà cung cấp, số lượng và tổng tiền, rồi để agent phê duyệt hoặc chuyển lên.

Một agent pháp lý chỉ truy xuất điều khoản gia hạn tương tự nhất vẫn bỏ sót mối quan hệ giữa hợp đồng, phần sửa đổi và lịch trình. Thao tác hữu ích là trích xuất ngày và nghĩa vụ, so sánh điều khoản gốc và hiện tại, xác định điều khoản đã thay đổi và tạo nhiệm vụ review.

Onboarding khách hàng cũng theo mẫu tương tự: đơn đăng ký, giấy tờ tùy thân và hồ sơ công ty. Thao tác cốt lõi là xác minh chéo tài liệu, không phải tìm kiếm đoạn văn tương tự.

Những sai lầm phổ biến khi xây dựng agentic RAG

• Coi mọi vấn đề tài liệu là tìm kiếm ngữ nghĩa khi workflow cần tổng tiền, ngày tháng hoặc mã định danh.
• Xây vector database trước khi hiểu hành vi tài liệu của sản phẩm.
• Gửi file thô trực tiếp cho mô hình thay vì biểu diễn nhất quán.
• Bỏ qua quan hệ tài liệu: hóa đơn, đơn hàng và phiếu giao hàng thường là một hồ sơ.
• Coi thông tin thiếu là câu trả lời phủ định. Không biết không giống với sai.
• Cho phép hành động không được hỗ trợ trên hệ thống tài chính, pháp lý hoặc khách hàng.
• Che giấu bằng chứng đằng sau kết quả.

Tương lai của RAG cho agent

Tương lai khó có thể là một kiến trúc truy xuất phổ quát duy nhất. Mẫu đang nổi lên là tầng thông tin dẫn dắt bởi công cụ: trích xuất tài liệu, xử lý đa tài liệu, JSON có cấu trúc, ngữ cảnh Markdown, tìm kiếm, SQL, API, knowledge graph và con người review. Vector database và embedding vẫn là một phần của hệ sinh thái này, được chọn cho các nhiệm vụ truy xuất cụ thể thay vì hạ tầng bắt buộc cho mọi agent.

RAG truyền thống truy xuất văn bản tương tự. Agentic RAG cung cấp cho agent các công cụ để có được, so sánh và sử dụng thông tin phù hợp cho nhiệm vụ. Với các nhà phát triển xây dựng agent nhận biết tài liệu, câu hỏi chiến lược không còn là dùng vector database nào, mà là agent nên có thể gọi những năng lực tài liệu và thông tin nào.