- Bắt đầu từ nhận định rằng "nếu biểu diễn văn bản dưới dạng hình ảnh, có thể chứa cùng một lượng thông tin với số token ít hơn rất nhiều"
- Đây là mô hình đề xuất một cách tiếp cận mới nhằm nén thông tin văn bản thành biểu diễn thị giác 2D, đồng thời kiểm chứng thực nghiệm khái niệm nén dựa trên thị giác (Optical Compression) để xử lý ngữ cảnh dài một cách hiệu quả
- Mô hình gồm DeepEncoder (encoder) và DeepSeek3B-MoE-A570M (decoder), đạt mức sử dụng bộ nhớ kích hoạt thấp ngay cả với đầu vào độ phân giải cao và tỷ lệ nén token khoảng 10~20 lần
- Vẫn duy trì độ chính xác OCR 97% ở mức nén 10 lần và trên 60% ngay cả ở mức nén 20 lần, qua đó cho thấy tiềm năng thực tế cho nghiên cứu nén ngữ cảnh dài và cơ chế quên của bộ nhớ
- Trên OmniDocBench, mô hình vượt GOT-OCR2.0 chỉ với 100 vision token so với 256 token/trang, và cho kết quả tốt hơn MinerU2.0 với dưới 800 token so với trung bình hơn 6000 token/trang
- Chỉ với một GPU A100-40G có thể tạo hơn 200.000 trang dữ liệu mỗi ngày, mang lại giá trị thực tiễn cao như một data engine phục vụ huấn luyện quy mô lớn cho LLM/VLM
1. Bối cảnh nghiên cứu
- Các LLM hiện nay có giới hạn cấu trúc khi chi phí tính toán tăng theo bậc hai theo độ dài chuỗi
- Bài báo khởi nguồn từ nhận định "nếu biểu diễn văn bản dưới dạng hình ảnh, có thể chứa cùng một lượng thông tin với số token ít hơn rất nhiều"
- Nhóm tác giả định nghĩa điều này là nén ngữ cảnh dài dựa trên vision token (Context Optical Compression) và chọn OCR làm môi trường thử nghiệm
- Kết quả cho thấy biểu diễn thị giác có thể mở ra một hướng mới để cải thiện hiệu quả xử lý ngữ cảnh của LLM
2. Kiến trúc mô hình
- DeepSeek-OCR = DeepEncoder + decoder DeepSeek3B-MoE
- DeepEncoder: SAM (Window Attention) + CLIP (Global Attention) + bộ nén token 16 lần
- DeepSeek3B-MoE: kích hoạt 6 trong số 64 expert, tổng cộng 570M tham số hoạt động
- Hỗ trợ chế độ đa độ phân giải (Tiny~Gundam)
- Hỗ trợ đầu vào độ phân giải 512~1280 và có thể xử lý tổng hợp tối đa 9 tile
- Chế độ Gundam dành cho tài liệu siêu độ phân giải cao (như báo in), dùng tối đa 800 vision token
3. Data engine
- Tổng cộng kết hợp 3 loại dữ liệu:
- Dữ liệu OCR 1.0: 30M trang tài liệu (100 ngôn ngữ), có chú thích chi tiết về bố cục và văn bản
- Dữ liệu OCR 2.0: 16M mẫu cho nhận diện phức hợp như biểu đồ, công thức hóa học (SMILES), hình học
- Dữ liệu vision tổng quát: dùng để duy trì năng lực hiểu thị giác dựa trên CLIP, chiếm 20% tổng dữ liệu
- Dữ liệu chỉ văn bản: chiếm 10% để bổ sung năng lực ngôn ngữ
- Tỷ lệ cấu thành toàn bộ dữ liệu huấn luyện
- OCR 70% / vision 20% / văn bản 10%
4. Pipeline huấn luyện
- Huấn luyện theo hai giai đoạn: DeepEncoder → DeepSeek-OCR
- Trên tổng cộng 20 node (8×A100 GPU), data parallelism DP=40, batch toàn cục 640
- Tốc độ huấn luyện: 90B token/ngày với dữ liệu văn bản, 70B token/ngày với dữ liệu đa phương thức
5. Kết quả đánh giá
(1) Thí nghiệm nén (benchmark Fox)
- Đạt 97% độ chính xác ở mức nén 10 lần, và vẫn giữ trên 60% ở mức nén 20 lần
- Hiệu năng giảm khi tài liệu dài hoặc phức tạp hơn, nhưng điều này được diễn giải là có thể mô phỏng “cơ chế quên”
- Ở mức nén 10× trở xuống, có thể khôi phục ngữ cảnh gần như không mất mát
(2) Nhận diện tài liệu thực tế (OmniDocBench)
- So sánh các chế độ Tiny (64 token) ~ Gundam (800 token)
- So với GOT-OCR2.0 (256 token), chế độ Small (100 token) cho kết quả tốt hơn
- So với MinerU2.0 (7.000 token), Gundam (800 token) cho hiệu năng vượt trội hơn
- Số lượng token cần thiết khác nhau tùy loại tài liệu
- Slide, báo cáo: chỉ cần 64~100 token
- Báo, bài báo học thuật: cần 400~800 token
6. Phân tích định tính (Qualitative Study)
- Chế độ Deep Parsing
- Có thể trích xuất có cấu trúc bằng một prompt duy nhất cho biểu đồ, hình học, công thức hóa học và cả ảnh tự nhiên
- Nhận diện đa ngôn ngữ
- Hỗ trợ PDF của khoảng 100 ngôn ngữ, bao gồm cả các ngôn ngữ ít phổ biến như Ả Rập và Sinhala
- Hiểu thị giác tổng quát
- Có thể thực hiện mô tả ảnh, phát hiện đối tượng và grounding
- Khi kết hợp với LLM, có thể dùng như mô hình nền tảng cho suy luận kết hợp vision-ngôn ngữ
7. Thảo luận và hàm ý
- DeepSeek-OCR là thử nghiệm đầu tiên khám phá ranh giới của nén văn bản dài bằng vision token,
lượng hóa khái niệm “một bức ảnh chứa cả nghìn từ”
- Ngay cả ở mức nén 10× vẫn có thể khôi phục gần như không mất mát → có thể mở rộng sang nén lịch sử hội thoại, tối ưu hóa bộ nhớ dài hạn
- Đề xuất mô phỏng sự suy giảm token tương tự đường cong quên trong sinh học bằng cách giảm dần độ phân giải hình ảnh theo thời gian
8. Kết luận
- DeepSeek-OCR là mô hình thực chứng cho ánh xạ nén 10~20 lần giữa văn bản và thị giác,
mở ra một mô hình mới để vượt qua giới hạn xử lý ngữ cảnh dài của LLM
- Vượt ra ngoài OCR, trong tương lai mô hình được kỳ vọng mở rộng sang pretraining lai số-quang học và
mô hình ngữ cảnh siêu dài dựa trên ‘Optical Context Memory’
- Mã nguồn đã được công bố và có thể được sử dụng cho nghiên cứu cũng như data engine thương mại
- So với các dự án OCR mã nguồn mở hiện có, DeepSeek-OCR nổi bật nhờ kiến trúc dựa trên mô hình ngôn ngữ lớn (LLM) có khả năng mã hóa thông tin thị giác hiệu quả
- Hỗ trợ nhiều mức độ phân giải (512×512~1280×1280), cùng chế độ Gundam cho độ phân giải động, giúp thích ứng tốt với nhiều môi trường khác nhau
- Nhờ thiết kế prompt rõ ràng, mô hình hỗ trợ nhiều chế độ tác vụ như mô tả ảnh tổng quát, chuyển đổi sang Markdown, OCR bỏ qua layout, parsing biểu đồ
- Hiệu năng tích hợp với các benchmark ngành như Fox, OmniDocBench đã được xác nhận và kiểm chứng qua các thử nghiệm xử lý tài liệu thực tế
- Mô hình tiếp thu và triển khai ưu điểm cùng ý tưởng từ các dự án phổ biến khác như GOT-OCR2.0, PaddleOCR
- Độ phân giải hỗ trợ
- Tiny: 512×512 (64 vision tokens)
- Small: 640×640 (100 vision tokens)
- Base: 1024×1024 (256 vision tokens)
- Large: 1280×1280 (400 vision tokens)
- Dynamic mode(=Gundam): độ phân giải tự do (n×640×640 + 1×1024×1024)
- Suy luận song song cho PDF và ảnh, cùng tốc độ xử lý nhanh
- Trên GPU A100, xử lý PDF đạt khoảng ~2.500 token/giây
- Bối cảnh kỹ thuật và liên kết hệ sinh thái
- Được triển khai 100% bằng Python
- Hỗ trợ cả hai môi trường suy luận chính là vLLM và Transformers
- Sử dụng các benchmark và framework đánh giá quan trọng như OpenChart, Fox, OmniDocBench
- Tương thích với các mô hình tiền nhiệm như GOT-OCR2.0, PaddleOCR, Vary; đồng thời kế thừa ý tưởng và tăng cường hiệu năng
1 bình luận
Ý kiến trên Hacker News
Bài báo này không chỉ dừng lại ở việc là thêm một VLM khác cho OCR, mà còn chuyển sang các chủ đề thú vị hơn như nén
Ví dụ, có đoạn trích: "Chúng tôi tiến hành nghiên cứu ban đầu để khám phá ranh giới của nén thị giác-văn bản, xem cần bao nhiêu token thị giác để giải mã token văn bản. Kết quả sơ bộ cho thấy DeepSeek-OCR đạt được mức nén OCR gần như không mất mát ở tỷ lệ khoảng 10 lần, và ngay cả khi nén 20 lần vẫn giữ được độ chính xác 60%"
Theo trực giác thì điều đó có nghĩa là một token thị giác chứa lượng thông tin tương đương 10 token văn bản
Mong ai đó có thể giải thích vì sao lại ra kết quả như vậy dưới góc nhìn lý thuyết thông tin theo cách người mới cũng hiểu được
Có phải là vì token văn bản vẫn bị chia quá nhỏ (hoặc dư thừa), chưa đạt tới mức mã hóa entropy, hay là khi chuyển sang cách biểu diễn bằng token thị giác thì thoát khỏi giới hạn kiểu 'đơn vị từ' nên có thể tiến gần entropy hơn không (giống khác biệt giữa arithmetic encoding và mã Huffman)
Và bài báo cũng bàn về việc khi xử lý ngữ cảnh rất lớn thì họ thực sự downscale hình ảnh, từ đó thảo luận mối tương ứng giữa mất mát thông tin trong miền văn bản và miền hình ảnh
Token văn bản là các đơn vị con đã được lượng tử hóa (subword), còn token thị giác chỉ tồn tại trong không gian embedding
Trong LLM, cách tokenize văn bản có cấu trúc là bảng tra từ (nhỏ) token ID sang (lớn) vector embedding
Khi đưa văn bản vào LLM, ta cắt chuỗi theo ranh giới token, chuyển sang token ID, rồi lấy các vector từ bảng tra để tạo thành ma trận hàng ngữ cảnh (context matrix)
Việc truyền chuỗi token văn bản thực tế rất hiệu quả, vì chỉ cần truyền một mảng số (ID) là đủ (thường khoảng ~100 nghìn token ID duy nhất)
Ngược lại, truyền chính ma trận embedding thì không hiệu quả, vì embedding gồm hàng nghìn số thực dấu phẩy động
Ảnh được mã hóa theo cách khác. Dữ liệu ảnh được tiền xử lý rồi đưa thẳng vào bộ mã hóa ảnh dựa trên mạng nơ-ron để biến thành vector và ghép các vector này vào ngữ cảnh
Nghĩa là token ảnh không có token ID, không có bảng tra, mà đi thẳng từ dữ liệu sang embedding
Kết quả là để truyền token ảnh thì phải gửi chính embedding, nên kém hiệu quả
Dù ảnh được mã hóa bằng ít token hơn, mỗi token lại nặng hơn rất nhiều
Tóm lại, token văn bản là số nguyên (0~n) có ánh xạ rõ ràng sang vector, nên có 'n' lựa chọn
Trong khi đó, token ảnh là mảng số thực m chiều (vector), nên có không gian token lớn hơn rất nhiều
Xét về mẫu hình, token văn bản bám trực tiếp vào chuỗi byte UTF-8 liên tiếp và phần lớn không vượt ra ngoài ranh giới từ, nên các mẫu toàn cục (ví dụ: “câu này là của Hamlet”, “đoạn này là tiếng Tây Ban Nha”) không thể được biểu diễn bằng một token duy nhất
Tôi không chắc chính xác cách các LLM đa phương thức embedding đầu vào ảnh, nhưng hiểu cơ bản là họ cắt ảnh thành lưới và mã hóa từng vùng
Trong thí nghiệm của DeepSeek, có lẽ trọng tâm không hẳn là tính chất lý thuyết thông tin, mà là có thể giảm độ phân giải hoặc tăng kích thước lưới (patch) đến mức nào mà vẫn giữ đủ chi tiết để OCR chính xác
Mong Karpathy mở rộng NanoChat sang đa phương thức rồi chia sẻ kinh nghiệm về quy trình mã hóa kiểu này
Tỷ lệ nén phù hợp rốt cuộc chắc chắn phụ thuộc vào độ phân giải của từng ký tự và kích thước tương đối của mỗi patch token thị giác
Chỉ như vậy thì số token văn bản trích xuất bằng OCR cuối cùng mới có thể giữ ổn định, độc lập với độ phân giải ảnh
Mỗi token văn bản chủ yếu ở mức subword, còn token thị giác của VLM nằm trong không gian ngữ nghĩa (semantic space)
Không gian ngữ nghĩa có thể nén thông tin mạnh hơn nhiều so với việc tách nhỏ theo subword
Lưu ý: tôi không phải chuyên gia, chỉ là suy nghĩ nhanh tại chỗ
LLM có lượng tính toán tăng theo bình phương số token
Vì vậy trong VLM người ta muốn nén token văn bản thành token thị giác
Có vẻ họ đang thử render văn bản thành ảnh trước rồi tokenize để giảm chi phí tính toán
PyTorch trên NVIDIA Spark (ARM64) hơi khó nhằn, nhưng tôi đã làm nó chạy được bằng cách chạy Claude Code với quyền root trong một container Docker mới
Ghi chú chi tiết xem tại đây
Kết quả thực tế có thể xem ở liên kết này, thử trên ảnh OCR gốc (tại đây)
Kết quả OCR nhìn chung rất chắc
Tuy vậy, ở đoạn ngay dưới phần trích dẫn nó đã thêm nội dung không cần thiết và bị hallucination, rồi nối luôn sang cột tiếp theo
Cảm ơn vì đã đẩy nhanh bài test
Việc nó bỏ sót chữ "A" ở đầu văn bản thì cũng hiểu được (có lẽ tập dữ liệu không có nhiều bài báo tin tức)
Nhưng điều thú vị hơn là nó bỏ hẳn toàn bộ câu "Hallucination is a risk and...", cả chủ đề bên cạnh tác giả ("theme") lẫn phần email cuối cùng
Chỉ riêng thí nghiệm này thôi cũng xứng đáng có một bài đăng riêng
"chạy Claude Code với quyền root trong một container Docker mới"
Tôi muốn biết cụ thể cách cấu hình để nó chạy với quyền root
(nếu đã có giải thích thì tôi sẽ xem trong bài)
Bài báo không nhắc tới Anna’s Archive
Tôi nghĩ DeepSeek có thể đã thực sự tận dụng đề nghị từ phía Anna cho phép các nhà nghiên cứu OCR truy cập bộ sưu tập 7,5 triệu cuốn sách phi hư cấu tiếng Trung (350TB)
Quy mô này còn lớn hơn cả Library Genesis
Bài blog tham khảo
Trong bài báo trước của DeepSeek, họ có nhắc trực tiếp tới Anna’s Archive
"Đã làm sạch 860K ebook tiếng Anh, 180K ebook tiếng Trung từ Anna’s Archive cùng hàng triệu đề thi giáo dục K-12"
Xem bài báo DeepSeek-VL
Tôi thắc mắc vì sao lại phải xin quyền truy cập chỉ vì họ đang lưu trữ sách của người khác
Tôi cũng nghĩ ngay tới Anna’s Archive, và tò mò không biết khi nào bộ dữ liệu đã OCR sẽ được công bố
Điều đó cũng có nghĩa là bộ dữ liệu có thể sẽ không bao giờ được công khai
Trong tình huống như vậy, tôi lo Anna’s Archive cuối cùng cũng sẽ bị các công ty LLM lạm dụng đến mức biến mất
Trong khi META đã kéo tới 70TB từ Library Genesis qua torrent rồi mà vẫn chưa đủ
Chia sẻ kinh nghiệm về chất lượng thực tế của các benchmark hiện nay
Benchmark OmniAI không tốt lắm
Thay vào đó, tôi khuyên dùng OmniDocBench
Mistral OCR kém rõ rệt so với các mô hình OCR mã nguồn mở khác và cả Gemini
OCR đầu-cuối (E2E OCR) vẫn rất khó
Cách pipeline (phát hiện bố cục → xác định thứ tự đọc → OCR từng thành phần) hoạt động tốt hơn
Phân tích bảng phức tạp vẫn là bài toán rất lớn
Tôi cũng muốn thấy các benchmark so sánh với Apple Vision Framework
Nó được tích hợp sẵn trên gần như mọi thiết bị Apple và thực tế cho OCR chất lượng cao, nhanh (đặc biệt để chuyển PDF), nhưng có vẻ ít người biết
Tôi rất tò mò nó đang đứng ở đâu trong benchmark
Theo benchmark OmniAI thì Omni OCR cho hiệu năng cao nhất
Chắc ai cũng sẽ tiếp nhận kết quả kiểu này mà không hề đặt câu hỏi
Tôi muốn biết OCR dựa trên LLM có ưu điểm và khác biệt gì so với các dịch vụ như Azure AI Document Intelligence(liên kết), Google Vision API(liên kết)
OmniAI có benchmark LLM nội bộ của họ với OCR đám mây
Benchmark blog OmniAI (tính đến tháng 2/2025)
Sau đó LLM đã tiến bộ rất nhanh
Dòng Qwen3-VL, đặc biệt là Qwen3-VL-235B-A22B-Instruct, gần đây cho kết quả tốt nhất
Tôi đoán các mô hình OCR thương mại/độc quyền vẫn sẽ tiếp tục tốt hơn trên tài liệu thực tế
Nhờ có rất nhiều bộ dữ liệu huấn luyện riêng chất lượng cao
LLM công khai được huấn luyện chủ yếu trên arXiv, ebook và dữ liệu thiên về bài báo, nên khi gặp tài liệu công việc thực tế thì kém hơn là điều khó tránh
Cách làm dựa trên LLM giảm lỗi thay ký tự (lỗi chính tả, biến thể), nhưng độ nhất quán ở cấp độ cả trang lại thấp hơn
Nó cũng có thể tạo ra kết quả hoàn toàn sai như các LLM không phải OCR
Với ký tự CJK, OCR kiểu cũ vẫn thường tạo ra rất nhiều thay thế không phù hợp
Có quá nhiều ký tự quá giống nhau, đôi khi chỉ phân biệt được ở mức kính hiển vi hoặc nhị phân
LLM áp ràng buộc mạnh hơn lên các chuỗi ký tự có khả năng xuất hiện, nên có thể kỳ vọng kết quả chính xác hơn
Ít nhất chính mối băn khoăn này là động lực để áp dụng OCR dựa trên LLM
Tôi không rõ mô hình khác ra sao, nhưng công ty tôi đang chạy hệ thống phân tích CV bằng Azure AI Document Intelligence và khá hài lòng
Ban đầu chỉ cần chú ý tinh chỉnh một chút, còn suốt năm vừa qua gần như không phải đụng đến
Tôi đã thử nhiều VLM khác nhau, từ mô hình nhỏ tới lớn (Granite, Qwen, v.v.), và đi đến kết luận khá thất vọng nếu muốn thay thế hoàn toàn OCR truyền thống
Hệ thống của chúng tôi nhận tài liệu khách hàng và trả lại tài liệu chuẩn đã được đánh dấu theo yêu cầu, dưới dạng bitmap nhiều trang kiểu raster
Với chúng tôi, độ chính xác trích xuất tọa độ đến cấp ký tự hoặc từ riêng lẻ trong dữ liệu là rất quan trọng, nhưng thực tế thông tin vị trí từ VLM quá thất thường, hoặc hoàn toàn bịa đặt (hallucinated), hoặc quá mơ hồ để đảm bảo độ chính xác/độ chi tiết cần thiết
Cho đến nay chúng tôi vẫn dùng nền tảng Tesseract cùng các quy trình làm sạch kết quả, và chỉ thỉnh thoảng dùng đầu ra văn bản từ VLM như công cụ hỗ trợ khi không có bộ dữ liệu có cấu trúc
Có thể trường hợp của chúng tôi là nhu cầu rất hẹp, và với đa số mọi người thì chỉ cần dump văn bản hoặc chuyển sang Markdown/HTML là đủ
Nhưng tôi cảm thấy có khoảng cách khá lớn giữa tuyên bố rằng các mô hình này đã 'giải quyết hoàn toàn OCR' và trải nghiệm thực tế
Gợi ý thử mô hình moondream 3 preview
Trong bài blog họ nói nó vượt hiệu năng của nhiều VLM khác và là mô hình nhẹ
Xem trang chính, mô hình, blog
Tôi tò mò không biết tài liệu khách hàng có chứa chữ viết tay hay không
Cũng có thể dùng CNN để tìm bounding box của văn bản trước, rồi chạy VLM trên từng box
Ấn tượng cá nhân của tôi là OCR đã phần nào là một bài toán được giải quyết
Benchmark OmniAI cũng chưa được cập nhật với các mô hình gần đây, và tôi nghĩ lý do là vì LLM đa dụng đã vượt OCR gốc của benchmark đó
Thực tế, nếu đưa từng ảnh trang vào Gemini 2.5 Flash Lite và yêu cầu trích xuất ở dạng Markdown thì chi phí chỉ khoảng 20 cent cho mỗi 1000 trang, mà kết quả rất tốt
Tôi thắc mắc hiện nay điểm khó của OCR là gì
Hầu hết OCR/LLM, kể cả Gemini Pro 2.5, vẫn rất chật vật khi chuyển bảng phức tạp sang Markdown/HTML
Nhiều tiêu đề, ô gộp, cột có checkbox đều là vấn đề thường gặp, và bảng kéo dài qua nhiều trang thì chúng cũng không hiểu đúng
Llamaindex cũng thất bại nặng tương tự
Tôi muốn biết OCR/LLM nào làm tốt hơn ở các bài toán này
Ví dụ bảng phức tạp, Ví dụ toàn bộ checklist ICAO
Thực ra không phải OCR mà HTR (nhận dạng/chép lại chữ viết tay) vẫn còn rất khó
Nhờ LLM mà độ chính xác đã tốt hơn nhiều, nhưng lỗi sai lại cực khó để con người phát hiện (nó không đọc được thì tự bịa luôn)
Nếu bạn chấp nhận việc nó không nói "tôi không biết" ở chỗ không nhận ra được mà tự tưởng tượng ra để lấp vào, thì có thể xem là bài toán đã được giải quyết
(không phải mỉa mai, trong vài tình huống điều đó thực sự chấp nhận được)
Tôi là tác giả của benchmark OmniAI
Lý do chưa cập nhật mô hình mới là vì bản thân API OCR đang bị thu hẹp trong sản phẩm
Nội bộ chúng tôi vẫn dùng, còn benchmark thì lười nên chưa cập nhật
Gemini là tốt nhất cho OCR
Tuy nhiên, khi kết quả quá gần dữ liệu huấn luyện thì thường hay gặp lỗi 'recitation' khiến khoảng 10% đầu ra bị cắt ngang đột ngột
Với tập PDF trộn, nếu có trang trắng chen vào thì còn có những hallucination buồn cười là tự tạo ra nội dung linh tinh
OpenAI cũng không tệ, nhưng GPT5 không khác GPT-4o hay 4.1 về hiệu năng
Một số nội dung như header/footer hay biến mất, và nếu trang bị xoay ngang thì nó xử lý rất tệ
Nó cũng hay tự từ chối với giấy tờ tùy thân, hồ sơ y tế, nội dung có nguy cơ PII cao
Tôi thấy hoàn toàn chưa phải bài toán đã được giải quyết
Hãy thử OCR một tạp chí có bố cục lạ là biết gần như bất khả thi
Tôi sưu tầm tạp chí cổ và luôn thử OCR bằng công nghệ mới nhất, nhưng lúc nào cũng cần rất nhiều công sức chỉnh tay
Tôi đang thắc mắc có mô hình 'OCR' nhỏ nào không
Tôi chỉ cần lấy số serial từ ảnh chụp tại hiện trường nhà máy, không cần phân tích cả tài liệu
Dùng mô hình 3 tỷ tham số cho việc này thì quá nặng
Tôi tò mò DeepSeek-OCR so với Tesseract(liên kết) thế nào
Tôi rất thích ocrmypdf(liên kết) và đang dùng cực ổn trên máy cục bộ
Nhưng nếu thực tế Tesseract đạt 80% còn mô hình mới đạt 95%
mà đổi lại phải gánh nhu cầu hạ tầng như ổ cứng gấp 100 lần, Kubernetes/Docker, GPU 16GB VRAM, thì đó rõ ràng là yếu tố đáng cân nhắc
Vì tôi không theo kịp nghiên cứu mới, có ai giải thích kiểu ELI5 cho tôi đây là gì và vì sao nó quan trọng không
Tiêu đề trên GitHub hay bài báo là OCR, nhưng phần tóm tắt và readme.md lại nói về nén ngữ cảnh LLM nên khá rối
Tôi đang tìm ai đó giải thích cách hai thứ này kết nối với nhau ở bức tranh lớn hơn
Hình ảnh đó chứa lượng thông tin tương đương ‘1000 token’
Trên thực tế, phải biến ảnh thành feature/embedding rồi giải mã
Nếu ảnh được xử lý thành 100 ‘token ảnh’, rồi 100 token ảnh đó được chuyển thành 1000 ‘token văn bản’
Thì xét thuần túy từ góc độ giải mã, bạn đã truyền cùng đầu ra thông tin đó với mức nén 10 lần
Với LLM, điều đó nghĩa là nếu có thể nén trước thành một biểu diễn tiềm ẩn (latent) nhỏ hơn 10 lần, thì không cần 1000 token/embedding mà vẫn có thể tạo ra kết quả tương đương hoặc tốt hơn