Fine-tuning vs RAG: cuándo entrenar un modelo propio

Cuando una empresa decide que un modelo de lenguaje genérico ya no es suficiente, llega la pregunta inevitable: ¿entrenamos un modelo propio o conectamos el modelo a nuestros documentos? La respuesta importa mucho, porque un error de arquitectura al principio se paga en meses de retrabajo y en decenas de miles de euros. En este artículo explicamos con precisión técnica y criterio de negocio cuándo aplicar fine-tuning, cuándo RAG (Retrieval-Augmented Generation) y cuándo tiene sentido combinar los dos enfoques.

Qué es el fine-tuning y qué problema resuelve

El fine-tuning (ajuste fino) consiste en continuar el entrenamiento de un modelo de lenguaje preentrenado usando ejemplos propios de la empresa. El objetivo no es enseñarle conocimiento nuevo —para eso está RAG—, sino reformatear el comportamiento y el estilo: que el modelo adopte un tono corporativo específico, que produzca siempre una estructura de salida determinada (JSON, XML, formulario), o que domine una jerga muy especializada que en los datos de preentrenamiento aparece apenas de pasada.

Técnicamente, el fine-tuning actualiza los pesos del modelo mediante retropropagación sobre un conjunto de pares (instrucción, respuesta ideal) que la empresa proporciona. Desde 2023 se han popularizado variantes eficientes como LoRA (Low-Rank Adaptation) y QLoRA, que reducen drásticamente la memoria de GPU necesaria al congelar la mayoría de los parámetros y entrenar solo matrices de rango bajo. Esto ha democratizado el fine-tuning: empresas sin clúster propio pueden ajustar modelos de 7B o 13B parámetros en una GPU de 24 GB en pocas horas.

Lo que el fine-tuning no resuelve bien es la actualización continua de información. Una vez ajustado el modelo, su «conocimiento» queda fijo hasta el próximo ciclo de reentrenamiento. Si el dato cambia —una tarifa, una normativa, un catálogo de producto—, el modelo seguirá respondiendo con el dato antiguo.

Qué es RAG y para qué sirve

RAG —siglas de Retrieval-Augmented Generation— es una arquitectura en la que el modelo de lenguaje no actúa solo: antes de generar la respuesta, un componente de recuperación consulta una base de conocimiento externa (documentos, bases de datos, APIs) y le pasa el contexto relevante al modelo como parte del prompt. El modelo razona sobre ese contexto y produce la respuesta.

La ventaja decisiva de RAG es la frescura del dato. La base de conocimiento se puede actualizar en tiempo real —o varias veces al día— sin tocar el modelo. Además, la recuperación es auditable: puedes ver exactamente qué fragmento de qué documento sustentó cada respuesta, lo que simplifica el cumplimiento normativo en entornos regulados (seguros, banca, sanidad).

RAG tampoco es la solución universal. Si el modelo base no «habla bien» el idioma o la jerga del dominio, los fragmentos recuperados serán correctos pero las respuestas podrían seguir siendo torpes. Y si el corpus de documentos es muy grande y está mal estructurado, la calidad de la recuperación cae y con ella la del sistema completo. La ingeniería del índice y del chunking es, en la práctica, la mitad del trabajo de un proyecto RAG bien hecho.

Comparativa directa: fine-tuning vs RAG

Cuándo elegir fine-tuning

El fine-tuning es la elección correcta cuando el problema no es de conocimiento sino de comportamiento. Tres señales que apuntan hacia él:

• El formato de salida es crítico y rígido. Si el sistema tiene que producir siempre un JSON con campos específicos, o rellenar una plantilla de informe con estructura exacta, el fine-tuning es mucho más fiable que confiar en que el prompt induzca ese formato. Los modelos ajustados para clasificación o extracción son más rápidos y baratos en producción que los modelos generales con prompts largos.
• El tono corporativo o la jerga son muy específicos. Un modelo de atención al cliente para un banco privado, por ejemplo, necesita un nivel de formalidad y una terminología que un modelo genérico no reproduce de manera consistente.
• El dato del dominio es relativamente estable. Si los procedimientos o los criterios de decisión del negocio cambian menos de una vez al trimestre, el coste del reentrenamiento es asumible.

