Cuestionando la pila de agentes: almacenes vectoriales, hipergrafos y tareas de codificación

La tendencia a añadir más

Al leer la cobertura de este año sobre los agentes de IA, una cosa destaca por encima de cualquier afirmación individual: el consejo es casi siempre añadir algo más. Una capa de memoria. Un grafo. Un marco de orquestación. Un pipeline de recuperación con tres pasos de reclasificación. Más agentes para supervisar a los que ya tienes. En el fondo existe la creencia tácita de que la sofisticación significa progreso, y de que un sistema que no hace nada más avanzado que hace seis meses está quedándose atrás.

Probablemente, una buena parte de ese conjunto tecnológico ya ha sido desarrollado y defendido por cualquiera que esté leyendo esto. Por lo tanto, vale la pena detenerse en un pequeño grupo de ejemplos que argumentan lo contrario: lo sofisticado que se ha añadido probablemente no merece su lugar. La mayoría de los escritos tecnológicos contrarios son en realidad exageraciones al revés, igualmente seguros pero igualmente carentes de pruebas. Estos tres casos son diferentes porque cada uno se basa en algo verificable, ya sea un resultado de pruebas de rendimiento, una prueba estructural o un relato simple de cómo transcurre el día laboral de alguien. Ese estándar se aplica a continuación, y también a cualquier conjunto tecnológico, incluido el propio.

Cada caso representa un momento en el que el campo buscó más estructura, aunque el problema real residía en algo menos evidente.

Caso uno: memoria de agentes y almacenes vectoriales

La memoria del agente en un almacén vectorial suele establecerse en aproximadamente medio minuto. Alguien señaló que el agente debería conservar la información entre sesiones, y de ahí surgió la solución: incrustar, almacenar y recuperar mediante similitud. Todos los tutoriales funcionan de esa manera, por lo que se convirtió en la opción predeterminada, y nadie lo probó frente a algo más simple.

Un artículo publicado este año realizó esa prueba. En el benchmark LoCoMo, un conjunto de referencia formado por una carpeta de archivos de texto plano y grep obtuvo mejores resultados que varios productos especializados financiados para almacenamiento de memoria. La comparación no fue controlada. Los sistemas que utilizaban incrustaciones, búsqueda por similitud y, a veces, memoria basada en grafos, perdieron frente a una configuración que requiere toda una tarde para armarla.

Después de pensarlo bien, la explicación parece clara. La búsqueda por similitud encuentra información, pero no razona. Funciona bien para extraer texto cuyo significado es similar a una consulta. Pero falla en tareas que requieren memoria, como reconocer que un hecho de hace tres semanas fue reemplazado por uno de ayer, o que dos memorias guardadas son contradictorias y solo una puede prevalecer. Un índice no tiene concepto de tiempo ni de correcciones, por lo que devuelve los vectores más cercanos y deja que el modelo se dé cuenta de que dos de los cinco principales son contradictorios entre sí.

Otra discrepancia se refiere a la familiaridad y no a la capacidad. Los modelos han sido entrenados con enormes volúmenes de material sobre el trabajo con archivos: abrirlos, buscar en ellos, editarlos, listar carpetas, rastrear importaciones. Los archivos están muy cerca del material original de sus datos de entrenamiento, y un bucle de lectura de archivos combinado con grep los utiliza directamente. En contraste, la API de consultas vectoriales de un proveedor es algo que el modelo debe aprender a utilizar adecuadamente dentro de su propia ventana de contexto, sin haber estado expuesto a ella previamente. Este intercambio implica reemplazar una habilidad que ya posee por otra que debe adquirir durante la tarea, además de generar demoras en el proceso de incrustación y recuperación.

Una guía de decisión para las dos opciones, presentadas una al lado de la otra, se ve así.

WHEN A FILESYSTEM + GREP BASELINE IS ENOUGH        WHEN YOU ACTUALLY NEED A VECTOR STORE
------------------------------------------------   ------------------------------------------------
Single-agent or small-team memory                  Retrieval across a corpus too large to
                                                    fit or scan in context at all
Facts that change over time and need               Cross-document semantic search where
correction, not just accumulation                  keyword overlap is genuinely weak
Memory the model itself writes,                    Centralized memory shared by many agents
manages, and re-reads in its own loop               that needs access control and auditing
Debuggable state, plain text you can                Multi-hop or relational reasoning across
open, diff, and edit by hand                        thousands of entities where similarity
                                                     search is doing real narrowing work

