ImageToTextTask so với VisionEngine: Chọn một người giải CAPTCHA hình ảnh

TL;DR

• Chọn nhiệm vụ CAPTCHA dựa trên đầu vào và đầu ra được tài liệu hóa, thay vì dựa vào việc thử thách chứa hình ảnh.
• ImageToTextTask là điểm bắt đầu cho nhận dạng văn bản được hỗ trợ; VisionEngine cung cấp các module có tên với các kết quả khác nhau.
• VisionEngine không chỉ giới hạn ở hình học: ví dụ được tài liệu hóa ocr_gif của nó trả về văn bản.
• Cả hai gia đình nhiệm vụ đều trả về kết quả nhận dạng trực tiếp từ createTask; không thêm giai đoạn kiểm tra định kỳ theo mặc định.
• Xác minh kết quả nhận dạng riêng biệt khỏi cách ứng dụng sử dụng câu trả lời, đặc biệt khi liên quan đến tọa độ, kích thước hình ảnh hoặc thử thách được làm mới.

Sự khác biệt giữa ImageToTextTask và VisionEngine là gì?

ImageToTextTask và VisionEngine là các gia đình nhiệm vụ nhận dạng hình ảnh với các trường yêu cầu và phản hồi cụ thể theo module. Việc chọn đúng gia đình phụ thuộc vào định dạng thử thách mà ứng dụng được ủy quyền hỗ trợ và câu trả lời mà ứng dụng cần tiếp theo.

Trong CapSolver, việc chọn đúng gia đình không chỉ đơn giản là thay đổi tên nhiệm vụ. Một bộ phân tích kỳ vọng các ký tự được nhận dạng không thể an toàn sử dụng khoảng cách hoặc góc. Ngược lại, một câu trả lời hình học là không cần thiết khi bước tiếp theo của ứng dụng chỉ so sánh chuỗi được nhận dạng với một bộ thử nghiệm đã biết.

Phân tích quang học ký tự, hay OCR, trích xuất văn bản từ hình ảnh. Điều này giúp giải thích một loại CAPTCHA nhận dạng, nhưng "CAPTCHA hình ảnh" rộng hơn OCR. Một thử thách có thể yêu cầu văn bản, vị trí hoặc mối quan hệ thị giác được hỗ trợ khác.

Hướng dẫn này so sánh các hợp đồng được tài liệu hóa và lựa chọn đánh giá. Các tình huống của nó liên quan đến các bộ thử nghiệm CAPTCHA do chính bạn sở hữu và QA được phép. Nó không trình bày một đoạn mã chung để tương tác với các trang web bất kỳ hay tuyên bố rằng kết quả nhận dạng hoàn tất thử thách trình duyệt chỉ bằng bản thân nó.

So sánh hợp đồng nhiệm vụ trước khi chọn

Hợp đồng nhiệm vụ xác định dữ liệu hình ảnh bạn gửi và cách bạn diễn giải kết quả.

So sánh	ImageToTextTask	VisionEngine
Trường hình ảnh yêu cầu chính	body	image
Chọn nhiệm vụ	ImageToTextTask, với các tùy chọn module được tài liệu hóa	VisionEngine cộng với một module tên được hỗ trợ
Kết quả dự kiến	Văn bản hoặc câu trả lời tùy theo module	Kết quả văn bản hoặc hình học tùy theo module
Giao hàng kết quả	Trả về trực tiếp từ createTask	Trả về trực tiếp từ createTask
Câu hỏi tích hợp chính	Mô hình nhận dạng được chọn có khớp với câu trả lời kỳ vọng không?	Module chính xác có khớp với định dạng hình ảnh và hợp đồng đầu ra không?
Giả định không an toàn	Mọi phản hồi đều là một chuỗi văn bản	Mọi hình ảnh đều có thể sử dụng cùng một module hoặc bộ phân tích

