Structured Context Engineering for File-Native Agentic Systems: Evaluating Schema Accuracy, Format Effectiveness, and Multi-File Navigation at Scale

1. El Problema

Con el auge de los agentes de Modelos de Lenguaje Grande (LLM) que operan sistemas externos mediante interfaces programáticas, existe una falta de orientación empírica sobre cómo estructurar el contexto que estos agentes consumen. Tradicionalmente, el contexto se inyectaba directamente en los prompts o mediante recuperación aumentada (RAG). Sin embargo, una nueva tendencia ("agentes nativos de archivos") utiliza herramientas de archivos nativos (como grep y read) para recuperar esquemas de datos estructurados de documentos persistentes.

El problema central es determinar:

• Si la arquitectura de recuperación basada en archivos mejora la precisión en comparación con la inyección directa en el prompt.
• Cómo afectan los formatos de archivo (YAML, JSON, Markdown, TOON) a la precisión y eficiencia.
• Si estas estrategias escalan a esquemas masivos (miles de tablas) y cómo varían según la capacidad del modelo (frontier vs. código abierto).

2. Metodología

El estudio es sistemático y abarca 9,649 experimentos diseñados para evaluar la generación de SQL como proxy de operaciones programáticas.

• Variables Experimentales:
  • Modelos: 11 modelos divididos en tres niveles de capacidad: Frontier (Claude Opus, GPT-5, Gemini Pro), Frontier Lab (versiones más rápidas/baratas) y Open Source (DeepSeek, Llama, Qwen, Kimi).
  • Formatos: 4 representaciones de esquemas: YAML, Markdown, JSON y TOON (Token-Oriented Object Notation, un formato compacto personalizado).
  • Arquitecturas:
    1. File Agent: El agente usa herramientas grep/read para recuperar información bajo demanda.
    2. Prompt Baseline: El esquema completo (~6,000 tokens) se inyecta directamente en el sistema.
  • Escala: Esquemas desde 10 tablas hasta 10,000 tablas (usando particionamiento por dominios para los más grandes).
  • Complejidad: Consultas SQL de 5 niveles (L1: búsqueda directa a L5: razonamiento multi-paso).
• Evaluación: Se utilizó la similitud de Jaccard sobre los conjuntos de resultados (umbral de éxito ≥ 0.9) con temperatura 0 para garantizar reproducibilidad.

3. Contribuciones Clave

El artículo aporta cinco hallazgos principales que desafían suposiciones comunes en la ingeniería de contextos:

1. Dependencia del Modelo: La arquitectura de "agente nativo de archivos" no es universalmente superior; su eficacia depende críticamente de la capacidad del modelo.
2. Neutralidad del Formato (en agregado): El formato del archivo no afecta significativamente la precisión general, aunque existen sensibilidades específicas por modelo.
3. Brecha de Capacidad: La diferencia entre modelos frontier y open source es el factor dominante, superando cualquier efecto de arquitectura o formato.
4. Escalabilidad: Los agentes nativos de archivos pueden navegar esquemas de 10,000 tablas con alta precisión si se utiliza particionamiento por dominios.
5. El "Impuesto Grep" (Grep Tax): Se identifica un fenómeno donde formatos compactos o novedosos pueden generar un sobrecosto de tokens en tiempo de ejecución debido a la densidad de salida de grep y la falta de familiaridad del modelo con los patrones de búsqueda.

4. Resultados Detallados

A. Arquitectura: Archivo vs. Prompt (RQ1)

• Modelos Frontier: La recuperación nativa de archivos mejoró la precisión en un +2.7% (p=0.029) en comparación con el prompt completo.
• Modelos Open Source: Mostraron resultados mixtos y, en agregado, un déficit del -7.7% (p<0.001) al usar archivos. Modelos como Qwen y Llama Maverick sufrieron caídas drásticas (-21.9% y -13.9% respectivamente), mientras que Kimi y Llama Scout mostraron diferencias insignificantes.
• Conclusión: Los modelos avanzados gestionan mejor la recuperación iterativa, mientras que los modelos open source a menudo fallan al navegar archivos dinámicamente.

