Fine-tuning o RAG: elección, datos y costos

Elija RAG si el modelo necesita consultar información privada, reciente o respaldada por fuentes; considere el fine-tuning si necesita mejorar de forma duradera un comportamiento especializado mediante ejemplos corregidos. Empiece por medir los errores de un modelo con instrucciones adecuadas: ambas técnicas pueden combinarse, pero ninguna sustituye a los datos fiables ni a una evaluación independiente.

Qué cambia realmente con cada enfoque

El RAG, o generación aumentada por recuperación, incorpora una búsqueda antes de generar la respuesta. El sistema selecciona fragmentos de una colección de documentos y los envía al modelo junto con la pregunta. En esta arquitectura habitual, los parámetros del modelo generador no se modifican.

El fine-tuning, o ajuste fino, continúa el entrenamiento de un modelo existente. En su modalidad supervisada, utiliza ejemplos que relacionan una entrada con la salida deseada: clasificar una solicitud, extraer campos o redactar una respuesta conforme a una convención del sector.

La distinción entre conocimientos y comportamiento es un buen punto de partida, aunque no establece una frontera absoluta. Un entrenamiento puede hacer que el modelo memorice hechos; los ejemplos incluidos en el contexto pueden modificar su comportamiento. La cuestión práctica es dónde conviene situar la información para poder controlarla, actualizarla y comprobar cómo se utiliza.

La comparación publicada en la documentación de AWS recomienda empezar por RAG para consultar documentos propios de una organización. También señala que ambos enfoques pueden combinarse.

Para revisar los componentes disponibles, consulte las fichas de modelos de lenguaje. Elegir un buen modelo base para su tarea puede evitar una personalización costosa.

Tabla de decisión: información, comportamiento y restricciones

Criterio	RAG	Fine-tuning
Objetivo principal	Dar acceso a información seleccionada	Adaptar las respuestas a una tarea o un comportamiento
Datos de partida	Documentos utilizables y metadatos	Ejemplos representativos con las salidas esperadas
Actualización	Actualizar las fuentes y su índice	Preparar y evaluar un nuevo entrenamiento
Referencias documentales	Posibles si los fragmentos conservan su procedencia	El aprendizaje no las proporciona automáticamente
Control de acceso	Debe aplicarse al seleccionar los documentos	Difícil de individualizar para los hechos memorizados
Costo inicial	Preparación, ingesta, búsqueda e integración	Anotación, entrenamiento, evaluación y despliegue
Costo por solicitud	Búsqueda, contexto enviado y generación	Inferencia del modelo personalizado y posible alojamiento
Fallo característico	El fragmento útil no llega al modelo	El comportamiento aprendido no se generaliza bien

Una documentación que cambia con frecuencia, los procedimientos internos o las fichas de productos apuntan hacia la recuperación de información. Una clasificación estable y repetitiva, con categorías bien definidas, puede justificar un entrenamiento especializado.

La trazabilidad exige, sin embargo, una precisión: recuperar una fuente no garantiza que la respuesta respete su contenido. Es necesario conservar el fragmento utilizado, comprobar que respalda la afirmación y distinguir una referencia pertinente de un simple enlace añadido al final de la respuesta.

Además, ni RAG ni el fine-tuning son imprescindibles para todas las tareas. Si unos pocos documentos caben en el contexto y su acceso está autorizado, puede bastar con enviarlos directamente. Para un cálculo exacto o un dato transaccional, una consulta determinista puede ser más adecuada.

Diagnostique los errores antes de elegir

Reúna un conjunto de solicitudes representativas y observe el resultado de una solución sencilla: instrucciones claras, ejemplos pertinentes y un modelo adecuado. Después, clasifique los errores según su causa probable, en lugar de agruparlos bajo una única puntuación baja.

