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 3
GARAGe: Khi Retrieval quyết định chất lượng của AI Agent (Phần 3)
Phân tích chuyên sâu 5 cơ chế cốt lõi giúp GARAGe vượt qua giới hạn của RAG truyền thống
Ở phần trước, chúng ta đã tìm hiểu kiến trúc của GARAGe và cách hệ thống sử dụng Generation để cải thiện Retrieval. Thay vì truy xuất trực tiếp từ tài liệu, GARAGe chủ động tạo ra các câu hỏi đại diện, xây dựng GARAGe Index và áp dụng cơ chế Two-hop Retrieval để đưa LLM đến đúng ngữ cảnh trước khi sinh câu trả lời.
Tuy nhiên, kiến trúc chỉ là một phần của câu chuyện.
Điều thực sự tạo nên giá trị của GARAGe nằm ở năm cơ chế nền tảng giúp hệ thống cải thiện khả năng truy xuất tri thức trong môi trường sản xuất (production).
Đây không chỉ là những tối ưu kỹ thuật. Chúng phản ánh một thay đổi trong cách thiết kế AI Agent: thay vì cố gắng làm cho LLM "thông minh hơn", GARAGe tập trung làm cho quá trình Retrieval "đúng hơn".
1. Two-hop Retrieval: Từ tìm kiếm tài liệu sang tìm kiếm ý định
Đây là nền tảng quan trọng nhất của GARAGe.
Trong RAG truyền thống, khi người dùng gửi một truy vấn, hệ thống sẽ thực hiện một phép so khớp trực tiếp giữa embedding của câu hỏi và embedding của các chunk trong Knowledge Base.
Luồng xử lý có thể biểu diễn như sau:
User Query → Embedding → Vector Search → Document Chunk → LLM
Mô hình embedding sẽ tìm các chunk có khoảng cách vector gần nhất, giả định rằng khoảng cách ngữ nghĩa nhỏ đồng nghĩa với việc chunk đó chứa câu trả lời phù hợp.
Trong nhiều trường hợp, giả định này hoạt động tốt.
Tuy nhiên, trong môi trường doanh nghiệp, điều này không phải lúc nào cũng đúng.
Ví dụ, khách hàng hỏi:
"Làm sao mở lại tài khoản?"
Trong Knowledge Base, thông tin có thể được lưu dưới tiêu đề:
"Quy trình kích hoạt lại tài khoản sau khi bị tạm khóa do xác minh danh tính."
Hai câu này nói về cùng một nghiệp vụ.
Nhưng cách diễn đạt khác nhau đáng kể.
Nếu embedding không đủ mạnh để nhận diện sự tương đồng này, Retrieval sẽ bỏ sót tài liệu đúng hoặc chỉ truy xuất được những đoạn có liên quan một phần.
GARAGe giải quyết vấn đề bằng cách bổ sung một lớp trung gian.
Luồng xử lý trở thành:
User Query → Synthetic Question → Semantic Answer → LLM
Hay chính xác hơn:
User Query → Embedding → GARAGe Index → Question Matching → Semantic Chunk → LLM
Thay vì tìm tài liệu ngay lập tức, hệ thống trước tiên xác định:
"Người dùng đang hỏi giống với câu hỏi nào mà chúng ta đã dự đoán trước?"
Sau khi xác định được câu hỏi gần nghĩa nhất, hệ thống mới truy xuất câu trả lời hoặc semantic chunk tương ứng.
Đây chính là Two-hop Retrieval.
Bước đầu tiên xác định ý định (intent).
Bước thứ hai truy xuất tri thức (knowledge).
Việc tách hai nhiệm vụ này giúp cải thiện đáng kể độ chính xác của Retrieval, đặc biệt trong những trường hợp người dùng sử dụng ngôn ngữ tự nhiên, từ viết tắt, tiếng lóng hoặc cách diễn đạt không giống tài liệu nội bộ.
Có thể xem lớp câu hỏi tổng hợp (Synthetic Questions) như một semantic bridge – cây cầu nối giữa ngôn ngữ của người dùng và cấu trúc tri thức của doanh nghiệp.
2. Optimal Semantic Chunks: Từ chia tài liệu sang tổ chức tri thức
Một trong những bài toán khó nhất khi triển khai RAG là Chunking.
Để thực hiện Retrieval, tài liệu thường được chia thành nhiều đoạn nhỏ.
Nghe có vẻ đơn giản, nhưng việc xác định ranh giới của mỗi chunk lại ảnh hưởng trực tiếp đến chất lượng của toàn bộ hệ thống.
Nếu chunk quá nhỏ:
Nếu chunk quá lớn:
Không có một kích thước chunk tối ưu cho mọi loại tài liệu.
Đó là lý do vì sao chunking luôn là một trong những bước khó tối ưu nhất trong RAG.
GARAGe thay đổi hoàn toàn cách tiếp cận.
Thay vì coi chunk là đơn vị cơ bản để Retrieval, GARAGe coi câu trả lời mới là đơn vị tri thức.
Trong quá trình xử lý ngoại tuyến, LLM có thể:
Kết quả là mỗi semantic answer không còn bị giới hạn bởi ranh giới vật lý của tài liệu.
Điều này rất quan trọng.
Trong RAG truyền thống, cấu trúc của tài liệu quyết định cấu trúc Retrieval.
Trong GARAGe, ý nghĩa của tri thức mới quyết định cách Retrieval hoạt động.
Đó là lý do Ada gọi đây là Optimal Semantic Chunks.
Đơn vị được truy xuất không phải là "đoạn văn", mà là một đơn vị tri thức hoàn chỉnh về mặt ngữ nghĩa.
3. Offline Preprocessing: Chuyển chi phí tính toán sang trước thời điểm truy vấn
Một trong những ưu điểm lớn nhất của GARAGe là khả năng xử lý phần lớn công việc trước khi người dùng gửi truy vấn.
Trong RAG truyền thống, nhiều bước vẫn phải thực hiện trong thời gian thực:
Khi số lượng tài liệu tăng lên hàng triệu bản ghi, chi phí tính toán và độ trễ cũng tăng theo.
GARAGe chuyển phần lớn khối lượng công việc sang giai đoạn offline.
Khi Knowledge Base được nhập hoặc cập nhật, hệ thống sẽ:
Quá trình này có thể mất nhiều thời gian và tài nguyên tính toán.
Nhưng nó chỉ diễn ra khi dữ liệu thay đổi.
Khi AI Agent vận hành thực tế, quy trình được rút gọn đáng kể:
Điều này mang lại ba lợi ích quan trọng.
Thứ nhất, giảm độ trễ (latency) vì hệ thống không phải xử lý nhiều bước phức tạp tại thời điểm truy vấn.
Thứ hai, giảm chi phí suy luận, đặc biệt với các hệ thống xử lý hàng chục nghìn hoặc hàng triệu truy vấn mỗi ngày.
Thứ ba, tăng khả năng mở rộng (scalability) vì khối lượng công việc nặng đã được chuyển sang giai đoạn chuẩn bị dữ liệu.
Đây là một tư duy quen thuộc trong khoa học máy tính: nếu có thể dự đoán trước công việc cần làm, hãy xử lý trước thay vì đợi đến thời gian chạy (runtime).
4. Feedback Mechanism: Retrieval có khả năng học hỏi từ dữ liệu thực tế
Knowledge Base không phải là một tập dữ liệu bất biến.
Quy trình nghiệp vụ thay đổi.
Sản phẩm mới được phát hành.
Chính sách được cập nhật.
Ngôn ngữ của khách hàng cũng thay đổi theo thời gian.
Điều này đồng nghĩa với việc Retrieval không thể chỉ được xây dựng một lần rồi giữ nguyên mãi mãi.
GARAGe được thiết kế để liên tục cải thiện thông qua Feedback Mechanism.
Trong môi trường production, AI Manager có thể quan sát:
Nếu phát hiện một truy vấn chưa được xử lý tốt, AI Manager có thể:
Ở các lần truy vấn sau, hệ thống sẽ nhận diện tốt hơn những câu hỏi tương tự.
Điểm đáng chú ý là GARAGe không cần huấn luyện lại toàn bộ LLM để cải thiện chất lượng.
Phần lớn sự cải thiện diễn ra ở tầng Retrieval.
Điều này phù hợp với thực tế vận hành AI doanh nghiệp, nơi Knowledge Base thay đổi thường xuyên hơn nhiều so với bản thân mô hình ngôn ngữ.
Theo thời gian, GARAGe tạo ra một vòng lặp tích cực:
Production Queries → Human Feedback → Updated GARAGe Index → Better Retrieval → Better Answers
Hệ thống càng được sử dụng nhiều, chất lượng Retrieval càng được cải thiện.
5. Negative Indexing: Quản lý cả những gì hệ thống chưa biết
Đây có lẽ là ý tưởng thú vị nhất trong GARAGe.
Hầu hết các hệ thống Retrieval chỉ quan tâm đến việc:
"Tài liệu nào phù hợp nhất?"
GARAGe đặt thêm một câu hỏi khác:
"Có phải Knowledge Base hiện tại chưa đủ để trả lời truy vấn này?"
Nếu truy vấn của người dùng không đủ tương đồng với bất kỳ câu hỏi nào trong GARAGe Index, hệ thống không cố gắng "đoán" một câu trả lời.
Thay vào đó, truy vấn được đánh dấu là một Knowledge Gap.
Đây chính là cơ chế Negative Indexing.
Nó giúp hệ thống nhận diện những khoảng trống trong cơ sở tri thức.
Ví dụ:
Những truy vấn này sẽ được thu thập và chuyển cho AI Manager xem xét.
Từ đó doanh nghiệp có thể:
Điểm đáng giá của Negative Indexing là nó biến thất bại của Retrieval thành nguồn dữ liệu để cải thiện hệ thống.
Thay vì chỉ đo lường tỷ lệ trả lời đúng, doanh nghiệp còn biết chính xác AI Agent chưa biết điều gì.
Đây là một lợi thế rất lớn khi triển khai AI Agent trong các lĩnh vực có yêu cầu cao về độ chính xác như ngân hàng, bảo hiểm, y tế hoặc dịch vụ khách hàng.
GARAGe không chỉ cải thiện Retrieval, mà còn thay đổi cách doanh nghiệp xây dựng Knowledge Base
Nếu nhìn tổng thể, năm cơ chế trên đều hướng tới cùng một mục tiêu:
đưa Retrieval đến gần hơn với cách con người suy nghĩ và đặt câu hỏi.
Trong RAG truyền thống, Knowledge Base được xây dựng xoay quanh tài liệu.
Trong GARAGe, Knowledge Base được tái cấu trúc xoay quanh ý định của người dùng.
Đây là một thay đổi quan trọng về tư duy kiến trúc.
Doanh nghiệp không còn chỉ lưu trữ thông tin, mà còn chủ động xây dựng các "điểm truy cập ngữ nghĩa" để AI Agent có thể tìm thấy đúng tri thức vào đúng thời điểm.
Nhờ đó, LLM không cần phải bù đắp cho những thiếu sót của Retrieval. Thay vào đó, mô hình được cung cấp một ngữ cảnh đầy đủ, chính xác và nhất quán ngay từ đầu.
Trong phần cuối của loạt bài, chúng ta sẽ đánh giá GARAGe dưới góc nhìn kiến trúc AI doanh nghiệp, so sánh trực tiếp với RAG truyền thống, phân tích các trường hợp triển khai phù hợp và thảo luận liệu GARAGe có phải là bước tiến tiếp theo của Retrieval-Augmented Generation hay không.
Bạn muốn triển khai giải pháp này?
Chúng tôi tư vấn và đo đạc trực tiếp dựa trên hiện trạng doanh nghiệp.
