«¿Y no sería mejor entrenar el modelo con nuestros datos?» La pregunta aparece en cuanto alguien técnico entra en la conversación, y la intuición tiene sentido: si el modelo aprende cómo funciona el producto, responderá mejor.
Para soporte, casi nunca compensa, y el coste es solo uno de los motivos.
¿En qué se diferencian RAG y fine-tuning?
Con RAG, el modelo busca en tu documentación cada vez que responde, así que la respuesta cambia cuando cambia el artículo y sabes de dónde salió. Con fine-tuning, ajustas el modelo con ejemplos y aprende a sonar como tú, pero no a saberse tus datos. Para soporte, casi siempre RAG; el fine-tuning solo tiene sentido para la forma, el vocabulario o el coste. Y ninguno de los dos responde «¿cuánto cupo me queda?»: para eso el sistema tiene que consultar tu API.
Qué hace cada uno
El fine-tuning modifica el modelo. Le das ejemplos y ajustas sus pesos para que responda de una manera determinada. El conocimiento queda dentro del modelo, congelado en el momento del entrenamiento.
RAG (generación aumentada por recuperación) no toca el modelo. Cuando llega una pregunta, busca los fragmentos relevantes de tu documentación con embeddings, que representan el significado de un texto para buscar por parecido, y se los pasa al modelo junto con la pregunta para que redacte con ellos. El conocimiento se queda fuera, en tus documentos.
Que el conocimiento esté dentro o fuera del modelo lo decide todo lo demás.
Por qué en 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 ese mismo día. Con fine-tuning, corriges el artículo y el modelo sigue diciendo lo de antes hasta que vuelvas a entrenarlo.
Un sistema de soporte que responde con el producto de hace dos meses es peor que no tener nada, porque el cliente hace lo que le dices.
Sabes de dónde sale cada respuesta
Con RAG sabes exactamente qué fragmentos se usaron. Cuando algo sale mal, que saldrá, miras qué se recuperó y lo arreglas; casi siempre es un artículo ambiguo o dos que se contradicen. Con fine-tuning, una respuesta incorrecta es un peso mal ajustado en algún sitio, y lo único que puedes hacer es reentrenar y esperar.
En soporte, poder seguir el rastro de una respuesta es lo que te permite mejorar el sistema en vez de cruzar los dedos. Y te permite enseñarle a un cliente de dónde salió lo que se le dijo.
El fine-tuning enseña a sonar como tú
Aquí está el malentendido. Ajustar un modelo con tus conversaciones le enseña tu tono, tu estructura y tu manera de cerrar. Pero no le enseña de forma fiable que el plan Pro incluye cinco asientos, y mucho menos cuántos le quedan a este cliente.
Si quieres que sepa datos, usa RAG. Si quieres que suene de cierta manera, suele bastar con un buen prompt de sistema, que no cuesta nada.
Ninguno de los dos sabe el dato de la cuenta
Esto 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 pieza, la llamada a herramientas: que el sistema consulte tu API antes de responder y pueda hacer cambios cuando la respuesta lo pida. En un SaaS, ese tipo de pregunta suele ser la mitad de las conversaciones, así que discutir entre RAG y fine-tuning sin resolver esto es optimizar la mitad pequeña. Es lo que distingue un chatbot de un agente.
Cuándo sí tiene sentido el fine-tuning
Aun así, el fine-tuning tiene sus usos:
- Un formato de salida muy estricto que el modelo no respeta con instrucciones: un JSON con campos fijos, una plantilla con secciones obligatorias.
- Un vocabulario muy particular que el modelo no maneja bien: la jerga de un sector cerrado o términos médicos o legales en un idioma con poca presencia.
- Bajar el coste por token con un volumen enorme, cambiando un modelo grande por uno pequeño ajustado que hace lo mismo en ese caso concreto.
- Clasificar, que es un problema distinto de responder y en el que un modelo pequeño ajustado funciona muy bien: etiquetar el motivo de un ticket, detectar urgencias, repartir entre equipos.
Ninguno de los cuatro consiste en que sepa cosas de tu producto.
Lo que hay que cuidar en RAG
RAG no funciona solo. Tres cosas deciden si responde bien:
Cómo se parte la documentación. Los fragmentos demasiado grandes traen ruido y los demasiado pequeños pierden el sentido. Un artículo que responde a una sola pregunta se parte bien; uno que explica cuatro cosas, no. Está en preparar la documentación para un agente de IA.
Qué pasa cuando no encuentra nada parecido. Si el sistema recupera lo más cercano aunque no tenga que ver y redacta con ello, tienes una alucinación con fuentes. La regla debe ser: si lo recuperado no responde a la pregunta, decir «no lo sé» y pasar a una persona.
Cómo se evalúa. Un conjunto de preguntas reales con su respuesta correcta y una evaluación cada vez que cambia la documentación o el modelo. Si no, no sabes si la última actualización mejoró o empeoró las cosas.
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 |
| Coste por respuesta | Algo más de tokens (los fragmentos) | Algo menos, si el modelo es pequeño |
| Cambiar de modelo cuando salga uno mejor | Inmediato | Reentrenar |
| 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 qué se puede leer y qué se puede ejecutar. Cubren las preguntas que dependen de la cuenta.
- Un buen prompt para el tono y los límites. Es gratis y llega más lejos de lo que parece.
- Fine-tuning, solo si después de todo 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. Así está montado el agente de Intake: RAG sobre tu centro de ayuda, herramientas contra tu API y un modelo de terceros sin ajustar, que cambiamos cuando sale uno mejor sin que tengas que hacer nada.
Preguntas frecuentes
¿Qué es RAG en pocas palabras?
Buscar en tus documentos los fragmentos que responden a la pregunta y dárselos al modelo para que redacte con ellos. El modelo no aprende nada: lee cada vez.
¿El fine-tuning hace que el modelo se equivoque menos?
En la forma, sí; en los datos, no. Un modelo ajustado con tus conversaciones sonará como tú y seguirá sin saber cuántos asientos le quedan a este cliente.
¿Se pueden combinar?
Sí: un modelo pequeño ajustado para clasificar o para un formato, y RAG con herramientas para responder. Pocas veces lo necesita un SaaS de tamaño medio.
¿Cuánto cuesta montar RAG?
Unas horas, si la documentación está en orden; si no, lo que cueste ordenarla. Las herramientas de soporte con IA ya lo traen hecho: conectas el centro de ayuda y listo.
¿Y si tengo mucha documentación técnica?
Mejor para RAG, siempre que esté partida en artículos que respondan a una sola cosa. Para una API con una referencia extensa, lo que funciona es RAG sobre la referencia más herramientas que consulten la cuenta; hay ejemplos en soporte con IA para herramientas de desarrollo.
Para seguir
- MCP en atención al cliente
- 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
- Tu propio chatbot de soporte con la API de OpenAI o de Claude
