24 de setiembre de 2026
La mayoría de los modelos de IA que usamos a diario están diseñados para escribir. Jev, de TypeSafe AI, está diseñado para decidir — recibe un estado de datos y una pregunta estructurada, y devuelve una opción tipada, una probabilidad y un nivel de confianza. Nada de prosa.
Qué es exactamente un “System One model”
TypeSafe AI llama a Jev un modelo “System One”, en referencia a la distinción de pensamiento rápido vs. lento: no razona en lenguaje natural paso a paso, sino que evalúa un estado dado contra opciones predefinidas y responde de inmediato. La propia empresa lo describe como una llamada a función de inteligencia de frontera: entra estado sin estructurar, sale una decisión probabilística tipada.
Cómo funciona técnicamente
Tres piezas lo hacen posible: una arquitectura de modelo distinta a la de un LLM generativo, un “parallel sampler” que genera todas las opciones de respuesta en una sola consulta en vez de token por token, y un método de entrenamiento llamado RLCD (Reinforcement Learning for Calibrated Decisions) enfocado en calibrar qué tan confiable es cada decisión, no solo en acertar.
El resultado: respuestas en 70-500 milisegundos, frente a los 3-30 segundos típicos de un LLM generativo resolviendo la misma clasificación con una instrucción larga — TypeSafe reporta hasta 200 veces más velocidad y 400 veces menos costo que un LLM de frontera comparable en tareas de clasificación.
Probabilidad de opción vs. confianza global
Son dos números distintos y confundirlos lleva a interpretar mal el resultado. La probabilidad es específica de cada opción — qué tan probable es “pillar” frente a “secundaria” frente a “descartar” para una keyword dada. La confianza global es una medida calibrada de qué tan fiable es la decisión completa — Jev está entrenado para que una confianza alta se corresponda con una tasa de acierto real más alta, no solo con un número inflado.
Por qué no reemplaza a un embedding vectorial
Un embedding vectorial representa el significado semántico de un texto como una posición en un espacio de muchas dimensiones — útil para medir similitud entre dos keywords o detectar solapamiento temático. Jev no genera esa representación: consume datos ya estructurados (incluyendo, si hace falta, resultados de similitud calculados por embeddings) y decide qué hacer con ellos. Son capas distintas de un mismo sistema, no alternativas entre sí.
Aplicación práctica: filtrar antes de gastar créditos de API
Esto conecta directo con un problema real de cualquier sistema SEO que ya delega tareas a agentes de IA: gestionar los límites de una API de datos de keywords sin quemar el presupuesto en solicitudes que no valían la pena. Si tu sistema consulta una API como DataForSEO para una palabra con miles de variantes, el costo no está en pedir muchos resultados por solicitud — el límite (limit) ya tope esa cantidad — sino en gastar solicitudes completas en keywords que ni siquiera merecían evaluarse.
Ahí es donde una decisión tipada como la de Jev sirve de filtro previo: clasificar cada keyword candidata como pillar, secundaria, independiente o descartar antes de decidir si vale la pena investigarla a fondo con una llamada de datos más cara.
Ejemplo de código con AI SDK
import { experimental_evaluate as evaluate } from "ai";
const result = await evaluate({
model: "typesafe-ai/jev",
state: {
keyword: "padel lima",
searchVolume: 1900,
intent: "local",
serpOverlap: 0.72,
existingArticles: 12
},
questions: {
contentType: {
type: "choice",
instructions: "Clasifica el tipo editorial recomendado para esta keyword.",
criteria: {
pillar: "Debe ser una página principal que cubra un tema amplio y soporte contenidos secundarios.",
secondary: "Debe ser un contenido específico que dependa de una página principal.",
independent: "Debe tratarse como contenido independiente sin dependencia clara de un cluster.",
discard: "No es relevante o no aporta valor editorial."
}
},
cannibalizationRisk: {
type: "score",
instructions: "Evalúa el riesgo de canibalización con el inventario editorial existente.",
criteria: [
"Riesgo bajo: no existe una intención ni cobertura similar.",
"Riesgo medio: existe coincidencia parcial.",
"Riesgo alto: existe una página con intención y cobertura prácticamente iguales."
]
}
}
});
console.log(result.answers);
serpOverlap (0.72 en el ejemplo) es el dato que normalmente vendría de comparar embeddings de tu contenido existente contra la SERP de la keyword — Jev no lo calcula, lo recibe ya calculado y decide con base en él.
Qué preguntas SEO puede resolver este tipo de modelo
Más allá del ejemplo de tipo de contenido, el mismo patrón sirve para preguntas repetitivas que hoy se resuelven a mano o con reglas rígidas: si una keyword se mantiene, se revisa o se descarta del plan editorial; si el riesgo de canibalización es bajo, medio o alto frente al inventario existente; o si la intención de búsqueda es informativa, local, comercial o transaccional. Cada una es una decisión tipada, no un texto que alguien tenga que leer e interpretar.
Cómo incorporamos Jev a nuestro motor editorial SEO
Actualmente, nuestro motor de redacción SEO combina datos de búsqueda, análisis de SERP, filtros deterministas y señales semánticas para decidir qué temas tienen sentido dentro del calendario editorial. Jev nos ayuda a resolver los casos ambiguos: interpreta esas señales y devuelve una decisión estructurada sobre la relevancia, el tipo de contenido y el posible riesgo de solapamiento.
Jev se ubica entre los filtros deterministas y la política editorial: decide, pero no redacta.
De esta manera, reservamos modelos generativos más costosos, como DeepSeek o Gemini, para tareas que realmente requieren razonamiento y redacción. Al usar Jev solo como capa de decisión y no para generar textos completos, reducimos el consumo, mantenemos el proceso más controlable y podemos escalar el análisis SEO con un costo menor.
Qué evaluar antes de sumarlo a un sistema propio
- TypeSafe reporta un costo de $0.042 por millón de tokens de entrada — barato para volumen alto, pero conviene medir el costo real contra tu propio patrón de uso antes de asumir el ahorro.
- No sustituye la búsqueda semántica ni el análisis de canibalización que ya hagas con embeddings — se apoya en esos datos, no los reemplaza.
- Está pensado para decisiones repetitivas con opciones bien definidas de antemano. Si el criterio de decisión cambia constantemente, un modelo generativo con instrucciones flexibles puede seguir siendo la opción más práctica.






