RAG (Retrieval-Augmented Generation) hoạt động tốt trong demo vì demo thường dùng một vài tài liệu được chọn kỹ, query đơn giản, và không ai đo recall hay precision. Trong production, tình hình khác: knowledge base có hàng nghìn document với chất lượng không đồng đều, người dùng hỏi theo cách không ngờ tới, và một retrieval miss có nghĩa là LLM trả lời sai hoặc hallucinate — mà không có warning nào.

Chất lượng của RAG pipeline phụ thuộc vào ba lớp độc lập nhau: indexing (cách tài liệu được xử lý và lưu vào vector store), retrieval (cách tìm đoạn liên quan khi có query), và generation (cách LLM tổng hợp câu trả lời từ context được trả về). Lỗi ở bất kỳ lớp nào đều làm hỏng output — nhưng chúng có triệu chứng khác nhau và cần debug theo cách khác nhau.

Chunking strategy — quyết định đầu tiên và quan trọng nhất

Chunking là quá trình chia tài liệu thành các đoạn nhỏ để index và retrieve. Chiến lược chunking ảnh hưởng trực tiếp đến recall: chunk quá nhỏ mất context, chunk quá lớn làm loãng signal và tốn token khi đưa vào LLM context window. Không có kích thước chunk "đúng" cho mọi trường hợp — cần thử nghiệm với data thực tế:

Fixed-size chunking với overlap: chia theo số token (512, 1024) với overlap 10–20% để tránh cắt giữa câu quan trọng. Đơn giản nhất để implement nhưng không tôn trọng cấu trúc tài liệu — một bảng hoặc đoạn code có thể bị cắt giữa chừng
Semantic chunking: chia tại ranh giới ngữ nghĩa tự nhiên — đầu đề, đoạn văn, section. Giữ context tốt hơn nhưng tạo ra chunk có kích thước không đều. Phù hợp với tài liệu có cấu trúc rõ ràng như technical doc, FAQ, policy document
Hierarchical chunking: index cả parent chunk (lớn, cho context) và child chunk (nhỏ, cho precision). Retrieve bằng child chunk nhưng trả về parent chunk cho LLM — giữ được context rộng hơn mà không làm loãng signal khi retrieve
Document-aware chunking: với PDF có bảng biểu, code block hay hình ảnh, cần extract và xử lý từng element riêng. Bảng biểu nên được convert thành text có cấu trúc trước khi chunk — embed raw HTML của bảng thường cho kết quả retrieval kém

Một test nhanh để đánh giá chunking: lấy 20 câu hỏi thực tế từ người dùng, tìm tay đoạn tài liệu chứa câu trả lời, rồi xem chunk nào cover đoạn đó. Nếu câu trả lời bị split giữa hai chunk — cần tăng kích thước hoặc thêm overlap.

Embedding model — precision phụ thuộc vào lựa chọn này

Embedding model chuyển đổi text thành vector để so sánh semantic similarity. Lựa chọn model ảnh hưởng đến mức độ chính xác của retrieval — và không phải model tốt nhất trên benchmark chung cũng là model tốt nhất cho domain cụ thể của bạn:

Domain-specific vs general: model train trên text tổng quát (như `text-embedding-3-large` của OpenAI hay `e5-large`) hoạt động tốt với nhiều loại nội dung. Với tài liệu kỹ thuật chuyên sâu (y tế, pháp lý, kỹ thuật công nghiệp), model fine-tune trên domain đó thường cho recall tốt hơn đáng kể
Tiếng Việt: model đa ngữ (multilingual-e5, BGE-M3) cần thiết nếu knowledge base chứa tiếng Việt. Model tiếng Anh thuần túy sẽ tạo ra embedding kém chất lượng cho text tiếng Việt, dẫn đến recall thấp ngay cả khi chunking tốt
Dimensionality vs cost: vector 1536 chiều (text-embedding-3-large) cho precision cao hơn nhưng tốn storage và compute hơn 256 hay 384 chiều. Với knowledge base nhỏ hơn 100K chunk, sự khác biệt storage không đáng kể — ưu tiên quality. Với hàng triệu chunk, cần cân nhắc kỹ
Consistency: embedding model dùng khi index và khi query phải giống nhau. Thay đổi model sau khi đã index yêu cầu re-embed toàn bộ knowledge base — lên kế hoạch kỹ trước khi chọn

Vector search và hybrid retrieval

Sau khi có embedding tốt, cần index và query hiệu quả. Hai loại search thường dùng trong production RAG có đặc điểm khác nhau và thường được kết hợp:

