Jev อ่านภาพถ่ายได้แล้ว: จากการตรวจสินค้าคืนไปจนถึงการชี้จุดเสียหาย

ลูกค้าถ่ายรูปแก้วที่บิ่น เครื่องมือฝ่ายบริการต้องตอบคำถามคนละข้อสามอย่าง: มองเห็นแก้วหรือไม่ ภาพแสดงความเสียหายหรือไม่ และผู้ตรวจควรมองบริเวณใด คำบรรยายคล่อง ๆ เกี่ยวกับเซรามิกไม่ใช่ผลลัพธ์ระหว่างทางที่มีประโยชน์ที่สุด

เมื่อวันที่ 14 ตุลาคม 2026 TypeSafe AI ประกาศเพิ่มการรองรับภาพแบบทดลองให้ Jev พร้อมกับ Jev 1.14.0 และชนิดเอาต์พุต box แบบภาพใช้งานได้ทั้ง Jev 1.13 และ 1.14 แต่ Box ต้องใช้ 1.14 TypeSafe ระบุว่าฟีเจอร์เหล่านี้ยังเป็นการทดลอง และยังไม่แนะนำให้ใช้กับระบบอัตโนมัติใน production ประกาศอย่างเป็นทางการ

การเปลี่ยนแปลงที่เป็นประโยชน์มีขอบเขตแคบกว่าผู้ช่วย multimodal ที่ทำได้ทุกอย่าง: ภาพถ่ายเปลี่ยนเป็นคำตัดสินแบบมีชนิดข้อมูลหรือตำแหน่งภายในโปรแกรมได้ ต่อไปนี้จะอธิบายว่ามีผลอย่างไรกับเวิร์กโฟลว์รับคืนสินค้า อินเทอร์เฟซรองรับอินพุตแบบใด และจะสร้างต้นแบบอย่างระมัดระวังโดยไม่เข้าใจผิดว่ากรอบสี่เหลี่ยมคือหลักฐานได้อย่างไร

แผนภาพอธิบายต้นฉบับ: รับภาพเข้า ส่งคำตัดสินแยกกันและพิกัดออกมา พร้อมให้คนตรวจบริเวณความเสียหาย ภาพนี้อธิบายเวิร์กโฟลว์ ไม่ใช่ผลโมเดลที่บันทึกจากการทดลอง

ภาพถ่ายเปลี่ยนเป็นคำตัดสินได้ ไม่ใช่แค่คำบรรยาย

Jev เดิมโดดเด่นที่คำตอบแบบมีขอบเขต: เลือกตัวเลือกที่กำหนด ให้คะแนนตามระดับที่อธิบายไว้ หรือประเมินข้อเสนอแบบใช่/ไม่ใช่ คู่มือก่อนหน้าของเราเกี่ยวกับโมเดล decision ของ Jev อธิบายพื้นฐานนี้ ความสามารถใหม่คือการนำหลักฐานภาพมาใช้กับคำถามเหล่านั้น พร้อมวิธีส่งพิกัดเชิงพื้นที่กลับมา

สำหรับหน้าจอรับคืนสินค้า นี่เปลี่ยนการแบ่งงาน โมเดลเสนอได้ว่ามองเห็นความเสียหาย จากนั้นโค้ดแอปนำข้อเสนอนั้นไปแสดงข้างภาพที่ลูกค้าส่งมา แต่ไม่มีขั้นตอนใดยืนยันได้ว่าความเสียหายเกิดขึ้นเมื่อไร ภาพเป็นของคำสั่งซื้อนี้จริงหรือไม่ หรือได้รับอนุญาตให้คืนเงินหรือไม่ นี่เป็นคำถามคนละข้อและใช้หลักฐานคนละชนิด

ขอบเขตเหล่านี้อ้างอิงจาก model reference, สัญญาคำขอ API และ SDK ที่รองรับภาพ โฟลเดอร์ PDF ไม่ได้กลายเป็น pipeline ประมวลผลเอกสารเพียงเพราะบางหน้ามีรูป และการดึงหลายเฟรมก็ไม่ได้แปลว่าโมเดลเข้าใจวิดีโอ native หรือเข้าถึงเสียงประกอบคลิปได้

