Trong vài năm gần đây, Large Language Models (LLMs) đã thay đổi cách chúng ta xây dựng phần mềm. Các mô hình hiện đại có thể viết code, tóm tắt tài liệu, phân tích dữ liệu và hỗ trợ giải quyết nhiều bài toán phức tạp. Tuy nhiên, khi triển khai trong môi trường doanh nghiệp, một giới hạn quan trọng nhanh chóng xuất hiện: mô hình không sở hữu tri thức mà doanh nghiệp thực sự cần.

Dữ liệu sản phẩm, tài liệu nội bộ, quy trình vận hành hay thông tin khách hàng đều liên tục thay đổi. Trong khi đó, kiến thức của LLM lại được cố định tại thời điểm huấn luyện. Khoảng cách giữa năng lực suy luận của mô hình và khả năng tiếp cận tri thức thực tế đã tạo ra nhu cầu cho một kiến trúc mới: Retrieval-Augmented Generation (RAG).

Thay vì coi mô hình là nguồn tri thức duy nhất, RAG tách biệt giữa khả năng suy luận và nguồn dữ liệu, cho phép hệ thống truy xuất thông tin từ các nguồn bên ngoài trước khi sinh câu trả lời. Cách tiếp cận này nhanh chóng trở thành tiêu chuẩn cho các hệ thống AI doanh nghiệp hiện đại.

Kiến trúc RAG hoạt động như thế nào?

Mặc dù có nhiều biến thể khác nhau, phần lớn hệ thống RAG đều được xây dựng dựa trên hai pipeline độc lập.

Knowledge Ingestion Pipeline

Đây là giai đoạn chuyển đổi dữ liệu thô thành tri thức có thể tìm kiếm.

Nguồn dữ liệu có thể đến từ PDF, Wiki nội bộ, Database, API, tài liệu nghiệp vụ hoặc hệ thống ticket hỗ trợ khách hàng. Trước khi được sử dụng, dữ liệu cần trải qua một chuỗi xử lý gồm:

Extraction → Chunking → Embedding → Indexing

Kết quả cuối cùng là một kho tri thức được lưu trữ trong Vector Database và sẵn sàng cho việc truy xuất.

Trên thực tế, chất lượng của hệ thống RAG thường được quyết định ngay từ giai đoạn này. Một pipeline indexing được thiết kế kém sẽ dẫn đến chất lượng retrieval thấp, bất kể mô hình hay prompt có được tối ưu đến đâu.

Query Pipeline

Khi người dùng gửi câu hỏi, hệ thống bắt đầu quá trình truy xuất thông tin.

Thay vì chuyển trực tiếp câu hỏi tới LLM, truy vấn sẽ được chuyển đổi thành embedding vector và đối chiếu với dữ liệu đã được lập chỉ mục. Những tài liệu phù hợp nhất được lựa chọn, sắp xếp lại theo mức độ liên quan và đưa vào context trước khi mô hình tạo ra câu trả lời cuối cùng.

Ở mức độ khái quát, toàn bộ quy trình có thể được mô tả bằng ba bước:

Retrieve → Rank → Generate

Nghe có vẻ đơn giản, nhưng phần lớn thách thức trong các hệ thống RAG đều nằm bên trong từng bước này.

Chunking: Quyết định thiết kế quan trọng nhất của RAG

Khi bắt đầu xây dựng RAG, nhiều nhóm kỹ thuật thường tập trung vào việc lựa chọn Vector Database hoặc Embedding Model. Tuy nhiên, trong thực tế, yếu tố ảnh hưởng lớn nhất tới chất lượng retrieval lại là cách dữ liệu được chia nhỏ.

Chunking quyết định đơn vị thông tin nào sẽ được lưu trữ và truy xuất. Nếu một chunk quá nhỏ, nó có thể mất ngữ cảnh cần thiết. Nếu quá lớn, hệ thống sẽ phải xử lý nhiều thông tin dư thừa, làm giảm độ chính xác của retrieval.

Fixed-size Chunking

Đây là cách tiếp cận đơn giản nhất, trong đó tài liệu được chia theo số lượng token hoặc ký tự cố định.

Ưu điểm là dễ triển khai và có hiệu năng cao. Tuy nhiên, phương pháp này thường phá vỡ các ranh giới ngữ nghĩa tự nhiên của tài liệu, khiến những thông tin liên quan bị tách rời khỏi nhau.

Semantic Chunking

Thay vì dựa trên kích thước, tài liệu được chia theo ý nghĩa.

Một đoạn văn, một khái niệm hoặc một chủ đề hoàn chỉnh sẽ được giữ nguyên trong cùng một chunk. Điều này giúp tăng đáng kể khả năng truy xuất đúng ngữ cảnh khi người dùng đặt câu hỏi.

Recursive Chunking

Đây là chiến lược phổ biến nhất trong các framework hiện nay.

Tài liệu được chia dần từ cấp độ lớn xuống nhỏ:

Document → Section → Paragraph → Sentence

Mục tiêu là duy trì sự cân bằng giữa ngữ cảnh và khả năng truy xuất.

Structure-aware Chunking

Đối với tài liệu kỹ thuật hoặc tài liệu doanh nghiệp, việc tận dụng cấu trúc sẵn có như tiêu đề, chương mục, bảng biểu hoặc code block thường mang lại hiệu quả cao hơn so với việc chia theo token đơn thuần.

LLM-based Chunking

Một số hệ thống hiện đại đã bắt đầu sử dụng chính LLM để xác định ranh giới chunk tối ưu.

