RAG cambia qué información puede consultar el modelo; fine-tuning cambia cómo se comporta. Si el problema es conocimiento privado, cambiante o que debe citarse, empieza por contexto o RAG. Si el modelo ya tiene la información pero falla de forma repetible en una tarea, puede tener sentido evaluar ajuste. Y si el dato vive en un sistema de negocio, quizá la respuesta correcta sea una tool/API, no ninguna de las dos.
“El modelo no sabe esto” puede significar varias cosas: le falta un dato actual, recuperó la fuente equivocada, el contexto está mal construido o conoce la información pero ejecuta mal una tarea. Cada fallo pide una intervención distinta.
Retrieval-Augmented Generation recupera información relevante en tiempo de consulta y la añade al contexto. Permite actualizar fuentes sin reentrenar, aplicar permisos y mostrar procedencia.
Eso no elimina errores. Si el corpus está obsoleto, el chunking es malo o el buscador recupera la política incorrecta, el modelo puede responder de forma convincente con mala evidencia.
El fine-tuning ajusta un modelo para una tarea o patrón de salida mediante ejemplos. Puede aportar en clasificación, formatos, estilo o comportamiento repetible cuando existe un dataset bueno y una métrica clara.
No es la forma natural de “memorizar” una tarifa que cambia cada semana ni de gestionar permisos documentales por usuario.
Si los datos necesarios son pocos y conocidos, pueden ensamblarse directamente en el contexto sin montar un RAG completo. Si precio, stock, estado o identidad viven en CRM/ERP, una llamada a una herramienta puede consultar la fuente autoritativa en tiempo real.
La pregunta correcta no es RAG o fine-tuning, sino qué mecanismo entrega al sistema la información y el comportamiento correctos con la menor complejidad.
| Problema | Primera opción a evaluar | Por qué |
|---|---|---|
| Documentación cambia y debe citarse | RAG | Actualización y procedencia sin reentrenar. |
| Dato vivo en CRM/ERP | Tool/API | Consulta la fuente de verdad en el momento. |
| Pocos datos estructurados | Contexto | Evita infraestructura de retrieval innecesaria. |
| Tarea repetible con muchos ejemplos | Fine-tuning | Puede especializar comportamiento. |
| Conocimiento fresco + conducta específica | Combinación | Las técnicas resuelven capas diferentes. |
Primero mide retrieval: ¿recupera la evidencia correcta dentro de los primeros resultados? Después mide generation: ¿la respuesta usa esa evidencia sin inventar ni contradecirla?
Microsoft insiste en la preparación y recuperación como determinantes de calidad y advierte que el grounding no impide por sí solo las alucinaciones.
Microsoft · RAG y fine-tuning.
Separa entrenamiento, validación y test. Compara el modelo ajustado contra la baseline con el mismo conjunto que no haya servido para entrenar. Si no mejora una métrica que importa —y además introduce coste o dependencia—, el ajuste no está justificado.
Dataset y procedimiento de evaluación se convierten en activos que deben versionarse igual que el código.
En RAG, una fuente cambia y se sincroniza o reindexa. En fine-tuning, una nueva versión exige dataset, entrenamiento, evaluación y rollout. Esa diferencia pesa mucho cuando el conocimiento cambia con frecuencia.
Por eso es peligroso entrenar hechos que deberían seguir viviendo en un sistema de negocio o repositorio.
Con RAG bien diseñado, la identidad del usuario puede filtrar qué documentos se recuperan antes de que lleguen al modelo. También puede mostrarse la fuente. Fine-tuning no aporta por sí solo ACL documentales ni una cita factual.
Eso no hace RAG automáticamente privado o seguro: proveedor, índices, logs y permisos siguen formando parte de la arquitectura.
Un índice no convierte documentación contradictoria en conocimiento. Antes de optimizar embeddings, define qué fuente manda, cómo se versiona, qué documentos están vigentes y quién mantiene el corpus.
Muchas “alucinaciones de RAG” empiezan siendo problemas de contenido, permisos o recuperación que la capa generativa sólo hace visibles.
Conocimiento cambiante: contexto/RAG. Dato transaccional vivo: tool/API. Comportamiento repetible: prompt/evals y, si hace falta, fine-tuning. Varias necesidades: combinación.
La técnica correcta es la que corrige el fallo observado y se puede mantener; no la que suena más propietaria.
Respuestas directas para convertir la pregunta en una decisión de proyecto.
RAG aporta información externa en tiempo de consulta; fine-tuning ajusta el comportamiento del modelo mediante ejemplos.
RAG suele ser el primer enfoque porque permite actualizar fuentes, conservar procedencia y aplicar permisos sin reentrenar por cada cambio.
Cuando el dato es transaccional y vive en un sistema de verdad —precio, stock, estado, saldo—, una tool o API suele ser más apropiada.
No. Puede fallar la recuperación o la interpretación. Hay que evaluar retrieval, generation, citas y abstención.
Cuando existe una tarea repetible, un dataset de calidad y una métrica que muestra que la baseline no alcanza el comportamiento necesario.
Sí. Un modelo especializado puede seguir recuperando conocimiento fresco mediante RAG.
Separamos conocimiento, dato vivo y comportamiento para elegir la intervención mínima y una arquitectura que se pueda mantener.