Construyendo sistemas de IA: De RAG a agentes

La mayoría de los equipos comienzan con RAG, descubren sus límites y luego incorporan fine-tuning. Ambos resuelven la recuperación y el razonamiento. Ninguno resuelve la orquestación: decidir cuándo actuar, cuántos agentes generar, cuándo detenerse y qué significa el consenso. Construí un sistema de deliberación multi-agente (3.500 líneas de Python, 86 hooks, 141 pruebas) que maneja los tres aspectos.

TL;DR

RAG recupera documentos en el momento de la consulta. Fine-tuning modifica los pesos del modelo con datos del dominio. Ambos son herramientas de recuperación y razonamiento. Ninguno maneja la orquestación: coordinar múltiples agentes, validar el consenso o decidir cuándo una tarea necesita una llamada al modelo versus doce. Me encontré con este muro al construir un sistema de calidad para un blog que necesitaba linting en paralelo, puntuación de profundidad, verificación de citas y evaluación con LLM a través de 33 publicaciones. La solución fue una capa de orquestación de agentes con deliberación activada por confianza, gestión de presupuesto de generación y validación de consenso con cuatro verificaciones. Esta publicación cubre la decisión RAG-vs-fine-tuning y luego va donde la mayoría de las guías se detienen: qué sucede cuando se necesitan agentes.

Parte 1: RAG vs Fine-Tuning

Un estudio de Databricks de 2024 encontró que el 78% de los equipos empresariales de IA eligieron RAG primero; sin embargo, el 34% descubrió posteriormente que fine-tuning habría sido el mejor enfoque, desperdiciando un promedio de 3,2 meses en tiempo de implementación.¹

La decisión no es una cosa u otra. Se trata de emparejar la técnica con el problema.

Cuándo gana RAG

Conocimiento que cambia frecuentemente. RAG recupera documentos actuales en el momento de la consulta. Cuando la base de conocimiento se actualiza diariamente (documentación de productos, artículos de soporte, presentaciones regulatorias), RAG proporciona información actual sin necesidad de reentrenamiento.²

Requisitos de atribución de fuentes. RAG cita documentos específicos porque la recuperación produce una lista explícita de fuentes. En industrias reguladas (salud, finanzas, legal), la atribución de fuentes es frecuentemente un requisito de cumplimiento.³

Bases de conocimiento grandes. Un sistema RAG sobre 10 millones de documentos rinde de forma comparable a uno sobre 1 millón si la calidad de recuperación es consistente. Los modelos con fine-tuning alcanzan límites de capacidad determinados por el tamaño del modelo.⁴

Cuándo gana Fine-Tuning

Patrones de razonamiento específicos del dominio. RAG proporciona información. Fine-tuning proporciona capacidad. Un modelo con fine-tuning en conversaciones de diagnóstico médico aprende patrones de diagnóstico diferencial: cómo ponderar síntomas, cuándo considerar condiciones raras, cómo formular preguntas de seguimiento. RAG puede suministrar el conocimiento médico, pero el patrón de razonamiento requiere ajuste de pesos.⁵

Requisitos estrictos de formato de salida. Fine-tuning aplica salidas estructuradas (JSON, XML, esquemas específicos) de manera más confiable que la ingeniería de prompts. Para sistemas donde las fallas de formato causan errores posteriores, fine-tuning proporciona mayor confiabilidad.⁶

Aplicaciones críticas en latencia. RAG agrega latencia de recuperación: incrustar la consulta, buscar en la base de datos vectorial, recuperar documentos e inyectarlos en el prompt. Para aplicaciones con objetivos de respuesta inferiores a 200 ms, eliminar la recuperación mediante fine-tuning puede ser necesario.⁷

La matriz de comparación

El enfoque combinado

La mayoría de los sistemas en producción combinan ambas técnicas. Se aplica fine-tuning al modelo en patrones de razonamiento del dominio y formatos de salida. Se usa RAG para proporcionar conocimiento actual y atribuible en el momento de la consulta. El modelo con fine-tuning sabe cómo razonar sobre el dominio. El sistema RAG proporciona sobre qué razonar.⁸

Parte 2: Cuándo se necesitan agentes

RAG y fine-tuning manejan la recuperación y el razonamiento. Ninguno maneja la orquestación: decidir si una tarea necesita una llamada al modelo o doce, cuándo generar trabajadores en paralelo, cómo validar sus resultados y cuándo escalar a un humano.

