Kinh nghiệm Production RAG rút ra khi xử lý hơn 5 triệu tài liệu

• Trong 8 tháng triển khai dự án RAG (Retrieval-Augmented Generation), đã phân biệt được những cách thực sự hiệu quả và những cách chỉ tốn thời gian
• Ban đầu sử dụng Langchain và Llamaindex để hoàn thành prototype nhanh chóng, nhưng khi nhận phản hồi từ người dùng thực tế đã gặp phải giới hạn về hiệu năng
• Những yếu tố có tác động lớn nhất đến việc cải thiện hiệu năng truy xuất tài liệu được xác định là tạo truy vấn, reranking, chiến lược chunking, tận dụng metadata, định tuyến truy vấn
• Trong thực tế, nhóm xây dựng pipeline tùy biến bằng cách linh hoạt lựa chọn vector database, embedding, reranking, LLM
• Toàn bộ kinh nghiệm và bí quyết đã được tổng hợp và công khai trong dự án mã nguồn mở(agentset-ai/agentset)

---

Tổng quan về 8 tháng xây dựng Production RAG

• Chia sẻ kinh nghiệm xây dựng và vận hành hệ thống RAG trên các tập dữ liệu quy mô lớn như tổng cộng 9 triệu trang (Usul AI), 4 triệu trang (một công ty AI pháp lý ẩn danh)
• Ban đầu, làm theo tutorial trên YouTube, chuyển từ Langchain sang Llamaindex và hoàn thành prototype chỉ trong vài ngày, nhưng khi triển khai thực tế đã lộ ra vấn đề hiệu năng thấp mà chỉ người dùng mới có thể nhận ra
• Sau vài tháng, từng thành phần của hệ thống được chỉnh sửa dần dần để đạt đến hiệu năng tối ưu

Những yếu tố thực sự đóng góp vào cải thiện hiệu năng (theo ROI)

1. Tạo truy vấn (Query Generation)

   • Vì truy vấn cuối cùng của người dùng không thể chứa toàn bộ ngữ cảnh, nên dùng LLM để xem lại hội thoại và tạo ra nhiều truy vấn ngữ nghĩa lẫn truy vấn từ khóa
   • Các truy vấn này được xử lý song song rồi chuyển cho reranker, từ đó mở rộng phạm vi truy xuất và bù lại độ lệch của hybrid search

2. Reranking

   • Ảnh hưởng của reranking đến hiệu năng, dù chỉ cần khoảng 5 dòng code để triển khai, lớn hơn nhiều so với tưởng tượng
   • Với đầu vào là nhiều chunk lớn (ví dụ: 50), việc sắp xếp lại và chọn lọc một số chunk hàng đầu (ví dụ: 15) mang lại ROI cao nhất
   • Chỉ riêng reranking cũng có thể bù đắp đáng kể cho những thiếu sót của một pipeline được thiết kế chưa tốt

3. Chiến lược chunking (Chunking Strategy)

   • Đây là phần chiếm phần lớn thời gian trong toàn bộ quá trình phát triển
   • Cần hiểu chính xác cấu trúc và mẫu của dữ liệu, chunk theo đơn vị logic và tự kiểm tra để tránh cắt ngang chữ hoặc câu ở giữa
   • Mỗi chunk phải giữ được ý nghĩa độc lập

4. Tận dụng metadata trong đầu vào LLM

   • Thay vì chỉ đưa văn bản chunk thuần túy vào LLM, việc thêm metadata (title, author, v.v.) giúp cải thiện đáng kể ngữ cảnh và chất lượng câu trả lời

5. Định tuyến truy vấn (Query Routing)

   • Với những loại câu hỏi mà RAG không thể trả lời (ví dụ: tóm tắt bài viết, yêu cầu thông tin tác giả), nhóm đưa vào một router nhẹ để chuyển truy vấn sang luồng xử lý API+LLM

Stack thực chiến (Our stack)

