Quay lại trang Blog
Kỹ thuật

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 1

Viết bởi: Đội ngũ chuyên gia Cua AI
2026-07-03
Thời lượng: 5 phút đọc
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 1
Khám phá công nghệ GARAGe - một hướng tiếp cận mới giúp nâng cao chất lượng RAG truyền thống cho các AI Agent doanh nghiệp.

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:

sử dụng mô hình lớn hơn;
tăng số lượng tham số;
mở rộng cửa sổ ngữ cảnh (Context Window);
cải thiện khả năng suy luận (Reasoning);
giảm hiện tượng Hallucination.

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:

huấn luyện lại mô hình;
hoặc tinh chỉnh (Fine-tuning).

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:

1.Tài liệu được đưa vào Knowledge Base.
2.Mỗi tài liệu được chia thành nhiều đoạn nhỏ (chunks).
3.Các chunk được chuyển thành vector thông qua mô hình Embedding.
4.Các vector được lưu trong Vector Database.
5.Khi người dùng gửi truy vấn, truy vấn cũng được chuyển thành embedding.
6.Hệ thống tìm những chunk có embedding gần nhất.
7.Các chunk đó được đưa vào Context của LLM.
8.LLM tạo câu trả lời dựa trên thông tin vừa truy xuất.

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ó:

LLM rất mạnh.
Embedding rất tốt.
Vector Database hiện đại.
Knowledge Base đầy đủ.

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:

câu hỏi của người dùng;
nội dung trong Knowledge Base.

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:

Điều kiện hoàn tiền.
Quy trình xử lý.
Thời gian hoàn tiền.
Trường hợp ngoại lệ.

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:

Retrieval vừa lấy nhầm tài liệu.
Một đoạn quan trọng đang bị thiếu.
Context chưa đầy đủ.
Có một tài liệu khác phù hợp hơn nhưng chưa được truy xuất.

Đố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 GenerationTwo-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.


Đọc tiếp Phần 2: Kiến trúc GARAGe

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.

Liên Hệ Tư Vấn