Hạ tầng RAG: Xây dựng hệ thống Retrieval-Augmented Generation cho môi trường Production

Cập nhật ngày 8 tháng 12, 2025

Cập nhật tháng 12/2025: Việc áp dụng RAG đang tăng tốc với tư cách là use case LLM doanh nghiệp số 1. Kiến trúc GraphRAG và agentic RAG đang thu hút sự chú ý cho các tác vụ suy luận phức tạp. Thị trường vector database đang hợp nhất xung quanh Pinecone, Weaviate, Milvus và Qdrant. Voyage-3-large vượt trội hơn OpenAI và Cohere embeddings từ 9-20%. Semantic chunking cải thiện recall lên đến 9% so với các phương pháp fixed-size. Những thách thức production đang chuyển từ prototype sang quy mô—embedding drift, multi-tenancy và yêu cầu độ trễ dưới 50ms đang thúc đẩy đầu tư hạ tầng.

Harvey AI phục vụ 97% các công ty luật Am Law 100 sử dụng retrieval-augmented generation để neo nghiên cứu pháp lý vào các án lệ thực tế thay vì các trích dẫn ảo giác.¹ Anthropic, OpenAI và Google đều khuyến nghị RAG là kỹ thuật chính để kết nối các large language model với dữ liệu doanh nghiệp độc quyền. Tuy nhiên, khoảng cách giữa một prototype RAG hoạt động được và hạ tầng cấp production kéo dài hàng tháng nỗ lực kỹ thuật. Các tổ chức phát hiện ra rằng vector database, embedding pipeline, chiến lược chunking và tối ưu hóa retrieval mỗi thứ đều đặt ra những thách thức hạ tầng riêng biệt và cộng hưởng ở quy mô lớn. Xây dựng hệ thống RAG xử lý hàng triệu tài liệu, phục vụ hàng nghìn người dùng đồng thời và duy trì độ trễ dưới một giây đòi hỏi các quyết định kiến trúc mà ít team nào lường trước được trong giai đoạn proof-of-concept.

Kiến trúc cốt lõi mà mọi hệ thống RAG production đều cần

Hệ thống RAG kết hợp hai khả năng cơ bản: truy xuất ngữ cảnh liên quan từ knowledge base và tạo phản hồi được neo vào ngữ cảnh đó. Kiến trúc chia thành năm thành phần riêng biệt, mỗi thành phần có yêu cầu hạ tầng cụ thể.

Document ingestion pipeline xử lý luồng từ tài liệu thô đến embedding có thể tìm kiếm. Hệ thống production xử lý PDF, HTML, tài liệu Word, tin nhắn Slack và bản ghi database thông qua các parser chuyên biệt cho từng định dạng. Ingestion pipeline phải theo dõi phiên bản tài liệu, xử lý cập nhật gia tăng và duy trì metadata để lọc. Các triển khai doanh nghiệp điển hình xử lý 100.000 đến 10 triệu tài liệu trong lần backfill ban đầu, với tải gia tăng hàng ngày từ 1.000 đến 50.000 tài liệu mới.²

Hệ thống chunking chia tài liệu thành các phân đoạn thân thiện với retrieval. Fixed-size chunking hoạt động tốt cho nội dung đồng nhất như bài báo tin tức, trong khi semantic chunking bảo toàn ranh giới ngữ nghĩa cho các tài liệu phức tạp.³ Hầu hết hệ thống production sử dụng recursive chunking với 400-512 token và 10-20% overlap, đạt 85-90% recall trong các bài kiểm tra benchmark.⁴ Việc chọn chiến lược chunking trở thành bán vĩnh viễn—thay đổi phương pháp sau này đòi hỏi phải re-embed toàn bộ corpus.