En Summum IA, cuando acompañamos proyectos de fine-tuning a medida, empezamos siempre por establecer la línea base con el modelo base sin ajustar: si ya cumple el 80% del objetivo solo con un buen prompt, raramente merece la pena el coste del ajuste fino.

Cuándo elegir RAG

RAG es la arquitectura de partida para la mayoría de los casos de uso empresariales porque combina flexibilidad y rapidez de despliegue. Elige RAG cuando:

• El conocimiento cambia con frecuencia. Documentación de producto, normativas, precios, procedimientos internos: todo aquello que se actualiza más de una vez al mes encaja mucho mejor en una base de conocimiento indexada que en los pesos de un modelo.
• La trazabilidad de la fuente es un requisito. En sectores regulados —seguros, banca, farmacia— poder mostrar que la respuesta viene de la sección 4.2 del manual de procedimientos es, a veces, un requisito legal, no solo una buena práctica.
• No tienes datos de entrenamiento etiquetados. Etiquetar cientos de pares (pregunta, respuesta ideal) es costoso. Si tienes documentos pero no ejemplos etiquetados, RAG es el camino natural.
• El corpus es grande y heterogéneo. Miles de PDFs, contratos, manuales técnicos, correos históricos: RAG convierte esa masa documental en base de consulta sin necesidad de procesarla manualmente.

Nuestro servicio de implementación RAG empresarial cubre el diseño del índice, la estrategia de chunking, la elección del modelo de embeddings y la evaluación de la recuperación antes de poner el sistema en producción.

La combinación: fine-tuning + RAG

En los casos más exigentes, la respuesta no es una u otra técnica, sino las dos en capas. El patrón más común es un modelo ajustado que actúa como lector: se ajusta el modelo para que sepa leer e interpretar bien los fragmentos recuperados del corpus de la empresa (terminología, estructura de los documentos), y luego esos fragmentos llegan vía RAG con la información actualizada.

Este enfoque combinado lo usan, por ejemplo, asistentes especializados en derecho fiscal o en medicina, donde el modelo necesita tanto dominar el idioma técnico del dominio (fine-tuning) como acceder a jurisprudencia o guías clínicas actualizadas (RAG). El coste de desarrollo es mayor, pero la calidad de respuesta justifica la inversión cuando el riesgo de error tiene consecuencias reales para el negocio.

Qué evaluar antes de decidir

Antes de comprometerse con una arquitectura, conviene responder honestamente a estas cuatro preguntas:

1. ¿Con qué frecuencia cambia el conocimiento relevante? Si la respuesta es «cada semana o más», RAG gana por comodidad operativa.
2. ¿Tienes datos etiquetados o solo documentos? Sin ejemplos (instrucción → respuesta ideal), el fine-tuning es difícil de hacer bien.
3. ¿El modelo base ya cumple el 80% del objetivo con un prompt bien diseñado? Si sí, ni fine-tuning ni RAG: optimiza el prompt primero.
4. ¿El caso de uso requiere auditar la fuente de cada respuesta? En ese caso RAG es prácticamente obligatorio.

Costes reales en 2025-2026

El mercado ha evolucionado mucho en los últimos dos años. A modo orientativo, con datos de proveedores cloud públicos a 2025:

