Anthropic Exam ProDomain 3: Integration·Task 3.5
Thiết kế pipeline RAG, chia chunk và đánh chỉ mục
Khi nào cần RAG, chia chunk theo hình dạng dữ liệu, contextual retrieval giảm truy xuất hỏng ra sao, và chọn embedding, chỉ mục cho một pipeline RAG.
- 7 phút đọc
- Đối chiếu docs 02/11/2026
- 5 nguồn
Đọc xong bạn nắm được
- Quyết định khi nào đưa cả kho tài liệu vào prompt thay vì dựng RAG
- Mô tả các bước của pipeline RAG từ nạp tài liệu tới dựng prompt
- Chọn cách chia chunk theo loại tài liệu
- Hiểu contextual retrieval, và đánh chỉ mục bằng embedding lẫn BM25
- Biết chỗ cần xem đầu tiên khi RAG bắt đầu trả lời sai
RAG (retrieval-augmented generation) là cách cho Claude trả lời dựa trên tài liệu của bạn: tìm những đoạn liên quan rồi đưa vào prompt. Chất lượng câu trả lời phụ thuộc rất nhiều vào khâu tìm. Claude không thể trả lời đúng từ một đoạn tài liệu sai hay thiếu.
Bài này giúp bạn trả lời: có cần RAG không, chia tài liệu thành đoạn (chunk) thế nào, và đánh chỉ mục (index) ra sao để tìm đúng?
Ví dụ xuyên suốt: kho tài liệu của một hãng thiết bị y tế
Một hãng sản xuất máy theo dõi bệnh nhân muốn trợ lý trả lời câu hỏi của kỹ thuật viên bệnh viện. Kho tài liệu gồm ba loại:
- Sổ tay vận hành và bảo trì: mỗi cuốn vài trăm trang, chia chương, mục, bảng.
- Phiếu bảo hành và phiếu sự cố: hàng chục nghìn bản ghi ngắn, mỗi phiếu vài dòng.
- Đặc tả firmware: mã nguồn và tài liệu đặc tả phân cấp theo module.
Kỹ thuật viên hỏi kiểu "máy báo lỗi E-417 khi đo SpO2 thì làm gì", có mã lỗi chính xác lẫn mô tả bằng lời.
Có cần RAG không
Bài viết về contextual retrieval của Anthropic nói: nếu kho kiến thức nhỏ hơn khoảng 200.000 token (khoảng 500 trang), có thể đưa cả kho vào prompt, không cần RAG. Kết hợp prompt caching, bài viết nói độ trễ giảm hơn 2 lần và chi phí giảm tới 90% cho phần dùng lại.
Kho của hãng thiết bị lớn hơn nhiều, nên cần RAG. Nhưng nếu một trợ lý khác chỉ cần một cuốn sổ tay 300 trang, đưa cả cuốn vào prompt có cache thường đơn giản và chính xác hơn dựng cả một pipeline.
Các bước của pipeline
| Giai đoạn | Việc |
|---|---|
| Nạp tài liệu | Đọc file, tách văn bản và bảng, gắn metadata (nguồn, phiên bản, ngày, quyền truy cập) |
| Chia chunk | Cắt thành đoạn theo hình dạng tài liệu |
| Đánh chỉ mục | Tạo embedding cho mỗi chunk và lưu vào vector store; đồng thời dựng chỉ mục từ khoá (BM25) |
| Truy xuất | Nhận câu hỏi, tìm trên cả hai chỉ mục, gộp kết quả, có thể xếp hạng lại (rerank) |
| Dựng prompt | Đưa các chunk tìm được, kèm nguồn, vào prompt để Claude trả lời và trích dẫn |
| Làm mới | Khi tài liệu đổi, chunk lại, embed lại, cập nhật chỉ mục |
Metadata về quyền truy cập phải gắn từ lúc nạp, để khâu truy xuất lọc được theo người hỏi (bài 3.2).
Chia chunk theo hình dạng dữ liệu
Bài viết về contextual retrieval nói kích thước chunk, ranh giới chunk và độ chồng lấn giữa các chunk đều ảnh hưởng tới kết quả truy xuất. Không có một kích thước đúng cho mọi kho. Câu luyện thi ghép cách chia với loại tài liệu như sau:
| Loại tài liệu | Cách chia hợp | Trong ví dụ |
|---|---|---|
| Tài liệu dài có cấu trúc | Chia theo ngữ nghĩa ở ranh giới đoạn hay điều khoản; chia phân cấp theo chương, mục | Sổ tay vận hành |
| Bản ghi ngắn, rời rạc | Mỗi bản ghi một chunk; hoặc chia cố định có chồng lấn khi các bản ghi dài gần bằng nhau | Phiếu bảo hành, phiếu sự cố |
| Code hoặc đặc tả phân cấp | Chia theo hàm hoặc theo mục; chia theo cây, bám cấu trúc code hay đặc tả | Firmware |
Contextual retrieval: chunk mất ngữ cảnh
Một chunk tách ra khỏi tài liệu thường mất ngữ cảnh. Bài viết lấy ví dụ một chunk chỉ ghi doanh thu tăng 3% so với quý trước, mà không nói công ty nào, quý nào. Trong ví dụ của hãng thiết bị, một chunk "Thay cảm biến theo bước 4.2" không nói đó là model máy nào.
Contextual retrieval sửa bằng cách, trước khi embed, nhờ Claude viết một đoạn ngữ cảnh ngắn (thường 50 tới 100 token) cho mỗi chunk dựa trên cả tài liệu, rồi ghép vào đầu chunk. Đoạn ngữ cảnh được đưa vào cả embedding lẫn chỉ mục BM25. Kết quả trong bài viết, đo bằng tỉ lệ không tìm được đoạn cần trong 20 đoạn đầu:
| Cách | Giảm tỉ lệ truy xuất hỏng |
|---|---|
| Contextual embeddings | 35% |
| Contextual embeddings + contextual BM25 | 49% |
| Thêm bước rerank | 67% |
Chi phí tạo ngữ cảnh được giữ thấp nhờ prompt caching: cả tài liệu được cache một lần rồi dùng lại cho mọi chunk của nó; bài viết ước tính khoảng 1,02 USD cho mỗi triệu token tài liệu. Hướng dẫn trong Cookbook nhấn mạnh phải xử lý lần lượt từng tài liệu, không trộn ngẫu nhiên chunk của nhiều tài liệu, thì cache mới trúng.
Embedding và chỉ mục
- Anthropic không có model embedding riêng. Docs gợi ý Voyage AI, nhưng khuyên tự đánh giá nhiều nhà cung cấp. Voyage có model chung, model cho code, cho pháp lý, cho tài chính, và một model tạo vector cho chunk mang sẵn ngữ cảnh của cả tài liệu.
- Ghi rõ loại đầu vào. Docs dặn khi dùng cho truy xuất, đặt
input_typelàdocumentkhi embed chunk vàquerykhi embed câu hỏi; không bỏ trống. - Hai loại chỉ mục bổ sung nhau. Bài viết nói embedding giỏi bắt ý nghĩa nhưng có thể lỡ những chỗ khớp chính xác; BM25 đặc biệt hiệu quả với mã định danh và thuật ngữ kỹ thuật. Câu hỏi có "E-417" cần BM25 (bài 3.6).
- Cùng một model cho chunk và câu hỏi. Đổi model embedding mà không embed lại cả kho thì vector của câu hỏi và của chunk không còn so được với nhau.
Bài viết cũng khuyên luôn chạy đánh giá: đo tỉ lệ tìm đúng đoạn trên một bộ câu hỏi có đáp án sẵn mỗi khi đổi cách chia, đổi model embedding hay làm mới kho.