Multimodal RAG: Kiến trúc, đánh đổi và những gì thực sự hiệu quả trong thực tế

Bài viết này giả định độc giả đã nắm rõ RAG là gì, tại sao RAG cơ bản không hiệu quả ở quy mô lớn, và ý nghĩa của việc phân đoạn (chunking), nhúng (embedding) và truy xuất (retrieval). Chúng tôi bỏ qua các kiến thức cơ bản. Vấn đề của RAG chỉ dựa trên văn bản ở quy mô lớn Các quy trình RAG tiêu chuẩn giả định cơ sở tri thức của bạn là văn bản. Giả định này đúng cho đến khi bạn làm việc với dữ liệu doanh nghiệp – và dữ liệu doanh nghiệp hầu như không bao giờ chỉ là văn bản thuần túy. Đó là các tệp PDF được quét có bảng biểu, các bản trình bày có biểu đồ, các bản ghi âm cuộc họp, hình ảnh sản phẩm và các tệp CSV có cấu trúc tồn tại cùng với các tài liệu phi cấu trúc. Chạy RAG chỉ dựa trên văn bản trên kho dữ liệu này có nghĩa là bạn đang bỏ qua một lượng lớn thông tin một cách có hệ thống – bất cứ thứ gì không tồn tại qua quy trình OCR hoặc bước trích xuất văn bản. Các chế độ lỗi cụ thể là: Một bảng trong tệp PDF được trích xuất dưới dạng văn bản lộn xộn, làm mất hoàn toàn cấu trúc hàng-cột. Một biểu đồ trở thành một hình ảnh không có chú thích mà bộ nhúng văn bản của bạn không bao giờ nhìn thấy. Một bản ghi âm giọng nói được phiên âm qua ASR, làm mất đi ngữ điệu của người nói, sự nhấn mạnh và âm thanh phi ngôn ngữ. Một hóa đơn được quét với logo, dấu và chữ viết tay gần như vô hình đối với bộ truy xuất của bạn. RAG đa phương thức không giải quyết được tất cả những vấn đề này – nhưng nó trực tiếp giải quyết các vấn đề truy xuất và định vị thông tin phát sinh khi dữ liệu của bạn không phải là văn bản sạch. Ba mô hình kiến trúc Trước khi đi sâu vào các thư viện và mã, hãy xác định những gì bạn thực sự đang lựa chọn khi thiết kế một quy trình đa phương thức. Có ba mô hình truy xuất/kết hợp, và chúng có những đánh đổi khác biệt đáng kể. Mô hình 1: Trích xuất rồi nhúng (Kết hợp muộn / Chỉ mục riêng biệt) Đây là mô hình được triển khai rộng rãi nhất hiện nay. Ý tưởng rất đơn giản: xử lý từng phương thức thông qua một bộ trích xuất chuyên biệt, chuyển đổi mọi thứ thành văn bản hoặc các biểu diễn gần với văn bản, sau đó nhúng bằng cách sử dụng các nhúng văn bản tiêu chuẩn. Quy trình: PDF → PyMuPDF / Unstructured → văn bản + chú thích hình ảnh (qua GPT-4V hoặc LLaVA) Âm thanh → Whisper → văn bản phiên âm Hình ảnh → BLIP-2 / LLaVA → văn bản chú thích được tạo Tất cả các đầu ra → bộ nhúng văn bản (ví dụ: OpenAI ada-002, BGE-M3) → kho vector Ưu điểm: Vận hành đơn giản. Tái sử dụng cơ sở hạ tầng RAG văn bản hiện có của bạn. Bất kỳ LLM nào có khả năng xử lý văn bản đều trở thành bộ tạo của bạn – không yêu cầu LLM đa phương thức để tạo, chỉ cần cho bước chú thích. Nhược điểm: Bạn mất thông tin ở mỗi bước trích xuất. Một biểu đồ cột được chú thích là “biểu đồ cột thể hiện xu hướng doanh thu” không giống như chính biểu đồ đó. Cấu trúc bảng bị sụp đổ thành văn bản tuyến tính. Whisper rất xuất sắc nhưng vẫn là một bản phiên âm có mất mát – thông tin phi ngôn ngữ bị mất. Quan trọng nhất, việc chú thích qua GPT-4V trong quá trình nhập liệu tốn kém và chậm ở quy mô lớn. Khi nào nên sử dụng: Bạn có một kho dữ liệu chủ yếu là văn bản với một số hình ảnh/bảng nhúng. Ngân sách của bạn không hỗ trợ cơ sở hạ tầng truy xuất đa phương thức gốc. Bạn cần triển khai nhanh chóng và yêu cầu chất lượng truy xuất của bạn ở mức vừa phải. Mô hình 2: Nhúng đa phương thức gốc (Kết hợp sớm / Không gian vector chung) Thay vì chuyển đổi mọi thứ thành văn bản, bạn nhúng trực tiếp từng phương thức vào một không gian vector chung bằng cách sử dụng bộ mã hóa đa phương thức. CLIP là ví dụ điển hình – nó ánh xạ văn bản và hình ảnh vào cùng một không gian 512 chiều, cho phép các truy vấn văn bản truy xuất hình ảnh trực tiếp mà không cần chú thích. Quy trình: Hình ảnh → bộ mã hóa hình ảnh CLIP → vector hình ảnh → kho vector (chỉ mục A) Văn bản/tài liệu → bộ mã hóa văn bản (ada-002 hoặc BGE) → vector văn bản → kho vector (chỉ mục B) Truy vấn → bộ mã hóa văn bản CLIP → truy xuất từ cả hai chỉ mục → sắp xếp lại → LLM đa phương thức Thiết lập mã với LlamaIndex: from llama_index.c `ore.indices.multi_modal.base` nhập `MultiModalVectorStoreIndex` `llama_index.vector_stores.qdrant` nhập `QdrantVectorStore` `llama_index.embeddings.clip` nhập `ClipEmbedding` `qdrant_client` Hai kho lưu trữ riêng biệt — một cho văn bản, một cho hình ảnh. `client = qdrant_client.QdrantClient(host="localhost", port=6333)` `text_store = QdrantVectorStore(client=client, collection_name="text_docs")` `image_store = QdrantVectorStore(client=client, collection_name="image_docs")` `storage_context = StorageContext.from_defaults(` `vector_store=text_store,` `image_store=image_store` `)` CLIP nhúng hình ảnh; bộ nhúng văn bản xử lý các đoạn văn bản. `index = MultiModalVectorStoreIndex.from_documents(` `documents,` `storage_context=storage_context,` `image_embed_model=ClipEmbedding()` `)` Hai bộ sưu tập Qdrant riêng biệt — một cho các đoạn văn bản (1536 chiều với ada-002), một cho các nhúng hình ảnh (512 chiều với CLIP). Tại thời điểm truy vấn, hai tìm kiếm tương đồng chạy song song và kết quả được hợp nhất trước khi tạo. Ưu điểm: Không có bước tạo chú thích giúp quá trình nhập liệu nhanh hơn. Truy xuất đa phương thức là bản địa — một truy vấn văn bản có thể trực tiếp kéo một biểu đồ liên quan. ImageBind (phiên bản kế nhiệm của CLIP của Meta) mở rộng điều này sang 6 phương thức: văn bản, hình ảnh, âm thanh, độ sâu, nhiệt và IMU — một không gian nhúng duy nhất cho mọi thứ. Nhược điểm: Nhúng 512 chiều của CLIP có dung lượng tương đối thấp. Suy luận hình ảnh phức tạp, hiểu bảng và bố cục tài liệu không được nắm bắt tốt trong một vectơ duy nhất. Sự căn chỉnh đa phương thức được đào tạo trên các cặp hình ảnh-văn bản tự nhiên — nó suy giảm trên các sơ đồ kỹ thuật, biểu đồ khoa học và biểu đồ chuyên biệt trừ khi được tinh chỉnh. Khi nào nên sử dụng: Tập dữ liệu nặng về hình ảnh (danh mục sản phẩm, quét y tế, tài liệu khoa học có hình minh họa). Khi cần truy vấn đa phương thức (tìm hình ảnh bằng văn bản, tìm hình ảnh tương tự). Âm thanh + hình ảnh + văn bản trong một bước truy xuất là trường hợp sử dụng cho ImageBind. Mô hình 3: ColPali / Tương tác muộn — Giải pháp tốt nhất hiện tại cho khối lượng công việc nặng về tài liệu. Đây là sự phát triển kiến trúc quan trọng nhất trong truy xuất đa phương thức trong năm qua và vẫn chưa được sử dụng rộng rãi trong sản xuất. Truy xuất bộ mã hóa kép tiêu chuẩn (CLIP, ada-002) nén một trang tài liệu thành một vectơ duy nhất. Đó là một nút thắt cổ chai nghiêm trọng — không thể chứa tất cả nội dung ngữ nghĩa của một trang PDF phức tạp vào một vectơ 512 hoặc 1536 chiều. ColPali áp dụng một cách tiếp cận khác: nó mã hóa từng phần hình ảnh của một trang tài liệu thành vectơ riêng, tạo ra một biểu diễn đa vectơ cho mỗi trang. Tại thời điểm truy vấn, sự tương đồng.