• Fine-tuning de un modelo de 7B parámetros con LoRA en GPU A100: entre 50 y 150 euros por ciclo completo de entrenamiento (unos pocos miles de ejemplos). La evaluación rigurosa y la ingeniería de datos suele costar más que el cómputo.
• Fine-tuning vía API de proveedor (OpenAI, Google Vertex, Azure): entre 0,008 y 0,030 dólares por cada 1.000 tokens de entrenamiento, según el modelo base. Un conjunto de 10.000 ejemplos de 500 tokens puede costar entre 40 y 150 dólares solo en compute.
• RAG con modelo en la nube: el coste dominante es la inferencia y el almacenamiento del índice vectorial. Con volúmenes medios (1-5 millones de fragmentos), los costes de indexación son menores de 100 euros; el coste operativo recurrente depende del volumen de consultas.
• Modelos soberanos en infraestructura propia: si los datos no pueden salir de la empresa, el análisis de coste-beneficio cambia radicalmente. Para estos casos, el equipo de IA soberana de Summum evalúa opciones de despliegue en hardware propio o en nube privada certificada.

Implicaciones del AI Act europeo

El Reglamento (UE) 2024/1689 (AI Act), en aplicación progresiva desde agosto de 2024, afecta directamente a las decisiones de arquitectura. Los sistemas de IA de alto riesgo —incluidos algunos clasificadores y asistentes de toma de decisiones— están sujetos a requisitos de trazabilidad, explicabilidad y gestión de datos de entrenamiento que condicionan el fine-tuning. En particular:

• Los datos usados para ajustar un modelo de alto riesgo deben documentarse conforme al Artículo 10 del Reglamento (gobernanza de datos, calidad, representatividad).
• Si el sistema toma decisiones que afectan a personas (crédito, empleo, sanidad), la capacidad de explicar cada respuesta —favorecida por RAG con fuentes visibles— facilita el cumplimiento del requisito de transparencia del Artículo 13.

Para las empresas que ya trabajan con la ISO 42001 (Sistema de Gestión de IA), la elección de arquitectura debe quedar documentada en el registro de riesgos del sistema y aprobada por el rol de «responsable de IA» definido en la norma.

Preguntas frecuentes

¿Puedo hacer fine-tuning sin saber programar?

Depende del proveedor. Plataformas como OpenAI o Azure ofrecen interfaces gráficas para subir datos y lanzar ciclos de fine-tuning sin escribir código. Sin embargo, la fase crítica —preparar y etiquetar correctamente los datos de entrenamiento— requiere siempre criterio experto sobre qué respuestas son «buenas» para el dominio concreto. La interfaz es sencilla; el diseño del conjunto de entrenamiento, no.

¿Cuántos ejemplos necesito para hacer fine-tuning?

La regla general es que con 200-500 ejemplos bien etiquetados ya se aprecia mejora en comportamiento para tareas de clasificación o extracción. Para tareas generativas (respuestas largas, redacción con tono específico) se suele necesitar entre 1.000 y 5.000 ejemplos para resultados robustos. La calidad de los ejemplos importa más que la cantidad: 300 pares perfectos superan a 3.000 pares mediocres.

¿RAG funciona con documentos en español?

Sí, sin problema, pero la elección del modelo de embeddings es clave. Modelos multilingües como multilingual-e5-large o modelos especializados en español (como algunos de la familia BETO o los publicados por BSC-CNS) ofrecen mejor recuperación que modelos entrenados solo en inglés. En Summum IA siempre evaluamos comparativamente al menos dos modelos de embeddings antes de fijar la arquitectura de producción.

¿El fine-tuning protege mis datos? ¿Se usan para entrenar modelos de terceros?

Depende del contrato con el proveedor. Los principales proveedores cloud (Microsoft Azure, Google Vertex, AWS Bedrock) garantizan en sus acuerdos empresariales que los datos de fine-tuning no se usan para mejorar sus modelos base. Es imprescindible leer y negociar el contrato antes de subir datos sensibles, y en sectores regulados (salud, banca) conviene optar por modelos desplegados en infraestructura privada. Si tus datos no pueden salir de tu perímetro, la opción de IA soberana resuelve el problema de raíz.