Tham khảo ImageToTextTask tài liệu hóa nội dung hình ảnh Base64 trong body, không có ký tự xuống dòng hoặc tiền tố data-URI. Các ví dụ của nó phân biệt text với answers tùy theo module. Đọc phản hồi của module được chọn thay vì làm phẳng mọi kết quả thành một chuỗi duy nhất.

Tham khảo VisionEngine tài liệu hóa các module có tên: ví dụ bao gồm slider_1 trả về distance, các module xoay trả về angle, và botdeflector trả về points. Ví dụ ocr_gif trả về text. Bảng thuộc tính chung liệt kê imageBackground là bắt buộc, trong khi một số ví dụ module bỏ qua nó. Giải quyết sự khác biệt này dựa trên ví dụ module cụ thể và xác minh bất kỳ sự mơ hồ nào trước khi triển khai.

Các ví dụ này xác lập các hợp đồng được hỗ trợ, không phải hiểu biết hình ảnh phổ quát. Một tên nhiệm vụ không phải là phép cho bạn tạo module, thêm lời nhắc tự do hoặc kỳ vọng loại phản hồi mà module được chọn không tài liệu hóa.

Khi nào bạn nên bắt đầu với ImageToTextTask?

Bắt đầu với ImageToTextTask khi câu trả lời hữu ích của thử thách được hỗ trợ là văn bản được nhận dạng và module được tài liệu hóa phù hợp với đầu vào của bạn.

Giả sử nhóm của bạn duy trì một biểu mẫu liên hệ cũ và có một tập thử nghiệm được phép gồm các hình ảnh ký tự. Câu hỏi đánh giá cụ thể là: con đường nhận dạng có trả về các ký tự kỳ vọng bởi bộ thử nghiệm không? Bạn có thể so sánh chuỗi trả về với nhãn thử nghiệm mà không cần liên quan đến tọa độ trình duyệt hoặc chuyển động con trỏ.

Định nghĩa các quy tắc văn bản của ứng dụng trước khi đánh giá bộ giải. Ứng dụng của bạn có phân biệt chữ hoa và chữ thường không? Có giữ nguyên số 0 đầu không? Có chấp nhận khoảng trắng không? Đây là các thuộc tính của ứng dụng bạn kiểm soát. Chúng không nên bị thay đổi một cách im lặng bởi hàm làm sạch kết quả chung.

Ví dụ, một bộ thử nghiệm có nhãn "007A" nên giữ nguyên chuỗi trong suốt quá trình so sánh. Xử lý kết quả của nó như một số sẽ khiến bộ phân tích ứng dụng chịu trách nhiệm cho lỗi có thể tránh được. Đây là ví dụ minh họa về xác minh, không phải đầu ra bộ giải được báo cáo.

Giữ kết quả trống và hình dạng phản hồi sai biệt lập. Một trường kỳ vọng bị thiếu là vấn đề tích hợp để kiểm tra. Một câu trả lời có hình dạng đúng nhưng sai thuộc về đánh giá nhận dạng. Kết hợp cả hai vào một số "độ chính xác" ẩn đi việc nhiệm vụ chọn hay nhận dạng hình ảnh cần được chú ý.

Khi nào VisionEngine xứng đáng được đánh giá?

Đánh giá VisionEngine khi một module được tài liệu hóa khớp với định dạng thử thách và cấu trúc trả về là thông tin mà ứng dụng của bạn cần.

Đối với một thử nghiệm hình ảnh được kiểm soát, một góc và danh sách điểm đại diện cho các khẳng định khác nhau. Một góc có thể so sánh với hướng kỳ vọng của bộ thử nghiệm. Một danh sách điểm cần quy tắc diễn giải riêng. Không nên để chúng đi qua bộ phân tích được viết cho nhận dạng ký tự.

