RAG đa phương thức: chọn kệ trước model

RAG đa phương thức: chọn kệ trước model

Đừng triển khai multimodal RAG vì demo đẹp. Hãy quyết định trước tài liệu cần được xếp kệ, chấm điểm và truy vấn ra sao.

Bạn có chắc team mình cần multimodal RAG không, hay chỉ đang thấy một notebook Colab trả lời được cả text, bảng, công thức, hình ảnh rồi tim đập nhanh hơn bình thường?

Mình hỏi hơi phũ, vì rất nhiều team triển khai RAG đang mắc một lỗi quen: thấy tài liệu có ảnh và bảng thì lập tức nghĩ “phải dùng pipeline đa phương thức”. Nghe hợp lý. PDF research report có chart, báo cáo tài chính có bảng, tài liệu kỹ thuật có sơ đồ, invoice có layout. Nếu chỉ chunk text thì mất ngữ cảnh.

Nhưng phản đề của mình là: multimodal RAG không bắt đầu từ model nhìn ảnh, mà bắt đầu từ quyết định bạn muốn lưu tài liệu theo đơn vị nào để truy xuất lại được.

Nếu ví hệ thống RAG như thư viện, thì model không phải thủ thư toàn năng. Việc đầu tiên là bạn quyết định sách được xếp theo kệ nào, thẻ mượn ghi metadata gì, và khi người hỏi cần “biểu đồ trang 7” thì hệ thống có tìm đúng ngăn không.

Sơ đồ minh họa cho bài RAG đa phương thức: chọn kệ trước model

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu thật: không phải đọc mọi thứ, mà gọi đúng mảnh

RAG-Anything trong tutorial chính cho thấy một hướng đáng chú ý: thay vì coi PDF là một cục text dài, nó chuyển tài liệu thành content_list — danh sách các block có cấu trúc gồm text, table, equation, image, kèm caption, footnote, page index và đường dẫn ảnh.

Dịch sang tiếng người: mỗi phần trong tài liệu được cấp một “thẻ thư viện” riêng. Đoạn văn là một thẻ. Bảng là một thẻ. Công thức là một thẻ. Hình ảnh là một thẻ. Khi truy vấn, hệ thống không phải lục nguyên cuốn PDF, mà tìm đúng loại mảnh phù hợp.

Đây là điểm nhiều team hiểu sai. Multimodal retrieval — truy xuất đa phương thức — không có nghĩa là cứ ném ảnh, bảng, chữ vào một model lớn rồi cầu may. Nó là bài toán thiết kế kho lưu trữ:

Nếu không trả lời mấy câu này, bạn chỉ đang xây một phòng đọc rất đẹp nhưng sách chưa dán mã phân loại.

Checklist trước khi mở Colab

Trước khi bắt tay cài RAG-Anything, mình sẽ ép team trả lời 5 câu. Không phải để làm màu quy trình, mà để tránh demo chạy được rồi production đứng hình.

1. Tài liệu của bạn có thật sự đa phương thức không?
Nếu 95% câu hỏi chỉ nằm trong text, dùng OCR tốt cộng RAG text có thể đủ. Đừng kéo vision model vào chỉ vì PDF có logo công ty.

2. Người dùng hỏi về “nội dung” hay “vị trí”?
Câu “metric của model A là gì?” khác với “bảng ở trang 3 ghi gì?”. Câu đầu cần semantic retrieval — tìm theo nghĩa. Câu sau cần metadata như page index, caption, table id.

3. Bảng và công thức có cần trả lời chính xác từng field không?
Nếu có, bạn cần evaluation theo field, giống tinh thần schema-guided evaluation — chấm từng trường theo schema định trước — trong workflow Lift. RAG trả lời nghe trơn tru nhưng sai một số trong bảng thì vẫn là hỏng.

4. Bạn có test data đủ giống đời thật chưa?
Pinecone nhấn mạnh chuyện tạo test data lặp lại được, đủ lớn và có metadata. Với RAG đa phương thức cũng vậy: đừng chỉ test bằng một PDF sạch sẽ. Hãy tạo tài liệu có bảng na ná nhau, chart dễ nhầm, footnote lắt léo, caption thiếu chữ.

5. Bạn sẽ chọn retrieval mode theo tình huống nào?
RAG-Anything thử các mode như naive, local, global, hybrid. Hybrid retrieval — truy xuất lai — thường kết hợp nhiều tín hiệu thay vì chỉ một kiểu tìm. Nhưng “hybrid” không mặc định thắng; nó cần query routing và đo chất lượng.

Playbook một buổi: dựng pipeline để ra quyết định

Bạn có thể làm bản thử trong một buổi chiều, nhưng mục tiêu không phải khoe “chat với PDF”. Mục tiêu là trả lời: team mình có nên đầu tư multimodal RAG không, và nếu có thì phần nào đáng làm trước?

Bước 1: Chọn 3 loại câu hỏi, không chọn 30

Lấy 3 nhóm query thật từ sản phẩm hoặc nội bộ:

Ví dụ cụ thể: giả sử team bạn làm hệ thống hỏi đáp báo cáo nghiên cứu. Đừng bắt đầu bằng 200 PDF. Hãy chọn 5 tài liệu đại diện, mỗi tài liệu có ít nhất một bảng, một hình, một đoạn giải thích, và một chỗ dễ gây nhầm giữa validation và test.

Bước 2: Biến tài liệu thành block có chủ đích

Đây là nơi content_list đáng học. Bạn không cần copy nguyên notebook, nhưng nên giữ tư duy block hóa:

{
  "type": "table",
  "page": 3,
  "caption": "Model performance on test set",
  "content": "...",
  "source_id": "report_01",
  "quality_flag": "synthetic_controlled"
}

Với image, giữ image_path, caption và page. Với equation, giữ biểu thức và đoạn text gần nó. Với text, giữ section heading.

Điểm quan trọng: metadata không phải phụ kiện. Nó là đường dẫn giữa câu trả lời và bằng chứng. Không có nó, bạn khó debug vì sao model trích sai.

Bước 3: Chạy ít nhất 3 kiểu retrieval

Đừng chỉ chạy mode mặc định. Hãy so sánh:

| Mode | Khi đáng thử | Rủi ro |
|---|---|---|
| Naive | Baseline nhanh, kiểm tra pipeline sống chưa | Dễ bỏ sót cấu trúc tài liệu |
| Local | Câu hỏi bám vào một vùng tài liệu cụ thể | Có thể thiếu bức tranh tổng thể |
| Global | Câu hỏi cần tổng hợp toàn tài liệu | Dễ kéo nhiều nhiễu vào context |
| Hybrid | Query lẫn text, bảng, hình, metadata | Tốn công tuning và chấm điểm |

Bản chất thật sự: bạn không chọn mode theo tên, bạn chọn theo loại câu hỏi. Một hệ thống tốt có thể route query “bảng trang 4” khác với query “kết luận chính của báo cáo”.

Bước 4: Chấm theo field, không chấm theo cảm giác

Đây là nơi nguồn về Lift rất đáng kéo vào cách nghĩ. Với PDF extraction, họ tạo tài liệu synthetic có distractor rồi chấm từng field như title, dataset, metric, limitation, repo link.

Áp dụng sang RAG đa phương thức, bạn có thể tạo rubric nhỏ:

Nếu chỉ hỏi vài câu rồi thấy model trả lời tự tin, bạn đang chấm thủ thư bằng giọng nói dễ nghe, không chấm xem lấy đúng sách chưa.

Pitfall: demo Colab sạch không giống kho tài liệu thật

Tutorial RAG-Anything dùng synthetic report để quan sát rõ text, table, equation và figure. Cách này tốt cho học cơ chế. Nhưng khi bước sang production, synthetic document chỉ là bài kiểm tra nhập môn.

Hình dung thế này: thư viện demo có 20 cuốn, bìa mới, mã kệ rõ ràng. Thư viện thật có sách cũ, trang scan nghiêng, mục lục lệch, bản phụ lục không đánh số, hai cuốn cùng tên khác năm. RAG của bạn phải sống trong thư viện thật đó.

Vài bẫy dễ dính:

Bẫy 1: gom mọi thứ vào embedding duy nhất.
Embedding — vector biểu diễn ngữ nghĩa — rất hữu ích, nhưng nếu nén cả bảng phức tạp thành một vector, bạn có thể mất quan hệ hàng-cột. Với bảng quan trọng, hãy cân nhắc lưu thêm dạng structured text hoặc JSON.

Bẫy 2: vision model thành điểm nghẽn chi phí.
Không phải ảnh nào cũng cần model nhìn ảnh. Chart có caption tốt có thể truy bằng caption trước, chỉ gọi vision khi query thật sự cần đọc hình.

Bẫy 3: context window bị nhồi quá tay.
Context window là vùng ngữ cảnh model xử lý trong một lượt. Nhồi nhiều block “có vẻ liên quan” làm tăng chi phí và có thể khiến model lẫn. Retrieval tốt là biết bỏ bớt.

Bẫy 4: không có dữ liệu test theo quy mô.
Pinecone nói đúng ở điểm này: test 500 nghìn vector không giống test hàng chục triệu vector. Với team nhỏ, bạn chưa cần nhảy thẳng lên quy mô lớn, nhưng cần dataset tạo lại được để so sánh từng thay đổi pipeline.

Khung quyết định: khi nào nên triển khai multimodal RAG?

Nếu là mình, mình sẽ dùng khung 3 cửa trước khi commit roadmap.

Cửa 1: Giá trị nằm ở modality nào?
Nếu câu trả lời chủ yếu nằm trong text, làm text RAG tốt trước. Nếu bảng/công thức/hình ảnh quyết định độ đúng, mới mở multimodal.

Cửa 2: Bạn cần answer hay extraction?
Answer là trả lời câu hỏi. Extraction là lấy dữ liệu có schema. Với báo cáo tài chính, research PDF, hồ sơ kỹ thuật, nhiều bài toán cần extraction trước rồi mới hỏi đáp. Đừng dùng chatbot để thay database nếu thứ bạn cần là field chuẩn.

Cửa 3: Bạn có chấm được sai không?
Không có evaluation thì multimodal RAG chỉ là demo có nhiều loại file. Tối thiểu hãy có bộ câu hỏi vàng, expected block, expected field và case “không đủ thông tin”.

Sau bài này, thứ mình muốn bạn nghĩ khác là: đừng hỏi “tool nào đọc được PDF đa phương thức?”, hãy hỏi “đơn vị lưu trữ nào giúp mình truy xuất và kiểm chứng đúng?”

Model mới có thể đổi. API có thể đổi. Nhưng cách bạn chia tài liệu thành block, gắn metadata, tạo test data và chấm theo field sẽ quyết định hệ thống có đi xa được không.

Kệ sách xếp sai thì thủ thư giỏi mấy cũng phải chạy lòng vòng.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo