RAG & Knowledge Base — Xây dựng kho tri thức cho AI Agent

Thu, 14 May 2026 00:00:00 +0700

1. Tại sao cần RAG thay vì chỉ dùng LLM thuần?

Khi triển khai AI Agent cho doanh nghiệp, câu hỏi đầu tiên thường gặp là:

“Chúng tôi đã mua API của GPT-4, vì sao chatbot vẫn trả lời sai thông tin nội bộ?”

Nguyên nhân cốt lõi: LLM không biết những gì chưa được huấn luyện vào nó. Dữ liệu nội bộ — quy trình, chính sách, sản phẩm, bảng giá, hướng dẫn nghiệp vụ — không bao giờ xuất hiện trong tập huấn luyện của bất kỳ LLM đại chúng nào.

RAG (Retrieval-Augmented Generation) giải quyết bài toán này: thay vì cố nhét toàn bộ kiến thức vào LLM, bạn truy xuất đúng đoạn thông tin liên quan từ kho tri thức rồi đưa vào ngữ cảnh (context) của LLM trước khi sinh câu trả lời.

1.1. So sánh 3 cách tiếp cận

Phương pháp	Cơ chế	Ưu điểm	Nhược điểm
LLM thuần (zero-shot)	Chỉ dùng kiến thức mô hình	Đơn giản, không cần hạ tầng thêm	Không biết dữ liệu nội bộ, dễ hallucinate
Fine-tuning	Huấn luyện lại mô hình với dữ liệu mới	Mô hình “hiểu sâu” domain	Đắt, lâu, khó cập nhật, cần GPU lớn
RAG	Truy xuất + sinh câu trả lời	Cập nhật tri thức realtime, kiểm soát nguồn	Cần hạ tầng vector DB, pipeline xử lý tài liệu

Kết luận thực chiến: với 95% dự án doanh nghiệp, RAG là lựa chọn tối ưu về chi phí, tốc độ triển khai và khả năng bảo trì.

2. Mục tiêu của một Knowledge Base hiệu quả

Trước khi bắt tay xây dựng, cần xác định rõ:

Phạm vi tri thức: loại tài liệu nào, bao nhiêu trang, cập nhật tần suất ra sao?
Người dùng cuối: nội bộ (nhân viên) hay bên ngoài (khách hàng)?
Ngôn ngữ & chất lượng nguồn: tiếng Việt, tiếng Anh hay song ngữ? Văn bản có cấu trúc hay tự do?
Yêu cầu bảo mật: tri thức có phân quyền theo bộ phận không?
Kỳ vọng độ chính xác: tỷ lệ câu trả lời đúng mục tiêu là bao nhiêu? (gợi ý: ≥ 85% cho MVP)

3. Kiến trúc RAG tổng thể

┌──────────────────────────────────────────────────────────────┐
│ OFFLINE PIPELINE (Ingestion) │
│ │
│ Nguồn tài liệu Xử lý & Index │
│ ┌──────────────┐ ┌──────────────────────────────────┐ │
│ │ PDF / Word │ │ 1. Parse & Clean │ │
│ │ Excel / CSV │───▶│ 2. Chunk (split văn bản) │ │
│ │ Web scrape │ │ 3. Embed (chuyển thành vector) │ │
│ │ Confluence │ │ 4. Index → Vector DB │ │
│ │ SharePoint │ └──────────────────────────────────┘ │
│ └──────────────┘ │ │
└─────────────────────────────────────┼────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ Vector Database (Persistent Store) │
│ pgvector / Qdrant / Weaviate / Milvus │
└──────────────────────────────┬───────────────────────────────┘
│
┌──────────────────────────────┼───────────────────────────────┐
│ ONLINE PIPELINE (Query-time RAG) │
│ │ │
│ Người dùng ▼ │
│ ┌──────────┐ ┌────────────────────────┐ │
│ │ Query │──▶│ Embed Query │ │
│ └──────────┘ │ → Semantic Search │ │
│ │ → Retrieve Top-K docs │ │
│ └───────────┬────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────┐ │
│ │ Augment Prompt │ │
│ │ (context + question) │ │
│ └───────────┬────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────┐ │
│ │ LLM Generate Answer │ │
│ │ + Cite Source │ │
│ └────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘

4. Pipeline xử lý tài liệu: Chunking → Embedding → Indexing

