AI Sources
De primera manoIAVídeo··10 min de lectura

Jev: el modelo diseñado para ser llamado por código, no por humanos

Diogo Almeida, ex-OpenAI, explica por qué creó una nueva clase de modelos «system one» — y por qué rechaza los benchmarks públicos, los refusals y el preentrenamiento.

Fuente : Latent Space · YouTubeVer el original

En breve

En una entrevista de más de dos horas en el estudio Latent Space, el fundador de TypeSafe detalla la tesis detrás de Jev: un modelo cuyo consumidor es el código, optimizado para la «inteligencia por dólar», sin cadena de razonamiento ni refusals. De paso, desmonta el RLHF, los benchmarks públicos y el debate sobre el «pacing» del frontier, y cuenta por qué dejó OpenAI tras impulsar InstructGPT.

🍺 Versión de barra

Desde hace tres años todo el mundo te explica que la IA será tu compañero de oficina. Él piensa que es un error de casting: la IA no es un becario, es una base de datos bastante hábil a la que llamas un millón de veces al día desde un bucle. De ahí un modelo que no conversa, no rechaza nada, no razona en voz alta, y solo devuelve tres cosas: un booleano difuso, un score, una elección. Si esto funciona, la revolución de la IA no llegará en forma de chatbot genial sino de software aburrido que, de repente, por fin toma solo las decisiones correctas.

Para recordar

  1. 1

    Jev pertenece a una clase de modelos que TypeSafe llama «system one», «machine native» o «large programmable»: el consumidor de la salida es código, no un humano.

  2. 2

    Solo tres primitivas — nule (derivado de Bernoulli), score y choice — que corresponden a un if, a un ordenamiento o umbral, y a un switch sobre enum.

  3. 3

    El modelo está optimizado para la «inteligencia por dólar» (de ahí el nombre, en referencia a la paradoja de Jevons), no para la velocidad ni para los rankings.

  4. 4

    Almeida se declara «extremadamente anti-benchmarks públicos»: demasiado fáciles de manipular, deberían dar paso a evaluaciones internas de los desarrolladores sobre sus propios workflows.

  5. 5

    Ningún refusal en la API: «refusal is obviously a type error» — un refusal aleatorio en una dependencia que corre en segundo plano rompe el software.

  6. 6

    Los datos son enteramente sintéticos y la empresa rechaza entrenar con los de los usuarios, para no sobreajustar al presente.

  7. 7

    Cifras citadas: más de 1.000 mil millones de tokens al día procesados, incluso de noche, 100.000 personas en el Discord, y casi ningún ingreso antes del lanzamiento.

Capítulos

0:00

Cold open: el enigma de la automatización

¿Cómo es que una IA capaz de resolver problemas matemáticos de alto nivel todavía no automatiza las tareas más básicas? El motor de automatización existe, faltan los enchufes.

1:32

Semana de lanzamiento: «never been worse»

Estado de ánimo del fundador tras un lanzamiento que saturó la timeline, y elección de priorizar los town halls de Discord sobre las citas con inversores.

4:27

¿Qué es Jev?

Definición de la nueva clase de modelos: system one, machine native, large programmable, con el código como consumidor y la inteligencia por dólar como métrica.

7:23

RLHF, mode collapse y la diapo de LeCun

El mode dropping del RLHF explica por qué la acumulación de errores predicha por LeCun no se verifica — al precio de una calibración destruida.

12:57

Por qué Jev nunca rechaza

El refusal como error de tipado en una API; distinción entre alineamiento de capacidad y alineamiento de seguridad; la inteligencia como base de datos en lugar de compañero.

19:30

Anti-benchmarks públicos

Por qué los benchmarks públicos son ingobernables y manipulables, y qué debería reemplazarlos: vibes, confianza, y luego evaluación en el workflow real.

22:03

La «bitterest lesson»: los datos primero

El dato importa más que el compute, RLCD como nueva north star, y la obsesión por contratar «data people».

42:45

Determinismo contra robustez

Sin seed por ahora: la buena propiedad sería la robustez, probada inyectando UUIDs en los prompts.

49:40

Versiones de modelos y LTS

Compromiso de no modificar un modelo desplegado, ausencia de promesa de soporte a largo plazo, e hipótesis de un LTS sobre Jev 1.13.0.

55:29

Diseño de la API: nule, score, choice

Origen de los nombres, rechazo de los tipos existentes, y correspondencia con if, umbral y switch sobre enum.

1:00:39

Cómo estructurar tus requests

Descomponer hasta la unidad semántica mínima, pasar JSON estructurado en lugar de plantillas, plantear muchas preguntas en paralelo.

1:16:00