Me encontré con este muro al construir mi infraestructura de calidad para el blog. Tenía 33 publicaciones de blog por evaluar, corregir y verificar. Una sola llamada al modelo por publicación no era suficiente. Cada publicación necesitaba linting (12 módulos), puntuación de profundidad (5 señales), análisis de legibilidad, verificación de citas y evaluación con LLM. Ejecutarlos secuencialmente tomaba demasiado tiempo. Ejecutarlos en paralelo sin coordinación producía conflictos y resultados inconsistentes.

La solución no era más RAG ni mejor fine-tuning. Era una capa de orquestación de agentes.

Qué requiere la orquestación de agentes

El pipeline tradicional de ML asume un flujo lineal: datos, preprocesamiento, modelo, evaluación, despliegue.⁹ Los sistemas de agentes son no lineales. Un agente podría:

1. Evaluar su propia confianza y decidir que necesita ayuda
2. Generar 5 sub-agentes en paralelo con diferente experiencia
3. Recopilar y clasificar sus resultados
4. Detectar cuándo los agentes convergen demasiado rápido (pensamiento grupal)
5. Validar el consenso contra umbrales de calidad
6. Generar una recomendación final

Cada paso requiere infraestructura que RAG y fine-tuning no proporcionan.

Parte 3: Lo que construí

La arquitectura

Mi sistema de deliberación abarca 3.500 líneas de Python distribuidas en 12 módulos:

Deliberation System
├── confidence.py       Triggers deliberation based on ambiguity/complexity/stakes
├── state_machine.py    Workflow: idle → research → ranking → consensus
├── agents.py           5+ persona templates (Architect, Security, Performance...)
├── context_isolation.py  RLM L0-L3 layers prevent context contamination
├── ranking.py          Stack ranking with weighted consensus calculation
├── spawner.py          Parallel agent spawning via Task API
├── conformity.py       Detects groupthink and premature convergence
├── mailbox.py          Multi-round debate protocol
├── memory.py           Cross-session learning and persona tracking
├── scaling.py          Dynamic agent count based on complexity
├── prd_generator.py    Converts decisions into product requirements
└── observability.py    Session metrics and audit replay

El sistema se apoya en 86 hooks que interceptan operaciones en seis puntos del ciclo de vida (PreToolUse, PostToolUse, Stop y tres más). Cada generación de agente, cada escritura de archivo, cada comando de git pasa por validación.

El disparador de confianza

No toda tarea necesita cinco agentes debatiendo. Construí un algoritmo de puntuación de confianza que evalúa cuatro dimensiones:

1. Ambigüedad — ¿La consulta tiene múltiples interpretaciones válidas? (Coincidencias de patrones: “mejor manera”, “debería”, “comparar vs”, “pros y contras”)
2. Complejidad del dominio — ¿Requiere conocimiento especializado? (Coincidencias de patrones: “arquitectura”, “seguridad”, “rendimiento”, “esquema de base de datos”)
3. Riesgo — ¿Es la decisión reversible? (Coincidencias de patrones: “producción”, “cambio disruptivo”, “eliminar”, “vulnerabilidad de seguridad”)
4. Dependencia del contexto — ¿Requiere comprender el sistema más amplio?

La puntuación se asigna a tres niveles:

• ALTO (0,85+): Proceder sin deliberación
• MEDIO (0,70-0,84): Proceder con una nota de confianza registrada
• BAJO (inferior a 0,70): Activar deliberación multi-agente completa

El umbral se adapta según el tipo de tarea. Las decisiones de seguridad requieren un 85% de consenso. Los cambios de documentación solo necesitan un 50%. Esto evita la sobreingeniería de tareas simples mientras asegura que las decisiones riesgosas reciban el escrutinio adecuado.

El problema del presupuesto de generación

Mi primera implementación usaba límites de recursión basados en profundidad: el agente en profundidad 0 genera profundidad 1, que genera profundidad 2, bloqueado en profundidad 3. Esto falló inmediatamente. Los agentes de deliberación necesitan ejecutarse en paralelo, no en serie. Cinco agentes en profundidad 1 no es recursión profunda. Es colaboración amplia.

La solución: un modelo de presupuesto de generación. El agente raíz recibe un presupuesto (12 agentes como máximo). Gasta ese presupuesto generando trabajadores en paralelo. Los trabajadores heredan el presupuesto restante pero no pueden excederlo. Esto previene cadenas descontroladas mientras permite la ejecución en paralelo que la deliberación requiere.

La prueba en el mundo real llegó cuando ejecuté 10 agentes de revisión a través de publicaciones de blog traducidas. La protección contra recursión bloqueó los agentes del 4 al 10 porque contaba las generaciones como incrementos de profundidad. Después de cambiar al modelo de presupuesto, los 10 se ejecutaron exitosamente. La profundidad nunca excedió 1. La amplitud se expandió para ajustarse a la tarea.¹⁰

