Jev ya interpreta fotos: de comprobar una devolución a localizar el daño

Diagrama explicativo original: entra una foto y salen decisiones y coordenadas por separado; una persona revisa la zona de daño propuesta. Ilustra un flujo de trabajo, no un resultado registrado del modelo.

Un cliente fotografía una taza con un desconchón. La herramienta de soporte tiene que responder tres preguntas distintas: ¿se ve la taza?, ¿la imagen muestra daños? y ¿dónde debería mirar la persona que la revise? Un párrafo fluido sobre cerámica no es el resultado intermedio más útil.

El 14 de octubre de 2026, TypeSafe AI anunció compatibilidad experimental con imágenes para Jev junto con Jev 1.14.0 y un nuevo tipo de salida box. Las imágenes funcionan tanto con Jev 1.13 como con Jev 1.14; Box requiere la versión 1.14. TypeSafe califica estas funciones de experimentales y deja claro que aún no recomienda usarlas en automatizaciones de producción. Anuncio oficial

El cambio útil tiene un alcance más concreto que un asistente multimodal de propósito general: una foto puede convertirse en una decisión tipada o en una ubicación dentro de un programa. Veamos cómo modifica un flujo de devoluciones, qué acepta la interfaz y cómo crear un prototipo prudente sin confundir un rectángulo con una prueba.

En resumen:

• Jev incorpora una vía experimental para comprender imágenes estáticas, no para generarlas.
• Comprueba que el objeto esté presente antes de fiarte de la ubicación propuesta.
• Conserva la foto original y la revisión humana; deja que el código valide las coordenadas, los permisos y las consecuencias.

Una fotografía puede convertirse en una decisión, no solo en una descripción

La propuesta original de Jev eran las respuestas acotadas: elegir una opción proporcionada, puntuar según niveles descritos o evaluar una proposición de sí o no. Nuestra guía anterior sobre el modelo de decisiones de Jev explica esa base. La novedad es aportar pruebas visuales a esas preguntas, además de una forma de devolver coordenadas espaciales.

En una interfaz de devoluciones, eso cambia el reparto del trabajo. El modelo puede sugerir que se ve un daño; el código de la aplicación puede mostrar esa sugerencia junto a la imagen enviada. Ninguna de las dos operaciones determina cuándo se produjo el daño, si la fotografía pertenece a este pedido ni si se ha autorizado un reembolso. Son preguntas diferentes y cada una requiere pruebas distintas.

Estos límites se basan en la referencia del modelo, el contrato de solicitudes de la API y el SDK con compatibilidad de imágenes. Una carpeta de PDF no se convierte en un flujo de procesamiento de documentos solo porque algunas páginas contengan imágenes. Del mismo modo, varios fotogramas extraídos no demuestran comprensión nativa del vídeo ni acceso a la pista de sonido del clip.

Nuestra conclusión: la unidad interesante es una decisión pequeña y comprobable, vinculada a sus pruebas. No es un nuevo permiso para automatizar todo lo que venga después.

Tres ejemplos oficiales convierten la misma foto en trabajos distintos

La documentación de JavaScript de TypeSafe ofrece tres puntos de partida concretos. Son ejemplos de código publicados, no informes de despliegues reales en clientes ni resultados medidos. Úsalos como patrones para un prototipo, no como promesas de precisión con tus fotografías.

El primer ejemplo combina una reclamación por una taza dañada con una foto del producto y pregunta a un Noul si hay daños y a un Score por su gravedad. En una cola de soporte, una adaptación podría priorizar para inspección los casos con posibles daños. El revisor debería seguir viendo la foto completa, la descripción del cliente y la opción de rechazar la sugerencia.

El segundo compara la foto que ha subido un vendedor con la imagen del catálogo. Pregunta si muestran el mismo producto y clasifica la utilidad de la foto, por ejemplo si está borrosa, recortada o contiene elementos ajenos al producto. En un marketplace, esto permite separar dos decisiones: la coincidencia de identidad y la calidad de la foto no tienen que compartir una única aprobación. Una imagen nítida del producto equivocado no debería aprobarse solo porque parezca profesional.

El tercero pide a Box que localice la zona dañada. El resultado podría orientar una superposición o un recorte sugerido para la persona que revise el caso. Conserva a su lado el original sin recortar: dirigir la atención puede ayudar a inspeccionar una reclamación, pero también puede ocultar contexto que altere su interpretación.