• Vector database: Azure → Pinecone → Turbopuffer (rẻ hơn và mặc định hỗ trợ keyword search)
• Trích xuất tài liệu: áp dụng cách làm tùy biến
• Công cụ chunking: mặc định dùng Unstructured.io, pipeline doanh nghiệp thì tùy biến (Chonkie cũng được đánh giá tốt)
• Mô hình embedding: dùng text-embedding-large-3 (chưa thử các mô hình khác)
• Reranker: None → Cohere 3.5 → Zerank (không quá phổ biến nhưng thực tế rất tốt)
• LLM: GPT 4.1 → GPT 5 → GPT 4.1 (chủ yếu dùng Azure credits)

Mã nguồn mở và kết luận

• Toàn bộ kết quả học được và kinh nghiệm thực chiến được đúc kết vào dự án mã nguồn mởagentset-ai/agentset
• Được phát hành theo giấy phép MIT, có thể tự do sử dụng và liên hệ hỏi thêm (có cung cấp thông tin liên hệ)

[GN⁺]

Ý kiến trên Hacker News

• Cảm thấy phần nói về việc tạo truy vấn tổng hợp thực sự rất quan trọng; trong thực tế người dùng thường nhập truy vấn rất thiếu chính xác, nên lúc đầu LLM sẽ tạo truy vấn tổng hợp. Tuy nhiên, kết quả dao động khá lớn tùy theo truy vấn tổng hợp được sinh ra mỗi lần, nên họ để một lần gọi LLM tạo đa dạng ba phiên bản truy vấn, rồi tìm kiếm song song và kết hợp thành danh sách kết quả mạnh hơn bằng reciprocal rank fusion. Phần tìm kiếm dùng hybrid dense + sparse bm25; chỉ dense thôi thì yếu với thuật ngữ chuyên môn. Gắn thêm reranker vào thì hầu hết vấn đề liên quan đến tìm kiếm được giải quyết.
  • Thấy thú vị với việc dùng cách hybrid (bm25 + dense search) để bù cho điểm yếu của mô hình dense với thuật ngữ kỹ thuật. Các mô hình v3 như SPLADE có vẻ cũng cho hiệu năng tốt nhờ cân bằng tốt giữa tìm kiếm ngữ nghĩa và từ vựng, nên luôn tò mò liệu có thể thay thế bằng một giải pháp đơn giản hơn hay không.
  • Nhấn mạnh rằng những chi tiết như tạo/tối ưu truy vấn này rốt cuộc là phần mà các nhà cung cấp giải pháp RAG như Amazon, Microsoft, OpenAI nên lo liệu.
  • Đồng ý rằng đây hiện là best practice, nhưng vẫn có cảm giác còn thiếu điều gì đó trong các chiến lược bổ sung có thể đẩy hiệu năng lên thêm một bậc nữa, như phân nhánh lựa chọn embedding model hay kết hợp nhiều re-ranker khác nhau.
  • Mẹo cuối là nên cho người dùng thấy LLM đã diễn giải ý định tìm kiếm của họ như thế nào cùng với kết quả, để họ có thể tự xác nhận liệu LLM có hiểu đúng hay không.
• Cảm thấy khá bối rối về tùy chọn self-hosted; xem tài liệu liên quan thì thấy cần ít nhất hơn 6 tài khoản dịch vụ bên thứ ba, và điều đó rất khác với ý nghĩa self-hosted thực sự.
  • Giải thích rằng bản thân đoạn mã đó có thể self-host trực tiếp; đồng thời cho rằng thuật ngữ “self-hosted” không có tiêu chuẩn chính thức thật rõ ràng. Ví dụ, một dịch vụ self-hosted vẫn có thể có tính năng sao lưu off-site; khi đó nó vẫn là self-hosted, đồng thời chỉ đơn giản là một dịch vụ được thiết kế tốt.
  • Kiểu marketing self-hosted như vậy có thể cũng là điều tự nhiên; vì mô hình kinh doanh gốc của nhà cung cấp là bán phiên bản được host, nên không nhất thiết họ phải cung cấp một sản phẩm self-hosted hoàn toàn độc lập.
  • Chia sẻ kinh nghiệm từng làm việc trong môi trường mạng bị hạn chế; suốt 20 năm qua đã làm trong môi trường mạng nội bộ bị cô lập hoàn toàn, nên có thể đã bỏ lỡ nhiều làn sóng công nghệ mới. Cũng hầu như không xem YouTube ngoài video sửa xe, và có phần dè dặt với các xu hướng công nghệ đòi hỏi kết nối trực tuyến liên tục.
  • Bản thân đang dùng phiên bản mã nguồn mở rất hài lòng; nếu không muốn phụ thuộc vào dịch vụ hosted thì cứ tự viết hết bằng Rust là được — một ý kiến rất thực tế.
