RAG, fine-tuning o prompting: cómo elegir para un caso empresarial

El problema no es el modelo, es la pregunta que te haces

Cuando una empresa decide aplicar un modelo de lenguaje a su operación, la conversación suele arrancar al revés. Se discute qué modelo usar, cuánta GPU hace falta o si conviene "entrenar la inteligencia artificial con nuestros datos", antes de haber definido qué problema concreto se quiere resolver. Y ahí es donde se quema presupuesto sin necesidad, porque las tres grandes estrategias para adaptar un modelo a tu negocio (prompting, RAG y fine-tuning) no son tres niveles de una misma escalera donde el de arriba es siempre mejor. Son herramientas que resuelven problemas distintos, y elegir la equivocada cuesta caro en dinero y en tiempo.

La buena noticia es que la decisión se puede ordenar con criterios bastante claros. La documentación de OpenAI sobre optimización de precisión lo plantea de una forma que vale la pena adoptar: no pienses en una secuencia lineal, piensa en dos ejes distintos. Por un lado está el conocimiento que el modelo necesita para responderte bien; por otro está el comportamiento, es decir, la forma, el tono y la consistencia con que responde. Casi cualquier fallo que veas en un asistente cae en uno de esos dos cubos, y cada cubo tiene su propia herramienta.

Prompting: el punto de partida que casi todos subestiman

El prompting, o ingeniería de instrucciones, es simplemente redactar con cuidado lo que le pides al modelo: darle contexto, ejemplos del resultado que esperas, el formato de salida, las reglas que debe respetar. No toca el modelo por dentro ni requiere infraestructura nueva. Es la opción más rápida de implementar, se mide en horas o días, y por eso es el lugar correcto para empezar prácticamente siempre.

Aquí hay un sesgo cultural que conviene nombrar. Mucha gente asume que "solo escribir un buen prompt" es una solución de juguete, un parche temporal hasta que llegue lo serio. La realidad es la contraria. La propia guía de OpenAI señala que para tareas como resumir documentos, traducir o generar código, el prompting bien hecho suele ser el único método necesario. Antes de invertir en nada más, el ejercicio de redactar buenas instrucciones te obliga a definir qué significa "una buena respuesta" en tu caso, y eso por sí solo revela si lo que te falta es conocimiento o es comportamiento. Saltarse este paso para irse directo a algo más sofisticado es como contratar un equipo de obra antes de tener los planos.

El prompting tiene un techo, claro. Cuando el modelo necesita saber cosas que no están en su entrenamiento (tu catálogo de productos, tus políticas internas, los precios de esta semana) o cuando por más que ajustes las instrucciones sigue equivocando el formato o el tono, el prompting solo ya no alcanza. Y ahí es donde tienes que decidir hacia cuál de los dos ejes moverte.

RAG: darle al modelo tu conocimiento, fresco y bajo control

RAG, por las siglas en inglés de generación aumentada por recuperación, ataca el problema del conocimiento. La idea es sencilla de entender: en lugar de meter toda tu información dentro del modelo, la dejas en una base de datos consultable, y cada vez que llega una pregunta el sistema primero busca los fragmentos relevantes de tus documentos y se los entrega al modelo como parte del contexto. El modelo entonces responde apoyándose en ese material que acabas de pasarle, no en su memoria general.

Lo importante de RAG es lo que resuelve y cómo lo resuelve. Resuelve el caso, que es el más común en una empresa, de que el modelo necesita acceso a información específica, propietaria y que cambia: documentación interna, manuales, contratos, historial de soporte, normativa vigente. Y lo resuelve sin tocar el modelo, lo que tiene tres consecuencias muy prácticas. La primera es la frescura del dato: si actualizas un documento en tu base, la próxima respuesta ya usa la versión nueva, sin reentrenar nada. Como resume la firma IBM en su comparación entre ambos enfoques, los sistemas RAG integran información actualizada sin necesidad de reentrenamiento, algo esencial en entornos que evolucionan todo el tiempo. La segunda es la trazabilidad: como el modelo responde a partir de fragmentos concretos, puedes mostrar de dónde salió cada afirmación y reducir las invenciones. La tercera es el control de acceso y la privacidad, porque tus datos viven en tu infraestructura y decides quién consulta qué.

