GARAGe: Cách tiếp cận mới giúp AI Agent truy xuất thông tin chính xác hơn RAG truyền thống - Phần 2

GARAGe: Khi Retrieval quyết định chất lượng của AI Agent (Phần 2)

Kiến trúc GARAGe: Khi Generation được sử dụng để tối ưu Retrieval

Trong phần trước, chúng ta đã thấy rằng hạn chế lớn nhất của RAG truyền thống không nằm ở mô hình ngôn ngữ (LLM), mà nằm ở khả năng Retrieval.

RAG giúp AI Agent truy xuất thông tin từ Knowledge Base thay vì chỉ dựa vào kiến thức đã học. Tuy nhiên, Retrieval vẫn phải giải quyết một bài toán rất khó: làm sao hiểu đúng ý định của người dùng khi cách họ đặt câu hỏi hoàn toàn khác với cách tri thức được lưu trữ trong tài liệu?

Đây chính là nguyên nhân tạo ra hiện tượng Semantic Mismatch.

Thay vì tiếp tục tối ưu mô hình embedding hay thử các chiến lược chunking phức tạp hơn, Ada đặt ra một câu hỏi khác:

Nếu LLM có khả năng hiểu tài liệu rất tốt, tại sao không tận dụng chính khả năng đó để chuẩn bị trước cho quá trình Retrieval?

Từ câu hỏi này, GARAGe ra đời.

Khác với RAG truyền thống, GARAGe không chờ đến khi người dùng gửi truy vấn mới bắt đầu tìm kiếm dữ liệu. Thay vào đó, hệ thống sử dụng LLM để chuẩn bị trước toàn bộ "điểm truy cập" vào Knowledge Base ngay từ giai đoạn xây dựng dữ liệu.

Đây là lý do Ada gọi phương pháp này là Generation-first Retrieval.

Ý tưởng cốt lõi của GARAGe

Để hiểu GARAGe, hãy bắt đầu bằng một câu hỏi rất đơn giản.

Giả sử Knowledge Base của doanh nghiệp có một tài liệu hướng dẫn dài 20 trang về quy trình hoàn tiền.

Một khách hàng có thể hỏi:

Năm câu hỏi trên có cách diễn đạt khác nhau nhưng đều hướng tới cùng một ý định.

Trong RAG truyền thống, hệ thống sẽ đợi từng câu hỏi xuất hiện rồi cố gắng tìm các chunk có nội dung gần nhất.

Trong GARAGe, hệ thống làm điều ngược lại.

Ngay từ khi tài liệu được đưa vào Knowledge Base, LLM sẽ đọc tài liệu và chủ động tạo ra những câu hỏi mà người dùng có khả năng sẽ đặt.

Thay vì chỉ lưu trữ tài liệu, GARAGe còn lưu trữ cách con người sẽ hỏi về tài liệu đó.

Đây là khác biệt mang tính nền tảng.

Knowledge Base không còn chỉ là tập hợp các tài liệu.

Nó trở thành tập hợp các ý định (intent) mà người dùng có thể có.

Từ tài liệu đến GARAGe Index

Quá trình xây dựng GARAGe diễn ra hoàn toàn ở chế độ offline.

Đây là giai đoạn mà doanh nghiệp nhập mới hoặc cập nhật Knowledge Base.

Luồng xử lý có thể mô tả như sau.

Bước 1. Đưa tài liệu vào LLM

Khi một tài liệu mới được thêm vào Knowledge Base, tài liệu đó sẽ được gửi tới LLM.

Khác với RAG truyền thống chỉ chia tài liệu thành các chunk, LLM sẽ đọc và hiểu toàn bộ nội dung.

Mục tiêu không phải là tạo câu trả lời ngay.

Mục tiêu là hiểu tài liệu dưới góc nhìn của người dùng.

LLM sẽ xác định:

Có thể xem đây là quá trình chuyển đổi từ document-centric sang user-centric.

Tri thức không còn được tổ chức theo cấu trúc tài liệu mà theo nhu cầu thông tin của người dùng.

Bước 2. Sinh các cặp Question – Answer

Sau khi hiểu nội dung, LLM sẽ tự động sinh ra nhiều cặp Question – Answer.

Ví dụ một tài liệu về hoàn tiền có thể tạo ra hàng chục hoặc hàng trăm câu hỏi như:

Điểm quan trọng là những câu hỏi này không nhất thiết phải xuất hiện trong tài liệu gốc.

Chúng được tạo ra dựa trên khả năng hiểu ngữ nghĩa và suy luận của LLM.

Nói cách khác, LLM đang mô phỏng cách khách hàng sẽ tương tác với Knowledge Base.

Đây là điều mà RAG truyền thống không thực hiện.

Bước 3. Xây dựng câu trả lời tối ưu

Sau khi sinh câu hỏi, GARAGe không đơn giản lấy nguyên văn một đoạn tài liệu làm câu trả lời.

Thay vào đó, hệ thống có thể:

Điều này rất quan trọng.

Trong RAG truyền thống, chất lượng Retrieval phụ thuộc nhiều vào cách tài liệu được chia thành chunk.

Nếu thông tin nằm ở nhiều đoạn khác nhau, Retrieval có thể chỉ lấy được một phần.

GARAGe giải quyết vấn đề ngay từ đầu bằng cách tạo ra một câu trả lời hoàn chỉnh về mặt ngữ nghĩa, thay vì phụ thuộc vào ranh giới của các chunk.

Đó là lý do Ada gọi đây là Optimal Semantic Chunks.

