API Xóa Nền: Cách Hoạt Động và Những Điều Cần Kiểm Tra
Tìm hiểu cách một API xóa nền trả về các mặt nạ PNG trong suốt, xử lý các cạnh cứng và phù hợp với quy trình làm việc hình ảnh và video trong sản xuất.

Một bản xem trước đẹp mắt có thể là đầu ra ít hữu ích nhất mà một API xóa nền trả về. Nếu tệp đằng sau nó không có alpha channel thực sự, hoặc nếu các cạnh của nó bị cắt cứng, bạn không thể composite nó một cách sạch sẽ trên một nền mới, tái sử dụng nó trên các mẫu, hoặc tin cậy nó trong một batch. Tôi thà chọn một tệp độ phân giải thấp với một matte chính xác hơn là một hình ảnh trông sắc nét nhưng lại giả mạo độ trong suốt bằng một ô bàn cờ được vẽ.
Đó là bài kiểm tra cần áp dụng xuyên suốt. Sản phẩm không phải là thumbnail. Đó là pixel level transparency mà bạn có thể kiểm tra, đo lường và tái sử dụng mà không cần dọn dẹp thủ công.
Mục lục
- Tổng quan về các kết quả đầu ra của API xóa nền
- Cách gửi ảnh và nhận kết quả trong suốt
- So sánh các mô hình Sync, Async và Webhook
- Đo lường chất lượng mặt nạ bằng kiểm thử chấp nhận
- Các trường hợp khó mà mặt nạ thất bại và cách khắc phục
- Khung hình video và tính nhất quán thời gian
- Xác thực tải lên, khóa và xử lý lỗi
- Xác nhận lựa chọn của bạn trước khi triển khai
Tổng quan về các định dạng đầu ra của API xóa nền
Một API xóa nền nhận một hình ảnh được tải lên, tách chủ thể khỏi nền, và trả về một hình ảnh trong suốt, một alpha matte, hoặc một mask. Câu nói đơn giản đó ẩn chứa một quyết định quan trọng định hình hầu hết các công việc tiếp theo. Bạn không chỉ mua khả năng phát hiện chủ thể. Bạn đang mua một hợp đồng tệp cụ thể.
Năm định dạng đầu ra, năm cam kết khác nhau
| Định dạng đầu ra | Nội dung | Tốt nhất cho | Rủi ro chính |
|---|---|---|---|
| RGBA PNG cutout | Các pixel của chủ thể cộng với kênh alpha | Ghép ảnh lên nền mới và ảnh danh mục sản phẩm | Viền sáng/tối (halos) nếu alpha bị ngưỡng hóa cứng |
| 8-bit alpha matte | Độ trong suốt một phần cho mỗi pixel | Tóc, lông, kính và hiệu ứng mờ chuyển động | Khó xem trước nếu không ghép ảnh |
| Binary mask | Tiền cảnh là 1,, hậu cảnh là 0 | Kiểm tra vùng và cắt ảnh hàng loạt | Mất hoàn toàn các cạnh mềm |
| Transparent WebP | Kênh alpha trong WebP | Phân phối trên web với tệp nhỏ hơn | Chế độ nén mất dữ liệu có thể làm mờ các cạnh tinh xảo |
| Flattened JPEG on white | Không có độ trong suốt | Danh sách sản phẩm trên sàn thương mại điện tử yêu cầu nền trắng | Nền bị cố định và không thể tái sử dụng |
Một RGBA PNG cutout là lựa chọn mặc định an toàn nhất khi người khác sẽ ghép ảnh kết quả. Bạn giữ lại các pixel màu của chủ thể và một giá trị trong suốt riêng biệt cho mỗi pixel, để một hệ thống bố cục có thể đặt cùng một tài sản lên nền trắng, màu thương hiệu hoặc một bức ảnh. Rủi ro xuất hiện ở đường biên. Nếu nhà cung cấp đã ngưỡng hóa một cạnh mềm thành hoàn toàn mờ đục hoặc hoàn toàn trong suốt, bạn sẽ thấy một viền sáng hoặc tối ngay khi nền mới tương phản với nền cũ.
Một 8-bit alpha matte mang lại cho bạn quyền kiểm soát tối đa và khả năng xem trước ít tiện lợi nhất. Vì mỗi pixel có thể mang độ che phủ một phần, đây là định dạng phù hợp cho các sợi tóc, lông, viền kính, ren và hiệu ứng mờ chuyển động. Bạn cần bước ghép ảnh của riêng mình để đánh giá nó, đây chính là lý do tại sao các nhóm bỏ qua việc đánh giá và bỏ lỡ các vấn đề. Hãy đánh giá nó sau khi đã ghép ảnh, chứ không phải dưới dạng một hình ảnh màu xám.
Một binary mask giải quyết một vấn đề hẹp hơn. Nó hữu ích cho việc cắt ảnh, đếm vùng hoặc kiểm tra xem chủ thể có hiện diện hay không, với điều kiện nhà cung cấp tài liệu hóa ngưỡng được sử dụng để tạo ra nó. Theo định nghĩa, nó không thể hỗ trợ các cạnh mềm. Nếu quy trình của bạn biến một binary mask trở lại thành hình ảnh sản phẩm, các chi tiết mỏng manh đã biến mất.
Transparent WebP là một lựa chọn để phân phối, không phải là nâng cấp chất lượng. Nó có thể giảm kích thước tệp cho việc sử dụng trên web, nhưng các cài đặt nén mất dữ liệu có thể làm mờ đồ trang sức mỏng, chữ trên bao bì và tóc. Hãy giữ một bản gốc không mất dữ liệu và tạo WebP từ đó, để bạn có thể thay đổi nén sau này mà không cần gọi lại API.
Một flattened JPEG on white chỉ ổn khi nơi đến vĩnh viễn yêu cầu nền trắng và bạn giữ bản gốc ở nơi khác. Một khi đã được làm phẳng, bạn không thể khôi phục độ trong suốt, thay đổi nền hoặc tái tạo bóng mềm. Thị trường xóa nền bằng AI toàn cầu được định giá USD 1.42 tỷ vào năm 2024, theo Growth Market Reports, đây là một lời nhắc nhở tốt rằng nhiều nhà cung cấp sẽ bán cho bạn một kết quả, nhưng không nhất thiết là một kết quả có thể tái sử dụng.
Bắt đầu từ đây: Hãy chọn định dạng đầu ra mà quy trình của bạn cần trước khi so sánh các nhà cung cấp, bởi vì một nhà cung cấp có thể thắng thế với bản xem trước JPEG nhưng lại hoàn toàn thất bại khi là nguồn matte.
Cách gửi ảnh và nhận kết quả trong suốt
Quy trình làm việc đủ ngắn để thiết lập trong một buổi chiều, miễn là bạn xác minh tệp bạn nhận được thay vì tin tưởng bản xem trước. Bắt đầu với đầu ra bạn đã chọn, sau đó làm theo trình tự này.