Sigue los ejemplos oficiales de evaluación de daños, comparación con el catálogo y localización de daños. Nuestro flujo de devoluciones propuesto añade protecciones en la aplicación alrededor de esos patrones; no es el informe de una prueba.

Una caja no puede decirte que no hay nada que localizar

El detalle esencial del contrato Box de TypeSafe es que no existe una salida para indicar que el objetivo no está presente. Box devuelve cuatro bordes incluso cuando no se encuentra lo que se busca. Por tanto, un rectángulo alrededor de una taza intacta no demuestra por sí solo que haya daños.

Pregunta por separado a un Noul si está presente el objetivo solicitado. En este flujo, distingue entre que la taza sea visible y que haya daños visibles. Una respuesta afirmativa sobre la taza no basta para autorizar una superposición de daños. Ignora la caja propuesta para daños a menos que las comprobaciones pertinentes de presencia superen las reglas validadas de tu aplicación.

Esta comprobación de presencia no elimina los errores. Los dos juicios pueden estar equivocados a la vez. Un reflejo intenso puede parecer un desconchón, mientras una grieta real puede confundirse con un esmalte estampado. Antes de elegir umbrales, prueba fotografías sin taza, de tazas intactas, con reflejos ambiguos, con varios objetos y con daños claramente visibles.

Diagrama original de decisiones: solo se puede utilizar un rectángulo válido si se supera la comprobación de presencia. Si las comprobaciones fallan o son inciertas, se conserva la foto original para revisión humana; no se convierte el resultado en un rechazo automático.

Piensa en el rectángulo como un puntero, no como un veredicto.

Trata las coordenadas como geometría y después comprueba qué significan

Box devuelve left, right, top y bottom como fracciones de las dimensiones de la imagen, medidas desde la esquina superior izquierda. Los valores van de 0 a 1, con left < right y top < bottom. Una pregunta produce una sola caja, no una lista de detecciones de objetos. Contrato de respuesta de Box

Para una imagen preparada ilustrativa de 1200 x 900, los bordes left: 0.20, top: 0.30, right: 0.60 y bottom: 0.70 corresponden a los píxeles 240, 270, 720 y 630. Son ejemplos aritméticos, no una respuesta de Jev. Las API de recorte suelen esperar izquierda, arriba, derecha y abajo; asigna con cuidado los campos por nombre en lugar de depender del orden de las propiedades JSON.

Valida los números finitos, los límites y el orden antes de dibujar nada. Después comprueba si la región identifica realmente el daño. Si cambias el tamaño, rotas, añades márgenes o divides una foto en mosaicos, conserva la transformación necesaria para volver a mapear las coordenadas; de lo contrario, una caja verosímil podría apuntar a los píxeles equivocados.

Prepara la imagen antes de la solicitud, no después de un error

Los límites oficiales de imágenes son precisos e inclusivos. Si una imagen queda fuera de los límites, se rechaza; no se cambia de tamaño automáticamente. Una sola imagen rechazada invalida la solicitud completa.

Las referencias repetidas se cuentan otra vez en la solicitud expandida. El tamaño del archivo, las dimensiones y la longitud del contexto son comprobaciones distintas. Límites de imágenes

Diagrama original de restricciones basado en la documentación de imágenes de TypeSafe, consultada el 18 de octubre de 2026. Los límites por archivo, por imágenes procesadas, por solicitud expandida y por cuerpo se aplican por separado.

TypeSafe también indica que hay que girar los píxeles para que queden derechos antes del envío: la API elimina los metadatos y no aplica la orientación EXIF. Convierte primero los formatos no admitidos. Pautas de preparación

Para crear un prototipo, prepara una copia claramente identificada de una foto propia y deja intacto el original. Comprueba localmente las dimensiones y previsualiza exactamente la copia que vas a enviar. Puede que haya que añadir márgenes a un recorte estrecho para alcanzar la dimensión mínima; registra esos márgenes antes de interpretar sus coordenadas.

Fija la versión 1.14 y activa explícitamente la función experimental

A fecha del 18 de octubre, la tabla de alias publicada asigna jev-latest a jev-1.13.0 y jev-preview a jev-1.14.0. Para un ejemplo con Box, fija jev-1.14.0 en vez de presuponer que latest significa la versión preliminar más nueva. Alias de modelos

El procedimiento siguiente crea un ejemplo local destinado solo a revisión. El último comando envía una solicitud de inferencia facturable y el SDK puede reintentarla; nunca aprueba una devolución ni modifica una cuenta. Utiliza una foto de prueba preparada que sea tuya, sin personas, etiquetas de envío, direcciones ni documentos privados.

