RAG o ajuste fino: cómo decidir en un sistema LLM de empresa

TankDev ha publicado un marco de decisión para elegir entre recuperación aumentada (RAG) y ajuste fino en despliegues de LLM dentro de una empresa. Su tesis de partida es que plantearlos como dos respuestas a la misma pregunta es un error: RAG cambia qué conocimiento está disponible en el momento de responder y el ajuste fino cambia cómo se comporta el modelo ante una tarea. Un sistema en producción decide dónde colocar reglas deterministas, recuperación, ajuste fino y revisión humana.

Conocimiento, comportamiento o regla

El primer paso es clasificar el problema antes de tocar el modelo. Si la pregunta es por la política de devoluciones vigente de un cliente concreto, el asunto es de conocimiento y la evidencia válida es la revisión del documento en vigor: eso es RAG. Si lo que falla es la forma de la respuesta —clasificar un correo en seis categorías y devolver únicamente JSON válido—, el problema es de comportamiento y contrato de salida, y ahí el ajuste fino tiene sentido. Y si la norma es que por encima de 5.000 TRY de reembolso hace falta una segunda aprobación, eso va en SQL, en un flujo de trabajo o en un servicio de reglas, no en un LLM.

Sobre RAG, el texto insiste en algo que se suele pasar por alto: una base de datos vectorial es un componente, no la definición del sistema. Una ruta de recuperación en producción adquiere fuentes, conserva revisión, fecha de vigencia, ámbito de producto, idioma y control de acceso, recupera candidatos, los reordena y genera una respuesta con cita. El filtrado por actor tiene que ocurrir durante la recuperación: añadir una instrucción de "no reveles información privada" al prompt no es control de acceso. Si la recuperación no devuelve evidencia suficiente, el sistema debe declararlo en vez de fabricar una respuesta plausible.

El ajuste fino mueve un modelo base hacia ejemplos de entrada y salida para una tarea concreta: etiquetas de clasificación, formato estructurado, lenguaje del dominio, estilo conciso o selección de herramientas. Lo que no hace es convertirse en un almacén de documentos fiable. Cuando cambia un precio o una política, no hay manera de identificar todas las respuestas afectadas, y un dato memorizado no es citable, ni actual, ni está sujeto a permisos. La referencia de ajuste fino de OpenAI documenta el flujo con datos de entrenamiento en JSONL, y el conjunto de validación y el de prueba deben mantenerse separados: ningún cliente, plantilla o familia de documentos puede filtrarse entre particiones.

Cómo se mide

El marco pone un ejemplo: un asistente de soporte B2B que recupera la cláusula contractual vigente, clasifica texto libre en seis categorías y deja que un servicio determinista valide cliente, pedido, ventana temporal y autorización antes de crear una devolución. Para la clasificación, propone comparar un prompt base contra 600 ejemplos etiquetados sobre un conjunto de prueba reservado.

La evaluación de RAG necesita dos capas distintas: si la recuperación trajo la evidencia correcta y si la generación respondió usando solo esa evidencia. Un documento equivocado se puede resumir con total fluidez y uno correcto puede sostener la cláusula que no toca. Las señales que enumeran son la recuperación en los primeros k resultados, la precisión de las citas, la corrección anclada en la evidencia y la capacidad de abstenerse cuando no hay respaldo. La guía de RAG de Google Cloud cubre buena parte de ese recorrido.

Lo que importa de todo esto es económico: entrenar es caro y lento, y hacerlo por reflejo cuando el fallo estaba en la recuperación, los filtros o la calidad de las fuentes es tirar el presupuesto. Si la evidencia llega bien pero el formato o el lenguaje del dominio siguen siendo inconsistentes, entonces sí hay una hipótesis que merece un experimento de ajuste fino.