มุมมองของเรา: หน่วยที่น่าสนใจคือคำตัดสินเล็ก ๆ ที่ตรวจได้และแนบหลักฐานไว้ด้วย ไม่ใช่สิทธิ์ใหม่ให้ทำทุกขั้นตอนต่อจากนั้นเป็นอัตโนมัติ

ตัวอย่างทางการสามแบบเปลี่ยนภาพเดียวกันให้เป็นงานต่างชนิด

เอกสาร JavaScript ของ TypeSafe มีจุดเริ่มต้นที่เป็นรูปธรรมสามแบบ เป็นตัวอย่างโค้ดที่เผยแพร่ ไม่ใช่รายงานการใช้งานจริงของลูกค้าหรือผลวัด ให้มองเป็นรูปแบบสำหรับต้นแบบ ไม่ใช่คำมั่นด้านความแม่นยำกับภาพของคุณ

ตัวอย่างแรกผสานคำร้องว่าแก้วเสียหายกับภาพสินค้า แล้วถาม Noul เรื่องความเสียหายและถาม Score เรื่องระดับความรุนแรง ในคิวฝ่ายสนับสนุน สามารถปรับใช้เพื่อจัดกรณีที่สงสัยว่ามีความเสียหายไว้ให้ตรวจได้ก่อน ผู้ตรวจยังควรเห็นภาพเต็ม คำอธิบายของลูกค้า และตัวเลือกให้ปฏิเสธข้อเสนอ

ตัวอย่างที่สองเปรียบเทียบภาพที่ผู้ขายอัปโหลดกับภาพในแค็ตตาล็อก ถามว่าเป็นสินค้าเดียวกันหรือไม่ และจัดประเภทความพร้อมใช้งานของภาพ รวมถึงภาพเบลอ ถูกครอป และมีสิ่งอื่นที่ไม่ใช่สินค้า สำหรับ marketplace นี่ชี้ให้เห็นการแยกที่มีประโยชน์: การจับคู่ตัวตนกับคุณภาพภาพไม่จำเป็นต้องใช้การอนุมัติข้อเดียว ภาพชัดของสินค้าผิดชิ้นไม่ควรผ่านเพียงเพราะดูเป็นมืออาชีพ

ตัวอย่างที่สามขอให้ Box ระบุตำแหน่งบริเวณเสียหาย ผลลัพธ์อาจช่วยวาง overlay หรือเสนอส่วนครอปให้ผู้ตรวจ เก็บภาพต้นฉบับที่ไม่ครอปไว้คู่กัน การจำกัดจุดสนใจช่วยให้ตรวจคำร้องได้ง่ายขึ้น แต่ก็อาจซ่อนบริบทที่เปลี่ยนความหมาย

ดูตัวอย่างอย่างเป็นทางการสำหรับ ประเมินความเสียหาย, เปรียบเทียบแค็ตตาล็อก และ ระบุตำแหน่งความเสียหาย เวิร์กโฟลว์รับคืนสินค้าที่เราเสนอเพิ่มมาตรการป้องกันระดับแอปรอบรูปแบบเหล่านี้ ไม่ใช่รายงานจากการทดลอง

กรอบสี่เหลี่ยมบอกไม่ได้ว่าไม่มีอะไรให้หา

รายละเอียดสำคัญใน สัญญา Box ของ TypeSafe คือ ไม่มีเอาต์พุตกรณีไม่พบเป้าหมาย คำถาม Box จะคืนขอบทั้งสี่แม้ไม่มีเป้าหมายที่ระบุ ดังนั้นกรอบรอบแก้วที่สมบูรณ์จึงใช้ยืนยันด้วยตัวเองไม่ได้ว่ามีความเสียหาย