Đây là giai đoạn quyết định chất lượng toàn bộ hệ thống RAG. Làm kém ở đây thì LLM tốt đến đâu cũng vô dụng.

4.1. Bước 1 — Parse & Clean

Loại tài liệu	Công cụ parse gợi ý	Lưu ý
PDF	`pdfplumber`, `pypdf2`, `unstructured`	Cẩn thận PDF scan (dùng OCR nếu cần)
Word (.docx)	`python-docx`, `unstructured`	Giữ nguyên cấu trúc heading/table
Excel / CSV	`pandas`	Chuyển bảng thành văn bản có nhãn cột
HTML / Web	`BeautifulSoup`, `trafilatura`	Loại bỏ navigation, ads, footer
Confluence	Confluence REST API	Export sang Markdown trước

Làm sạch bắt buộc:

Xóa header/footer lặp lại, số trang, watermark
Chuẩn hóa khoảng trắng, ký tự đặc biệt
Tách bảng thành văn bản có cấu trúc (đừng bỏ qua dữ liệu trong bảng)

4.2. Bước 2 — Chunking (Chia đoạn)

Đây là bước kỹ thuật tinh tế nhất. Chunk quá ngắn → mất ngữ cảnh. Chunk quá dài → nhiễu, tốn token.

Chiến lược Chunking	Mô tả	Phù hợp với
Fixed-size	Chia theo số token/ký tự cố định (VD: 512 token)	Tài liệu không có cấu trúc rõ
Recursive	Ưu tiên chia theo `\n\n`, rồi `\n`, rồi `.`	Văn bản tự do dài
Semantic	Chia theo ranh giới nghĩa (dùng embedding)	Tài liệu kỹ thuật, quy trình
Document-based	Chia theo tiêu đề (H1/H2/H3)	Tài liệu có cấu trúc rõ ràng
Sliding Window	Chunk chồng lấp (overlap 10–20%)	Tránh mất thông tin ở ranh giới

Gợi ý thực chiến:

Bắt đầu với chunk size ~512 token, overlap ~10%
Đính kèm metadata vào mỗi chunk: tên tài liệu, phần/mục, ngày cập nhật
Lưu cả chunk và summary của tài liệu gốc (để hỗ trợ trả lời câu hỏi tổng quan)

4.3. Bước 3 — Embedding

Embedding chuyển văn bản thành vector số học để tính toán độ tương đồng ngữ nghĩa.

Model Embedding	Chiều vector	Ngôn ngữ	Chi phí	Ghi chú
`text-embedding-3-small` (OpenAI)	1536	Đa ngôn ngữ	~$0.02/1M token	Tốt cho tiếng Việt
`text-embedding-3-large` (OpenAI)	3072	Đa ngôn ngữ	~$0.13/1M token	Độ chính xác cao hơn
`multilingual-e5-large` (Microsoft)	1024	Đa ngôn ngữ	Miễn phí (self-host)	Hiệu quả tiếng Việt khá tốt
`bge-m3` (BAAI)	1024	Đa ngôn ngữ	Miễn phí (self-host)	Mạnh cho tiếng Á
`nomic-embed-text` (Ollama)	768	Đa ngôn ngữ	Miễn phí (local)	Phù hợp môi trường offline

Nguyên tắc quan trọng: dùng cùng một model embedding cho cả quá trình index tài liệu và embed query người dùng.

4.4. Bước 4 — Indexing vào Vector DB

Mỗi chunk sau khi embed sẽ được lưu kèm:

Vector: biểu diễn ngữ nghĩa
Metadata: nguồn, ngày, danh mục, quyền truy cập
Nội dung gốc (hoặc ID tham chiếu): để trả lại cho LLM

5. So sánh Vector Database

	pgvector	Qdrant	Weaviate	Milvus	Chroma
Loại	Extension PostgreSQL	Standalone DB	Standalone DB	Standalone DB	Embedded/Client
Self-host	✅ Dễ	✅ Docker	✅ Docker	✅ Docker/K8s	✅ Python lib
Cloud managed	✅ (Supabase)	✅ Qdrant Cloud	✅ WCS	✅ Zilliz	❌
Hiệu suất (10M+ vectors)	⚠️ Vừa	✅ Tốt	✅ Tốt	✅ Rất tốt	❌ Không phù hợp
Hybrid search (vector + keyword)	⚠️ Cần cấu hình	✅ Có sẵn	✅ Có sẵn	✅ Có sẵn	❌
Metadata filtering	✅	✅	✅	✅	✅
Phù hợp cho	Stack đã có PostgreSQL, tập nhỏ–vừa	Production, startup	Production, graph-based	Scale lớn, enterprise	Prototype, lab