Hạ tầng embedding chuyển đổi các chunk văn bản thành biểu diễn vector dày đặc. Các tổ chức chọn giữa API được quản lý (OpenAI, Cohere, Voyage AI) và các model tự host. Việc tạo embedding tạo ra cấu trúc chi phí biến động nhất trong hệ thống RAG, với giá dao động từ $0.02 đến $0.18 cho mỗi triệu token tùy thuộc vào lựa chọn model.⁵ Xử lý batch song song hóa việc tạo embedding trên các node GPU cho tải ban đầu, trong khi streaming pipeline xử lý cập nhật gia tăng.

Vector database lưu trữ và truy xuất embedding sử dụng thuật toán approximate nearest neighbor. Bốn lựa chọn hàng đầu—Pinecone, Weaviate, Milvus và Qdrant—phục vụ các profile vận hành khác nhau. Pinecone cung cấp dịch vụ được quản lý không cần vận hành, Weaviate cung cấp hybrid search với khả năng knowledge graph, Milvus xử lý triển khai quy mô tỷ, và Qdrant xuất sắc trong lọc metadata phức tạp.⁶ Yêu cầu lưu trữ tỷ lệ với chiều embedding và số lượng tài liệu; một corpus 10 triệu tài liệu với embedding 1024 chiều đòi hỏi khoảng 40GB lưu trữ vector.

Điều phối retrieval và generation liên kết các thành phần với nhau, thường sử dụng các framework như LangChain, LlamaIndex hoặc triển khai tùy chỉnh. Điều phối xử lý query processing, retrieval, reranking, xây dựng prompt và tạo phản hồi. Hệ thống production triển khai các lớp caching, chiến lược fallback và công cụ observability ở mỗi giai đoạn.

Lựa chọn vector database quyết định độ phức tạp vận hành

Thị trường vector database đã hợp nhất xung quanh bốn nhà cung cấp lớn vào tháng 12/2025, mỗi nhà phục vụ các profile vận hành và use case riêng biệt.

Pinecone thống trị phân khúc dịch vụ được quản lý, xử lý hoàn toàn hạ tầng đằng sau API của họ. Các team triển khai hệ thống production trong vài giờ thay vì vài tuần, với auto scaling, replication đa vùng và tuân thủ SOC 2 được bao gồm. Pinecone hỗ trợ metadata lên đến 40KB cho mỗi vector, cho phép lọc phong phú mà không cần hệ thống bên ngoài. Đánh đổi bao gồm chi phí cho mỗi query cao hơn và kiểm soát giảm đối với tối ưu hóa hạ tầng. Các tổ chức chạy workload có thể dự đoán thường thấy Pinecone hiệu quả về chi phí; những tổ chức có lưu lượng biến động cao hoặc yêu cầu quy mô cực lớn thường chuyển sang các phương án thay thế.⁷

Weaviate cầu nối giữa tính linh hoạt open-source với sự tiện lợi được quản lý thông qua Weaviate Cloud. Hệ thống kết hợp vector search với khả năng knowledge graph, cho phép các query lai lọc trên dữ liệu có cấu trúc trong khi xếp hạng theo độ tương đồng ngữ nghĩa. Kiến trúc modular của Weaviate hỗ trợ nhiều model embedding đồng thời, hữu ích cho các tổ chức thử nghiệm các phương pháp khác nhau. Triển khai Docker và Kubernetes đòi hỏi chuyên môn vận hành khiêm tốn, khiến Weaviate phổ biến trong các team có một số khả năng hạ tầng.⁸

Milvus (và đối tác được quản lý Zilliz Cloud) nhắm đến triển khai quy mô tỷ với hiệu suất là mục tiêu thiết kế chính. Milvus dẫn đầu benchmark về độ trễ thô, đạt thời gian query dưới 10ms trên các chỉ mục vector tỷ thông qua tăng tốc GPU và thuật toán indexing tiên tiến.⁹ Kiến trúc tách biệt compute và storage, cho phép scale độc lập từng lớp. Vận hành Milvus đòi hỏi chuyên môn data engineering đáng kể—các team không có nhân sự hạ tầng chuyên dụng thường gặp khó khăn với quản lý cluster và điều chỉnh hiệu suất.

