OCR thông minh, sập cũng thông minh

Khi Vision Language Model xử lý tài liệu production, nó không sập như phần mềm thường — nó sập theo cách chỉ AI mới nghĩ ra được.

"Model ngon lắm, demo mượt lắm" — rồi production tắt đèn

"Vision Language Model đọc tài liệu chuẩn hơn OCR truyền thống" — câu này đúng. Nhưng nó đúng giống kiểu nói "đầu bếp 5 sao nấu ngon hơn nồi cơm điện" — đúng, cho đến khi đầu bếp đó quyết định nấu một nồi phở rồi khuấy mãi không chịu dừng.

Đội ngũ LlamaIndex vừa public một bài post-mortem thẳng thắn về chính service LlamaParse của họ. Nếu bạn từng đọc bài mình chia sẻ về tài liệu "bất trị" và cách AI xử lý document, thì đây là chương tiếp theo không ai muốn viết: khi hệ thống document processing lên production — và sập.

Không phải sập kiểu server hết RAM hay database lock. Mà sập theo kiểu chỉ AI mới nghĩ ra được.

Cú sập thứ nhất: AI "kẹt đĩa" — lặp mãi không dừng

Hình dung thế này: bạn giao cho nhân viên mới một xấp hợp đồng scan để nhập liệu. Nhân viên đó bắt đầu gõ... rồi gõ cùng một dòng, lặp đi lặp lại, suốt 3 tiếng, cho đến khi hết giấy in.

Đó chính xác là chuyện xảy ra khi VLM gặp một số loại tài liệu nhất định. Model bắt đầu generate output, rồi rơi vào vòng lặp — xuất ra whitespace hoặc text lặp lại vô hạn. Team LlamaIndex gọi đây là failure mode "Infinite Loop".

Nói thẳng ra thì model không "hiểu" nó đang lặp. Nó chỉ predict token tiếp theo, và nếu pattern trước đó toàn khoảng trắng, token tiếp theo nhiều khả năng cũng là khoảng trắng. Cứ thế, vòng xoáy kéo dài cho đến khi hit max token limit — và trong lúc đó, GPU cháy tiền, queue tắc nghẽn, user thì ngồi chờ dài cổ.

Ví dụ cụ thể: Giả sử team bạn 5 người, đang build hệ thống xử lý hóa đơn cho một công ty logistics. Mỗi ngày có khoảng 500 tài liệu scan đẩy vào pipeline. Chỉ cần 2–3 tài liệu trigger vòng lặp này, GPU instance của bạn bị chiếm toàn bộ, queue xử lý ùn lại, và 497 hóa đơn còn lại nằm im chờ chết. Khách hàng gọi lên hỏi "sao chưa xong?" — bạn mở dashboard thấy model vẫn đang hăng say... generate khoảng trắng.

Cú sập thứ hai: AI "giật phanh" — nhìn tài liệu rồi bỏ đi

Nếu cú đầu tiên là đầu bếp khuấy nồi mãi không dừng, thì cú thứ hai là đầu bếp nhìn nguyên liệu rồi... buông đũa bỏ đi. Không nấu. Không giải thích.

VLM hiện đại đều có safety filter. Khi model "nghĩ" rằng nội dung nó đang xử lý vi phạm policy — ví dụ trích dẫn y văn có mô tả chấn thương, hợp đồng bảo hiểm mô tả tai nạn, hay tài liệu pháp lý nhạy cảm — nó dừng generate ngay lập tức. LlamaIndex gọi đây là "Hard Stop" do recitation và content blocking.

Plot twist: tài liệu hoàn toàn hợp pháp. Không có gì vi phạm. Nhưng model "tưởng" nó đang recite copyrighted content hoặc nội dung nhạy cảm, nên từ chối làm việc.