B. Efecto del Formato (RQ2)

• No hubo diferencia significativa en la precisión agregada entre YAML, Markdown, JSON y TOON (p=0.484).
• Sin embargo, los modelos individuales mostraron sensibilidades. Los modelos open source tuvieron variaciones de precisión de hasta 20 puntos porcentuales entre formatos, mientras que los frontier variaron menos de 5 puntos.
• YAML fue el formato más eficiente en tokens (12,729 tokens promedio), seguido de JSON, TOON y Markdown.

C. Capacidad del Modelo (RQ3)

• La capacidad del modelo es el factor determinante.
  • Frontier: 86.0% de precisión.
  • Frontier Lab: 76.7%.
  • Open Source: 64.6%.
• Existe una brecha de 21 puntos porcentuales entre los niveles superior e inferior, lo que eclipsa cualquier beneficio de optimización de formato o arquitectura.
• En tareas complejas (L5), los modelos frontier mantuvieron un 64% de precisión, mientras que los open source cayeron al 27%.

D. Escalabilidad (RQ4)

• Con esquemas de un solo archivo, la precisión se mantuvo casi perfecta hasta 1,000 tablas.
• Para 10,000 tablas, el uso de particionamiento por dominios (aprox. 250 tablas por dominio) permitió mantener una alta precisión de navegación, evitando que el contexto excediera los límites de ventana del modelo.

E. Eficiencia y el "Impuesto Grep" (RQ5)

• Eficiencia de Tokens: Contraintuitivamente, formatos más compactos como TOON (que reducen el tamaño del archivo en un 25%) consumieron 38% más de tokens en tiempo de ejecución que YAML en promedio.
• Causa del Impuesto Grep:
  1. Densidad de Salida: Una coincidencia de grep en TOON devuelve más contenido por línea que en YAML.
  2. Desconocimiento de Patrones: Los modelos no entrenados en TOON intentan patrones de búsqueda erróneos (basados en DDL o JSON) antes de encontrar el patrón correcto, generando múltiples llamadas a herramientas innecesarias.
• Este fenómeno es dependiente del modelo: Claude Opus lo maneja bien, mientras que Haiku y modelos open source sufren un aumento exponencial en llamadas a herramientas y tokens a medida que crece la escala.

5. Significado y Recomendaciones Prácticas

El estudio concluye que no existen mejores prácticas universales para la ingeniería de contextos en agentes; las decisiones deben adaptarse a la capacidad del modelo elegido.

Guía de Recomendaciones para Practicantes:

1. Selección de Arquitectura:
   • Modelos Frontier: Usar Agentes Nativos de Archivos (File Agent).
   • Modelos Open Source: Preferir Ingeniería de Prompts (inyección directa) o validar exhaustivamente el uso de archivos, ya que suelen fallar en la recuperación dinámica.
2. Selección de Formato:
   • Priorizar YAML por su equilibrio entre eficiencia de tokens y legibilidad para grep.
   • Evitar formatos compactos personalizados (como TOON) sin proporcionar ejemplos específicos de patrones de búsqueda en el prompt del sistema para mitigar el "impuesto grep".
3. Estrategia de Escala:
   • Para entornos empresariales (>1,000 tablas), implementar particionamiento por dominios es esencial para mantener la precisión y la eficiencia.
4. Inversión Estratégica:
   • La capacidad del modelo es el factor más crítico. Es más efectivo invertir en un modelo de mayor nivel que en la optimización de formatos de archivo.

En resumen, el papel demuestra que la ingeniería de contextos debe ser un proceso de ajuste fino basado en el modelo específico, donde la arquitectura de recuperación y el formato del archivo deben alinearse con las capacidades de razonamiento y uso de herramientas del LLM seleccionado.