Resumen Técnico: TraceCompiler

Definición del Problema

Los agentes de modelos de lenguaje con capacidad de uso de herramientas (LLM) redescubren frecuentemente procedimientos que ya han ejecutado, lo que incurre en costos significativos tanto en el uso de tokens como en la latencia. Una única intención recurrente (por ejemplo, solicitar un pago o listar entradas) suele activar un rastro que contiene una mezcla de estructura reutilizable (herramientas necesarias, dependencias de datos reales, configuración estable) e historial de ejecución accidental (reintentos, búsquedas de esquemas, ordenamiento estilístico y resolución de hechos repetidos).

Los enfoques actuales, como resumir los rastros como guía textual, aún requieren que el LLM reinterprete el procedimiento en tiempo de ejecución. El descubrimiento de procesos convencional es insuficiente porque el orden de los eventos observados no implica dependencia; las llamadas consecutivas pueden ser el resultado de operaciones independientes, intentos fallidos o flujo de datos. Además, los registros desplegados suelen sufrir de observabilidad parcial, registrando argumentos pero no las salidas de las herramientas, lo que hace imposible verificar las dependencias mediante la correspondencia de las salidas del productor con las entradas del consumidor.

El desafío central es compilar rastros de agentes ruidosos y parcialmente observables en flujos de trabajo ejecutables y mayoritariamente deterministas, donde las decisiones respaldadas por evidencia se eliminen de la responsabilidad del modelo en tiempo de ejecución, dejando únicamente las opciones genuinamente abiertas para el LLM.

Metodología

TraceCompiler es un sistema guiado por habilidades que mina grupos de rastros ruidosos y los compila en flujos de trabajo tipados. El proceso consta de las siguientes etapas:

1. Descubrimiento de Intenciones y Agrupamiento (Clustering)

Las conversaciones se incrustan como documentos que combinan la solicitud inicial con razonamientos e llamadas a herramientas intercaladas. La aglomeración por umbral (distancia de coseno, enlace promedio) agrupa los rastros en grupos de intención. El sistema prioriza un sub-agrupamiento conservador para evitar contaminar intenciones distintas. Pasadas previas idempotentes detectan y dividen conversaciones que mezclan intenciones no relacionadas.

2. Normalización y Eliminación de Ruido Conductual

Los rastros brutos se normalizan a un vocabulario canónico de app.action. Las acciones se etiquetan como:

• Esenciales: Requeridas para la tarea.
• Recuperación/Exploratorias/Redundantes: Retenidas para análisis pero potencialmente eliminables.
• Salida Muerta (Dead Output): Acciones cuyas salidas nunca son consumidas aguas abajo (por ejemplo, búsquedas de esquemas).
• Reintento vs. Variación: El sistema distingue entre ruido (fluctuaciones en los argumentos que convergen hacia un éxito) y un fan-out genuino (argumentos sistemáticamente distintos, por ejemplo, búsquedas por canción). Los bucles de paginación se detectan mediante contadores literales.

3. Verificación de Dependencia a Nivel de Argumento

Esta es la innovación central. Un arco $a \to b$ se admite como una dependencia fuerte solo si:

1. Un valor en el argumento de $b$ es rastreable hasta la salida de $a$.
2. Exclusión: Se excluye todo origen alternativo para ese valor (expresiones del usuario, contexto estático, valores por defecto de la herramienta y salidas de todas las llamadas precedentes).

Si existe un origen alternativo plausible (por ejemplo, dos productores de tipos compatibles), el arco se degrada a sospechoso y no impone una restricción de orden. Esto evita que el compilador infiera dependencias falsas basadas únicamente en la adyacencia.

4. Clasificación de Procedencia y Contexto Estático

Las vinculaciones se clasifican en:

• Constante: Estable a través de los rastros (se resuelve en tiempo de compilación).
• Entrada de Usuario: Se resuelve en tiempo de ejecución.
• Arco de Copia (Copy Edge): Un valor cuya procedencia se demuestra originada en un productor específico.
• Transformación: Transformaciones deterministas.
• LLM/Dinámico: Vinculaciones semánticas genuinas que requieren resolución del modelo en tiempo de ejecución.

El compilador está especificado para realizar una inyección de contexto estático limitada al alcance, resolviendo valores estables en tiempo de compilación y prohibiendo las herramientas de descubrimiento para esos valores en tiempo de ejecución. Sin embargo, esta característica no fue ejercitada en los resultados reportados; ningún caso de estudio reporta un valor inyectado, y el elemento de diseño permanece a la espera de evidencia. Si un efecto secundario irreversible está subdeterminado (por ejemplo, si la dirección de una mutación es ambigua), el compilador se abstiene y no emite un grafo ejecutable, escalando la solicitud en su lugar.

5. Compilación y Tiempo de Ejecución

El análisis se compila en una definición ejecutable (DAG) con nodos tipados (HERRAMIENTA, TRANSFORMACIÓN, DECISIÓN, LLM, HUMANO). El enrutador de tiempo de ejecución despacha las solicitudes a los flujos de trabajo compilados si coinciden con un umbral de similitud conservador; las solicitudes no coincidentes recurren al agente general.

El motor del compilador (v1) se implementa como una habilidad de LLM versionada —un paquete de instrucciones cargado por un agente— en lugar de un modelo entrenado. Esto permite una auditoría adversarial y una revisión rápida sin necesidad de reentrenamiento.

Contribuciones Clave

