La memoria de agentes guiada por esquemas parte de una idea incomoda: la mayoria de sistemas de memoria fallan no porque recuerden poco, sino porque recuerdan mal. El debate habitual gira en torno a maximizar el recall, cuando el verdadero cuello de botella es decidir que olvidar y como estructurar lo que se conserva. La propuesta consiste en definir esquemas explicitos antes de generar la memoria, acotando que tipos de entidades, campos y relaciones puede extraer el modelo. Un cambio de enfoque que, sobre el papel, parece menor pero altera la economia completa de un agente con estado.
Por que recordarlo todo es un mal objetivo
El patron dominante en muchos sistemas de memoria consiste en extraer entidades y relaciones sin restricciones desde texto libre. El resultado es un grafo de conocimiento que crece sin control y que, en la practica, acaba comportandose como un costoso vector store generico: almacena mucho, recupera con ruido y aporta poco mas que una busqueda semantica corriente. El articulo que analizamos sostiene que esa obsesion por el recall ignora el problema central, que es la estructura. Si todo entra sin filtro, nada esta realmente organizado.
La memoria de agentes hereda asi un vicio conocido en gestion de datos: confundir volumen con utilidad. Un grafo poblado por extraccion libre mezcla hechos relevantes con detalles irrelevantes, duplica entidades mal normalizadas y dificulta el versionado. Cuando llega el momento de consultar, el agente no sabe que busca porque nunca se definio que importaba. La extraccion sin esquema delega esa decision al modelo en tiempo de generacion, justo donde menos control se tiene. El planteamiento alternativo invierte el orden: primero se decide la forma, despues se rellena.
Esquemas explicitos: la analogia con function calling
La solucion propuesta es usar esquemas explicitos, por ejemplo modelos Pydantic, que definan los tipos de entidades, sus campos, las relaciones permitidas y las restricciones de cada una antes de generar nada. La logica es la misma que opera en el function calling: al acotar el espacio de salida, el modelo sabe exactamente que tiene que buscar y rellenar, en lugar de inventar una estructura sobre la marcha. La memoria de agentes deja de ser un vertedero semantico para convertirse en un repositorio tipado y predecible.
Las ventajas son concretas. Acotar la salida reduce el ruido, porque el modelo descarta lo que no encaja en el esquema. Facilita el versionado, ya que un esquema es un contrato explicito que se puede evolucionar de forma controlada. Y permite gestionar mejor la granularidad temporal y la evolucion del grafo de conocimiento: se decide que se actualiza, que se sobrescribe y que se conserva como historico. Frente a la extraccion libre, donde cada ejecucion produce un grafo ligeramente distinto, el esquema impone consistencia. Esa consistencia es la que convierte un grafo de conocimiento en algo consultable y mantenible a largo plazo.
Como pueden aplicar esto las empresas hoy
La recomendacion practica es empezar pequeno. En lugar de modelar todo el dominio de golpe, conviene definir unos pocos tipos de entidades y aristas que capturen la mayor parte de la logica del negocio, y refinar el esquema a medida que aparecen errores o necesidades reales en produccion. Para una PYME que esta montando un agente de soporte, un CRM conversacional o un asistente interno, esto evita el error mas caro: invertir semanas en un grafo de conocimiento sobreingenierizado que nadie consulta bien. Si vas a construir memoria de agentes, define primero tres o cuatro entidades clave (cliente, producto, incidencia, contrato) y sus relaciones, valida que el modelo las rellena bien y crece desde ahi.
Sobre ROI: un esquema explicito reduce coste de tokens al extraer solo lo relevante, baja el coste de mantenimiento al hacer el grafo versionable y mejora la precision de las respuestas del agente. Que evitar: no caer en la extraccion libre por comodidad inicial, y no confundir un grafo de conocimiento con una base vectorial disfrazada. Si tu sistema de memoria solo hace busqueda semantica, no necesitas un grafo; necesitas honestidad sobre que problema resuelves.
Analisis Blixel
Llevamos un par de anos viendo equipos que tratan la persistencia de un agente como un problema de almacenamiento cuando en realidad es un problema de diseno de datos de toda la vida. Aqui no hay magia nueva: hay modelado de dominio aplicado a un contexto donde un LLM hace de extractor. Y eso es buena noticia, porque significa que las disciplinas que ya conocemos (definir entidades, restricciones, contratos, versionado) siguen siendo el camino. La trampa del vector store generico disfrazado de grafo es real y la hemos visto en clientes que pagaban infraestructura compleja para obtener resultados que una busqueda semantica les daba mas barato. El consejo de empezar con pocos tipos de entidad es el mas valioso del articulo, aunque tambien el mas ignorado: hay una tentacion fuerte de modelar el dominio entero antes de tener un solo usuario. No lo hagas. El esquema correcto se descubre observando los fallos en produccion, no en una pizarra. Donde matizamos: el enfoque por esquemas anade rigidez, y para dominios muy abiertos o exploratorios esa rigidez puede limitar mas de lo que ayuda. No es una bala de plata, es una decision de ingenieria con sus contrapartidas. La clave esta en saber si tu agente opera sobre un dominio acotado (donde el esquema brilla) o sobre uno impredecible (donde quiza necesites un hibrido). Como casi todo en este campo, la respuesta depende del caso, no de la moda.
Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.
Deja una respuesta