1. Obtén acceso y elige la organización correcta. TypeSafe indica que registrarse ya no requiere aprobación de una lista de espera. Crea una clave de API en la consola y revisa los créditos de la organización antes de probarlo. Acceso a la cuenta, ajustes de créditos

2. Usa Node.js 22 o posterior. La versión del SDK de JavaScript con compatibilidad de imágenes es 0.7.0, fechada el 14 de octubre. Fijarla deja explícita la dependencia del cliente en este ejemplo. Registro de cambios del SDK

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

3. Define una clave solo para la sesión. En Windows PowerShell usa el primer bloque; en Bash/Zsh de macOS o Linux, el segundo. Sustituye el marcador de posición localmente y no confirmes una clave real en el repositorio.

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

export TYPESAFE_API_KEY="your-api-key"

4. Prepara owned-mug.jpg y crea inspect-return.mjs. Esta adaptación original usa los helpers documentados del SDK. El encabezado experimental se configura antes de enviar cualquier imagen. Los dos umbrales de probabilidad siguientes son reglas ilustrativas de la aplicación, no recomendaciones de TypeSafe. Todos los resultados requieren revisión humana. Uso del 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. Ejecuta el ejemplo solo cuando estés listo para enviar la imagen y generar consumo. En los tres sistemas operativos, el comando es node inspect-return.mjs. Una excepción o suggestedBox: null debería dejar disponible la imagen original para revisión, no activar envíos automáticos repetidos.

Las preguntas comparten una sola solicitud, pero la aplicación ignora la caja salvo que se supere la comprobación. Esto no evita pagar por calcular una caja que luego no se utiliza. Una solución posterior podría pedir la localización en una segunda solicitud, intercambiando una llamada adicional por evitar solicitudes innecesarias de localización.

Un precio pequeño por token no equivale al precio de una fotografía

La tarifa publicada para ambas versiones es de 0,042 USD por millón de tokens de entrada; los tokens de salida son gratuitos. Eso significa que 10 millones de tokens de entrada facturados cuestan 0,42 USD con la tarifa indicada; no significa que diez millones de imágenes cuesten eso. Precios publicados

Las imágenes cuentan como tokens de entrada a la tarifa de texto, sin un cargo adicional por imagen. TypeSafe todavía no ha publicado una fórmula para estimar los tokens de imagen. Para presupuestar una evaluación autorizada, usa usage.input_tokens de la respuesta en lugar de inventarte un coste por fotografía. Facturación de imágenes

Incluye en el presupuesto los intentos fallidos, los reintentos, el preprocesamiento, el almacenamiento y el tiempo de revisión. Mantén juntas las métricas de coste y calidad: ahorrar una fracción de céntimo no sirve de mucho si un recorte demasiado estrecho obliga a cada revisor a volver a abrir el original. Compara la tarea de revisión completa con una alternativa manual sencilla.

Diseña teniendo en cuenta la incertidumbre, la privacidad y la carga del servicio

Noul devuelve una probabilidad sin un campo confidence independiente. Choice y Score incluyen distribuciones y valores de confianza derivados. Esos valores describen la incertidumbre del modelo; no son un certificado general de corrección. Documentación de confianza

Para el flujo de la taza, valida la comprobación con fotografías reservadas y etiquetas acordadas. Agrupa resultados similares y compáralos con la corrección observada para comprobar la calibración en tu tarea. Mide por separado los daños no detectados y las falsas alarmas, y distingue una superposición mal ubicada de una decisión de reembolso equivocada. Vuelve a evaluar los umbrales si cambias de modelo, iluminación, categoría de producto o proceso de captura.

No interpretes cualquier imagen que no supere la comprobación como una prueba contra el cliente. La foto puede ser inadecuada porque la cámara sea mala, el objeto refleje la luz o haga falta otro ángulo para ver el defecto. Una revisión útil ofrece las opciones de enviar otra foto y de inspeccionar manualmente, sin culpar al cliente por la incertidumbre del modelo.

TypeSafe afirma que las solicitudes y respuestas de clientes no se utilizan para entrenar Jev. Su centro de ayuda también explica que el procesamiento puede incluir la prestación del servicio, la facturación, la prevención de abusos y la telemetría; la conservación depende de los datos, los acuerdos y cualquier opción de retención cero de datos. No entrenar con los datos no equivale a no conservarlos. Política de tratamiento de datos

