GARAGe: Cách Cua AI sử dụng LLM để nâng cao chất lượng RAG bằng cách cải thiện Retrieval

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

Vì sao RAG vẫn chưa đủ? Giới thiệu GARAGe và bài toán Semantic Retrieval

Trong hai năm trở lại đây, sự phát triển của các Large Language Models (LLMs) như GPT, Claude hay Gemini đã thay đổi cách doanh nghiệp xây dựng các hệ thống AI Agent. Những mô hình này có thể hiểu ngôn ngữ tự nhiên, lập luận trên nhiều bước và tạo ra câu trả lời gần giống con người.

Tuy nhiên, khi AI Agent được đưa vào môi trường doanh nghiệp, một thực tế nhanh chóng xuất hiện: khả năng của LLM không đồng nghĩa với khả năng trả lời chính xác.

Một AI Agent có thể sử dụng mô hình mạnh nhất hiện nay nhưng vẫn đưa ra câu trả lời sai, thiếu thông tin hoặc thậm chí "bịa" nội dung (hallucination). Trong phần lớn trường hợp, nguyên nhân không nằm ở bản thân mô hình mà nằm ở dữ liệu được cung cấp cho mô hình.

Đây cũng là lý do khiến kiến trúc Retrieval-Augmented Generation (RAG) trở thành nền tảng của hầu hết AI Agent doanh nghiệp hiện nay.

Nhưng liệu RAG đã thực sự giải quyết được bài toán truy xuất tri thức?

Câu trả lời là chưa hoàn toàn.

Đó chính là lý do Ada giới thiệu một hướng tiếp cận mới mang tên GARAGe (Generative-Augmented Retrieval-Augmented Generation).

Khác với RAG truyền thống, GARAGe không chỉ tối ưu quá trình sinh câu trả lời (Generation), mà còn tập trung cải thiện chính bước Retrieval — thành phần quyết định AI Agent có tìm được đúng ngữ cảnh trước khi suy luận hay không.

Khi vấn đề không nằm ở LLM

Trong cộng đồng AI hiện nay, rất nhiều cuộc thảo luận xoay quanh việc làm thế nào để AI chính xác hơn.

Các hướng tiếp cận phổ biến bao gồm:

Tất cả những yếu tố này đều quan trọng.

Tuy nhiên, chúng chưa giải quyết được một vấn đề nền tảng hơn:

Một LLM chỉ có thể đưa ra câu trả lời tốt khi nó được cung cấp đúng thông tin để suy luận.

LLM không tự truy cập cơ sở dữ liệu của doanh nghiệp.

Nó không biết tài liệu nội bộ.

Nó không biết quy trình vận hành mới nhất.

Nó cũng không biết chính sách vừa được cập nhật cách đây vài phút.

Nếu không được cung cấp đúng ngữ cảnh, mô hình sẽ phải suy luận dựa trên kiến thức đã học trong quá trình huấn luyện, hoặc tệ hơn là tạo ra câu trả lời nghe có vẻ hợp lý nhưng không đúng với thực tế của doanh nghiệp.

Điều này dẫn đến một nguyên tắc quan trọng trong thiết kế AI Agent:

Garbage In, Garbage Out.

Nếu Retrieval cung cấp sai ngữ cảnh, thì dù sử dụng GPT-5, Claude Opus hay bất kỳ LLM tiên tiến nào, kết quả cuối cùng vẫn sẽ không đáng tin cậy.

Nói cách khác, chất lượng của AI Agent không chỉ được quyết định bởi Generation, mà còn bởi Retrieval.

RAG ra đời để giải quyết vấn đề gì?

Trước khi RAG xuất hiện, phần lớn ứng dụng AI đều dựa hoàn toàn vào kiến thức đã được mô hình học trong giai đoạn huấn luyện.

Điều này tạo ra nhiều hạn chế.

Ví dụ:

Một ngân hàng cập nhật quy định mở tài khoản.

Một sàn thương mại điện tử thay đổi chính sách hoàn tiền.

Một công ty SaaS phát hành tính năng mới.

Một doanh nghiệp sửa đổi quy trình vận hành nội bộ.

LLM hoàn toàn không biết những thay đổi này.

Muốn AI trả lời đúng, doanh nghiệp chỉ có hai lựa chọn:

Cả hai đều tốn kém, mất thời gian và không phù hợp với dữ liệu thay đổi liên tục.

RAG được tạo ra để giải quyết chính bài toán đó.

Thay vì yêu cầu mô hình "ghi nhớ" toàn bộ kiến thức của doanh nghiệp, RAG cho phép AI truy xuất thông tin tại thời điểm người dùng đặt câu hỏi.

Quy trình hoạt động của RAG khá đơn giản:

Nhờ vậy, AI không còn phụ thuộc hoàn toàn vào dữ liệu đã được huấn luyện từ nhiều tháng hoặc nhiều năm trước.