System 1 contra system 2

Por qué los LLM preentrenados son fundamentalmente pensadores system one, y lo que aportó el RLVR — con su fragilidad fractal.

1:31:37

Antes del lanzamiento: más de la mitad no entendía

Repaso de una fase de validación decepcionante, la falta de ingresos y el cuestionamiento de la noción de product-market fit.

1:36:13

Familias de usos y coding agents

Dark data, tiempo real, verificación, smart software — y la crítica a la «tiranía del KV cache» en los agentes de código.

1:43:16

El debate sobre la ralentización del frontier

La declaración conjunta de los labs presupone, según él, que siempre hace falta más RLVR; una hipótesis que considera no universal.

1:57:49

De InstructGPT a la salida de OpenAI

La lucha por desplegar InstructGPT, el documento enviado a Sam Altman, y la creación de TypeSafe con Eric y luego Sasha.

2:09:50

Los proyectos que ofrece a los demás

Videojuegos inteligentes y una reinvención de los coding agents liberados del KV cache: dos direcciones que le gustaría ver explorar por otros.

Una nueva clase de modelos: el código como cliente

El punto de partida es una oposición de tareas. El preentrenamiento optimiza el autocompletado de Internet, el RLHF optimiza la respuesta a un humano, el RLVR optimiza salidas verificables. TypeSafe reivindica un cuarto objetivo, llamado RLCD: producir salidas consumidas directamente por código. De ahí el nombre de la empresa, TypeSafe.

Concretamente, Jev no escribe texto libre. Expone tres primitivas: nule (derivado de la probabilidad de Bernoulli, un booleano continuo), score y choice. Almeida las describe como tipos deliberadamente nuevos, que no se confunden con un bool, un int o un function call.

La correspondencia con el código es explícita: un nule alimenta un if, un score un ordenamiento o umbral, un choice un switch sobre un enum. «Habrá otros tipos, y corresponderán a primitivas de programación», anuncia.

El nombre Jev viene de la paradoja de Jevons. La marca interna es clara: Jev designa la familia de modelos que se mantiene en la frontera de la inteligencia por dólar. No la más inteligente en absoluto — la más inteligente a un precio dado.

El juicio al RLHF: mode collapse y calibración

Es la parte más técnica de la entrevista, y viene de alguien que trabajó en InstructGPT. Según Almeida, nadie ha mirado los efectos secundarios del RLHF, en particular el mode dropping: el modelo abandona los modos minoritarios de la distribución para producir solo lo más seguro.

Lo usa para explicar una paradoja conocida. La famosa diapositiva de Yann LeCun sobre la acumulación de errores con la longitud de secuencia es, dice, «matemáticamente evidente pero manifiestamente falsa» empíricamente. Razón invocada: para no descarrilar en cadenas largas, los modelos RLHF se vuelven ultraconservadores y pierden su calibración.

Esta calibración rota es, para él, «un veneno» en las distribuciones de probabilidad sobre cadenas de caracteres — y la razón por la que se toman malas decisiones al sobrecargar modelos de texto.

Considera a LeCun uno de los comentaristas más acertados del campo, aunque se niega a pronunciarse sobre JEPA: «investigación temprana muy bonita», pero todavía no pragmática a sus ojos.

Ni refusals, ni benchmarks: la doctrina de plataforma

Sobre la seguridad, la posición es tajante. Almeida no se opone a la seguridad como principio, pero considera que el safety alignment está desalineado con los usuarios de una API. Un refusal es «un type error»: aceptable en un producto de consumo, absurdo en una dependencia que corre en segundo plano.

Su analogía vuelve varias veces: «la inteligencia se parecerá más a una base de datos que a un compañero de trabajo». Y no le corresponde al motor de base de datos juzgar el uso posterior. Sobre el uso militar, concede una preferencia personal, pero se niega a inscribirla en la capa tecnológica, alegando que cada sobreajuste «fractura la inteligencia».

Misma lógica para los benchmarks públicos. Recuerda que cada laboratorio tenía antes un equipo dedicado a recopilar datos parecidos a MMLU. Su conclusión: «a largo plazo, hacen falta vibes y confianza», y luego una evaluación en el workflow real. Internamente, las evals existen — la disciplina consiste en no manipularlas.

El coste de esta postura fue real: en la ronda anterior, nadie les creía por falta de cifras que mostrar. Dice haberse mantenido firme por principio. También se declara «anti-demos», incluso para las demos halagadoras de su comunidad.

Fiabilidad, versiones, GPU: las promesas hechas a los desarrolladores

