Agent in a Bottle: Can LLM Agents Turn Their Capabilities Into Cheap, Scalable Artifacts?

El problema que resuelve

En el ecosistema actual de agentes de LLMs, existe una dicotomía económica insostenible: la versatilidad generalista de los modelos de frontera contrasta con el costo prohibitivo de inferencia cuando se enfrentan a millones de instancias relacionadas pero no idénticas. Consultar un LLM de 70B+ parámetros para cada consulta individual en un pipeline de alta frecuencia genera costos de cómputo y latencia que escalan linealmente con el volumen de datos, haciendo inviables aplicaciones como el etiquetado masivo, la clasificación de documentos o la extracción de entidades en tiempo real.

El paper "Agent in a Bottle" introduce el concepto de "bottling": la capacidad de un agente LLM para autonomamente generar soluciones específicas de tarea (artefactos) que equilibren la calidad de respuesta con el costo amortizado. En lugar de mantener el modelo generalista activo en cada ciclo, el agente "destila" su conocimiento en un artefacto ligero (un prompt optimizado, un pequeño modelo fine-tuneado o una lógica procedural) que puede ejecutarse de forma masiva y barata. Este enfoque transforma la arquitectura de inferencia de un modelo centralizado y costoso a uno distribuido y eficiente, permitiendo que la inteligencia general se convierta en capacidad operativa escalable.

Arquitectura y mecanismo (con detalle técnico)

El mecanismo central propuesto es el framework BOTTLED. La arquitectura opera en tres fases críticas:

1. Análisis de Tarea (Task Profiling): El agente recibe una descripción de la tarea y un conjunto de ejemplos de muestra. Utiliza razonamiento ReAct para identificar los patrones de entrada-salida, las restricciones de calidad y la distribución de los casos límite. Aquí, el agente no solo clasifica, sino que modela la función objetivo implícita.
2. Síntesis del Artefacto (Artifact Synthesis): Basándose en el perfil, el agente genera el "botellón". Esto puede manifestarse de tres formas:
   • Prompt Engineering Extremo: Generación de prompts con ejemplos few-shot óptimos y instrucciones de formato estricto para modelos pequeños (ej. 7B-13B).
   • Fine-tuning Ligero: Selección de hiperparámetros y datos de sintesis para entrenar un modelo base pequeño en GPU accesible.
   • Lógica Híbrida: Combinación de reglas deterministas (regex, árboles de decisión) con llamadas a LLMs solo para casos ambiguos.
3. Evaluación y Refinamiento (Iterative Distillation): Se ejecuta el artefacto en un conjunto de validación. Si la calidad cae por debajo del umbral definido, el agente analiza los errores (error analysis) y refina el artefacto. Este bucle continúa hasta alcanzar el equilibrio óptimo entre costo y precisión.

El aspecto técnico clave es la amortización. El costo de la fase de síntesis (que puede ser alta en tokens o cómputo) se diluye en las millones de inferencias baratas posteriores. Por ejemplo, gastar $50 en generar un prompt perfecto y un modelo de 3B fine-tuneado para una tarea específica es rentable si esa tarea se ejecuta 100,000 veces, donde cada ejecución cuesta $0.0001, frente a $0.05 por consulta al modelo original.

Qué lo hace genuinamente nuevo

A diferencia del fine-tuning tradicional o el RAG estándar, BOTTLED introduce la autonomía en la optimización de infraestructura. Tradicionalmente, los ingenieros de ML deciden qué modelo usar y cómo optimizarlo. Aquí, el LLM agente decide qué infraestructura construir.

La novedad radica en el concepto de artefacto como producto de la inteligencia. No se trata solo de obtener una respuesta correcta, sino de crear una capacidad reutilizable que persiste más allá de la sesión de inferencia. Esto cambia el paradigma de "consulta-respuesta" a "diseño-deploy-operación". Además, el paper demuestra que los agentes LLMs actuales (como Claude o GPT-4) son capaces de realizar esta metacognición sobre su propio costo de inferencia, algo que no se exploraba en profundidad en la literatura de agentes ReAct o BDI hasta ahora.

Cómo integrarlo en Zeropithos o Dibroclaw (componente concreto: RAG, BDI, knowledge graph, inferencia, seguridad + pasos de implementación)

