Tin tức & ghi chú kỹ thuật

Bài toán đếm SKU trên ảnh nghe đơn giản: đếm số hộp, số sản phẩm trong một khung hình. Nhưng nó khó ở chỗ các vật thể thường nhỏ so với toàn bức ảnh, xếp sát nhau, và đôi khi ảnh có phần mờ do góc chụp hoặc điều kiện ánh sáng thực tế tại nhà máy hoặc kho hàng.

Một mô hình object detection tiêu chuẩn như YOLOv8 chạy một lần suy luận trên toàn bức ảnh sẽ có xu hướng bỏ lỡ các vật thể nhỏ nằm dày đặc, vì mô hình phải "nhìn" cả bức ảnh lớn trong một lần và các vật thể nhỏ chiếm quá ít pixel để mô hình tự tin phát hiện.

SAHI (Slicing Aided Hyper Inference) giải quyết vấn đề này bằng một cách rất trực tiếp: cắt ảnh gốc thành nhiều lát nhỏ chồng lấn nhau, chạy suy luận YOLOv8 riêng trên từng lát, rồi ghép kết quả lại và loại bỏ các phát hiện trùng lặp ở vùng chồng lấn. Vì mỗi lát nhỏ hơn, vật thể nhỏ trong lát đó chiếm tỷ lệ pixel lớn hơn, nên mô hình phát hiện chính xác hơn.

Trong module đã nghiệm thu, cách kết hợp YOLOv8 và SAHI này cho ra kết quả đếm trong thời hạn SLA dưới 3 giây, kèm ảnh xuất ra có vẽ khung bounding box cho từng vật thể được đếm. Hệ thống cũng ghi lại phiên bản mô hình đã dùng cho lần đếm đó, để khi khách hàng hỏi "vì sao lần này đếm khác lần trước", chúng tôi có thể tra ngược lại chính xác phiên bản đã chạy.

Bộ test của hệ thống SOAI được chia thành ba lớp. Lớp thứ nhất là 10 test suite unit và integration ở backend, bao phủ models, các `AnalysisEngine`, các worker xử lý bất đồng bộ (Celery) và các API. Lớp thứ hai là 99 kịch bản end-to-end, đi qua toàn bộ luồng dữ liệu thật: Upload → Process → Storage → Query. Nghĩa là kiểm tra không chỉ một hàm chạy đúng, mà cả một chuỗi bước từ lúc người dùng tải video lên đến lúc họ tra được kết quả.

Lớp thứ ba là 27 bài test áp lực và đối kháng (stress & adversarial media test): đưa vào hệ thống video/ảnh mờ, file bị hỏng cấu trúc, mã QR không đọc được rõ, và kết nối mạng bị ngắt giữa lúc xử lý.

Vì sao lớp thứ ba này quan trọng hơn ở một hệ thống giám sát so với phần mềm thông thường: nếu một ứng dụng quản lý văn bản gặp file hỏng và báo lỗi, người dùng thử lại là xong. Nhưng nếu một hệ thống giám sát gặp video hỏng hoặc ảnh mờ và im lặng trả về "không phát hiện vi phạm", một kết quả trông hoàn toàn bình thường, thì đó là một lỗ hổng an toàn thực sự, vì không ai biết hệ thống đã thất bại.

Hãy tưởng tượng một tình huống cụ thể: một file video ghi lại quá trình đóng hàng bị hỏng một phần do lỗi ghi đĩa, và khi hệ thống cố trích xuất khung hình bằng FFmpeg, lệnh gọi thất bại. Có hai cách một hệ thống có thể xử lý việc này. Cách thứ nhất: bắt lỗi, trả về một kết quả mặc định rỗng, ví dụ "không tìm thấy mã QR" hoặc "không phát hiện vi phạm", và tiếp tục chạy. Cách thứ hai: để lỗi đó nổi lên thành một exception rõ ràng, kèm thông tin vì sao thất bại.

Chúng tôi chọn cách thứ hai. Toàn bộ hệ thống SOAI dùng một hệ thống ngoại lệ tuỳ biến gọi là `SOAIException`, phân theo loại lỗi cụ thể (lỗi cơ sở dữ liệu, file hỏng, lỗi xử lý media, lỗi kết nối thiết bị...). Mọi sự cố đều đi qua hệ thống này, được quăng lên thành một lỗi minh bạch kèm HTTP response tuân thủ chuẩn RFC, và được ghi log chi tiết.

Lý do điều này quan trọng với đúng bản chất của một hệ thống giám sát: giá trị của hệ thống nằm ở việc nó có thể trả lời chính xác "có" hoặc "không" cho một câu hỏi nghiệp vụ (có đủ hàng không, có vi phạm an toàn không). Một cách fallback im lặng, tức trả về mặc định khi gặp lỗi, sẽ biến một sự cố kỹ thuật thành một câu trả lời nghiệp vụ sai, và người xem báo cáo sẽ không có cách nào phân biệt được "không có vi phạm thật" với "hệ thống đã thất bại nhưng không ai biết".

Nói cách khác, một lỗi hiện rõ và được ghi log là một sự cố có thể sửa. Một lỗi bị nuốt âm thầm là một sự cố sẽ quay lại tìm chúng tôi, dưới dạng một khách hàng mất niềm tin vào dữ liệu mà hệ thống báo cáo.