ถาม Noul อีกข้อแยกต่างหากว่ามีเป้าหมายที่ต้องการอยู่หรือไม่ สำหรับเวิร์กโฟลว์นี้ ให้แยกว่ามองเห็นแก้วกับมองเห็นความเสียหายหรือไม่ การตอบว่ามีแก้ว ไม่เพียงพอที่จะอนุญาตให้แสดงกรอบความเสียหาย ให้ละเว้นกรอบที่เสนอ เว้นแต่การตรวจการมีอยู่ของเป้าหมายที่เกี่ยวข้องผ่านกติกาที่คุณประเมินแล้ว

นี่เป็นประตูตรวจว่ามีเป้าหมาย ไม่ใช่วิธีแก้ความผิดพลาด คำตัดสินทั้งสองข้ออาจผิดพร้อมกัน แสงสะท้อนจ้าอาจดูเหมือนรอยบิ่น ขณะที่รอยร้าวจริงอาจกลืนไปกับลายเคลือบ ทดสอบภาพที่ไม่มีแก้ว แก้วสมบูรณ์ แสงสะท้อนกำกวม วัตถุหลายชิ้น และความเสียหายที่เห็นชัดก่อนเลือก threshold

แผนภาพการตัดสินใจต้นฉบับ: ใช้กรอบที่ถูกต้องได้เมื่อผ่านการตรวจว่ามีเป้าหมายเท่านั้น หากตรวจไม่ผ่านหรือไม่แน่ใจ ให้คงภาพต้นฉบับไว้ตรวจโดยคน ไม่ใช่ใช้ปฏิเสธคำร้องอัตโนมัติ

ให้คิดว่ากรอบเป็นตัวชี้ ไม่ใช่คำตัดสิน

มองพิกัดเป็นเรขาคณิต แล้วค่อยตรวจความหมาย

Box ส่ง left, right, top และ bottom เป็นสัดส่วนเทียบกับขนาดภาพ โดยวัดจากมุมซ้ายบน ค่าอยู่ระหว่าง 0 ถึง 1 และต้องเป็นไปตาม left < right กับ top < bottom หนึ่งคำถามให้หนึ่งกรอบ ไม่ใช่รายการตรวจจับวัตถุ สัญญาโครงสร้างคำตอบ Box

สำหรับภาพเตรียมไว้ขนาด 1200 x 900 เป็นตัวอย่าง ขอบที่ left 0.20, top 0.30, right 0.60 และ bottom 0.70 ตรงกับขอบพิกเซล 240, 270, 720, 630 นี่เป็นตัวอย่างคำนวณ ไม่ใช่คำตอบจาก Jev API ครอปทั่วไปมักต้องการลำดับ left, top, right, bottom ให้จับคู่ฟิลด์ที่มีชื่ออย่างตั้งใจ อย่าพึ่งลำดับ property ใน JSON

ตรวจว่าค่าทั้งหมดเป็นตัวเลขจำกัด อยู่ในขอบเขต และเรียงลำดับถูกต้องก่อนวาดสิ่งใด จากนั้นตรวจว่าบริเวณนั้นชี้ไปที่ความเสียหายจริงหรือไม่ หากปรับขนาด หมุน เติมขอบ หรือแบ่งภาพเป็น tiles ให้เก็บข้อมูลการแปลงไว้เพื่อแปลงพิกัดกลับ ไม่เช่นนั้นกรอบที่ดูสมเหตุสมผลอาจชี้ไปยังพิกเซลผิดตำแหน่ง

เตรียมภาพก่อนส่งคำขอ อย่ารอให้ error แจ้ง

ข้อจำกัดภาพอย่างเป็นทางการ กำหนดค่าแน่นอนและรวมค่าขอบเขต ภาพที่เกินขอบเขตจะถูกปฏิเสธโดยไม่มีการปรับขนาดอัตโนมัติ หากมีภาพหนึ่งภาพถูกปฏิเสธ คำขอทั้งหมดจะล้มเหลว

