2.4 — Por que Grounding Precede Ação: o Harness Decide o que "Sabe" antes de Decidir o que "Faz"

Objetivo da Aula

Posicionar o grounding como etapa obrigatória do agent loop antes da decisão de ação, não como tool opcional que o agente pode ignorar

Desenhar o ponto de decisão onde o harness usa o sinal de cobertura (capítulo 2.1) para escolher entre responder, buscar mais, ou recusar agir

Diferenciar conhecimento paramétrico (o que o LLM "sabe" por treino) de conhecimento de grounding (o que o sistema recuperou agora) como duas fontes de verdade com autoridade diferente

Integrar o ciclo grounding→decisão com os padrões de loop de agente vistos na Parte 1 (ReAct, Plan-Execute, Ralph Loop)

Reconhecer os sintomas arquiteturais de um sistema que age sem grounding suficiente, e desenhar o circuito de contenção

Por que isso importa

Os três capítulos anteriores desta parte estabeleceram grounding como infraestrutura (2.1), como ela é construída (2.2, indexação) e como ela é consultada (2.3, retrieval). Este capítulo fecha o ciclo respondendo a uma pergunta diferente: em que momento do agent loop essa infraestrutura é consultada, e o que acontece quando o resultado da consulta é insuficiente?

A resposta ingênua — "o agente chama a tool de busca quando acha que precisa" — é exatamente o tipo de decisão implícita que a Parte 1 já ensinou a desconfiar. Um LLM decidindo sozinho, a cada turno, se vale a pena consultar a base de conhecimento é o mesmo problema arquitetural de um LLM decidindo sozinho quais permissões usar: funciona na demonstração, falha de forma imprevisível em produção, porque a decisão de "quando confiar no que sei vs. quando verificar" fica espalhada implicitamente no comportamento probabilístico do modelo, em vez de ser uma regra explícita do harness.

Impacto direto no seu trabalho: todo incidente de "o agente agiu com base em informação errada/desatualizada" tem uma causa raiz comum — o sistema tomou uma ação (responder, executar, aprovar) sem que o harness tivesse verificado, antes, se havia grounding suficiente para essa ação. Projetar esse ponto de verificação como etapa obrigatória do loop — não como comportamento emergente do prompt — é o que separa um agente confiável de um agente que parece confiável até o dia em que não é.

Conceitos Fundamentais

Duas fontes de conhecimento, duas autoridades diferentes

Todo LLM chega à conversa já "sabendo" coisas — o conhecimento paramétrico absorvido no treino. Grounding adiciona uma segunda fonte: o conhecimento recuperado agora, específico do contexto da empresa. O harness precisa tratar essas duas fontes com autoridade explicitamente diferente, porque elas divergem exatamente nos casos que mais importam.

O erro mais comum em produção é deixar essas duas fontes se misturarem sem sinalização: o prompt injeta os chunks recuperados e pede para o LLM responder, sem instrução explícita sobre o que fazer quando os chunks não cobrem a pergunta. Nesse vácuo, o LLM tende a completar a lacuna com conhecimento paramétrico — plausível, bem escrito, e potencialmente errado para o contexto específico da empresa. Do ponto de vista do usuário, a resposta parece igualmente confiável nos dois casos. É exatamente essa indistinguibilidade que o harness precisa eliminar.

O ponto de decisão: cobertura como gate antes da ação

Retomando o sinal de cobertura introduzido no capítulo 2.1, o harness usa esse sinal como um gate — um ponto de controle explícito no agent loop, antes de qualquer ação ser tomada (responder ao usuário, chamar uma tool que modifica estado, aprovar uma solicitação).