Chuẩn bị bộ chuyển đổi chuyên dụng cho module với trách nhiệm rõ ràng: nhận dạng hình dạng phản hồi được tài liệu hóa, xác minh và chuyển câu trả lời đã diễn giải đến ứng dụng sở hữu. Không để bộ chuyển đổi quyết định điều khiển trình duyệt không liên quan. Giữ phân tích nhận dạng tách biệt giúp lỗi dễ tái tạo với các bộ thử nghiệm lưu trữ.

Sự hiện diện của module OCR cũng ngăn chặn quy tắc đơn giản như "văn bản luôn có nghĩa là ImageToTextTask." Đối với đầu vào văn bản động, kiểm tra định dạng và module được tài liệu hóa trước khi chọn. Chỉ định dạng câu trả lời không xác lập rằng hai nhiệm vụ chấp nhận cùng đầu vào hoặc thực hiện tốt như nhau trên chúng.

Nếu không có module được tài liệu hóa khớp với thử thách, ghi lại nó là không hỗ trợ hoặc chưa giải quyết. Thay đổi nhãn yêu cầu cho đến khi API chấp nhận tải trọng không phải là phương pháp đánh giá đáng tin cậy. Việc chấp nhận yêu cầu không xác lập rằng mô hình nhận dạng của nó phù hợp với hình ảnh.

Nhận mã thưởng CapSolver của bạn

Tăng ngân sách tự động hóa của bạn ngay lập tức!
Sử dụng mã thưởng CAP26 khi nạp tiền vào tài khoản CapSolver để nhận thêm 5% thưởng trên mỗi lần nạp — không giới hạn.
Nhận mã thưởng ngay bây giờ trong Bảng điều khiển CapSolver

Cách chuẩn bị hình ảnh ảnh hưởng đến so sánh như thế nào?

Chuẩn bị hình ảnh nên bảo tồn bằng chứng mà mỗi nhiệm vụ cần, để đánh giá đo lường sự phù hợp của nhiệm vụ thay vì sai lệch tiền xử lý ngẫu nhiên.

Base64 là đại diện cho byte. Thông số kỹ thuật Base64 RFC 4648 định nghĩa mã hóa; nó không xác lập rằng tệp được mã hóa là hình ảnh đúng cho module nhận dạng. Một tải trọng có thể được mã hóa về mặt cú pháp và vẫn chứa thử thách lỗi thời, cắt sai hoặc định dạng hình ảnh không được hỗ trợ.

Đối với mỗi bộ thử nghiệm do bạn sở hữu, giữ lại tham chiếu đến hình ảnh gốc và ghi chú bất kỳ biến đổi nào trước khi gửi. Ví dụ bao gồm thay đổi kích thước, làm phẳng hoạt hình hoặc thay đổi cắt. Tránh áp dụng cùng biến đổi cho mọi gia đình nhiệm vụ: xóa khung hoạt hình có thể thay đổi thông tin có sẵn cho nhiệm vụ dự định cho đầu vào động.

Nếu một module được đánh giá cần hình ảnh nền và nền, hãy đảm bảo chúng thuộc cùng một phiên bản bộ thử nghiệm. Kết hợp nền từ một lần làm mới với nền từ lần khác tạo ra sự không khớp đầu vào. Sự thất bại này không nên được đếm là bằng chứng cho thấy module hợp lệ không chính xác.

Sử dụng hình ảnh thử nghiệm tổng hợp hoặc được phê duyệt mà không có thông tin cá nhân không liên quan. Một ảnh chụp màn hình toàn bộ trang hỗ trợ có thể chứa nhiều hơn thử thách. Giới hạn hình ảnh được gửi đến đầu vào được phép làm cho bài kiểm tra rõ ràng hơn và giảm phơi bày dữ liệu không cần thiết.

Tại sao kết quả tọa độ khó tích hợp hơn văn bản?

Kết quả tọa độ yêu cầu sự đồng thuận về khung tham chiếu hình ảnh và bố cục trước khi ứng dụng có thể sử dụng chúng đúng cách.

