RAG vs. fine-tuning para el conocimiento de la empresa: guía para compradores

Tarde o temprano, todo equipo que evalúa IA para el conocimiento interno escucha ambos términos en la misma reunión: "deberíamos hacer fine-tuning de un modelo con nuestros documentos" y "deberíamos montar RAG". Suenan intercambiables. No lo son: cambian partes distintas del sistema, cuesta distinto mantenerlos vivos y fallan de formas diferentes.

No necesitas formación en ML para elegir bien. Necesitas saber qué hace realmente cada técnica y qué cuesta después del lanzamiento.

Qué hace realmente cada técnica

• RAG (generación aumentada por recuperación) deja el modelo intacto y le da acceso de búsqueda a tus documentos. Cuando llega una pregunta, el sistema recupera los pasajes más relevantes y el modelo responde a partir de ellos, como un recién llegado brillante con un buscador muy bueno. Puede mostrar exactamente qué documentos usó.
• Fine-tuning cambia el propio modelo entrenándolo con cientos o miles de ejemplos. El modelo interioriza patrones (tono, formato, reglas de clasificación) como un empleado interioriza un curso de formación. No puede citar dónde aprendió algo, y el conocimiento queda congelado en el momento del entrenamiento.

El error de compra más común es tratar el fine-tuning como "enseñarle al modelo nuestros documentos". Eso es justo lo que hace de forma poco fiable: los hechos se difuminan, las fuentes desaparecen y actualizar exige reentrenar. Para conocimiento, el fine-tuning es la herramienta equivocada usada con mucha confianza.

Por qué RAG con citas es la opción por defecto correcta

• Datos frescos. Cuando cambia una lista de precios o una política, reindexas el documento en minutos. Sin reentrenos ni ciclos de release.
• Trazabilidad. Cada respuesta lleva citas al documento y la sección de origen, así que un experto verifica en segundos en lugar de re-investigar. Describimos el patrón en búsqueda de conocimiento con citas.
• Control de acceso. La recuperación puede filtrar por los permisos del usuario que pregunta antes de que el modelo vea nada. El conocimiento incrustado en los pesos no se puede ocultar por usuario: una vez está en el modelo, lo tiene todo el que accede al modelo.
• Depurabilidad. Una respuesta errónea viene con una causa visible: mira qué se recuperó. El análisis de fallos consiste en leer, no en hacer análisis forense de ML.

Un benchmark interno de nuestras entregas de búsqueda de conocimiento: la aceptación de respuestas de IA por parte de los revisores aproximadamente se duplica cuando cada respuesta enlaza a sus pasajes de origen. El modelo es el mismo; la confianza la generan las citas.

Cuándo el fine-tuning se gana su coste

• Formato y estilo a escala. Miles de salidas al día con una estructura propia exacta (descripciones de producto, resúmenes codificados, plantillas regulatorias) donde la consistencia solo con prompts se sigue escapando.
• Clasificación con histórico etiquetado. Años de tickets, expedientes o documentos etiquetados. Un modelo pequeño con fine-tuning suele ser más consistente y mucho más barato por llamada que un modelo frontera con prompts.
• Techos de latencia y coste. Destilar una tarea estrecha en un modelo más pequeño puede recortar el coste por llamada en un orden de magnitud con la misma calidad en esa tarea.
• Despliegues restringidos. Entornos on-premise o edge donde solo caben modelos pequeños, y el modelo pequeño necesita ayuda para alcanzar calidad de producción.

Fíjate en lo que falta en esta lista: "añadir el conocimiento de la empresa". El fine-tuning se gana su coste en comportamiento, no en hechos.

El patrón híbrido

Los sistemas maduros suelen combinar ambas técnicas, cada una en el trabajo que se le da bien:

• Una capa RAG aporta los hechos, con citas y filtrado por permisos
• Un modelo pequeño con fine-tuning (o con prompts muy ajustados) lleva el enrutado y el formateo de alto volumen
• Un modelo frontera se encarga de los pasos de síntesis de bajo volumen y alto riesgo

Un help desk es el ejemplo canónico: un clasificador pequeño enruta tickets, RAG redacta respuestas ancladas en el corpus de ayuda vigente y un modelo más potente compone los escalados difíciles. En ese punto, esto ya es automatización de flujos de trabajo con IA normal y corriente: cada paso recibe el componente más barato que pasa la evaluación.

Coste y mantenimiento comparados

Qué debe probar un PoC de dos semanas

Para el conocimiento de empresa, el primer proyecto correcto es una búsqueda RAG sobre un conjunto de documentos bien elegido, juzgada con un conjunto de evaluación y no con una demo. Dos semanas bastan para probar (o refutar) cinco cosas:

• Existe y está acordado un gold set de 50-100 preguntas reales con fuentes correctas conocidas
• Tasa de acierto de la recuperación: con qué frecuencia el documento correcto llega delante del modelo
• Precisión de las citas: los pasajes citados sostienen de verdad la respuesta dada
• Rechazos honestos: qué pasa con las preguntas que el corpus no puede responder
• Coste y latencia por consulta a volumen diario realista

Ese es el formato de nuestro PoC DX Rápido (11.500-16.500 €): dos semanas, demos semanales, un informe de evaluación y documentación de traspaso con la que tu equipo puede trabajar, vaya o no con nosotros la siguiente fase.

Compra la pregunta, no la técnica

La decisión RAG versus fine-tuning va menos de machine learning que de qué propiedad necesita primero tu negocio. Si las respuestas deben ser actuales, verificables y respetar permisos, eso es RAG, y eso es la mayor parte del conocimiento de empresa. Si lo que hace falta es una forma de salida precisa repetida miles de veces al día, el fine-tuning se ganará el puesto: normalmente más tarde, en un paso estrecho, cuando el volumen lo justifique.

La mayoría de los equipos de negocio necesitan RAG ahora y fine-tuning quizá más adelante. Empezar por la semana de auditoría de los paquetes lo zanja con datos: un conjunto de evaluación, un modelo de costes y una recomendación por escrito en lugar de una técnica elegida por moda.