Khuyến nghị thực chiến:

Dự án mới, stack PostgreSQL: bắt đầu với pgvector trên Supabase → đơn giản, chi phí thấp
Production cần hybrid search: chọn Qdrant — Docker-native, API tốt, tài liệu rõ
Scale lớn (>10M vectors): Milvus trên Kubernetes

6. Workflow Ingestion & Cập nhật tri thức

Một Knowledge Base không cập nhật định kỳ sẽ nhanh chóng trở thành gánh nặng thay vì tài sản.

6.1. Sơ đồ ingestion pipeline

# Pseudo workflow: document_ingestion_pipeline
name: kb_ingestion_pipeline
trigger:
- manual_upload
- scheduled_sync: "0 2 * * *" # Chạy lúc 2h sáng mỗi ngày
- webhook: document_updated
steps:
- name: fetch_documents
action: pull_from_source
sources:
- type: sharepoint
path: /sites/company/Shared Documents/Policies
- type: confluence
space: PROD
- type: local_upload
bucket: s3://kb-raw-docs
- name: parse_and_clean
action: extract_text
options:
ocr_fallback: true
remove_duplicates: true
- name: chunk_documents
action: split_text
options:
chunk_size: 512
overlap: 50
strategy: recursive
- name: embed_chunks
action: embed
model: text-embedding-3-small
batch_size: 100
- name: upsert_to_vector_db
action: upsert
target: qdrant
collection: company_kb
deduplication_key: doc_hash
- name: notify_completion
action: send_notification
channel: slack
message: "KB sync completed: {{ stats.added }} added, {{ stats.updated }} updated, {{ stats.deleted }} deleted"
on_error:
- log_to: elasticsearch
- alert: ops_team
- retry_strategy: exponential_backoff
max_retries: 3

6.2. Chiến lược cập nhật

Tình huống	Cách xử lý
Tài liệu mới	Thêm chunk mới, không xóa cũ
Tài liệu sửa đổi	So sánh hash → xóa chunk cũ → index lại
Tài liệu hết hạn/thu hồi	Đánh dấu `is_active: false` hoặc xóa hẳn
Thay đổi policy khẩn cấp	Trigger ingestion thủ công ngay lập tức

7. Thiết kế Query Pipeline hiệu quả

Truy xuất tốt đòi hỏi hơn chỉ “tìm kiếm vector gần nhất”.

7.1. Các kỹ thuật tăng chất lượng retrieval

Kỹ thuật	Mô tả	Khi nào dùng
Hybrid search	Kết hợp vector search + BM25 keyword	Khi người dùng dùng từ khoá chính xác (mã SKU, tên quy định)
Query rewriting	LLM viết lại query trước khi search	Query người dùng mơ hồ hoặc ngắn
HyDE (Hypothetical Document Embeddings)	LLM tạo tài liệu giả định, embed rồi search	Query dạng câu hỏi mở
Re-ranking	Dùng cross-encoder để re-rank top-K kết quả	Cần độ chính xác cao, có ngân sách latency
Metadata filtering	Lọc theo phòng ban, ngày, loại tài liệu	Hệ thống có phân quyền hoặc nhiều danh mục
Parent-child chunking	Truy xuất chunk nhỏ nhưng trả lại đoạn lớn hơn cho context	Câu hỏi cần ngữ cảnh rộng

7.2. Ví dụ prompt augmentation chuẩn

## System
Bạn là trợ lý AI của [Tên Công ty]. Nhiệm vụ của bạn là trả lời câu hỏi
dựa HOÀN TOÀN vào các đoạn thông tin được cung cấp bên dưới.
Nguyên tắc:
- Chỉ trả lời dựa trên thông tin trong [CONTEXT].
- Nếu không tìm thấy thông tin, hãy nói: "Tôi chưa có thông tin về vấn đề này.
Vui lòng liên hệ [bộ phận liên quan]."
- Không suy diễn hoặc bịa đặt thông tin.
- Trích dẫn nguồn tài liệu ở cuối câu trả lời khi có thể.
## Context
[CONTEXT]
{{ retrieved_chunks }}
[/CONTEXT]
## Câu hỏi
{{ user_query }}