การอ้างภาพซ้ำจะถูกนับซ้ำอีกครั้งในคำขอที่ขยาย ขนาดไฟล์ มิติภาพ และความยาว context เป็นการตรวจคนละข้อ ข้อจำกัดภาพ

แผนภาพข้อจำกัดต้นฉบับอ้างอิงเอกสารภาพของ TypeSafe ตรวจสอบเมื่อ 18 ตุลาคม 2026 ขีดจำกัดต่อไฟล์ ภาพหลังประมวลผล คำขอหลังขยาย และ request body มีผลแยกจากกัน

TypeSafe ยังระบุให้หมุนพิกเซลให้ตั้งตรงก่อนส่ง: API ลบ metadata และไม่ใช้ EXIF orientation แปลงรูปแบบที่ไม่รองรับก่อน แนวทางเตรียมภาพ

สำหรับต้นแบบ ให้เตรียมสำเนาภาพที่คุณเป็นเจ้าของโดยตั้งชื่อชัดเจน แล้วเก็บต้นฉบับไว้ ตรวจมิติภาพในเครื่องและแสดงตัวอย่างสำเนาที่จะส่งจริง ภาพครอปแคบอาจต้องเติมขอบให้ถึงมิติขั้นต่ำ ให้บันทึกขอบที่เติมไว้ก่อนตีความพิกัด

Pin รุ่น 1.14 และเปิดสวิตช์ทดลองอย่างชัดเจน

ณ วันที่ 18 ตุลาคม ตาราง alias ที่เผยแพร่จับคู่ jev-latest กับ jev-1.13.0 และ jev-preview กับ jev-1.14.0 หากใช้ตัวอย่าง Box ให้ pin jev-1.14.0 แทนการคิดว่า latest หมายถึง preview ใหม่ที่สุด model aliases

ขั้นตอนต่อไปนี้สร้างตัวอย่างในเครื่องที่ใช้เพื่อการตรวจทานเท่านั้น การรันคำสั่งสุดท้ายจะส่ง inference request ที่มีค่าบริการ และ SDK อาจลองซ้ำ แต่จะไม่อนุมัติการคืนสินค้าหรือเปลี่ยนบัญชี ใช้ภาพจัดฉากที่คุณเป็นเจ้าของ โดยไม่มีคน ฉลากขนส่ง ที่อยู่ หรือเอกสารส่วนตัว

1. ขอสิทธิ์และเลือกองค์กรที่ถูกต้อง TypeSafe ระบุว่าการสมัครไม่ต้องรออนุมัติ waitlist อีกแล้ว สร้าง API key ใน console แล้วตรวจเครดิตองค์กรก่อนทดสอบ การเข้าถึงบัญชี, การตั้งค่าเครดิต
2. ใช้ Node.js 22 หรือใหม่กว่า SDK JavaScript ที่รองรับภาพรุ่น 0.7.0 ลงวันที่ 14 ตุลาคม การ pin รุ่นทำให้ dependency ของตัวอย่างชัดเจน บันทึก SDK changelog

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

3. ตั้ง key เฉพาะเซสชัน ใช้บล็อกแรกใน Windows PowerShell และบล็อกที่สองใน macOS หรือ Linux Bash/Zsh แทน placeholder ในเครื่องและอย่า commit key จริง

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

export TYPESAFE_API_KEY="your-api-key"

4. เตรียม owned-mug.jpg แล้วสร้าง inspect-return.mjs การดัดแปลงต้นฉบับนี้ใช้ helper ของ SDK ตามเอกสาร ตั้ง header ทดลองก่อนส่งคำขอภาพใด ๆ ค่า cutoff ความน่าจะเป็นสองค่าด้านล่างเป็นกติกาแอปเพื่อประกอบตัวอย่าง ไม่ใช่คำแนะนำจาก TypeSafe ทุกผลลัพธ์ยังต้องให้คนตรวจ การใช้งาน 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. รันเมื่อพร้อมส่งภาพและยอมรับค่าใช้งานเท่านั้น ทั้งสามระบบปฏิบัติการใช้คำสั่ง node inspect-return.mjs หากเกิด exception หรือได้ suggestedBox: null ให้คงภาพต้นฉบับไว้สำหรับการตรวจ ไม่ใช่ส่งคำขออัตโนมัติซ้ำ