Một điểm đo dựa trên hình ảnh gốc không tự động là một điểm trong khung xem trình duyệt. Định nghĩa khung bao của trình duyệt mô tả một hình chữ nhật tương đối với khung xem và bao gồm biên và lề của phần tử. Điều này khác với việc giả định phần tử được hiển thị chính xác khớp với kích thước hình ảnh gốc.

Trong bộ kiểm tra QA do bạn sở hữu, kiểm tra diễn giải tọa độ như một thành phần riêng biệt. Ghi lại kích thước của bộ thử nghiệm, kích thước thực tế được trình bày cho bộ giải và biểu diễn ứng dụng được sử dụng để đánh giá câu trả lời. Nếu các biểu diễn này khác nhau, ứng dụng cần có bản đồ rõ ràng, được kiểm tra phù hợp với giao diện của chính nó.

Không sử dụng phản hồi nhận dạng thành công như bằng chứng cho thấy bản đồ đó đúng. Một bài kiểm tra hữu ích có thể so sánh kết quả đã diễn giải với bộ thử nghiệm được ghi nhãn trước khi bất kỳ hành động trình duyệt nào xảy ra. Một bài kiểm tra thứ hai có thể xác minh xem thành phần sở hữu có sử dụng kết quả đã diễn giải như mong muốn không.

Sự tách biệt này cũng giúp với các thử thách được làm mới. Nếu giao diện thay thế hình ảnh trong khi nhận dạng đang chạy, câu trả lời vẫn thuộc về bộ thử nghiệm ban đầu. Ứng dụng của bạn nên xóa liên kết lỗi thời thay vì áp dụng kết quả đó cho hình ảnh thay thế.

Làm thế nào để so sánh độ chính xác và chi phí hoạt động một cách công bằng?

So sánh công bằng nhóm kết quả theo gia đình thử thách được hỗ trợ và đếm các kết quả ứng dụng hoàn thành riêng biệt từ các phản hồi API hợp lệ.

Bắt đầu với một tập hợp bộ thử nghiệm đại diện, được phép. Bao gồm các biến thể hình ảnh mà ứng dụng của bạn thực sự tạo ra, như kích thước bình thường và phạm vi ký tự kỳ vọng. Giữ lại một tập hợp kiểm tra để đánh giá để các điều chỉnh về tiền xử lý không được đánh giá chỉ dựa trên cùng các ví dụ đã thúc đẩy chúng.

Ghi lại các danh mục này riêng biệt:

Danh mục đánh giá	Điều nó nói với bạn
Đầu vào bị từ chối	Yêu cầu hoặc định dạng cần chú ý
Hình dạng phản hồi kỳ vọng được trả về	Hợp đồng bộ phân tích được đáp ứng
Câu trả lời khớp với bộ thử nghiệm	Nhận dạng đáp ứng tiêu chí của bộ thử nghiệm
Ứng dụng sở hữu chấp nhận câu trả lời	Tích hợp bảo tồn ý nghĩa của kết quả
Kết quả đến sau khi thay thế bộ thử nghiệm	Thời gian hoặc chu kỳ cuộc sống khiến kết quả không sử dụng được

Không so sánh các nhiệm vụ không liên quan bằng một chỉ số độ chính xác tổng thể. Một bộ thử nghiệm văn bản và một bộ thử nghiệm hình học kiểm tra đầu ra khác nhau. Khi hai tùy chọn được tài liệu hóa thực sự khớp với cùng gia đình đầu vào, giữ nguyên bộ thử nghiệm và định nghĩa thành công.

Đối với chi phí, đo tổng chi phí đánh giá so với kết quả thành công, phù hợp và tính đến công việc kỹ thuật. Một bộ phân tích yêu cầu điều tra thủ công thường xuyên có thể tốn thời gian ngay cả khi chi phí nhiệm vụ nhỏ. Không có người chiến thắng duy nhất về giá cả hoặc hiệu suất được xác lập chỉ bởi tên API.