Así es el bucle basado en archivos

“Simplemente usa archivos” suena vago hasta que se convierte en código. Esta versión no necesita un servicio alojado.

import os
import subprocess
from datetime import datetime
MEMORY_DIR = "agent_memory"
def write_memory(topic: str, content: str) -> str:
    os.makedirs(MEMORY_DIR, exist_ok=True)
    path = os.path.join(MEMORY_DIR, f"{topic}.md")
    timestamp = datetime.utcnow().isoformat()
    with open(path, "a", encoding="utf-8") as f:
        f.write(f"\n## {timestamp}\n{content}\n")
    return path
def recall(query: str) -> str:
    # ripgrep if you have it, grep -r works fine too
    result = subprocess.run(
        ["rg", "-i", "-C", "2", query, MEMORY_DIR],
        capture_output=True, text=True
    )
    return result.stdout or "no matches"
def list_topics() -> list[str]:
    if not os.path.isdir(MEMORY_DIR):
        return []
    return [f[:-3] for f in os.listdir(MEMORY_DIR) if f.endswith(".md")]

Dale al modelo esas tres funciones como herramientas y déjalo decidir cuándo guardar, cuándo buscar y cuándo cargar un archivo completo de un tema breve. El resultado es una memoria sin costos de incrustación, sin base de datos que albergar o pagar, y con un estado que se puede abrir en cualquier editor cuando algo funciona mal. Cuando este enfoque eventualmente se agote, la razón será concreta, como un corpus demasiado grande para buscar rápidamente o una pregunta de múltiples pasos a la que la búsqueda por palabras clave no puede responder. Eso justifica el uso de un almacén de vectores mucho mejor que copiar un tutorial.

Nada de esto significa que las bases de datos vectoriales no deberían existir. Significa que no se debe recurrir a ellas antes de evaluar la opción básica y sencilla. Pruebe primero con el contexto completo, el sistema de archivos y grep, y adopte un producto de memoria de pago solo si supera significativamente esa opción básica, lo suficiente como para cubrir su costo y la pérdida de posibilidades de depuración. La memoria de la mayoría de los agentes rara vez necesita superar ese umbral.

Caso dos: hipergrafos en RAG

El estándar del año pasado era la base de datos vectorial. Este año es el RAG basado en grafos, y los hipergrafos entran en juego cuando un equipo considera que un grafo de conocimiento ordinario no puede expresar lo suficiente. Este caso parece razonable. Un borde regular conecta dos nodos, pero muchos hechos involucran a más participantes. Tomemos la aprobación de un gasto: una persona aprueba el informe de un colega, lo carga al presupuesto trimestral de marketing en nombre del equipo financiero. Eso son cinco partes en un solo hecho. Si se intenta agruparlas en pares, ya sea que deje de ser un evento atómico o se divida en varios bordes binarios que las consultas deben volver a unir. Un hiperborde conecta cualquier número de nodos a la vez, por lo que parece ser la forma fiable de almacenar tales hechos, y los equipos crean sistemas RAG con hipergrafos esperando que esta fidelidad mejore la recuperación de información.

Otro artículo verificó esa expectativa comparando el código funcional de un trabajo sobre RAG de hipergrafos en lugar de su resumen, y descubrió algo casi cómico. HyperGraphRAG, diseñado para fomentar los hiperaristas nativos, almacena todo en una base de datos de grafos regular con aristas binarias. Sus propios autores demuestran que convertir cada hiperarista en unas pocas aristas binarias alrededor de un nodo reificado para el evento no implica ninguna pérdida, por lo que cada formato puede reconstruirse con precisión a partir del otro.

Ese detalle contiene todo el razonamiento. Supongamos que un hiperborde nativo y un clúster reificado de bordes binarios tienen exactamente la misma estructura de incidencia, y que uno de ellos puede regenerar al otro sin esfuerzo. Entonces, la elección entre ellos no tiene consecuencias en el modelado y se reduce a escoger un formato de almacenamiento. Un comentarista resumió brevemente las matemáticas: las dos formas representan la misma estructura de incidencia, y el ancho del hiperárbol solo cambia en una cantidad constante cuando el número de aridades está limitado. El ancho del hiperárbol es lo que determina cuán costosa es una consulta. El recorrido por enlaces no lo hace, al igual que la cantidad de participantes incluidos en un mismo borde. Convierta su representación, despláce ese valor en una cantidad constante, mantenga cada hecho con un número limitado de participantes (cinco personas aprobando un gasto, no quinientas), y la dificultad de la consulta permanecerá igual.