Thay vì áp dụng các quy tắc cố định, mô hình sẽ đánh giá nội dung và quyết định vị trí phù hợp để chia tài liệu. Mặc dù chi phí xử lý cao hơn, đây đang là hướng tiếp cận được nhiều hệ thống enterprise quan tâm.

Retrieval ngày nay không còn là Vector Search đơn thuần

Thế hệ RAG đầu tiên chủ yếu dựa vào Semantic Search. Ý tưởng khá đơn giản: những tài liệu có embedding gần với embedding của câu hỏi sẽ được xem là liên quan.

Tuy nhiên, cách tiếp cận này bộc lộ nhiều hạn chế trong môi trường thực tế.

Các định danh như mã sản phẩm, mã lỗi hệ thống, số hợp đồng hoặc mã khách hàng thường không được xử lý hiệu quả bởi Semantic Search thuần túy. Đó là lý do vì sao hầu hết hệ thống hiện đại đã chuyển sang sử dụng Hybrid Search.

Hybrid Search kết hợp hai phương pháp:

• Dense Retrieval để hiểu ngữ nghĩa.

• Sparse Retrieval để xử lý các từ khóa và định danh chính xác.

Cách tiếp cận này giúp tăng đáng kể khả năng truy xuất trong các hệ thống dữ liệu lớn và đa dạng.

Sau bước retrieval, nhiều kiến trúc còn bổ sung thêm tầng Reranking nhằm đánh giá lại độ liên quan của các kết quả trước khi đưa vào context của LLM. Mục tiêu là đảm bảo cửa sổ ngữ cảnh chỉ chứa những thông tin có giá trị nhất cho quá trình sinh câu trả lời.

Từ Simple RAG Đến Agentic RAG

Khi yêu cầu nghiệp vụ ngày càng phức tạp, mô hình Retrieve → Generate truyền thống bắt đầu bộc lộ giới hạn.

Nhiều kiến trúc mới đã xuất hiện để giải quyết những bài toán đòi hỏi khả năng suy luận và điều phối cao hơn.

Branched RAG

Truy vấn được phân loại trước khi thực hiện tìm kiếm.

Ví dụ, câu hỏi liên quan đến pháp lý có thể được chuyển tới Legal Index, trong khi các câu hỏi kỹ thuật sẽ được định tuyến tới Technical Index. Điều này giúp tăng độ chính xác và giảm nhiễu trong quá trình retrieval.

HyDE

HyDE (Hypothetical Document Embeddings) hoạt động bằng cách tạo ra một câu trả lời giả định trước khi thực hiện tìm kiếm.

Thay vì truy xuất trực tiếp từ câu hỏi của người dùng, hệ thống sử dụng nội dung giả định này làm cơ sở để tìm kiếm các tài liệu phù hợp hơn.

Corrective RAG

CRAG bổ sung một tầng đánh giá chất lượng retrieval.

Nếu kết quả không đạt ngưỡng tin cậy, hệ thống có thể kích hoạt các chiến lược thay thế như truy xuất từ nguồn dữ liệu khác hoặc tìm kiếm trên Internet trước khi tiếp tục sinh câu trả lời.

Self-RAG

Ở kiến trúc này, mô hình có khả năng tự đánh giá chất lượng đầu ra của chính mình.

Khi phát hiện thiếu thông tin hoặc mức độ tin cậy chưa đủ cao, hệ thống sẽ chủ động thực hiện thêm một vòng retrieval để cải thiện kết quả.

Agentic RAG

Đây là hướng phát triển nhận được nhiều sự quan tâm nhất hiện nay.

Thay vì vận hành theo một pipeline cố định, các AI Agent có thể tự lập kế hoạch, chia nhỏ bài toán, truy xuất dữ liệu từ nhiều nguồn và sử dụng nhiều công cụ khác nhau để hoàn thành mục tiêu.

Sự khác biệt quan trọng nằm ở chỗ:

RAG truyền thống giúp AI tìm kiếm thông tin.
Agentic RAG giúp AI giải quyết vấn đề.

Tương lai của RAG

RAG đang dần chuyển từ một kỹ thuật truy xuất tài liệu thành một lớp hạ tầng tri thức cho các hệ thống AI.

Trong những năm tới, ba xu hướng đáng chú ý nhất bao gồm:

Multimodal RAG, nơi hệ thống có thể truy xuất đồng thời văn bản, hình ảnh, video và dữ liệu đa phương tiện.

Graph RAG, kết hợp Vector Search với Knowledge Graph nhằm cải thiện khả năng suy luận dựa trên mối quan hệ giữa các thực thể.

Và cuối cùng là Agent-Orchestrated Systems, nơi nhiều AI Agent chuyên biệt phối hợp với nhau để tìm kiếm, phân tích, đánh giá và thực thi các tác vụ phức tạp.

Kết luận

Điều đáng chú ý là RAG không còn đơn thuần là một kỹ thuật giúp chatbot trả lời chính xác hơn.

Nó đang trở thành nền tảng tri thức cho thế hệ ứng dụng AI tiếp theo.

Khi các tổ chức bắt đầu triển khai AI ở quy mô lớn, câu hỏi không còn là "Có nên sử dụng RAG hay không?" mà là "Làm thế nào để thiết kế kiến trúc retrieval đủ linh hoạt, đủ chính xác và đủ khả năng mở rộng cho những bài toán ngày càng phức tạp?"

Từ góc nhìn kiến trúc hệ thống, đó mới là bài toán thực sự của RAG trong những năm tới.