• Rất khuyến khích thử các reranker dựa trên LLM cỡ lớn như Qwen3-reranker, vì chúng cho thấy hiệu năng mà trước đây người ta mong đợi ở cross-encoder, dù chi phí tính toán khá lớn. Ngoài ra, thông tin metadata/bảng biểu là kiến thức nền quá hiển nhiên với con người nhưng lại không được lặp lại trong các text chunk, nên nếu bơm chúng vào đầu vào của LLM thì hệ thống sẽ trông “thông minh” hơn hẳn. Các truy vấn phức tạp mà RAG đơn giản xử lý chưa tốt, chẳng hạn tóm tắt 20 tài liệu mới nhất, thì cần cẩn trọng. Vì vậy, nhóm này tập trung UI vào tìm kiếm, giảm bớt chat UX, và để người dùng cũng nhìn thấy đúng những thông tin mà mô hình thực sự đang thấy.
  • Hoàn toàn đồng ý rằng việc giúp người dùng hiểu đúng cách LLM xử lý ngữ cảnh là cực kỳ khó. Hiếm có ví dụ công khai nào thoát khỏi chat UX, và cũng hoài nghi liệu các công ty lớn từng thử rồi bỏ có thật sự là vì “không hiệu quả” hay không. Trên thực tế, với các ứng dụng tiêu dùng quy mô lớn, chi phí cho context/suy luận là chi phí trọng yếu cần phải kiểm soát, nên có vẻ UI hiển thị ngữ cảnh tường minh không được ưu tiên. Ngược lại, với hệ thống RAG nội bộ trong doanh nghiệp, áp lực chi phí thấp hơn nên trải nghiệm thực tế cho thấy người ta tập trung hơn nhiều vào chất lượng kết quả và việc tiết kiệm thời gian cho nhân viên.
  • Tối ưu kỹ thuật cũng quan trọng, nhưng vẫn muốn biết thêm các ca sử dụng thực tế cho thấy hiệu quả công việc của khách hàng đã cải thiện ra sao; nếu không thì nó chỉ lại là thêm một trào lưu công nghệ nữa.
• Chia sẻ một bài tổng kết viết từ một năm rưỡi trước về xử lý RAG cho hàng triệu trang tài liệu, đặc biệt là tài liệu kỹ thuật: https://jakobs.dev/learnings-ingesting-millions-pages-rag-azure/
  • Cũng từng xây dựng một hệ thống RAG cho tìm kiếm kỹ thuật vào năm trước, và cảm thấy đến giờ nhìn lại thì nhiều phần vẫn gần như giống hệt.
• Từ góc nhìn của người đang muốn xây hoặc áp dụng hệ thống RAG kiểu này, có người thắc mắc liệu có thể tạo một cấu trúc thực dụng bằng cách tải tài liệu qua API vào các thư mục Google Workspace rồi dùng Google AI search API để tìm kiếm tài liệu hay không, theo kiểu tách thư mục riêng cho từng người dùng; hoặc liệu có thể làm tương tự trên Azure hay không.
• Có người hỏi về cách quản lý phiên bản embedding: nên làm thế nào nếu cần cập nhật dữ liệu, hiển thị phiên bản cụ thể, hoặc lọc theo ngày; đồng thời đang nghĩ tới phương án thêm phiên bản ngữ cảnh vào đầu mỗi chunk.
  • Chỉ cần lưu văn bản gốc và metadata, bao gồm thông tin phiên bản, cùng trong vector store. Ví dụ, trên turbopuffer thì việc lọc theo attribute khá tiện; họ giới thiệu tài liệu này.
  • Cảm thấy bản thân câu hỏi này đã là một câu hỏi rất hữu ích và quan trọng.