Ponto de decisão no agent loop:

  1. Agente recebe tarefa/pergunta
  2. Harness resolve: esta tarefa requer grounding?
     (nem toda tarefa requer — "resuma este texto que colei"
     não precisa consultar índice nenhum; "qual é a política de
     reembolso atual" precisa)
  3. SE requer grounding:
       consulta o serviço de grounding (capítulo 2.1-2.3)
       recebe: chunks + sinal de cobertura

       SE cobertura == "alta":
           prossegue com ação, chunks como evidência primária
       SE cobertura == "media" | "baixa":
           prossegue com ressalva explícita na resposta
           ("não encontrei confirmação completa sobre X")
           OU aciona busca adicional (outro índice, escopo mais
           amplo) antes de decidir
       SE cobertura == "nenhuma":
           NÃO prossegue com ação que dependa do fato ausente
           escala para humano (HITL, Parte 1.3) ou recusa
           explicitamente, nunca preenche a lacuna com
           conhecimento paramétrico apresentado como fato
           específico da empresa
  4. SE não requer grounding:
       prossegue direto com conhecimento paramétrico,
       mas isso é uma decisão registrada, não uma omissão

O detalhe arquitetural essencial no passo 2: a decisão de "esta tarefa requer grounding" não deveria ser deixada inteiramente a critério do próprio LLM dentro do loop, pela mesma razão que resolução de tools não é deixada a critério livre do agente (Parte 1.5) — é uma política do harness, que pode ser tão simples quanto uma classificação de intenção (a pergunta menciona entidade específica da empresa? cita data, contrato, política?) rodando antes do LLM sequer começar a formular resposta.

Conectando com os padrões de loop da Parte 1

O gate de grounding se encaixa de forma diferente em cada padrão de loop de agente estabelecido em 1.6, e vale nomear a diferença:

O padrão comum aos três: em nenhum caso o gate de grounding é opcional ou incidental — em cada padrão de loop, existe um ponto estrutural específico onde ele precisa ser avaliado, e adiar essa avaliação para "quando o LLM achar que precisa" reintroduz exatamente a fragilidade que a Parte 1 já endereçou para permissões e estado.

Aprofundamento Técnico

O custo de agir sem grounding suficiente é assimétrico

Vale nomear explicitamente por que este gate merece ser rígido em vez de "melhor esforço". O custo de falso negativo (bloquear uma ação que na verdade tinha base suficiente) e o custo de falso positivo (deixar passar uma ação sem base suficiente) não são simétricos na maioria dos contextos corporativos.

Essa assimetria é o argumento para calibrar o limiar de cobertura de forma conservadora — errar para o lado de pedir mais confirmação é estruturalmente mais barato que errar para o lado de agir com confiança indevida. É a mesma lógica de raio de impacto da Parte 1.3: quanto maior a irreversibilidade da ação a jusante, mais rígido deveria ser o limiar de cobertura que a autoriza.

Grounding insuficiente não é sempre "buscar mais" — às vezes é "a pergunta é a resposta errada"

Um refinamento importante do gate: cobertura baixa não significa sempre que o índice tem a resposta e a busca precisa melhorar. Às vezes significa que a base de conhecimento genuinamente não cobre aquele domínio — e a ação correta do harness é sinalizar isso como fato, não como falha de retrieval a ser corrigida com mais tentativas.

Diagnóstico de cobertura baixa — duas causas distintas:

Distinguir as duas causas evita um antipadrão comum: um agente que entra em loop de refinamento de busca indefinidamente contra uma lacuna real de conhecimento, gastando ciclos de custo (tema da Parte 5) atrás de algo que não está — e nunca vai estar — no índice. Um harness bem projetado limita o número de tentativas de refinamento antes de tratar cobertura persistentemente baixa como Causa B e escalar.

O gate de grounding como pré-condição, não como tool entre outras

Fechando o argumento central deste capítulo e desta parte: se grounding fosse modelado como "mais uma tool que o agente pode chamar" (equivalente a uma calculadora ou um lookup de CEP), o motor de resolução condicional da Parte 1.5 trataria sua ausência de chamada como uma escolha válida do agente — afinal, tools são opcionais por definição. O argumento deste capítulo é que, para tarefas que dependem de fato específico e verificável, consultar grounding não é uma tool opcional entre outras — é uma pré-condição estrutural da ação, no mesmo nível arquitetural de uma verificação de permissão.

Modelagem errada (grounding como tool opcional):
  tools_disponíveis = [buscar_conhecimento, enviar_email,
                        aprovar_solicitacao, ...]
  → agente decide livremente se chama buscar_conhecimento antes
  de aprovar_solicitacao; nada estrutural impede pular direto
  para a ação

Modelagem correta (grounding como pré-condição de gate):
  antes de permitir ação_com_impacto_factual:
      exigir(gate_de_grounding.cobertura >= limiar_da_ação)
  → a ação em si SÓ é resolvida pelo motor de tools (Parte 1.5)
  se o gate já passou; grounding não é uma opção do menu, é uma
  porta que precisa estar aberta antes do menu aparecer

Essa é a razão pela qual esta parte termina aqui, e não com "mais um capítulo sobre RAG avançado": o objetivo da Parte 2 nunca foi ensinar a montar um pipeline RAG melhor — isso o leitor já sabe fazer, é pré-requisito. O objetivo foi mostrar onde essa infraestrutura se encaixa no harness que a Parte 1 construiu, e por que a ordem — saber antes de agir — não é um detalhe de implementação, é o princípio de arquitetura que sustenta agentes confiáveis em produção.