1. Formulación: Enmarcar la reutilización de rastros de agentes recurrentes como un problema de compilación sobre la estructura del flujo de trabajo, la procedencia de parámetros y las decisiones residuales del LLM bajo observabilidad parcial.
2. Pipeline: Un pipeline no supervisado completo para el descubrimiento de intenciones, eliminación de ruido conductual, verificación de dependencias, clasificación de procedencia y generación de flujos de trabajo ejecutables.
3. Regla de Dependencia: Una regla formalizada y conservadora de dependencia a nivel de argumento que admite arcos solo mediante la exclusión de orígenes alternativos. Introduce tuplas de evidencia explícitas y una relación de "sospecha" para casos ambiguos.
4. Evaluación: Evaluación contra dos verdades fundamentales (T1 y AppWorld) que no comparten maquinaria, comparándose contra bases de referencia basadas en orden y en recurrencia.
5. Casos de Estudio: Demostración de compilación exitosa (solicitud de dinero en Venmo) y rechazo de compilación (Spotify/Todoist) cuando los efectos secundarios irreversibles están subdeterminados.

Resultados

Precisión de Dependencia

• Corpus T1 (División de Entrenamiento): La regla mecanizada logró una precisión de 0.928 y una sensibilidad (recall) de 0.943 en 15,775 arcos de definición-uso. Esto supera significativamente a las bases de referencia basadas en adyacencia (F1 de 0.711) y medidas de seguimiento directo por umbral de frecuencia (F1 de 0.712).
  • Advertencia: Los estudios de ablación revelan que, en este corpus específico, la prueba de exclusión es casi vacua porque cada relación tiene al menos un productor candidato. Por consiguiente, la precisión reportada depende fuertemente de la recencia (seleccionando al sobreviviente más reciente) entre los candidatos sobrevivientes, más que de la prueba de exclusión completa. La disciplina de exclusión es ejercida por la habilidad de LLM, no por la regla mecanizada, debido a las limitaciones del corpus.
• Ejecución de la Habilidad Ciega: En un subconjunto de 250 arcos de T1, la habilidad de LLM logró 0.992 de precisión/sensibilidad en una sola ejecución.
• AppWorld: Contra una referencia basada en la reproducción (que recupera valores enmascarados), la regla logró una precisión de 0.993 en 563 arcos de tokens. Esto sirve como una verificación de autoconsistencia más que como una validación independiente, ya que la construcción de la referencia comparte la misma suposición (preferir tokens de la misma aplicación) que la regla probada. Además, este límite de brazo solo atribuye el token de sesión y no valida la recuperación de flujos de identificadores no pertenecientes a tokens.

Compilación y Ejecución de Flujos de Trabajo

• Intención de Venmo: Compiló 34 llamadas a la API observadas (incluyendo reintentos y búsquedas de esquemas) en 11 llamadas en tiempo de ejecución. El flujo de trabajo pasó 15 de 21 pruebas de estado en instancias retenidas. Los 6 fallos ocurrieron porque la rama específica requerida para la instancia retenida nunca fue observada en el conjunto de entrenamiento, causando que el sistema escalara en lugar de actuar.
• Intención de Spotify/Todoist: El compilador correctamente se negó a compilar esta intención porque la dirección de la mutación (añadir vs. eliminar) estaba subdeterminada por los rastros, representando un efecto secundario irreversible.
• Reducción de Llamadas: A través de 56 escenarios de AppWorld, la fracción mediana de llamadas eliminables (descubrimiento de esquemas y repeticiones idénticas en bytes) fue del 51.4%.

Descubrimiento de Intenciones

En T1, el agrupamiento logró una pureza de 0.930 sobre los diálogos cubiertos pero un Índice de Rand Ajustado bajo (0.235) frente a las etiquetas de referencia. Esto indica que el sistema descubre una partición más fina que las etiquetas de referencia (subdividiendo dominios en tareas de nivel de plantilla) en lugar de clasificar erróneamente.

Significado y Reivindicaciones

El artículo sostiene que la adyacencia observada no implica dependencia. Al imponer una disciplina de evidencia que requiere la exclusión de orígenes alternativos, TraceCompiler puede compilar rastros ruidosos en flujos de trabajo deterministas que reducen las llamadas a herramientas y las invocaciones del LLM en tiempo de ejecución.

• Seguridad: El sistema prioriza la seguridad sobre la completitud. Se abstiene de compilar flujos de trabajo donde los efectos secundarios irreversibles están subdeterminados, evitando la ejecución de procedimientos especulativos e inseguros.
• Eficiencia: Aunque el artículo mide la reducción de llamadas (por ejemplo, de 34 a 11 llamadas), explícitamente no afirma una eficiencia neta porque no se miden los costos de compilación fuera de línea. La premisa económica es que un modelo capaz puede amortizar el costo del análisis sobre ejecuciones repetidas.
• Limitaciones: Los autores reconocen que la evaluación actual depende de datos sintéticos o generados por simuladores. La disciplina de "exclusión" es ejercida por la habilidad de LLM pero no totalmente por la regla mecanizada debido a las limitaciones del corpus (falta de tokens señuelo). El sistema carece actualmente de mecanismos de versionado de flujo de trabajo e invalidación para el cambio (drift) de las API.

El trabajo establece que los rastros observados delimitan las afirmaciones sobre la necesidad tan estrictamente como delimitan las afirmaciones sobre la dependencia, y que los instrumentos utilizados para probar los flujos de trabajo compilados (harnesses de ejecución) son en sí mismos procedimientos de inferencia que requieren validación.