- Để trích xuất thông tin từ tài liệu phức tạp, cách làm OCR và parsing truyền thống không thể bảo toàn ý nghĩa một cách đầy đủ
- Morphik triển khai phương pháp embedding tài liệu trực quan dựa trên mô hình ColPali, cho phép hiểu trực tiếp cả bảng biểu, biểu đồ và ngữ cảnh bố cục
- So với pipeline hiện có, phương pháp này vượt trội rõ rệt về độ chính xác và khả năng bảo toàn thông tin, đạt độ chính xác tối đa 95,56% trong các bài kiểm thử benchmark
- Ngoài ra, việc áp dụng MUVERA và Turbopuffer còn giúp tăng tốc độ trong truy xuất tài liệu ở quy mô lớn
- Trong tương lai, mục tiêu là tự động hóa công việc tài liệu thực tế như suy luận đa tài liệu, tích hợp workflow và diễn giải ở cấp độ chuyên gia
Giới hạn của việc parsing tài liệu phức tạp và khó khăn của RAG
- Khi cố gắng trích xuất thông tin từ tài liệu PDF phức tạp có trộn lẫn biểu đồ, sơ đồ và bảng, các pipeline OCR và parsing thường làm mất thông tin cần thiết
- Những tình huống thực tế như bảng lồng nhau, sơ đồ quan trọng, tài liệu kỹ thuật có nhiều chú thích, thậm chí cả hướng dẫn không có văn bản cho thấy rõ giới hạn của pipeline truyền thống
- Các bước trong pipeline truyền thống:
- Áp dụng OCR cho PDF (có thể đọc sai số hoặc ký tự)
- Dùng mô hình phát hiện bố cục để cố phân biệt bảng/sơ đồ (tỷ lệ thất bại cao)
- Khôi phục thứ tự đọc (có thể bỏ lỡ luồng trực quan)
- Nhận diện chú thích biểu đồ (thường làm mất sắc thái)
- Chia nhỏ văn bản (thông tin liên quan có thể bị tách rời)
- Tạo vector embedding và lưu vào vector DB (mất thông tin vị trí và ngữ cảnh)
- Ví dụ: ngay cả một bảng đơn giản cũng có thể bị đọc
1,000 thành l,0O0, hoặc bảng bị tách khỏi phần tiêu đề khiến việc tính tổng thất bại
- Các trường hợp mất thông tin thực tế cũng xảy ra thường xuyên, chẳng hạn nhầm chú giải biểu đồ thành nội dung chính, hoặc các giá trị phần trăm bị rải sai vị trí
Cách tiếp cận mới: chuyển sang hiểu tài liệu dựa trên thị giác
- Nhóm Morphik tìm thấy bước ngoặt từ câu hỏi: "Nếu hiểu tài liệu như một đối tượng trực quan giống con người thì sao?"
- Nhờ các nghiên cứu mới nhất (ColPali) và sự phát triển của Vision Language Model(VLM), có thể embedding trực tiếp hình ảnh để bảo toàn toàn bộ ngữ cảnh tài liệu và thông tin thị giác mà không cần parsing hay OCR
- Mỗi trang tài liệu được xử lý như hình ảnh độ phân giải cao, rồi chia theo từng patch để tạo embedding phản ánh cả thông tin trực quan lẫn văn bản
- SigLIP-So400m Vision Transformer tạo embedding cho các patch hình ảnh, còn mô hình ngôn ngữ PaliGemma-3B hiểu cấu trúc tài liệu
- Với truy vấn như "xu hướng doanh thu Q3", hệ thống truy xuất bằng cơ chế late interaction có thể tìm chính xác thông tin liên quan, bao gồm cả văn bản, biểu đồ, bảng và các tín hiệu thị giác như màu sắc
- Mọi thông tin thị giác như vị trí trong tài liệu, bố cục, màu sắc và biến đổi của đồ thị đều được giữ lại — gần giống với cách con người nhìn tài liệu trong một lần
So sánh parsing truyền thống và phương pháp ColPali
- Pipeline parsing truyền thống làm thất thoát thông tin ở từng bước, và vì embedding văn bản với hình ảnh bị tách rời nên không thể diễn giải quan hệ không gian trong tài liệu
- Ngược lại, phương pháp ColPali tích hợp mọi thông tin trong một không gian embedding thị giác duy nhất, từ đó bảo toàn ý nghĩa và ngữ cảnh của toàn bộ tài liệu
- Trong benchmark thực tế (tập trung vào tài liệu tài chính, dùng bộ dữ liệu công khai), Morphik (dựa trên ColPali) ghi nhận độ chính xác tối đa 95,56% (trong khi LangChain+OpenAI text-embedding chỉ đạt 72%, còn OpenAI file search chỉ đạt 13,33%)
- Trên benchmark ViDoRe, phương pháp dựa trên thị giác đạt hiệu năng cao hơn parsing truyền thống hơn 14 điểm phần trăm theo nDCG@5
Tối ưu hiệu năng và ứng dụng thực tế
- Nhược điểm ban đầu của cách làm này là tốc độ chậm do gánh nặng tính toán, vì cấu trúc yêu cầu truy xuất vector cho từng patch nên không phù hợp với hàng chục triệu truy vấn mỗi giây
- Tham khảo bài báo MUVERA, nhóm áp dụng cách thay thế truy xuất đa vector bằng truy xuất một vector duy nhất (mã hóa chiều cố định)
- Kết hợp với vector DB chuyên dụng Turbopuffer, tốc độ truy vấn được cải thiện từ 3-4 giây xuống còn khoảng 30ms
- Nhờ đó, hệ thống có thể truy xuất hàng triệu tài liệu với tốc độ vượt trội so với parsing văn bản truyền thống
Lĩnh vực ứng dụng và API đơn giản
- Hỗ trợ truy xuất độ chính xác cao trên nhiều loại tài liệu mà không làm mất cấu trúc trực quan và thông tin
- Tài liệu tài chính nơi bảng biểu và biểu đồ phức tạp là trọng yếu
- Sổ tay kỹ thuật thiên về bản vẽ
- Trích xuất thông tin theo bố cục từ hóa đơn, biên lai
- Hiểu tài liệu trực quan/dữ liệu số trong bài báo nghiên cứu
- Nhận diện quan hệ dựa trên bố cục trong hồ sơ y tế
- API có cấu trúc rất đơn giản: tải tài liệu lên rồi đặt câu hỏi bằng ngôn ngữ tự nhiên, hỗ trợ các yêu cầu như "hãy cho tôi xem tất cả hợp đồng có điều khoản phạt trên 10.000 USD"
Hướng đi tương lai: trí tuệ đa tài liệu và hiểu sâu hơn
- Trí tuệ đa tài liệu: đang phát triển khả năng tham chiếu chéo và theo dõi thông tin giữa nhiều tài liệu
- Vượt qua truy xuất trong một tài liệu đơn lẻ để hỗ trợ theo dõi quan hệ và suy luận giữa nhiều tài liệu (ví dụ: từ điều khoản hợp đồng → tài liệu quy định → sổ tay thực thi)
- Hệ thống hiểu dành cho agent: vượt qua hỏi đáp đơn giản trong tài liệu để tự động hóa suy luận logic giữa các chunk như trích xuất điều khoản → kiểm chứng bằng tài liệu khác → đối chiếu chi tiết
- Tích hợp workflow: nâng cấp trí tuệ tự động hóa tài liệu phù hợp với quy trình thực tế như so sánh điều kiện giữa nhiều hợp đồng hoặc truy vết lịch sử quyết định kỹ thuật
Giới hạn và mục tiêu sắp tới
- Cách tiếp cận hiện tại vẫn chưa đạt tới khả năng diễn giải ở cấp độ chuyên gia và năng lực phán đoán theo ngữ cảnh
- Những phần như diễn giải chuyên sâu của chuyên gia tài chính vẫn còn hạn chế về mặt kỹ thuật, và các yêu cầu doanh nghiệp như độ tin cậy, định lượng mức độ bất định vẫn cần phát triển thêm
- Kết hợp hiểu thị giác với đồ thị tri thức theo miền, suy luận quan hệ nhân quả và cung cấp chỉ số độ tin cậy là các bài toán lớn tiếp theo
Kết luận
- Tài liệu cần được xử lý như đối tượng tri thức trực quan, và vượt qua giới hạn của parsing, hiểu tài liệu dựa trên hình ảnh là lời giải tốt hơn cho môi trường RAG
- Morphik muốn đưa ra một tiêu chuẩn mới cho trích xuất thông tin tài liệu, hướng tới tự động hóa workflow tài liệu phức tạp và ứng dụng vào công việc thực tế
- Có thể trải nghiệm chi tiết các tính năng tại morphik.ai
1 bình luận
Ý kiến trên Hacker News
Có nhiều vấn đề nền tảng mà mọi người nhất định պետք է biết
LLM thường được tiền huấn luyện chủ yếu với khoảng 4k token văn bản, rồi sau đó mới được mở rộng sang cửa sổ ngữ cảnh dài hơn (đi từ 4000 lên 4001 là chuyện dễ, nhưng với hình ảnh thì không thể làm vậy vì cách token hóa khác hẳn)
Kết quả là mô hình bị lệch khỏi phân phối huấn luyện, nên khi xử lý hơn hai hoặc ba ảnh thì hiện tượng ảo giác trở nên rất nghiêm trọng
PDF độ phân giải 1536×2048 dùng nhiều token hơn văn bản từ 3 đến 5 lần, nên chi phí suy luận tăng và tốc độ trả lời chậm hơn
Nếu hạ độ phân giải thì ảnh sẽ bị mờ
Bản thân ảnh gốc cũng nặng, nên chỉ riêng việc tải các ảnh cần thiết đã làm tăng độ trễ cho từng yêu cầu
Trong các benchmark nhỏ, cách này đương nhiên hoạt động tốt hơn chunking văn bản cơ bản với các tài liệu tài chính có nhiều biểu đồ và bảng
Cá nhân tôi muốn thử kiểu như Gemini cho phép chú thích ảnh bằng OCR rồi so sánh kết quả
Cách tiếp cận end-to-end bằng hình ảnh có ý nghĩa trong các trường hợp đặc thù như bằng sáng chế, sơ đồ kiến trúc..., nhưng thực sự chỉ nên là phương án cuối cùng
Vấn đề là LLM có thể bịa ra văn bản nghe hợp lý ở những chỗ nó không đọc được, khiến kết quả còn tệ hơn
Ví dụ, GPT4.1 hoạt động hoàn hảo với ảnh chụp màn hình kích thước 1296×179, nhưng khi thu nhỏ còn 50% xuống 650×84 thì nó trả về "Pdf's at 1536 × 2048 use 3 to 5X more tokens" thành "A PNG at 512x 2048 is 3.5k more tokens"
Phần lớn thì nó làm đúng, nhưng cần cẩn thận vì những chi tiết tinh vi như thế có thể bị thay đổi
Một đặc tính thú vị của dòng gemma3 là tăng kích thước ảnh đầu vào không làm tăng nhu cầu bộ nhớ xử lý
Vì bộ mã hóa ở giai đoạn thứ hai nén về token kích thước cố định
Trên thực tế điều này khá hữu ích
Nhưng làm vậy đồng nghĩa toàn bộ tập tài liệu được xử lý đều buộc phải đi qua một VLM lớn
Có thể sẽ quá đắt và quá chậm
Rõ ràng ở đây có trade-off
Trong đa số trường hợp, cách hiện tại vẫn hiệu quả nhất
Có những trường hợp người ta cứ đưa mọi thứ vào LLM, nhưng tùy tình huống điều đó có thể không phù hợp
Không phải lúc nào cũng cần xử lý mọi thứ bằng LLM
Có vẻ nó có thể mở rộng thành một ý tưởng để thay đổi cả pipeline RAG
Với mỗi kết quả RAG, ở bước model xử lý có thể trích xuất trực tiếp từ ảnh những thông tin liên quan đến truy vấn của người dùng, rồi gom các kết quả đó dưới dạng văn bản để làm đầu vào cho bước sinh cuối cùng
Như vậy có thể lách giới hạn token của nhiều ảnh và song song hóa quá trình hiểu ảnh
Tôi và đồng nghiệp đã thử triển khai kiểu này cho một cơ quan chính phủ Pháp cách đây 6 tháng
Chúng tôi cung cấp mã nguồn mở tại đây: https://github.com/jolibrain/colette
Đây không phải mảng kinh doanh chính của chúng tôi nên hiện chỉ để đó, nhưng với một chút tinh chỉnh thì nó hoạt động khá hiệu quả
Điểm thú vị thực sự là có thể làm cho toàn bộ pipeline trở nên khả vi hoàn toàn để finetune viz rag chuyên biệt cho một bộ dữ liệu cụ thể
Có thể tùy biến cả layout model để hiểu tài liệu chính xác hơn
Trong trường hợp thông thường, rào cản lớn nhất là cần một bộ đánh giá chất lượng cao (và chuyện này lúc nào cũng là rào cản)
Tôi đã thực hiện nhiều nghiên cứu benchmark giữa OCR và ảnh + LLM đa dụng: https://getomni.ai/blog/ocr-benchmark
Vấn đề lớn nhất của cách trích xuất trực tiếp từ ảnh là tài liệu nhiều trang
Với một trang đơn, trong so sánh (OCR=>LLM vs Image=LLM) thì ảnh trực tiếp nhỉnh hơn đôi chút, nhưng khi vượt quá 5 ảnh thì độ chính xác giảm mạnh so với cách OCR trước
Thực ra ngay cả long-context recall với văn bản cũng đã là bài toán khó, nhưng LLM ít nhất còn được tối ưu cho việc đó; còn long-context recall với ảnh thì hiện vẫn còn yếu khá nhiều
Thêm một lớp chuyển đổi nhỏ từ ảnh sang LLM cũng khá hiệu quả (tức là thay vì OCR trực tiếp, gửi 5 ảnh cùng lúc vào một model vision nhỏ để chỉ trích xuất những điểm quan trọng nhất của tài liệu)
Hiện chúng tôi đang nghiên cứu cách sửa cache hoặc attention map của LLM để các batch ảnh lớn hơn hoạt động tốt hơn
Những cách tiếp cận như sliding window hay infinite retrieval có vẻ đầy hứa hẹn
Đây chỉ là dự đoán cá nhân, nhưng nhìn vào tốc độ tiến bộ của các model đa phương thức, tôi nghĩ chẳng bao lâu nữa long-context cho ảnh sẽ không còn là vấn đề lớn
Bài blog này nêu ra vài điểm hay về việc dùng model vision cho retrieval, nhưng tôi muốn chỉ ra một số vấn đề
Document parsing là công việc chuyển tài liệu thành văn bản có cấu trúc như Markdown/JSON (hoặc đầu ra theo schema nếu là trích xuất)
RAG chỉ là một trong các ứng dụng của nó, ngoài ra còn nhiều mục đích khác
ColPali rất tốt cho retrieval, nhưng ít nhất ở dạng native thì không dùng được cho document parsing thuần túy
Tác giả chủ yếu chỉ nhắc đến benchmark retrieval trực quan
Nó thường hoạt động tốt hơn OCR tiêu chuẩn, nhưng
a. vẫn còn vấn đề độ chính xác ở phần long tail
b. thiếu metadata như confidence score, bounding box, v.v.
c. bản thân pipeline ảnh chụp màn hình cũng cần nhiều công sức nếu muốn nâng cấp bài bản
Token ảnh mạnh hơn nhiều, nhưng token văn bản rẻ hơn rất nhiều về chi phí lưu trữ nên có thể truy vấn trên toàn bộ tài liệu khi retrieval, thay vì chỉ theo chunk
(Lưu ý: tôi là CEO của llamaindex và đã làm cả parsing lẫn retrieval với LlamaCloud, đây chỉ là góc nhìn chung)
Năm ngoái tôi đã dành khá nhiều thời gian để xây dựng một hệ thống phân tích tài liệu bằng sáng chế
Bằng sáng chế chứa nhiều loại nội dung như sơ đồ trừu tượng, công thức hóa học, công thức toán..., nên việc chuẩn bị dữ liệu cho LLM thực sự rất khó
Cách đơn giản nhất mà tôi tìm ra là chuyển từng trang theo kiểu “chụp ảnh”, rồi yêu cầu LLM tạo JSON mô tả nội dung cùng metadata như số trang, số lượng thành phần trực quan, v.v.
Với ảnh phức tạp thì chỉ cần yêu cầu model mô tả lại
Làm vậy sẽ dễ dàng nhúng JSON vào vector store mong muốn
Khó đánh giá hiệu quả chi phí, nhưng cách này đơn giản và hiệu quả hơn đề xuất của tác giả
Ví dụ, dù model có thể trích xuất khá tốt các cặp x, y từ biểu đồ, nhưng nếu người dùng hỏi chính xác một giá trị x/y cụ thể thì nó có thể bỏ sót
Nếu hiển thị trực tiếp ảnh ở bước suy luận cho model, nó có thể trả lời đúng chính xác điều người dùng hỏi, nên cách tiếp cận đó hiệu quả hơn
Trở ngại thực sự duy nhất ở đây là chất lượng retrieval, và đây là vấn đề tương đối nhỏ
Nói cách khác, nếu chỉ cần truyền đúng ngữ cảnh thì phần còn lại LLM sẽ tự lo được
Nếu không thì số lượng bài toán như OCR, parsing, mô tả ảnh... sẽ tăng vọt
Nhưng nó cũng cho thấy cơ hội của LLM tập trung vào việc phân loại lại/xử lý lại các giá trị sẵn có như tài liệu bằng sáng chế
Thập niên 90–00 là thời các công ty phần mềm thành công bằng cách chuyển hồ sơ giấy cũ vào cơ sở dữ liệu
Còn việc tạo ra bộ dữ liệu mới thật sự có giá trị ngay từ đầu vẫn đòi hỏi rất nhiều đầu tư và công sức
Theo kinh nghiệm của tôi thì cách này không hay lắm
Tùy font mà rất khó phân biệt giữa o và 0
Khi chuyển tài liệu (doc/xls/pdf/html) thành ảnh, bạn sẽ mất những thông tin phân biệt như vậy
Với số sê-ri chẳng hạn, đôi khi con người nhìn còn không phân biệt nổi
Vì vậy với PDF, render ra ảnh rồi trích xuất lại là một cách khá hợp lý
Còn các định dạng khác thì parse trực tiếp tài liệu sẽ tốt hơn
Tuy nhiên trong thực tế công việc, khi làm thiết kế trang thì việc cho model xem ảnh thực tế hiệu quả hơn nhiều cho debug so với chỉ đưa mã
Vấn đề 1 với I, 0 với O là có thật, nhưng với những tài liệu vốn đã có nhiều sơ đồ/biểu đồ thì tôi thường thấy xử lý chỉ bằng ảnh dễ hơn hẳn
(Có thể đây là selection bias)
Tôi đã mất vài phút thử copy lịch trình sang Gemini để truy vấn, nhưng dù ở dạng HTML thì nó vẫn không làm tốt
Cuối cùng tôi chụp màn hình, che đen những phần không cần thiết rồi đưa ảnh vào, và nó hoạt động rất tốt
Tôi hơi thắc mắc vì có vẻ bài toán này đã được giải bằng multimodal RAG rồi
Tôi có kết quả phân tích ảnh khá hài lòng với Flash 2.5, Sonnet 3.7, v.v.
Thậm chí tôi có cảm giác khi đưa ảnh vào thì phản hồi còn tốt hơn so với đưa văn bản
https://www.youtube.com/watch?v=p7yRLIj9IyQ
Chỉ là multi-vector ở trạng thái ban đầu (nền tảng của multimodal RAG) rất khó xử lý, và phép tính độ tương đồng cũng cực kỳ đắt đỏ nên khó scale up
Cần có lượng tử hóa, chuyển đổi về vector đơn (mã hóa chiều cố định), tối ưu indexing, v.v.
Đó chính là điều chúng tôi đang làm ở Morphik
Tôi cũng từng thử quét tất cả hóa đơn một lượt bằng cách chỉ trích xuất file đính kèm từ hộp thư, rồi chạy script tải lên từng cái để yêu cầu xác định “hóa đơn: có/không” và trích xuất từng hạng mục/tên nhà cung cấp/ngày/số hóa đơn, v.v.
Kết quả là tỷ lệ đọc hiểu khá cao, dù các lệnh gọi LLM chạy hơn 3 tiếng nhưng vì tự động hóa nên tôi không bận tâm
Sau đó tôi còn để LLM đối chiếu với sao kê ngân hàng, và chỉ thiếu một số hóa đơn không được gửi kèm file đính kèm
Tuy nhiên việc khớp hóa đơn với sao kê thì LLM làm khá tệ (chỉ lệch vài đô là nó vẫn trả lời là cùng một sao kê)
Nên có lẽ trước mắt vẫn cần kế toán
Tôi cũng không ước tính kỹ chi phí, và dùng model rẻ như Claude 3.7
Tôi hiểu vì sao ColPali trông trực quan và mạnh mẽ, nhưng xử lý tài liệu theo cách truyền thống vẫn có những ưu điểm riêng