RAG vs fine-tuning: qué necesitan de verdad las empresas

Casi todos los proyectos de IA que comentamos con clientes empiezan con la misma pregunta: «¿Deberíamos hacer fine-tuning de un modelo con nuestros datos?». A veces la respuesta es sí. Más a menudo, la necesidad real es otra: un asistente que conozca tus documentos actuales, cite sus fuentes y pueda actualizarse un martes por la tarde sin lanzar un entrenamiento. Este artículo explica las opciones principales en lenguaje claro, cuándo encaja cada una y cómo decidir sin quemar meses en el enfoque equivocado.

Las cuatro herramientas de la caja#

Cuando alguien dice «enseñarle al modelo cómo es nuestro negocio», suele referirse a una de cuatro técnicas distintas. Resuelven problemas diferentes y se pueden combinar.

Generación aumentada por recuperación (RAG)#

RAG deja el modelo tal como está. En su lugar, cuando llega una pregunta, el sistema busca primero en tu propio contenido, como manuales, contratos, tickets o un catálogo de productos, y le pasa al modelo los pasajes más relevantes junto con la pregunta. El modelo responde entonces a partir de esos pasajes.

Aquí importan tres ideas:

• Recuperación (retrieval): encontrar los pasajes correctos. Suele ser una mezcla de búsqueda semántica sobre embeddings y búsqueda clásica por palabras clave, a menudo seguida de un paso de reranking.
• Grounding: indicar al modelo que responda a partir del material aportado, y que lo diga cuando el material no contiene la respuesta.
• Citas: señalar el documento, la página o el pasaje exactos de los que sale una respuesta, para que una persona pueda comprobarla.

RAG brilla cuando el conocimiento cambia con frecuencia, cuando el corpus es grande y cuando la gente necesita verificar las respuestas.

Fine-tuning#

El fine-tuning continúa el entrenamiento de un modelo con tus propios ejemplos, de modo que su comportamiento cambia. Es bueno para enseñar cómo responder: un tono coherente, un formato de salida estricto, un esquema de clasificación propio del sector o una tarea acotada que se ejecuta miles de veces al día. Es una mala forma de enseñar qué es cierto ahora mismo. Los hechos aprendidos mediante fine-tuning son difíciles de actualizar, difíciles de rastrear hasta una fuente, y pueden mezclarse o recordarse mal.

El fine-tuning también te permite trasladar una tarea acotada a un modelo más pequeño, barato y rápido, algo que puede pesar mucho con volúmenes altos.

Contexto largo con prompt caching#

Los modelos modernos de Anthropic, OpenAI y varias familias de modelos open source aceptan entradas muy largas. Si tu base de conocimiento tiene un tamaño modesto, por ejemplo un manual de producto, un conjunto de políticas o una colección de preguntas frecuentes, a menudo puedes meterla entera directamente en el prompt. Sin índice, sin pipeline de recuperación y sin decisiones de chunking.

La objeción evidente es el coste y la latencia: enviar el mismo documento grande con cada petición es un desperdicio. El prompt caching resuelve esto. Los proveedores pueden guardar en caché un prefijo estable del prompt, de modo que las peticiones repetidas reutilizan el contenido ya procesado y se facturan y se sirven de forma más eficiente. Para un cuerpo de conocimiento estable y acotado, el contexto largo con caché suele ser lo más sencillo que funciona.

Salidas estructuradas#

Muchos proyectos de «IA» son en realidad proyectos de extracción: leer una factura, un currículum, un contrato o un correo y producir campos limpios. Aquí la capacidad clave son las salidas estructuradas (structured outputs), en las que se obliga al modelo a devolver datos que se ajustan a un esquema que tú defines, por ejemplo JSON con campos y tipos concretos. Esto no tiene nada que ver con el conocimiento. Tiene que ver con la fiabilidad del formato, y normalmente hace innecesario el fine-tuning en las tareas de extracción.

Cuándo encaja cada enfoque#

Una forma útil de pensarlo: separa el conocimiento del comportamiento.

