Jev giờ đã đọc ảnh: từ kiểm tra hàng trả đến xác định vị trí hư hỏng

Sơ đồ giải thích nguyên bản: ảnh được đưa vào, các phán đoán và tọa độ riêng biệt được trả ra, rồi một người kiểm tra vùng hư hỏng được đề xuất. Sơ đồ minh họa quy trình, không phải kết quả mô hình được ghi nhận.

Khách hàng chụp một chiếc cốc bị mẻ. Công cụ hỗ trợ của bạn cần trả lời ba câu hỏi khác nhau: có nhìn thấy chiếc cốc không, ảnh có cho thấy hư hỏng không và người rà soát nên xem ở đâu? Một đoạn văn trôi chảy về đồ gốm không phải kết quả trung gian hữu ích nhất.

Ngày 14 tháng 10 năm 2026, TypeSafe AI thông báo hỗ trợ hình ảnh thử nghiệm cho Jev cùng Jev 1.14.0 và kiểu đầu ra box mới. Ảnh dùng được với cả Jev 1.13 lẫn 1.14; Box cần phiên bản 1.14. TypeSafe gọi các tính năng này là thử nghiệm và nêu rõ chưa khuyến nghị dùng chúng cho tự động hóa sản xuất. Thông báo chính thức

Thay đổi hữu ích hẹp hơn một trợ lý đa phương thức đa năng: ảnh có thể trở thành quyết định có kiểu hoặc một vị trí trong chương trình. Sau đây là tác động với quy trình trả hàng, giao diện chấp nhận đầu vào nào và cách xây dựng nguyên mẫu thận trọng mà không nhầm hình chữ nhật với bằng chứng.

Tóm tắt:

• Jev hiện có đường thử nghiệm để hiểu ảnh tĩnh, không phải tạo ảnh.
• Hãy hỏi mục tiêu có hiện diện không trước khi tin vị trí được đề xuất.
• Giữ ảnh gốc và bước con người rà soát; để mã kiểm tra tọa độ, quyền và hệ quả.

Ảnh chụp có thể trở thành quyết định thay vì lời mô tả

Điểm hấp dẫn ban đầu của Jev là câu trả lời có giới hạn: chọn một phương án được cung cấp, đánh giá theo các mức mô tả hoặc kiểm tra mệnh đề có/không. Hướng dẫn trước đây của chúng tôi về mô hình quyết định Jev trình bày nền tảng đó. Phát triển mới là đưa bằng chứng hình ảnh vào những câu hỏi ấy, cùng cách trả về tọa độ không gian.

Với giao diện trả hàng, điều này thay đổi cách phân công. Mô hình có thể đề xuất rằng nhìn thấy hư hỏng; mã ứng dụng có thể hiển thị đề xuất bên cạnh ảnh được gửi. Không thao tác nào xác nhận hư hỏng xảy ra khi nào, ảnh có thuộc đơn hàng này không hay có được phép hoàn tiền không. Đó là những câu hỏi riêng, đòi hỏi bằng chứng khác nhau.

Các ranh giới này dựa trên tham chiếu mô hình, hợp đồng yêu cầu API và SDK hỗ trợ ảnh. Một thư mục PDF không tự biến thành pipeline xử lý tài liệu chỉ vì vài trang có hình. Tương tự, một số khung hình trích xuất không chứng minh có khả năng hiểu video gốc hoặc truy cập phần âm thanh của clip.

Nhận định của chúng tôi: đơn vị đáng chú ý là một phán đoán nhỏ, có thể kiểm tra và gắn với bằng chứng. Nó không phải quyền mới để tự động hóa mọi thứ phía sau.

Ba ví dụ chính thức biến cùng một ảnh thành các công việc khác nhau

Tài liệu JavaScript của TypeSafe cung cấp ba điểm khởi đầu cụ thể. Đây là ví dụ mã đã công bố, không phải báo cáo triển khai khách hàng thực tế hay kết quả đo. Hãy xem chúng là mẫu cho nguyên mẫu, không phải cam kết về độ chính xác trên ảnh của bạn.

