Operator es un modelo compacto que estoy entrenando para operar Kernel Memory
Protocol (KMP), el protocolo de memoria de Underpass Kernel.
KMP no es un estándar externo. Es el contrato que estoy definiendo dentro de
Underpass para leer memoria, moverse por ella y escribir nueva información de
forma validable.
Operator no nace porque KMP sea difícil de usar. KMP está diseñado para agentes,
humanos y herramientas mediante MCP o una API tipada.
Operator nace de una observación concreta: en benchmarks como LongMemEval o
MemoryArena, GPT-4o podía entender la pregunta y aun así fallar en la operación.
Elegir la herramienta MCP, copiar la referencia exacta, respetar un cursor,
mantener el presupuesto o escribir una relación con evidencia válida no son
detalles secundarios. Son parte del resultado.
También aparece una inercia típica de los modelos de propósito general: volver a
pensar la pregunta. Operator busca lo contrario: tomar un estado visible y emitir
la siguiente acción KMP.
Esa es la hipótesis que quiero medir: si un modelo compacto puede aprender la
parte estricta de operar ese contrato.
Cuando un sistema opera contra un protocolo o una API, una acción casi correcta
no sirve. La llamada tiene que ser válida.
Ahí entra Operator.
La idea
La idea es simple: no todas las decisiones de un sistema de agentes tienen que
ser razonamiento abierto.
El modelo principal puede entender la tarea, interpretar la evidencia y producir
la respuesta final. Operator ocupa un espacio más estrecho: decide cuál es la
siguiente acción KMP que conviene ejecutar desde el estado visible.
No sustituye al modelo principal. Le quita una parte concreta del trabajo:
operar memoria con precisión en escenarios exigentes.
Lo importante es que esa operación deja de ser una intuición dentro de una
respuesta libre. Pasa a ser una acción verificable, entrenable y auditable.
Qué es Operator
Operator es:
- un modelo compacto especializado en operar KMP;
- un predictor de la siguiente acción desde un estado visible de memoria;
- una pieza que trabaja con referencias, cursores, herramientas permitidas,
presupuesto, dimensiones y observaciones anteriores; - un emisor de acciones acotadas:
tool_call,prepared_tool_call,stopo
escalate; - un modelo entrenado contra el contrato real MCP/KMP, no contra una simulación
de laboratorio.
Las herramientas que puede emitir incluyen:
kernel_ingest;
kernel_write_memory;
kernel_wake;
kernel_ask;
kernel_goto;
kernel_near;
kernel_rewind;
kernel_forward;
kernel_trace;
kernel_inspect.
Qué no es
Operator no es:
- Underpass Kernel;
- KMP;
- un modelo de pregunta-respuesta;
- un agente autónomo;
- un razonador general;
- un sustituto del lector;
- quien decide el significado final de una memoria;
- una solución ad hoc para memorizar benchmarks;
- una base de datos vectorial.
Tampoco es una capa necesaria para usar KMP. Un modelo capaz puede operar KMP
directamente mediante MCP.
Qué ve y qué emite Operator
Operator no ve todo el problema. Ese es el punto.
Su mundo es más acotado que el mundo del modelo principal. No recibe una
conversación completa para interpretarla desde cero. Recibe un estado
estructurado: la parte de la memoria y del contrato que necesita para decidir el
siguiente paso.
Ese estado puede incluir un objetivo operativo, referencias conocidas, cursores,
dimensiones, herramientas permitidas, presupuesto restante y observaciones
anteriores.
No tiene que decidir qué significa todo. Tiene que decidir qué hacer ahora.
Con eso produce una única acción. Una muestra real, reducida a lo esencial,
queda así:
ESTADO VISIBLE
objetivo: expandir alrededor de ref_0001
modo: read
dimensión relevante: session:handoff
presupuesto: 1 llamada, 600 tokens
refs conocidas: ref_0001 ... ref_0005
ACCIÓN EMITIDA
tool_call: kernel_near
anchor: ref_0001
dimensions: [session:handoff]
limit: 4
La salida no es una explicación. No es una respuesta al usuario. Es una acción.
Cómo encaja con KMP
KMP es el contrato.
MCP es una forma de exponer ese contrato como herramientas para agentes.
Operator solo propone la siguiente acción.
No tiene una API privada. No salta por detrás de Underpass Kernel. Emite
acciones sobre el mismo contrato que usaría cualquier agente mediante MCP.
estado visible + objetivo + presupuesto
-> Operator
-> acción KMP/MCP
-> Underpass Kernel
-> evidencia, refs, prueba o error
Cómo se entrena
Operator no se entrena con preguntas y respuestas finales. Se entrena con
decisiones operativas.
El entrenamiento parte de trayectorias de operación:
estado visible -> acción esperada
El estado visible es la parte de la memoria que Operator puede usar en ese
paso: objetivo operativo, referencias conocidas, cursores, herramientas
permitidas, presupuesto y observaciones previas.
La acción esperada es la decisión correcta para ese estado: inspeccionar una
referencia, ampliar una ventana temporal, parar porque ya hay evidencia
suficiente, escalar porque hace falta razonamiento abierto o emitir una
escritura preparada.
Cada trayectoria se convierte en una fila SFT con tres mensajes:
system -> contrato MCP/KMP, herramientas permitidas y reglas de salida
user -> estado visible de memoria
assistant -> acción esperada en JSON estricto
Después se ajusta Qwen/Qwen2.5-0.5B-Instruct con LoRA SFT sobre ese formato.
Qwen no aprende a contestar el benchmark. Aprende a no volver a resolver la
tarea desde cero y a emitir la siguiente acción KMP válida desde el estado que ve.
LoRA permite hacer ese ajuste sin reentrenar todo el modelo. La base de Qwen se
mantiene congelada y se entrenan adaptadores ligeros sobre algunas capas. Esos
adaptadores son los que aprenden el patrón operativo de KMP: leer el estado
visible, respetar el contrato y emitir el JSON correcto.
Para que ese aprendizaje sea medible, el dataset tiene que estar muy controlado:
- las referencias visibles para el modelo deben ser opacas:
ref_0001,ref_0002,
about_0001; - el
userno puede incluir la respuesta esperada del benchmark, la acción
objetivo, memoria oculta ni salidas de herramienta que el modelo no debería ver; - el prompt de sistema debe incluir el esquema MCP/KMP real;
- el prompt de entrenamiento y el prompt de servicio tienen que ser equivalentes;
- las filas duplicadas o con colisiones visibles para el modelo se rechazan;
- cada acción se valida contra el contrato antes de entrar al entrenamiento.
Sin esas reglas, el resultado de evaluación deja de medir Operator. Puede estar
midiendo fuga de datos, divergencia entre entrenamiento y servicio o memorización
de nombres de dominio.
Cómo se evalúa
Después del entrenamiento, el adaptador LoRA se ejecuta sobre el conjunto de
evaluación.
Para cada fila, Operator recibe el estado visible y debe producir una única
acción. Esa es la diferencia con la respuesta libre de un LLM convencional: aquí
la salida se puede comprobar.
El proceso genera predictions.jsonl y summary.json. Luego el evaluador compara
cada predicción contra la acción esperada.
Las métricas principales son:
parseo: la salida es JSON válido con la forma esperada;
herramienta correcta: eligió la herramienta esperada;
contrato válido: la acción parsea y cumple las reglas mínimas;
argumentos exactos: referencias, cursores, límites y campos coinciden;
cobertura de contrato: el perfil declarado cubre lo que dice cubrir;
replay real: la acción se ejecuta contra Underpass Kernel mediante MCP.
La última métrica es la que evita autoengaños. Un JSON puede parecer correcto y
fallar contra el kernel real. Si falla ahí, la acción no sirve.
La afirmación publicable que busco es esta:
Operator predice acciones acotadas de Kernel Memory Protocol
desde estados visibles de memoria, con contrato estricto
y replay real contra Underpass Kernel mediante MCP.
Por qué Qwen 0.5B
Qwen 0.5B encaja con la hipótesis de Operator: especializar un modelo abierto en
una tarea estrecha y verificable.
Operator no tiene que escribir un ensayo ni resolver una incidencia completa.
Tiene que:
- mirar un estado estructurado;
- elegir una acción de una lista finita;
- construir argumentos válidos;
- parar o escalar.
Por eso Qwen es una buena base:
- es abierto y se puede entrenar sin depender de una API propietaria;
- está preparado para seguir instrucciones y emitir salidas estructuradas;
- es suficientemente compacto para ajustarlo con LoRA sin convertir el
experimento en un problema de infraestructura.
No busco demostrar que Operator sea más inteligente que un modelo de propósito
general. Busco comprobar si un modelo abierto y compacto puede aprender a operar
un contrato estricto.
Lo que aprendimos al evaluar
La evaluación también puede engañar.
Un evaluador puede aceptar acciones demasiado parecidas. Si esperaba
Stop(reason=NoCandidate) y acepta Stop(reason=AnswerReady) solo porque ambas
son stop, la exactitud aparente sube pero la semántica está mal.
También puede pasar con cursores. Una herramienta puede ser correcta y el cursor
equivocado. En KMP eso no es un detalle: cambia la acción.
Otro fallo posible es enseñar al modelo información que no debería ver:
respuestas finales, referencias futuras, sesiones objetivo o nombres de dominio.
Por eso antes de hablar de exactitud hay que hablar de contrato.
Estado actual
El pipeline ya existe: preparación SFT, referencias opacas, paridad entre
entrenamiento y servicio, ajuste LoRA, predicción, evaluación y replay por MCP.
El trabajo abierto está en endurecerlo: ampliar y diversificar el conjunto de
entrenamiento, reducir errores en llamadas casi correctas y validar replay contra
memorias realmente cargadas en Underpass Kernel.
No es una idea en papel. Es un sistema en entrenamiento.
Conclusión
Operator no intenta competir con otros modelos.
Quiere ocupar otro lugar.
La pregunta es más concreta: si un protocolo de memoria está bien definido,
¿puede un modelo compacto aprender a operarlo con disciplina?
Underpass Kernel convierte la memoria en una estructura que se puede leer,
recorrer, escribir y auditar.
KMP define el contrato.
Operator intenta aprender a ejecutarlo.
Recursos
- Underpass Kernel: https://github.com/underpass-ai/rehydration-kernel
- Operator trainer: https://github.com/underpass-ai/underpass-kmp-operator-trainer
- Qwen2.5 0.5B Instruct: https://huggingface.co/Qwen/Qwen2.5-0.5B-Instruct
- LoRA: https://arxiv.org/abs/2106.09685