Por qué esto engaña a la gente

Es un error fácil de cometer. El recuento de saltos parece algo natural, ya que más nodos entre la pregunta y la respuesta sugieren una consulta más compleja. La anchura del hiperárbol es mucho menos intuitiva: pertenece a la teoría de satisfacción de restricciones y complejidad de consultas, y difiere del recuento de saltos de maneras que no se apreciarán hasta que se analice detenidamente. Se puede añadir estructura que reduzca los saltos para una consulta de ejemplo sin afectar, o incluso perjudicar ligeramente, a la clase de complejidad a la que pertenece dicha consulta. Los ejemplos ilustrativos en un artículo pueden parecer impresionantes, pero aún así no revelan nada sobre la métrica que rige el caso general.

Antes de decidirse por un grafo simple, un grafo reificado o un almacén de hipergrafos nativo, esta comparación resulta útil.

REPRESENTATION          WHAT IT ADDS                     WHAT IT ACTUALLY CHANGES
---------------------   -------------------------------  --------------------------------
Plain binary graph       Simplest to build and query      Baseline; loses atomicity of
                         with standard graph tooling      multi-participant facts
Reified binary graph     Recovers atomicity via an        Same incidence structure as a
(event node + roles)     explicit "event" node             hyperedge; hypertree width
                                                            shifts by a constant only
Native hypergraph        Hyperedges as first-class         No reduction in query
store                    objects, arguably cleaner          complexity class over a
                         to write against                   reified graph; new storage
                                                             engine to run and maintain

Eso no hace que la estructura de grafos sea inútil para RAG. La recuperación relacional de múltiples saltos sí se beneficia de los grafos en comparación con la búsqueda vectorial plana, y nadie lo niega. La objeción se refiere al salto adicional de grafos a hipergrafos. Una vez que la prueba sustituye al argumento, ese salto genera modelos de datos de apariencia más ordenada, añade un nuevo tipo de infraestructura para operar y deja intacta la métrica que determina si las consultas son rápidas o lentas. Si la recuperación es deficiente, la solución respaldada por evidencias suele ser una construcción de grafos mejorada o una estrategia de recuperación más inteligente sobre el grafos ya creado, y no un tipo de arista más exótico.

Caso tres: cuál es realmente el trabajo de un ingeniero senior

Tanto los casos anteriores como este tratan sobre la arquitectura de recuperación. El último difiere, ya que no se trata de elegir una herramienta, sino de entender de qué está compuesto el trabajo de ingeniería senior.

Un líder técnico que dirige un equipo de cinco personas dentro de una empresa de más de mil empleados escribió que la IA no puede hacer el 95 % de su trabajo. Comienza con algo que suena a una concesión: escribir código ocupa la menor parte de su tiempo, por una amplia ventaja. Su equipo sigue el principio de “tú lo construyes, tú lo operas”, lo que implica que sus propios ingenieros están a cargo de la atención de emergencia de sus sistemas, y no un grupo de operaciones separado que pueda tratar la producción como si fuera asunto de otro. Su mañana comienza a las 8:30 con la revisión de solicitudes de integración. El código que llega, en gran parte escrito por agentes de IA, es claramente mejor que el que revisó hace dos años. No cuestiona que la IA escriba buen código; lo acepta por completo, y luego señala cuán poco cambia eso en el trabajo que realmente realiza.

Esto cuestiona una premisa común al pensar en pilas de agentes, a saber, que las capacidades determinan el ritmo de la automatización. Según esta lógica, si un modelo genera código correcto, ya no se necesita una persona para programar, y la automatización del trabajo se limita a la parte relacionada con la creación del código. El líder técnico afirma que esa ecuación nunca fue cierta, y que la IA solo hace visible el defecto. Su trabajo no consistía principalmente en programar, sino en coordinar: decidir qué construir y en qué orden, negociar el alcance con personas cuyas prioridades chocan, revisar y respaldar las decisiones tomadas por otros, encargarse de los avisos urgentes, guiar a ingenieros más jóvenes y mediar entre las solicitudes de los interesados y lo que el sistema puede soportar sin riesgos. Ninguna de estas tareas es de programación.

