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 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.
Operator es:
tool_call
, prepared_tool_call
, stop
o
escalate
;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
.Operator no es:
Tampoco es una capa necesaria para usar KMP. Un modelo capaz puede operar KMP
directamente mediante MCP.
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.
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
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:
ref_0001
, ref_0002
,
about_0001
;user
no puede incluir la respuesta esperada del benchmark, la acción objetivo, memoria oculta ni salidas de herramienta que el modelo no debería ver;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.
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:
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.
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:
Por eso Qwen es una buena base:
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.
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.
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.
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.