Qdrant đạt được sự chấp nhận nhanh chóng cho các yêu cầu lọc phức tạp. Được xây dựng bằng Rust, Qdrant thực thi payload filtering trực tiếp trong thuật toán tìm kiếm thay vì xử lý hậu kỳ, mang lại hiệu suất vượt trội cho các query có lọc.¹⁰ Footprint tài nguyên gọn nhẹ khiến Qdrant phổ biến cho các triển khai nhạy cảm về chi phí, trong khi thiết kế API rõ ràng tăng tốc tốc độ phát triển. Triển khai tự host chạy mượt mà trên hạ tầng khiêm tốn, mặc dù các tính năng enterprise đòi hỏi giấy phép thương mại.

Tiêu chí lựa chọn nên ưu tiên khả năng vận hành trước. Các team cần không vận hành chọn Pinecone hoặc Weaviate Cloud. Các tổ chức có năng lực SRE thoải mái với workload Kubernetes stateful đạt được tiết kiệm chi phí và kiểm soát từ Milvus, Qdrant hoặc Weaviate tự host. Yêu cầu tuân thủ đôi khi loại bỏ các tùy chọn—Pinecone và Weaviate Cloud cung cấp tuân thủ SOC 2 và HIPAA, trong khi yêu cầu on-premise đòi hỏi giải pháp tự host.

Lựa chọn embedding model ảnh hưởng đến cả chi phí và chất lượng retrieval

Embedding model chuyển đổi văn bản thành biểu diễn vector, và việc lựa chọn model ảnh hưởng trực tiếp đến độ chính xác retrieval. Bối cảnh tháng 12/2025 cung cấp ba lựa chọn thương mại hàng đầu cùng với một số phương án open-source mạnh mẽ.

Voyage AI dẫn đầu benchmark MTEB, với voyage-3-large vượt trội hơn OpenAI text-embedding-3-large 9.74% và Cohere embed-v3-english 20.71% trên các domain được đánh giá.¹¹ Voyage AI hỗ trợ cửa sổ ngữ cảnh 32K-token (so với 8K cho OpenAI và 512 cho các model Cohere cũ hơn), cho phép xử lý tài liệu dài hơn mà không cần chunking. Embedding 1024 chiều có giá $0.06 cho mỗi triệu token—rẻ hơn OpenAI 2.2 lần và Cohere 1.6 lần—trong khi đòi hỏi lưu trữ vector ít hơn 3 lần so với embedding 3072 chiều của OpenAI.

OpenAI text-embedding-3-large cung cấp tùy chọn được thử nghiệm thực chiến nhất cho triển khai production. Model hỗ trợ chiều đầu ra có thể cấu hình từ 256 đến 3072, cho phép đánh đổi chi phí-lưu trữ. Với $0.13 cho mỗi triệu token, OpenAI nằm ở giữa phổ giá trong khi cung cấp uptime đáng tin cậy và tài liệu phong phú. Các tổ chức đã sử dụng API inference của OpenAI thường chuẩn hóa trên embedding của họ để đơn giản hóa vận hành.

Cohere embed-v4 đạt điểm MTEB cao nhất (65.2) tính đến tháng 11/2025, được tối ưu hóa đặc biệt cho search và retrieval thay vì embedding đa mục đích.¹² Cohere embedding kết hợp tự nhiên với reranker của Cohere cho pipeline retrieval hai giai đoạn. Model xuất sắc trong các ứng dụng đa ngôn ngữ, hỗ trợ hơn 100 ngôn ngữ với cross-lingual retrieval mạnh mẽ.