คำถามทั้งสองข้อใช้คำขอเดียวกัน แต่จะละเว้นกรอบหากไม่ผ่าน gate ของแอป วิธีนี้ไม่ได้ประหยัดค่าใช้จ่ายคำนวณกรอบที่ไม่ใช้ การออกแบบภายหลังอาจทำ localization เป็นคำขอที่สองหลังตรวจการมีเป้าหมายแล้ว เพื่อแลกกับ round trip เพิ่มหนึ่งครั้งและลดการเรียก localization ที่ไม่จำเป็น

ราคา token ต่ำไม่ใช่ราคาต่อภาพถ่าย

ราคาที่เผยแพร่สำหรับทั้งสองรุ่นคือ $0.042 ต่อ input หนึ่งล้าน token ส่วน output token ฟรี ดังนั้น input ที่คิดค่าบริการ 10 ล้าน token มีค่า $0.42 ไม่ได้หมายความว่าภาพสิบล้านภาพมีราคาเท่านั้น ราคาที่เผยแพร่

ภาพถูกนับเป็น input token ด้วยอัตราข้อความ ไม่มีค่าธรรมเนียมภาพแยกต่างหาก เอกสาร TypeSafe ยังไม่ได้ให้สูตรประมาณ image token ใช้ usage.input_tokens ที่ได้กลับมาเพื่อวางงบในการประเมินที่ได้รับอนุญาต แทนการแต่งต้นทุนต่อภาพขึ้นเอง การคิดค่าภาพ

งบควรรวมคำขอที่ล้มเหลว การลองซ้ำ การเตรียมภาพ พื้นที่จัดเก็บ และเวลาผู้ตรวจ จดต้นทุนกับคุณภาพไว้ด้วยกัน: ประหยัดเศษเสี้ยวเซนต์ไม่มีประโยชน์ หากกรอบที่แคบเกินทำให้ผู้ตรวจทุกคนต้องเปิดภาพต้นฉบับอีกครั้ง เปรียบเทียบงานตรวจทั้งหมดกับ baseline ที่ทำด้วยมือแบบง่าย

ออกแบบให้รองรับความไม่แน่นอน ความเป็นส่วนตัว และบริการที่มีภาระ

Noul คืนค่าความน่าจะเป็นโดยไม่มีฟิลด์ confidence แยก ส่วน Choice และ Score มี distribution และค่า confidence ที่คำนวณเพิ่มเติม ค่าเหล่านี้แสดงความไม่แน่นอนของโมเดล ไม่ใช่ใบรับรองความถูกต้องแบบครอบจักรวาล เอกสาร confidence

สำหรับเวิร์กโฟลว์แก้ว ให้ตรวจ gate ด้วยภาพที่กันไว้ทดสอบและมีป้ายกำกับตกลงร่วมกัน จัดกลุ่มเอาต์พุตที่คล้ายกันแล้วเทียบกับความถูกต้องที่สังเกตได้เพื่อตรวจ calibration สำหรับงานของคุณ วัดความเสียหายที่พลาดแยกจาก false alarm และแยกกรอบ overlay ผิดตำแหน่งออกจากการตัดสินใจคืนเงินที่ผิด ประเมิน threshold ใหม่เมื่อเปลี่ยนโมเดล แสง หมวดสินค้า หรือวิธีถ่ายภาพ

อย่ามองว่าภาพที่ไม่ผ่านทั้งหมดเป็นหลักฐานกล่าวโทษลูกค้า ภาพอาจไม่เพียงพอเพราะกล้องคุณภาพต่ำ วัตถุสะท้อนแสง หรือข้อบกพร่องต้องใช้มุมอื่น สถานะการตรวจที่ดีควรเปิดทางให้ส่งภาพเพิ่มและตรวจด้วยคน โดยไม่โยนความผิดให้ลูกค้าเพราะโมเดลไม่แน่ใจ

