Los modelos System One de Jev: Glean, UiPath y Workday integran llamadas rápidas directamente en el código

Un dolor conocido: un LLM en el código de producto se comporta como una lotería. Diogo Almeida, cofundador y CEO de TypeSafe AI, lo formuló así en el AI Engineer Code Summit: el 95% de las veces obtienes a Einstein, y el otro 5%, a Mr. Bean. Y si no puedes distinguir uno de otro, no hay nada que automatizar. Su respuesta a este problema se llama System One.

Qué son los modelos System One

Son modelos no generativos. No escriben texto coherente ni razonan paso a paso. Devuelven un resultado estructurado: una opción de una lista, una puntuación o una probabilidad. Por eso, por lo general, son notablemente más rápidos y baratos que los LLM de razonamiento, a los que en la conferencia llamaron System Two.

Un ejemplo sencillo. Antes le pedías a un LLM «evalúa si este documento se refiere a la consulta», recibías un párrafo de razonamientos y lo procesabas con expresiones regulares. Ahora llamas a un modelo que devuelve de inmediato un número o una etiqueta. Se puede colocar en un bucle, en una condición if o en una ordenación, y se comportará de forma predecible.

Jev es el producto con el que, según Latent Space, empezó esta ola. Salió en septiembre, y el pódcast con Almeida se convirtió en el episodio más popular del año del medio. La tesis principal de Almeida para los ingenieros: el código es el lenguaje de la automatización, así que el modelo hay que integrarlo en el código. El fundador de Latent Space, swyx, lo resumió así: reparte llamadas a System One generosamente dentro de la aplicación en lugar de «pegamos cadenas y esperamos que salga bien».

Qué se está construyendo ya

Glean usa System One junto con LLM y otros clasificadores. Chinmay Goyal destacó la principal ventaja de Jev: la flexibilidad zero-shot. Cuando cambia la taxonomía de decisiones, no hace falta reentrenar los modelos una y otra vez. A los usuarios de Glean les da igual lo que haya bajo el capó, y la empresa oculta deliberadamente esa diferencia.

UiPath mostró un patrón de «torneo». Jev elige los fragmentos de documentos más relevantes de pequeños grupos, los ganadores pasan a la siguiente ronda, y así hasta la final. Todo el proceso tardó menos de un segundo, aunque hubo miles de llamadas a Jev. La conclusión de los ingenieros de UiPath: por separado el modelo puede parecer poco inteligente, pero con el esquema adecuado de bloques así se obtiene un sistema más inteligente.

Scott Roberts, ingeniero de Workday, mostró un prototipo en el que la interfaz empieza a rellenar la ficha de vacaciones mientras el usuario todavía escribe. Aquí, una llamada rápida al modelo no solo acelera el formulario, sino que cambia el comportamiento del propio software: de predecir lo que quieres decir a predecir lo que quieres hacer.

Limitaciones

Esto es una crónica de una conferencia, no un benchmark. En el material no hay cifras de precisión, y «el 95% de Einstein» es un chiste desde el escenario, no una medición. Jev existe desde hace menos de dos meses, así que es pronto para hablar de explotación a largo plazo. Además, Almeida comparó explícitamente el momento actual con los inicios de internet, cuando los experimentos son valiosos solo porque son posibles. Eso inspira, pero no es una justificación de producto. Los LLM de razonamiento tampoco desaparecen: la propia Glean los usa junto con System One.

Qué hacer en la práctica

1. Repasa tu código y encuentra los lugares donde se usa un LLM como clasificador, ordenador por relevancia o enrutador. Son los primeros candidatos para sustituir por un modelo rápido.
2. Prueba el esquema de torneo para el ranking: muchas llamadas baratas sobre grupos pequeños en lugar de una cara sobre toda la lista.
3. Mide en tus propios datos la precisión, la latencia y el coste, sin fiarte de las presentaciones. Para una automatización fiable importa no la precisión media, sino lo predecible que sea el resultado.
4. Piensa en qué casos una respuesta instantánea cambia la interfaz. El autorrelleno de un formulario mientras se escribe es justo uno de ellos.

Lo principal de esta historia no es un producto concreto, sino un cambio de arquitectura: no toda decisión de una aplicación hay que dejarla en manos de un gran modelo generativo.