La página pública del estado del servicio indica la geografía de EE. UU. y las regiones us-east-1, us-east-2 y us-west-2. Los equipos sujetos a requisitos regionales de residencia de datos deberían aclarar dónde se procesan las imágenes antes de subir fotografías de clientes. Poder acceder a una consola no constituye un acuerdo de residencia de datos.

Minimiza los datos antes de subirlos. Si no hace falta, recorta la etiqueta con la dirección en una copia preparada, restringe el acceso a los originales y evita incluir imágenes o secretos en los registros habituales. Define la conservación de tus propios registros de revisión independientemente de la política del proveedor.

Los límites de la organización se aplican a solicitudes y tokens por segundo. La API documenta 429 para la limitación de frecuencia y 529 para la sobrecarga; una entrada mal formada o demasiado grande requiere corregirse, no volver a enviarse sin cambios. Límites de frecuencia, errores de la API

La política predeterminada de reintentos del SDK de JavaScript hace dos reintentos y respeta los encabezados admitidos de espera entre intentos. No añadas otro ciclo externo de reintentos sin límite. Establece un límite de tiempo, conserva un estado de error que permita actuar y mantén separada cualquier acción comercial futura para que una inferencia repetida no emita reembolsos duplicados. Política de reintentos

Preguntas para antes de tu primer flujo con fotografías

¿Jev editará o generará la foto de la devolución?

No. La imagen sirve como prueba para una decisión o una región propuesta. Tu aplicación dibuja una superposición o recorta la imagen con código normal de procesamiento de imágenes. Conserva aparte la fuente intacta: un rectángulo útil no sustituye las pruebas originales.

¿Por qué el ejemplo fija la versión 1.14 en vez de usar latest?

La tabla de alias publicada asigna actualmente jev-latest a la versión 1.13, mientras que Box requiere la 1.14. Fijar jev-1.14.0 hace explícita esa dependencia. Antes de cambiar la versión, vuelve a leer las notas de publicación y ejecuta tus pruebas; no supongas que el cambio de alias conserva el comportamiento.

¿Una probabilidad alta de daños puede activar un reembolso?

No es seguro hacerlo basándose solo en esas pruebas. La probabilidad se refiere a la pregunta formulada sobre la imagen enviada; no autentica el pedido, no determina responsabilidades ni aplica la política de devoluciones. Empieza asistiendo a la revisión, valida ejemplos representativos y reserva la decisión humana para las acciones con consecuencias.

¿Si la salida es gratuita, una solicitud con imagen no cuesta nada?

No. Se facturan los tokens de entrada, incluidos los de imagen. La tarifa publicada no es un precio por foto porque todavía no se documenta la fórmula para estimar los tokens de imagen. En un piloto autorizado, revisa el consumo comunicado e incluye los reintentos y el tiempo de revisión en el total.

¿Puedo enviar directamente un vídeo de producto o un PDF?

No a través de la interfaz documentada para imágenes estáticas. La aplicación debe extraer primero fotogramas adecuados, texto o páginas renderizadas y contar con permiso para procesarlos. Extraer un fotograma pierde la información temporal y de audio, así que formula solo preguntas que las pruebas suministradas puedan responder.

En resumen: dirige la atención antes de delegar autoridad

La versión preliminar de Jev para imágenes propone algo práctico: convertir pruebas visuales en respuestas pequeñas que el software pueda inspeccionar. Una herramienta de devoluciones de tazas puede ponerlo a prueba separando la presencia, los daños, su ubicación y la revisión. El resultado inicial más valioso no es un reembolso autónomo; es que quien revisa llegue a una decisión mejor respaldada y tenga que buscar menos.

Ese es el criterio que merece medirse: ¿ayuda la región propuesta a una persona a entender las pruebas originales, incluso cuando el modelo se equivoca?

Fuentes y alcance

Fuentes primarias consultadas el 18 de octubre de 2026: el anuncio de TypeSafe del 14 de octubre, modelos y precios, límites de imágenes y facturación, contrato Box, ejemplos de JavaScript y notas de versión del SDK. Las fuentes adicionales sobre políticas y fiabilidad están enlazadas junto a las afirmaciones correspondientes. El flujo y los diagramas son adaptaciones explicativas, no un benchmark práctico; no se realizó ninguna llamada de pago al modelo para este artículo. Los diagramas son originales y no copian material del proveedor.

Conserva la fuente junto a la conclusión

En tu propia investigación de modelos, mantén separadas las fuentes originales de las conclusiones que extraigas. Crea una cuenta de Telli.sh para organizar el material de investigación y las notas derivadas sin perder el contexto de sus fuentes.