Đây là các khuyến nghị đánh giá, không phải kết quả tiêu chuẩn. Chạy chúng trên ứng dụng được phép trước khi đưa ra tuyên bố về độ chính xác, tốc độ hoặc tiết kiệm.

Checklist chọn nhiệm vụ cuối cùng nên chứa gì?

Checklist chọn nhiệm vụ nên xác định đầu vào được hỗ trợ, câu trả lời kỳ vọng, hành vi giao hàng và kiểm tra chấp nhận ứng dụng.

Đối với mỗi gia đình CAPTCHA được hỗ trợ, tài liệu hóa nhiệm vụ và module được chọn, quy tắc chuẩn bị hình ảnh, trường giải pháp kỳ vọng và điều gì xảy ra nếu phản hồi có hình dạng khác. Giao nhiệm vụ cho người chịu trách nhiệm xem xét các giả định đó khi ứng dụng của bạn thay đổi triển khai CAPTCHA.

Giữ riêng đánh giá khả năng tiếp cận khỏi đánh giá nhận dạng. Thảo luận của W3C về việc không thể truy cập của CAPTCHA giải thích các rào cản được tạo bởi cơ chế thử thách. Việc thêm bộ giải vào luồng QA tự động không chứng minh rằng biểu mẫu công khai cung cấp trải nghiệm khả năng tiếp cận. Chủ sở hữu trang vẫn cần đánh giá các lựa chọn người dùng phù hợp.

Đối với giải thích rộng hơn về lớp nhận dạng, xem cách một API nhận dạng hình ảnh phù hợp với tự động hóa CAPTCHA tùy chỉnh. Quay lại so sánh này khi chọn hợp đồng nhiệm vụ chính xác.

Bắt đầu với một nhiệm vụ CapSolver được hỗ trợ, một tập thử nghiệm nhỏ có nhãn và một bộ phân tích giữ nguyên kết quả được tài liệu hóa. Mở rộng phạm vi chỉ sau khi mỗi gia đình đầu vào mới có tiêu chí chấp nhận rõ ràng.

Câu hỏi thường gặp

Câu hỏi: VisionEngine có phải là sự thay thế cho ImageToTextTask không?

VisionEngine không phải là sự thay thế toàn diện. Chọn nhiệm vụ mà module được tài liệu hóa hỗ trợ đầu vào và cung cấp kết quả mà ứng dụng của bạn kỳ vọng. Các hình dạng phản hồi khác nhau và yêu cầu hình ảnh có thể yêu cầu các bộ chuyển đổi khác nhau.

Câu hỏi: VisionEngine luôn trả về tọa độ không?

VisionEngine không luôn trả về tọa độ. Các ví dụ module của nó bao gồm kết quả hình học và một ví dụ OCR trả về văn bản. Đọc hợp đồng phản hồi của module được chọn thay vì suy ra từ tên gia đình nhiệm vụ.

Câu hỏi: Hai gia đình nhiệm vụ này có cần kiểm tra getTaskResult không?

Cả hai tham chiếu gia đình nhiệm vụ đều mô tả kết quả được trả về trực tiếp qua createTask. Một bộ bao bọc API chung nên giữ nguyên giải pháp trực tiếp thay vì bắt đầu vòng lặp kiểm tra tự động.

Câu hỏi: Một câu trả lời được nhận dạng có chứng minh rằng biểu mẫu CAPTCHA hoạt động không?

Một câu trả lời được nhận dạng không chứng minh việc định tuyến kết quả đúng hay hoàn thành biểu mẫu. Xác minh câu trả lời với bộ thử nghiệm, sau đó kiểm tra xem ứng dụng sở hữu có sử dụng nó cho thử thách phù hợp và đạt được kết quả kỳ vọng không.