JEV ahora puede evaluar imágenes, y para mí acá es donde se pone interesante. Le pasas una foto, le explicas qué necesitas revisar y usas la respuesta para hacer algo dentro de tu aplicación. No se trata solamente de obtener una descripción de lo que aparece. Se trata de convertir esa imagen en un dato que tu código pueda aprovechar.
Piensa en una tienda donde los clientes suben fotos de productos. O en una colección de referencias que ya no sabes cómo ordenar. O en un buscador que recibe una imagen y te ayuda a elegir un diseño web. Son problemas distintos, pero comparten una estructura muy sencilla: una imagen, una pregunta concreta y una acción a partir del resultado.
Hice una consulta real con la foto de un perfume para comprobar ese recorrido. También preparé un buscador visual para el catálogo de Dínamo Sites. La primera prueba sirve para entender la base; la segunda muestra cómo esa misma idea puede convertirse en una herramienta útil para trabajar.
Eso sí, hay que separar lo que ya probamos de lo que todavía son ideas, entender bien los puntajes y recordar que la entrada de imágenes sigue siendo experimental. Ahí está la diferencia entre una demostración que se ve interesante y una función que puedes incorporar con criterio a un proyecto.
Tabla de contenido
- 🧠 Qué es JEV y para qué sirve dentro de una aplicación
- 👁️ Qué cambia ahora que JEV puede evaluar imágenes
- 🎯 Noul, Choice y Score: tres formas de preguntar
- 🧴 Una consulta real: comprobar si un perfume aparece completo
- 🔌 Cómo conectar JEV con OpenRouter
- 💡 Tres ideas de aplicaciones que salen de esta base
- 📍 Box: localizar un objeto no es comprobar su presencia
- 🏡 Mi prueba en Dínamo Sites: buscar diseños con una imagen
- ✍️ Cómo hacer preguntas que produzcan respuestas útiles
- 💰 Cuánto costó la búsqueda y qué necesitas medir
- 🛠️ Cómo empezaría a construir una primera versión
🧠 Qué es JEV y para qué sirve dentro de una aplicación
JEV es un modelo de inteligencia artificial de TypeSafe pensado para evaluar información y devolver una respuesta que tu programa pueda utilizar directamente. Tú le entregas lo que debe revisar, defines qué necesitas saber y recibes un dato: una categoría, un puntaje o una estimación de si se cumple una condición.
La parte importante viene después. El modelo evalúa; tu código decide qué sigue. Puede ordenar un archivo, enviar una solicitud a cierto equipo, pedir información adicional o permitir que una persona avance al siguiente paso.
Esa forma de usar la IA ya tenía aplicaciones con texto. Por ejemplo, podías entregarle un mensaje de soporte para decidir a qué equipo enviarlo. También podías revisar si una solicitud incluía la información necesaria antes de continuar con el proceso.
En ambos casos, el resultado no necesita convertirse en una conversación. Lo útil es que encaje dentro de un flujo. Si devuelve una categoría, tu programa la usa para clasificar. Si detecta que falta información, tu aplicación puede solicitarla.
Con las imágenes aparece otra posibilidad: aplicar ese mismo patrón a información visual. Muchas veces lo que necesitamos evaluar no está escrito. Está en el encuadre de una foto, en la distribución de una captura de pantalla o en la relación entre dos referencias.
Antes, intentar describir todo eso con palabras podía complicar el proceso. Ahora puedes entregar la imagen junto con la pregunta y los criterios que te interesan. Incluso puedes aportar referencias visuales para comparar. No elimina la necesidad de explicar bien el objetivo, pero sí evita que tengas que traducir primero toda la imagen a una descripción.
👁️ Qué cambia ahora que JEV puede evaluar imágenes
La novedad no es únicamente que el modelo reconozca lo que aparece en una foto. Lo interesante es poder preguntar por una característica visual que tenga consecuencias dentro de tu producto.
No es lo mismo pedir una descripción general de un perfume que preguntar si el frasco aparece completo, incluyendo la tapa y la base. La segunda consulta está mucho más cerca de una decisión que una aplicación necesita tomar.
También puedes comparar imágenes según un objetivo concreto. Quizás no te interesa encontrar dos fotografías con el mismo objeto, sino dos composiciones que dejen espacio para colocar texto. Esa relación visual puede ser más útil para tu trabajo que el nombre del archivo o una categoría general.
Ahora bien, la entrada de imágenes todavía es experimental. Yo lo tomaría como una invitación a probar tus propios casos, no como una garantía de que cualquier evaluación visual va a funcionar bien desde el primer intento.
La pregunta práctica es qué logra resolver con las imágenes que realmente tendrá tu aplicación. Una foto clara puede ser sencilla de evaluar. Una donde el producto aparece pequeño o apenas se distingue su base puede comportarse de otra manera. Necesitas conocer ambos escenarios antes de decidir cuánto vas a automatizar.
🎯 Noul, Choice y Score: tres formas de preguntar
Para empezar conviene entender tres tipos de evaluación. Cada uno responde a una necesidad distinta, y elegir bien el formato ayuda a que el resultado tenga sentido dentro de tu código.
Noul: comprobar si se cumple una condición
Una pregunta de tipo noul sirve para evaluar una condición. Por ejemplo, si un producto aparece completo en una imagen. Devuelve un número entre 0 y 1 que expresa qué tan probable estima el modelo que la respuesta sea afirmativa.
Acá conviene formular algo que puedas comprobar al revisar la foto. La presencia de la tapa y la base de un frasco es un criterio bastante más concreto que decir que la fotografía está bien.
Ese número puede alimentar una regla de tu aplicación. Pero la regla la defines tú, después de probar el comportamiento del modelo. No viene resuelto de antemano qué resultado debe aceptar una imagen o enviarla a revisión.
Choice: elegir entre tus opciones
choice sirve para elegir una opción entre categorías que tú proporcionas. Si quieres clasificar archivos como foto de producto, paisaje o captura de pantalla, puedes entregar esas alternativas y usar la categoría devuelta para organizarlos.
Lo valioso es que las opciones responden a la estructura de tu proyecto. No tienes que conformarte con una descripción libre para luego intentar deducir dónde guardar cada archivo.
Aun así, dejaría una forma sencilla de corregir una clasificación equivocada. La automatización puede ayudarte a ordenar, pero no debería convertir un error en algo difícil de arreglar.
Score: calificar con criterios definidos
score permite calificar usando una escala. La condición es que expliques bien qué representa cada nivel. Un puntaje por sí solo no dice demasiado si no sabes qué está midiendo.
Si utilizas niveles bajos, medios y altos, necesitas describir qué falta en el nivel bajo, qué se cumple parcialmente en el intermedio y qué se considera bien resuelto en el alto. La escala necesita criterios, no solamente números.
La elección depende de lo que quieras hacer después: comprobar una condición, asignar una categoría o comparar grados de cumplimiento. No hace falta pedir una calificación si una pregunta concreta resuelve mejor el problema.
🧴 Una consulta real: comprobar si un perfume aparece completo
Para probarlo usé una imagen de un perfume. El objetivo era sencillo: determinar si el frasco se veía entero. La condición especificaba que debían aparecer tanto la tapa como la base, para evitar que la evaluación quedara demasiado abierta.
Ejecuté la consulta y JEV devolvió 0,95. En esa foto y para esa condición, el modelo estimó una probabilidad alta de que el frasco estuviera completo.
Con eso ya tenemos algo que una aplicación puede utilizar. En una tienda, por ejemplo, el código podría usar la evaluación para aceptar la foto o solicitar una nueva toma. Pero hay una distinción importante: en esta prueba hice la consulta y mostré el resultado. El flujo completo para recibir imágenes de clientes y gestionar su aceptación sería una aplicación que podrías construir a partir de esa base.
También hay que leer correctamente el número. Un resultado de 0,95 no significa que JEV tenga un 95 % de exactitud general. Es una estimación sobre una condición concreta en una imagen concreta. No demuestra cómo se comportará con todas las fotografías ni con cualquier otra pregunta.
Yo continuaría con casos más difíciles:
- Un frasco cortado por el borde de la foto.
- Un producto que aparezca demasiado pequeño.
- Una imagen donde cueste distinguir la base.
Esas pruebas permiten ver en qué situaciones la respuesta tiene sentido y dónde empieza a fallar. Eso sirve mucho más para decidir si puedes incorporarlo a tu aplicación que quedarse solamente con el primer resultado favorable.
Además, ayudan a revisar la propia pregunta. Si tú tampoco puedes decidir con claridad si una foto cumple la condición, quizás necesitas precisar el criterio o aceptar que ese caso termine en revisión.
🔌 Cómo conectar JEV con OpenRouter
En esta prueba utilicé OpenRouter como intermediario para enviar la petición al modelo. Puedes consultar JEV 1.14 en OpenRouter, que es la versión utilizada en el ejemplo.
La estructura tiene dos partes: una pantalla donde seleccionas la imagen y una ruta en el servidor que realiza la llamada. La clave de acceso se queda guardada en el servidor. La interfaz permite iniciar la consulta, pero la llamada al proveedor pasa por esa parte del sistema.
El recorrido completo se puede entender así:
- Seleccionas la foto en la aplicación.
- El servidor prepara la imagen y la consulta.
- La petición se envía a OpenRouter con el modelo elegido.
- El servidor recibe la respuesta.
- La aplicación muestra el dato o lo utiliza para continuar.
Dentro de la estructura de la consulta hay dos campos que conviene reconocer. En state va la información que el modelo tiene que revisar. En questions defines las preguntas y el tipo de respuesta esperado.
Para el perfume, la consulta incluía una pregunta de condición sobre la visibilidad del frasco completo. El servidor la envió, recibió la estimación y la mostró en pantalla. Ese es el recorrido básico que necesitamos comprobar antes de añadir más funciones.
No hace falta comenzar con un sistema enorme. Una pantalla, una imagen, una pregunta y un resultado ya permiten validar la parte esencial. Después puedes construir la lógica que transforma ese dato en una acción útil.
💡 Tres ideas de aplicaciones que salen de esta base
Una vez que funciona ese recorrido, empiezan a aparecer proyectos. Las siguientes son ideas para explorar, no aplicaciones que haya construido en la prueba del perfume. Todas parten del mismo patrón, pero cambian la pregunta y lo que hace el código con la respuesta.
1. Un revisor de fotos para una tienda
En lugar de preguntar de forma general si una foto sirve, puedes separar la revisión en criterios: si el producto se ve completo, si hay objetos que compiten con él y si el fondo cumple las condiciones de la tienda.
Después, tu aplicación podría mostrar qué fotos requieren atención y qué criterio necesita revisarse en cada una. Eso es mucho más útil que devolver una aprobación o un rechazo sin contexto.
Si el problema es el encuadre, la persona sabe que debe repetir la toma. Si es el fondo, sabe qué aspecto necesita corregir. El resultado de la evaluación se convierte así en una indicación práctica.
2. Un organizador de referencias visuales
Uno guarda capturas, fotos e ideas para una web, y después cuesta encontrar lo que estaba buscando. Puedes definir tus categorías y utilizar choice para clasificar esos archivos, manteniendo una opción de corrección manual.
También puedes ir más allá de las categorías. Una referencia puede servir para buscar otras imágenes que compartan una característica concreta, como una distribución que deje espacio libre para texto.
Ahí la búsqueda empieza a depender de lo que se ve y de lo que necesitas conseguir. No solamente del nombre que le pusiste al archivo cuando lo guardaste, que muchas veces no describe lo que ahora te interesa encontrar.
3. Una aplicación de retos con la cámara
Otra posibilidad es pedir que se fotografíe un objeto de cierto color o categoría. La aplicación recibe la imagen, el modelo evalúa si cumple la consigna y tu código decide si desbloquea el siguiente reto.
En este caso, la cámara se convierte en una forma de interactuar con la aplicación. La foto no se guarda únicamente como contenido: funciona como entrada para evaluar una condición.
También acá dejaría una salida para los resultados dudosos. Repetir la foto puede ser mejor que bloquear el avance por una evaluación que no está clara. La experiencia no tiene por qué depender de que el modelo acierte siempre.
📍 Box: localizar un objeto no es comprobar su presencia
En la documentación de TypeSafe también aparece box, una función para localizar un elemento dentro de una imagen. Devuelve las coordenadas de un rectángulo alrededor del objeto, que podrías utilizar para destacarlo o preparar un recorte.
No la ejecuté en estas pruebas, pero merece la pena conocerla. Hay proyectos donde saber que algo aparece no basta: también necesitas saber dónde está.
El detalle importante es que Box siempre devuelve un rectángulo. Por lo tanto, obtener coordenadas no demuestra por sí mismo que el objeto buscado esté presente. También necesitas comprobar esa presencia.
Son dos preguntas diferentes: si el elemento existe en la imagen y dónde se encuentra. Si tu aplicación necesita ambas respuestas, no conviene tratar la localización como si resolviera automáticamente la primera.
🏡 Mi prueba en Dínamo Sites: buscar diseños con una imagen
En mi caso, lo que más me interesaba era partir de una referencia visual y encontrar algo que me sirviera para trabajar. Por eso preparé un buscador para el catálogo de Dínamo Sites.
El prototipo permite escribir una idea, subir una imagen o combinar ambas entradas para encontrar diseños que podrían encajar. En la prueba subí la foto de una casa, sin agregar texto y manteniendo el encuadre completo.
La primera sugerencia fue Surco. Me hizo sentido por una relación concreta de composición: la arquitectura tenía más peso hacia la derecha y quedaba espacio abajo, a la izquierda, para colocar los textos. Además, compartía el tono cálido de la referencia.
En esa ejecución, el buscador comparó la referencia con 97 diseños y tardó 2,5 segundos. Para mí, el valor está en tener una primera opción que puedo abrir y revisar sin recorrer todo el catálogo.
Hay algo que quiero dejar claro: JEV no creó esa web ni reemplazó sus fotografías. La vista previa seguía mostrando el diseño original. Lo utilizamos para decidir qué opción convenía mirar primero.
Después sigue siendo necesario abrir la sección y revisar cómo se mueve, cómo se comporta y qué detalles no aparecen en una captura estática. La búsqueda ayuda a elegir un punto de partida; no reemplaza esa revisión.
También dejamos visibles los puntajes de composición, estilo y afinidad. Sirven para comparar las opciones de esa búsqueda y entender mejor sus diferencias. No los tomaría como una declaración universal sobre cuál diseño es mejor, sino como apoyo para el objetivo de esa consulta.
Esta misma lógica puede aplicarse a fotos, referencias o recursos propios. Tú defines qué te interesa comparar y para qué utilizarás el resultado. La utilidad no está solamente en encontrar semejanzas, sino en encontrar las que te permiten avanzar.
El buscador visual está en desarrollo y se prueba en local. Todavía no está disponible públicamente. Mientras sigo afinándolo, puedes explorar los diseños actuales y registrarte gratis en Dínamo Sites. Si activas las novedades, podrás recibir el aviso cuando esté listo.
✍️ Cómo hacer preguntas que produzcan respuestas útiles
La pregunta importa mucho. Decir que una imagen está buena deja demasiadas cosas abiertas. ¿Buena para qué? ¿Para mostrar un producto, para servir como fondo o para colocar un título encima?
En cambio, preguntar si el producto aparece completo o si queda espacio libre a un lado permite revisar la imagen y comprobar si la respuesta tiene sentido. Una buena pregunta conecta un criterio visible con una necesidad de tu aplicación.
Yo trabajaría con estas tres reglas:
- Pregunta por algo concreto. El encuadre o la presencia del producto son más comprobables que una valoración general.
- Separa los criterios. Si te importan el fondo, el encuadre y la presencia de otros objetos, evalúalos por separado.
- Define qué harás con cada respuesta. El dato debe servir para clasificar, comparar, pedir otra imagen o continuar el proceso.
Separar los criterios también facilita corregir problemas. Si juntas todo en una sola evaluación, puedes recibir un resultado que no explica qué falló. Con preguntas distintas, tu código puede combinar las respuestas y conservar la información que necesita para orientar a la persona.
Puedes enviar varias preguntas en una misma petición. Eso no significa que dejen de tener costo, pero evita tener que realizar una llamada diferente por cada una.
Y deja una salida cuando el resultado sea dudoso. Puede ser pedir otra foto o enviar el caso a revisión. Tu aplicación no tiene que resolverlo todo automáticamente para resultar útil.
De hecho, una función que identifica los casos claros y aparta los ambiguos puede encajar mejor en el flujo que una que obliga a aceptar o rechazar cada imagen. La decisión sobre cuánto automatizar viene de las pruebas, no de la primera respuesta del modelo.
💰 Cuánto costó la búsqueda y qué necesitas medir
En el prototipo del buscador medimos aproximadamente 0,006 dólares por una búsqueda completa al catálogo. Mil búsquedas parecidas rondarían los seis dólares, contando solamente las llamadas al modelo.
La precisión de esa frase importa: hablamos de nuestra búsqueda por los diseños. Una consulta con una foto y una pregunta es una operación distinta. No usaría esa cifra como tarifa general para cualquier aplicación con JEV.
Cuando hagas tu prueba, mide cuánto consume tu propio caso y establece un límite de uso. La cifra que necesitas conocer es la de la operación que realmente vas a ofrecer, con sus imágenes y sus preguntas.
También puedes conservar la imagen original y enviar una copia más liviana, siempre que mantenga los detalles necesarios para evaluar el criterio. Si necesitas distinguir la base de un frasco, reducir la imagen hasta que deje de verse no ayuda.
La idea es equilibrar el tamaño del archivo con la información que necesitas conservar. Después vuelves a probar y compruebas si la evaluación sigue teniendo sentido. Optimizar no debería significar quitar justo la evidencia visual sobre la que estás preguntando.
🛠️ Cómo empezaría a construir una primera versión
Yo no empezaría intentando resolver todas las ideas al mismo tiempo. Elegiría una sola condición, como hice con el frasco de perfume, y comprobaría el recorrido completo antes de ampliar el proyecto.
- Define una necesidad concreta. Por ejemplo, comprobar si un producto aparece entero.
- Elige el tipo de respuesta. Una condición, una categoría o una escala, según lo que necesite tu código.
- Conecta la consulta desde el servidor. Mantén allí la clave y devuelve el resultado a la interfaz.
- Prueba casos claros y difíciles. No te quedes solamente con la imagen donde todo funciona.
- Decide la acción posterior. Aceptar, clasificar, mostrar opciones, pedir otra foto o revisar.
- Mide el consumo y limita el uso. Evalúa el costo de tu operación real.
Con eso ya tienes una base para decidir si vale la pena seguir. Si necesitas recursos para preparar tu proyecto, en Primera App tienes prompts profesionales para crear tu aplicación. Y si también estás resolviendo dónde alojar tu web, te dejo mi enlace de descuento de Hostinger.
Para acceder a los prompts de la comunidad y compartir lo que estás construyendo, puedes sumarte a Círculo Builders. Intercambiar pruebas y proyectos ayuda a aterrizar estas posibilidades en problemas concretos.
Para mí, lo más interesante de JEV con imágenes no es pedirle que opine sobre cualquier foto. Es darle una tarea bien definida y conectar su respuesta con algo útil. A veces será revisar un encuadre. Otras, ordenar referencias. En mi caso, encontrar un diseño que tenga sentido como punto de partida.
Empieza con una imagen y una pregunta que puedas comprobar. Prueba dónde funciona, identifica dónde duda y construye la acción que viene después. Ahí es donde una capacidad del modelo empieza a convertirse en una función de tu aplicación.
Aviso: este artículo puede incluir enlaces promocionales. Si realizas una compra, puedo recibir una comisión sin costo adicional para ti.