Trình tự gọi
- Chuẩn bị đầu vào. Áp dụng các quy tắc xác thực tải lên của bạn trước khi gửi, để các tệp bị lỗi định dạng hoặc quá khổ bị lỗi trong mã của bạn với một thông báo lỗi rõ ràng. Đừng trả chi phí suy luận chỉ để phát hiện ra một tệp chưa bao giờ là hình ảnh.
- Xác thực bằng một API key có phạm vi. Sử dụng một API key dành riêng cho ứng dụng này, không phải một API key dùng chung cho không gian làm việc. Nếu nó bị lộ, bạn có thể thu hồi nó mà không làm hỏng các dịch vụ không liên quan.
- Gửi ảnh và yêu cầu loại đầu ra. Yêu cầu RGBA PNG khi kết quả sẽ được tổng hợp. Lỗi thường gặp là chấp nhận cài đặt mặc định của nhà cung cấp làm phẳng ảnh lên nền trắng.
- Đọc metadata phản hồi. Xác nhận kích thước đầu ra, mô hình màu và độ sâu bit alpha trước khi lưu tệp. Một thao tác thay đổi kích thước hoặc chuyển đổi màu sắc âm thầm sẽ làm hỏng kích thước và màu sắc thương hiệu sau này.
- Xử lý phản hồi tác vụ một cách chính xác. Nếu bạn nhận được một ID tác vụ thay vì một hình ảnh, hãy thăm dò để hoàn thành hoặc chờ webhook. Đừng coi một phản hồi đang chờ xử lý là một hình ảnh bị lỗi và gửi các bản sao.
- Xác minh kênh alpha bằng lập trình. Giải mã tệp và xác nhận kênh alpha tồn tại, không hoàn toàn mờ đục, không trống và chứa các giá trị trung gian dọc theo các cạnh. Kiểm tra này phát hiện các mô hình vẽ một bàn cờ vào một hình ảnh RGB thông thường.
- Lưu trữ kết quả bằng một content hash. Giữ hình ảnh gốc riêng biệt để kiểm tra và xử lý lại. Hash cho phép bạn lưu vào bộ nhớ cache một cách an toàn và chứng minh đầu ra nào đến từ đầu vào nào.
Tài liệu về media của chúng tôi](https://uberllm.dev/docs/media) là điểm tham chiếu về cách các tác vụ media được gửi và trả về, nhưng bước xác minh thuộc về client của bạn bất kể nhà cung cấp nào. Các nhà cung cấp có thể thay đổi mô hình trong khi vẫn giữ endpoint ổn định.
Quy ước alpha của PNG
Đặc tả PNG của W3C](https://www.w3.org/TR/PNG-DataRep.html) định nghĩa các mẫu alpha trên thang đo 8- hoặc 16-bit, trong đó không có nghĩa là hoàn toàn trong suốt, giá trị tối đa có nghĩa là hoàn toàn mờ đục, và các giá trị trung gian đại diện cho độ che phủ một phần có thể được tổng hợp với một nền mới. Những giá trị trung gian đó là điểm mấu chốt. Tóc, vật liệu trong mờ và các cạnh được khử răng cưa không chiếm các pixel theo kiểu tất cả hoặc không có gì.
Kiểm tra xem các giá trị RGB là straight alpha hay premultiplied alpha, và ghi lại điều đó trong metadata tài sản của bạn. Nếu bộ tổng hợp của bạn giả định một loại và tệp sử dụng loại kia, các cạnh sẽ tối đi hoặc sáng lên ngay cả khi mặt nạ chính xác. Cũng hãy nhớ rằng PNG chứa tiền cảnh và độ trong suốt, chứ không phải nền cuối cùng. Việc tổng hợp vẫn ở phía sau, nơi nó có thể được lặp lại một cách rẻ tiền.
Hướng dẫn này cho thấy luồng yêu cầu và phản hồi dự kiến trong thực tế.
Một kết quả tốt vẫn sạch sẽ khi đặt trên nền đen, trắng và một màu bão hòa. Bạn sẽ không thấy quầng sáng chói, tóc bị cắt cụt, và không có hình chữ nhật mờ đục ở nơi kính nên cho phép nền mới hiển thị. Hãy kiểm tra ở độ phân giải đầy đủ, không phải kích thước hình thu nhỏ, vì việc chia tỷ lệ hình thu nhỏ che giấu gần như mọi lỗi cạnh mà bạn sẽ quan tâm trong sản xuất.
So sánh các mô hình Sync, Async và Webhook
Các hình ảnh đã cắt không trả về trên kết nối HTTP đang mở. Trên UberLLM, văn bản truyền theo từng token, trong khi một tác vụ hình ảnh hoặc video trả về một tác vụ mà bạn thăm dò (poll), hoặc một webhook báo cáo kết quả đã sẵn sàng. Hãy chọn thăm dò (polling) hoặc gọi lại (callback) dựa trên thời gian hệ thống khác cần phản ứng, và số lượng tác vụ bạn sẽ có đang thực hiện. Một ảnh sản phẩm đơn lẻ và một nguồn cấp dữ liệu nhà cung cấp qua đêm sử dụng cùng một mô hình tác vụ. Chúng không nên dùng chung một thiết kế client.
Chờ đợi một tác vụ cho công việc tương tác
Đối với một bản thử nghiệm (prototype) hoặc bản xem trước dành cho người dùng, hãy gửi hình ảnh, lưu trữ ID tác vụ và thăm dò (poll) cho đến khi tệp PNG trong suốt sẵn sàng. Người chờ đợi vẫn thấy một trạng thái tiến trình duy nhất. Bên dưới, client đang thăm dò một tác vụ, vì vậy một người bán chậm không làm kẹt một luồng yêu cầu cho toàn bộ quá trình tạo.
Đặt một thời gian chờ giới hạn cho việc chờ đợi đó, và thử lại các kiểm tra trạng thái bằng một idempotency key để việc thử lại không bắt đầu một suy luận thứ hai. Hiển thị trạng thái tiến trình và đường dẫn thất bại. Đừng để màn hình tải lên quay mãi. Chỉ thay đổi kích thước theo một quy tắc đã được ghi lại. Việc giảm kích thước đầu vào để làm cho thời gian chờ có vẻ ngắn hơn sẽ phá hủy các cạnh tinh tế và làm cho các so sánh chất lượng sau này trở nên không hợp lệ. Kênh alpha là tài sản bạn đang chờ đợi, không phải một bản xem trước đã được làm phẳng.
Thăm dò (Polling) cho hình ảnh lớn và các lô
Một cuộc gọi dựa trên tác vụ sẽ trả về một định danh trước. Bạn thăm dò trạng thái cho đến khi hình ảnh đã cắt sẵn sàng. Sự phân tách đó quan trọng khi phương tiện nằm cạnh trò chuyện: văn bản truyền theo luồng, còn hình ảnh và video thì không, ngay cả dưới một API key.
Thăm dò với backoff. Đảm bảo các kiểm tra trạng thái an toàn để thử lại. Lưu trữ ID tác vụ trước lần thăm dò đầu tiên, vì việc khởi động lại quy trình không nên làm mất một tác vụ đã trả phí. Theo dõi tác vụ Async và các cuộc gọi lại webhook giúp các quy trình làm việc với phương tiện truyền thông khối lượng lớn tiếp tục hoạt động khi các hình ảnh riêng lẻ hoàn thành không theo thứ tự.
Webhooks cho các quy trình
Sử dụng các cuộc gọi lại webhook khi một hệ thống khác cần hành động ngay khi một hình ảnh đã cắt sẵn sàng, chẳng hạn như một nhà xuất bản danh mục hoặc trình kết xuất mẫu. Xác thực người gọi trên endpoint của riêng bạn trước khi bạn tin tưởng payload, xác nhận nhanh chóng và thực hiện việc tải xuống và lưu trữ nặng nề trong hàng đợi của riêng bạn. Trình xử lý của bạn phải chấp nhận các lần gửi trùng lặp mà không xuất bản tài sản hai lần.
Hướng dẫn Photo Editing API mô tả việc xóa nền là một thao tác trong một luồng chỉnh sửa rộng hơn, đây là nơi các cuộc gọi lại thể hiện sự phức tạp của chúng. Đối với các tác vụ hình ảnh và video, theo dõi tác vụ và các cuộc gọi lại webhook có nghĩa là một sự gián đoạn đối với một người bán sẽ không làm mất tác vụ của khách hàng. Bạn vẫn cần đối chiếu. Theo một lịch trình, hãy liệt kê các tác vụ chưa bao giờ tạo ra một cuộc gọi lại và thăm dò chúng trực tiếp.
Thăm dò (Poll) hoặc đăng ký (subscribe) cho mọi tác vụ hình ảnh, bao gồm cả một bản thử nghiệm (prototype) một lần. Chuyển từ thăm dò chặt chẽ sang webhooks khi hình ảnh đến theo lô hoặc cấp dữ liệu cho một hệ thống tự động khác.
Đo lường chất lượng mặt nạ bằng thử nghiệm chấp nhận
Đừng chấp thuận một nhà cung cấp chỉ vì hai mươi hình ảnh mẫu trông đẹp mắt trên trình duyệt. Hãy xây dựng một bài kiểm tra chấp nhận có thể lặp lại với đầu vào cố định, ngưỡng cố định và các chỉ số phân biệt giữa việc phát hiện đối tượng thô với chất lượng đường biên.

Các chỉ số hỗ trợ đưa ra quyết định
| Chỉ số | Đo lường điều gì | Dùng để đánh giá |
|---|---|---|
| IoU | Độ chồng lấp vùng giữa mặt nạ dự đoán và mặt nạ ground-truth | Độ chính xác phân đoạn thô |
| Dice | Độ chồng lấp được ưu tiên cho các vùng nhỏ hơn | Các đối tượng nhỏ và các bộ phận mỏng |
| Trimap hoặc lỗi đường viền | Độ chính xác dọc theo đường biên | Tóc, lông và các cạnh mềm |
| Độ phủ Alpha | Tỷ lệ pixel bán trong suốt | Liệu độ trong suốt thực sự có được trả về hay không |
| Độ trễ p50 và p95 | Thời gian phản hồi điển hình và đuôi | Thông lượng theo lô và thời gian chờ của người dùng |
| Tỷ lệ thành công khi thử lại | Tỷ lệ các cuộc gọi được thử lại hoàn thành | Độ tin cậy khi gặp lỗi |
IoU và Dice cho bạn biết liệu nhà cung cấp có tìm thấy vùng gần đúng hay không. Chúng không cho bạn biết liệu đường biên có được ghép sạch sẽ hay không. Một mặt nạ có thể đạt điểm cao về độ chồng lấp trong khi cắt bỏ mọi sợi tóc lỏng lẻo, bởi vì tóc chiếm ít pixel so với toàn bộ đối tượng.
Trimap hoặc lỗi đường viền tập trung đánh giá gần đường biên, nơi khách hàng nhận thấy lỗi. Độ phủ Alpha là kiểm tra nhanh chóng và hiệu quả của bạn trên mỗi phản hồi. Nếu các đối tượng được cho là mềm mại chỉ trả về các pixel hoàn toàn mờ đục và hoàn toàn trong suốt, bạn đang xem xét một mặt nạ đã được ngưỡng hóa, một bản giả phẳng, hoặc một tùy chọn đầu ra mà bạn không có ý định yêu cầu.
Độ trễ thuộc về cùng một báo cáo. Ghi lại độ trễ p50 và p95 riêng biệt, cộng với tỷ lệ thành công khi thử lại, bởi vì thời gian phản hồi trung bình che giấu phần đuôi quyết định việc hoàn thành lô và sự từ bỏ của người dùng.
Thiết kế bộ dữ liệu kiểm tra
Tạo một bộ dữ liệu ground truth với mặt nạ cấp độ pixel nếu có thể, và phân tầng nó theo cấu trúc mịn, độ tương phản thấp, vật thể phản chiếu hoặc trong suốt, nhiều đối tượng, bóng đổ và nền lộn xộn. Hướng dẫn đo lường dựa trên phân đoạn của NIST phân biệt mặt nạ nhị phân trong đó nền là 0 và tiền cảnh là 1, một lời nhắc nhở hữu ích rằng API của bạn nên định nghĩa ngữ nghĩa mặt nạ một cách rõ ràng thay vì bắt khách hàng phải đoán.
Bao gồm nhiều loại ánh sáng, thiết bị máy ảnh, tỷ lệ khung hình và các định dạng tệp mà người dùng của bạn thực sự tải lên. Một bộ dữ liệu danh mục studio sẽ không dự đoán được hiệu suất trên ảnh chụp bằng điện thoại trong nhà kho. Một bộ dữ liệu chân dung sẽ không cho bạn biết bất cứ điều gì hữu ích về chai thủy tinh hoặc các bộ phận mạ crôm.
Đặt ngưỡng đạt cho mỗi lớp trước khi kiểm tra. Nếu bạn chọn ngưỡng sau khi xem kết quả, bạn sẽ hợp lý hóa bất cứ điều gì nhà cung cấp đầu tiên trả về. Yêu cầu một alpha matte mềm mại cộng với một mặt nạ nhị phân tùy chọn ở một ngưỡng đã được ghi lại, và đánh giá từng cái cho mục đích sử dụng dự kiến của nó.
Chỉ hiển thị điểm tin cậy cho người dùng sau khi bạn đã hiệu chỉnh nó trên dữ liệu giữ lại. Một điểm số không được hiệu chỉnh sẽ tạo ra sự đảm bảo sai lầm và làm cho hàng đợi đánh giá của con người kém hữu ích hơn, bởi vì người đánh giá ngừng tin tưởng tín hiệu định tuyến.
Chạy lại bộ dữ liệu giống hệt sau bất kỳ thay đổi nào về mô hình hoặc nhà cung cấp. Trong một thị trường hoặc thiết lập định tuyến, hành vi biên có thể thay đổi ngay cả khi endpoint và định dạng yêu cầu vẫn tương thích.
Những Trường Hợp Khó Mà Mặt Nạ Thất Bại Và Cách Khắc Phục
Lỗi tốn kém phổ biến nhất là bỏ sót đối tượng tiền cảnh. Một bàn tay đang cầm sản phẩm biến mất, một người thứ hai bị coi là nền, hoặc một phụ kiện bị cắt bỏ. Điều này gây hại hơn một cạnh thô vì việc ghép ảnh sau này không thể tạo ra đối tượng bị thiếu, và bài kiểm tra chấp nhận của bạn nên đánh trượt toàn bộ lớp khi điều này xảy ra.

Các lỗi cạnh có thể nhìn thấy
- Quầng tóc và lông: Phần cắt trông chấp nhận được trên nền trắng, sau đó hiển thị một viền sáng trên nền tối. Nguyên nhân có thể là do mặt nạ nhị phân hoặc ngưỡng cứng. Yêu cầu một alpha matte và kiểm tra các pixel cạnh để tìm các giá trị một phần.
- Ren, lưới và kim loại mỏng bị đứt: Dây đeo, dây điện, dây chuyền trang sức và nan hoa xe đạp bị đứt thành từng mảnh. Đầu vào có thể thiếu độ phân giải đủ cho cấu trúc, hoặc mô hình có thể phân loại các phần mỏng là kết cấu nền. Gửi ảnh gốc có độ phân giải cao hơn và áp dụng kiểm tra đường viền cho lớp này.
- Va chạm màu sắc giữa chủ thể và nền: Một chiếc váy trắng trên bộ ga trải giường trắng hoặc một chú chó đen trên ghế sofa tối màu tạo ra các cạnh không ổn định. Cách khắc phục không phải là đòi hỏi sự hoàn hảo từ mọi nhà cung cấp. Chuyển các trường hợp độ tương phản thấp đến người kiểm tra hoặc một mô hình mạnh hơn và ghi lại chúng như một lớp kiểm tra riêng biệt.
Đừng che giấu những khuyết điểm này bằng cách thu nhỏ bản xem trước. Ghép ảnh ở kích thước đầy đủ trên một màu tương phản và kiểm tra ranh giới, vì đó là cách khách hàng sẽ gặp phải khi phóng to vào trang sản phẩm.
Các quyết định sản phẩm được ngụy trang thành lỗi mô hình
Các vật thể trong suốt cần một quy tắc sản phẩm. Kính và chai trong suốt nên giữ lại độ trong mờ nơi nền hiển thị xuyên qua. Một matte biến kính hoàn toàn mờ đục sẽ tạo ra hình ảnh sản phẩm trông như sáp, trong khi một matte xóa bỏ hoàn toàn là một lỗi rõ ràng. Quyết định điều gì được coi là đúng cho chai lọ, cửa sổ, mạng che mặt và bao bì nhựa trước khi chấm điểm chúng.
Bóng đổ cũng cần một lựa chọn rõ ràng. Giữ một bóng đổ tiếp xúc mềm dưới dạng alpha một phần nếu bạn muốn một hình ghép tự nhiên, hoặc loại bỏ nó để có một hình cắt sạch cho catalog. Cả hai đều hợp lệ, nhưng việc chuyển đổi giữa chúng trong một catalog sẽ trông không nhất quán. Mã hóa lựa chọn này vào hồ sơ yêu cầu của bạn và kiểm tra nó.
Người chồng chéo kiểm tra sự tách biệt cá thể. Mỗi người nên giữ nguyên sự khác biệt khi các cơ thể chồng chéo, không để cánh tay của một người bị gán vào nền hoặc hợp nhất vào người bên cạnh. Các chỉ số chồng chéo toàn bộ hình ảnh có thể bỏ sót điều này, vì vậy hãy kiểm tra lớp này bằng mắt thường cùng với điểm ranh giới.
Độ trong suốt giả là lỗi ít nhìn thấy nhất và dễ phát hiện nhất. Đừng tìm kiếm một bàn cờ. Giải mã tệp và kiểm tra xem kênh alpha có tồn tại với các pixel trong suốt và bán trong suốt có ý nghĩa hay không. Một mẫu bàn cờ trong RGB là một hình ảnh của độ trong suốt, không phải độ trong suốt thực sự.
Thứ tự phân loại: Kiểm tra sự hiện diện của alpha trước, sau đó là các cạnh, sau đó là các chủ thể bị bỏ sót. Thứ tự đó loại bỏ các tệp không thể sử dụng trước khi bạn dành thời gian đánh giá sự khác biệt chất lượng tinh tế.
Khung hình video và Tính nhất quán thời gian
Video không phải là một thư mục chứa các hình ảnh tĩnh không liên quan. Việc phân đoạn từng khung hình không có bộ nhớ thời gian, vì vậy một ranh giới có thể di chuyển nhẹ giữa các khung hình gần như giống hệt nhau. Khi phát ở tốc độ cao, những thay đổi nhỏ đó sẽ trở thành nhấp nháy xung quanh tóc, tay và các cạnh sản phẩm.
Thông lượng là một hạn chế khác. Mỗi lệnh gọi API cho từng khung hình sẽ thêm một lượt tải lên và một lượt truyền dữ liệu qua mạng trước khi bạn có thể mã hóa kết quả. Một quy trình làm việc có vẻ chấp nhận được cho một bức chân dung có thể trở nên không khả thi đối với một đoạn clip ngắn, ngay cả trước khi bạn xem xét việc thử lại.
Ba kiến trúc
| Kiến trúc | Độ ổn định thời gian | Thông lượng | Tốt nhất cho |
|---|---|---|---|
| Lệnh gọi API từng khung hình | Thấp, ranh giới có thể rung lắc giữa các khung hình | Một lượt truyền dữ liệu qua mạng cho mỗi khung hình | Ảnh tĩnh và clip ngắn có ít khung hình |
| Các tác vụ không đồng bộ phía máy chủ với sự lan truyền | Cao hơn, sử dụng theo dõi thời gian | Xếp hàng và xử lý theo lô | Clip sản phẩm và xử lý theo lô |
| Khung hình chính lai với theo dõi cục bộ | Trung bình, phụ thuộc vào bộ theo dõi | Ít lệnh gọi API nhất | Xem trước trực tiếp và cảnh quay dài |
Lệnh gọi API từng khung hình là nguyên mẫu đơn giản nhất và kiến trúc dễ gỡ lỗi nhất. Chúng cũng kém ổn định nhất và thường tốn nhiều yêu cầu nhất. Hãy sử dụng chúng cho ảnh tĩnh, hình thu nhỏ hoặc một vài khung hình được chọn, không phải là một giả định cho toàn bộ cảnh quay.
Các tác vụ không đồng bộ phía máy chủ với sự lan truyền thời gian cho phép hệ thống xử lý sử dụng thông tin trên nhiều khung hình. Bạn gửi clip hoặc một lô, theo dõi tác vụ và truy xuất một chuỗi mặt nạ ổn định hơn. Điều này phù hợp với các clip sản phẩm và xử lý ngoại tuyến nơi hàng đợi là chấp nhận được.
Khung hình chính lai với theo dõi cục bộ giảm lưu lượng API. Bạn gửi các khung hình chính được chọn để phân đoạn chất lượng cao, sau đó theo dõi đối tượng cục bộ giữa chúng và yêu cầu một khung hình chính mới khi độ tin cậy theo dõi giảm hoặc cảnh thay đổi. Điều này hấp dẫn cho các bản xem trước trực tiếp, nhưng bộ theo dõi trở thành một phần bề mặt chất lượng của bạn và cần các thử nghiệm riêng.
Xây dựng danh sách kiểm tra năng lực trước khi cam kết. Ghi lại số yêu cầu mỗi giây cho mỗi người dùng, giới hạn đồng thời, hành vi hàng đợi, tổng lượng truyền dữ liệu theo cả hai hướng, chi phí thử lại và cách bạn sẽ khôi phục một clip đã xử lý một phần. Giá mỗi hình ảnh rẻ nhất có thể trở thành lựa chọn đắt nhất khi sự không ổn định buộc phải xử lý lại, dọn dẹp thủ công hoặc mã hóa lại.
Ghim mô hình hoặc nhà cung cấp cho một clip, lưu trữ mặt nạ cho mỗi khung hình và ghi lại phiên bản được sử dụng cho mỗi tác vụ. Nếu không có kỷ luật đó, việc chạy lại cùng một cảnh quay sau khi thay đổi định tuyến có thể tạo ra kết quả khác và bạn sẽ không có cách nào rõ ràng để tái tạo phiên bản mà khách hàng đã chấp thuận.
Xác thực Tải lên, Khóa và Xử lý Lỗi
Hầu hết các sự cố sản xuất liên quan đến API xóa nền không phải là lỗi mô hình lạ. Chúng là do đầu vào xấu, khóa bị rò rỉ, thử lại trùng lặp và các máy khách coi mọi lỗi là tạm thời. Hãy thiết lập các biện pháp kiểm soát trước khi suy luận, chứ không phải sau khi hàng đợi đầy các tệp không thể sử dụng.
Xác thực hình ảnh thực tế
Kiểm tra loại MIME thực tế và kích thước đã giải mã thay vì tin tưởng vào phần mở rộng tên tệp. Một tệp có tên product.png có thể chứa bất cứ thứ gì. Giải mã tiêu đề an toàn, giới hạn tổng số megapixel và từ chối các đầu vào bị lỗi hoặc bom giải nén trước khi chúng đến mô hình.
Đặt kích thước tối thiểu cũng như tối đa. Những hình ảnh quá nhỏ không chứa đủ thông tin cạnh để tạo lớp phủ đáng tin cậy, và ứng dụng của bạn nên thông báo trực tiếp điều đó cho người dùng. Cũng hãy quyết định cách bạn sẽ xử lý các hình ảnh đã có độ trong suốt, vì việc làm phẳng hoặc giữ nguyên nó sẽ thay đổi kết quả.
Giữ các lỗi xác thực cụ thể. Định dạng không được hỗ trợ, hình ảnh quá lớn và hình ảnh quá nhỏ cần các hành động khác nhau từ người dùng. Các thông báo lỗi chung chung sẽ dẫn đến việc tải lên lặp lại cùng một tệp xấu.
Phạm vi và bảo vệ khóa
Sử dụng một khóa cho mỗi ứng dụng, giữ nó trên máy chủ và không bao giờ đưa nó vào mã giao diện người dùng (front end code). API keys có phạm vi và có thể thu hồi, và các yêu cầu được mã hóa trong quá trình truyền tải. Xem lại tài liệu xác thực của chúng tôi để biết cách xử lý khóa phù hợp với máy khách của bạn, sau đó xoay vòng khóa theo lịch trình và ngay lập tức sau khi có thay đổi về nhân sự hoặc nhà cung cấp.
Đặt giới hạn yêu cầu cho mỗi khóa nếu nền tảng cho phép. Giới hạn này sẽ không ngăn chặn rò rỉ, nhưng nó hạn chế mức độ thiệt hại mà một khóa bị rò rỉ có thể gây ra trước khi cảnh báo và thu hồi có hiệu lực. Thêm khóa idempotency vào các lượt tải lên và gửi công việc, để việc thử lại mạng không tạo ra một bản sao có thể tính phí thứ hai.
Ánh xạ lỗi với hành vi máy khách
| Trạng thái | Ý nghĩa | Hành động |
|---|---|---|
| 429 | Đã đạt giới hạn tốc độ | Chờ thời gian được chỉ định, sau đó thử lại |
| 503 | Dịch vụ không khả dụng | Thử lại với exponential backoff |
| Lỗi xác thực 4xx | Đầu vào bị từ chối | Sửa đầu vào; không thử lại mà không thay đổi |
Sự khác biệt rất đơn giản. Hãy thử lại giới hạn tốc độ và tình trạng không khả dụng tạm thời với exponential backoff có giới hạn và jitter. Đừng thử lại lỗi xác thực với cùng một byte, vì bạn sẽ nhận được cùng một sự từ chối chậm hơn.
Ghi lại input hash, output hash, task ID và model version cho mỗi công việc. Bản ghi đó hỗ trợ kiểm toán, phát hiện trùng lặp và xử lý lại mà không giữ hình ảnh khách hàng lâu hơn chính sách lưu giữ của bạn yêu cầu. Chỉ lưu trữ bản gốc khi việc xử lý lại hoặc giải quyết tranh chấp cần đến.
Xác nhận lựa chọn của bạn trước khi triển khai
Chỉ triển khai sau khi ba tiêu chí được đáp ứng trên hình ảnh của riêng bạn. Định dạng đầu ra phải khớp với trình biên soạn của bạn, mẫu phản hồi phải phù hợp với kích thước và dung lượng hình ảnh của bạn, và nhà cung cấp phải vượt qua kiểm thử chấp nhận của bạn trên các lớp khó, không chỉ trên các mẫu sạch.
Danh sách kiểm tra bạn có thể chạy ngay hôm nay
- Thu thập một mẫu phân tầng từ các hình ảnh tải lên thực tế, bao gồm tóc, kính, chủ thể có độ tương phản thấp, nhiều người, bóng đổ và nền lộn xộn.
- Chạy kiểm thử chấp nhận với các ngưỡng đã đặt trước và chấm điểm sự chồng lấn vùng riêng biệt với chất lượng đường biên.
- Xác nhận alpha thực bằng cách giải mã đầu ra và kiểm tra các pixel trong suốt và bán trong suốt.
- Đo độ trễ p95 và hành vi thử lại dưới mức độ đồng thời và kích thước hình ảnh bạn mong đợi trong môi trường sản xuất.
- Kiểm tra xác thực và kiểm soát khóa, bao gồm các hình ảnh tải lên bị lỗi định dạng, các khóa có phạm vi có thể thu hồi và các lần thử lại bất biến.
Nếu bạn muốn kiểm tra một tuyến đường qua UberLLM, hãy bắt đầu từ base URL https://api.uberllm.dev/v1. Một API key hoạt động với các yêu cầu tương thích với OpenAI và Anthropic, và khách hàng có thể sử dụng một API key miễn phí và phải nạp thêm tín dụng để vượt quá giới hạn đó. Khả năng tương thích đó giúp giảm thay đổi phía client, nhưng nó không đảm bảo chất lượng đường biên, vì vậy hãy xác nhận mô hình đã chọn trả về alpha thực trên dữ liệu của bạn.
Tôi cũng sẽ chạy lại cùng một kiểm thử sau khi chuyển đổi mô hình, ngay cả khi chỉ có mã định danh mô hình thay đổi. Khả năng tương thích endpoint giúp việc di chuyển đủ dễ dàng đến mức các nhóm đôi khi bỏ qua chính việc đánh giá có thể phát hiện ra một kiểu matte khác.
Hãy triển khai nhà cung cấp vượt qua mọi tiêu chí trên hình ảnh của bạn, chứ không phải nhà cung cấp có bản xem trước hấp dẫn nhất.
Chạy kiểm thử chấp nhận của bạn thông qua UberLLM để so sánh các tuyến loại bỏ nền dưới một API key và một số dư, sử dụng cùng hình ảnh và kiểm tra alpha mà bạn sẽ sử dụng trong môi trường sản xuất. Bắt đầu với một khóa miễn phí, xác minh matte ở độ phân giải đầy đủ và chỉ giữ lại mô hình vượt qua các tiêu chí về đường biên, độ trễ và thử lại của bạn.