Jev de TypeSafe procesa 1 billón de tokens diarios mientras su fundador rechaza benchmarks, negativas y el RLHF a favor de una nueva categoría de IA
Una entrevista durante la semana de lanzamiento revela la filosofía técnica y las apuestas de negocio detrás de los modelos de IA de "sistema uno", orientados a las máquinas en lugar de a los chatbots
TypeSafe, la startup de inteligencia artificial fundada por el ex investigador de OpenAI Diogo, aprovechó el lanzamiento de su nueva línea de modelos, Jev, para introducir lo que denomina una categoría completamente nueva de inteligencia artificial: "modelos de sistema uno", diseñados para ser consumidos por código en lugar de por humanos. En una extensa entrevista concedida durante la semana de lanzamiento, Diogo expuso una serie de posturas inusualmente directas sobre los benchmarks, la alineación de seguridad, el fine-tuning y el estado actual de la investigación en IA de frontera, que los inversores que siguen de cerca el sector querrán comprender, independientemente de si deciden respaldar a la compañía.
Una nueva categoría de modelos, diseñada para máquinas y no para chatbots
La tesis central de TypeSafe es que toda la industria ha estado optimizando los modelos de lenguaje grande para el consumidor equivocado. Los modelos preentrenados se crearon para el autocompletado, los chatbots ajustados mediante RLHF como ChatGPT y Claude se diseñaron para satisfacer a los evaluadores humanos, y los modelos de razonamiento optimizados con RLVR se construyeron para resolver problemas evaluables mediante benchmarks. Jev, argumenta Diogo, es el primer modelo construido explícitamente para que "el código sea el consumidor". Lo describió como "nativo para máquinas, grande y programable", y señaló que el nombre —una referencia a la paradoja de Jevons— refleja el enfoque singular de la empresa en la inteligencia por dólar. "Jev será el nombre de los modelos que estén en la frontera de la inteligencia por dólar", afirmó, y añadió que la fiabilidad, el costo, la calibración y la velocidad están en tensión, y que TypeSafe ha decidido apostar "a fondo" específicamente por el eje de la inteligencia por dólar.
La compañía enmarca esto como la solución a lo que Diogo llama la paradoja central del momento actual de la IA: los modelos capaces de abordar problemas matemáticos dignos de un premio del milenio aún no pueden automatizar el trabajo de conocimiento básico y repetitivo. "Tenemos este motor sobrealimentado de automatización que simplemente no tiene los conectores adecuados para integrarse en todo este trabajo de valor económico", señaló, argumentando que la brecha no es un problema de capacidad, sino de diseño y de interfaz.
Cifras de adopción que superan las expectativas de la propia empresa
Quizás el dato más concreto de la entrevista: Jev ya ha superado el billón de tokens procesados al día, una cifra que Diogo enfatizó refleja un uso genuino de máquina a máquina que se ejecuta de forma continua, "incluso por la noche", en lugar de pruebas humanas puntuales. El video de lanzamiento ha alcanzado 38 millones de vistas, lo que, según señaló el coanfitrión de Diogo, lo sitúa por delante de los momentos clave de la conferencia magistral de Jensen Huang en Nvidia (74 millones en total) en una base semanal, y por delante de otros grandes lanzamientos tecnológicos recientes como la demo de Fable (57 millones).
Dicho esto, Diogo fue sincero al admitir que la compañía no estaba preparada para la acogida. Dijo que, antes del lanzamiento, "más de la mitad de las personas que probaron [el modelo] simplemente no lo entendieron", y que el área no técnica de la empresa temía estar "vendiendo una vitamina y no un analgésico". TypeSafe casi no tenía ingresos antes de esta semana. Asimismo, rechazó la idea de que el lanzamiento reflejara una gran habilidad en marketing: "No tenemos un especialista en marketing, y por cierto, estamos contratando", apuntó, agregando que las inscripciones en la lista de espera son una métrica de vanidad que la empresa ha aprendido a ignorar en gran medida; la verdadera señal, indicó, es la agresividad con la que los usuarios piden límites de tasa más altos una vez que experimentan el producto, ya que eso indica una dependencia genuina y no simple curiosidad.
Sin benchmarks públicos, por diseño
TypeSafe ha adoptado una postura inusualmente adversarial hacia la señal de credibilidad estándar de la industria: los benchmarks públicos. Diogo afirmó que la empresa es "extremadamente anti-benchmark público" y que solo apoya con un nivel "medio" los benchmarks privados utilizados como referencias internas, argumentando que los benchmarks públicos se manipulan trivialmente incluso por laboratorios que no tienen la intención de hacerlo. "En el pasado, cada laboratorio tenía un equipo para recopilar datos que se parecían a MMLU para mejorar su apariencia, lo cual no es más que hacer benchmarks con pasos adicionales", comentó. En su lugar, TypeSafe apuesta a que la confianza en la inteligencia del modelo se establecerá a través de lo que denominó "vibes" —fiabilidad en el mundo real demostrada dentro de flujos de trabajo reales— en lugar de la posición en las tablas de clasificación. Reconoció que la compañía mantiene evaluaciones internas, pero señaló que protegerse contra la manipulación de dichas evaluaciones es "una de las cosas más importantes" que el equipo aplica internamente, dado lo fácil que es que los incentivos corrompan la medición.
Las negativas son "un error de tipo", no una característica de seguridad
Una de las posturas más provocadoras de Diogo fue su rechazo a las negativas al estilo de la alineación de seguridad dentro de un producto API, distinguiéndolas claramente de los productos de chat para consumidores como ChatGPT o Claude, donde afirma que tales salvaguardas tienen sentido. En el contexto de una API, argumentó, una negativa rompe el software de forma no determinista e impredecible. "Si estás chateando con un bot y se produce una negativa, es molesto, pero puedes lidiar con ello", expresó. "Si se trata de una dependencia que se ejecuta en segundo plano, ¿qué pasa si eso se niega? Eso es pura locura". Tuvo cuidado de señalar que esto no es una objeción general a la seguridad como concepto, sino la convicción de que la alineación de capacidades (hacer que los modelos sigan las instrucciones de los desarrolladores con precisión) y la alineación de seguridad (hacer que los modelos sigan las preferencias de otra persona, como las de la plataforma) son problemas fundamentalmente distintos que no deben confundirse a nivel de modelo. Ante la delicada cuestión del uso de modelos en conflictos bélicos, indicó que personalmente preferiría que la tecnología no se utilizara para hacer daño a las personas, pero declinó incorporar esa preferencia en el propio modelo, argumentando que hacerlo "fractura" la inteligencia general del mismo.
Un nuevo paradigma de postentrenamiento que la compañía denomina RLCD
Diogo, quien trabajó en el esfuerzo de InstructGPT basado en RLHF en OpenAI —el predecesor del comportamiento de seguimiento de instrucciones de ChatGPT—, sostuvo que la industria solo ha logrado establecer dos o tres "estrellas del norte" de entrenamiento genuinamente nuevas en la historia de los modelos de lenguaje grande: el RLHF (optimización para la preferencia humana y el seguimiento de instrucciones) y el RLVR (optimización para el razonamiento verificable mediante benchmarks). TypeSafe propone una tercera vía, que internamente denomina RLCD, orientada hacia la fiabilidad programática en lugar de complacer a un evaluador humano o resolver un acertijo verificable. Cabe destacar que la empresa todavía no ha publicado un documento técnico que describa la técnica. Diogo también aprovechó la entrevista para explicar por qué cree que los modelos de chat ajustados mediante RLHF son estructuralmente propensos a la adulación, el exceso de confianza y las alucinaciones; describió esto como una consecuencia de la "pérdida de modos" (mode dropping), en la que los modelos se vuelven hiperconfiados para evitar ser penalizados por matizar sus respuestas, distorsionando así sus distribuciones de probabilidad subyacentes. Relacionó esto con la conocida crítica de Yann LeCun de que los modelos autorregresivos están condenados a acumular errores en secuencias largas, calificando a LeCun como "uno de los pensadores más precisos" en IA, aunque argumentó que el mecanismo subyacente es el colapso de calibración derivado del RLHF y no un defecto inherente en la generación token por token.
Escepticismo ante el consenso de seguridad de la industria sobre "marcar el ritmo de la frontera"
Al ser consultado sobre el creciente acuerdo entre los laboratorios de frontera en torno a ralentizar el progreso de las capacidades de IA por razones de seguridad, Diogo ofreció una réplica incisiva, argumentando que dicho enfoque asume que todos los laboratorios deben seguir escalando el RLVR para mantenerse competitivos, una premisa que rechaza para la propia familia de modelos de TypeSafe. "Es evidente que no creo que necesite hacer más RLVR en nuestros modelos", afirmó. "Considero que cero es la cantidad óptima para nuestra estructura". Calificó el debate de la industria sobre la regulación del ritmo como "un poco de juego de manos", sugiriendo que los laboratorios que otorgan a los modelos una autonomía amplia y sin restricciones durante el entrenamiento para maximizar sus capacidades son también los que luego citan el riesgo resultante como justificación para desaceleraciones coordinadas, sin reconocer que existen diseños de modelos alternativos. Por otro lado, señaló sin entrar en detalles que algunas de estas conversaciones sobre seguridad están moldeadas por consideraciones políticas vinculadas a las próximas elecciones, más que por evaluaciones de riesgos puramente técnicas.
Los agentes de código podrían transformarse mediante arquitecturas de múltiples modelos
Diogo señaló al mercado de agentes de código —liderado actualmente por Claude Code de Anthropic y Codex de OpenAI— como un área en la que el enfoque de TypeSafe podría resultar disruptivo. Destacó que ambos productos líderes están estructurados en torno a un único modelo fundacional, lo cual tenía sentido en un entorno donde todos los proveedores ofrecían perfiles de capacidad más o menos comparables. Argumentó que muchos proyectos independientes de agentes de código abiertos están integrando ahora Jev y compitiendo para encontrar casos de uso diferenciados que una arquitectura de un solo modelo no puede replicar fácilmente. Asimismo, Diogo abordó un documento interno próximo a publicarse —que amplía un artículo que escribió titulado "KV Cache Rules Everything Around Me"— en el que argumenta que los agentes de código actuales están limitados arquitectónicamente por su dependencia de la caché de clave-valor (key-value cache) de un solo modelo, lo que encierra a los agentes en un único modelo, desincentiva una descomposición adecuada del software y complica la delegación de tareas a subagentes, la compactación de contexto y el intercambio de estados entre múltiples agentes. Afirmó que liberar a los agentes de esa restricción podría dar lugar a diseños de agentes sustancialmente diferentes, más económicos y más modulares.
Hoja de ruta del producto: sin determinismo, sin fine-tuning (por ahora), y posibles variantes de modelos
Respecto a decisiones específicas de diseño de producto, Diogo confirmó que Jev no admite salidas deterministas (la misma entrada garantizando la misma salida), argumentando que la "robustez" —entradas similares que producen salidas similares— es la propiedad más importante, y que el determinismo tendría un costo directo para la optimización central de la compañía en cuanto a inteligencia por dólar. Dejó abierta la puerta a ofrecer variantes deterministas si la demanda de los clientes justificara dicho equilibrio. El fine-tuning tampoco se ofrece actualmente, y Diogo fue explícito sobre los motivos, señalando que OpenAI, Anthropic y Google han retirado sus funciones de fine-tuning tras comprobar que resultaban ser más un inconveniente que un beneficio: "Podría ser un disparo en el pie", indicó, aunque no descartó retomar el fine-tuning ni ofrecer múltiples tamaños de modelos en el futuro a medida que madure la comprensión de la demanda por parte de la empresa. También reveló que TypeSafe evita deliberadamente entrenar con datos de clientes, a pesar de que probablemente podría obtener los derechos para hacerlo, porque desea prevenir el sobreajuste (overfitting) del modelo a los casos de uso actuales a expensas de aplicaciones futuras más difíciles de imaginar.
En cuanto a los casos de uso empresariales, Diogo apuntó a los "datos oscuros" (dark data) —grandes conjuntos de datos corporativos que antes resultaban demasiado costosos de procesar mediante LLMs— junto con los agentes de código como los dos principales impulsores de ingresos a corto plazo, situando como categorías secundarias las aplicaciones en tiempo real (en particular el comercio electrónico, donde la latencia afecta directamente a las conversiones) y las cargas de trabajo de observabilidad y verificación empresarial. Fue sincero al reconocer que el razonamiento de múltiples saltos (multi-hop reasoning) sigue siendo un punto débil en comparación con las tareas de un solo salto, y que algunas capacidades demostradas, incluido el control completo de computadoras y voz, aún no son lo suficientemente fiables para entornos de producción y surgieron de manera algo inesperada por parte de los desarrolladores en lugar de provenir de la propia hoja de ruta de la compañía.
Del equipo de RLHF de OpenAI a dos años de desarrollo en modo sigiloso
Diogo relató que la idea de TypeSafe se gestó mientras trabajaba en InstructGPT en OpenAI, cuando se convenció de que los productos de chat basados en instrucciones, aunque comercialmente exitosos, constituían una aplicación limitada y en última instancia restrictiva de la tecnología subyacente —una que generaba valor principalmente en categorías como la redacción de material publicitario mediante IA—. Comentó que planteó la idea internamente en OpenAI, incluso directamente a Sam Altman, pero que al final concluyó que una startup podía avanzar con mayor rapidez que si continuaba de forma interna. También reveló que la primera versión de InstructGPT se entrenó utilizando un algoritmo personalizado e inédito que él mismo desarrolló, ya que la optimización de políticas proximales estándar (proximal policy optimization) era demasiado lenta para depurar los datos de preferencia subyacentes, un detalle que no es ampliamente conocido de manera pública. Sobre la ola general de nuevos laboratorios de IA fundados por antiguos investigadores de frontera, Diogo se mostró inusualmente duro, al afirmar que "la mayoría de los Neo-labs son una porquería" y que muchos carecen de una estrella del norte técnica clara, argumentando que el prestigio en la investigación pura sin una tarea útil definida rara vez crea valor.