Dense retrieval (HNSW index): tìm kiếm theo semantic similarity — hiểu được paraphrase, synonym, và câu hỏi có cùng ý nghĩa nhưng khác từ. Nhược điểm: kém với exact keyword matching — nếu người dùng tìm "mã lỗi E-1042", dense retrieval có thể miss nếu code đó không xuất hiện nhiều trong training data của embedding model
Sparse retrieval (BM25): tìm kiếm theo từ khóa chính xác — tốt với product code, tên riêng, số hiệu tài liệu. Không hiểu semantic nhưng không bao giờ miss exact match
Hybrid search: kết hợp dense và sparse bằng Reciprocal Rank Fusion (RRF) hoặc weighted sum. Phần lớn production RAG system cần hybrid — ngưỡng cải thiện recall so với dense-only thường là 10–20% trên query thực tế
Metadata filtering trước vector search: nếu knowledge base có nhiều loại document khác nhau (manual, policy, FAQ), filter trước theo metadata (document_type, date, department) để giảm search space và tăng precision. Weaviate, Qdrant và Pinecone đều hỗ trợ pre-filter trước khi HNSW search

Reranking — lớp thường bỏ qua

Vector search trả về top-K kết quả theo similarity score, nhưng similarity score không hoàn toàn tương quan với relevance cho một query cụ thể. Reranker là cross-encoder model đánh giá lại từng (query, chunk) pair và sắp xếp lại — chậm hơn bi-encoder embedding nhưng chính xác hơn nhiều:

Cross-encoder reranker (như Cohere Rerank, BGE-Reranker): lấy top 20–50 kết quả từ vector search, rerank và chỉ giữ top 3–5 để đưa vào LLM context. Tỷ lệ relevant-in-context tăng rõ rệt, giảm hallucination do context loãng
Khi nào thêm reranking: nếu LLM thường xuyên trả lời "tôi không tìm thấy thông tin" dù knowledge base có câu trả lời, hoặc câu trả lời không dùng đến chunk quan trọng nhất — reranker thường fix được vấn đề này. Latency overhead từ 50–200ms tùy model

Evaluation pipeline — không thể cải thiện không đo

Phần bị bỏ qua nhiều nhất trong RAG implementation: pipeline đánh giá có hệ thống. Không có evaluation, mọi thay đổi (chunking, embedding, reranking) chỉ là đoán mò — không biết thay đổi đó cải thiện hay làm xấu hơn:

RAGAS framework: đánh giá RAG theo bốn metric chính: Context Recall (có chunk chứa câu trả lời trong retrieved context không), Context Precision (chunk nào trong context thực sự được dùng), Faithfulness (LLM có trả lời dựa trên context không, hay hallucinate), và Answer Relevancy (câu trả lời có liên quan đến câu hỏi không)
Golden dataset: tập 50–200 cặp (question, ground-truth answer) được tạo từ tài liệu thực tế — dùng để evaluate mỗi khi thay đổi bất kỳ thành phần nào trong pipeline. Có thể dùng LLM để tự động tạo golden dataset từ tài liệu rồi human review
Offline vs online evaluation: offline trên golden dataset cho feedback nhanh trong development. Online evaluation theo dõi thumbs up/down hoặc follow-up question rate trên traffic thực — tín hiệu quan trọng nhất về chất lượng thực tế

Thứ tự debug khi RAG cho kết quả kém: (1) kiểm tra Context Recall — nếu thấp, vấn đề ở chunking hoặc embedding. (2) Nếu Recall ổn nhưng Faithfulness thấp, vấn đề ở LLM prompt hoặc context quá dài. (3) Nếu cả hai ổn nhưng người dùng không hài lòng, vấn đề ở Answer Relevancy hoặc kỳ vọng không khớp.

Ví dụ thực tế: RAG cho hệ thống hỗ trợ kỹ thuật

Trong dự án AI agent cho chuỗi bán lẻ 12 cửa hàng, RAG pipeline được xây để trả lời câu hỏi từ nhân viên về chính sách, quy trình và product catalog. Implementation đầu tiên dùng fixed-size chunk 512 token và OpenAI embedding — Context Recall trên golden dataset đạt 61%. Sau khi chuyển sang hierarchical chunking và hybrid search (dense + BM25), Recall tăng lên 84%. Thêm BGE-Reranker và giảm context window từ top-10 xuống top-4 sau rerank: Faithfulness tăng từ 71% lên 89%, số câu hỏi người dùng phải hỏi lại giảm 40%.

Kết luận

RAG không phải một component mà là một pipeline với nhiều điểm quyết định — chunking, embedding, retrieval, reranking, generation. Mỗi điểm cần được thiết kế dựa trên đặc điểm của data và query thực tế, không phải dựa trên default của framework. Evaluation pipeline là thành phần không thể thiếu: không đo được thì không cải thiện được. Trong lớp AI & ML của KonexForge, RAG pipeline là một trong những use case được triển khai nhiều nhất — và evaluation-first là nguyên tắc thiết kế ngay từ Pilot Build.

RAG pipeline trong production: chunking strategy, vector search và đánh giá chất lượng retrieval