CogniConsole: fiabilidad del LLM por control, no por capacidad

La receta habitual para hacer más fiable a un LLM es cambiarlo por uno más grande o más capaz. Un trabajo publicado en arXiv discute esa idea con datos: en 489 pruebas dentro de un entorno interactivo de varios pasos, aumentar el andamiaje estructural alrededor del modelo, sin tocar el modelo, reduce de forma sistemática la varianza de las salidas y la tasa de fallos.

El artículo, CogniConsole: Externalizing Inference-Time Control as a Formal Abstraction for Reliable LLM Interactions, propone tratar el control en tiempo de inferencia como una abstracción de primera clase, al mismo nivel que la arquitectura o los datos de entrenamiento.

Qué es el control en tiempo de inferencia

Los autores llaman inference-time control a la capa computacional que decide cómo se enmarca la tarea y qué contexto se selecciona antes y durante cada llamada al modelo. Es todo lo que ocurre alrededor del prompt: qué instrucciones se fijan, qué información se recupera, cómo se coordinan los pasos de una tarea compleja. La tesis del paper es que buena parte de la fiabilidad de un sistema depende de esta capa, no solo del modelo que hay debajo.

CogniConsole es la instancia concreta de esa idea. Externaliza el control en una interfaz estructurada que combina coordinación programática con razonamiento acotado basado en prompts. En lugar de dejar que el modelo improvise el marco de la tarea, el marco se define fuera y se le impone.

Qué midieron

El experimento son lo que los autores llaman controllability-oriented probes: 489 sondas en un entorno interactivo de varios pasos. La variable que mueven es el grado de andamiaje, desde interacción no estructurada hasta una totalmente estructurada, con la arquitectura del modelo fija. El resultado es claro en una dirección: a más estructura, menos varianza en la salida y menos fallos.

Más interesante que el número es la interpretación. Los autores sostienen que fallos habituales como el context drift (la deriva del contexto a lo largo de una conversación) o la adherencia inconsistente a las restricciones no son necesariamente síntomas de un modelo poco capaz, sino de un control mal especificado. Es decir, el sistema falla porque no le hemos dicho con suficiente precisión qué hacer y con qué contexto, no porque no sepa hacerlo.

Por qué importa y para quién

Para cualquiera que construya agentes o flujos con LLM, esta es una confirmación empírica de algo que muchos equipos ya intuían en la práctica. La diferencia entre un agente frágil y uno estable rara vez es el modelo; suele ser cuánto has estructurado el andamiaje a su alrededor: instrucciones explícitas, gestión del contexto, coordinación de pasos.

Encaja bien con las piezas que Anthropic ha ido normalizando en Claude Code. Las skills empaquetan instrucciones y contexto que Claude invoca bajo demanda; los subagents delegan tareas acotadas a agentes especializados; los hooks fijan comportamiento en puntos concretos del ciclo de vida. Todo eso es, en el vocabulario del paper, control en tiempo de inferencia externalizado. El trabajo aporta una base experimental a una forma de construir que ya se estaba imponiendo.

El aviso de siempre: es un estudio con 489 pruebas en un entorno concreto, no una ley universal. La forma exacta del andamiaje que funciona en su banco de pruebas no tiene por qué trasladarse tal cual a un caso de producción distinto. Pero la dirección, más estructura reduce varianza a igualdad de modelo, es consistente con lo que vemos a diario.

Nuestra lectura

En ElephantPink llevamos tiempo diseñando integraciones partiendo de la estructura antes que del modelo, y este paper pone nombre y números a esa intuición. La lectura útil no es que el modelo dé igual, sino que buena parte del margen de fiabilidad está en la capa que tú controlas, y esa es una buena noticia para quien construye.