• Conocimiento reciente o cambiante, y respuestas que la gente debe verificar: usa RAG, o contexto largo si el material es lo bastante pequeño. Ambos te permiten actualizar el conocimiento actualizando documentos, y ambos admiten citas.
• Conocimiento estable y acotado que cabe en la ventana de contexto: empieza con contexto largo y prompt caching. Pasa a RAG cuando el material se quede grande o cuando necesites un control de acceso fino por documento.
• Estilo, tono o formato coherentes en muchas salidas: prueba primero con instrucciones claras y unos cuantos buenos ejemplos en el prompt. Si con tu volumen no basta, el fine-tuning es una opción legítima.
• Clasificación o enrutamiento acotados a gran escala: hacer fine-tuning de un modelo más pequeño, o simplemente usar un modelo general más pequeño con un prompt bien diseñado, suele ser el camino más económico.
• Extracción de campos de documentos: salidas estructuradas, combinadas si hace falta con documentos como entrada y citas, para que cada valor extraído pueda rastrearse.

No son excluyentes. Un sistema maduro puede usar RAG para el conocimiento, salidas estructuradas para el formato de la respuesta y un pequeño modelo con fine-tuning para enrutar las peticiones entrantes.

Comparativa lado a lado#

Una checklist práctica para decidir#

Antes de elegir una arquitectura, responde con honestidad a estas preguntas:

1. ¿Cuál es la tarea, exactamente? ¿Responder preguntas, redactar texto, clasificar o extraer? Escribe cinco ejemplos reales de entrada y de salida ideal.
2. ¿Con qué frecuencia cambia el conocimiento de base? Los cambios diarios o semanales apuntan claramente en contra del fine-tuning.
3. ¿Necesitan los usuarios verificar las respuestas? En contextos legales, financieros, de compliance, de soporte o sanitarios, las citas no suelen ser negociables.
4. ¿Cómo de grande es la base de conocimiento? Si cabe con holgura en una ventana de contexto, prueba primero el contexto largo con caché.
5. ¿Quién puede ver qué? Si distintos usuarios tienen acceso a distintos documentos, necesitas recuperación con filtrado por permisos, no un único prompt compartido ni un modelo entrenado con todo.
6. ¿Qué volumen y qué latencia esperas? Un volumen alto en una tarea acotada es donde los modelos más pequeños o con fine-tuning se ganan el sueldo.
7. ¿Tienes ejemplos etiquetados? El fine-tuning sin un conjunto considerable de buenos ejemplos rara vez supera a un prompt bien escrito.
8. ¿Cómo vas a medir el éxito? Si no puedes responder a esto, para y construye primero un conjunto de evaluación.

Si la mayoría de las respuestas apuntan a «conocimiento cambiante, necesita citas, volumen moderado», lo tuyo es RAG o contexto largo. Si apuntan a «tarea estable, formato estricto, volumen muy alto», plantéate el fine-tuning o un modelo más pequeño.

Errores habituales#

Estos son los problemas que vemos más a menudo cuando revisamos sistemas de IA que «casi funcionan».

• Mal chunking. Dividir los documentos en trozos arbitrarios de tamaño fijo parte las tablas por la mitad, separa los títulos de su contenido y pierde contexto. Divide siguiendo la estructura del documento y conserva metadatos útiles como el título, la sección y la fecha.
• Sin evaluaciones. Sin un conjunto de evaluación, cada cambio es una apuesta. Los equipos retocan prompts, cambian de modelo y modifican el tamaño de los chunks sin saber si la cosa ha mejorado o empeorado.
• Índices desactualizados. Los documentos de origen se actualizaron y el índice no. El asistente cita con total seguridad la política del año pasado. La reindexación debe formar parte del flujo de trabajo de contenidos, no ser una tarea manual que se deja para después.
• Alucinaciones sin citas. Si el sistema no muestra de dónde sale una respuesta, los usuarios no pueden distinguir una respuesta fundamentada de una inventada. Exige citas y enseña al modelo a decir «no lo sé» cuando las fuentes no dicen nada.
• Privacidad y RGPD. Los datos personales en documentos, prompts y logs siguen siendo datos personales. Ten claro qué proveedor los trata, en qué región, con qué contrato de encargo del tratamiento y cuánto tiempo se conservan los logs. El fine-tuning con datos personales merece una cautela especial, porque eliminarlos después es difícil.
• Prompt injection desde los documentos. El contenido recuperado es una entrada no fiable. Un documento puede contener texto que intente dar instrucciones al modelo, por ejemplo que ignore sus reglas o que revele otros datos. Trata el texto recuperado como datos, limita lo que el modelo puede hacer con herramientas y no permitas nunca que el contenido de un documento conceda permisos.

