Đọc ảnh hiện trường, biểu mẫu viết tay và video của khách bằng vision model: hướng dẫn từng bước

Người dùng ở hiện trường không chụp ảnh theo kiểu tài liệu mẫu. Kỹ thuật viên chụp phiếu kiểm tra từ xa, điện thoại xoay ngang, chữ viết tay có dấu tiếng Việt, kèm thêm một clip 3 phút quay băng chuyền mà chuyện đáng chú ý chỉ xảy ra trong nửa giây.

Demo chạy trên ảnh sạch thì đẹp, còn ảnh thật của khách mới cho biết pipeline có dùng được hay không.

Với một FDE, đây là việc rất hay gặp: khách đưa một thư mục ảnh, PDF scan và video rồi hỏi “AI đọc được không?”. Bài này đi qua cách dựng một pipeline nhỏ đọc ba loại đầu vào đó, kiểm tra kết quả ở từng bước và biết chỗ nào model hay sai.

Bạn sẽ dựng gì, và cần chuẩn bị gì?

Thử hình dung khách là một công ty bảo trì nhà máy. Họ gửi ba thứ: ảnh một máy bơm hỏng, ảnh biểu mẫu kiểm tra viết tay, và video điện thoại quay dây chuyền. Đầu ra mong muốn là JSON có cấu trúc để kỹ sư của khách duyệt lại, chứ không phải một đoạn văn mô tả chung chung.

Nền tảng ở đây là Vision Language Model (VLM). Hugging Face định nghĩa đây là các model hiểu và xử lý được cả hình ảnh lẫn văn bản. Bạn cần một API key cho model đọc ảnh (bài dùng tài liệu của OpenAI làm ví dụ) và một model đọc video (bài dùng Gemini), cùng khoảng 20 mẫu thật của khách.

Chuẩn bị quan trọng nhất không nằm ở code mà là bộ đáp án. Với mỗi biểu mẫu, hãy tự gõ lại nội dung đúng. Với mỗi video, ghi lại mốc thời gian của sự kiện cần bắt. Thiếu bộ này thì bạn không có cách nào biết model đọc đúng hay sai.

Bước 1: lỗi hay nằm ở ảnh đầu vào

Tài liệu vision của OpenAI ghi rõ model có thể hiểu sai chữ và ảnh bị xoay hoặc lộn ngược. Ảnh chụp từ điện thoại ở hiện trường thường bị như vậy. Vì thế việc đầu tiên là chuẩn hóa chiều ảnh trước khi gửi, bằng bất kỳ thư viện xử lý ảnh nào bạn quen dùng.

Việc thứ hai là xử lý chữ nhỏ. Với biểu mẫu chụp từ xa, OpenAI khuyên phóng to phần chữ trong ảnh để model đọc dễ hơn. Trên thực tế, bạn có thể cắt riêng vùng có chữ viết tay rồi phóng to vùng đó, thay vì gửi cả tấm ảnh mà chữ chỉ chiếm một góc nhỏ.

Việc thứ ba dễ bị quên nhất: kiểm tra kích thước. Mỗi request có giới hạn dung lượng khi gửi nhiều ảnh, và tài liệu nói ảnh vượt giới hạn 30,000 patch sau khi xử lý sẽ bị từ chối, không được tự thu nhỏ. Nếu khách tải lên ảnh rất lớn từ máy ảnh chuyên dụng, pipeline phải tự thu nhỏ ảnh trước khi gửi.

Kiểm tra sau bước 1: mở 10 ảnh đã xử lý và tự đọc bằng mắt. Nếu bạn phải nghiêng đầu hoặc nheo mắt mới đọc được thì model cũng sẽ đọc khó.

Bước 2: chọn cách gửi ảnh và thử tham số detail

OpenAI hỗ trợ ba cách đưa ảnh vào: URL, Base64 data URL, hoặc file ID. Nếu ảnh của khách nằm trong mạng nội bộ không truy cập được từ ngoài thì URL không dùng được, và Base64 thường là lựa chọn đơn giản nhất. Cấu trúc request dưới đây đã được giản lược; tên trường chính xác cần đối chiếu với tài liệu API bạn đang dùng:

{
  "role": "user",
  "content": [
    { "type": "text", "text": "Đọc biểu mẫu kiểm tra này và trả về JSON." },
    { "type": "image", "image_url": "data:image/jpeg;base64,<...>", "detail": "high" }
  ]
}

Tham số detail quyết định cách ảnh được tiền xử lý. Mức low cho kết quả thô, và tài liệu nói rõ low không phải lúc nào cũng tốn ít token hơn high. Vì vậy đừng mặc định chọn low để tiết kiệm. Hãy gửi cùng một ảnh ở hai mức, rồi ghi lại số token và số trường đọc đúng của mỗi lần.

Bước 3: đọc biểu mẫu tay mà không tin hết vào model

Tài liệu của OpenAI liệt kê vài giới hạn đã biết: model chỉ đếm số vật thể ở mức xấp xỉ, xác định vị trí trong ảnh còn yếu, và xử lý chữ không phải Latin chưa tốt. Tiếng Việt dùng chữ Latin nhưng có nhiều dấu, nên bạn cần kiểm thử riêng phần dấu thay vì cho rằng model sẽ đọc đúng.

