El modelo no es el agente: Por qué 7 fine-tunings me llevaron a construir un harness determinista
AGENT HARNESS // DETERMINISTIC BOUNDARY // OPERATIONAL MEMORY
Entrenar modelos de lenguaje es fascinante, pero la práctica prolongada en entornos reales expone verdades incómodas. En el desarrollo de Home Assistant Specialist (versiones v0.2 a v0.5.2), el objetivo inicial era claro: afinar un modelo local ultraespecializado de 4B parámetros (Qwen3-4B-Instruct) utilizando Unsloth y PyTorch en entornos como Kaggle para que entendiera las llamadas nativas de Home Assistant.
Siete iteraciones de dataset después, las métricas contaban una historia dividida: mientras que la precisión de llamada a herramientas en casos positivos alcanzaba un 92.22%, la capacidad del modelo para abstenerse de actuar (la llamada safe rejection o frontera negativa) se desplomó de un 60.32% en la v0.5 a un 17.65% en la v0.5.1 al intentar balancear el dataset.
El modelo aprendió la forma sintáctica del ejecutor, pero perdió el criterio de cuándo no actuar. Ese fue el momento de inflexión: los modelos de lenguaje son probabilísticos por naturaleza. Home Assistant y la infraestructura crítica de un hogar requieren comportamiento determinista.
1. Las métricas del colapso: La ilusión del fine-tuning
Cuando entrenas un SLM para control de dispositivos, es fácil enamorarse de la curva de loss o del tool call exact score. Sin embargo, el comportamiento en producción en un homelab exige auditar los falsos positivos y los casos de abstención.
| Métrica Scorer Estricto | Fine-Tuning v0.5 | Fine-Tuning v0.5.1 |
|---|---|---|
| Tool Call Exacto (Positivos) | 92.22% | 88.40% |
| Argumentos Exactos | 94.70% | 91.10% |
| Safe Rejection (Negativos) | 60.32% | 17.65% |
| Multi-Call Exacto | 80.00% | 4.55% |
En la versión v0.5.1, al triplicar ejemplos sintéticos para corregir el balance de dataset (tuxevil/Home-Assistant-Requests-V5.2-Native-Strict), el modelo sufrió sobre-activación: interpretaba cualquier consulta ambiental como una orden implícita de ejecución o colapsaba al intentar encadenar múltiples llamadas.
Confiar la seguridad de una casa a la distribución probabilística de un modelo de 4B parámetros implica aceptar que en un porcentaje de turnos el modelo ejecutará un servicio arbitrario por alucinación sintáctica.
2. El pivote: Arquitectura Tuxbot HA Supervisor
La solución no era generar otros 10,000 pares sintéticos de entrenamiento. La solución era mover la frontera de seguridad fuera de los pesos del LLM y colocarla en un harness determinista escrito en código.
Nace Tuxbot HA Supervisor, un proceso independiente en Python que desacopla la interpretación de lenguaje de la ejecución física:
Eventos HA / Revisión Periódica
↓
Context Builder & History
↓
Modelo Local (Ollama / Qwen3 / Bonsai)
↓
Tuxbot HA Supervisor (Policy Engine & Action Registry)
↓
[Guardarraíl: ¿Es Energía/Infraestructura?] → SÍ → Bloqueo Absoluto / Aprobación
↓ NO
Acción Tipada + Verificación de Estado Físico
↓
Registro en Memoria OperacionalReglas de oro de la arquitectura:
- Acciones tipadas, no invocaciones genéricas: El modelo jamás invoca
call_servicegenérico ni ejecuta código arbitrario. Solamente emite intenciones tipadas que el supervisor valida contra un esquema estricto. - Aislamiento de infraestructura vital: Los sistemas de energía solar, baterías, redes y los propios servidores donde corre el agente tienen un guardarraíl absoluto en código. El agente no tiene permisos para cortar la energía de su propio nodo de cómputo.
- Verificación física tras la acción: Cada acción ejecutada requiere un read-back del estado en la API de Home Assistant para confirmar que la entidad cambió de estado físicamente.
3. Del modelo “Junior” al “Senior”: Autonomía Progresiva y Memoria
En lugar de pretender que un modelo recién desplegado actúe con autonomía total desde el día uno, el supervisor implementa una jerarquía de maduración similar a la de un operador humano:
Nivel 1: Observador → Detecta anomalías y sugiere (cero acciones físicas).
Nivel 2: Recomendador → Notifica al usuario la intención y espera aprobación.
Nivel 3: Reversible → Ejecuta acciones menores (luces, switches) y notifica.
Nivel 4: Senior → Autonomía alta basada en patrones consolidados en memoria.El bucle de aprendizaje explícito
Cuando el supervisor ejecuta una acción autónoma (ej. apagar un switch de iluminación) y el operador humano revierte manualmente el dispositivo en los segundos posteriores, el supervisor no asume el motivo por probabilidad.
El sistema envía una notificación vía Home Assistant Assist o canal directo preguntando explícitamente el motivo de la corrección. La respuesta del usuario se persiste en la memoria operacional determinista del supervisor, evitando que el error se repita sin necesidad de re-entrenar los pesos del modelo base.
4. Conclusión: El modelo es la herramienta, no el agente
El dataset v0.5.2 (tuxevil/Home-Assistant-Requests-V5.2-Native-Strict) en Hugging Face no fue un esfuerzo desperdiciado: queda consolidado como nuestro benchmark interno estricto para evaluar la capacidad sintáctica de modelos locales en Ollama.
La lección fundamental de estas 7 iteraciones de fine-tuning es de arquitectura: un modelo de lenguaje no es el agente; es el motor de razonamiento dentro de un arnés de software determinista. La responsabilidad de no apagar la casa cuando no debe nunca perteneció a los gradientes de loss, sino a los guardarraíles del código.