Ese podría ser el punto más pasado por alto este año en los debates entre agentes, más que cualquier otro indicador, porque explica por qué mejores puntuaciones en pruebas de codificación y un trabajo significativamente más sencillo no han ido de la mano para muchos ingenieros senior, ni siquiera para los usuarios diarios entusiastas. Que las puntuaciones de SWE-bench suban de un dígito a los setenta en pocos años representa un avance real y considerable. Pero eso no significa que el trabajo disminuya en un 70%, porque la creación de código nunca constituyó el 70% del trabajo, sobre todo cuando el puesto incluye turnos de respuesta inmediata, planes de desarrollo y solicitudes de integración.

Una advertencia: el tercer punto se aplica a otros entornos de forma menos clara que los dos primeros. Las afirmaciones sobre bases de datos vectoriales e hipergrafos pueden verificarse mediante pruebas de rendimiento o demostraciones. La distribución del tiempo entre tareas de coordinación y desarrollo en la semana de un ingeniero senior varía según el tamaño de la empresa, la madurez del equipo, si la carga adicional se debe a disfunciones o a actividades esenciales, y el nivel de experiencia de la persona. Un equipo de cinco personas en una empresa de mil empleados con una política de “construye y ejecuta” representa un tipo específico de trabajo y no abarca todos los roles de ingeniería. La dirección de la corrección sigue pareciendo en general acertada. Las capacidades del agente limitan cuánta parte de la tarea de escribir código puede automatizarse, y prácticamente no dicen nada sobre la parte relacionada con la coordinación, que nunca dependió de la velocidad de escritura ni de la calidad del código.

El patrón común

Si se colocan los tres casos uno al lado del otro, la lección no trata específicamente de bases de datos vectoriales, hipergrafos ni capacidades de IA. Se trata de la brecha entre donde un área creía que estaba el cuello de botella y donde realmente se encontraba.

CASE                WHERE COMPLEXITY WAS ADDED         WHERE THE REAL BOTTLENECK WAS
------------------  ----------------------------------  --------------------------------
Agent memory         Vector embeddings, similarity       Whether the model can use a
                     search, sometimes a graph layer      retrieval method it already
                     on top of that                        has deep fluency with
RAG structure         Native hyperedges, a new             The complexity class governing
                      storage engine, more                  query cost, which the fancier
                      elaborate graph modeling               structure barely touches
"How much of the      An assumption that model             Whether the job was ever
job gets automated"   capability alone predicts             mostly about the thing the
                       the automatable fraction              model is good at

Ninguna de las opciones sofisticadas está mal por existir. Las bases de datos vectoriales tienen usos reales, los hipergrafos podrían ser útiles en áreas que aún nadie ha explorado, y los agentes de IA realmente eliminan tareas tediosas del trabajo de ingeniería, algo que el líder técnico reconoce. El error fue pasar por alto la pregunta de si esa sofisticación adicional aborda el verdadero cuello de botella o solo aquel para el cual es más fácil crear una solución elaborada.

Esta costumbre se extiende mucho más allá de la ingeniería de agentes. Añadir una capa es más sencillo que preguntarse si la solución básica ya se evaluó de manera justa en comparación con ella. Una nueva abstracción se considera un progreso visible al que se puede hacer referencia y al que se le llama actualización. Verificar que grep ya cumple con la función, que la complejidad de las consultas realmente ha mejorado, o que lo que ocupaba toda la semana era precisamente lo que se había supuesto, lleva más tiempo, resulta más complicado y a veces conduce a la decisión de dejar de desarrollar.

Una lista de verificación antes de la siguiente capa

Una breve lista que vale la pena revisar en cualquier stack antes de añadir otra capa:

1. Have I benchmarked the boring baseline, not just assumed it loses?
   (full-context, grep, a plain graph, a human doing the coordination)
2. Does the new structure change the metric that actually governs cost
   or quality, or does it just look more sophisticated on a diagram?
3. Am I reaching for this because a benchmark or proof told me to,
   or because it's what the tutorials and the funded products default to?
4. If I strip this layer back out, what specifically breaks?
   If I can't name it precisely, I probably don't need the layer yet.
5. Am I solving the bottleneck I actually have, or the bottleneck
   that's most interesting to build a sophisticated solution for?

Nada de esto aboga por menos ingeniería. Aboga por invertir esfuerzos de ingeniería en identificar dónde se encuentra el cuello de botella antes de construir algo complejo que asume que ya se conoce la respuesta. Esos tres análisis no se realizaron solo por oposición. Realizaron verificaciones poco llamativas, y esas verificaciones no coincidían con la suposición inicial. Eso representa un estándar mucho más alto que una opinión contundente acompañada de un titular llamativo, y es el estándar al que debería ajustarse cualquier sistema.