En Zeropithos, integraremos BOTTLED en el nodo de Inferencia Adaptativa dentro de la arquitectura BDI de Dibro.

Componente Concreto: Módulo de Destilación Dinámica (DDB)

1. Extensión del Loop BDI:

   • Belief: El agente detecta que una consulta recurrente en el corpus AMASE (ej. "extraer métricas de benchmarks en papers de arXiv") está generando costos de GPU > $X/día.
   • Desire: Reducir el costo a < $Y manteniendo precisión > Z%.
   • Intention: Iniciar protocolo BOTTLED.

2. Pipeline de Implementación en Rust:

   • Paso 1: Extracción de Schemas. Utilizar el grafo de conocimiento Fuseki/SPARQL para identificar las entidades repetitivas. Si la consulta es SELECT ?metric WHERE { ?paper :benchmark ?metric }, el agente identifica el patrón estructural.
   • Paso 2: Generación de Datos Sintéticos. Dibro genera 500-1000 ejemplos sintéticos basados en el esquema SPARQL y el corpus existente para entrenar un modelo pequeño (ej. Llama-3-8B-Instruct).
   • Paso 3: Fine-tuning Ligero con QLoRA. Utilizando la GPU de 32GB, ejecutamos un script de entrenamiento rápido (LoRA/QLoRA) que dura < 30 minutos. El modelo resultante se guarda en el vector store como un "artefacto vectorial".
   • Paso 4: Routing Inteligente. El RAG pipeline se modifica. En lugar de enviar todas las consultas al LLM grande, el router consulta primero al artefacto pequeño. Si la confianza es alta, devuelve la respuesta. Si es baja, escala al LLM grande.

3. Seguridad y Validación:

   • El artefacto generado debe pasar por una "sandbox" de seguridad antes de ser desplegado en producción. Se verifica que el prompt generado no contenga inyecciones ni que el modelo fine-tuneado no haya desarrollado comportamientos alucinantes en los casos de borde.

Retos prácticos (VRAM, datos, dependencias)

• VRAM y Computed Budget: Aunque el artefacto final es barato, la fase de síntesis requiere recursos. El fine-tuning de un modelo de 8B con QLoRA requiere ~16-24GB de VRAM. En nuestra infraestructura de 32GB, esto es viable, pero limita la posibilidad de destilar modelos de 70B directamente. Deberemos usar aproximaciones de gradientes o destilar desde un modelo de 13B-30B como intermedio.
• Calidad de Datos Sintéticos: El éxito de BOTTLED depende de la calidad de los ejemplos que el agente genera. Si el agente LLM genera datos sintéticos sesgados o incompletos, el artefacto resultante será defectuoso. Necesitamos un validador automático (posiblemente basado en reglas lógicas del grafo Fuseki) para filtrar los ejemplos antes del entrenamiento.
• Mantenimiento del Artefacto: El conocimiento cambia. Si el corpus AMASE ingesta papers nuevos con formatos de benchmark distintos, el artefacto obsoleto debe ser detectado y regenerado. Esto requiere un monitor de "drift" de calidad. Si la tasa de escalado al LLM grande aumenta > 5%, se dispara la regeneración.
• Dependencias de Software: Necesitamos integrar peft (para LoRA) y transformers en el stack de Rust vía bindings o microservicios Python aislados, ya que el ecosistema de entrenamiento está fuertemente ligado a Python. Esto añade complejidad de orquestación en Dagster.

Conclusión

"Agent in a Bottle" no es solo una optimización de costos; es un cambio de paradigma en la ingeniería de agentes. Al permitir que los LLMs construyan sus propias herramientas de inferencia baratas, pasamos de una economía de "tokens" a una economía de "capacidades empaquetadas". Para Zeropithos, esto significa que Dibro no será solo un consumidor de inteligencia, sino un fabricante de la misma, optimizando su propia huella de cómputo de forma autónoma. La implementación en nuestro pipeline RAG/BDI permitirá escalar el procesamiento del corpus AMASE a órdenes de magnitudes superiores sin proporcional aumento en los costos de GPU, consolidando a Zeropithos como una infraestructura de IA verdaderamente eficiente y autosostenible.