Loop engineering: a camada que faz seu RAG se recuperar em vez de girar em círculos

O que é loop engineering e por que ele virou o assunto da vez

Depois da engenharia de prompt e da engenharia de contexto, uma terceira disciplina passou a dominar as conversas entre engenheiros de IA em 2026: a engenharia de loops. O termo ganhou força depois que Boris Cherny, o engenheiro da Anthropic por trás do Claude Code, afirmou ter praticamente parado de escrever prompts manuais — em vez disso, ele escreve loops que acionam o modelo repetidamente até uma condição ser satisfeita.

Um artigo detalhado do Towards Data Science, assinado por Angela Shi, aplica essa ideia a um cenário menos glamouroso e muito mais comum: pipelines de RAG em ambientes corporativos. Num agente de código com uma suíte de testes para conferir, o loop funciona quase sozinho. Já num pipeline de RAG empresarial, o loop é exatamente a parte que precisa ser projetada — porque as falhas que ele absorve são corriqueiras: o parser achata a única tabela que importava, a recuperação retorna a página vizinha da certa, o modelo devolve um JSON que não passa no schema ou a API cai no meio de um lote.

A anatomia de um loop: três superfícies de controle

Todo loop, pequeno ou grande, tem as mesmas três alavancas — e é mais fácil projetá-las separadamente do que juntas:

• Gatilho (trigger): a condição que dispara uma nova chamada. Pode ser a validação de schema que falhou, um “auto-sinalizador” no próprio retorno (como um campo complete_answer_found em false ou confiança abaixo de 0,6) ou uma falha transitória de API (timeout, 429, 5xx).
• Terminação (termination): a condição que faz o loop parar. “Loop até concluir” (o predicado foi satisfeito), “loop até o orçamento” (esgotou o número de tentativas ou o tempo) ou um “teto rígido” que interrompe incondicionalmente após N tentativas.
• Recuperação (recovery): o que acontece quando a chamada falha. A opção mais simples é o retry com backoff — seis tentativas com esperas de 2, 4, 8, 16, 32 e 60 segundos mais um jitter. Alternativas mais ricas: trocar de modelo, escalar para revisão humana ou pular o item e devolver o que já foi computado.

A regra anti-giro: todo retry precisa mudar algo

A regra mais importante — e a mais simples — é esta: um loop só deve tentar de novo quando algo mudou entre uma tentativa e a próxima. Um loop que dispara o gatilho, repete o mesmo payload, recebe a mesma falha e repete de novo não é um loop: é um ataque de negação de serviço contra o próprio orçamento de API.

Há três coisas legítimas para mudar entre tentativas:

1. O payload: ampliar o escopo da recuperação, adicionar uma restrição ao prompt ou reformular a pergunta.
2. O modelo: o modelo pequeno devolveu lixo, o modelo maior ganha a segunda chance.
3. A estratégia: a busca por palavras-chave falhou, a segunda tentativa usa recuperação densa.

A regra operacional: todo retry deve carregar um registro que nomeie o que mudou. Se o registro está vazio, o retry não deveria ter acontecido.

Loops pequenos e loops grandes

Os loops se organizam em duas escalas. Os loops pequenos vivem dentro de uma única “peça” do pipeline: o parser de documentos roda uma cascata de imagens, a recuperação desce o índice até a subseção certa, a geração refaz o JSON quando o schema falha. Os loops grandes cruzam peças: a geração lê a própria entrada, decide que ela não serve para responder e devolve o pipeline para uma etapa anterior — reparsear a página com um parser mais profundo, resolver uma referência pendente ou ampliar o escopo da recuperação.

Três modos de falha que a disciplina previne

• Loop infinito em falha transitória: sem um teto rígido, a API queima o orçamento a noite inteira retentando um 429. A correção é um teto + um erro explícito + alerta.
• Girando numa falha determinística: o schema rejeita o JSON porque o modelo escreveu um campo com typo, e o retry repete o mesmo prompt — seis vezes, seis rejeições. A correção é incluir a mensagem de erro do validador no próximo prompt.
• Flag de confiança ignorada: a resposta volta com confiança 0,3 e o dispatcher entrega ao usuário sem avisar. A correção é aplicar um limiar e escalar ou rotular a resposta como baixa confiança.

Os três loops e o humano no centro

Usando um quadro popularizado por Andrew Ng, o artigo encerra lembrando que há três loops rodando em ritmos diferentes: o loop interno (segundos a minutos, o dispatcher decidindo sozinho), o loop de desenvolvimento (minutos a horas, o engenheiro lendo a trilha de auditoria e corrigindo dicionários e schemas) e o loop externo (horas a semanas, o especialista humano corrigindo um campo extraído e alimentando o sistema com novo conhecimento). O ponto de Ng é que, enquanto o humano souber algo que a IA não sabe, esse loop externo não pode ser fechado por mais automação — e tratá-lo como ruído a ser eliminado é o erro.