Pinecone y los gestionados: qué compras cuando pagas

Cuarta entrega del bloque de plataformas. Los servicios gestionados tienen mala prensa entre equipos técnicos y buena entre quienes pagan las nóminas. Merece la pena separar qué se compra realmente, qué se cede a cambio y en qué situaciones concretas la factura es la opción barata.

La categoría incluye dos cosas distintas que conviene no mezclar. Por un lado, los servicios vectoriales puros, que nacieron como servicio y no tienen versión autoalojable: Pinecone es el nombre de referencia. Por otro, las capacidades vectoriales añadidas a bases de datos gestionadas que muchas empresas ya tienen contratadas: MongoDB Atlas Vector Search, la búsqueda vectorial de Elasticsearch y OpenSearch, Redis con su índice vectorial, y los servicios equivalentes de las grandes nubes.

La diferencia importa porque el segundo grupo cambia por completo la ecuación: si tus documentos ya están en MongoDB, añadir un índice vectorial sobre la colección que ya existe no es adoptar un sistema nuevo, es activar una función. Y evitar la sincronización entre dos sistemas vale más de lo que suele parecer sobre el papel.

Qué compras exactamente

Un servicio gestionado no te vende búsqueda vectorial: eso lo hace igual un contenedor de código abierto en una máquina de veinte euros al mes. Te vende cuatro cosas.

Que no haya nada que operar. Ni actualizaciones de versión, ni parches de seguridad, ni discos que se llenan, ni reinicios, ni una migración mayor cada dieciocho meses. Para un equipo de tres personas que además construye el producto, esto no es comodidad: es la diferencia entre que el proyecto avance o no.

Escalado sin proyecto de por medio. Pasar de dos millones de vectores a veinte es cambiar un parámetro o simplemente insertar más datos, según el modelo del servicio. En autoalojado, el mismo salto es dimensionar máquinas, reconstruir índices, probablemente introducir reparto y planificar una ventana.

Disponibilidad con compromiso contractual. Replicación, conmutación por error y copias de seguridad hechas por alguien cuyo negocio depende de que funcionen. Puedes construir eso tú, y te va a llevar más tiempo y a quedar peor probado.

Alguien a quien llamar. A las tres de la mañana, con un contrato detrás. No es un detalle menor cuando el sistema está en el camino crítico de un producto.

Lo que no compras, y a veces se supone: mejor recall, mejores respuestas, ni ahorro de trabajo en el troceado, los metadatos o la evaluación. La calidad del RAG sigue dependiendo de lo que vimos en los bloques anteriores, y ningún proveedor la resuelve.

Cómo está estructurado el precio

Las tarifas cambian y no tiene sentido escribirlas aquí. La estructura, en cambio, es estable y es lo que hay que entender para estimar.

Hay dos modelos dominantes. El primero es el aprovisionado: pagas por unidades de capacidad reservada —memoria, cómputo, réplicas—, tengas o no tráfico. Es predecible, tiene un suelo alto y penaliza al proyecto pequeño o intermitente. El segundo es el sin servidor: pagas por almacenamiento de vectores, por operaciones de lectura y por operaciones de escritura, cada una con su unidad. El suelo es bajísimo y el techo es incierto, porque depende de tu tráfico real.

Las variables que mueven la factura en el modelo sin servidor, por orden de impacto habitual:

• Número de vectores por su dimensionalidad. Reducir de 1.536 a 768 dimensiones con un modelo equivalente, o usar reducción tipo Matryoshka, recorta el almacenamiento a la mitad. Es el ahorro más fácil y el menos aplicado.
• Consultas por segundo. Y aquí hay un multiplicador que sorprende: si haces búsqueda híbrida con varias reformulaciones de la consulta, como en la entrega 17, una pregunta del usuario pueden ser cuatro o seis consultas facturadas.
• Escrituras. Suelen ser más caras por unidad que las lecturas. Una reindexación completa del corpus es un pico de factura, y si reindexas cada vez que cambias de troceado, conviene saberlo antes.
• Número de índices o espacios de nombres. En arquitecturas multi-inquilino con un índice por cliente, el coste fijo por índice se multiplica rápido. Suele ser mejor un índice con filtrado por inquilino, con las cautelas de la entrega 45.

La regla para estimar: calcula el coste al volumen que tendrás dentro de doce meses, no al de hoy. Los gestionados son baratos en el arranque por diseño, y es en el crecimiento donde se decide si la elección fue buena.

Los vectoriales integrados en lo que ya tienes

Merecen una mirada aparte porque casi siempre son la respuesta que menos se considera y más a menudo acierta.