TypeSafe ระบุว่าไม่นำคำขอและคำตอบของลูกค้าไปฝึก Jev ศูนย์ช่วยเหลือยังอธิบายว่าการประมวลผลอาจรวมการให้บริการ การเรียกเก็บเงิน การป้องกันการใช้งานผิด และ telemetry ส่วนการเก็บรักษาขึ้นอยู่กับข้อมูล ข้อตกลง และการจัดการ zero-data-retention ที่มี การไม่ฝึกโมเดลไม่เท่ากับไม่เก็บข้อมูล นโยบายจัดการข้อมูล

หน้า สถานะบริการสาธารณะ ระบุภูมิศาสตร์สหรัฐฯ และ region us-east-1, us-east-2 และ us-west-2 ทีมที่ต้องปฏิบัติตามข้อกำหนด data residency ในภูมิภาคควรตกลงเรื่องสถานที่ประมวลผลก่อนอัปโหลดภาพลูกค้า การเปิด console ได้ไม่ใช่ข้อตกลงเรื่อง residency

ลดข้อมูลก่อนอัปโหลด ตัดฉลากที่อยู่บนพัสดุออกจากสำเนาที่เตรียมไว้หากไม่เกี่ยว จำกัดสิทธิ์เข้าถึงต้นฉบับ และหลีกเลี่ยงการใส่ภาพหรือ secret ลงใน logs ปกติ กำหนดการเก็บรักษาบันทึกตรวจของคุณแยกจากนโยบายผู้ให้บริการ

ข้อจำกัดขององค์กรครอบคลุมจำนวน request และ token ต่อวินาที API ระบุ 429 สำหรับ rate limiting และ 529 เมื่อระบบล้น ส่วนอินพุตผิดรูปแบบหรือใหญ่เกินต้องแก้ ไม่ใช่ส่งซ้ำแบบเดิม Rate limits, API errors

นโยบาย retry เริ่มต้นของ JavaScript SDK คือสองครั้ง และทำตาม header หน่วงเวลาที่รองรับ อย่าเพิ่ม retry loop ภายนอกที่ไม่จำกัด ตั้งงบเวลา เก็บสถานะ error ที่นำไปแก้ต่อได้ และแยกการกระทำทางธุรกิจในอนาคตไว้ต่างหาก เพื่อไม่ให้ inference ที่ลองซ้ำส่งคำขอคืนเงินซ้ำ นโยบาย retry

คำถามที่ควรตอบก่อนสร้างเวิร์กโฟลว์ภาพแรก

Jev จะแก้ไขหรือสร้างภาพถ่ายสินค้าคืนหรือไม่?

ไม่ ภาพเป็นหลักฐานประกอบคำตัดสินหรือบริเวณที่เสนอ แอปของคุณเป็นผู้วาด overlay หรือครอปภาพด้วยโค้ดประมวลผลภาพทั่วไป เก็บต้นฉบับที่ยังไม่แตะต้องแยกไว้ กรอบที่ใช้ได้ไม่ใช่สิ่งทดแทนหลักฐานต้นฉบับ

ทำไมตัวอย่าง pin 1.14 แทนที่จะใช้ latest?

ตาราง alias ที่เผยแพร่ตอนนี้จับคู่ jev-latest กับ 1.13 แต่ Box ต้องใช้ 1.14 การ pin jev-1.14.0 ทำให้ dependency นี้ชัดเจน ก่อนเปลี่ยนเวอร์ชัน ให้ตรวจ release notes และชุดทดสอบ อย่าคิดว่าการอัปเดต alias จะคงพฤติกรรมเดิมเสมอ

ความน่าจะเป็นความเสียหายสูงสั่งคืนเงินได้ไหม?

