Estrategia Q7 — LLM en runtime para automation reasoning (v1)¶
Primera versión de Q7. Distinto de Q10 (agente operando infra): acá el LLM es parte de la automation misma — decide qué hacer en runtime cuando el trigger es ambiguo o el contexto requiere razonamiento. HA tiene el stack oficial (AI Task entity). El reto no es técnico — es acotar dónde vale la pena introducir AI en runtime sin sacrificar confiabilidad.
Contexto¶
Q7 era el más postergado en el wiki — escribir esta página después de Q10 maduro era la decisión. Llegó el momento. Hay tres tensiones a balancear:
- Confiabilidad: una automation con AI puede fallar de formas que una determinista no.
- Latencia: AI Task con cloud LLM = 1-5s; local Ollama = 2-10s. No apto para "luz se prende cuando entrás".
- Costo: cada invocación a AI tiene un costo (tokens cloud, electricidad local). Hacerlo en cada motion sensor = quemar plata.
La meta: AI runtime usado solo donde el determinismo no alcanza, con fallbacks deterministas para todos los casos críticos.
Contenido¶
Qué SÍ es buen caso para AI en runtime¶
| Caso | Por qué |
|---|---|
| Image classification (cuenta gallinas, detecta persona vs paquete en cam) | Tarea genuinamente AI; sin LLM/vision necesitás ML específico. |
| Resumen diario (digest del día: qué pasó, alerta resumida) | Texto natural language es el output natural del LLM. |
| Decisión high-level con muchas variables ("¿es razonable iniciar el calentamiento ahora dado el pronóstico, ocupación esperada, precio energía?") | Combina muchos inputs heterogéneos. |
| Plan generation ("genera el horario óptimo de riego esta semana dadas las temps pronosticadas") | Output complejo, deterministic rules serían enormes. |
| Voice transcription / intent extraction (out of scope acá) | El use case canónico de NLP, pero out of scope del wiki. |
Qué NO es buen caso¶
| Caso | Por qué |
|---|---|
| Motion → light | Latencia y costo prohibitivos para 0 valor sobre rule. |
| Door open → notify | Trivial; AI sólo agrega failure modes. |
| Temperature threshold → HVAC | Determinismo total alcanza; no hay reasoning. |
| Schedule-based actions | El schedule es la regla; AI no aporta. |
| Cualquier essentials (luces críticas, calefacción, seguridad) | El costo de "AI alucinó" en essentials es alto. |
Patrón de seguridad: AI propone, determinista decide¶
Modelo recomendado en lugar de "AI decide directo":
- alias: "AI heating recommendation"
trigger:
- platform: time_pattern
hours: "/4" # cada 4 horas
action:
# 1. AI sugiere
- service: ai_task.generate_data
data:
entity_id: ai_task.default
task: |
Dado pronóstico para próximas 4h: {{ weather }},
presencia esperada: {{ occupancy_forecast }},
precio energía: {{ energy_price }},
recomendá: ¿activo calefacción? (yes/no) y qué temperatura target.
structure:
activate: bool
target_temp_c: float
reasoning: string
response_variable: ai_response
# 2. Determinista valida
- if: >
{{ ai_response.target_temp_c >= 16 and ai_response.target_temp_c <= 24 }}
then:
- service: climate.set_temperature
data:
temperature: "{{ ai_response.target_temp_c }}"
# 3. Log siempre
- service: logbook.log
data:
message: "AI recomendó: {{ ai_response.reasoning }}. Aplicado: {{ ai_response.target_temp_c }}"
Tres invariantes: - AI nunca actúa directo en hardware crítico. - Determinista valida output (range checks, sanity checks). - Log siempre — sin esto no aprendés si el AI se desvía.
Stack para el setup del usuario¶
Opción default: cloud (Anthropic / OpenAI) vía AI Task integration.
- Pros: calidad alta, latencia razonable (1-3s), no requiere GPU.
- Contras: dependencia internet, costo per invocación (~$0.001-0.01 según tokens).
- Mitigación de costo: usar AI runtime solo en automations con
time_pattern(no por evento), o gateando con conditions deterministas previas.
Opción local: Ollama en mini-PC.
- Pros: zero data leaving home, sin costo recurring.
- Contras: requiere GPU dedicada para latencia razonable; CPU-only es 10-30s por query.
- Cuándo elegir: si tenés GPU vieja >= 8GB VRAM disponible, vale la pena. Si no, cloud es más práctico.
Modelo cost-budget mensual¶
Heurística para el usuario:
| Use case | Invocaciones/día | Costo cloud/mes |
|---|---|---|
| Daily digest (1×día, 500 tokens) | 1 | <$0.50 |
| HVAC AI recommendation (6×día, 2000 tokens) | 6 | $5-10 |
| Image classification cada 5 min (10000 tokens incl. image) | 288 | $50-100 |
| Per-event automation con AI (alta) | 1000+ | $200+ |
Implicación: el 80% del valor se extrae con invocaciones de baja frecuencia. Per-event AI es prohibitivo salvo cases muy específicos.
Failure modes específicos de Q7¶
A registrar en el catálogo:
- AI Task timeout: el LLM no responde en N segundos. Fallback: usar valor default determinista o skip.
- AI Task malformed output: response_variable no tiene la estructura esperada. Fallback: alerta humano + skip.
- AI Task quota exceeded (cloud): plan acabó. Fallback: throttle + alerta.
- AI alucinación que pasa validación determinista: AI dice "target_temp_c: 18" cuando debería ser 22 (mala lectura del contexto). Catch: history audit + outlier detection.
Conexión con Q10¶
Q7 (runtime) y Q10 (ops) son agentes distintos con modelos de autoridad distintos:
| Dimensión | Q10 (agente ops) | Q7 (LLM en automation) |
|---|---|---|
| Authority | Operator (con perímetro) | Suggester (humano/determinista valida) |
| Frequency | Por evento de health | Por trigger de automation (controlado) |
| Stake | Infra (containers, configs) | Comfort (no essentials) |
| Where it runs | Mini-PC | HA Container o Yellow |
| Failure mode si rompe | Visible (alert) | Sutil (decisión subóptima) |
Importante: nunca dejes que el agente de Q10 modifique automations Q7 sin approval humano. Doble compounding de incertidumbre.
Plan de adopción (gradual)¶
| Fase | Cuándo | Qué |
|---|---|---|
| 0 | Mes 1-3 (skip) | Sin Q7 hasta tener observabilidad sólida. |
| 1 | Mes 3+ | Primer AI Task: daily digest (low risk, 1×día). |
| 2 | Mes 4+ | Image classification para cámara existente (si aplica). |
| 3 | Mes 6+ | Decisión high-level (HVAC, riego) con AI propone + determinista valida. |
| 4 | Mes 12+ | Plan generation periódico (semanal, no per-event). |
| 5 | Nunca | AI tomando decisiones de essentials sin determinista en el camino. |
Relaciones¶
- Implementa: Q7 (LLM en runtime).
- Distinto de: q10-ai-tooling-strategy-v1 (ops, no runtime).
- Habilitada por: ../sources/ha-ai-2025-09 (HA tiene el stack).
- Aplica principio: ai-as-operator adaptado — "AI suggester, deterministic decider" en runtime.
Citas / evidencia¶
-
"now it's hard to go wrong" (sobre model choice 2025-09) — ../sources/ha-ai-2025-09.
- AI Task entity es feature stable (no experimental) según HA team — ../sources/ha-ai-2025-09.
Abierto / gaps¶
- Patrón concreto de "AI propone + determinista valida" como técnica reusable (template page).
- Modelo de cost tracking (Prometheus metric de tokens consumidos por día).
- Lista de "10 ideas para AI Task en una casa típica" — content marketing pero útil.
- ¿Existe AI Task con tool use (function calling) en HA? Vendría como evolución natural — buscar source.