Nó có thể sử dụng thông tin mới nhất trong Knowledge Base để trả lời người dùng.

Đó chính là ý nghĩa của cái tên Retrieval-Augmented Generation — quá trình sinh câu trả lời (Generation) được tăng cường bằng khả năng truy xuất thông tin (Retrieval).

Nhưng Retrieval không đơn giản như chúng ta nghĩ

Sau khi triển khai RAG ở quy mô lớn, nhiều doanh nghiệp nhận ra một vấn đề.

Họ đã có:

Nhưng AI Agent vẫn trả lời sai.

Lỗi không nằm ở mô hình.

Lỗi nằm ở Retrieval.

Cụ thể hơn, hệ thống không tìm được đúng tài liệu cần thiết.

Đây là vấn đề mà Ada gọi là Semantic Retrieval.

Hay nói cách khác:

Retrieval không chỉ là tìm tài liệu giống từ khóa nhất, mà là tìm tài liệu có cùng ý nghĩa với điều người dùng đang muốn hỏi.

Đó là hai bài toán hoàn toàn khác nhau.

Semantic Mismatch – Khoảng cách giữa cách người dùng hỏi và cách doanh nghiệp lưu trữ tri thức

Đây là nguyên nhân cốt lõi khiến nhiều hệ thống RAG hoạt động chưa hiệu quả.

Mặc dù Embedding đã giúp Retrieval vượt xa phương pháp tìm kiếm theo từ khóa (Keyword Search), nhưng Embedding vẫn phải so sánh hai đối tượng:

Vấn đề là hai đối tượng này hiếm khi được viết theo cùng một cách.

Ví dụ, một khách hàng có thể hỏi:

"Làm sao đổi thẻ ATM?"

Trong khi tài liệu nội bộ lại có tiêu đề:

"Quy trình thay thế thẻ thanh toán bị mất hoặc hư hỏng."

Về mặt ngữ nghĩa, hai câu này nói về cùng một vấn đề.

Nhưng cách diễn đạt lại hoàn toàn khác.

Không chỉ vậy, sự khác biệt còn xuất hiện ở nhiều khía cạnh khác:

Người dùng đặt câu hỏi ngắn

Ví dụ:

"Hoàn tiền bao lâu?"

Trong khi tài liệu có thể dài hàng nghìn từ.

Người dùng sử dụng ngôn ngữ đời thường

Ví dụ:

"Ví bị khóa."

Trong khi tài liệu ghi:

"Tài khoản bị tạm ngừng do vi phạm điều khoản sử dụng."

Người dùng hỏi theo ngôi thứ nhất

Ví dụ:

"Tôi muốn hủy đơn."

Trong khi tài liệu được viết dưới dạng:

"Khách hàng có thể hủy đơn hàng khi..."

Người dùng quan tâm đến mục tiêu

Ví dụ:

"Làm sao lấy lại tiền?"

Trong khi tài liệu được tổ chức theo quy trình:

Không có đoạn nào trả lời trực tiếp đúng cách người dùng hỏi.

Đây chính là hiện tượng Semantic Mismatch.

Embedding có thể nhận ra một phần sự tương đồng.

Nhưng trong nhiều trường hợp, khoảng cách ngữ nghĩa vẫn quá lớn khiến Retrieval trả về những chunk chưa thực sự phù hợp.

Một LLM mạnh cũng không thể cứu Retrieval yếu

Đây là điểm quan trọng nhất.

Khi AI Agent nhận được sai ngữ cảnh, mọi bước suy luận phía sau đều bị ảnh hưởng.

LLM không có khả năng tự biết rằng:

Đối với LLM, những gì Retrieval cung cấp chính là "sự thật" để nó dựa vào lập luận.

Điều đó dẫn đến một kết luận quan trọng:

Generation chỉ tốt khi Retrieval đủ tốt.

Nói cách khác, hiệu quả của AI Agent không bắt đầu từ mô hình ngôn ngữ, mà bắt đầu từ khả năng tìm đúng tri thức trước khi mô hình sinh câu trả lời.

Đó cũng là lý do Ada đặt ra một câu hỏi hoàn toàn khác:

Nếu vấn đề nằm ở Retrieval, tại sao chúng ta chỉ tập trung cải thiện Generation?

Thay vì chờ người dùng đặt câu hỏi rồi mới tìm tài liệu, liệu có thể sử dụng chính sức mạnh của LLM để chuẩn bị trước quá trình Retrieval?

Đây chính là ý tưởng nền tảng dẫn đến sự ra đời của GARAGe (Generative-Augmented Retrieval-Augmented Generation).

Trong phần tiếp theo, chúng ta sẽ đi sâu vào cách GARAGe thay đổi kiến trúc RAG truyền thống bằng cách sử dụng Generation để tối ưu Retrieval, đồng thời phân tích cơ chế GARAGe Index, Offline Question Generation và Two-hop Retrieval – những thành phần tạo nên sự khác biệt của kiến trúc này.

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.

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