Kịch bản team Việt Nam: Bạn đang build hệ thống trích xuất thông tin từ hồ sơ bệnh án cho một bệnh viện. Mọi thứ chạy ngon lành với phần lớn tài liệu. Nhưng một số hồ sơ có mô tả chi tiết về tình trạng bệnh nhân — model đọc đến đoạn đó thì im lặng. Không output, không lỗi rõ ràng, chỉ trả về kết quả trống hoặc bị cắt giữa chừng. Và bạn không biết nó fail — vì nó không throw exception. Nó chỉ đơn giản là... không trả lời đầy đủ. Data integrity bay màu mà không ai hay.

Bếp vẫn phải mở — mitigation cho người thực chiến

Vậy bỏ VLM, quay về Tesseract thuần cho lành? Không hẳn. Bạn không sa thải đầu bếp giỏi chỉ vì anh ta thỉnh thoảng quên tắt bếp — bạn lắp thêm hệ thống báo khói.

Dưới đây là các chiến lược mà team LlamaIndex áp dụng, và bạn hoàn toàn có thể build tương tự:

1. Output health check — phát hiện vòng lặp sớm

Monitor output ngay trong quá trình generation. Nếu phát hiện cùng một chuỗi ký tự xuất hiện liên tiếp quá N lần, kill process và đánh dấu tài liệu đó. Quan trọng nhất: đặt timeout cho mỗi trang. Đây là lưới an toàn cơ bản mà nhiều team quên.

2. Fallback pipeline — luôn có plan B

Khi VLM fail trên một tài liệu, tự động chuyển sang OCR truyền thống (Tesseract, EasyOCR — cả hai đều open-source). Chất lượng có thể kém hơn, nhưng "có output" luôn tốt hơn "không có gì". Ghi log tài liệu bị fail để phân tích pattern theo thời gian.

3. Prompt engineering cho extraction

Với use case y tế, pháp lý — những ngành mà tài liệu hay trigger safety filter — cần prompt rõ ràng: "Đây là tài liệu chuyên ngành hợp pháp, nhiệm vụ của bạn là extract text, không phải đánh giá nội dung." Một dòng prompt có thể cứu cả pipeline.

4. Queue isolation — cách ly tài liệu "khó tính"

Tài liệu đã từng gây lỗi hoặc thuộc nhóm rủi ro cao → đẩy vào queue riêng với resource limit thấp hơn. Một tài liệu "quái" không được phép block cả hệ thống.

Thử chiều nay: stress-test pipeline của bạn trong 30 phút

Nếu bạn đang dùng VLM xử lý tài liệu — dù là LlamaParse, GPT-4o, hay Gemini — đây là bài kiểm tra nhanh:

1. Thu thập "tài liệu quái": lấy 10–20 edge case — scan mờ, bảng phức tạp, trang gần trắng, tài liệu có nội dung y tế hoặc pháp lý. Đẩy qua pipeline.
2. Đo thời gian xử lý từng trang: trang nào mất gấp 5 lần trung bình → dấu hiệu vòng lặp.
3. So sánh output length vs input complexity: trang đơn giản mà output dài bất thường = repetition. Trang phức tạp mà output ngắn bất thường = content blocking.
4. Kiểm tra timeout: nếu pipeline chưa có timeout per-document, thêm ngay hôm nay. Nghiêm túc.

Bài học từ bếp production

Cái hay của bài post-mortem từ LlamaIndex không phải ở giải pháp — mà ở sự thẳng thắn. Ít team dám public thừa nhận service của mình sập, và còn ít hơn nữa team giải thích tại sao nó sập theo cách mà developer khác học được.

Hầu hết failure mode trong AI production không phải lỗi code. Nó là loại lỗi mà model "đúng" theo logic của nó, nhưng "sai" hoàn toàn theo kỳ vọng của bạn. Bạn không debug được bằng stack trace — bạn phải hiểu model đang "nghĩ" gì.

Nếu bạn đang build hệ thống document processing, đừng chỉ test happy path. Hãy test cả kịch bản model đơ, model từ chối, model "sáng tạo" quá mức. Vì ngoài production, nồi phở không tự tắt bếp — và AI cũng vậy.

---

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