RAG vs Fine-Tuning vs Long-Context: El Cruce de Costes de 2026

El default de 2024 era "usa RAG para todo". En 2026 la matemática ha cambiado. Los precios de APIs LLM bajaron aproximadamente 10x en 24 meses en el extremo barato. Las context windows alcanzaron 1M a 2M tokens. El fine-tuning maduró y se abarató. La decisión arquitectónica ya no es "RAG sí/no" sino un cruce de tres vías. Este post expone dónde gana cada opción a mediados de 2026, con un ejemplo concreto de coste en el que puedes meter tus números.

Perspectiva de ingeniería, no pitch de vendor. Puntos de referencia del trabajo de IA de Wavect incluyendo PromptID, Twinsoft AI y Quivr.

¿Qué cambió entre 2024 y 2026?

Tres cambios estructurales:

• Los precios de tokens colapsaron. El pricing de input de modelos mid-tier bajó de aproximadamente EUR 2,50 por 1M tokens de input (2024) a menos de EUR 0,30 en niveles competitivos en 2026. El pricing de tokens de output siguió.
• Las context windows crecieron. 1M de context de input es ahora el estándar mid-tier, con 2M disponibles. El prompt caching reduce el coste efectivo de releer el mismo contexto en una sesión un 80 a 90 por ciento.
• El fine-tuning maduró. Los adaptadores LoRA y los modelos open-weight pequeños en el rango 7B a 30B abarataron la adaptación de dominio. El self-hosting en infraestructura UE por razones de data-residency es ahora económicamente viable para muchos equipos SaaS.

La implicación. El árbol de decisión de 2024 está equivocado. Vuélvelo a correr en precios de 2026 y los puntos de cruce se han movido.

¿Cuándo le gana long-context a RAG en 2026?

Long-context gana cuando el corpus cabe en el prompt y el workload es ad-hoc:

• Corpus por debajo de ~10 MB de texto (aproximadamente 2M tokens). Cabe en un prompt de modelo frontier.
• Queries ad-hoc o de bajo volumen donde el overhead de ingeniería de retrieval no se amortiza.
• Tareas donde el reasoning entre documentos importa y el chunking rompería el contexto.
• Sesiones con altas tasas de cache-hit de prompt (asistentes multi-turn sobre el mismo conjunto de docs).

La trampa. El coste de long-context escala linealmente con el tamaño del corpus en cada query a menos que el caching actúe. A 100k queries/mes, la diferencia entre cachear y no cachear es la diferencia entre un feature rentable y un desastre de margen.

¿Cuándo le gana fine-tuning a ambos?

Fine-tuning gana en tres firmas:

• Estilo o persona. Necesitas que el modelo suene consistentemente como tu marca o siga un formato preciso. El prompt engineering tiene rendimientos decrecientes; un fine-tune lo fija.
• Idiom de dominio. El vocabulario es especializado (legal, médico, industrial de nicho) y el modelo base trata tus términos como polisémicos. El fine-tuning realinea los embeddings.
• Tareas estrechas sensibles a latencia. Un modelo 7B con fine-tune en un solo workload le gana a un modelo 70B en coste y latencia para ese workload, a menudo con calidad comparable.

La trampa. El fine-tuning hornea los datos. Si tu conocimiento se actualiza diariamente, un fine-tune está obsoleto para el miércoles. Combínalo con RAG para las partes que cambian.

¿Cuándo sigue ganando RAG?

RAG sigue siendo la decisión correcta cuando:

• Corpus grandes o que se actualizan. Por encima de ~10 MB de texto relevante, o con refresh diario/semanal, la matemática favorece retrieval.
• Requisitos de citación. Compliance, legal, médico o cualquier producto donde los usuarios necesiten ver la fuente de la respuesta.
• Aislamiento de datos multi-tenant. Cada cliente tiene su propio corpus y no puedes cruzar polinización. RAG separa limpiamente por tenant; long-context y fine-tuning no.
• Patrones de retrieval sparse. La mayoría de queries tocan una pequeña fracción del corpus. Cargar todo el corpus en contexto desperdicia tokens.

¿Cómo se ve el cruce de coste-por-query en tamaños comunes de corpus?

Coste-por-query indicativo para un deployment basado en UE a precios de tokens de mediados de 2026, asumiendo pricing representativo de modelo mid-tier (EUR 0,30 por 1M de input, EUR 1,20 por 1M de output) y un output de 1k tokens. Números redondeados por claridad; mete el pricing exacto de tu provider en tu propio modelo.

Lectura del cruce. Por debajo de 10 MB y con una tasa alta de cache-hit, long-context se vuelve económicamente defendible. Por encima de 10 MB, RAG es la única opción que mantiene su forma de coste. El terreno medio interesante es la banda de 1 a 10 MB, donde la decisión correcta depende más de patrones de query que del tamaño bruto del corpus.

¿Cómo se ve un deployment concreto en UE?

Ejemplo trabajado. Corpus de 100 MB de documentación técnica, 10.000 queries por mes, requisito de residencia UE, citación necesaria en cada respuesta:

1. Arquitectura. RAG con vector store hosted en UE, endpoint API UE para el provider LLM o modelo open-weight self-hosted en infraestructura UE.
2. Coste por query. Retrieval (~3k tokens de input + 1k de output) a pricing mid-tier de 2026 aterriza cerca de EUR 0,0024 por query. A 10k queries/mes, aproximadamente EUR 24 al mes en coste de LLM.
3. Más infra. Vector store, refresh de embeddings, observability, eval harness. Sobre realista de infra EUR 200 a 800 al mes a esta escala.
4. Más build. Implementación inicial incluyendo data ingestion, eval harness, UI de citación, monitoring, aterriza en el rango de 4 a 10 semanas del historial de engagements de Wavect en scopes similares.

El mismo workload con long-context, ignorándolo ni siquiera cabe. El mismo workload con fine-tune, sacrificas citaciones y necesitas un camino de retrieval separado para datos frescos de todas formas, así que acabas con RAG más un fine-tune, no en lugar de.

"Las decisiones de arquitectura siguen la curva de precios, no la curva de hype. El modelo correcto en 2024 es el modelo equivocado en 2026 aunque nada más haya cambiado."

¿Y las arquitecturas híbridas?

En producción, las respuestas más limpias son normalmente híbridas:

• RAG más fine-tune. Retrieval maneja el corpus que cambia; el fine-tune maneja tono, formato y vocabulario de dominio. Este es el default al que recurrimos en asistentes de cara al cliente donde la voz de marca importa.
• RAG más long-context. Recupera un candidate set más amplio, luego deja que la context window de long-context haga reasoning entre documentos. Útil para revisión legal y tareas de síntesis.
• Modelo pequeño más router. Un modelo pequeño y rápido clasifica la query y rutea al backend correcto (RAG, fine-tune o un modelo frontier). Recorta coste 3 a 5x en nuestra experiencia.

¿Qué significa esto para un founder UE en 2026?

Tres reglas operativas desde el campo:

1. Corre el modelo de coste antes de la reunión de arquitectura. Mete tu volumen real de queries, tu tamaño real de corpus y el pricing real de tu provider en la tabla de arriba. La arquitectura correcta sale de los números, no de las charlas de conferencia.
2. Construye el eval harness primero, independientemente de la arquitectura. Sin evals, no puedes saber qué arquitectura está ganando realmente. Hemos escrito sobre esto en nuestro post de agents y aplica el doble aquí.
3. Vuelve a correr el análisis cada seis meses. Los precios de tokens y las context windows se están moviendo más rápido que tu cadencia de revisión de arquitectura. El default de 2025 será el default equivocado de 2027.