Đơn vị lưu trữ không còn là "đoạn văn", mà là đơn vị tri thức hoàn chỉnh.

Bước 4. Tạo Embedding cho câu hỏi

Sau khi các cặp Question – Answer được tạo xong, hệ thống sẽ tạo embedding cho từng câu hỏi.

Lưu ý rằng embedding được tạo cho câu hỏi, không phải cho tài liệu.

Điều này có ý nghĩa rất lớn.

Embedding giờ đây đại diện cho ý định của người dùng, thay vì chỉ đại diện cho nội dung tài liệu.

Nhờ vậy, quá trình so khớp sau này sẽ gần với cách con người đặt câu hỏi hơn.

Bước 5. Xây dựng GARAGe Index

Các embedding của câu hỏi được lưu vào một chỉ mục riêng gọi là GARAGe Index.

Khác với Vector Database trong RAG truyền thống, GARAGe Index không lưu trữ các đoạn tài liệu như những điểm truy xuất chính.

Nó lưu trữ các câu hỏi đại diện cho ý định của người dùng.

Mỗi câu hỏi trong GARAGe Index sẽ liên kết với:

Có thể hình dung GARAGe Index như một lớp ngữ nghĩa nằm giữa người dùng và Knowledge Base.

Đây chính là điểm khác biệt lớn nhất của GARAGe.

Runtime: Điều gì xảy ra khi người dùng gửi truy vấn?

Khi AI Agent đi vào vận hành, quy trình Retrieval thay đổi đáng kể.

Thay vì tìm trực tiếp các chunk trong Knowledge Base, hệ thống sẽ thực hiện theo hai bước.

Bước 1. So khớp với câu hỏi trong GARAGe Index

Truy vấn của người dùng được chuyển thành embedding.

Embedding này không được dùng để tìm đoạn tài liệu ngay lập tức.

Thay vào đó, hệ thống tìm những câu hỏi trong GARAGe Index có ý nghĩa gần nhất.

Nói cách khác, hệ thống đang trả lời câu hỏi:

"Người dùng hiện tại đang hỏi giống với câu hỏi nào mà chúng ta đã dự đoán trước?"

Đây là một thay đổi rất lớn về mặt tư duy.

Thay vì so sánh người dùng với tài liệu, GARAGe so sánh người dùng với một tập hợp các ý định đã được LLM xây dựng từ trước.

Bước 2. Ánh xạ tới câu trả lời

Sau khi tìm được câu hỏi gần nghĩa nhất, hệ thống chỉ cần lấy semantic chunk hoặc câu trả lời đã liên kết với câu hỏi đó.

LLM nhận được một ngữ cảnh đã được chuẩn bị trước, đầy đủ và sát với ý định của người dùng.

Lúc này, Generation chỉ còn là bước diễn đạt lại câu trả lời theo ngữ cảnh hội thoại.

Phần khó nhất – hiểu người dùng cần thông tin gì và lấy đúng tri thức nào – đã được giải quyết ngay từ bước Retrieval.

Two-hop Retrieval: Lớp trung gian giúp cải thiện độ chính xác

Ada gọi kiến trúc này là Two-hop Retrieval.

Tên gọi xuất phát từ việc hệ thống không còn truy xuất trực tiếp từ:

User Query → Document Chunk

mà chuyển thành:

User Query → Synthetic Question → Semantic Answer

Hay nói cách khác, Retrieval diễn ra qua hai "bước nhảy" (hop).

Bước nhảy đầu tiên xác định ý định.

Bước nhảy thứ hai mới truy xuất tri thức.

Lớp trung gian này đóng vai trò như một semantic translator – một bộ phiên dịch ngữ nghĩa giữa cách người dùng diễn đạt và cách doanh nghiệp lưu trữ tri thức.

Đây là điểm mà RAG truyền thống thường gặp khó khăn, đặc biệt trong các lĩnh vực có ngôn ngữ chuyên ngành như tài chính, bảo hiểm, ngân hàng, y tế hoặc pháp lý.

Generation không còn là đích đến, mà là công cụ để cải thiện Retrieval

Một điểm thú vị của GARAGe là cách nhìn về vai trò của LLM.

Trong RAG truyền thống, LLM chủ yếu được sử dụng ở giai đoạn cuối để tạo câu trả lời.

Trong GARAGe, LLM được đưa vào ngay từ đầu của quy trình.

Nó không chỉ tạo câu trả lời mà còn:

Nói cách khác, LLM không chỉ là Answer Generator mà còn trở thành Knowledge Architect – thành phần giúp tổ chức lại tri thức theo cách mà người dùng thực sự sẽ tìm kiếm.

Đó cũng chính là ý nghĩa của tên gọi Generative-Augmented Retrieval-Augmented Generation.

Generation không còn chỉ là bước cuối cùng trong quy trình. Nó được đưa lên phía trước để tăng cường cho Retrieval, từ đó tạo nền tảng cho những câu trả lời chính xác hơn khi AI Agent vận hành trong thực tế.

Phần tiếp theo sẽ đi sâu vào năm ưu điểm cốt lõi của GARAGe, bao gồm Two-hop Retrieval, Optimal Semantic Chunks, Offline Preprocessing, Feedback Mechanism và Negative Indexing, đồng thời phân tích vì sao những cơ chế này giúp GARAGe vượt qua các hạn chế vốn có của RAG truyền thống.

Đọc tiếp Phần 3: 5 cơ chế cốt lõi của GARAGe