Cuando una empresa tiene que meter su propio conocimiento en un modelo de lenguaje —su catálogo, sus manuales, su histórico de tickets— casi siempre aparece la misma discusión: ¿RAG, fine-tuning o simplemente meterlo todo en el contexto? La conversación suele girar en torno a la calidad: cuál responde mejor, cuál alucina menos, cuál es más fácil de mantener.
Es la pregunta equivocada para empezar. En la mayoría de los proyectos que vemos, la decisión no se rompe por calidad —las tres pueden dar una calidad aceptable— sino por coste por tarea. Y ahí las tres opciones se comportan de forma radicalmente distinta según tu volumen. Una que parece la más barata en la demo se vuelve la más cara en producción, y al revés.
Las tres opciones, en una frase de coste
Contexto largo. Metes el conocimiento relevante directamente en el prompt en cada petición. Cero infraestructura, cero preparación. Pero pagas esos tokens cada vez que preguntas. Es el “copiar y pegar el manual entero” antes de cada consulta.
RAG (generación aumentada por recuperación). En vez de mandar todo el conocimiento, un buscador recupera solo los fragmentos relevantes para cada consulta y esos —y solo esos— viajan en el prompt. El contexto por petición se mantiene pequeño. A cambio, montas y mantienes una tubería: trocear los documentos, generar embeddings, una base vectorial, la lógica de recuperación.
Fine-tuning. Ajustas el propio modelo con tus datos. Pagas un coste de entrenamiento por adelantado, pero después el conocimiento (o el estilo, o el formato) vive dentro del modelo, así que el prompt de cada petición puede ser mucho más corto: ya no hace falta reenviar instrucciones ni ejemplos.
Dónde se paga cada una
La clave está en distinguir coste de arranque (una vez) de coste por tarea (cada petición, para siempre). Es la misma lógica del coste por tarea: lo que te hunde el presupuesto no es el precio de lista, es lo que multiplicas por tu volumen mensual.
Contexto largo tiene coste de arranque casi cero y el coste por tarea más alto de los tres. Si arrastras 8.000 tokens de manual en cada consulta y resuelves cien mil consultas al mes, has pagado ese manual cien mil veces. Barato de montar, caro de operar.
Fine-tuning invierte el reparto: coste de arranque alto (preparar el dataset, entrenar, y volver a entrenar cada vez que el conocimiento cambia), pero el coste por tarea más bajo, porque el prompt adelgaza. Es la opción de “pagar mucho una vez para pagar poco muchas veces”.
RAG se queda en medio en las dos dimensiones: un arranque moderado (la tubería de recuperación) y un coste por tarea bajo, porque solo mandas los fragmentos que hacen falta, no todo. Además tiene un coste que las otras dos no tienen tan visible: cada consulta paga también la recuperación (embedding de la pregunta, búsqueda en la base vectorial), aunque suele ser pequeño frente al ahorro en tokens del modelo.
Un ejemplo con números
Supongamos una tarea que necesita apoyarse en una base de conocimiento. Respuesta de 300 tokens en los tres casos. Precios ilustrativos de 2 $ por millón de entrada y 12 $ por millón de salida.
| Enfoque | Tokens de entrada por tarea | Coste por tarea |
|---|---|---|
| Contexto largo (manual entero) | 8.000 | 0,0196 $ |
| RAG (solo fragmentos relevantes) | 1.500 | 0,0066 $ |
| Fine-tuning (prompt mínimo) | 500 | 0,0046 $ |
A simple vista, fine-tuning gana. Pero falta la otra mitad. Si haces mil tareas al mes, la diferencia entre contexto largo y fine-tuning es de unos 15 $ mensuales: no compensa ni de lejos el coste de preparar y mantener un modelo ajustado. Si haces un millón, esa misma diferencia son unos 15.000 $ al mes —180.000 $ al año—, y de repente el fine-tuning se paga solo en semanas.
El punto de equilibrio no lo marca qué opción es “mejor”, sino cuántas veces vas a repetir la tarea.
Cómo decidir sin instrumentar medio equipo
Tres preguntas ordenan casi todos los casos:
¿Cuál es tu volumen? Con volúmenes bajos, el contexto largo casi siempre gana: el coste por tarea es irrelevante frente al tiempo de ingeniería que ahorras. No montes una tubería de RAG para resolver mil consultas al mes.
¿Cada cuánto cambia el conocimiento? Si tu base cambia a diario —precios, inventario, políticas—, el fine-tuning es una trampa: reentrenar constantemente es caro y lento. RAG brilla justo aquí, porque actualizar es tan sencillo como cambiar los documentos indexados. El fine-tuning encaja cuando lo que enseñas es estable: un tono, un formato de salida, una jerga de dominio.
¿Qué estás metiendo, conocimiento o comportamiento? RAG es para saber cosas (hechos, documentos, datos que se consultan). Fine-tuning es para comportarse de cierta forma (responder con un estilo, seguir una estructura, hablar tu idioma técnico). Confundirlos es el error más caro: intentar meter una base de conocimiento cambiante por fine-tuning, o forzar un formato rígido a base de estirar el prompt en cada petición.
Y no son excluyentes. La combinación más habitual en producción es fine-tuning para el comportamiento + RAG para el conocimiento: un modelo ajustado para responder como tú quieres, alimentado con fragmentos recuperados al vuelo. Se paga el arranque del fine-tuning una vez, se mantiene el conocimiento barato con RAG, y el prompt por tarea queda corto por los dos lados.
Una advertencia honesta
Los números de este artículo son un ejemplo para ilustrar el mecanismo, no una medición de tu caso. El punto de equilibrio real depende de tu volumen, de cuánto contexto arrastra hoy cada petición y de con qué frecuencia cambia tu conocimiento. Puede estar en diez mil tareas al mes o en diez millones.
Lo que no cambia es el orden de la decisión: primero mide cuánto te cuesta hoy una tarea y cuántas haces, y solo después elige arquitectura. Elegir por lo que se lleva —“todo el mundo hace RAG”— en vez de por tus números es la forma más habitual de acabar pagando de más por una arquitectura que tu volumen no justifica.
Esta pieza forma parte del clúster sobre el coste por tarea de IA, la guía que ancla todo lo demás.
En e-ficient medimos el coste por tarea de empresas que ya tienen IA en producción, incluido cuánto te costaría cada arquitectura en tu volumen real. La auditoría inicial no tiene coste y devuelve un diagnóstico en 72 horas.