Cómo montar un RAG con Elasticsearch serverless

Montar un RAG con Elasticsearch serverless cambia cuál es la parte difícil. Hasta ahora, construir recuperación aumentada —trocear los documentos, generar los embeddings, elegir y ajustar el índice vectorial, y luego mantener las GPUs que hacen todo eso— era más trabajo que la aplicación en sí. La oferta serverless de Elasticsearch se queda con esa parte: tú llevas los documentos y las consultas, y el servicio se encarga de las incrustaciones, del ajuste del índice y de la infraestructura. Aquí está cómo se monta, qué hace por debajo y dónde están sus límites.

Lo primero: un RAG con Elasticsearch serverless no lleva pipeline

El cambio conceptual es este. En un RAG montado a mano, el trabajo empieza antes del índice: partes los documentos en trozos del tamaño correcto, llamas a un modelo para convertir cada trozo en un vector, y guardas ambos. Aquí, el tipo de campo semantic_text resuelve todo eso a nivel de índice: el troceado, la configuración de las incrustaciones y el modelo corriendo en GPUs gestionadas, sin que montes nada.

Se crea un índice con una sola propiedad:

PUT my-vectors
{
  "mappings": {
    "properties": {
      "description": { "type": "semantic_text" }
    }
  }
}

Y a partir de ahí, indexas texto normal —tal cual, sin vectores— y las incrustaciones se generan solas:

POST /my-vectors/_doc
{
  "id": "park_rocky-mountain",
  "title": "Rocky Mountain",
  "description": "Bisected north to south by the Continental Divide, this portion of the Rockies has ecosystems varying from over 150 riparian lakes to montane and subalpine forests to treeless alpine tundra."
}

La búsqueda es semántica, no por palabras

La consulta busca por significado, no por coincidencia de términos:

GET /my-vectors/_search
{
  "query": {
    "semantic": {
      "field": "description",
      "query": "a mountain range in the middle of north america"
    }
  }
}

Y devuelve la coincidencia con su puntuación:

{
  "took": 80,
  "hits": {
    "max_score": 0.7792325,
    "hits": [
      {
        "_index": "my-vectors",
        "_score": 0.7792325,
        "_source": {
          "id": "park_rocky-mountain",
          "title": "Rocky Mountain",
          "description": "Bisected north to south by the Continental Divide, ..."
        }
      }
    ]
  }
}

Fíjate en lo que no hay en la consulta: ni un vector, ni una dimensión, ni el nombre del modelo. La pregunta va en lenguaje natural y el servicio hace el resto.

Lo que hace el modo de índice por debajo

Hay un ajuste nuevo llamado vectordb_document, activado por defecto, que aplica lo que Elastic llama la configuración que elegirían los expertos. Cuatro cosas:

• bfloat16 por defecto. Los vectores se guardan a la mitad de tamaño que en float32, con lo que el post describe como impacto insignificante en la recuperación. Es la mitad de disco antes de cuantizar nada.
• Los vectores originales no se duplican. Como las incrustaciones ya viven en las estructuras del índice, se descarta la copia en _source: menos que guardar y respuestas más rápidas.
• Los archivos que la búsqueda vectorial toca primero se precargan en memoria.
• Las fusiones de segmentos se hacen en paralelo, consolidando en mejores estructuras vectoriales con varios hilos.

Y encima de eso, la cuantización: BBQ comprime los vectores hasta 32 veces, y DiskBBQ aprieta más para volúmenes muy grandes. Hay además una calibración automática opcional que ajusta la cuantización por segmento a tus datos y recalibra en cada fusión; en 18 conjuntos de prueba reportan una mejora media del 16,7% en consultas por segundo, con ganancias de recuerdo en la mayoría.

Búsqueda híbrida, que es la parte que casi nadie acierta

La búsqueda puramente vectorial falla donde la de texto acierta: nombres propios, códigos, términos exactos. Por eso lo que funciona en producción es la híbrida, y aquí viene montada: junta recuperación por texto y por vector en una sola búsqueda, con fusión por RRF o por el método que prefieras.

También hay búsqueda vectorial con filtros, que aplica los filtros de metadata dentro de la recuperación vectorial en vez de después. La diferencia importa: filtrar después puede dejarte sin resultados cuando el filtro recorta lo que el vector había encontrado.

Lo que no te dice el anuncio

• No hay precios. El cobro se describe por cantidades conocidas —cuánto guardas, cuánto indexas y cuánta capacidad de búsqueda necesitas— y dice que puedes estimarlo de antemano sabiendo el número de documentos, las dimensiones del vector y la carga de búsqueda. Pero cifras, ninguna. Eso lo tendrás que sacar de la calculadora.
• No hay SQL en los ejemplos. El artículo muestra la API de búsqueda; si esperabas ES|QL para esto, no está aquí.
• No dice cuánto tarda en estar listo un proyecto nuevo, ni qué límites tiene el plan gratuito o de entrada.
• La parte de las incrustaciones es del servicio. Es lo que lo hace cómodo y también lo que te ata: si algún día quieres cambiar de modelo con una estrategia propia, tendrás que mirar cómo se hace eso fuera del camino cómodo.

Cómo comprobarlo con tus datos

• Mide el recuerdo, no solo la latencia. Un RAG que responde en 50 ms pero no encuentra el documento correcto es peor que uno lento que sí lo encuentra. Prueba con preguntas cuya respuesta conozcas.
• Prueba con términos exactos, del tipo que la búsqueda semántica suele fallar: números de referencia, nombres propios, siglas. Ahí verás si la parte híbrida está haciendo su trabajo.
• Calcula el coste antes de crear el proyecto. Como el cobro es por datos, indexación y capacidad, puedes estimarlo con tus números en vez de descubrirlo a fin de mes.
• Y decide si quieres depender del servicio para las incrustaciones. Es lo que te ahorra el trabajo y lo que te lo esconde.

Y si encima del RAG va un agente: cómo migrar a LangChain 1.0 es el paso siguiente.

Fuente: el anuncio de la base de datos vectorial serverless de Elasticsearch en Elasticsearch Labs, de donde salen los ejemplos de API, la descripción del modo de índice y los números de la calibración automática.