8. Checklist chất lượng Knowledge Base

✅ Checklist chuẩn bị tài liệu

Xác định và liệt kê đầy đủ các nguồn tài liệu
Loại bỏ tài liệu hết hạn, mâu thuẫn nhau
Đảm bảo tài liệu có tiêu đề, ngày cập nhật, tác giả rõ ràng
Tài liệu dạng bảng đã được chuyển sang văn bản có cấu trúc
File scan đã được OCR và kiểm tra chất lượng nhận dạng

✅ Checklist pipeline kỹ thuật

Parser xử lý đúng định dạng PDF, Word, Excel của dự án
Chunk size và overlap đã thử nghiệm với ≥ 20 câu hỏi mẫu
Metadata đầy đủ: nguồn, ngày, phòng ban, is_active
Embedding model nhất quán (index và query)
Vector DB đã thiết lập backup và restore
Pipeline ingestion có xử lý lỗi và retry

✅ Checklist chất lượng retrieval

Precision@3: ≥ 80% câu hỏi mẫu có chunk đúng trong top-3
Câu hỏi về tài liệu đã xóa không trả lời thông tin cũ
Câu hỏi ngoài phạm vi được từ chối hoặc chuyển hướng đúng
Hybrid search đã bật nếu dữ liệu có nhiều mã/số/ký hiệu cụ thể
Thời gian truy xuất < 1 giây ở tải trung bình

✅ Checklist vận hành

Có quy trình cập nhật tài liệu rõ ràng (ai chịu trách nhiệm, tần suất)
Dashboard theo dõi: số chunk, số câu hỏi/ngày, tỷ lệ không tìm thấy
Lưu log đủ để trace: câu hỏi → chunk được dùng → câu trả lời
Quy trình xử lý phản hồi tiêu cực từ người dùng

9. Stack công nghệ khuyến nghị

Thành phần	Lựa chọn MVP	Lựa chọn Production	Ghi chú
Document parser	`unstructured` (Python)	`unstructured` + custom parser	Hỗ trợ 25+ định dạng
Chunking	LangChain `RecursiveCharacterTextSplitter`	Custom theo domain	Dễ bắt đầu, tuỳ chỉnh sau
Embedding	`text-embedding-3-small` (OpenAI)	`multilingual-e5-large` (self-host)	Self-host tiết kiệm chi phí dài hạn
Vector DB	`pgvector` (Supabase)	`Qdrant`	Nâng cấp khi tập > 500k chunks
Orchestration	LangChain / LlamaIndex	Semantic Kernel / custom	Tuỳ stack .NET hay Python
LLM	OpenAI GPT-4o-mini	OpenAI + Ollama hybrid	Ollama cho tài liệu nội bộ nhạy cảm
Pipeline Scheduler	n8n	n8n + Temporal	Temporal nếu pipeline phức tạp
Storage tài liệu gốc	MinIO / S3	MinIO cluster	Lưu file gốc tách biệt vector
Monitoring	Elasticsearch + Kibana	Elasticsearch + Grafana

10. KPI, ROI và chi phí vận hành

10.1. KPI cho Knowledge Base RAG

KPI	Định nghĩa	Mục tiêu MVP	Mục tiêu Production
Retrieval Precision@3	% query có chunk đúng trong top-3	≥ 75%	≥ 90%
Answer Accuracy	% câu trả lời đúng theo đánh giá	≥ 80%	≥ 90%
Fallback Rate	% câu hỏi không tìm được thông tin	≤ 20%	≤ 8%
Query Latency (P95)	Thời gian từ câu hỏi đến câu trả lời	≤ 5s	≤ 2s
KB Freshness	% tài liệu được cập nhật đúng chu kỳ	≥ 90%	≥ 98%

10.2. Ước lượng chi phí (Quy mô SMB)

