¿Cuánto cuesta realmente un sistema RAG?

Un sistema RAG (Retrieval-Augmented Generation) no tiene un único coste: hay que sumar la ingesta de documentos, el almacenamiento vectorial, la recuperación de pasajes y la generación de la respuesta con el modelo de lenguaje. Para una base de conocimiento mediana (entre 500 y 2.000 páginas), el coste real por pregunta suele moverse entre 0,001 € y 0,05 €, pero la factura mensual puede dispararse si no controla el volumen de preguntas, el tamaño del contexto o la frecuencia de reindexado. Aquí desglosamos cada partida con cifras orientativas y le damos pautas concretas para bajar el coste sin perder calidad de respuesta.

Los cuatro componentes del coste de un sistema RAG

Cuando alguien pregunta «¿cuánto cuesta un RAG?» suele pensar solo en el precio de la llamada al modelo de lenguaje. Pero esa es solo una de las cuatro partidas. Entender las otras tres es lo que le permite predecir la factura antes de escalar a miles de preguntas al mes.

1. Ingesta: extraer texto de los documentos, trocearlo (chunking) y generar un embedding por cada fragmento.
2. Almacenamiento: guardar esos vectores en una base de datos vectorial o en un índice híbrido, de forma persistente y con copias de seguridad.
3. Recuperación: buscar los fragmentos relevantes para cada pregunta, a veces con un paso de reordenado (reranking) adicional.
4. Generación: enviar la pregunta y los fragmentos recuperados al modelo de lenguaje para que redacte la respuesta final.

Ingesta y troceado: un coste casi siempre de un solo pago

Generar embeddings es barato por unidad (del orden de fracciones de céntimo por cada 1.000 tokens) pero el coste total depende de cuántos fragmentos genere. Un chunking demasiado fino multiplica el número de embeddings y, con ello, el coste de ingesta y de almacenamiento posterior. Un chunking demasiado grueso reduce el coste pero empeora la precisión de la recuperación. Si quiere entender cómo elegir el tamaño y el solapamiento correctos, le conviene revisar nuestra guía sobre estrategias de chunking para RAG. Para entender qué es técnicamente un embedding y por qué cuesta lo que cuesta generarlo, puede consultar qué son los embeddings.

Almacenamiento vectorial: un coste recurrente que crece con el catálogo

Guardar vectores no es gratis: la mayoría de bases de datos vectoriales cobran por volumen de datos indexados, por número de consultas o por ambas cosas, además de la infraestructura de servidores que hay que mantener encendida aunque nadie pregunte nada. Si gestiona usted mismo pgvector, Qdrant o Milvus, el coste es sobre todo de servidor; si usa un servicio gestionado tipo Pinecone, el coste suele ser por GB almacenado y por operación. Hemos desglosado estas diferencias en el artículo sobre el precio de una base de datos vectorial y en la comparativa de alternativas a Pinecone para equipos pequeños que no quieren asumir ese coste fijo mensual.

Recuperación: barata por pregunta, cara si añade reranking agresivo

La búsqueda en sí (vectorial, por palabras clave o híbrida) tiene un coste computacional pequeño comparado con la generación. El salto de coste aparece cuando se añade un modelo de reranking que vuelve a puntuar cada candidato con una llamada adicional, o cuando se recuperan demasiados fragmentos «por si acaso» y se envían todos al modelo generador. La combinación de texto completo y expansión semántica suele dar mejores resultados que forzar un reranking caro; puede leer por qué en nuestro artículo sobre búsqueda híbrida.

Generación: la partida que más varía según el modelo y el contexto

Aquí es donde más dinero se gasta o se ahorra. El coste depende de tres factores: el precio por token del modelo elegido, el número de tokens de contexto que le envía (es decir, cuántos fragmentos recuperados mete en el prompt) y la longitud de la respuesta generada. Meter 20 fragmentos de 500 tokens cada uno en lugar de 5 fragmentos de 200 tokens puede multiplicar por diez el coste de generación sin mejorar la respuesta. Si duda entre recuperar pasajes relevantes o simplemente meter todo el documento en el contexto del modelo, conviene leer RAG vs modelos de contexto largo: a partir de cierto volumen de documentos, la recuperación selectiva siempre sale más barata.

Cuánto cuesta cada pregunta en la práctica

