Por qué lo más simple supera a lo complejo en las arquitecturas actuales de agentes de IA
Este artículo analiza tres argumentos presentados en 2024 contra las bases de datos vectoriales, la memoria hipergráfica y la complejidad en la orquestación, demostrando que los sistemas más simples suelen superar a las estructuras complejas formadas por agentes.
Al leer suficiente contenido sobre agentes de IA de este año, surge un patrón antes incluso de que se presente algún argumento concreto. Casi todo lo que se propone es aditivo: se añade una capa de memoria, un grafo, un marco de orquestación o un pipeline de recuperación con tres etapas de reclasificación. También se incorporan más agentes cuya función es supervisar a aquellos que ya se han creado. Bajo casi todo esto se encuentra la misma creencia no expresada: que la complejidad equivale al progreso, y que si tu sistema no es más elaborado que hace medio año, debes estar quedándote atrás.
Un especialista en desarrollo de equipos probablemente ya haya ensamblado partes de esta misma arquitectura y podría haber justificado algunas de esas decisiones en su momento. Por lo tanto, cuando este año surgieron algunos argumentos en contra, sosteniendo que esa adición tan elaborada probablemente no valía la pena, merecieron más atención de la que suelen recibir los titulares habituales del tipo “no necesitas esto”. La mayoría de los artículos tecnológicos contrarios no son más que promoción al revés, igualmente seguros pero igualmente carentes de pruebas. Estos tres argumentos fueron diferentes: cada uno se basa en algo verificable, ya sea una puntuación de referencia, un argumento estructural o una descripción clara de cómo se desarrolla realmente el trabajo día a día. Ese es el estándar que debe aplicarse aquí, y también será el estándar al que se atendrá el resto de este texto.
A continuación se presentan tres ejemplos. En cada uno de ellos, se recurrió a más arquitectura cuando el problema real era algo mucho menos complejo.
Caso uno: es probable que su agente no necesite una base de datos vectorial
Decidir utilizar una memoria para agentes de envíos respaldada por un almacén vectorial es una decisión que suele tomarse en segundos. Alguien plantea el requisito de “que el agente recuerde cosas entre sesiones”, y la respuesta automática es: incrustar los datos, almacenarlos y recuperarlos por similitud. Este es el enfoque predeterminado no porque alguien lo haya probado frente a alternativas, sino porque todos los tutoriales lo hacen de esa manera.
Esa suposición es exactamente lo que se puso a prueba en un artículo de este año, “Your AI Agent Doesn’t Need a Vector Database”, de Anubhav. El resultado digno de recordar proviene del benchmark LoCoMo: un punto de referencia formado únicamente por un directorio de archivos de texto plano buscados con grep superó a varios productos de memoria desarrollados específicamente y financiados, en el mismo benchmark contra el cual se midieron esos productos. No se trató de una comparación manipulada creada para obtener ventaja. Los sistemas más sofisticados, algunos de los cuales combinaban embeddings, búsquedas de similitud e incluso memoria estructurada en forma de grafo, siguieron perdiendo frente a algo que se podía crear en una sola tarde.
Una vez que se comprende ese resultado, la explicación deja de parecer sorprendente. La similitud vectorial es una técnica de recuperación, no una técnica de razonamiento. Destaca en mostrar texto semánticamente cercano a una consulta. Es deficiente en las tareas que la memoria realmente requiere, como reconocer que un hecho registrado hace tres semanas ya ha sido reemplazado por la actualización de ayer, o que dos entradas almacenadas se contradicen abiertamente y una debe tener prioridad. Un índice vectorial no tiene un sentido del tiempo incorporado ni concepto de corrección. Simplemente devuelve lo que está más cerca en el espacio de embeddings y deja que el modelo averigüe por sí mismo por qué dos de las cinco coincidencias principales difieren.
Existe una segunda discrepancia, que tiene menos que ver con la capacidad bruta y más con la familiaridad. Los modelos de lenguaje han absorbido enormes cantidades de datos de entrenamiento centrados en el trabajo con archivos: leerlos, buscar información en ellos, editarlos, listar directorios y rastrear cadenas de importación. Eso no es un efecto secundario, sino que está muy cerca del núcleo de lo que constituye una gran parte de su corpus de entrenamiento. Un bucle basado en grep y la lectura de archivos aprovecha directamente esa fluidez ya existente. Por el contrario, la interfaz de consulta de una base de datos vectorial es una herramienta que el modelo debe aprender a utilizar de manera efectiva dentro de su contexto específico, sin la profundidad en el manejo de archivos que ya posee. Al final, se sustituye una habilidad que el modelo ya tiene por otra que debe adquirir sobre la marcha, y se paga un precio en términos de latencia en el proceso de incrustación y recuperación por esa sustitución.
Así es como podría enmarcarse aproximadamente la decisión ahora, después de razonarla realmente en lugar de recurrir a la costumbre:
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
El ciclo de escritura, gestión y lectura descrito en ese texto merece ser concretado, ya que “simplemente usa archivos” puede sonar como una solución superficial hasta que se muestra como código funcional. He aquí una versión que podría ejecutarse hoy mismo, sin necesidad de ningún 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")]
No se dice que las bases de datos vectoriales no tengan lugar en el mundo. El punto es más específico: no las utilice antes de medir realmente hasta dónde puede llegar con la solución básica, que no es tan atractiva. Pruebe primero el carga de contexto completo y el uso del sistema de archivos junto con comandos como grep. Solo opte por un producto de memoria de pago si supera significativamente a esa solución básica, tanto en términos de rendimiento como de la capacidad de depuración que pierde. La mayoría de las cargas de trabajo relacionadas con la memoria de los agentes nunca alcanzan ese nivel.
Caso dos: los hipergrafos tampoco salvarán su sistema RAG
Si las bases de datos vectoriales eran la opción automática del año pasado, el RAG basado en grafos se ha convertido en la del año actual, y los hipergrafos representan el siguiente paso cuando un equipo decide que un simple grafo de conocimiento aún no es lo suficientemente expresivo. A primera vista, la idea parece razonable: un arista ordinaria de grafo conecta exactamente dos nodos, pero muchos hechos del mundo real involucran a más de dos participantes al mismo tiempo. Considere un escenario en el que un empleado aprueba los gastos de viaje de un colega en nombre de todo un departamento durante un ciclo presupuestario específico; ese único hecho involucra a cinco participantes distintos. Si se intenta representarlo mediante aristas entre pares, solo queda una opción: o bien se pierde la noción de que se trató de un evento único, o bien se divide en varias aristas binarias que luego deben volver a unirse en el momento de la consulta. Un hiperarista, capaz de conectar cualquier número de nodos simultáneamente, parece ser la solución.
Una forma más fiel de modelarlo. Por eso los equipos crean sistemas RAG de hipergrafos con la convicción de que esta mayor fidelidad se traducirá en una mejor recuperación de información.Un artículo publicado este año por un escritor llamado Dustin, titulado “Los hipergrafos no mejorarán tu sistema RAG. Aquí está lo que realmente cambian”, puso a prueba esa creencia frente a la implementación real detrás de un artículo sobre RAG con hipergrafos, y no solo su resumen. Lo que salió a la luz fue casi cómico: HyperGraphRAG, un sistema cuya premisa fundamental es que los hiperaristas nativos son importantes, en realidad almacena todo internamente en una base de datos de grafos estándar utilizando aristas binarias comunes. Aún más revelador es que los propios autores del artículo demuestran que esta traducción —dividir cada hiperarista en un pequeño grupo de aristas binarias alrededor de un nodo que representa el evento— no elimina nada. Nada de la estructura subyacente se pierde en la conversión. La supuesta representación más honesta con hipergrafos y la versión “aburrida” con aristas binarias pueden reconstruirse una a partir de la otra con total precisión.
ly.
Eso no es una simple nota al pie sobre la implementación: socava todo el argumento. Si un hiperarco nativo y un clúster de arcos binarios reificados en roles codifican la misma estructura de incidencia, y cada uno puede reconstruirse trivialmente a partir del otro, entonces elegir uno en lugar del otro no constituye realmente una elección de modelado con consecuencias posteriores. Es simplemente una decisión sobre el formato de almacenamiento. Un comentarista de ese artículo, Felix Anderson, expuso las matemáticas relevantes de la forma más clara posible: un hiperarco y un grafo binario reificado en roles describen la misma estructura de incidencia, y el ancho del hipertree solo varía por un factor constante cuando la aridad está limitada. El ancho del hipertree es la medida real de complejidad que determina cuán costoso es evaluar una consulta, no el número de saltos ni cuántos participantes se agolpan en un arco. Si cambiar la representación solo modifica ese número en una cantidad constante, y cada hecho involu
Si se considera un número limitado de participantes (lo cual es cierto en casi todos los hechos del mundo real: un puñado de personas en una cadena de aprobación, no miles), entonces todo el esfuerzo de ingeniería invertido en el conmutador no sirve para nada en la dimensión que realmente determina el costo de las consultas.Vale la pena ser justos al explicar por qué es fácil caer en este error de concepción. El recorrido entre nodos resulta intuitivo: más nodos intermedios entre una pregunta y su respuesta parecen indicar que la consulta es más compleja. En cambio, el ancho del hiperárbol no lo es en absoluto; proviene de la teoría de satisfacción de restricciones y de la complejidad de las consultas, y puede variar de maneras que el recorrido entre nodos nunca señala, a menos que alguien lo verifique específicamente. Es totalmente posible añadir complejidad estructural que reduzca el recorrido entre nodos en una consulta de ejemplo cuidadosamente seleccionada, sin afectar la clase de complejidad subyacente, o incluso empeorándola ligeramente. Los ejemplos presentados en un artículo pueden parecer impresionantes, pero aún así no ofrecen información significativa sobre el caso general.
Aquí está la comparación lado a lado que merece ser revisada antes de elegir entre un grafo simple, un grafo reificado o un almacén de hipergrafos nativo:
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
Nada de esto demuestra que la estructura gráfica sea inútil para RAG. La recuperación relacional de múltiples pasos realmente se beneficia de la estructura gráfica en comparación con la búsqueda vectorial plana; eso está fuera de duda. Lo que sí está en discusión es el salto adicional desde un grafo ordinario hasta un hipergrafo. Y una vez que se examina más allá de las promesas y se analiza la prueba real, la conclusión honesta es que este salto proporciona un modelo de datos que parece más limpio, pero requiere una nueva categoría de infraestructura para funcionar, todo sin afectar al factor que determina si las consultas se ejecutan rápido o lento. Si el problema es la calidad de la recuperación, la solución respaldada por evidencia concreta suele ser un proceso de construcción de grafos mejorado o una estrategia de recuperación más inteligente basada en el grafo ya existente, y no un tipo de arista más exótico.
Caso tres: el verdadero cuello de botella nunca fue el código en sí
Los dos primeros argumentos versaban sobre la arquitectura de recuperación, un tema que se encuentra claramente en un ámbito conocido. Este tercero es diferente, ya que no se trata de elegir la herramienta adecuada, sino de comprender en qué consiste realmente el trabajo de un ingeniero senior, y resultó ser más relevante de lo esperado.
Patrick Koss, líder técnico que dirige un equipo de cinco ingenieros en una empresa con más de mil empleados, tituló su artículo “La IA no puede hacer el 95 % de mi trabajo (y soy ingeniero de software)”. La afirmación inicial suena casi como una admisión de derrota antes de convertirse en un argumento: escribir código es solo una pequeña parte, por mucho, de cómo pasa su tiempo. Su equipo sigue un modelo de “tú lo construyes, tú lo operas”, lo que significa que la responsabilidad de atender los sistemas que gestionan recae en sus propios ingenieros y no en un grupo de operaciones separado que trataría los problemas de producción como si fueran de otra persona. Sus mañanas comienzan alrededor de las 8:30 con la revisión de solicitudes de integración, y el código que aparece en esas solicitudes —en gran parte escrito por agentes de IA que se encargan de la mayor parte de la redacción— es notablemente mejor que el que revisaba hace un par de años. Él no está cuestionando si la IA puede generar código de calidad para
Día. Él admite plenamente ese punto y luego señala que eso apenas cambia lo que su trabajo realmente le exige.Ese es el detalle en el que vale la pena detenerse, porque cuestiona una suposición arraigada en gran parte del razonamiento relacionado con las plataformas de agentes, incluidos muchos argumentos presentados en este ámbito: la idea de que las capacidades determinan la automatización. La lógica habitual es que, una vez que un modelo puede escribir código correcto, la creación de código deja de ser trabajo humano, por lo que la parte del “trabajo” que se automatiza debería coincidir con la parte del trabajo que antes involucraba escribir código. La contrapropuesta de Koss es que esta ecuación ya estaba rota mucho antes de que la IA apareciera; la IA simplemente hace que el error sea más visible. El papel de un líder técnico nunca fue principalmente producir código, sino siempre coordinar: decidir qué se desarrollará y en qué secuencia, negociar el alcance con las partes interesadas que tienen prioridades conflictivas, revisar y respaldar las decisiones técnicas de otros, encargarse de los avisos urgentes y orientar a quienes tienen menos experiencia.
Trabajar con ingenieros y traducir entre lo que solicita un interesado y lo que el sistema puede soportar de manera realista sin colapsar. Nada de eso es trabajo de programación disfrazado. Se trata de tareas organizativas e interpersonales que, por casualidad, generan código en el proceso, y además un resultado altamente automatizable. Todo esto está incluido dentro de un conjunto mucho más amplio de responsabilidades que se resisten a la automatización precisamente porque no tienen como objetivo producir artefactos, sino lograr acuerdos, equilibrios y responsabilidad entre las personas.Puede que esta sea la observación más subestimada en las conversaciones de este año sobre los agentes, más significativa que cualquier número de referencia individual, porque explica por qué “el modelo mejoró drásticamente en la programación” y “mi trabajo se volvió drásticamente más fácil” no han avanzado al mismo ritmo para muchos ingenieros senior, incluso aquellos que utilizan activamente estas herramientas y obtienen un valor real de ellas. Ver cómo las puntuaciones de SWE-bench pasan de unos pocos dígitos a los setenta en un par de años representa un salto real y sustancial en las capacidades. Pero ese salto no se traduce automáticamente en un trabajo que sea un 70 por ciento más ligero, porque el trabajo nunca fue en un 70 por ciento dedicado a la producción de código desde un principio, especialmente cuando ya se es lo suficientemente senior como para que el puesto también incluya la responsabilidad de la rotación de guardias y del plan estratégico, no solo las solicitudes de integración.
La advertencia honesta es que este argumento no se generaliza con tanta claridad como los dos primeros. Las afirmaciones sobre bases de datos vectoriales e hipergrafos son lo suficientemente técnicas como para poder verificarlas mediante pruebas de referencia o demostraciones, y esa verificación es exactamente lo que ocurrió anteriormente. La cuestión de cuánto del trabajo de un ingeniero senior consiste en coordinación y cuánto en programación variará según el tamaño de la empresa, la madurez del equipo, cuánto de la carga administrativa es realmente necesaria frente a ser simplemente disfuncional, y cuán experimentado sea el individuo. Un equipo de cinco personas dentro de una empresa de mil empleados que sigue el principio “tú lo construyes, tú lo operas” representa un tipo específico de puesto de trabajo, no un sustituto de todos los roles de ingeniería. Aun así, la corrección subyacente parece ser válida en general: las capacidades del agente establecen un límite sobre cuánta parte de la tarea de escribir código podría teóricamente automatizarse, pero eso indica...
Casi no se sabe cuánto puede abarcar la parte de coordinación, ya que esa parte nunca estuvo limitada por la velocidad de escritura ni por la calidad del código desde un principio.El hilo conductor
Si se comparan estos tres casos, la verdadera lección no tiene nada que ver específicamente con bases de datos vectoriales, hipergrafos o las capacidades de los agentes. Se trata de una discrepancia entre el lugar donde cada área suponía que residía la dificultad y el lugar donde en realidad 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 más complejas es inherentemente una mala idea. Las bases de datos vectoriales resuelven problemas reales en el contexto adecuado, los hipergrafos pueden resultar útiles en situaciones no abordadas aquí, y los agentes de IA realmente eliminan tareas repetitivas en trabajos de ingeniería reales, algo que el investigador detrás del tercer caso señala explícitamente. El error no fue buscar la sofisticación, sino omitir el paso de verificar que dicha sofisticación vaya dirigida a la restricción real, y no a aquella que resulta ser la más conveniente para crear una solución impresionante.
Esa costumbre se manifiesta también mucho más allá del área de ingeniería de agentes. Añadir otra capa es casi siempre más fácil que detenerse a preguntarse si la base simple y poco llamativa ya fue probada adecuadamente en comparación con ella. Una nueva abstracción se percibe como un progreso visible, algo a lo que se puede hacer referencia y al que se le puede llamar una actualización. Verificar si grep ya cubre el caso, o si la complejidad de la consulta realmente ha mejorado, o si lo que ocupaba toda tu semana era realmente lo que creías que era: ese trabajo es más lento y mucho menos satisfactorio, y puede terminar con la conclusión de que deberías dejar de desarrollar en lugar de continuar.
Aquí hay una versión condensada de la lista de verificación que vale la pena aplicar a cualquier stack antes de añadirle 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 realizar menos trabajo de ingeniería en general. Más bien, sugiere dirigir los esfuerzos de ingeniería hacia la identificación real del cuello de botella antes de crear una solución compleja que presuma ya conocer la respuesta. Los tres ejemplos presentados aquí no fueron elegidos por su carácter controvertido. Recibieron ese calificativo porque alguien realizó el trabajo poco glamoroso de verificar, y los resultados no coincidieron con la suposición inicial. Eso representa un estándar considerablemente más alto que un titular llamativo acompañado de una opinión contundente, y es el estándar que merece aplicarse a su propio entorno tecnológico en el futuro.
Lecturas relacionadas
- Comprendiendo los agentes de IA: objetivos, herramientas, memoria y el bucle del agente — Una explicación sencilla para principiantes sobre cómo difieren los agentes de IA de los chatbots, abordando sus componentes esenciales, el bucle de toma de decisiones, los niveles de autonomía y casos de uso en el mundo real.
- Comprendiendo la memoria de IA: contexto, embeddings, RAG y pesos del modelo explicados — Este artículo explica cómo los sistemas de IA realmente almacenan información, abarcando ventanas de contexto, embeddings, bases de datos vectoriales, RAG y parámetros del modelo.