MongoDB Atlas Vector Search añade índices vectoriales sobre colecciones existentes. El documento, sus metadatos y su vector son el mismo objeto, la consulta se escribe en el mismo lenguaje de agregación que ya usas y el filtrado aprovecha los índices que ya tienes. La ventaja estructural es la misma que la de pgvector en la entrega 29: un solo sistema.

Elasticsearch y OpenSearch son el caso más claro cuando el corpus ya está indexado ahí. Tienen la mejor búsqueda léxica del mercado, y su búsqueda vectorial permite combinar las dos partes en una sola consulta con fusión por rango recíproco incorporada. Si necesitas híbrido de verdad y ya tienes Elasticsearch, empezar por otro sitio es difícil de justificar.

Redis encaja en un nicho estrecho pero real: conjuntos que caben en memoria y exigen latencia de un dígito de milisegundos. Es la opción para cachés semánticas y para índices pequeños y calientes, no para el corpus principal.

El aviso común a los tres: su búsqueda vectorial es una función de un producto más grande, y por tanto suele ir un paso por detrás de los motores dedicados en cuantización, en afinado de índices y en opciones de filtrado avanzado. Para la mayoría de los casos, ese paso no se nota.

Lo que cedes

Dependencia de proveedor

Hay que graduarla, porque no todas las dependencias son iguales.

La más fuerte es la del servicio sin equivalente autoalojable: si el proveedor cambia sus precios, sus condiciones o su rumbo, tus opciones son aceptar o migrar. La intermedia es la del gestionado sobre software abierto —Qdrant Cloud, Weaviate Cloud, un Postgres gestionado con pgvector—: cambias de operador sin cambiar de tecnología, que es una migración incómoda pero acotada. La más leve es la del vectorial integrado en una base de datos que ya usabas: la dependencia existía antes y no aumenta por añadir vectores.

La mitigación práctica es la misma que ya mencionamos en la entrega 28 y no cuesta casi nada: aísla el acceso al índice tras una interfaz propia de cuatro operaciones. Y guarda siempre los vectores originales, o al menos el texto y el modelo con que se generaron, fuera del servicio. Si tu única copia de los embeddings está dentro del proveedor, la migración incluye recalcularlos todos.

Coste de salida

Dos costes distintos con el mismo nombre. El literal, el tráfico de datos que se factura al extraerlos, que en índices grandes no es trivial. Y el real: el tiempo de reescribir la integración, reindexar en el destino, validar que el recall no se ha movido y hacer el cambio sin cortar el servicio. El segundo es siempre mayor que el primero.

Residencia de los datos y cumplimiento

Este apartado decide la elección más veces de lo que la conversación técnica sugiere.

Las preguntas que hay que hacer antes de firmar: en qué regiones se pueden alojar los datos y si la elección de región es garantía contractual; si hay cifrado en reposo con claves gestionadas por el cliente; qué certificaciones sostiene el proveedor; qué figura como subencargado del tratamiento; y si existe un acuerdo de tratamiento de datos que tu departamento jurídico acepte.

Hay un matiz específico de RAG que se pasa por alto: aunque el vector no sea texto legible, es una representación del contenido, y hay trabajos que muestran que a partir de embeddings se puede reconstruir información sustancial del texto original. Tratar los vectores como si no fueran datos personales cuando proceden de documentos que sí lo son es un error de análisis, no un tecnicismo.

Cuándo el gestionado es la decisión correcta aunque parezca caro

• Cuando el equipo no tiene operaciones. Si nadie tiene guardia, nadie ha restaurado nunca una copia de seguridad y nadie va a actualizar el motor, el autoalojado no es más barato: es un incidente pendiente de ocurrir.
• Cuando el proyecto todavía no está validado. Antes de saber si el producto funciona, el coste de oportunidad de montar infraestructura es enorme. Se gestiona primero y se migra si el volumen lo justifica.
• Cuando la carga es muy irregular. Picos concentrados y valles largos encajan mal con capacidad aprovisionada propia, que se dimensiona para el pico y se paga siempre.
• Cuando el vectorial ya viene con la base de datos que pagas. Aquí la comparación no es gestionado contra autoalojado, sino un sistema contra dos.

Y el reverso, dicho con la misma claridad: si tienes plataforma, volumen alto y estable, y el gasto en el servicio se acerca al de una persona de infraestructura, el autoalojado empieza a tener sentido económico. Ese cálculo hay que rehacerlo cada cierto tiempo, porque el volumen crece y la respuesta cambia.

Qué viene ahora

La siguiente entrega baja al otro extremo del espectro: las opciones embebidas para prototipar sin montar nada. Chroma, LanceDB y Faiss, qué son exactamente —Faiss no es lo que mucha gente cree—, cómo se levantan en minutos y dónde está la frontera concreta que obliga a migrar a algo serio.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.