Ví dụ đầu kết hợp yêu cầu về chiếc cốc hư hỏng với ảnh sản phẩm, hỏi Noul về hư hỏng và Score về mức độ. Trong hàng đợi hỗ trợ, một phiên bản điều chỉnh có thể đưa trường hợp nghi hư hỏng lên đầu để kiểm tra. Người rà soát vẫn cần thấy toàn ảnh, mô tả của khách hàng và lựa chọn bác bỏ đề xuất.

Ví dụ thứ hai so sánh ảnh người bán tải lên với ảnh trong danh mục. Nó hỏi chúng có cùng sản phẩm không và phân loại mức hữu dụng của ảnh, gồm mờ, bị cắt và có nội dung không liên quan đến sản phẩm. Với sàn thương mại, điều đó gợi ý nên tách riêng: khớp nhận dạng và chất lượng ảnh không nhất thiết phải dùng chung một quyết định phê duyệt. Ảnh rõ nét của nhầm sản phẩm không nên được chấp nhận chỉ vì trông chuyên nghiệp.

Ví dụ thứ ba yêu cầu Box định vị vùng hư hỏng. Kết quả có thể hướng dẫn lớp phủ hoặc phần cắt ảnh gợi ý cho người rà soát. Hãy giữ ảnh gốc chưa cắt bên cạnh: thu hẹp sự chú ý có thể giúp kiểm tra yêu cầu, nhưng cũng có thể che mất ngữ cảnh làm thay đổi ý nghĩa.

Theo các ví dụ chính thức về đánh giá hư hỏng, so sánh danh mục và định vị hư hỏng. Quy trình trả hàng đề xuất của chúng tôi bổ sung biện pháp bảo vệ ứng dụng quanh những mẫu đó; đây không phải tường thuật về một lần thử nghiệm.

Hộp tọa độ không thể cho biết chẳng có gì để tìm

Chi tiết quan trọng trong hợp đồng Box của TypeSafe là không có đầu ra cho trường hợp mục tiêu vắng mặt. Câu hỏi Box trả về bốn cạnh ngay cả khi mục tiêu được yêu cầu không tồn tại. Vì thế, hình chữ nhật bao quanh chiếc cốc còn nguyên không thể tự chứng minh có hư hỏng.

Hãy hỏi Noul riêng xem mục tiêu có hiện diện không. Với quy trình này, phân biệt việc nhìn thấy chiếc cốc với việc nhìn thấy hư hỏng. Câu trả lời chiếc cốc hiện diện không đủ để cho phép phủ lớp vùng hư hỏng. Bỏ qua khung hư hỏng được đề xuất trừ khi các bước kiểm tra hiện diện liên quan vượt qua quy tắc đã được xác thực.

Đây là cổng kiểm tra sự hiện diện, không phải cách chữa mọi lỗi. Cả hai phán đoán có thể cùng sai. Ánh phản chiếu mạnh có thể trông như vết mẻ, còn vết nứt thật có thể chìm vào lớp men hoa văn. Trước khi chọn ngưỡng, hãy thử ảnh không có cốc, cốc nguyên vẹn, ánh phản chiếu mơ hồ, nhiều vật thể và hư hỏng nhìn thấy rõ.

Sơ đồ quyết định nguyên bản: chỉ có thể dùng hình chữ nhật hợp lệ sau khi vượt cổng kiểm tra mục tiêu hiện diện. Kiểm tra thất bại hoặc chưa chắc chắn giữ ảnh gốc cho con người rà soát; chúng không tự biến thành lý do từ chối.

Hãy xem hình chữ nhật là con trỏ, không phải phán quyết.

Xem tọa độ như hình học, rồi kiểm tra ý nghĩa

Box trả về left, right, top và bottom dưới dạng phân số theo kích thước ảnh, đo từ góc trên bên trái. Giá trị nằm trong khoảng 0 đến 1, với left < right và top < bottom. Một câu hỏi tạo một khung, không phải danh sách phát hiện vật thể. Hợp đồng phản hồi Box

