«¿Y no sería mejor entrenar el modelo con nuestros datos?» Es la pregunta que aparece en cuanto alguien técnico entra en la conversación, y la intuición detrás es razonable: si el modelo aprende cómo funciona nuestro producto, responderá mejor.
Para soporte, casi siempre la respuesta es que no. Y el motivo no es el coste, aunque también.
Qué hace cada uno
Fine-tuning modifica el modelo. Le das ejemplos y ajustas sus pesos para que responda de una determinada manera. El conocimiento queda dentro del modelo, congelado en el momento del entrenamiento.
[RAG](/es/glosario/rag) deja el modelo intacto. Cuando llega una pregunta, busca los fragmentos relevantes en tu documentación y se los pasa junto con la pregunta para que redacte con ellos. El conocimiento se queda fuera, en tus documentos.
Esa diferencia —dentro o fuera— decide todo lo demás.
Por qué para soporte gana RAG
El contenido cambia y el modelo no
Tu producto cambia cada semana. Con RAG, corriges un artículo y la respuesta cambia hoy. Con fine-tuning, corriges un artículo y el modelo sigue diciendo lo de antes hasta que vuelvas a entrenar.
Un sistema de soporte que responde con la versión del producto de hace dos meses es peor que no tener sistema, porque el cliente actúa según lo que le dices.
Puedes saber de dónde salió una respuesta
Con RAG sabes exactamente qué fragmentos se usaron. Cuando algo sale mal —y va a salir mal— puedes mirar qué se recuperó y arreglarlo. Con fine-tuning, una respuesta incorrecta es un peso ajustado en algún sitio, y lo único que puedes hacer es reentrenar y esperar.
En soporte esa trazabilidad no es un lujo: es lo que permite mejorar el sistema en vez de rezarle.
El fine-tuning no enseña datos, enseña forma
Es el malentendido central. Ajustar un modelo con tus conversaciones le enseña a sonar como tú: tu tono, tu estructura, tu manera de cerrar. No le enseña de forma fiable que el plan Pro incluye cinco asientos, y desde luego no le enseña cuántos le quedan a este cliente.
Si lo que quieres es que sepa datos, RAG. Si lo que quieres es que suene de cierta manera, un buen prompt suele bastar y cuesta cero.
Ninguno de los dos resuelve el dato de la cuenta
Y esta es la parte que casi nunca se dice. Ni RAG ni fine-tuning responden a «¿cuánto cupo me queda?», porque esa respuesta no está en ningún documento ni en ningún peso: está en tu base de datos, y cambia cada minuto.
Para eso hace falta una tercera cosa, que es llamar a herramientas: que el sistema consulte tu API antes de responder. En un SaaS ese grupo suele ser la mitad de las conversaciones, así que discutir entre RAG y fine-tuning sin resolver esto es optimizar la mitad pequeña.
Cuándo sí tiene sentido el fine-tuning
Que la respuesta general sea RAG no lo convierte en inútil.
- Un formato de salida muy estricto que el modelo no respeta con instrucciones.
- Un vocabulario muy particular —jerga de un sector cerrado— que el modelo no maneja bien.
- Reducir coste por token en un volumen enorme, sustituyendo un modelo grande por uno pequeño ajustado.
- Clasificar, que es un problema distinto de responder y donde un modelo pequeño ajustado va muy bien.
Ninguno de esos cuatro es «que sepa cosas de mi producto».
La cuenta
| Criterio | RAG | Fine-tuning |
|---|---|---|
| Montaje | Horas | Días o semanas |
| Actualizar contenido | Editar el artículo | Reentrenar |
| Saber de dónde vino una respuesta | Sí | No |
| Coste de arranque | Bajo | Medio o alto |
| Responde con el dato de la cuenta | No | No |
La última fila es la importante: las dos columnas dicen que no.
Qué montar, en orden
- RAG sobre tu documentación. Cubre las preguntas cuya respuesta es igual para todos.
- Herramientas contra tu API, decidiendo con criterio qué se puede leer y qué se puede ejecutar. Cubre las que dependen de la cuenta.
- Un buen prompt para el tono. Es gratis y llega más lejos de lo que la gente cree.
- Fine-tuning, solo si después de lo anterior queda un problema concreto de forma o de coste.
La mayoría de los equipos se quedan en el paso 2 y hacen bien.
Para seguir
- Qué es RAG, en el glosario
- Qué es un agente de soporte con IA
- Alucinación, que es lo que ninguna de las dos técnicas elimina del todo
