Virtual Assistant — Un Agente de IA que Corre donde Otros No Pueden

Por qué lo hice

Quería aprender cómo se construye un agente de IA desde cero. No un wrapper de APIs, no un chatbot — un agente que realmente ejecuta herramientas, toma decisiones, y se autocorrige.

Probé opciones existentes:

• OpenClaw CLI está optimizado para APIs cloud. Su documentación recomienda “usar el modelo más potente disponible”. En la práctica, modelos pequeños sin fine-tuning de tool calling “a menudo se quedan en bucles o fallan al formatear JSON para tool calls”. Mi iGPU no carga un 7B a velocidad usable.

• Hermes Agent (Nous Research) está diseñado para APIs cloud; requiere modelos con al menos 64K tokens de contexto. Su documentación no prescribe modelos locales específicos para tool calling. En hardware local, modelos sin fine-cutting de tool calling fallan en tareas agénticas.

• Frameworks cloud no son una opción: dependen de internet, tienen latencia alta, y no conocen mi infraestructura local (Home Assistant, contenedores, etc.).

La solución no era comprar hardware mejor. Era aprender a hacer más con menos.

---

Qué aprendí

1. Un modelo 3B bien afinado hace tool calling mejor que uno 7B genérico

Hammer2.1-3B (fine-tune de Qwen2.5-Coder para function calling) puntúa mejor en el benchmark BFCL-v3 que modelos de 7B sin especializar. Corre a ~35 tok/s en mi iGPU. El truco no es el tamaño del modelo, sino que esté entrenado para la tarea correcta.

2. Decidir ANTES de ejecutar es la optimización más importante

La mayoría de agentes intentan con el modelo grande y escalan si falla. Este proyecto hace lo contrario: clasifica la intención primero, y solo usa el modelo caro si la tarea lo requiere. El 80% de las peticiones se resuelven con el modelo pequeño (~1-3s).

Escenario	Sin optimizar	Con routing predictivo
”Enciende la luz”	~8s (escala a capable)	~2s (standard directo)
“¿Qué temperatura hace?”	~6s (embedding + capable)	~2.5s (keyword + standard)
“Búscame horarios de cine”	~45s (3 rondas capable)	~12s (planner→standard, 2 rondas)

3. La separación razonamiento/ejecución funciona independientemente del modelo

Un patrón que descubrí por experimentación: el modelo capaz (Gemma-4-E2B) genera un plan, el modelo standard (Hammer2.1-3B) lo ejecuta paso a paso. El modelo pequeño es mejor siguiendo instrucciones de tool calling que el grande, que tiende a divagar. Esto contradice la intuición de “modelo más grande = mejor en todo”.

4. La validación sin IA es más importante que la IA misma

El sistema de grounding verifica cada respuesta contra los datos reales de las herramientas usando solo regex y reglas de dominio. Tarda <1ms y detecta fechas inventadas, estados incorrectos, y alucinaciones numéricas. En otros frameworks esto se hace con otra llamada LLM (2-10s adicionales).

5. Los perfiles de modelos intercambiables permiten experimentar sin miedo

Los modelos se definen externamente en archivos INI que llama-router lee. Hay 6 perfiles distintos, cada uno con 3 modelos (standard/capable/fallback). Cambiar de perfil no requiere tocar el código del agente. Esto me ha permitido probar combinaciones sin riesgo.

---

Resultados

Rendimiento vs alternativas

Sistema	Hardware mínimo	Modelo recomendado	Latencia típica
OpenClaw CLI	GPU 8GB+ VRAM	Modelo más potente disponible (cloud/local)	Depende del hardware
Hermes Agent	8GB RAM + 6GB VRAM	64K+ contexto (cloud/local)	~30-120s en CPU
Este proyecto	iGPU integrada + 24GB RAM	Hammer2.1-3B + Gemma-4-E2B	~2s (80%), ~12s (20%)

Datos reales de inferencia en mi hardware

Benchmarks medidos en AMD Ryzen 7 7840HS + Radeon 680M iGPU (Vulkan):

Modelo	Tamaño	Velocidad	VRAM	Primera respuesta
Hammer2.1-3B (Q4_K_M)	3B params	~35 tok/s	~4GB	~200ms
Gemma-4-E2B (Q4_K_M)	2B params efectivos	~15 tok/s	~5GB	~400ms
Qwen2.5-Coder-7B (Q6_K, CPU offload)	7B params	~8 tok/s	~2GB GPU+4GB RAM	~800ms

