Todas las entradas · · 5 min de lectura
Poner un modelo System One en producción
Un modelo que devuelve probabilidades calibradas en vez de texto cambia las preguntas operativas, no solo el código. Qué cablear, qué poner tras una compuerta, qué auditar, y qué pasa el día que el proveedor se cae.
Un modelo System One — Jev, de TypeSafe, es el primero — responde preguntas tipadas sobre un estado con probabilidades calibradas en vez de prosa. Para la mitad de un agente que decide en lugar de escribir, eso elimina de un saque el parser, el bucle de reintentos y la confianza inventada.
También cambia la conversación operativa, y esa es la parte que una plataforma tiene que responder. Esto es lo que implica de verdad ponerlo en producción.
Dos slots, no un reemplazo§
El juez no reemplaza al modelo de lenguaje. Va al lado: el juez decide, el LLM escribe, y la configuración normal tiene los dos cableados. En la plataforma son dos configuraciones independientes (SYNSEMA_JUDGE_ junto a SYNSEMA_LLM_), dos juegos de credenciales y dos presupuestos.
Esa separación es además un límite de permisos, y es lo primero que va a notar una revisión de seguridad:
require judge -- puede clasificar
require llm -- puede generar
Ninguno otorga el otro. Un servicio desplegado con judge y sin llm es un servicio que puede medir y no puede escribir: no se lo puede convencer de emitir texto libre, ni exfiltrar por ahí. Para las partes de enrutamiento, triage y elegibilidad de un producto, eso es mucho menos cosa que defender.
La clave nunca llega al programa§
TYPESAFE_API_KEY entra como un secreto sellado, igual que cualquier otro: guardado en el plano de control, inyectado cuando arranca el contenedor, mostrado en el panel como nombre y huella. El programa no puede imprimirla, loguearla, concatenarla ni devolverla desde una ruta, y el host al que va la llamada lo fija el runtime — un .syn desplegado no puede redirigir sus juicios a otro lado.
Cada comprobación de capacidad que hace el runtime queda en la auditoría, así que "¿este servicio clasificó algo anoche, y cuánto gastó haciéndolo?" es una consulta y no una investigación.
Un preflight que podés poner en el despliegue§
La falla más aburrida de producción es un servicio que arranca bien y deja de juzgar en silencio porque una clave nunca llegó al entorno. El CLI responde eso antes de que el proceso arranque, sin tocar la red:
$ synsema judge status
Key TYPESAFE_API_KEY ✗ FALTA
Model jev-latest (SYNSEMA_JUDGE_MODEL, default)
Base URL https://api.typesafe.ai (SYNSEMA_JUDGE_BASE_URL, default)
Budget (sin techo) (SYNSEMA_JUDGE_BUDGET, default)
decide LLM (default) (SYNSEMA_JUDGE_DECIDE)
Sale 0 cuando está vivo y 1 cuando no, así que synsema judge status && synsema serve app.syn es una compuerta y no un ritual. La clave se informa por presencia; el valor no aparece nunca.
El día que el proveedor se cae§
Esta es la pregunta que conviene resolver antes del incidente, porque la alternativa a una buena respuesta es un sistema que sigue respondiendo con seguridad, con números que se inventó.
Sin clave, pasado el presupuesto o tras una falla de red, cada respuesta vuelve con available: false, confidence: 0 y su valor principal en nothing. Un aviso sale por stderr y el programa sigue corriendo. Nunca se devuelve una probabilidad inventada — y eso importa más de lo que suena, porque una oración inventada se ve en la salida y una probabilidad inventada no: simplemente se multiplica, callada, hasta volverse un reembolso, un enrutamiento, un pago.
La consecuencia útil es que la degradación cae en la rama que ya escribiste. Una compuerta de confianza en 0,9 no la cumple una confianza de 0, así que cada ticket se va solo al camino humano:
when v.team.available and confidence of v.team >= 0.9
route(v.team.choice)
otherwise
approve "Route to " + text(v.team.choice) + "?"
En la plataforma ese approve es una cola de verdad: la aprobación aparece en el panel y en la API, avisada por webhook firmado y respondida con un token de un solo uso. Una caída del proveedor se convierte en una bandeja más ocupada durante unas horas, no en una decisión equivocada a escala.
Un presupuesto es una perilla, no una planilla§
SYNSEMA_JUDGE_BUDGET es un techo duro de tokens de entrada por proceso. En el techo, las respuestas degradan a available: false sin tocar la red — el gasto se detiene en un número que elegiste vos, no a fin de mes. Poné uno por servicio, igual que ponés la memoria.
Fijá la versión contra la que calibraste los umbrales§
judge_model() devuelve el id versionado que respondió la última llamada (jev-1.13.0), nunca el alias, y es deliberado: los proveedores mueven latest. Un umbral de 0,9 es un número ajustado contra un modelo concreto, así que fijá SYNSEMA_JUDGE_MODEL a una versión en producción y volvé a medir tus compuertas cuando la muevas — la misma disciplina que aplicarías a un modelo de scoring entrenado por vos.
Dos cosas más que conviene saber antes del primer despliegue: pedidos idénticos se mueven unas centésimas (0,72 → 0,69), así que los tests afirman ganadores y rangos y nunca igualdad; y SYNSEMA_JUDGE_PROVIDER=mock responde de forma determinista sin red y sin cuenta, que es como esto corresponde en CI.
Qué reemplaza§
Para el trabajo con forma de clasificación, reemplaza una llamada de chat más un parser más un reintento más una confianza que te inventaste. Para lo demás — la respuesta que lee el cliente, el resumen, la explicación — el modelo de lenguaje sigue siendo la herramienta correcta, y los dos están cableados a la vez.
La guía del lado del desarrollo es Cómo usar Jev desde Synsema; la página del manual es Judge. La próxima entrada es sobre lo que va a preguntar el área de finanzas: cuánto cuesta esto comparado con lo que estás haciendo hoy.