Build a RAG App on AWS: Hướng dẫn kiến trúc từ Ingestion đến Querying
Xây dựng RAG app on AWS với S3, Lambda, API Gateway, Amazon Bedrock và vector database — kèm diagram và best practices
Trong bài viết này
- RAG là gì và vì sao nên build a RAG app on AWS?
- Kiến trúc tổng quan
- Giai đoạn 1 — Ingestion
- Giai đoạn 2 — Querying
- Chọn vector database trên AWS
- Best practices khi build a RAG app on AWS
- Tối ưu vector search với binary quantization
- Mở rộng kiến trúc
- Câu hỏi thường gặp (FAQ)
RAG là gì và vì sao nên build a RAG app on AWS?
Nếu bạn muốn build a RAG app on AWS, trước hết cần hiểu RAG (Retrieval-Augmented Generation) là gì. RAG là pattern giúp một LLM trả lời dựa trên dữ liệu thật của bạn, thay vì chỉ dựa vào những gì model “đoán” từ tri thức có sẵn. Thay vì fine-tune lại model mỗi khi dữ liệu thay đổi, bạn để model truy xuất (retrieve) đúng phần thông tin liên quan rồi mới sinh (generate) câu trả lời. Kết quả: câu trả lời bám sát nguồn, ít bịa (hallucinate) hơn, và cập nhật được theo thời gian.
AWS là nền tảng lý tưởng cho RAG vì mọi mảnh ghép đều có sẵn dưới dạng managed service: lưu trữ với S3, xử lý serverless với Lambda, expose API với API Gateway, embeddings và generation với Amazon Bedrock, và lưu vector với OpenSearch Serverless, DynamoDB hoặc Aurora. Về bản chất, một RAG app on AWS gồm hai giai đoạn: Ingestion (chuẩn bị tri thức) và Querying (dùng tri thức).
Kiến trúc tổng quan của một RAG app on AWS
Trước khi đi vào chi tiết, đây là toàn bộ kiến trúc. Hai giai đoạn chạy độc lập nhưng chia sẻ chung một vector database: Ingestion ghi (write) embeddings vào đó, còn Querying đọc (read) ra để tìm context. Vector DB chính là “bộ nhớ dài hạn” của cả hệ thống.
Hình 1 — Kiến trúc RAG app on AWS: Ingestion (nền) và Querying (real-time) dùng chung một Vector DB.
Giai đoạn 1 — Ingestion: biến raw data thành searchable knowledge
Mục tiêu của Ingestion là chuyển tài liệu thô thành một dạng mà model có thể “tìm kiếm theo ngữ nghĩa”. Luồng xử lý diễn ra như sau:
Hình 2 — Luồng Ingestion: S3 → Lambda → Chunking → Bedrock Titan Embeddings → Vector DB.
Tài liệu nằm trên S3 (hoặc bất kỳ internal data source nào). Mỗi khi có file mới, một Lambda ingestion function được kích hoạt (thường qua S3 event notification). Function này làm sạch, xử lý và chunk tài liệu thành các đơn vị nhỏ hơn mà model có thể tiêu hoá được.
Mỗi chunk được đưa qua Bedrock Titan Embeddings để biến thành một vector (embedding) — một dãy số biểu diễn ý nghĩa của đoạn văn bản. Các embedding này được lưu vào một vector database. Đây chính là searchable knowledge store của bạn.
Giai đoạn này có thể chạy liên tục ở background, giữ cho tri thức luôn tươi mới. Nhưng bạn cần chiến lược khi reindex: nếu một tài liệu chỉ thay đổi đúng một ký tự, bạn không muốn reprocess lại toàn bộ file. Vì vậy smart diffing, incremental updates và metadata checks trở nên quan trọng — để tránh chi phí không cần thiết và giữ ingestion hiệu quả.
Giai đoạn 2 — Querying: retrieve và generate câu trả lời
Đây là phần người dùng thực sự tương tác. Toàn bộ diễn ra real-time, thường trong vài trăm mili-giây:
Hình 3 — Luồng Querying: User → API Gateway → Lambda → Titan Embeddings → Vector DB → Bedrock LLM → User.
Người dùng đặt câu hỏi qua app. Request đi qua API Gateway vào một Lambda query function. Câu hỏi được embed bằng chính Bedrock Titan Embeddings (dùng cùng model với lúc ingest để cùng không gian vector). Embedding của câu hỏi được đem đi so khớp (similarity search) với vector database để lấy ra các chunk liên quan nhất.
Những chunk đó được truyền cho một Bedrock LLM (như Claude hoặc OpenAI) làm context để soạn câu trả lời cuối cùng. Câu trả lời quay ngược lại người dùng qua đúng đường API cũ. Pattern này đảm bảo LLM được grounded trên dữ liệu thật của bạn, chứ không phải phỏng đoán của model.
Chọn vector database trên AWS
Vector DB là trái tim của mọi RAG app on AWS. Ba lựa chọn phổ biến, mỗi cái hợp một bối cảnh khác nhau:
OpenSearch Serverless
Được thiết kế cho vector search quy mô lớn, hỗ trợ k-NN, hybrid search (kết hợp keyword + vector) và tự scale. Là lựa chọn mặc định cho phần lớn use case sản xuất khi bạn có hàng triệu chunk trở lên.
DynamoDB
Phù hợp khi dataset nhỏ–vừa và bạn muốn độ trễ thấp, chi phí vận hành gần như bằng không. Thường dùng khi số lượng vector khiêm tốn hoặc kết hợp brute-force search trong Lambda.
Aurora (pgvector)
Lý tưởng nếu team đã dùng PostgreSQL: bật extension pgvector là có ngay similarity search cạnh dữ liệu quan hệ, thuận tiện cho metadata filtering phức tạp trong cùng một truy vấn SQL.
Best practices khi build a RAG app on AWS
- Chunking hợp lý: chọn kích thước chunk vừa phải (khoảng 200–500 token) và cho overlap nhẹ để không cắt đứt ngữ cảnh giữa các đoạn.
- Đồng bộ embedding model: dùng đúng một model (Titan Embeddings) cho cả ingest và query để hai bên nằm chung không gian vector.
- Incremental reindex: dùng smart diffing và metadata checks để chỉ cập nhật phần thay đổi, tránh reprocess toàn bộ tài liệu.
- Bảo mật: phân quyền IAM tối thiểu cho từng Lambda, mã hoá S3 và vector DB, đặt API sau authorizer của API Gateway.
- Kiểm soát cost: cache câu hỏi lặp lại, giới hạn số chunk retrieve, và cân nhắc binary quantization cho vector store.
- Eval pipeline: đo chất lượng câu trả lời (faithfulness, relevance) trên tập test cố định trước mỗi lần thay đổi retrieval.
Tối ưu vector search với binary quantization
Phần lớn kiến trúc RAG phụ thuộc nặng vào vector search để gom context từ vector DB. Chính layer này có thể được làm tiết kiệm bộ nhớ tới 32 lần bằng binary quantization — kỹ thuật nén mỗi chiều của vector từ số thực (float32) xuống chỉ còn 1 bit. Với dataset lớn, đây là khác biệt giữa việc phải trả tiền cho hàng chục GB RAM và chỉ vài trăm MB, đổi lại độ chính xác giảm nhẹ (thường bù lại được bằng một bước re-rank trên tập nhỏ ứng viên).
Mở rộng kiến trúc
Đây là dạng cơ bản nhất của một RAG app on AWS, nhưng pattern không đổi kể cả khi hệ thống phát triển. Bạn có thể thêm dần: chunking thông minh hơn, retrieval tinh vi hơn (hybrid search, re-ranking), caching layer, orchestration, streaming responses, eval pipeline, hoặc multi-source ingestion — mà kiến trúc cốt lõi vẫn đứng vững.
Câu hỏi thường gặp (FAQ)
RAG là gì?
RAG (Retrieval-Augmented Generation) là pattern cho phép LLM truy xuất dữ liệu liên quan từ một knowledge store rồi mới sinh câu trả lời, giúp câu trả lời bám sát nguồn và ít hallucinate hơn.
Cần những AWS service nào để build a RAG app on AWS?
Tối thiểu bạn cần S3 (lưu tài liệu), Lambda (ingestion & query), API Gateway (expose API), Amazon Bedrock (Titan Embeddings + LLM) và một vector database như OpenSearch Serverless, DynamoDB hoặc Aurora.
Nên chọn vector database nào trên AWS?
OpenSearch Serverless cho quy mô lớn và hybrid search; DynamoDB cho dataset nhỏ–vừa cần độ trễ thấp; Aurora với pgvector nếu team đã dùng PostgreSQL và cần metadata filtering phức tạp.
Làm sao giảm chi phí khi ingest dữ liệu?
Dùng smart diffing, incremental updates và metadata checks để chỉ reprocess phần thay đổi thay vì toàn bộ tài liệu mỗi lần.
Binary quantization giúp gì cho vector search?
Nó nén mỗi chiều vector từ float32 xuống 1 bit, tiết kiệm bộ nhớ tới 32 lần, đổi lại độ chính xác giảm nhẹ và thường được bù bằng bước re-rank.
Kết luận
Để build a RAG app on AWS, hãy nhớ hai vòng lặp đơn giản: ingest để chuẩn bị tri thức, và query để dùng nó — với Bedrock lo phần embeddings và generation, còn vector DB đóng vai trò bộ nhớ chung. Bắt đầu từ phiên bản cơ bản này, rồi thêm chunking, retrieval, caching và eval khi nhu cầu tăng. Pattern vẫn nguyên vẹn; chỉ có từng mảnh là được nâng cấp.
Tài liệu tham khảo (external links)
- Amazon Bedrock — Knowledge Bases: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html
- Amazon Titan Embeddings: https://docs.aws.amazon.com/bedrock/latest/userguide/titan-embedding-models.html
- Amazon OpenSearch Serverless — Vector engine: https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-vector-search.html
Ghi chú: Nội dung tham khảo và diễn giải mở rộng từ pattern RAG on AWS phổ biến (lấy cảm hứng từ post của ByteByteGo), bổ sung chú thích và tối ưu SEO.
Vui lòng đăng nhập để bình luận.