Với ảnh chuẩn bị sẵn 1200 x 900 mang tính minh họa, cạnh trái 0.20, trên 0.30, phải 0.60 và dưới 0.70 tương ứng các cạnh pixel 240, 270, 720, 630. Đây là ví dụ số học, không phải phản hồi Jev. API cắt ảnh thường nhận trái, trên, phải, dưới; hãy ánh xạ trường có tên một cách rõ ràng thay vì dựa vào thứ tự thuộc tính JSON.

Kiểm tra số hữu hạn, giới hạn và thứ tự trước khi vẽ bất cứ thứ gì. Sau đó xem vùng đó có thực sự chỉ ra chỗ hư hỏng không. Nếu đổi kích thước, xoay, thêm viền hoặc chia ô ảnh, hãy giữ phép biến đổi cần thiết để ánh xạ tọa độ trở lại; nếu không, một khung trông hợp lý vẫn có thể chỉ nhầm pixel.

Chuẩn bị ảnh trước khi gửi yêu cầu, đừng đợi đến khi gặp lỗi

Giới hạn ảnh chính thức chính xác và bao gồm cả hai đầu mút. Ảnh ngoài giới hạn sẽ bị từ chối thay vì tự động đổi kích thước; chỉ một ảnh bị từ chối cũng làm hỏng toàn bộ yêu cầu.

Tham chiếu lặp lại cũng được tính lại trong yêu cầu sau mở rộng. Kích thước tệp, kích thước ảnh và độ dài ngữ cảnh là các kiểm tra riêng. Giới hạn ảnh

Sơ đồ ràng buộc nguyên bản dựa trên tài liệu ảnh TypeSafe, kiểm tra ngày 18 tháng 10 năm 2026. Giới hạn từng tệp, ảnh đã xử lý, yêu cầu sau mở rộng và thân yêu cầu áp dụng độc lập.

TypeSafe cũng yêu cầu xoay pixel cho thẳng trước khi gửi: API gỡ metadata và không áp dụng hướng EXIF. Trước tiên hãy chuyển định dạng không được hỗ trợ. Hướng dẫn chuẩn bị

Với nguyên mẫu, hãy chuẩn bị một bản sao được đặt tên rõ ràng từ ảnh bạn sở hữu và giữ nguyên bản gốc. Kiểm tra kích thước cục bộ và xem trước đúng bản sao sẽ gửi. Ảnh cắt hẹp có thể cần thêm viền để đạt kích thước tối thiểu; ghi lại phần viền trước khi diễn giải tọa độ.

Ghim phiên bản 1.14 và bật rõ công tắc thử nghiệm

Tính đến ngày 18 tháng 10, bảng bí danh đã công bố ánh xạ jev-latest sang jev-1.13.0 và jev-preview sang jev-1.14.0. Với ví dụ Box, hãy ghim jev-1.14.0 thay vì giả định latest có nghĩa là bản xem trước mới nhất. Bí danh mô hình

Quy trình sau tạo một ví dụ cục bộ chỉ để rà soát. Chạy lệnh cuối sẽ gửi yêu cầu suy luận bị tính phí, SDK có thể thử lại; lệnh không bao giờ phê duyệt hàng trả hay thay đổi tài khoản. Dùng ảnh chiếc cốc đã chuẩn bị mà bạn sở hữu, không có người, nhãn vận chuyển, địa chỉ hay tài liệu riêng tư.

1. Đăng ký truy cập và chọn đúng tổ chức. TypeSafe cho biết hiện không cần được duyệt danh sách chờ mới đăng ký. Tạo khóa API trong console và kiểm tra credit của tổ chức trước khi thử. Quyền truy cập tài khoản, cài đặt credit

2. Dùng Node.js 22 trở lên. Bản SDK JavaScript hỗ trợ ảnh là 0.7.0, đề ngày 14 tháng 10. Ghim phiên bản này để khai báo rõ phụ thuộc client trong ví dụ. Nhật ký thay đổi SDK

node --version
mkdir jev-photo-check
cd jev-photo-check
npm init -y
npm install @typesafe-ai/[email protected]