Una prueba de diagnóstico útil consiste en proporcionar manualmente al modelo el fragmento correcto. Si responde bien, es probable que la dificultad esté en el acceso a la información. Si falla pese a disponer de pruebas completas y legibles, revise las instrucciones, la capacidad del modelo o la complejidad de la tarea.

Distinga, en particular, entre estos casos:

Falta de información: el sistema no dispone de la respuesta.
Fallo de búsqueda: la respuesta existe, pero no se recupera el fragmento útil.
Uso incorrecto de la información: el fragmento adecuado está presente, pero se interpreta mal.
Comportamiento inestable: el modelo comprende la tarea, pero aplica de forma incorrecta una convención recurrente.
Tarea mal definida: los propios evaluadores no coinciden en cuál debería ser la salida.

Conviene experimentar con fine-tuning cuando el comportamiento sigue fallando pese a contar con instrucciones y contexto adecuados. Esta técnica no corrige directamente una extracción documental que ha perdido las columnas de una tabla.

Si necesita un formato estricto, pruebe primero la generación restringida por un esquema, cuando el motor lo permita, y después una validación desde la aplicación. Entrenar al modelo para producir una estructura no elimina la necesidad de comprobar los campos, los tipos y los valores permitidos.

Qué datos necesita para construir un RAG

Una carpeta llena de archivos todavía no es una base de conocimiento utilizable. Debe identificar los documentos de referencia, eliminar duplicados y conservar la fecha de aplicación, la versión documental, la procedencia y los permisos de acceso.

La preparación depende del contenido. En una tabla hay que preservar las relaciones entre celdas; en un procedimiento, las condiciones y excepciones. Dividir los documentos de forma mecánica puede separar una regla de la restricción que cambia su significado.

Un embedding representa un contenido de forma numérica para facilitar la búsqueda por similitud. No comprueba su validez ni si está actualizado. Según las solicitudes, puede resultar más apropiada una búsqueda que combine similitud semántica, palabras clave y filtros que una búsqueda exclusivamente semántica.

Prepare también preguntas de referencia asociadas a los fragmentos que deberían recuperarse. Incluya siglas del sector, referencias exactas, preguntas ambiguas y solicitudes para las que no haya una respuesta disponible. Así podrá evaluar la selección de documentos antes de valorar la redacción de las respuestas.

La guía de referencia sobre RAG explica la división en fragmentos y la indexación. Para elegir una solución, nuestra selección de herramientas de bases documentales y RAG permite examinar los componentes sin confundir una base de búsqueda con una aplicación completa.

Prevea también la retirada de documentos obsoletos. Añadir un procedimiento nuevo sin desactivar el anterior deja al sistema ante textos contradictorios, a veces casi idénticos, entre los que tendrá que elegir.

Qué datos necesita para hacer fine-tuning

En un entrenamiento supervisado, debe mostrar lo que el modelo tendrá que producir en las condiciones reales de uso. Cada ejemplo debe contener una entrada representativa y una salida corregida conforme a una regla explícita. Acumular respuestas históricas sin revisarlas puede hacer que el modelo aprenda las incoherencias del servicio.

La cobertura de casos importa tanto como el volumen. Un conjunto formado únicamente por solicitudes fáciles aportará poca información sobre las excepciones. Incluya entradas incompletas, formulaciones poco habituales, categorías similares y situaciones en las que la respuesta correcta sea pedir una aclaración.

Separe los datos de entrenamiento, validación y prueba. Evite que variantes de un mismo expediente aparezcan en distintos conjuntos: el modelo podría reconocer un caso en vez de aprender la tarea. Según el uso, puede ser necesario separar los datos por cliente, documento o período.

No existe un umbral universal de ejemplos. Empiece por un conjunto controlado, amplíe su diversidad y registre el rendimiento en la prueba independiente. Si la mejora se estanca, examine las anotaciones antes de contratar más capacidad de cómputo.

Los ejemplos sintéticos pueden complementar los datos, pero requieren verificación. Un generador puede repetir el mismo error con formulaciones distintas. Conserve la procedencia de los ejemplos y distinga los validados por un especialista de los que siguen siendo automáticos.

