RAG, ajuste fino o agentes: elegir la capa adecuada y el orden para construirla
RAG frente a ajuste fino frente a agentes de IA: qué hace cada uno, costo, latencia y modos de fallo, reglas prácticas, y un asistente de recursos humanos que muestra el orden para desarrollarlos.
Fuentes: RAG vs Fine-Tuning vs AI Agents: When to Use What in Real-World AI Systems
En casi todos los proyectos de LLM surgen, tarde o temprano, dos preguntas. Una es si recuperar documentos o ajustar el modelo. La otra es si el producto necesita un agente o simplemente un prompt más inteligente. Sorprendentemente, con frecuencia se dan respuestas deficientes a ambas, y no solo por parte de los principiantes. Ingenieros experimentados han pasado semanas ajustando un modelo para que memorice hechos que una consulta de recuperación habría proporcionado en una tarde. Otros equipos han incorporado un marco de trabajo de agentes a lo que en realidad era un endpoint de respuesta a preguntas, simplemente porque los agentes eran el tema en cada reunión diaria de ese trimestre.
La realidad menos emocionante es que la recuperación de información, el ajuste fino y los agentes no son competidores para el mismo trabajo. Cada uno resuelve un problema distinto, y los sistemas que se utilizan con usuarios reales suelen combinar dos de ellos o los tres, de modo que cada componente haga lo que mejor sabe hacer. A continuación se explica cómo funciona cada uno en profundidad, cuál es su costo, cómo los equipos los utilizan indebidamente, cómo se integran los componentes y un pequeño proyecto que muestra el orden para desarrollarlos.
Qué hace realmente cada uno
Generación mejorada por recuperación de información
La recuperación de información no afecta al modelo. Solo modifica lo que el modelo lee antes de responder.
Cuando llega una pregunta, el sistema la convierte en un embedding, una representación numérica de su significado, y busca en una base de datos vectorial como Pinecone, Qdrant, FAISS o Azure AI Search los fragmentos almacenados que tengan un significado más similar. Esos fragmentos se incluyen en el prompt como contexto, y el modelo responde a partir de ese material en lugar de de lo que absorbió durante el preentrenamiento.
El valor radica en los fallos que previene. Los modelos inventan detalles con mayor facilidad cuando se ven obligados a responder a partir de su memoria interna, especialmente en temas recientes, poco conocidos o específicos de una empresa. Proporcionar al modelo texto de referencia en cada llamada significa que razona sobre el material actual y no adivina.
El pipeline tiene una estructura fija: ingiere documentos, los divide en fragmentos, incrusta esos fragmentos, almacena los vectores, realiza una búsqueda de similitud (a menudo combinada con una búsqueda por palabras clave), opcionalmente vuelve a clasificar los candidatos, reúne el prompt y genera el resultado.
Afinamiento
El afinamiento difiere en naturaleza, no solo en grado. Un modelo preentrenado continúa entrenándose con un conjunto seleccionado de ejemplos propios, generalmente pares de entrada y salida deseada que demuestran el comportamiento exacto que se desea. Los pesos cambian, o en el caso de LoRA y QLoRA, cambia un pequeño conjunto de pesos de adaptador sobre una base congelada.
Funciona bien para enseñar modales: un tono de voz, un formato de salida rígido, una forma específica de abordar un tipo de problema, o el manejo de casos límite en un campo donde existen miles de ejemplos etiquetados. El objetivo es remodelar el comportamiento por defecto para que no sea necesario repetir las mismas instrucciones en cada solicitud, en lugar de añadir datos nuevos.
Funciona mal para cualquier cosa que cambie constantemente. Un catálogo de productos que se actualiza semanalmente no puede almacenarse de manera adecuada en los pesos, ya que el conocimiento se congela al final del entrenamiento y cada actualización implica ejecutar el proceso nuevamente.
Agentes
Un agente coloca el modelo dentro de un bucle: observar, razonar, actuar, observar el resultado, razonar de nuevo y continuar hasta que se alcanza un objetivo o se activa una regla de detención. El modelo ya no produce una sola respuesta; decide qué hacer a continuación, frecuentemente mediante el uso de herramientas como APIs, funciones, bases de datos y otros servicios, e incorpora sus resultados en su siguiente decisión.
Ese bucle es lo que convierte a un sistema que responde preguntas en uno que completa tareas. LangGraph, CrewAI y un bucle ReAct escrito a mano implementan todas una versión de él: el modelo escribe un pensamiento, selecciona una herramienta, la herramienta se ejecuta, el resultado vuelve al contexto y el ciclo se repite hasta que el agente considera que ha terminado o alcanza un límite de pasos. Siempre se debe establecer un límite de pasos.
Una forma concisa de diferenciarlos:
- La recuperación de información proporciona la información adecuada.
- El ajuste fino proporciona el comportamiento adecuado.
- Los agentes ofrecen el grado adecuado de autonomía.
Junto a lado
Las diferencias se manifiestan en varias dimensiones:
- Actualizaciones de conocimiento. La recuperación es en tiempo real, ya que basta con actualizar el almacén de vectores. El conocimiento ajustado con precisión se mantiene inalterado hasta el próximo entrenamiento. En el caso de los agentes, depende de lo que recuperen o a qué recurran.
- Costo. La recuperación es moderada: embeddings, almacenamiento y tokens de entrada adicionales. El ajuste fino es costoso debido a la curaduría de datos, los cálculos, el tiempo de uso de GPU y la evaluación. Los agentes presentan costos que van de moderados a altos, ya que cada tarea implica varias llamadas al modelo además de cargos por uso de herramientas.
- Complejidad. La recuperación de información requiere dividir los datos en bloques, utilizar embeddings y ajustar la búsqueda. El ajuste fino necesita preparación de datos, infraestructura de entrenamiento, ciclos de evaluación y medidas para evitar el sobreajuste. Los agentes necesitan capacidad de planificación, integración de herramientas, manejo de errores y control de ciclos.
- Tiempo de implementación. Días para la recuperación de información, semanas para el ajuste fino, y de días a semanas para los agentes, dependiendo del flujo de trabajo.
- Más adecuado para. Respuestas a preguntas, búsqueda de documentos y fundamentación en la recuperación de información. Ajuste fino para el tono, el formato y el razonamiento en un dominio específico. Tareas de múltiples pasos, automatización y uso de herramientas para los agentes.
- Latencia. La recuperación de información añade un paso adicional, generalmente de 50 a 300 milisegundos. El ajuste fino no añade nada en términos de latencia durante la inferencia en comparación con el modelo base. Los agentes suelen necesitar varios pasos y pueden tardar segundos por tarea.
- Mantenimiento. La recuperación implica mantener actualizada la base de conocimientos. El ajuste fino significa volver a entrenar periódicamente a medida que cambian las necesidades. Los agentes implican actualizar flujos de trabajo, herramientas e instrucciones.
- Fallo típico. Una mala recuperación conduce a un contexto irrelevante y a una respuesta inadecuada. El sobreajuste hace que un modelo ajustado sea frágil ante entradas desconocidas. Los agentes entran en bucles, utilizan la herramienta incorrecta o generan costos ilimitados.
Tres situaciones, una para cada una
Un chatbot de soporte basado en documentos del producto facilita la recuperación de información. Una empresa de software con 400 páginas de documentación, registros de cambios y políticas podría ajustar el modelo a ese texto, pero dicho modelo quedaría desactualizado para el siguiente lanzamiento. Al incrustar cada fragmento en un almacén de vectores se evita esto. Cuando un cliente pregunta si la API admite solicitudes por lotes, el sistema extrae las tres secciones más relevantes, el modelo responde a partir de ellas e indica la página correspondiente. Cuando los cambios en el próximo ciclo actualizan la documentación, volver a incrustar los datos actualiza las respuestas sin necesidad de volver a entrenar el modelo.
Un asistente de escritura de estilo casero es ideal para el ajuste fino. Una empresa de medios desea resúmenes con un estilo exacto: un ritmo específico en las oraciones, sin uso de primera persona y un número determinado de puntos clave al principio. Las instrucciones iniciales dan buenos resultados, pero se desvían con sesiones prolongadas. El entrenamiento con unos 2,000 pares de resúmenes editados por humanos permite que el modelo genere texto acorde a la marca de forma fiable, sin necesidad de incluir la guía de estilo en cada solicitud.
La selección de candidatos es tarea del agente. Una startup de reclutamiento desea indicar que se debe evaluar a este candidato y programar una llamada si cumple los requisitos, dejando que el resto se gestione automáticamente. El agente lee el currículum, lo compara con los requisitos del puesto mediante una API interna de puntuación, consulta el calendario del gerente de contrataciones, escribe y envía el correo de programación, y registra el resultado en el sistema de seguimiento de aplicantes. Una sola instrucción abarca todo esto, y nadie interviene en los pasos individuales.
Esta misma división se repite con frecuencia en la práctica: los diseños centrados en la recuperación de información se encargan de los aspectos básicos, los agentes se ocupan de la orquestación, y el ajuste fino solo se utiliza cuando las instrucciones no son suficientes para mantener el comportamiento estable.
Cómo se integran entre sí
Estas tres capas no son exclusivas entre sí. Los sistemas más avanzados las combinan, de modo que una solicitud fluye desde el agente que realiza la planificación, pasando por la recuperación de información que proporciona los hechos, hasta llegar a un modelo ajustado que formula la respuesta.
User Query
↓
Agent (decides what needs to happen — plan the steps)
↓
RAG (retrieves relevant knowledge, if the step needs facts)
↓
LLM (fine-tuned, if tone/format/behavior consistency matters)
↓
Action (respond to user, call a tool, trigger a downstream workflow)
↓
Agent (evaluates result → loop again or stop)
En un entorno de soporte, todo se desarrolla de la siguiente manera: llega un mensaje y el agente clasifica la intención, concluyendo que se necesita información del producto. El sistema de recuperación obtiene los fragmentos de documentación relevantes. Un modelo ajustado redacta la respuesta con la voz de la marca. Luego, el agente evalúa si la confianza es suficiente como para enviarla automáticamente o si es necesario que interviniera un humano, y finalmente registra el intercambio en el CRM.
Si se elimina cualquiera de estos componentes, surge una brecha. La recuperación sin un agente no puede decidir cuándo buscar información y cuándo actuar. Un agente sin sistema de recuperación carece de conocimiento sobre cualquier cosa fuera de sus datos de entrenamiento. Un modelo ajustado sin sistema de recuperación genera respuestas seguras y bien formateadas, pero que podrían estar desactualizadas.
Costo de cada componente
Las cifras que se indican a continuación solo sirven como orientación, ya que las cifras reales varían según la escala y el proveedor.
Para la recuperación, el costo inicial es la integración del corpus, ya sea de una sola vez o de forma gradual a medida que aumenta el volumen de documentos. Los costos operativos corresponden al alojamiento de la base de datos vectorial según el plan de precios, más tokens adicionales para el contexto recuperado en cada solicitud. Es la opción más económica en función del valor que ofrece, por lo que la mayoría de los equipos deberían comenzar por ella.
Para el ajuste fino, el elemento de mayor costo inicial suele ser los datos: recopilar y etiquetar ejemplos de entrenamiento de calidad es costoso. A continuación vienen los costos de procesamiento para los ciclos de entrenamiento y evaluación. Después se requiere un nuevo entrenamiento cada vez que es necesario cambiar el comportamiento, además del alojamiento del modelo personalizado, a menos que se utilice LoRA sobre una base compartida. Esto exige la mayor inversión inicial y tolera menos errores, ya que datos de entrenamiento de mala calidad imprimen directamente un comportamiento deficiente en los pesos del modelo.
Para los agentes, la configuración implica el diseño de flujos de trabajo, la integración de herramientas y la pruebas de los escenarios de fallo. El costo operativo es el aspecto más sutil, ya que cada paso del agente representa otra llamada al modelo. Una tarea de cinco pasos puede costar de cinco a diez veces más que una sola consulta de recuperación, y un bucle sin límite de iteraciones puede volverse completamente incontrolable. El costo refleja la complejidad de la tarea y no solo el volumen de uso.
En la práctica, la recuperación de información suele ser la opción más económica para reducir al máximo las alucinaciones. El ajuste fino solo se justifica cuando un comportamiento consistente es un requisito real del producto y no un simple beneficio adicional. Los agentes justifican el precio por tarea únicamente cuando el trabajo requiere varias decisiones y acciones, y no cuando una sola llamada bien fundamentada sería suficiente.
Reglas prácticas para elegir
- Elija la recuperación de información cuando los datos cambian con frecuencia. Los documentos, políticas, catálogos, precios e inventarios que se actualizan semanal o diariamente se adaptan bien a este enfoque, pero no tanto al ajuste fino.
- Elija el ajuste fino cuando el comportamiento es más importante que el conocimiento. Si el modelo conoce el dominio pero sigue utilizando el tono, formato o patrón de razonamiento incorrecto a pesar de una buena instrucción, el problema es de tipo conductual.
- Elija un agente cuando la tarea requiere varios pasos o acciones en el mundo real.Responder a una pregunta no necesita uno, pero planificar qué debe suceder y luego ejecutarlo a través de diferentes sistemas sí lo requiere.
- Combine la recuperación de información con el ajuste fino cuando se necesitan hechos precisos además de un tono consistente, lo cual es muy común en productos orientados al cliente.
- Combine la recuperación de información con un agente cuando la tarea exige hechos además de decisiones, siendo el agente quien elige qué buscar y cuándo actuar en función de ello.
La misma lógica se aplica en dos diagramas de flujo cortos. El primero verifica si la respuesta depende de información que cambia con frecuencia.
Does the answer depend on information that changes often?
YES → RAG
NO ↓
El segundo pregunta sobre la consistencia en el comportamiento y si la tarea abarca múltiples pasos o acciones reales.
Does the model need to consistently behave/sound a certain way,
and prompting alone isn't holding that consistency?
YES → Fine-tuning
NO ↓Does the task require multiple steps, tool calls, or real actions
(not just answering a question)?
YES → Agent (likely combined with RAG, and fine-tuning if voice matters)
NO → A single well-prompted LLM call is probably enough
Un pequeño proyecto que muestra el orden
Tomemos como ejemplo a un asistente interno de recursos humanos.
- Comience con la recuperación de información. Incorpore el manual del empleado, las políticas de ausentismo y los documentos relacionados con beneficios en un almacén vectorial. De esta manera, los empleados pueden preguntar cuántos días de enfermedad tienen y recibir una respuesta fundamentada y con referencias concretas. Esto aborda aproximadamente el 70 por ciento de los casos de uso y requiere unos pocos días.
- Añada ajustes detallados solo si surge una deficiencia. Supongamos que los recursos humanos desean que cada respuesta tenga un tono empático específico y un formato estricto que indique “aquí está la política, aquí está lo que significa para usted”, pero las respuestas siguen desviándose de ese patrón. Un modelo pequeño ajustado con unos pocos cientos de pares de preguntas y respuestas seleccionadas en ese estilo puede subsanar esa deficiencia.
El orden es intencional. La recuperación de información se realiza primero porque es la más económica y abarca la mayor cantidad de tareas. El ajuste del modelo solo se aplica cuando se detecta una verdadera discrepancia en el comportamiento. Los agentes intervienen por último, y únicamente cuando la tarea realmente requiere acciones en múltiples pasos.
Errores frecuentes
- Ajuste fino donde se necesita la recuperación de información. Los equipos intentan incorporar conocimientos en los pesos del modelo cuando el problema real implica falta de acceso a información actual. El resultado es un proceso más lento, mucho más costoso y obsoleto tan pronto como se pone en producción.
- Agentes sin flujo de trabajo definido. Un objetivo vago junto con herramientas sin restricciones hace que el agente divague, entre bucles y se comporte de manera impredecible. Herramientas específicas, condiciones claras para detenerse y un límite estricto en los pasos de razonamiento mantienen su comportamiento bajo control, mientras que pedirle simplemente que resuelva los problemas no sustituye a un proceso bien definido.
- Ignorar la latencia y el costo. Cada intento de recuperación de información y cada paso del agente implican otro viaje de ida y vuelta y más tokens por los que hay que pagar. Una demostración puede parecer excelente, pero en la producción puede requerir 12 segundos y seis llamadas al modelo para obtener una sola respuesta.
Dirección de desarrollo
La industria se dirige claramente hacia flujos de trabajo basados en agentes, es decir, sistemas que planifican, actúan y realizan seguimientos sin necesidad de ser instruidos cada vez. El siguiente paso es el enfoque híbrido: utilizar la recuperación de información para obtener respuestas, realizar ajustes para estabilizar el comportamiento y contar con una memoria a largo plazo que permita a los agentes recordar interacciones anteriores en lugar de comenzar desde cero en cada sesión.
Se observa un cambio evidente de los chatbots a lo que algunos ahora denominan empleados de IA, sistemas que realizan tareas continuas a través de diferentes herramientas y a lo largo del tiempo en lugar de esperar a que se haga una pregunta. Alcanzar ese punto tiene poco que ver con elegir la técnica más llamativa; depende de comprender qué hace bien cada componente y de combinarlos de manera deliberada, comenzando con la capa más simple que resuelva el problema.
Nunca la elección estuvo entre recuperación de información, ajuste fino o agentes. La verdadera pregunta es qué combinación necesita un sistema determinado y en qué orden construirlo.
Leer más
- Chroma Context-1: Un subagente de búsqueda de 20B para un RAG agente más económico y preciso — Cómo Chroma’s Context-1 de 20B funciona como un subagente exclusivo para recuperación de información que elimina su propio contexto, cómo fue entrenado, qué falta sin su integración y dónde presenta limitaciones.
- Notas prácticas: Los tres niveles de Google Cloud RAG: Búsqueda vectorial, motor RAG y recuperación por agente — Guía paso a paso de las Notas prácticas: Los tres niveles de Google Cloud RAG: Búsqueda vectorial, motor RAG y recuperación por agente: contratos, verificaciones y espacios para código listo para usar.
- Modelo pequeño, gran apalancamiento: Qué aprendimos con el fine-tuning de NVIDIA Nemotron 3.5 — Guía práctica de Modelo pequeño, gran apalancamiento: Qué aprendimos con el fine-tuning de NVIDIA Nemotron 3.5: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.
- Notas prácticas: Qué significa la propiedad cuando los agentes escriben el código — Guía práctica de Notas prácticas: Qué significa la propiedad cuando los agentes escriben el código: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.