3. Đặt khóa chỉ cho phiên hiện tại. Trên Windows PowerShell, dùng khối đầu; trên Bash/Zsh của macOS hoặc Linux, dùng khối thứ hai. Thay chỗ giữ chỗ tại máy của bạn, đừng commit khóa thật.

$env:TYPESAFE_API_KEY = "your-api-key"

export TYPESAFE_API_KEY="your-api-key"

4. Chuẩn bị owned-mug.jpg và tạo inspect-return.mjs. Bản điều chỉnh nguyên bản này dùng các helper SDK được tài liệu hóa. Header thử nghiệm được cấu hình trước mọi yêu cầu ảnh. Hai ngưỡng xác suất dưới đây là quy tắc ứng dụng minh họa, không phải khuyến nghị của TypeSafe. Mọi kết quả vẫn phải qua con người rà soát. Cách dùng SDK

import { readFile } from "node:fs/promises";
import { box, image, noul, TypeSafeClient } from "@typesafe-ai/sdk";

if (!process.env.TYPESAFE_API_KEY) {
  throw new Error("Set TYPESAFE_API_KEY before choosing to run this example.");
}

const client = new TypeSafeClient({
  defaultHeaders: { "TypeSafe-Danger-Zone-Images": "true" },
});
const photo = image(await readFile("owned-mug.jpg"));
const response = await client.systemOne({
  model: "jev-1.14.0",
  state: { photo },
  questions: {
    mugVisible: noul("Is a mug clearly visible in `photo`?"),
    damageVisible: noul("Is physical damage clearly visible on the mug in `photo`?"),
    damageRegion: box("The physically damaged area of the mug in `photo`"),
  },
});

const { mugVisible, damageVisible, damageRegion } = response.answers;
const edges = damageRegion.box;
const coordinates = [edges.left, edges.top, edges.right, edges.bottom];
const validBox = coordinates.every(
  (value) => Number.isFinite(value) && value >= 0 && value <= 1,
) && edges.left < edges.right && edges.top < edges.bottom;

const presencePasses = [mugVisible.noul, damageVisible.noul].every(
  (value) => Number.isFinite(value) && value >= 0.95 && value <= 1,
);

console.log({
  model: response.model,
  usage: response.usage,
  humanReviewRequired: true,
  suggestedBox: presencePasses && validBox ? edges : null,
});

5. Chỉ chạy khi đã sẵn sàng gửi ảnh và phát sinh mức sử dụng. Trên cả ba hệ điều hành, lệnh là node inspect-return.mjs. Lỗi ngoại lệ hoặc suggestedBox: null cần giữ ảnh gốc để rà soát, không khởi động các lần gửi lại tự động.

Các câu hỏi dùng chung một yêu cầu, nhưng bỏ qua Box trừ khi cổng của ứng dụng được thông qua. Điều đó không tiết kiệm chi phí tính toán Box không dùng đến. Một thiết kế sau này có thể chuyển định vị thành yêu cầu thứ hai, sau bước kiểm tra hiện diện, đổi thêm một lượt kết nối lấy việc tránh các lần định vị không cần thiết.

Giá token thấp không phải giá cho mỗi bức ảnh

Mức giá đã công bố cho cả hai phiên bản là 0,042 USD trên mỗi triệu token đầu vào, token đầu ra miễn phí. Nghĩa là 10 triệu token đầu vào bị tính phí sẽ tốn 0,42 USD theo giá niêm yết; không có nghĩa mười triệu ảnh tốn chừng ấy. Bảng giá đã công bố

Ảnh được tính là token đầu vào theo giá văn bản, không có khoản phí ảnh riêng. TypeSafe chưa cung cấp công thức ước tính token ảnh trong tài liệu. Khi lập ngân sách cho một đợt đánh giá được cho phép, hãy dùng usage.input_tokens trong phản hồi thay vì tự nghĩ ra giá cho mỗi bức ảnh. Tính phí hình ảnh