Por último, redacte unas instrucciones de anotación que puedan utilizar varias personas. Los desacuerdos sobre la respuesta esperada suelen revelar un problema de definición que el entrenamiento no resolverá.

Fine-tuning completo, adaptadores y funcionamiento

El fine-tuning completo ajusta todos los parámetros entrenables seleccionados para el modelo. Los métodos basados en adaptadores limitan los parámetros que se modifican. La documentación técnica de LoRA explica cómo este enfoque mantiene fijos los pesos de base y aprende matrices de adaptación más pequeñas.

Esta reducción afecta a los parámetros entrenables; no significa que el modelo base desaparezca. Tanto el entrenamiento como la inferencia siguen necesitando cargar los elementos correspondientes, con requisitos de memoria que dependen del modelo, el contexto y la configuración.

Un adaptador también debe mantener la compatibilidad con su modelo base. Archive el identificador exacto del modelo, los parámetros de entrenamiento, los datos utilizados y los resultados de evaluación. Un archivo de adaptación aislado no basta para reproducir una aplicación.

Si utiliza una API alojada, compruebe en el momento del proyecto qué modelos admiten personalización, qué formatos se aceptan y cuáles son las condiciones de despliegue. Que un modelo esté disponible para inferencia no demuestra que admita fine-tuning.

Si usted gestiona el despliegue, incorpore a la decisión la licencia, el mantenimiento y los recursos de cómputo. La posibilidad técnica de entrenar no resuelve los derechos de uso de los datos ni las restricciones operativas.

Ante todo, el modelo elegido debe realizar correctamente la tarea después de la personalización. Una reducción de la pérdida de entrenamiento indica que la optimización avanza sobre sus ejemplos; por sí sola, no demuestra una mejora ante solicitudes nuevas.

Calcule el costo total, más allá de los tokens

RAG añade varias partidas de gasto: extracción, indexación inicial, actualizaciones, almacenamiento, búsqueda, posible reordenamiento de resultados y contexto enviado al generador. El fine-tuning añade la preparación de ejemplos, las pruebas de entrenamiento, su evaluación y el despliegue del modelo resultante.

El trabajo humano forma parte del presupuesto. Limpiar un corpus o resolver anotaciones contradictorias puede costar más que las llamadas al modelo. Cuente también las nuevas evaluaciones necesarias cuando cambie un procedimiento, una categoría o el modelo base.

Partida	RAG	Fine-tuning
Puesta en marcha	Limpieza documental y sistema de búsqueda	Definición de la tarea y anotación
Cómputo inicial	Extracción e indexación	Entrenamientos y pruebas
Funcionamiento	Búsqueda, almacenamiento y generación	Inferencia y alojamiento del modelo adaptado
Mantenimiento	Sincronización y retirada de fuentes	Nuevos ejemplos y reentrenamiento
Control de calidad	Búsqueda, pruebas documentales y respuesta	Generalización y regresiones

Las unidades facturadas dependen del proveedor. La documentación de personalización de Amazon Bedrock describe, entre otros conceptos, una facturación del entrenamiento basada en los tokens del corpus multiplicados por las pasadas de entrenamiento, además del almacenamiento del modelo. Estas condiciones no constituyen una tarifa universal.

Compare los costos para un mismo período:

Costo total = preparación + experimentación + funcionamiento + mantenimiento + gestión de errores.

La última partida incluye las correcciones manuales y las solicitudes que deben repetirse. La calculadora de precios de LLM ayuda a estimar el consumo; debe completar esa cantidad con sus costos de infraestructura y personal.

Un ejemplo con cifras y el punto de equilibrio

Tomemos un escenario hipotético de cálculo, sin medición de rendimiento: una aplicación procesa 10 000 solicitudes mensuales. Cada solicitud contiene 1 000 tokens de instrucciones y pregunta, recibe 4 000 tokens de documentación y produce 500 tokens.