Các phương án open-source bao gồm các model BGE, E5 và GTE cho phép embedding tự host ở quy mô lớn. Các tổ chức xử lý hàng tỷ tài liệu thường triển khai các model này trên hạ tầng GPU nội bộ để loại bỏ chi phí per-token. Tự host đòi hỏi quản lý cập nhật model, lập kế hoạch capacity và tối ưu hóa inference—những đánh đổi chỉ hợp lý ở quy mô đáng kể.

Quyết định embedding model lan tỏa qua toàn bộ hệ thống. Thay đổi model sau này đòi hỏi re-embed hoàn toàn corpus tài liệu, một quá trình tốn thời gian, compute và có thể gián đoạn dịch vụ. Hệ thống production nên đánh giá model dựa trên benchmark domain-specific thay vì dựa vào điểm MTEB chung. Một model xuất sắc ở kiến thức chung có thể kém hiệu quả trên văn bản pháp lý, y tế hoặc tài chính.

Chiến lược chunking quyết định độ chính xác retrieval

Document chunking tạo ra các đơn vị nguyên tử mà hệ thống retrieval tìm kiếm. Việc lựa chọn chiến lược chunking nằm trong số các quyết định hạ tầng có ảnh hưởng lớn nhất, với biến động recall tiềm năng 9% giữa phương pháp tốt nhất và tệ nhất.¹³

Fixed-size chunking chia tài liệu ở số token được xác định trước bất kể cấu trúc nội dung. Phương pháp hoạt động tốt cho corpus đồng nhất—bài báo tin tức, mô tả sản phẩm hoặc tài liệu được chuẩn hóa. Triển khai đòi hỏi độ phức tạp tối thiểu, khiến fixed-size chunking là điểm khởi đầu tự nhiên cho prototype. Hầu hết hệ thống production sử dụng chunk 400-512 token với overlap 50-100 token, cân bằng độ chi tiết retrieval với bảo toàn ngữ cảnh.

Semantic chunking chia tài liệu tại các ranh giới có ý nghĩa—ngắt đoạn, tiêu đề section hoặc chuyển đổi chủ đề—bảo toàn các ý tưởng mạch lạc trong mỗi chunk. Triển khai sử dụng sentence embedding để phát hiện ranh giới ngữ nghĩa, chia khi độ tương đồng giữa các câu liền kề giảm xuống dưới ngưỡng. Semantic chunking cải thiện recall lên đến 9% cho nội dung narrative như tài liệu, FAQ và dữ liệu hội thoại.¹⁴ Phương pháp đòi hỏi nhiều compute hơn trong quá trình ingestion và điều chỉnh cẩn thận ngưỡng tương đồng.

Recursive chunking áp dụng các quy tắc chia phân cấp, đầu tiên cố gắng chia lớn (ngắt section), sau đó dần dần nhỏ hơn (ngắt đoạn, ngắt câu) cho đến khi chunk đạt kích thước mục tiêu. RecursiveCharacterTextSplitter của LangChain triển khai pattern này, đạt hiệu suất mạnh mẽ trên các loại tài liệu đa dạng mà không cần điều chỉnh cho từng corpus. Recursive chunking cân bằng sự đơn giản triển khai với chất lượng retrieval, khiến nó là khuyến nghị mặc định cho hệ thống mới.

Page-level chunking xuất hiện từ benchmark của NVIDIA cho thấy độ chính xác 0.648 với variance thấp nhất trên các loại tài liệu.¹⁵ Đối với tài liệu có cấu trúc như báo cáo và bài nghiên cứu, coi mỗi trang là một chunk bảo toàn các mối quan hệ không gian và tham chiếu chéo. Phương pháp page-level hoạt động kém cho tài liệu thiếu ranh giới trang rõ ràng (HTML, chat log, code) nhưng xuất sắc cho corpus nặng PDF.

Hierarchical chunking xây dựng chỉ mục đa cấp với độ chi tiết lồng nhau—cấp section, subsection, đoạn và câu. Retrieval đầu tiên xác định các section liên quan, sau đó đào sâu vào các đ

[Nội dung bị cắt ngắn để dịch]