RAG, fine-tuning o prompts: cuál conviene para un LLM en producción

Hay tres maneras de adaptar un modelo de lenguaje al trabajo de una empresa: escribirle mejores instrucciones, darle los documentos de la casa en el momento de la consulta o reentrenarlo con datos propios. Casi todos los proyectos que revisamos empiezan por la opción más cara. El orden en que se prueban pesa más que la técnica elegida, y ese orden es siempre el mismo.

Las instrucciones resuelven más casos de los que parece

El prompt es el conjunto de instrucciones, ejemplos y formato de salida que recibe el modelo con cada petición. Cuesta horas, se cambia sin desplegar nada y se prueba en una tarde. Por eso es el primer paso, aunque a los equipos técnicos les parezca poco ambicioso.

En la práctica, un prompt bien construido fija el rol, describe la tarea con un ejemplo real, define los campos que se esperan y obliga a devolver un JSON estricto. Con eso quedan cubiertas tareas de clasificación, extracción de campos de un tipo de documento y redacción de respuestas a partir de una plantilla. Lo que no puede hacer es aportar información que el modelo no tiene: el catálogo de la empresa, la política de devoluciones vigente, el historial de un cliente.

El límite aparece cuando el prompt crece hasta convertirse en un manual. Si cada caso raro añade un párrafo, se vuelve imposible de mantener y cambia de comportamiento con cada versión del modelo. Esa es la señal para pasar a la recuperación de documentos.

RAG da al modelo los datos de la empresa sin reentrenarlo

RAG (generación aumentada por recuperación) consiste en buscar, para cada pregunta, los fragmentos de documentación interna que la responden y pasárselos al modelo como contexto. Los documentos siguen donde ya estaban (SharePoint, el ERP, una base de datos, un buzón lleno de PDF); se indexan y se consultan en el momento. El modelo redacta a partir de lo recuperado y puede citar de dónde sale cada dato.

Lo que cambia respecto al prompt es la frescura y la trazabilidad. Si el precio de un producto se actualiza hoy en Business Central, la respuesta de mañana lo refleja. Si una respuesta es incorrecta, se ve qué fragmento la provocó. Ninguna de las dos cosas existe con un modelo reentrenado.

El problema es que RAG hereda la calidad de las fuentes. Una wiki con tres versiones del mismo procedimiento produce respuestas con tres versiones, todas escritas con la misma seguridad. Por eso la mayor parte del trabajo de un proyecto RAG está en la capa de datos: decidir qué fuentes entran, quién las mantiene y cómo se trocean e indexan. El modelo (Claude, GPT, Gemini o uno de pesos abiertos dentro de la propia nube en Azure o AWS) es la pieza que menos horas consume.

El fine-tuning cambia el comportamiento, no el conocimiento

Reentrenar un modelo con ejemplos propios ajusta cómo responde: el tono, el formato, la manera de clasificar. Compensa cuando hay miles de ejemplos etiquetados de una tarea estable y las dos técnicas anteriores se han quedado cortas en la evaluación. Un caso típico es una clasificación con decenas de categorías propias del sector donde los prompts largos nunca alcanzan la precisión exigida.

A cambio, el conocimiento queda congelado en la fecha del entrenamiento y cada actualización obliga a repetir el proceso, con su coste de GPU y de preparación de datos. Un modelo reentrenado tampoco cita fuentes. Dicho de otro modo, no es la herramienta para que el modelo "conozca la empresa"; para eso está RAG.

Conviene tratarlo como la última opción. En la mayoría de empresas medianas el conjunto de datos etiquetados no existe, y construirlo cuesta más que el resto del proyecto.

Lo que decide el resultado es la evaluación

Antes de tocar nada hace falta un conjunto de prueba: entre cincuenta y cien peticiones reales con la respuesta que el equipo considera correcta. Con él se mide el punto de partida y cada cambio (un prompt nuevo, otra estrategia de indexación, un modelo distinto) se compara con un número en lugar de con una impresión. Sin ese conjunto, la discusión sobre técnicas es una discusión de opiniones.

Las métricas útiles son pocas: acierto por tipo de petición, proporción de respuestas en las que el modelo reconoce que no tiene datos, latencia y coste por petición. Un sistema que responde bien en la mayoría de casos y se inventa el resto es peor que uno que acierta algo menos y deriva las dudas a una persona.

En producción, el sistema necesita además lo que necesita cualquier software: registro de cada petición y respuesta, gestión de errores y de límites de la API, un modelo de respaldo y una vía para que una persona revise los casos de baja confianza. Ahí se va la mayor parte del presupuesto, y ahí se decide si el proyecto sobrevive al segundo mes.

Por dónde empezar esta semana

• Elegir una sola tarea con volumen y resultado verificable: clasificar correos entrantes, extraer campos de un tipo de documento o redactar la primera respuesta a una consulta.
• Reunir cincuenta casos reales con la respuesta correcta y anotar el acierto actual del proceso manual.
• Probar primero con un prompt sobre la API de un proveedor y medir contra ese conjunto.
• Añadir recuperación solo sobre documentos que alguien mantenga, y dejar por escrito quién.
• Plantear el fine-tuning únicamente si los números de la evaluación lo justifican.

Si el caso encaja, en LakeTab lo revisamos en una primera llamada de 60 minutos.