RAG no es gratis, eso sí. Lo que en prompting era costo cero pasa a ser costo de operación continuo: necesitas una base de datos vectorial, el procesamiento para indexar tus documentos y la infraestructura de búsqueda, que escala con el volumen de consultas. Las comparaciones de mercado de 2025 y 2026 coinciden en que RAG tiene un costo de arranque bajo pero gastos recurrentes de infraestructura, y que la cuenta final depende sobre todo de cuántas preguntas atiendes. Para la enorme mayoría de casos empresariales sigue siendo más barato y más manejable que la alternativa pesada, que es la siguiente.

Fine-tuning: enseñarle al modelo a comportarse, no a saber

El fine-tuning es entrenar el modelo con tus propios ejemplos para que cambie su comportamiento de forma permanente. Y aquí está el malentendido más caro de toda esta conversación: mucha gente cree que se hace fine-tuning para "meterle conocimiento" al modelo. No es para eso. El fine-tuning brilla cuando el problema es de comportamiento, no de conocimiento. Sirve para fijar un formato de salida muy estricto, para que el modelo adopte el tono y la jerga de tu industria, para que razone de una manera particular en una tarea estrecha, o para bajar la latencia y el costo por consulta cuando ya tienes mucho volumen y un patrón bien definido.

La distinción que recomienda hacer la guía de OpenAI es la regla de oro para decidir. Cuando la causa del fallo son hechos que faltan, la solución directa es recuperación, o sea RAG. Cuando la causa es un comportamiento poco confiable, la solución directa es fine-tuning. Si tu asistente da respuestas correctas pero con el tono equivocado, eso es comportamiento. Si da respuestas con el tono perfecto pero con datos falsos o desactualizados, eso es conocimiento. Tratar un problema de conocimiento con fine-tuning es el error clásico, porque además de ser costoso no lo resuelve: un modelo afinado se entrena sobre datos estáticos y, para incorporar información nueva, hay que volver a entrenarlo, con la demora y el gasto que eso implica cada vez.

Por eso el fine-tuning casi nunca debería ser el primer paso de un proyecto. Tiene los costos de arranque más altos de los tres, exige reunir y curar un buen conjunto de ejemplos, y el costo de inferencia y mantenimiento puede multiplicarse frente a usar un modelo base. Conviene cuando el prompting ya tocó techo, cuando RAG resolvió el conocimiento pero persiste un problema de comportamiento que las instrucciones no logran corregir, o cuando el volumen es tan alto que afinar un modelo más pequeño y especializado sale más barato a la larga que pagar por uno grande en cada llamada.

Por qué la mayoría empieza por prompting más RAG

Si juntas todo lo anterior, el camino sensato para la mayoría de empresas se dibuja solo. Empiezas por prompting porque es inmediato, barato y te obliga a entender tu problema. Cuando el cuello de botella es que el modelo no conoce tu información, agregas RAG, porque encaja con la forma en que tu empresa ya guarda y actualiza su conocimiento, te da frescura, trazabilidad y privacidad, y su costo es de operación y no una apuesta grande por adelantado. Y solo cuando las evaluaciones muestran un problema de comportamiento que ni el prompting ni el contexto logran arreglar, consideras fine-tuning.

Esto no significa que el fine-tuning sea de segunda. Significa que es una herramienta de precisión que se usa cuando ya sabes exactamente qué estás corrigiendo. De hecho, los enfoques más maduros en producción suelen ser híbridos: se afina un modelo para que razone y responda con el estilo de tu dominio, y se le da conocimiento actual y gobernable por medio de RAG. El ejemplo que circula en la documentación de proveedores y guías técnicas lo ilustra bien: afinar un modelo para que razone como un profesional de un campo, y conectarlo por RAG a las guías y normativas vigentes de ese campo. Comportamiento estable por un lado, conocimiento fresco por el otro. Las dos piezas se complementan precisamente porque atacan ejes distintos.

La trampa que conviene evitar es invertir el orden por entusiasmo o por moda, lanzarse a entrenar un modelo propio antes de haber agotado opciones que cuestan una fracción y muchas veces bastan. La pregunta que ordena toda la decisión sigue siendo la misma del principio: ¿lo que le falta a mi asistente es saber algo, o es comportarse de cierta manera? Respóndela con honestidad sobre casos reales de tu operación y el resto casi se deduce.

En sof-IA diseñamos esta arquitectura a la medida de cada caso: partimos del problema concreto de tu empresa, medimos dónde fallan de verdad las respuestas y armamos la combinación de prompting, RAG y, cuando aporta, fine-tuning que resuelve sin inflar el presupuesto. Si estás evaluando llevar un modelo de lenguaje a tu operación y no quieres pagar de más por la herramienta equivocada, conversemos.