AI Search: la nueva primitiva de búsqueda de Cloudflare para tus agentes de IA
AI Search es la nueva apuesta de Cloudflare para resolver uno de los mayores cuellos de botella de quienes construyen agentes de IA hoy: encontrar la información correcta, en el momento adecuado, sin necesidad de montar toda una infraestructura de búsqueda desde cero.
Si alguna vez intentaste agregar búsqueda a un agente, sabes cómo eso puede volverse un lío bastante rápido. Necesitas un índice vectorial, un pipeline de indexación, lógica para mantener todo actualizado y, si también quieres búsqueda por palabras clave, entonces es otro índice separado con fusión de resultados encima. Multiplica eso por la cantidad de agentes que tienes corriendo y la cosa se complica muy rápido.
Es exactamente ese problema el que AI Search, antes conocido como AutoRAG, viene a resolver. Cloudflare anunció en abril de 2026 una actualización significativa de la herramienta, trayendo búsqueda híbrida, almacenamiento integrado por instancia, creación dinámica vía binding en el Worker y soporte a múltiples instancias en una sola consulta. En la práctica, esto significa que puedes entregarle a tu agente un motor de búsqueda completo con mucha menos configuración, y además con resultados más precisos de lo que cualquier enfoque aislado lograría por sí solo 🚀
En este artículo nos sumergimos en las novedades de AI Search, entendemos cómo funciona la búsqueda híbrida por dentro y además vemos todo esto en acción en un caso real de soporte al cliente.
Qué cambió en AI Search respecto a AutoRAG
Cuando Cloudflare lanzó AutoRAG, la propuesta ya era interesante: una capa gestionada de RAG (Retrieval-Augmented Generation) que abstraía buena parte de la complejidad de búsqueda semántica para agentes de IA. Pero con el tiempo quedó claro que los desarrolladores necesitaban algo más flexible, más potente y, sobre todo, más fácil de integrar en flujos de trabajo dinámicos. El cambio de nombre a AI Search no es solo cosmético, viene acompañado de una reformulación real de cómo funciona la herramienta por dentro y cómo encaja en el ecosistema de agentes de Cloudflare.
El primer gran cambio es el almacenamiento integrado por instancia. Antes, era necesario crear un bucket R2, vincularlo a una instancia de AI Search y gestionar el índice Vectorize provisionado en la cuenta. Ahora, cada nueva instancia de AI Search ya viene con su propio almacenamiento e su índice vectorial integrados, alimentados por R2 y Vectorize entre bastidores. Subes archivos directamente por la API, se indexan automáticamente, y no necesitas configurar buckets externos ni conectar fuentes de datos previamente. Esto simplifica enormemente el ciclo de vida de los datos dentro del agente y reduce la cantidad de piezas móviles que necesitas gestionar.
La creación dinámica vía binding en el Worker es otro salto considerable. El nuevo binding ai_search_namespaces permite crear y eliminar instancias en tiempo de ejecución directamente desde tu Worker. Esto reemplaza la API anterior env.AI.autorag(), que accedía a AI Search a través del binding AI. En lugar de preconfigurar instancias de forma estática antes de que el agente corra, ahora es posible instanciar AI Search directamente en el código, abriendo espacio para arquitecturas mucho más adaptables. Puedes crear una instancia por agente, por cliente o por idioma, sin necesidad de hacer redeploy.
Y el soporte a múltiples instancias en una sola consulta complementa exactamente eso: puedes reunir resultados de bases de conocimiento diferentes con una única llamada, algo que antes requeriría una lógica de orquestación manual considerable. También es posible adjuntar metadatos a los documentos y usarlos para impulsar rankings en el momento de la consulta.
Cómo funciona la búsqueda híbrida por dentro
La búsqueda híbrida es, sin duda, el corazón técnico de esta actualización. Hasta ahora, AI Search ofrecía únicamente búsqueda vectorial. La búsqueda vectorial es excelente para capturar similitud semántica: preguntas sobre atención posventa, y el sistema encuentra documentos que hablan sobre soporte aunque no usen exactamente esas palabras. Pero puede perder especificidades. En una consulta como ERR_CONNECTION_REFUSED timeout, el embedding captura el concepto amplio de fallos de conexión, pero el usuario no está buscando docs generales de red. Quiere el documento específico que menciona ese código de error exacto. La búsqueda vectorial puede devolver resultados sobre troubleshooting sin jamás traer la página que contiene esa cadena de texto.
La búsqueda por palabras clave resuelve exactamente eso. AI Search ahora soporta BM25, una de las funciones de puntuación de recuperación más utilizadas en el mundo. BM25 puntúa documentos considerando la frecuencia de los términos de la consulta, la rareza de esos términos en todo el corpus y la longitud del documento. Recompensa coincidencias en términos específicos, penaliza palabras comunes de relleno y normaliza por el tamaño del documento. Sin embargo, BM25 puede perder una página sobre troubleshooting de conexiones de red, aunque describa exactamente el mismo problema, solo con palabras diferentes. Ahí es donde la búsqueda vectorial brilla, y por eso necesitas ambas.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
Cuando la búsqueda híbrida está activa, AI Search ejecuta las dos estrategias en paralelo, fusiona los resultados y opcionalmente los reordena. El pipeline de recuperación es multi-etapas, y cada etapa es configurable 🔍
Tokenizador
El tokenizador controla cómo tus documentos se dividen en términos que pueden ser emparejados en el momento de la indexación. La opción Porter stemmer reduce palabras a su raíz, así running coincide con run. La opción Trigram hace coincidencia de subcadenas de caracteres, así conf coincide con configuration. Usa Porter para contenido en lenguaje natural como documentación, y Trigram para código donde las coincidencias parciales importan.
Modo de coincidencia por palabras clave
Este modo controla qué documentos son candidatos para la puntuación BM25 en el momento de la consulta. El modo AND exige que todos los términos de la consulta aparezcan en el documento. El modo OR incluye cualquier documento con al menos una coincidencia.
Fusión de resultados
La fusión controla cómo los resultados vectoriales y de palabras clave se combinan en la lista final. La Reciprocal Rank Fusion (RRF) fusiona por posición en el ranking en lugar de por puntuación, evitando comparar dos escalas de puntuación incompatibles. Por su parte, la Max Fusion simplemente toma la puntuación más alta.
Reranking opcional
Adicionalmente, es posible habilitar un paso de reranking con cross-encoder que repuntúa los resultados evaluando la consulta y el documento juntos como un par. Esto ayuda a capturar casos donde un resultado tiene los términos correctos pero en realidad no está respondiendo a la pregunta.
Cada opción tiene un valor predeterminado sensato cuando se omite, y tienes la flexibilidad de configurar lo que importa cada vez que creas una nueva instancia.
Boost de relevancia: surfeando lo que realmente importa
La recuperación trae resultados relevantes, pero la relevancia por sí sola no siempre es suficiente. En una búsqueda de resultados electorales, por ejemplo, un artículo de la semana pasada y uno de hace tres años pueden ser igualmente relevantes semánticamente, pero la mayoría de los usuarios probablemente quiere el más reciente. El boost de relevancia permite superponer lógica de negocio al ranking de recuperación, ajustando posiciones con base en metadatos del documento.
Puedes hacer boost por timestamp, que viene integrado en cada ítem, o por cualquier campo de metadato personalizado que definas. Esto permite que documentos más recientes, de mayor prioridad o de categorías específicas suban en el ranking sin alterar la lógica de búsqueda en sí. Es una capa extra de inteligencia que hace al sistema mucho más útil en escenarios reales.
AI Search en la práctica: agente de soporte al cliente
Para entender dónde todo esto converge de forma concreta, Cloudflare presentó un ejemplo detallado de un agente de soporte que busca dos tipos de conocimiento: documentación compartida del producto e historial por cliente, como resoluciones anteriores de problemas. La documentación del producto es demasiado grande para caber en la ventana de contexto, y el historial de cada cliente crece con cada problema resuelto. Entonces el agente necesita recuperación para encontrar lo que es relevante.
La arquitectura funciona así: la documentación compartida del producto vive en un bucket R2 conectado a una instancia fija de AI Search llamada product-knowledge, creada una sola vez en el dashboard de Cloudflare. Esa es la base de conocimiento que todos los agentes pueden referenciar.
Para el historial de cada cliente, el agente crea una instancia de AI Search dinámicamente usando el binding de namespace. Cuando un cliente aparece por primera vez, se crea una instancia exclusiva. Después de cada problema resuelto, el agente guarda un resumen de qué salió mal y cómo se corrigió. Con el tiempo, esto construye un registro buscable de resoluciones anteriores.
La estructura del namespace queda más o menos así: dentro del namespace support, existe la instancia product-knowledge usando R2 como fuente y compartida entre todos los agentes, e instancias individuales por cliente usando almacenamiento gestionado. El agente entonces usa el Agents SDK de Cloudflare y define dos herramientas que el modelo de lenguaje puede llamar conforme la conversación evoluciona.
La primera herramienta es la búsqueda en la base de conocimiento. Cuando se activa, consulta tanto la documentación del producto como el historial del cliente en una sola llamada, usando la funcionalidad de búsqueda entre instancias. Los resultados se fusionan y se rankean juntos. La segunda herramienta guarda la resolución: después de resolver un problema, el agente graba un resumen que se indexa inmediatamente y queda disponible para búsquedas en conversaciones futuras. El método uploadAndPoll espera hasta que la indexación esté completa antes de retornar, garantizando consistencia.
El modelo utilizado en el ejemplo es Kimi K2.5 vía Workers AI, y decide automáticamente cuándo llamar a cada herramienta con base en el contexto de la conversación. Esto significa que, con el tiempo, el agente se vuelve más inteligente para cada cliente específico, porque acumula contexto de resoluciones anteriores y evita repetir correcciones que ya fallaron 💡
Cómo funcionan ahora las instancias de AI Search
Si usaste AI Search antes de esta versión, conoces el setup anterior: crear un bucket R2, vincularlo a una instancia, AI Search genera un token de API de servicio, y gestionas el índice Vectorize provisionado en la cuenta. Subir un objeto requería escribir en R2 y luego esperar a que un job de sincronización corriera para que el objeto fuera indexado.
Las nuevas instancias funcionan de manera diferente. Cuando llamas a create(), la instancia ya viene con almacenamiento e índice vectorial integrados. Subes un archivo, se envía a indexación inmediatamente, y puedes seguir el estado de la indexación con una sola llamada uploadAndPoll(). Una vez completada, la instancia ya es buscable. No hay dependencias externas que conectar.
Cada instancia también puede conectarse a una fuente de datos externa, ya sea un bucket R2 o un sitio web, y correr en un cronograma de sincronización. La fuente externa puede coexistir con el almacenamiento integrado. En el ejemplo del agente de soporte, product-knowledge se alimenta de un bucket R2 para documentación compartida, mientras que las instancias por cliente usan almacenamiento integrado para contexto cargado dinámicamente.
Namespaces: creación de instancias en tiempo de ejecución
El binding ai_search_namespaces es la nueva forma de crear instancias de búsqueda dinámicamente. Expone APIs como create(), delete(), list() y search() a nivel de namespace. Si estás creando instancias dinámicamente, ya sea por agente, por cliente o por tenant, este es el binding correcto. Los bindings anteriores siguen funcionando a través de las fechas de compatibilidad de Workers.
Precios y límites durante la beta abierta
Las nuevas instancias creadas a partir de ahora reciben almacenamiento integrado e índice vectorial automáticamente. Estas instancias son gratuitas mientras AI Search esté en beta abierta, dentro de los límites establecidos. Cuando se usa un sitio como fuente de datos, el crawling vía Browser Run, antes Browser Rendering, ahora es un servicio integrado y no se cobrará por separado.
En el plan Workers Free, los límites incluyen 100 instancias por cuenta, 100 mil archivos por instancia, tamaño máximo de 4MB por archivo, 20 mil consultas por mes y 500 páginas rastreadas por día. En el plan Workers Paid, los números suben a 5 mil instancias por cuenta, 1 millón de archivos por instancia o 500 mil para búsqueda híbrida, tamaño máximo de 4MB, consultas ilimitadas y crawling ilimitado.
Herramientas que usamos a diario
Después de la beta, el objetivo es ofrecer una tarificación unificada para AI Search como un servicio único, en lugar de cobrar por separado cada componente subyacente. El uso de Workers AI y AI Gateway seguirá cobrándose aparte. Cloudflare se comprometió a dar al menos 30 días de aviso y comunicar detalles de precio antes de que cualquier cobro comience.
Para instancias creadas antes de esta versión, siguen funcionando exactamente como están. Buckets R2, índices Vectorize y uso de Browser Run permanecen en la cuenta y se cobran como antes. Los detalles de migración se compartirán próximamente.
Qué representa esto para quienes construyen agentes hoy
El movimiento de Cloudflare con AI Search dice mucho sobre cómo la construcción de agentes de IA está evolucionando. La tendencia clara es que las piezas de infraestructura que antes exigían configuración manual extensa, como índices vectoriales, pipelines de indexación, lógica de fusión de resultados y orquestación de múltiples fuentes de datos, están siendo absorbidas por plataformas gestionadas que exponen APIs simples y directas. Esto no significa que la complejidad haya desaparecido, solo fue encapsulada en capas más robustas y probadas, liberando a los equipos de producto para enfocarse en lo que realmente importa: el comportamiento del agente y la calidad de la experiencia que entrega.
Para quienes están construyendo agentes hoy, el impacto más inmediato es la reducción del tiempo entre la idea y el agente funcional. Con AI Search, ya no necesitas provisionar una base de datos vectorial separada, configurar embeddings, montar un pipeline de ingesta, agregar un motor de búsqueda por palabras clave y después escribir la lógica que une todo eso. Declaras una instancia, apuntas a tus documentos y la herramienta se encarga del resto. Esto es especialmente valioso en equipos pequeños o en proyectos donde la velocidad de iteración es crítica, como productos en fase de validación o proyectos internos de automatización.
La evolución de AutoRAG a AI Search también señala una madurez creciente en el mercado de herramientas para IA generativa. Cada vez más, las plataformas están saliendo del modo experimental y entregando primitivas de producción: confiables, escalables e integradas al ecosistema existente. La búsqueda híbrida nativa, el almacenamiento integrado y la creación dinámica de instancias no son solo features interesantes en el papel, representan decisiones de arquitectura que hacen a los agentes más robustos y más fáciles de mantener a lo largo del tiempo.
Vale destacar que la búsqueda en el propio blog de Cloudflare ahora está alimentada por AI Search, lo que sirve como una vitrina real de la capacidad de la herramienta en ambiente de producción.
AI Search ya está disponible para desarrolladores que utilizan la plataforma Cloudflare Workers AI. Para comenzar, basta con ejecutar el comando npx wrangler ai-search create my-search y crear tu primera instancia. La documentación completa está disponible en el sitio de desarrolladores de Cloudflare, y nuevas capacidades de indexación y conectores de fuentes de datos deberían llegar en las próximas actualizaciones.