Para dar cifras concretas, tomemos una base de conocimiento típica de una pyme: unas 800 páginas de documentación (manuales, políticas internas, contratos tipo), consultada unas 2.000 veces al mes. Las cifras siguientes son orientativas y varían según el proveedor y el modelo elegido, pero sirven para hacerse una idea del orden de magnitud.

Con 2.000 preguntas al mes, el rango total de la factura de consultas estaría entre 2 € y 100 €, a lo que hay que sumar el almacenamiento y, si gestiona usted la infraestructura, el coste del servidor o del servicio gestionado. La horquilla es amplia a propósito: un sistema mal optimizado (contexto demasiado largo, modelo caro para preguntas triviales, reranking en cada consulta) puede situarse en el extremo alto sin que nadie se dé cuenta hasta que llega la factura.

Pago por pregunta vs suscripción: qué modelo le conviene

Hay dos grandes formas de pagar un sistema RAG. La primera es montar toda la infraestructura usted mismo: base de datos vectorial, pipeline de ingesta, llamadas al modelo de lenguaje gestionadas con su propia clave de API. Esto le da control total, pero asume todos los costes fijos (servidor, mantenimiento, actualizaciones de embeddings) además de los variables por pregunta, y requiere alguien que lo mantenga.

La segunda es usar un servicio que ya incluye ingesta, indexado híbrido y generación con fuentes citadas, pagando solo por lo que usa. En Kopik, por ejemplo, el modelo es de créditos prepagados por pregunta o una suscripción de chat a 12 €/mes con un medidor de uso visible, sin necesidad de contratar ni mantener una base de datos vectorial aparte. Para un equipo pequeño que no quiere dedicar horas de ingeniería a optimizar chunking y reranking, el coste total suele salir más predecible que montar la infraestructura propia, sobre todo en los primeros meses cuando aún no se sabe el volumen real de preguntas.

La pregunta que debe hacerse no es «¿qué modelo es más barato en abstracto?» sino «¿cuántas preguntas voy a recibir al mes y cuánto vale mi tiempo de mantenimiento?». Por debajo de unas pocas miles de preguntas mensuales, pagar por pregunta o por suscripción casi siempre sale más barato que mantener infraestructura propia. Por encima de ese volumen, conviene recalcular, porque las economías de escala de montar algo propio empiezan a compensar el coste de ingeniería.

Siete formas de bajar el coste de un RAG sin perder calidad

1. Recorte el contexto: recupere solo los 3-6 fragmentos más relevantes en lugar de 15-20 «por si acaso».
2. Elija el tamaño de chunk correcto: ni tan pequeño que multiplique el número de embeddings, ni tan grande que infle cada llamada de generación.
3. Use modo «passages» (solo pasajes, sin generación) para los casos en los que el usuario solo necesita localizar el fragmento exacto, no una respuesta redactada.
4. Cachee las preguntas frecuentes: si el 20 % de las preguntas se repiten casi literalmente, una capa de caché evita volver a pagar la generación cada vez.
5. Reserve el reranking para consultas ambiguas: no todas las preguntas necesitan ese paso adicional de coste.
6. Use un modelo de generación más barato para preguntas simples y reserve el modelo más caro para las que de verdad lo requieren.
7. Mida antes de escalar: monitorice fidelidad y coste por pregunta desde el principio, como se explica en cómo evaluar un sistema RAG, para detectar derivas de coste antes de que se conviertan en una factura sorpresa.

Costes ocultos que la gente suele olvidar

Además de las cuatro partidas principales, hay gastos que aparecen más tarde y que pocas veces se incluyen en el presupuesto inicial.

• Reindexado completo cuando cambia de modelo de embeddings: hay que volver a procesar todos los documentos, no solo los nuevos.
• Monitorización y evaluación continua: medir fidelidad y detectar alucinaciones tiene un coste de ingeniería, no solo de infraestructura.
• Mantenimiento de la infraestructura propia: parches de seguridad, escalado del servidor, copias de seguridad.
• Revisión de cumplimiento normativo: si trata datos personales, conviene revisar qué implica el RGPD antes de lanzar el proyecto, como se detalla en RGPD y RAG: qué revisar.
• Tiempo de las personas que validan las respuestas, sobre todo en los primeros meses de un despliegue nuevo.

Preguntas frecuentes