Para aislar el costo de generación, utilizaremos las tarifas de GPT-6.1 Sol: 2 dólares por millón de tokens de entrada y 10 dólares por millón de tokens de salida, según el registro del sitio de octubre de 2026. Este ejemplo no presupone que el fine-tuning esté disponible para ese modelo.

Con estos supuestos, sin caché, descuentos ni llamadas adicionales:

Entrada mensual: 50 millones de tokens, equivalentes a 100 dólares.
Salida mensual: 5 millones de tokens, equivalentes a 50 dólares.
Generación total: 150 dólares, de los cuales 80 dólares corresponden a los fragmentos documentales.

Esta cantidad excluye la búsqueda, la indexación, el alojamiento y el mantenimiento. Ilustra por qué conviene medir la longitud de los fragmentos útiles, en lugar de enviar siempre más documentos.

Un modelo personalizado podría reducir ciertos ejemplos o instrucciones repetidos. Sin embargo, no permite retirar los documentos necesarios para consultar hechos recientes sin alterar la fiabilidad esperada.

El punto de equilibrio se calcula así: costo fijo adicional de personalización dividido entre el ahorro neto por solicitud resuelta correctamente. Este ahorro debe incluir las correcciones, las repeticiones y el alojamiento. Si es nulo o negativo, el entrenamiento no se amortiza por volumen; en ese caso, debe justificarse por una mejora de calidad medida.

Ejemplos de elección y arquitectura combinada

Las situaciones siguientes son ejemplos hipotéticos de diseño, no casos de clientes ni resultados observados.

Asistente de soporte documental. Debe explicar las condiciones aplicables a un producto concreto. Un RAG puede seleccionar la documentación correspondiente al producto y a su período de validez. La prueba decisiva consiste en comprobar si utiliza el procedimiento correcto, respeta sus excepciones y justifica la respuesta.

Clasificación de solicitudes entrantes. Hay que asignar una categoría estable a cada mensaje según una clasificación interna. Tras una prueba con instrucciones y ejemplos, puede evaluarse un fine-tuning para abordar las confusiones recurrentes. Si las categorías cambian con frecuencia, el costo de volver a anotarlas se convierte en un factor determinante.

Redacción conforme a una convención del sector. El sistema debe consultar los procedimientos vigentes y después elaborar una respuesta con una estructura concreta. RAG aporta los hechos; un entrenamiento puede mejorar la forma de utilizarlos. En ese caso, los ejemplos deben contener el contexto documental que estará realmente disponible.

La publicación RAFT: Adapting Language Model to Domain Specific RAG estudia una combinación de este tipo, con un entrenamiento que incluye documentos pertinentes y documentos distractores. Ofrece una posible vía de diseño, sin garantizar una mejora en su corpus.

Antes de adoptar esta arquitectura, compárela con RAG por sí solo. La combinación añade componentes y datos que habrá que mantener. Para entender una necesidad relacionada, el artículo sobre la memoria de los agentes de IA distingue entre conservar información de una sesión a otra y entrenar el modelo.

Evalúe la búsqueda y la respuesta por separado

Una media global puede ocultar qué componente falla. En RAG, mida primero si se recuperan las pruebas documentales esperadas. Después, evalúe si la respuesta respeta esas pruebas, atiende la solicitud y reconoce la información que falta.

La documentación de Microsoft sobre evaluadores de RAG distingue, entre otras dimensiones, la calidad de recuperación, el respaldo en el contexto, la pertinencia y la completitud. Estas dimensiones evitan confundir una respuesta fiel pero incompleta con otra detallada que contiene afirmaciones sin respaldo.

En el fine-tuning, mida la tarea prevista: clasificación correcta, campos exactos, respeto de las excepciones o calidad de redacción según una rúbrica. Compruebe también los comportamientos que no pretendía modificar.

