AI Search: a nova primitiva de busca da Cloudflare para seus agentes de IA
AI Search é a nova aposta da Cloudflare para resolver um dos maiores gargalos de quem constrói agentes de IA hoje: encontrar a informação certa, na hora certa, sem precisar montar toda uma infraestrutura de busca do zero.
Se você já tentou adicionar busca a um agente, sabe como isso pode virar uma bagunça rapidinho. Você precisa de um índice vetorial, um pipeline de indexação, lógica para manter tudo atualizado e, se quiser busca por palavras-chave também, aí é outro índice separado com fusão de resultados por cima. Multiplica isso pelo número de agentes que você tem rodando e a coisa fica complexa bem rápido.
É exatamente esse problema que o AI Search, anteriormente conhecido como AutoRAG, vem resolver. A Cloudflare anunciou em abril de 2026 uma atualização significativa da ferramenta, trazendo busca híbrida, armazenamento embutido por instância, criação dinâmica via binding no Worker e suporte a múltiplas instâncias numa única consulta. Na prática, isso significa que você consegue entregar ao seu agente um mecanismo de busca completo com muito menos configuração, e ainda com resultados mais precisos do que qualquer abordagem isolada conseguiria sozinha 🚀
Neste artigo, a gente mergulha nas novidades do AI Search, entende como a busca híbrida funciona por dentro e ainda vê tudo isso em ação num caso real de suporte ao cliente.
O que mudou no AI Search em relação ao AutoRAG
Quando a Cloudflare lançou o AutoRAG, a proposta já era interessante: uma camada gerenciada de RAG (Retrieval-Augmented Generation) que abstraía boa parte da complexidade de busca semântica para agentes de IA. Mas, com o tempo, ficou claro que os desenvolvedores precisavam de algo mais flexível, mais poderoso e, principalmente, mais fácil de integrar em fluxos de trabalho dinâmicos. A renomeação para AI Search não é só cosmética, ela acompanha uma reformulação real de como a ferramenta funciona por dentro e como ela se encaixa no ecossistema de agentes da Cloudflare.
A primeira grande mudança é o armazenamento embutido por instância. Antes, era necessário criar um bucket R2, vincular a uma instância do AI Search e gerenciar o índice Vectorize provisionado na conta. Agora, cada nova instância do AI Search já vem com seu próprio armazenamento e índice vetorial integrados, alimentados por R2 e Vectorize nos bastidores. Você faz upload de arquivos diretamente pela API, eles são indexados automaticamente, e não precisa configurar buckets externos nem conectar fontes de dados antes. Isso simplifica absurdamente o ciclo de vida dos dados dentro do agente e reduz o número de peças móveis que você precisa gerenciar.
A criação dinâmica via binding no Worker é outro salto considerável. O novo binding ai_search_namespaces permite criar e excluir instâncias em tempo de execução diretamente do seu Worker. Isso substitui a API anterior env.AI.autorag(), que acessava o AI Search através do binding AI. Em vez de pré-configurar instâncias de forma estática antes de o agente rodar, agora é possível instanciar o AI Search diretamente no código, abrindo espaço para arquiteturas muito mais adaptáveis. Você pode criar uma instância por agente, por cliente ou por idioma, sem precisar fazer redeploy.
E o suporte a múltiplas instâncias numa única consulta complementa exatamente isso: você pode reunir resultados de bases de conhecimento diferentes com uma única chamada, algo que antes exigiria lógica de orquestração manual considerável. Também é possível anexar metadados aos documentos e usá-los para impulsionar rankings no momento da consulta.
Como a busca híbrida funciona por dentro
A busca híbrida é, sem dúvida, o coração técnico desta atualização. Até agora, o AI Search oferecia apenas busca vetorial. Busca vetorial é excelente para capturar similaridade semântica: você pergunta sobre atendimento pós-venda, e o sistema encontra documentos que falam sobre suporte mesmo que não usem exatamente essas palavras. Mas ela pode perder especificidades. Numa consulta como ERR_CONNECTION_REFUSED timeout, o embedding captura o conceito amplo de falhas de conexão, mas o usuário não está procurando docs gerais de rede. Ele quer o documento específico que menciona aquele código de erro exato. A busca vetorial pode retornar resultados sobre troubleshooting sem nunca trazer a página que contém aquela string.
Já a busca por palavras-chave resolve exatamente isso. O AI Search agora suporta BM25, uma das funções de pontuação de recuperação mais utilizadas no mundo. O BM25 pontua documentos considerando a frequência dos termos da consulta, a raridade desses termos no corpus inteiro e o comprimento do documento. Ele recompensa correspondências em termos específicos, penaliza palavras comuns de preenchimento e normaliza pelo tamanho do documento. Porém, o BM25 pode perder uma página sobre troubleshooting de conexões de rede, mesmo que ela descreva exatamente o mesmo problema, só com palavras diferentes. É aí que a busca vetorial brilha, e por isso você precisa das duas.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
Quando a busca híbrida está ativa, o AI Search executa as duas estratégias em paralelo, funde os resultados e opcionalmente os reranqueia. O pipeline de recuperação é multi-etapas, e cada etapa é configurável 🔍
Tokenizador
O tokenizador controla como seus documentos são quebrados em termos correspondíveis no momento da indexação. A opção Porter stemmer reduz palavras à raiz, então running corresponde a run. A opção Trigram faz correspondência de substrings de caracteres, então conf corresponde a configuration. Use Porter para conteúdo em linguagem natural como documentação, e Trigram para código onde correspondências parciais importam.
Modo de correspondência por palavras-chave
Esse modo controla quais documentos são candidatos para pontuação BM25 no momento da consulta. O modo AND exige que todos os termos da consulta apareçam no documento. O modo OR inclui qualquer documento com pelo menos uma correspondência.
Fusão de resultados
A fusão controla como os resultados vetoriais e de palavras-chave são combinados na lista final. A Reciprocal Rank Fusion (RRF) mescla por posição no ranking em vez de pontuação, evitando comparar duas escalas de pontuação incompatíveis. Já a Max Fusion simplesmente pega a pontuação mais alta.
Reranking opcional
Adicionalmente, é possível habilitar um passo de reranking com cross-encoder que repontuada os resultados avaliando a consulta e o documento juntos como um par. Isso ajuda a capturar casos onde um resultado tem os termos certos mas não está realmente respondendo à pergunta.
Cada opção tem um padrão sensato quando omitida, e você tem a flexibilidade de configurar o que importa sempre que criar uma nova instância.
Boost de relevância: surfando no que realmente importa
A recuperação traz resultados relevantes, mas relevância sozinha nem sempre é suficiente. Em uma busca por resultados eleitorais, por exemplo, um artigo da semana passada e um de três anos atrás podem ser igualmente relevantes semanticamente, mas a maioria dos usuários provavelmente quer o mais recente. O boost de relevância permite sobrepor lógica de negócio ao ranking de recuperação, ajustando posições com base em metadados do documento.
Você pode fazer boost por timestamp, que é embutido em cada item, ou por qualquer campo de metadado customizado que você defina. Isso permite que documentos mais recentes, de maior prioridade ou de categorias específicas subam no ranking sem alterar a lógica de busca em si. É uma camada extra de inteligência que torna o sistema muito mais útil em cenários reais.
AI Search na prática: agente de suporte ao cliente
Para entender onde tudo isso converge de forma concreta, a Cloudflare apresentou um exemplo detalhado de um agente de suporte que busca dois tipos de conhecimento: documentação compartilhada do produto e histórico por cliente, como resoluções anteriores de problemas. A documentação do produto é grande demais para caber na janela de contexto, e o histórico de cada cliente cresce a cada problema resolvido. Então o agente precisa de recuperação para encontrar o que é relevante.
A arquitetura funciona assim: a documentação compartilhada do produto vive em um bucket R2 conectado a uma instância fixa do AI Search chamada product-knowledge, criada uma única vez no dashboard da Cloudflare. Essa é a base de conhecimento que todos os agentes podem referenciar.
Para o histórico de cada cliente, o agente cria uma instância do AI Search dinamicamente usando o binding de namespace. Quando um cliente aparece pela primeira vez, uma instância exclusiva é criada. Depois de cada problema resolvido, o agente salva um resumo do que deu errado e como foi corrigido. Com o tempo, isso constrói um log pesquisável de resoluções anteriores.
A estrutura do namespace fica mais ou menos assim: dentro do namespace support, existe a instância product-knowledge usando R2 como fonte e compartilhada entre todos os agentes, e instâncias individuais por cliente usando armazenamento gerenciado. O agente então usa o Agents SDK da Cloudflare e define duas ferramentas que o modelo de linguagem pode chamar conforme a conversa evolui.
A primeira ferramenta é a busca na base de conhecimento. Quando acionada, ela consulta tanto a documentação do produto quanto o histórico do cliente numa única chamada, usando o recurso de busca entre instâncias. Resultados são mesclados e ranqueados juntos. A segunda ferramenta salva a resolução: depois de resolver um problema, o agente grava um resumo que é imediatamente indexado e fica pesquisável para conversas futuras. O método uploadAndPoll espera até que a indexação esteja completa antes de retornar, garantindo consistência.
O modelo utilizado no exemplo é o Kimi K2.5 via Workers AI, e ele decide automaticamente quando chamar cada ferramenta com base no contexto da conversa. Isso significa que, ao longo do tempo, o agente fica mais inteligente para cada cliente específico, porque acumula contexto de resoluções anteriores e evita repetir correções que já falharam 💡
Como as instâncias do AI Search funcionam agora
Se você usou o AI Search antes desta versão, conhece o setup anterior: criar um bucket R2, vincular a uma instância, o AI Search gera um token de API de serviço, e você gerencia o índice Vectorize provisionado na conta. Upload de um objeto exigia escrever no R2 e depois esperar um job de sincronização rodar para que o objeto fosse indexado.
As novas instâncias funcionam de forma diferente. Quando você chama create(), a instância já vem com armazenamento e índice vetorial embutidos. Você faz upload de um arquivo, ele é enviado para indexação imediatamente, e você pode acompanhar o status da indexação com uma única chamada uploadAndPoll(). Uma vez completada, a instância já está pesquisável. Não há dependências externas para conectar.
Cada instância também pode se conectar a uma fonte de dados externa, seja um bucket R2 ou um site, e rodar em um cronograma de sincronização. A fonte externa pode coexistir com o armazenamento embutido. No exemplo do agente de suporte, product-knowledge é alimentado por um bucket R2 para documentação compartilhada, enquanto as instâncias por cliente usam armazenamento embutido para contexto carregado dinamicamente.
Namespaces: criação de instâncias em tempo de execução
O binding ai_search_namespaces é a nova forma de criar instâncias de busca dinamicamente. Ele expõe APIs como create(), delete(), list() e search() no nível do namespace. Se você está criando instâncias dinamicamente, seja por agente, por cliente ou por tenant, este é o binding certo. Os bindings antigos continuam funcionando através das datas de compatibilidade do Workers.
Preços e limites durante o beta aberto
As novas instâncias criadas a partir de agora recebem armazenamento embutido e índice vetorial automaticamente. Essas instâncias são gratuitas enquanto o AI Search estiver em beta aberto, dentro dos limites estabelecidos. Quando se usa um site como fonte de dados, o crawling via Browser Run, antigo Browser Rendering, agora é um serviço embutido e não será cobrado separadamente.
No plano Workers Free, os limites incluem 100 instâncias por conta, 100 mil arquivos por instância, tamanho máximo de 4MB por arquivo, 20 mil consultas por mês e 500 páginas crawleadas por dia. No plano Workers Paid, os números sobem para 5 mil instâncias por conta, 1 milhão de arquivos por instância ou 500 mil para busca híbrida, tamanho máximo de 4MB, consultas ilimitadas e crawling ilimitado.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
Após o beta, o objetivo é oferecer uma precificação unificada para o AI Search como um serviço único, em vez de cobrar separadamente por cada componente subjacente. O uso de Workers AI e AI Gateway continuará sendo cobrado à parte. A Cloudflare se comprometeu a dar pelo menos 30 dias de aviso e comunicar detalhes de preço antes de qualquer cobrança começar.
Para instâncias criadas antes desta versão, elas continuam funcionando exatamente como estão. Buckets R2, índices Vectorize e uso do Browser Run permanecem na conta e são cobrados como antes. Detalhes de migração serão compartilhados em breve.
O que isso representa para quem constrói agentes hoje
O movimento da Cloudflare com o AI Search diz muito sobre como a construção de agentes de IA está evoluindo. A tendência clara é que as peças de infraestrutura que antes exigiam configuração manual extensiva, como índices vetoriais, pipelines de indexação, lógica de fusão de resultados e orquestração de múltiplas fontes de dados, estão sendo absorvidas por plataformas gerenciadas que expõem APIs simples e diretas. Isso não significa que a complexidade desapareceu, ela só foi encapsulada em camadas mais robustas e testadas, liberando os times de produto para focar no que realmente importa: o comportamento do agente e a qualidade da experiência que ele entrega.
Para quem está construindo agentes hoje, o impacto mais imediato é a redução do tempo entre a ideia e o agente funcional. Com o AI Search, você não precisa mais provisionar um banco vetorial separado, configurar embeddings, montar um pipeline de ingestão, adicionar um mecanismo de busca por palavras-chave e depois escrever a lógica que une tudo isso. Você declara uma instância, aponta para seus documentos e a ferramenta cuida do resto. Isso é especialmente valioso em times pequenos ou em projetos onde a velocidade de iteração é crítica, como produtos em fase de validação ou projetos internos de automação.
A evolução do AutoRAG para o AI Search também sinaliza uma maturidade crescente no mercado de ferramentas para IA generativa. Cada vez mais, as plataformas estão saindo do modo experimental e entregando primitivas de produção: confiáveis, escaláveis e integradas ao ecossistema existente. A busca híbrida nativa, o armazenamento embutido e a criação dinâmica de instâncias não são só features interessantes no papel, elas representam escolhas de arquitetura que tornam os agentes mais robustos e mais fáceis de manter ao longo do tempo.
Vale destacar que a busca no próprio blog da Cloudflare agora é alimentada pelo AI Search, o que serve como uma vitrine real da capacidade da ferramenta em ambiente de produção.
O AI Search já está disponível para desenvolvedores que utilizam a plataforma Cloudflare Workers AI. Para começar, basta rodar o comando npx wrangler ai-search create my-search e criar sua primeira instância. A documentação completa está disponível no site de desenvolvedores da Cloudflare, e novas capacidades de indexação e conectores de fonte de dados devem chegar nas próximas atualizações.