Ngân sách cần tính cả lần thử thất bại, thử lại, tiền xử lý, lưu trữ và thời gian rà soát. Gắn chi phí với số đo chất lượng: tiết kiệm một phần cent chẳng ích gì nếu phần cắt quá chặt khiến người rà soát nào cũng phải mở lại ảnh gốc. Hãy so sánh toàn bộ tác vụ rà soát với một quy trình thủ công đơn giản làm mốc.

Thiết kế cho sự không chắc chắn, quyền riêng tư và dịch vụ bận

Noul trả về xác suất mà không có trường confidence riêng. Choice và Score gồm các phân phối cùng giá trị tin cậy được suy ra. Các giá trị ấy mô tả độ không chắc chắn của mô hình; chúng không phải chứng nhận tính đúng đắn chung. Tài liệu độ tin cậy

Với quy trình chiếc cốc, hãy xác thực cổng bằng ảnh giữ lại ngoài tập huấn luyện và nhãn đã thống nhất. Gom các đầu ra tương tự và so sánh với độ chính xác quan sát được để kiểm tra hiệu chỉnh trên tác vụ của bạn. Đo riêng trường hợp bỏ sót hư hỏng và báo động nhầm; phân biệt lớp phủ đặt sai với quyết định hoàn tiền sai. Đánh giá lại ngưỡng khi đổi mô hình, ánh sáng, danh mục sản phẩm hoặc quy trình chụp.

Đừng xem mọi ảnh không vượt qua kiểm tra là bằng chứng chống lại khách hàng. Ảnh có thể không đủ tốt vì máy ảnh kém, vật thể phản chiếu hoặc cần một góc khác mới thấy khuyết tật. Trạng thái rà soát hữu ích cho phép gửi ảnh khác và kiểm tra thủ công, không quy lỗi cho khách hàng vì mô hình chưa chắc chắn.

TypeSafe cho biết yêu cầu và phản hồi của khách hàng không được dùng để huấn luyện Jev. Trung tâm trợ giúp cũng giải thích việc xử lý có thể gồm cung cấp dịch vụ, thanh toán, ngăn lạm dụng và telemetry; thời hạn lưu giữ tùy thuộc dữ liệu, thỏa thuận và mọi cấu hình lưu giữ dữ liệu bằng không. Không dùng để huấn luyện không đồng nghĩa không lưu giữ. Chính sách xử lý dữ liệu

Trang trạng thái dịch vụ công khai liệt kê địa lý Hoa Kỳ và các vùng us-east-1, us-east-2, us-west-2. Nhóm có yêu cầu lưu trú dữ liệu theo khu vực cần giải quyết câu hỏi vị trí xử lý trước khi tải ảnh khách hàng; truy cập được console không phải thỏa thuận về lưu trú dữ liệu.

Áp dụng nguyên tắc giảm thiểu dữ liệu trước khi tải lên. Nếu không liên quan, hãy cắt nhãn địa chỉ khỏi bản sao đã chuẩn bị; giới hạn quyền truy cập ảnh gốc và tránh đưa ảnh hoặc bí mật vào log thường nhật. Tự xác định thời hạn lưu hồ sơ rà soát, tách biệt với chính sách của nhà cung cấp.

Giới hạn của tổ chức bao gồm yêu cầu và token mỗi giây. API ghi nhận 429 cho giới hạn tốc độ và 529 cho tình trạng quá tải; đầu vào sai định dạng hoặc quá lớn cần được sửa, không phải gửi lại y nguyên. Giới hạn tốc độ, lỗi API

Chính sách thử lại mặc định của SDK JavaScript là hai lần và tuân theo header thời gian chờ thử lại được hỗ trợ. Tránh bổ sung vòng lặp thử lại bên ngoài không giới hạn. Đặt ngân sách thời gian, giữ trạng thái lỗi có thể xử lý và tách mọi hành động nghiệp vụ sau này để suy luận được thử lại không phát hành khoản hoàn tiền trùng lặp. Chính sách thử lại

Câu hỏi cần trả lời trước quy trình ảnh đầu tiên

Jev có chỉnh sửa hoặc tạo ảnh trả hàng không?