Hạng mục	Chi phí thiết lập	Chi phí vận hành/tháng	Ghi chú
Embedding (OpenAI)	~$5–20 (index lần đầu)	~$2–10	Tùy số tài liệu và tần suất cập nhật
Vector DB (Qdrant Cloud)	$0 (Free tier)	$25–100	Tùy số vector và RAM
LLM API (GPT-4o-mini)	—	$20–80	Tùy lưu lượng query
Storage (MinIO/S3)	—	$5–20	Tùy dung lượng tài liệu gốc
Server pipeline (n8n)	$0 (self-host)	$10–30	VPS nhỏ là đủ
Tổng ước lượng	$20–50	$60–240	Có thể giảm 40–60% nếu self-host LLM

10.3. ROI tham chiếu

Nhân viên CS hiện xử lý 50 câu hỏi nội bộ/ngày × $0.5/câu = $750/tháng
Sau RAG: tự động 70% → tiết kiệm ~$525/tháng
Chi phí hệ thống RAG: ~$150/tháng
ROI tháng đầu: 250% | Hoàn vốn: < 30 ngày

11. Rủi ro và phương án giảm thiểu

Rủi ro	Mức độ	Cách giảm thiểu
Tài liệu nguồn chất lượng kém	Cao	Audit tài liệu trước khi index, lập quy trình duyệt nội dung
Hallucination do retrieval miss	Cao	Prompt nghiêm cấm ngoài context, thêm fallback rõ ràng
Chunk mất ngữ cảnh ở ranh giới	Trung bình	Dùng overlap chunking + parent-child retrieval
Tài liệu cũ không được cập nhật	Trung bình-Cao	Đặt TTL, cảnh báo tài liệu sắp hết hạn, phân công owner
Lộ tài liệu nội bộ nhạy cảm	Cao	Metadata-based ACL, lọc theo role trước khi trả chunk cho LLM
Chi phí embedding tăng đột biến	Thấp-Trung bình	Batch embedding, cache embedding, tránh re-index không cần thiết
Latency cao khi KB lớn	Trung bình	Tách collection theo domain, thêm re-ranking có điều kiện
Vendor lock-in model embedding	Thấp	Thiết kế abstraction layer cho embedding, sẵn sàng chuyển self-host

12. Roadmap triển khai 3 giai đoạn

Giai đoạn 1 (1–2 tuần): Nền móng & MVP

Audit và thu thập tài liệu nguồn (ưu tiên 50–100 tài liệu quan trọng nhất)
Thiết lập pipeline ingestion cơ bản: PDF/Word → chunk → embed → pgvector
Triển khai RAG chatbot MVP với prompt chuẩn
Kiểm thử với 30–50 câu hỏi mẫu, đo Precision@3
Kết quả: chatbot có thể trả lời 70%+ câu hỏi từ tài liệu đã index

Giai đoạn 2 (2–4 tuần): Tối ưu chất lượng

Phân tích lỗi từ giai đoạn 1, điều chỉnh chunk strategy
Bật hybrid search (vector + BM25)
Thêm metadata filtering theo phòng ban/danh mục
Triển khai pipeline cập nhật tự động (scheduler + webhook)
Dashboard theo dõi: fallback rate, latency, KB freshness
Kết quả: Precision@3 ≥ 85%, fallback rate ≤ 12%

Giai đoạn 3 (4–8 tuần): Sản xuất & Scale

Chuyển lên Qdrant hoặc vector DB production-grade
Triển khai ACL theo role người dùng
Thêm re-ranking cho query quan trọng
Tích hợp KB với AI Agent đa nhiệm (kết nối bài 2)
SLA monitoring, alerting và quy trình xử lý sự cố
Kết quả: Answer Accuracy ≥ 90%, hệ thống sẵn sàng production

13. Kết luận

RAG không chỉ là một kỹ thuật AI — đây là nền tảng để AI Agent thực sự hiểu doanh nghiệp của bạn.

Ba điều cốt lõi để RAG thành công:

Chất lượng tài liệu nguồn quyết định 50% kết quả. Garbage in → garbage out, dù dùng LLM nào.
Pipeline ingestion kỷ luật: chunk đúng chiến lược, embed nhất quán, cập nhật định kỳ.
Đo lường liên tục: Precision@3, fallback rate và KB freshness phải được theo dõi như SLA hệ thống.

Khi Knowledge Base được xây đúng, mỗi AI Agent trong hệ thống của bạn sẽ trả lời không chỉ thông minh — mà còn chính xác, có nguồn gốc và đáng tin cậy.

Tác giả: AI Agent Series | Cập nhật: 14/05/2026

Embedding on