Principais conclusões
- Alucinação na automação residencial = dispositivo errado acionado, estado lido incorretamente, ou entidade inexistente referenciada — não um fato geral inventado
- Principal solução: restringir o esquema de function calling do modelo apenas à sua lista de entidades real e atual
- Passar o estado atual do sensor/dispositivo diretamente no prompt, em vez de deixar o modelo presumir ou lembrar de um ponto anterior da conversa
- Modelos pequenos e bem delimitados (veja o guia de modelos de linguagem pequenos) são inerentemente menos propensos a isso do que modelos de uso geral com um conjunto de ferramentas amplo e irrestrito
- Teste as automações contra casos extremos (entidades renomeadas, dispositivos offline) antes de confiar nelas sem supervisão
Como a alucinação se manifesta na automação residencial
Os três modos de falha comuns são: acionar um dispositivo com nome parecido, mas errado, agir com base em um estado de sensor presumido em vez do real, e referenciar uma entidade que não existe na sua configuração.
- Acionamento do dispositivo errado: pedir para desligar "a luminária" quando você tem várias, e o modelo escolhe uma com base em um palpite, em vez de pedir esclarecimento ou usar o contexto corretamente.
- Estado presumido: uma automação age como se uma janela estivesse fechada porque esse é o caso comum, em vez de verificar a leitura real e atual do sensor.
- Entidade inexistente: o modelo referencia um nome de dispositivo que soa plausível (por ser comum nos dados de treinamento), mas que nunca foi realmente configurado na sua instância do Home Assistant.
Grounding: restringir a entidades reais
A principal solução é um esquema de function calling que expõe ao modelo apenas sua lista de entidades real e atual — ele só pode chamar funções para dispositivos que realmente existem, eliminando estruturalmente o modo de falha de "entidade inventada".
- Gere o esquema de function calling (ou a lista de entidades passada ao modelo) dinamicamente a partir do registro de entidades real e atual do Home Assistant, em vez de uma lista escrita à mão ou desatualizada que pode ficar dessincronizada à medida que você adiciona/remove dispositivos.
- Se sua configuração tem nomes de entidades ambíguos (várias entidades "luz"), renomeie-as para serem mais distintas, em vez de contar com o modelo para desambiguar corretamente — isso é uma correção de configuração, não de prompting, e é mais confiável.
- O guia de integração Home Assistant-Ollama aborda a configuração prática de conectar o Ollama ao agente de conversação do Home Assistant, que lida automaticamente com grande parte dessa geração de esquema.
Passando o estado atual, não um estado presumido
Automações que dependem do estado de um sensor devem consultar a leitura real e atual no momento da execução, em vez de confiar na memória do modelo sobre um turno de conversa anterior ou em uma suposição sobre o estado típico.
- Para qualquer automação em que "a janela está aberta" ou "a luz já está acesa" importe para a decisão, busque esse estado diretamente como parte da lógica da automação, em vez de confiar que o modelo o rastreou corretamente ao longo de uma conversa.
- Este é um princípio geral de redução da fragilidade de prompts (veja o guia transversal sobre esse tópico), aplicado especificamente ao estado da casa inteligente baseado em sensores.
- Combinar múltiplas leituras de sensores (fusão de sensores) antes de agir também pode reduzir que a leitura incorreta de um único sensor influencie uma decisão — veja a fusão de sensores no guia de casa inteligente.
Testando e detectando erros
Teste automações contra casos extremos — uma entidade renomeada, um dispositivo temporariamente offline, um comando ambíguo — antes de confiar nelas para funcionar sem supervisão, da mesma forma que você testaria qualquer lógica de automação.
- Teste deliberadamente um comando que referencia uma entidade recentemente renomeada ou removida para confirmar que a automação falha com segurança (pede esclarecimento ou não faz nada), em vez de tentar adivinhar um dispositivo com nome parecido.
- Registre as ações acionadas pela automação durante um período de teste inicial para que você possa revisar o que o modelo realmente fez em comparação com o que você pretendia, detectando falhas silenciosas de acionamento antes que se tornem rotina.
- Comece novas automações orientadas por LLM em dispositivos de baixo risco (iluminação) antes de estender o padrão para dispositivos de maior risco (fechaduras, sistemas de segurança) onde uma ação errada tem mais consequências.
Perguntas frequentes
Como isso é diferente de conselhos gerais sobre alucinação de IA?
As orientações gerais de redução de alucinações (veja o guia de alucinações de IA) abordam fatos inventados na geração de texto aberta. Este artigo é específico para os modos de falha de function calling que ocorrem quando um LLM mapeia um comando para uma ação em um dispositivo.
Um modelo menor alucina mais ou menos nesse contexto?
Um modelo pequeno bem delimitado e restrito a um esquema específico de function calling costuma ser menos propenso a isso do que um modelo de uso geral com um conjunto de ferramentas amplo e irrestrito — veja o guia de modelos de linguagem pequenos para entender o motivo.
Posso eliminar completamente os acionamentos de dispositivos errados?
Não completamente, mas restringir o esquema de function calling à sua lista de entidades real e atual, usar nomes de entidades distintos, e testar casos extremos reduz significativamente a taxa de falhas — trate isso como redução de risco, não como uma garantia.
Devo deixar um LLM controlar fechaduras e sistemas de segurança?
Comece com dispositivos de menor risco (iluminação) para construir confiança na confiabilidade da sua configuração específica antes de estender o controle por LLM a dispositivos de maior consequência, como fechaduras — essa é uma escolha de gestão de risco, não um requisito técnico.
A integração Ollama do Home Assistant lida com o grounding de entidades automaticamente?
Ela gera dinamicamente a lista de entidades disponíveis a partir da sua configuração atual para o agente de conversação, o que lida com grande parte do grounding descrito aqui — veja o guia de integração Home Assistant + Ollama para os detalhes de configuração.
O que uma automação deve fazer se não conseguir identificar com confiança a entidade correta?
Falhar com segurança — pedir esclarecimento ou não tomar nenhuma ação — em vez de tentar adivinhar uma entidade com nome parecido. Essa é uma escolha de design em como você estrutura a lógica de function calling da automação.