Không. Ảnh là bằng chứng cho phán đoán hoặc vùng được đề xuất. Ứng dụng của bạn vẽ lớp phủ hoặc cắt ảnh bằng mã xử lý ảnh thông thường. Giữ riêng nguồn chưa chỉnh sửa; khung hữu ích không thay thế bằng chứng gốc.

Vì sao ví dụ ghim 1.14 thay vì dùng latest?

Bảng bí danh đã công bố hiện ánh xạ jev-latest sang 1.13, trong khi Box cần 1.14. Ghim jev-1.14.0 làm rõ phụ thuộc này. Hãy xem lại ghi chú phát hành và bộ kiểm thử trước khi đổi phiên bản, thay vì cho rằng bí danh được cập nhật vẫn giữ nguyên hành vi.

Xác suất hư hỏng cao có thể kích hoạt hoàn tiền không?

Chỉ dựa vào bằng chứng đó thì không an toàn. Xác suất liên quan đến câu hỏi về ảnh đã gửi; nó không xác thực đơn hàng, xác định trách nhiệm hay áp dụng chính sách hoàn tiền. Hãy bắt đầu bằng trợ giúp rà soát, xác thực ví dụ đại diện và giữ quyết định của con người cho hành động có hệ quả.

Đầu ra miễn phí có nghĩa yêu cầu ảnh không tốn gì không?

Không. Token đầu vào, bao gồm token ảnh, vẫn bị tính phí. Giá đã công bố không phải báo giá mỗi ảnh vì công thức ước tính token ảnh chưa được tài liệu hóa. Trong chương trình thử nghiệm được cho phép, hãy kiểm tra mức sử dụng trả về và tính cả lần thử lại lẫn thời gian rà soát.

Có thể gửi trực tiếp video sản phẩm hoặc PDF không?

Không qua giao diện ảnh tĩnh được tài liệu hóa. Trước tiên ứng dụng phải trích xuất khung hình, văn bản hoặc trang đã kết xuất phù hợp và cần có quyền xử lý chúng. Chuẩn bị một khung hình sẽ làm mất thông tin thời gian và âm thanh, vì vậy chỉ hỏi điều mà bằng chứng đã cung cấp có thể trả lời.

Kết luận: hướng sự chú ý trước khi giao quyền quyết định

Bản xem trước ảnh Jev đưa ra một đề xuất thực tế: biến bằng chứng hình ảnh thành câu trả lời nhỏ mà phần mềm có thể kiểm tra. Công cụ xử lý trả hàng chiếc cốc có thể thử đề xuất này bằng cách tách hiện diện, hư hỏng, vị trí và rà soát. Kết quả đầu tiên giá trị nhất không phải tự động hoàn tiền; đó là giúp người rà soát đưa ra quyết định có cơ sở hơn với ít công tìm kiếm hơn.

Đó là tiêu chuẩn đáng đo: vùng được đề xuất có giúp một người hiểu bằng chứng gốc tốt hơn, kể cả khi mô hình sai không?

Nguồn và phạm vi

Nguồn chính được kiểm tra ngày 18 tháng 10 năm 2026: thông báo ngày 14 tháng 10 của TypeSafe, mô hình và giá, giới hạn và tính phí ảnh, hợp đồng Box, ví dụ JavaScript và ghi chú phát hành SDK. Các nguồn chính sách và độ tin cậy bổ sung được liên kết cạnh phần diễn giải tương ứng. Quy trình minh họa và sơ đồ là nội dung giải thích được điều chỉnh, không phải benchmark thực hành; không thực hiện lời gọi mô hình trả phí cho bài viết này. Sơ đồ là hình nguyên bản, không sao chép tư liệu của nhà cung cấp.

Đặt nguồn bên cạnh kết luận

Với nghiên cứu mô hình của riêng bạn, hãy giữ nguồn gốc tách biệt với kết luận rút ra từ chúng. Tạo tài khoản Telli.sh để sắp xếp tư liệu nghiên cứu và ghi chú phái sinh mà vẫn giữ nguyên ngữ cảnh nguồn.