Compare, sobre el mismo conjunto independiente, el modelo de partida, RAG por sí solo, el modelo personalizado y, si hace falta, su combinación. Mantenga condiciones comparables y registre los cambios de configuración.

Incluya documentos contradictorios, entradas mal formadas y solicitudes fuera del alcance previsto. Una buena evaluación también comprueba la abstención: responder siempre no es un objetivo de calidad.

Por último, mida la latencia y el costo por solicitud resuelta según sus criterios. Un sistema más barato por llamada puede acabar costando más si obliga a repetirla. La guía para evaluar un agente de IA explica cómo construir un conjunto de pruebas y hacer un seguimiento de las regresiones.

Confidencialidad, mantenimiento y decisión final

En un RAG, aplique los permisos antes de enviar los fragmentos al modelo. Un filtro en la interfaz no basta si la búsqueda puede recuperar documentos de otro usuario. Los índices, las cachés y los registros también forman parte de los elementos que deben protegerse.

Los textos recuperados siguen siendo datos, aunque contengan instrucciones. Delimite su función e impida que una instrucción encontrada en un documento modifique los permisos de la aplicación. El entrenamiento no debe considerarse una protección suficiente frente a esta manipulación.

En el fine-tuning, examine qué datos podrían memorizarse, quién podrá consultar el modelo y cuál será el procedimiento para sustituirlo. Evite entrenarlo con secretos o con información cuyo acceso dependa del usuario.

Prevea la posibilidad de volver a la configuración anterior con cada modificación. Mantenga versiones del corpus, el índice, las instrucciones y el modelo adaptado para poder explicar una regresión. Una mejora aparente resulta difícil de verificar si se modifican varios componentes a la vez.

Puntos clave

Empiece por diagnosticar los errores con una solución sencilla y una prueba independiente.
Elija RAG para consultar información que pueda actualizarse y verificarse.
Evalúe el fine-tuning para un comportamiento especializado definido mediante ejemplos coherentes.
Combine ambos enfoques solo si la mejora medida justifica su mantenimiento.
Presupueste la preparación, el funcionamiento y los errores, y compare después el costo por solicitud resuelta correctamente.

Páginas relacionadas

Preguntas frecuentes

¿Se puede usar RAG sin una base de datos vectorial?

Sí. Una búsqueda por palabras clave, una consulta a una base de datos relacional o una combinación de métodos puede seleccionar la información que se envía al modelo. La base vectorial es una herramienta de búsqueda, no un requisito para que un sistema se considere RAG.

¿Cuántos ejemplos se necesitan para hacer fine-tuning?

No existe una cantidad universal que garantice resultados. El volumen útil depende de la diversidad de las entradas, la dificultad de la tarea y el modelo elegido. Prepare conjuntos de ejemplos cada vez más amplios y compruebe si el rendimiento sigue mejorando en casos independientes.

¿El fine-tuning elimina las alucinaciones?

No. Puede mejorar un comportamiento concreto, pero también reproducir los errores y sesgos de los ejemplos de entrenamiento. Una respuesta mejor redactada puede seguir siendo incorrecta en los hechos.

¿Se puede borrar información aprendida mediante fine-tuning?

Eliminar esa información del archivo de entrenamiento no modifica el modelo que ya se ha generado. Debe prever un procedimiento de sustitución o reentrenamiento y comprobar su resultado. No trate los pesos del modelo como una base documental en la que cada dato pueda borrarse por separado.

¿Es necesario elegir un modelo de pesos abiertos para hacer fine-tuning?

No necesariamente: algunas API ofrecen personalización alojada para modelos compatibles. Disponer de los pesos permite un mayor control del entrenamiento y el despliegue, dentro de lo que autorice la licencia. Compare también el mantenimiento, los recursos de cómputo y las posibilidades de migración.

Fine-tuning o RAG: cómo elegir, costos, datos necesarios y ejemplos