Grounding atual e FinOps de IA
Manter o agente atualizado com web search, e manter a conta de IA barata e previsível.
7 min de leitura
Escolha como aprender
combine como quiserDica: o vídeo é um resumo visual rápido; o áudio e o texto trazem a aula completa. Terminar o áudio ou o vídeo, ou passar no quiz, já conta a aula como concluída.
Um agente que só conhece o que estava no seu conjunto de treino é um agente que vive no passado, e cobra caro por isso. Nesta aula fechamos o Módulo 4 unindo dois problemas práticos que todo arquiteto enfrenta na hora de colocar IA em produção: como manter o agente factualmente atualizado sem explodir o contexto, e como manter a conta da AWS abaixo de um valor que o seu gestor aprove sem pestanejar.
Grounding: por que o modelo precisa de fatos de hoje
LLMs têm uma data de corte. Tudo o que aconteceu depois disso, novos serviços AWS, mudanças de preço, artigos publicados ontem, simplesmente não existe para o modelo. O resultado prático é alucinação por desatualização: o modelo responde com confiança sobre algo que mudou.
Grounding é a prática de injetar fatos verificáveis e atuais no contexto antes da geração. A forma mais direta é web search: o agente emite uma query, recebe snippets reais de páginas indexadas hoje, e usa esses snippets como base para a resposta. Isso não elimina alucinação, mas troca a fonte de erro, em vez de inventar, o modelo passa a citar.
No Bedrock AgentCore, web search é uma tool nativa que o agente pode invocar dentro do loop ReAct (vimos esse loop na Aula 11). O fluxo é simples: o modelo decide que precisa de informação atual, chama a tool de search, recebe os resultados como texto estruturado, e incorpora ao raciocínio antes de responder. O custo adicional é real, cada chamada de search tem latência e pode aumentar o número de tokens processados, mas o ganho em confiabilidade costuma justificar, especialmente em domínios que mudam rápido: preços, regulações, releases de produto.
Uso esse padrão no meu próprio site: os artigos e estudos de caso são gerados com um agente que faz web search no Bedrock AgentCore antes de redigir qualquer afirmação factual. O resultado é conteúdo fundamentado em fontes reais, não em memória de treino.
Fluxo de grounding com web search no Bedrock AgentCore
O agente decide quando precisa de fatos atuais, chama a tool de search, recebe snippets reais e os injeta no contexto antes de gerar a resposta final.
- Usuário · Pergunta factual
- Orchestrator · Loop ReAct
- LLM (ex: Claude) · Raciocínio + geração
- Web Search Tool · Bedrock AgentCore
- Knowledge Base · Dados internos (RAG)
- Prompt Cache · Reutiliza prefixo
- Web Index · Snippets atuais
Na prática, uso web search como primeira etapa de qualquer artigo técnico que publico. O agente faz a busca, cita as fontes nos snippets, e só então redige. O custo extra por chamada de search é real, mas é marginal comparado ao custo de publicar algo factualmente errado. Meu conselho: ative grounding para qualquer claim que mude com o tempo, preços, versões de API, benchmarks, e desative para conteúdo estático onde o RAG interno já cobre.
FinOps de IA: as alavancas que realmente movem a conta
IA generativa cobra por token, entrada e saída separadamente, e o preço varia muito entre modelos. Isso muda a lógica de custo em relação a workloads tradicionais: não existe custo de infraestrutura ociosa no modelo serverless do Bedrock, mas existe custo de contexto desnecessário, modelo superdimensionado e ausência de cache.
Escolha de modelo por tarefa é a alavanca mais impactante. Um modelo grande e caro (ex: Claude Sonnet) faz sentido para raciocínio complexo, síntese e geração criativa. Para classificação, extração de campos ou roteamento de intenção, um modelo menor e mais barato (ex: Claude Haiku, Titan Text Lite) entrega o mesmo resultado a uma fração do custo. A regra prática: use o menor modelo que passa nos seus evals (Aula 09).
Prompt cache é a segunda alavanca. Se o seu system prompt tem 2 000 tokens e você faz 10 000 chamadas por dia, você está pagando por 20 milhões de tokens de entrada que são idênticos. O Bedrock suporta cache de prefixo: tokens em cache custam significativamente menos que tokens processados normalmente. Estruture seus prompts colocando a parte estável (instruções, contexto fixo) no início, é ela que será cacheada.
Limites de tokens e orçamentos fecham o ciclo. Configure cotas no AWS Budgets e alertas no CloudWatch para token throughput. No Bedrock AgentCore, você pode definir limites de iteração no loop do agente, um agente que entra em loop por bug pode gerar centenas de chamadas em segundos. Limite de iterações é tanto segurança quanto FinOps.
Alavancas de FinOps em IA: impacto e esforço
| Alavanca | Redução de custo típica | Esforço de implementação | Quando aplicar |
|---|---|---|---|
| Modelo menor por tarefa | Alto (50–90% por chamada) | Médio, requer evals por tarefa | Tarefas repetitivas e bem definidas |
| Prompt cache (prefixo estático) | Médio-alto (depende do volume) | Baixo, reestruturar o prompt | System prompts longos + alto volume |
| Limitar contexto / janela | Médio (tokens de entrada diretos) | Baixo, truncar histórico e chunks RAG | Agentes com histórico longo |
| Serverless (sem instância ociosa) | Alto para workloads esporádicos | Nenhum, padrão no Bedrock | Sempre (exceto throughput reservado) |
| Limite de iterações do agente | Proteção contra runaway cost | Baixo, configuração no AgentCore | Todo agente em produção |
| AWS Budgets + alertas | Não reduz, mas evita surpresas | Baixo, configuração de billing | Sempre, desde o primeiro dia |
Mantendo um sistema real abaixo de poucos dólares por mês
A pergunta que mais recebo de desenvolvedores iniciando com IA na AWS é: "quanto vai custar?" A resposta honesta é: depende de volume, mas um sistema bem arquitetado para uso pessoal ou pequeno time pode rodar por menos de cinco dólares por mês sem nenhum truque obscuro.
O segredo está em três decisões de design tomadas cedo. Primeiro, use modelos leves para o roteamento e modelos pesados só para geração final. Um agente que classifica intenção com Haiku e só chama Sonnet para redigir a resposta final pode ter 80% das chamadas a custo de centavos. Segundo, limite o tamanho dos chunks de RAG. Chunks grandes aumentam a precisão da recuperação marginalmente, mas aumentam o custo de entrada linearmente: 500 tokens por chunk é um bom ponto de partida para a maioria dos casos. Terceiro, não armazene histórico infinito no contexto. Implemente uma janela deslizante ou sumarização periódica (vimos as estratégias de memória na Aula 12).
Para o meu site, o custo mensal de IA fica abaixo de dez dólares processando dezenas de artigos, porque o agente usa Haiku para busca e triagem, Sonnet só para redigir, e o prompt de instrução fica em cache. Não é magia, é escolha consciente de modelo por etapa do pipeline.
Um último ponto sobre throughput reservado no Bedrock: faz sentido financeiro apenas quando você tem volume previsível e alto. Para a maioria dos projetos em fase inicial, o modo serverless on-demand é mais barato e mais simples. Reserve throughput quando os seus evals de custo mostrarem que o break-even foi atingido.
Alavancas de FinOps em IA
Toque num conceito e depois na definição.
O que lembrar desta aula
Perguntas frequentes
Web search no AgentCore sempre melhora a qualidade da resposta?
Não. Se a query de search for mal formulada ou os snippets retornados forem de fontes de baixa qualidade, o modelo pode citar informação errada com mais confiança do que se não tivesse feito a busca. Grounding melhora a qualidade quando a tool de search é bem configurada e os snippets são relevantes. Avalie com evals (Aula 09) antes de ativar em produção.
Prompt cache funciona automaticamente no Bedrock?
Depende do modelo e da configuração. Alguns modelos no Bedrock suportam cache de prefixo, mas você precisa estruturar o prompt corretamente e, em alguns casos, habilitar explicitamente. Consulte a documentação do modelo específico, nem todos os modelos disponíveis no Bedrock suportam cache da mesma forma.
Qual é o risco de usar modelos menores para economizar?
Qualidade de saída menor para tarefas complexas. O risco real é usar um modelo pequeno numa tarefa que exige raciocínio multi-etapa e não perceber a degradação porque você não tem evals. A mitigação é simples: defina evals antes de trocar de modelo, não depois.
Throughput reservado no Bedrock vale a pena para startups?
Raramente no início. Throughput reservado exige compromisso de volume e pagamento antecipado. Para a maioria das startups em fase de crescimento, o modelo on-demand é mais flexível e mais barato até que o volume seja previsível e estável. Reavalie quando os seus custos on-demand mensais forem consistentemente altos.
Fechando o Módulo 4
Grounding e FinOps parecem temas separados, mas têm a mesma raiz: decisões de arquitetura que você toma antes de escrever a primeira linha de código. Escolher quando buscar fatos externos, qual modelo usar em cada etapa, o que cachear e o que limitar, tudo isso define se o seu sistema é confiável e sustentável ou se é um protótipo caro que ninguém coloca em produção. O Módulo 4 cobriu os blocos fundamentais da arquitetura de IA na AWS: Bedrock, AgentCore, Knowledge Bases, e agora custo e atualidade. No próximo módulo, vamos olhar para a decisão mais importante de todas: quando usar IA e quando não usar.