RAG o fine-tuning de LLM para chatbots internos de empresa

01/10/2026

Un cliente me dijo una vez: “Nomás métanle todos los documentos de la empresa al modelo y listo”. Suena sencillo, y entiendo por qué lo pensó. Pero la forma de “meter” esos documentos, con RAG o con fine-tuning de un LLM, da como resultado dos sistemas muy distintos en costo, confiabilidad y mantenimiento. Este artículo cuenta cómo pensamos esa decisión cuando construimos chatbots internos para empresas vietnamitas.

Dos enfoques, dos trabajos distintos

RAG (retrieval-augmented generation) funciona así: cuando un usuario pregunta algo, el sistema busca algunos fragmentos relevantes en su repositorio de documentos, se los entrega al modelo junto con la pregunta, y el modelo responde con base en lo que acaba de leer. El modelo no aprende nada nuevo. Solo recibe material de consulta, como un empleado que abre el manual antes de contestar.

El fine-tuning es distinto. Se sigue entrenando el modelo con sus propios datos, y el cambio realmente queda en los pesos. Lo que el modelo suele aprender es estilo, formato, terminología y formas de razonar dentro de un área. No es una buena manera de meterle mil páginas de políticas de recursos humanos, porque el conocimiento absorbido así se recuerda mal o a medias con facilidad.

Una imagen que uso mucho: RAG es darle al empleado acceso a una biblioteca. El fine-tuning es mandarlo a un curso de capacitación en su oficio. La biblioteca le ayuda a consultar el dato correcto. El curso le ayuda a hablar y trabajar como se hace en esa profesión.

Cuándo conviene empezar con RAG

Si el chatbot responde sobre todo preguntas a partir de documentos existentes, como procedimientos, políticas y guías de producto, empiecen con RAG. Las razones son prácticas:

• Cuando un documento cambia, solo actualizan el repositorio en lugar de reentrenar.
• Se pueden citar las fuentes, así que los usuarios verifican de dónde salió una respuesta.
• El control de acceso es más sencillo: contabilidad solo ve los documentos de contabilidad.
• El costo de arranque es mucho menor.

Pero RAG no es la solución a todo. Lo más difícil casi nunca es el modelo sino los datos. He visto equipos pasar semanas solo lidiando con PDF escaneados borrosos, tablas rotas y documentos que existen en tres versiones contradictorias. Si la búsqueda trae el fragmento equivocado, el modelo responderá mal con toda seguridad, y a los usuarios les costará darse cuenta. En vietnamita, además, la segmentación del texto y la búsqueda semántica se ven afectadas por los diacríticos, las palabras compuestas y la escritura sin acentos que es común en los mensajes internos.

Cuándo sí vale la pena el fine-tuning

El fine-tuning empieza a rendir cuando el problema está en cómo responde el modelo y no solo en qué sabe. Algunas situaciones típicas:

• El modelo interpreta mal una y otra vez los términos del área, por ejemplo nombres de medicamentos, principios activos y abreviaturas de expedientes clínicos.
• La salida debe seguir un formato fijo, como formularios, esquemas de codificación o reportes con plantilla.
• El tono debe mantenerse acorde con la marca o con un estándar interno.
• Se busca un modelo más pequeño y barato que sea suficientemente bueno para una tarea muy específica.

El precio del fine-tuning es que se necesitan datos limpios, ejemplos etiquetados o de buena calidad, y una forma adecuada de evaluar. Datos malos dan un modelo malo, y el fine-tuning incluso puede desgastar parte de la capacidad general. No es raro. Por eso siempre queremos ver datos reales y un conjunto de preguntas de prueba antes de prometer cualquier cosa.

Cómo combinar ambos en la práctica

La mayoría de los buenos chatbots internos que conozco usan los dos, en un orden que tiene sentido. Primero se arma el RAG, se prueba unas semanas con empleados reales y se registran las respuestas incorrectas. Luego se clasifican los errores:

• Errores por recuperar el documento equivocado o por documentos faltantes: se corrigen en la capa de RAG y en los datos.
• Errores porque el modelo interpreta mal los términos, usa el formato equivocado o suena desentonado: son candidatos para fine-tuning.

Así se evita la trampa más cara: hacer fine-tuning demasiado pronto para parchar un problema que en realidad venía del repositorio de documentos. Una vez vi a un equipo hacer fine-tuning dos veces seguidas antes de descubrir que la política vieja seguía en el repositorio.

Un ejemplo de hospitales y farmacia

Imaginen un chatbot que ayuda a los farmacéuticos a consultar las guías internas de uso de medicamentos. Las guías cambian con cada actualización, así que RAG se encarga de la consulta y de citar la fuente. Pero los nombres genéricos, los nombres comerciales, las abreviaturas de cada servicio y la forma en que los farmacéuticos formulan sus preguntas son muy distintos de un texto común. Ahí el fine-tuning ayuda a que el modelo interprete bien la pregunta desde el inicio. Los dos se complementan, no compiten.

AIVISION es una empresa de IA en Vietnam que hace entrenamiento y fine-tuning de LLM para el vietnamita y para áreas específicas como salud y farmacéutica, en un clúster de 24x NVIDIA H200 y 8x NVIDIA B300. Hemos lanzado el LLM L1.0 y el modelo de reconocimiento de voz (speech to text) E1.0 para vietnamita. Cuando asesoramos, normalmente sugerimos a los clientes empezar por las partes baratas y reversibles. Hay más información sobre nuestra dirección en AIVISION.

Errores comunes

• Evaluar “a ojo”. Reúnan de decenas a unos cientos de preguntas reales de los empleados con respuestas de referencia, y vuelvan a correrlas después de cada cambio.
• Olvidar los permisos. Un chatbot interno donde cualquiera puede pedir la tabla de nómina es un incidente esperando a ocurrir.
• Tratar el chatbot como un proyecto de una sola vez. Los documentos cambian, los usuarios cambian la forma de preguntar, y el sistema necesita a alguien que lo atienda.
• Ignorar la respuesta “no lo sé”. Un chatbot que se atreve a decir que no encontró nada siempre es más confiable que uno que siempre tiene respuesta.

Si tuviera que dar un solo consejo corto: armen primero el RAG, midan los errores reales y luego decidan qué partes llevar a fine-tuning. El orden no es vistoso, pero ahorra dinero y evita semanas de trabajo innecesario.