ไม่ปลอดภัยหากใช้หลักฐานนั้นอย่างเดียว ความน่าจะเป็นตอบคำถามเกี่ยวกับภาพที่ส่งมา ไม่ได้ยืนยันคำสั่งซื้อ ระบุความรับผิด หรือใช้กติกาคืนเงิน เริ่มจากการช่วยผู้ตรวจ ประเมินตัวอย่างที่เป็นตัวแทน และคงการตัดสินใจของคนไว้สำหรับการกระทำที่มีผลสำคัญ

output ฟรีแปลว่าคำขอภาพไม่มีค่าใช้จ่ายหรือไม่?

ไม่ input token รวม image token มีค่าใช้จ่าย อัตราที่เผยแพร่ไม่ใช่ราคาต่อภาพ เพราะยังไม่มีเอกสารสูตรประมาณ image token ตรวจ usage ที่รายงานระหว่างโครงการนำร่องที่ได้รับอนุญาต และรวมการลองซ้ำกับเวลาตรวจทานไว้ในต้นทุนทั้งหมด

ส่งวิดีโอสินค้าหรือ PDF โดยตรงได้ไหม?

ไม่ได้ผ่านอินเทอร์เฟซภาพนิ่งที่เอกสารระบุ แอปของคุณต้องแยกเฟรมที่เหมาะสม ข้อความ หรือหน้าเรนเดอร์ก่อน โดยต้องได้รับอนุญาตให้ประมวลผล การเตรียมเฟรมทำให้ข้อมูลเวลาและเสียงหายไป ดังนั้นให้ถามเฉพาะสิ่งที่หลักฐานที่ให้มานั้นตอบได้

บทสรุป: ชี้จุดสนใจ ก่อนมอบอำนาจตัดสินใจ

พรีวิวภาพของ Jev เสนอแนวคิดที่ใช้ได้จริง: เปลี่ยนหลักฐานภาพให้เป็นคำตอบเล็ก ๆ ที่ซอฟต์แวร์ตรวจได้ เครื่องมือรับคืนแก้วสามารถทดสอบแนวคิดนี้ด้วยการแยกการมีอยู่ ความเสียหาย ตำแหน่ง และการตรวจทาน ผลลัพธ์แรกที่มีค่าที่สุดไม่ใช่การคืนเงินอัตโนมัติ แต่คือช่วยให้ผู้ตรวจตัดสินใจโดยมีหลักฐานรองรับดีขึ้นและค้นหาน้อยลง

มาตรฐานที่ควรวัดคือ: บริเวณที่เสนอช่วยให้คนเข้าใจหลักฐานต้นฉบับ รวมทั้งกรณีที่โมเดลผิด ได้ดีขึ้นหรือไม่?

แหล่งที่มาและขอบเขต

แหล่งข้อมูลปฐมภูมิตรวจสอบเมื่อ 18 ตุลาคม 2026: ประกาศวันที่ 14 ตุลาคมของ TypeSafe, โมเดลและราคา, ข้อจำกัดและการคิดค่าภาพ, สัญญา Box, ตัวอย่าง JavaScript และ บันทึกรุ่น SDK แหล่งข้อมูลด้านนโยบายและความเสถียรเพิ่มเติมลิงก์ไว้ข้างข้อกล่าวอ้าง เวิร์กโฟลว์และแผนภาพเป็นตัวอย่างอธิบาย ไม่ใช่ benchmark จากการทดลองจริง ไม่มีการเรียกโมเดลแบบเสียค่าใช้จ่ายเพื่อเขียนบทความนี้ แผนภาพเป็นงานต้นฉบับ ไม่ได้คัดลอกจากสื่อผู้ขาย

เก็บแหล่งข้อมูลไว้ข้างข้อสรุป

สำหรับการค้นคว้าโมเดลของคุณ ให้แยกแหล่งข้อมูลต้นฉบับออกจากข้อสรุปที่ได้จากแหล่งเหล่านั้น สร้างบัญชี Telli.sh เพื่อจัดระเบียบข้อมูลค้นคว้าและบันทึกที่ได้มา โดยคงบริบทของแหล่งต้นทางไว้