Conceito

Ancoragem de Respostas (Grounding)

Grounding, ou ancoragem de respostas, liga a saída de um modelo a evidências externas verificáveis, como documentos recuperados, dados de sensores, resultados de ferramentas ou bases estruturadas. A técnica difere de apenas dar mais contexto: cada afirmação relevante deve ser sustentada por uma fonte, timestamp ou resultado identificável. Em casa inteligente, o modelo deve dizer que a porta está trancada somente após consultar o sensor. RAG, citações e function calling ajudam, mas grounding não elimina erros de recuperação, fontes desatualizadas nem interpretações incorretas.


Definição aprofundada

A ancoragem de respostas trata a geração como uma camada posterior à obtenção de evidências. Em vez de permitir que o modelo responda apenas com conhecimento paramétrico, a aplicação fornece documentos, valores calculados, estados de dispositivos, resultados de APIs ou registros e exige que as afirmações importantes sejam compatíveis com essas fontes. O conceito pode usar RAG, consultas estruturadas, function calling, bancos de conhecimento, citações e verificadores. Grounding não significa que toda frase precisa vir de um documento; significa que fatos operacionais e verificáveis devem ter base rastreável. Na casa inteligente, estado, consumo, evento e procedimento devem indicar origem e horário. A técnica reduz alucinação e melhora auditoria, mas herda falhas da fonte, da recuperação, do relógio e da interpretação.

🔑Pontos-chave
  • A primeira distinção é entre fonte e contexto. Um texto dentro da janela pode ser irrelevante, incorreto ou malicioso. Grounding exige proveniência: título, sistema de origem, versão, página, entidade, timestamp e, quando possível, hash. Se o modelo afirma “o sensor registrou 28,4 °C às 14:02”, a ferramenta precisa ter retornado esses campos. Se explica um procedimento, a citação deve apontar ao manual do modelo e firmware corretos. Uma mensagem antiga do usuário não é fonte atual de estado. O sistema deve separar dado medido, inferência e conhecimento documental. A interface pode usar rótulos: “segundo o sensor”, “segundo o manual” e “estimativa do modelo”. Essa transparência reduz a tendência de tratar toda frase fluente como observação direta.
  • Grounding por ferramentas é apropriado para dados dinâmicos. Estado de luz, fechadura, portão, temperatura, energia e presença muda. O modelo chama uma API autorizada, recebe resposta estruturada e verbaliza. A ferramenta inclui unidade, qualidade, horário e erro. Um resultado `unknown` não pode virar `off`. Se o sensor está desatualizado, a resposta declara. Cálculos são feitos em código, não pelo modelo, quando precisão importa. Para “quanto consumi ontem?”, o serviço de séries temporais soma kWh e retorna. O modelo explica. A confirmação de uma ação vem do atuador ou sensor, não da emissão do comando. Essa regra é especialmente importante para portões, fechaduras e alarmes.
  • Grounding documental usa recuperação. O pipeline indexa fontes, filtra por produto, versão, idioma e permissão, recupera trechos e fornece citações. O modelo é instruído a limitar afirmações às evidências. Ainda pode extrapolar. Uma verificação posterior pode comparar frases e trechos, mas também é probabilística. Para números críticos, use extração estruturada. Se duas fontes divergem, a resposta deve mostrar conflito, não escolher silenciosamente. Documentos obsoletos são marcados. O sistema sabe dizer “não encontrei no material disponível”. A ausência de evidência não deve ser preenchida por memória geral quando a tarefa exige fonte local. Esse comportamento é medido em testes com perguntas sem resposta.
  • Grounding pode falhar por recuperação errada, fonte ruim ou interpretação. Um manual de modelo S200 recuperado para S100 produz resposta ancorada, porém errada para o contexto. Um sensor mal calibrado fornece dado real, porém inexato. Um relógio incorreto desloca evento. A ancoragem não prova qualidade da evidência. Metadados, filtros, calibração, integridade e monitoramento continuam. Em sistemas críticos, múltiplas fontes podem ser comparadas. Um sensor de fechadura e um contato magnético independentes elevam confiança. A resposta registra discrepância. Não se deve usar o termo “grounded” como sinônimo de “verdadeiro”. Ele descreve ligação a evidências identificadas.
  • A segurança exige controle de acesso e tratamento de dados não confiáveis. Uma fonte recuperada pode conter prompt injection. O texto é delimitado e não pode alterar políticas ou chamar ferramentas. A autorização é aplicada antes da recuperação. Um visitante não acessa vídeo ou logs administrativos. Citações não devem revelar caminhos internos, tokens ou dados de terceiros. O modelo recebe apenas o necessário. Ferramentas têm menor privilégio. A ancoragem pode aumentar privacidade se evita enviar todo o histórico e usa consultas específicas, mas também pode expor fontes sensíveis. Logs guardam IDs e decisões, com retenção. O usuário pode abrir a fonte quando autorizado.
  • A avaliação precisa medir suporte, não só fluência. Um conjunto de perguntas tem respostas e fontes esperadas. Métricas avaliam se o trecho relevante foi recuperado, se a resposta está suportada, se citações apontam corretamente, se números correspondem e se o sistema se abstém quando não há base. Para estados, testes simulam `offline`, atraso e conflito. Para ações, verificam que sucesso só é afirmado após confirmação. Avaliações automáticas ajudam, mas revisão humana é necessária em amostras. Modelos e prompts mudam. O grounding deve ser testado a cada versão. Em casa inteligente, o efeito prático é uma interface que mostra de onde veio a informação e evita transformar memória probabilística em controle factual.
Exemplos
Estado de fechadura com fonte e timestamp
O usuário pergunta “a porta da frente está trancada?”. O modelo não responde de memória. A ferramenta consulta o dispositivo e recebe `state=locked`, `observed_at=21:06:14`, `quality=confirmed`. A resposta diz: “O sensor da fechadura informa estado trancado às 21:06.” A interface mostra botão para abrir o histórico. Se a leitura tem 20 minutos, informa que está desatualizada e oferece atualizar. Se o comando de trancar foi enviado, mas o sensor não confirmou, não afirma sucesso. A ancoragem usa o estado real. A autorização impede que visitante veja detalhes.
Procedimento citado por modelo e firmware
Ao perguntar como recalibrar um sensor, o RAG filtra pelo inventário e recupera o manual do modelo X, firmware 3.4, páginas 18–19. O modelo gera passos e cita cada bloco. Um passo que não aparece é removido. Se o manual diz desligar por 30 segundos, o número vem da fonte. A resposta alerta sobre perda de configuração se descrita. Se o firmware atual é 2.9, o sistema avisa que o procedimento pode não se aplicar e busca a versão correta. Grounding não é apenas anexar link; é manter correspondência de versão e conteúdo.
Explicação de energia com cálculo externo
A pergunta “qual equipamento mais consumiu ontem?” dispara uma consulta ao banco de séries. O serviço calcula kWh por circuito e retorna tabela com período, fuso e cobertura. O modelo responde que o aquecedor consumiu 12,8 kWh, 31% do total, e cita o medidor. Se faltaram duas horas de dados, declara. Não calcula porcentagem mentalmente se o backend já pode. Um manual recuperado pode explicar modos, mas não alterar os valores. A resposta separa medição, cálculo e hipótese. O usuário pode abrir o gráfico. A ancoragem torna a análise auditável.