• Có người thấy lạ về việc thứ tự dùng phiên bản LLM là GPT 4.1 → GPT 5 → rồi quay lại GPT 4.1, cũng như sự không nhất quán với phiên bản của các thành phần khác trong stack, ví dụ text-embedding-large-3.
  • OP trả lời: ngay khi GPT-5 ra mắt đã thử dùng, nhưng khi đưa vào nhiều context, tối đa 100 nghìn token, thì hiệu năng lại kém hơn GPT-4.1 nên quay lại 4.1. Cụ thể: a) khả năng làm theo chỉ dẫn yếu hơn, nên không bám sát system prompt; b) câu trả lời quá dài dòng, ảnh hưởng lớn tới UX; c) giới hạn cửa sổ ngữ cảnh 125 nghìn token khiến đầu vào rất lớn dễ gây lỗi. Các vấn đề này nổi bật hơn trong “RAG”, nơi phải truyền nhiều chunk; còn với tác vụ thông thường thì GPT-5 vẫn có thể tốt hơn.
• Dù không phải người cổ vũ AWS, có người nhấn mạnh rằng S3 Vectors hiện là state-of-the-art trong lĩnh vực này. Kết hợp thêm Bedrock Knowledge Base thì Discovery/Rebalance cũng trở nên đơn giản, và đây có thể sẽ là giải pháp đơn giản nhất trên thị trường. Khi chính thức phát hành, họ cho rằng nó sẽ vượt xa phần lớn đối thủ.
  • Có người đùa rằng từ đúng không phải là “schlep” mà là “shill”.
  • Có người thắc mắc vì sao S3 Vectors lại là SOTA, vì suy cho cùng nó vẫn chỉ là vector store mà thôi.
• RAG dựa trên embedding thực ra chưa hẳn là cách tốt nhất; nó ổn cho một tác vụ đơn lẻ hay bản demo, nhưng trong tình huống thực tế thì thường gặp giới hạn.
  • Cũng có kinh nghiệm cho thấy không hẳn vậy. Sản phẩm Query Assistant của Honeycomb mà một người từng làm cũng dựa trên truy vấn dữ liệu từ năm 2023, và vì tính năng này được thiết kế cho mục đích rất đơn giản nên lại cho cảm giác là hướng đi lý tưởng cho sản phẩm dùng LLM; kết hợp thêm xử lý non-LLM là tốt.
  • RAG đang liên tục được diễn giải lại theo nhiều cách và có rất nhiều mục đích sử dụng. Có người nói họ đã tích hợp RAG như một công cụ vào agentic search, đồng thời trộn cả tìm kiếm trên nguồn thời gian thực lẫn cách chunk truyền thống. Với các cửa sổ context dung lượng lớn sắp xuất hiện, tương lai có thể sẽ cho phép đưa cả tài liệu vào trong một lần yêu cầu.
  • Có người hỏi đang đề xuất phương án thay thế nào, liệu có phải đang nói tới cách tạo truy vấn hay không.
  • Ngay cả với ChatGPT, RAG cũng hiệu quả để lấy thông tin mới nhất; tính hữu ích thực tế này chính là lý do hiện nay mọi nhà cung cấp lớn đều cung cấp nó.
  • Có người hỏi rõ là đang so sánh với cái gì.
• Có người nói việc chọn chiến lược chunk đã tốn rất nhiều thời gian và công sức, nên muốn nghe chi tiết hơn về các chiến lược cụ thể đã dùng.