Evalúa antes de optimizar#

El paso más valioso de cualquier proyecto de IA es también el menos vistoso: construir un conjunto de evaluación antes de elegir una arquitectura.

Un buen conjunto inicial son, sencillamente, entre unas decenas y unos cientos de preguntas o entradas reales, cada una con la respuesta esperada o con los documentos que deberían citarse. Después mide:

• Calidad de la recuperación: ¿encontró el sistema los pasajes correctos?
• Calidad de la respuesta: ¿es la respuesta correcta, completa y fundamentada en las fuentes?
• Exactitud de las citas: ¿respaldan de verdad los pasajes citados la afirmación?
• Comportamiento de negativa: ¿dice «no lo sé» cuando debe?
• Cumplimiento del formato: en extracción, ¿se ajusta cada salida al esquema?

Con esto en marcha, las comparaciones pasan a basarse en hechos. Puedes probar el contexto largo frente a RAG, un modelo frente a otro, o un modelo con fine-tuning frente a uno con prompt, con tus propios datos y no con benchmarks genéricos. A menudo descubrirás que el arreglo más barato es una mejor recuperación o un prompt más claro, no un modelo más grande ni un entrenamiento.

La corrección automática con un modelo puede acelerarlo, pero contrástala con revisores humanos mediante muestreo, sobre todo al principio.

Cómo ilustran estos patrones nuestras propias demos#

Intentamos practicar lo que recomendamos, y dos demos de este sitio muestran los patrones en acción.

El sigmacode Assistant responde a preguntas sobre nuestros servicios y nuestra forma de trabajar. Su base de conocimiento es pequeña y está deliberadamente congelada, así que, en lugar de un pipeline de recuperación, usa contexto largo con prompt caching: toda la base de conocimiento se encuentra en un prefijo de prompt en caché, y el modelo tiene instrucciones de responder únicamente a partir de él. Para un cuerpo de conocimiento acotado, esto es más sencillo de construir y más fácil de mantener correcto que un índice vectorial.

La demo Preguntas a documentos con citas muestra la otra cara. Aportas un documento, haces preguntas y cada respuesta llega con citas que señalan los pasajes en los que se ha basado. Esa es la promesa central de la IA fundamentada en fuentes: cada afirmación puede contrastarse con su origen.

Ninguna de las dos demos necesitó fine-tuning. Es lo habitual. En la mayoría de los problemas de conocimiento empresarial, el grounding y una buena evaluación importan más que un entrenamiento a medida.

La versión corta#

• Usa RAG cuando el conocimiento es grande, cambia con frecuencia, necesita control de acceso o debe citarse.
• Usa contexto largo con prompt caching cuando el conocimiento es estable y cabe en la ventana.
• Usa fine-tuning o modelos más pequeños para un comportamiento coherente o tareas acotadas con mucho volumen, no para los hechos.
• Usa salidas estructuradas para la extracción y para cualquier salida que un sistema tenga que parsear.
• Evalúa primero y después optimiza lo que los números te indiquen.

Si estás sopesando estas opciones para un proyecto real, nuestro equipo de IA y automatización, dirigido por un tech lead con más de 20 años de experiencia, puede ayudarte a definir el alcance, construir un conjunto de evaluación y lanzar una primera versión que puedas medir de verdad. Escríbenos y cuéntanos qué intentas resolver: un ingeniero sénior te responde en 24 horas en días laborables.