Validación de consenso

Después de que los agentes completan su trabajo, un hook post-deliberación ejecuta cuatro verificaciones:

1. Preparación de fase — ¿Ha progresado la deliberación más allá de la investigación hacia la clasificación?
2. Quórum de agentes — ¿Al menos 2 agentes completaron? (Configurable por tipo de tarea)
3. Umbral de consenso — ¿El acuerdo alcanza el nivel requerido? (70% base, 85% para seguridad)
4. Documentación del disenso — Si los agentes no están de acuerdo, ¿se registran las preocupaciones?

La verificación 4 fue la perspectiva que no esperaba. Las primeras ejecuciones producían “consenso” donde los agentes simplemente coincidían con la primera respuesta. El detector de conformidad ahora señala la convergencia prematura: si todos los agentes están de acuerdo en la primera ronda con puntuaciones de similitud altas, el sistema fuerza una segunda ronda de análisis adversarial.

Lo que aprendí por las malas

Las escrituras atómicas de archivos importan. Múltiples agentes escribiendo simultáneamente al mismo archivo de estado corrompieron el JSON. La solución: escribir en archivos .tmp y luego mover atómicamente con mv. El sistema operativo garantiza que mv es atómico en el mismo sistema de archivos. Este cambio de una línea eliminó toda una categoría de condiciones de carrera.

El aislamiento de contexto previene el pensamiento grupal. Cada agente recibe contexto independiente a través de cuatro capas (L0: conocimiento base, L1: específico de la tarea, L2: específico del persona, L3: específico de la ronda). Sin aislamiento, los agentes convergen en la primera respuesta plausible en lugar de explorar el espacio de soluciones. Con aislamiento, el agente de Seguridad y el agente de Rendimiento llegan a conclusiones genuinamente diferentes porque parten de supuestos diferentes.

Probar la infraestructura de agentes es más difícil que probar el código de aplicación. El sistema tiene 141 pruebas: 48 pruebas de integración en bash para el comportamiento de hooks, 81 pruebas unitarias en Python para módulos de biblioteca y 12 simulaciones de pipeline de extremo a extremo. Cada historia de fallo en la memoria de mi proyecto (bloqueo de presupuesto de generación, falsos positivos en detección de comillas, archivos de plan de blog servidos accidentalmente como publicaciones) se convirtió en un caso de prueba después de la corrección. Los errores de agentes son más difíciles de reproducir que los errores de aplicación porque dependen de la sincronización, el orden y el estado concurrente.

La división humano-agente

El patrón: los humanos son responsables de las decisiones que requieren contexto organizacional, juicio ético o dirección estratégica. Los agentes son responsables de las decisiones que requieren búsqueda computacional a través de grandes espacios de posibilidades.¹¹ Exploré esta división con mayor profundidad en mi análisis de arquitectura de agentes.

El ingeniero de ML agéntico no codifica pipelines a mano. El ingeniero de ML agéntico define objetivos, restricciones y criterios de evaluación. Los agentes manejan el ciclo de implementación: proponer, ejecutar, evaluar, iterar. El rol humano cambia de constructor a arquitecto: establecer barandillas, revisar resultados y tomar decisiones de juicio que requieren contexto de dominio del que los agentes carecen.¹²

Conclusiones clave

Para ingenieros que comienzan con sistemas de IA: - Comience con RAG para cualquier caso de uso que involucre conocimiento que cambia frecuentemente o requisitos de atribución de fuentes; RAG proporciona una línea base funcional en días, mientras que fine-tuning requiere semanas de preparación de datos - Combine RAG y fine-tuning cuando la aplicación necesite tanto razonamiento del dominio COMO conocimiento actual - Si necesita más de una llamada al modelo por tarea, necesita orquestación de agentes, y ese es un problema de ingeniería diferente al de RAG o fine-tuning

Para equipos que construyen sistemas de agentes: - Construya la puntuación de confianza antes de construir agentes; la mayoría de las tareas no necesitan deliberación, y el sistema que sabe cuándo usar agentes es más valioso que los agentes mismos - Use presupuestos de generación, no límites de profundidad, para arquitecturas de agentes en paralelo; los límites de profundidad bloquean patrones de colaboración amplia que la deliberación de agentes requiere - Pruebe la calidad del consenso, no solo la existencia del consenso; el acuerdo prematuro es peor que la ausencia de acuerdo porque crea falsa confianza

Referencias