Bedrock Knowledge Base agora permite escolher a profundidade da busca: de 0 chamadas ao LLM até RAG agêntico

De manhã, um funcionário de banco pergunta ao assistente interno de IA quais documentos são necessários para abrir uma conta de MEI (ИП, na versão russa do exemplo). A resposta está em um único checklist. À tarde, o mesmo funcionário pergunta quais são as diferenças de exigências entre ИП, ООО e sociedades com vários proprietários. Agora a resposta está espalhada por vários regulamentos. O assistente é o mesmo, mas as perguntas variam muito em complexidade e em custo. Se você rodar um pesado ciclo agêntico nas duas, vai pagar mais e perder em latência. Se fizer uma única busca nas duas, vai perder precisão na pergunta complexa.

A AWS fecha essa lacuna no Amazon Bedrock Managed Knowledge Base. Antes, o AgenticRetrieveStream oferecia apenas o modo agêntico. Agora há mais dois.

Um parâmetro em vez de duas APIs

Tudo é controlado pelo maxAgentIteration. O intervalo agora vai de 0 a 5, e o comportamento da consulta depende do valor.

0 — só busca. O serviço faz uma busca garantida e não gera nada. Não há chamadas a foundation models; na prática, é o equivalente à Retrieve API tradicional. O modo é útil para quem já migrou para o AgenticRetrieveStream e não quer trocar de API só para fazer uma consulta sem geração. Se você definir generateResponse=true com o valor zero, a chamada retorna erro 4xx: gerar uma resposta exige um LLM.

1 — RAG clássico. Uma busca, uma chamada ao modelo para responder, sem planejamento e sem reescrita da consulta. O exemplo do artigo é: «Quais documentos são necessários para abrir uma conta empresarial de ИП?». O checklist está na base, então o planejador só adicionaria latência. Se a maior parte do seu tráfego é de perguntas diretas e bem delimitadas, a AWS sugere que este seja o seu padrão.

2–5 — modo agêntico. O modelo divide a pergunta em subconsultas, busca por cada uma, avalia se o que encontrou é suficiente e, se necessário, refina a busca ou puxa o documento inteiro. Os valores de 2 a 5 funcionam como antes, e as consultas existentes não deixam de funcionar.

Como as iterações são contadas

A regra é simples: uma iteração equivale a uma chamada ao foundation model. A última iteração sempre é usada para gerar a resposta. Por isso, o valor n permite até n−1 rodadas de planejamento, e cada rodada consiste em reescrever a consulta e fazer a busca.

Há um detalhe. A busca especulativa, que é disparada antes da primeira etapa de planejamento, não conta como iteração. Ela não consome o limite e pode apenas acelerar a consulta.

A AWS também ressalta que busca única não significa uma única base de conhecimento. Os três modos, inclusive 0 e 1, funcionam com várias bases. O modo agêntico acrescenta a decomposição da pergunta, a avaliação das evidências encontradas e a busca iterativa, mas o suporte a múltiplas bases não depende dele.

No exemplo do banco, fica assim. Para a pergunta sobre o checklist de ИП, definimos maxAgentIteration=1 e generateResponse=true. Para comparar ИП e ООО com verificações de não residentes, definimos 4, ou seja, até três rodadas de planejamento. Quando o funcionário precisa do texto do regulamento em si, e não de um resumo, definimos 0 e generateResponse=false, e o aplicativo exibe as passagens com links para as fontes. Passar de uma chamada agêntica para um RAG comum é questão de alterar um número no JSON.

Limitações e o que fazer na prática

O principal: a escolha do modo continua por conta do seu aplicativo. Não há roteamento automático por complexidade da pergunta. É preciso um roteador simples (por tipo de cenário, por heurística ou por um classificador pequeno) ou fixar o modo para uma tela ou funcionalidade específica.

Segundo: o formato da resposta no modo 0 difere do Retrieve direto. As passagens deduplicadas chegam no evento result do stream, sem os campos score e location. Se a sua interface depende da pontuação de relevância ou da localização exata do trecho, verifique isso antes de migrar.

Terceiro: os exemplos com o banco no artigo são ilustrativos. A AWS não apresenta medições de latência, custo ou qualidade. A afirmação de que o single-shot reduz a latência e o gasto com o modelo em comparação com o modo agêntico é lógica, mas não vem acompanhada de números. Não a aceite na fé.

O plano prático é este:

• Monte um conjunto de perguntas reais, com respostas de referência extraídas dos seus documentos.
• Rode o conjunto no modo 1 e na sua configuração agêntica atual, sobre a mesma base de conhecimento.
• Meça a latência e o custo da consulta e verifique se as respostas estão corretas e respaldadas pelas passagens encontradas.
• Inclua obrigatoriamente perguntas cuja resposta precisa ser montada a partir de vários documentos. É nelas que a busca única costuma perder desempenho.

Se hoje o modo agêntico é o padrão no seu ambiente, é grande a chance de você estar pagando, em consultas simples, por um planejamento que não agrega nada. Comece com um valor baixo para o tráfego simples e aumente onde a precisão em perguntas complexas pesar mais que a velocidade. O limite de iterações também deve ser calibrado com os seus próprios dados: mais iterações nem sempre significam uma resposta melhor.