Para contexto: Gemma-4-E2B en un DGX Spark (NVIDIA GB10, 128 GB memoria unificada, 273 GB/s ancho de banda) hace ~53 tok/s. En mi iGPU (Radeon 680M, ~100 GB/s ancho de banda compartido) hace ~15 tok/s. La diferencia es ~3.5x, explicable por la combinación de mayor ancho de banda de memoria (~2.7-3x) más la ventaja computacional sustancial del DGX Spark.

Eficiencia energética

El sistema corre 24/7 en un servidor que consume ~25W en reposo, ~35W bajo carga. Para comparar, una RTX 4090 consume 450W solo la GPU. Esto significa que puedo tener el asistente funcionando todo el día por el coste de una bombilla.

---

Cómo funciona (el mínimo necesario para entenderlo)

Tú: "enciende la luz del salón"
           │
           ▼
┌─────────────────────────┐
│ 1. Clasificar           │  → es una orden de domótica
│    (qué quiere)         │     (11 tipos posibles)
└─────────┬───────────────┘
          │
          ▼
┌─────────────────────────┐
│ 2. Decidir               │  → es simple → modelo rápido
│    (quién lo hace)       │     (árbol de 11 reglas)
└─────────┬───────────────┘
          │
          ▼
┌─────────────────────────┐
│ 3. Preparar contexto     │  → "salón" = "light.salon", está apagado
│    (datos antes del LLM) │
└─────────┬───────────────┘
          │
          ▼
┌─────────────────────────┐
│ 4. Ejecutar             │  → LLM decide: ha_turn_on
│    (modelo + tools)     │  → Home Assistant: luz ON
└─────────┬───────────────┘
          │
          ▼
┌─────────────────────────┐
│ 5. Validar              │  → "encendida" coincide con ok:true ✓
│    (no alucine)         │     (<1ms, regex, sin LLM)
└─────────┬───────────────┘
          │
          ▼
"Encendida la luz del salón"   ← ~2 segundos

El asistente tiene 3 niveles de “cerebro” que se activan según la dificultad de la tarea:

Nivel	Modelo	Velocidad	Se usa para
Standard	Hammer2.1-3B	~35 tok/s	Luces, clima, saludos, consultas simples
Capable	Gemma-4-E2B	~15 tok/s	Búsquedas web, multi-paso, planificación
Fallback	Qwen2.5-Coder-7B	~8 tok/s	Cuando standard y capable fallan

---

Lo que el asistente sabe hacer

Actualmente entiende 11 tipos de intenciones y ejecuta herramientas en 16 dominios:

• Casa inteligente: encender luces, cambiar termostato, pasar aspiradora, consultar sensores
• Búsqueda web: preguntas factuales, horarios, noticias, navegación de URLs si los snippets no bastan
• Contenedores: estado, logs, reinicio de servicios Podman
• Rutas: tiempo de viaje con tráfico real vía Waze
• Memoria: recordar y recuperar información entre sesiones
• Archivos: leer, escribir y listar archivos del servidor
• Streaming: gestionar streams de Twitch/YouTube
• Metro y autobuses: consultar tiempos de transporte público de Málaga

---

Tecnologías usadas

Componente	Tecnología	Por qué
Clasificación de intents	ONNX + all-MiniLM-L6-v2 + cross-encoder	Sin GPU, corre en CPU en <50ms
Servidor LLM	llama.cpp con backend Vulkan	Única opción que acelera modelos pequeños en iGPU AMD
Router de modelos	llama-router (wrapper propio)	Lee perfiles INI, mapea tiers lógicos a GGUFs
Comunicación	python-telegram-bot	Async, long-polling, sin servidor web
HTTP	httpx (pool singleton)	Keepalive 120s, sin TCP handshake por request
Infraestructura	Podman + Docker Compose	4 redes externas, containers separados por servicio

Una lección importante: llama.cpp con backend Vulkan fue la única opción real para acelerar modelos en una iGPU AMD. Todas las alternativas (CUDA, ROCm, DirectML) o requieren hardware NVIDIA o tienen soporte experimental. El stack de inferencia local para AMD sigue siendo un punto débil del ecosistema.

---

Estado actual y próximos pasos

El sistema funciona 24/7 en un servidor casero. Se autoevalúa continuamente con phase scores (0-100 por fase del pipeline) y un runtime analyzer genera sugerencias de mejora automáticamente. Los phase scores actuales: Percepción 91, Routing 63, Contexto 88, Agent Loop 74, Tools 74, Memory 72, Validation 71, Reflection 69. Objetivo: 100/100 en cada fase.

El proyecto sigue activo. Las próximas áreas de mejora incluyen compresión adaptativa de contexto, detección más robusta de escalación como degradación, y TTL adaptativo en memoria semántica.