Sin seed, sin determinismo por ahora. Considera el determinismo interesante para tests unitarios, pero estima que la propiedad realmente deseable es la robustez: entradas semánticamente idénticas, salidas similares. Su test interno consiste en inyectar UUIDs en los prompts y verificar la estabilidad de las respuestas.

Sobre las versiones, el compromiso es claro: «no modificaremos nuestros modelos después del despliegue». En cambio, ninguna promesa de soporte a largo plazo — cuentan con iterar mucho más rápido que los proveedores habituales, con la hipótesis de un LTS temporal sobre la versión muy usada, Jev 1.13.0.

El contexto es el de una escasez duradera de GPU. Es también el argumento económico de su posicionamiento: menos inteligencia por dólar significa más GPU para el mismo resultado. El objetivo declarado no es incorporar grandes cuentas sino poner la herramienta en el máximo de manos posible.

El fine-tuning no está excluido, pero no está previsto: teme el efecto escopeta y prefiere apostar por la calibración y por cascadas de modelos de distintos tamaños.

Cómo usarlo, según su autor

Su consejo principal se resume en una palabra: descomponer. Plantear muchas preguntas pequeñas e independientes en lugar de una grande, hasta la unidad semántica más fina. El ejemplo que da: no preguntar «¿debo rechazar aquí?», sino interrogar por separado cada posible situación de refusal.

La ventaja es de ingeniería de software. Cada pregunta se vuelve medible, cada bug se corrige añadiendo una pregunta o ajustando un umbral, y el caso se convierte en un test permanente, a salvo del context rot. Resume: «es machine learning sin machine learning».

Segundo consejo: dejar de meter todo en cadenas de texto. El state, las instrucciones y los criterios aceptan JSON estructurado. Los system messages se describen como «asquerosas variables globales» donde se apila todo esperando que cada instrucción pase.

En cuanto a usos, clasifica cuatro grandes familias: los dark data que las empresas no se atrevían a pasar por un LLM por razones de coste, los coding agents, el tiempo real y los asistentes, y la verificación sistemática de las llamadas a LLM. El computer use, por su parte, llegó por sorpresa.

OpenAI, el invierno de la IA y el debate sobre el «pacing»

La parte biográfica ilumina el resto. Almeida cuenta que se peleó para desplegar InstructGPT, con un algoritmo no publicado escrito por él, y luego constató que el resultado servía sobre todo para copywriting. De ahí su pregunta: ¿qué falta entre «muy inteligente» y «crea valor»?

Su respuesta: en una revolución económica impulsada por la IA, la inmensa mayoría de las llamadas vendrán del código, no de humanos — y toda la optimización iba dirigida a los humanos. Dice haber escrito un documento, hablado de ello con Sam Altman, quien le aconsejó lanzarse, supuso que Anthropic ya lo estaba haciendo, y finalmente montó TypeSafe con Eric y luego Sasha.

Su motor declarado es el miedo a un invierno de la IA del que se sentiría personalmente responsable, tanto por la dirección RLHF como por no haberlo apostado todo a esa dirección. Su objetivo no es una puntuación sino una cifra macro: 3% de crecimiento de la productividad total de los factores en cinco años.

Sobre la declaración conjunta de los labs a favor de una ralentización, habla de un truco de manos: presupone que todos deben hacer siempre más RLVR dejando que los modelos actúen libremente. Para su forma de modelo, «cero es la cantidad óptima». El host añade otra lectura, más prosaica: posicionamiento político con vistas a 2028.

Refusal is just like obviously a type error.
I think intelligence will be more like a database than a coworker.
If you gave me a billion dollars I wouldn't pre-train.

Por qué importa

Desde hace tres años, el consenso de producto en IA se resume en una palabra: el agente, o el compañero digital. Almeida propone justo lo contrario — una inteligencia banalizada, invisible, llamada por programas, facturada como una consulta a base de datos y juzgada por su fiabilidad más que por su inteligencia bruta. Es una tesis coherente, argumentada técnicamente, y tiene el mérito de explicar un hecho incómodo: el software de 2026 todavía se parece al de 2019, con un chatbox lateral de más. Queda una tensión que no hay que borrar. Rechazar los benchmarks públicos, las demos y el determinismo en nombre de la pureza de ingeniería también hace que las afirmaciones de la empresa sean invérifiables desde fuera, justo en el momento en que «inteligencia por dólar» se convierte en un argumento comercial. La promesa de no modificar nunca un modelo desplegado, en cambio, es comprometedora: ahí es donde habrá que cumplirla.

#ia#llm#api#openai#startup#desarrollo
Fuente original
Why We Made Jev — Diogo Almeida, TypeSafe Co-founder & CEO
Latent Space
Abrir el vídeo

Sigue leyendo