Chữ “máy bơm hỏng” đọc thành “may bom hong” thì có thể vẫn hiểu được, nhưng với tên người hoặc tên linh kiện thì sai dấu là sai thông tin.

Từ các giới hạn đó, prompt nên cho model một cách để báo là nó không chắc:

Đọc biểu mẫu kiểm tra trong ảnh. Trả về JSON với các trường:
ma_thiet_bi, ngay_kiem_tra, nguoi_kiem_tra, tinh_trang, ghi_chu.
Nếu một trường không đọc rõ, ghi "KHONG_DOC_DUOC" thay vì đoán.
Giữ nguyên dấu tiếng Việt như trong ảnh.

Với ảnh máy bơm hỏng, đừng giao cho model những việc như “đếm có bao nhiêu bu lông bị gỉ” hoặc “chỉ chính xác vết nứt nằm ở tọa độ nào”. Đó chính là phần đếm và định vị mà tài liệu cảnh báo là yếu.

Hãy hỏi những câu mang tính mô tả, ví dụ có dấu hiệu rò rỉ hay không, và để con người xác nhận các con số.

Kiểm tra sau bước 3: so JSON với bộ đáp án theo từng trường, không chấm theo từng ảnh. Bạn sẽ thấy ngay trường nào hay sai, thường là tên riêng có dấu và chữ số viết tay.

Bước 4: video bị lấy mẫu 1 khung hình mỗi giây

Gemini mặc định lấy mẫu video ở mức 1 khung hình mỗi giây. Với clip băng chuyền, nếu một sản phẩm rơi ra trong nửa giây thì model có thể không thấy khung hình đó.

Bạn có thể chỉnh tần suất lấy mẫu bằng cách truyền tham số fps trong object cấu hình processing, đồng thời giới hạn đoạn clip cần xem. Đoạn dưới đây cũng đã được giản lược để minh họa ý tưởng:

{
  "processing": { "fps": 5 }
}

Bạn cũng có thể hỏi về một thời điểm cụ thể bằng mốc dạng MM:SS:

Tại 02:14, sản phẩm trên băng chuyền có rơi ra ngoài không?
Mô tả trạng thái băng chuyền từ 02:10 đến 02:20.

Chi phí cũng cần tính trước. Ở độ phân giải mặc định (low), video tốn khoảng 100 token mỗi giây. Clip 10 phút là 600 giây, tức khoảng 60,000 token cho mỗi lần hỏi. Nếu chỉ cắt 2 phút cần xem, con số còn khoảng 12,000.

Lưu ý rằng ước tính này dựa trên mức mặc định 1 khung hình mỗi giây; khi tăng fps, hãy đo lại số token thực tế thay vì giữ nguyên con số cũ.

Google cũng đã giới thiệu tính năng agentic video understanding, bật qua một thiết lập trong API. Tính năng này nhắm vào đúng vấn đề trên: bắt các thay đổi trạng thái chỉ diễn ra trong tích tắc, dễ bị bỏ sót ở 1 FPS. Nếu bài toán của khách là bắt khoảnh khắc ngắn như vậy, đây là lựa chọn đáng thử so với cách tự tăng fps.

Bước 5: dữ liệu bẩn là trạng thái bình thường

Splunk khi mô tả AI đa phương thức đã nêu ba khó khăn: độ nhiễu khác nhau, dữ liệu bị thiếu, và việc ghép dữ liệu từ nhiều nguồn. Ở hiện trường, cả ba xảy ra cùng lúc: ảnh mờ, biểu mẫu thiếu trang, video không khớp với phiếu ghi. Pipeline phải coi tình trạng này là bình thường chứ không phải ngoại lệ.

Đầu vào	Lỗi hay gặp	Việc làm đầu tiên
Ảnh hiện trường	Xoay ngược, file quá lớn bị từ chối	Chuẩn hóa chiều ảnh, thu nhỏ trước khi gửi
Biểu mẫu viết tay	Chữ nhỏ, sai dấu tiếng Việt	Cắt và phóng to vùng chữ, cho phép trả về “không đọc được”
Video điện thoại	Bỏ sót sự kiện nhanh ở 1 FPS	Cắt đoạn cần xem, tăng fps, hỏi theo MM:SS

Kỹ năng này xuất hiện ở công việc thật như thế nào?

Ở khách hàng, phần khó không nằm ở việc gọi API mà ở việc nói thật về độ chính xác. Khi demo, hãy cho khách xem bảng chấm theo từng trường trên chính dữ liệu của họ: tên thiết bị đúng bao nhiêu phần trăm, ngày tháng đúng bao nhiêu, trường nào cần người duyệt lại.

Một bảng như vậy thuyết phục hơn nhiều so với một ảnh demo chạy hoàn hảo.

Khi đọc JD vị trí FDE, hãy để ý các cụm như “unstructured data”, “document processing” hay “multimodal”. Trong CV, thay vì viết “dùng GPT-4 Vision”, hãy viết cụ thể bạn đã nâng độ chính xác đọc biểu mẫu viết tay tiếng Việt từ bao nhiêu lên bao nhiêu nhờ xoay ảnh và cắt vùng chữ. Con số đó cho thấy bạn đã làm việc với dữ liệu thật.

Ảnh chụp nghiêng đầu tiên khách gửi cho bạn là dấu hiệu tốt. Nó có nghĩa là bạn đang làm với dữ liệu thật của khách, không còn là bản demo.