Volver al inicio

Memory OS: paradoja de razonamiento y SGR en memoria de agente

El artículo analiza la arquitectura de Memory OS: paradoja de razonamiento en extracción, transición de flat RAG a ontología ConceptHypothesis, contrato de datos en SQLite/Neo4j. Escala — 106.7 millones de tokens, 2.4 millones de aristas. Soluciones clave para memoria de agente.

Paradoja de o4-mini: cómo el razonamiento rompe la extracción en Memory OS
Advertisement 728x90

Arquitectura de Memory OS: De paradojas de razonamiento a grafos de memoria jerárquicos

Modelos potentes como o4-mini con alto reasoning_effort rompen la rigidez de los esquemas durante la extracción de objetos estructurados. En lugar de ceñirse a los esquemas Pydantic, el modelo comienza a "mejorar" la estructura: fusiona objetos, ajusta campos JSON y difumina tipos de conceptos. Pruebas con más de 300 prompts revelaron una relación inversa: más razonamiento implica menos determinismo.

SGR (Razonamiento guiado por esquemas) con response_format y StrictBase estricto (extra='forbid', sin Optional/default) resuelve el problema parcialmente, pero el modelo aún lucha contra las restricciones. Introducir un Mapeador semántico redujo reasoning_effort al trasladar la disciplina a contratos de datos, validación y post-procesamiento.

Resultados:

Google AdInline article slot
  • Costos en tokens bajaron un 48%;
  • Calidad de extracción subió de 5.2 a 7.11;
  • Trazabilidad completa vía message_id.

El validador verifica recursivamente el esquema JSON: additionalProperties: false, todos los campos en required. Esto actúa como señal central para la memoria del agente: la inteligencia del LLM durante la extracción es para ejecutar el esquema, no para crear.

Por qué el RAG plano falla en datasets grandes y el cambio a memoria gestionada

El RAG plano brilla en demos, pero se desmorona en corpus grandes como Jocker (3.253 conversaciones, 24.639 mensajes): sin linaje, semántica temporal ni reglas de actualización. La recuperación extrae fragmentos similares sin vínculos a fuentes, generando Lodo de grafos — miles de nodos sin granularidad (más de 26.000 en Jocker pre-refactor).

La separación de capas es esencial:

Google AdInline article slot
  • Recuperación: top-k fragmentos similares;
  • Memoria: objetos de conocimiento, enlaces, cambios temporales, revisiones, degradación.

Sin esto, el sistema se convierte en un índice de fragmentos plagado de alucinaciones en consultas complejas.

Ontología central: ConceptHypothesis como ciudadano de primera clase

Partimos de una ontología central con objetos tipados y relaciones. Descartamos entidades/summaries sueltas por ConceptHypothesis:

from pydantic import BaseModel, ConfigDict, Field
from typing import List, Literal, Optional
from datetime import datetime

class StrictBase(BaseModel):
    model_config = ConfigDict(extra="forbid")

class EvidenceSpan(StrictBase):
    source_id: str
    message_id: str
    text: str
    confidence: float

class ConceptRelation(StrictBase):
    target_id: str
    relation: Literal["causes", "conflicts_with", "supports", "instance_of", "enables"]
    confidence: float

class ConceptHypothesis(StrictBase):
    concept_id: str
    title: str
    type: Literal["behavioral_pattern", "project", "event", "tension", "goal", "belief", "entity"]
    description: str
    state: Literal["active", "weak", "merged", "split", "archived"]
    confidence: float
    aliases: List[str]
    evidence_spans: List[EvidenceSpan]
    relations: List[ConceptRelation]
    revision_count: int
    first_seen: Optional[datetime]
    last_seen: Optional[datetime]

Este objeto porta spans de evidencia, relaciones, confianza y revision_count. El razonamiento temporal (eventos, contradicciones) es de primera clase, no un subproducto de fragmentos.

Google AdInline article slot

Contratos de datos y staging: SQLite como única fuente de verdad

Los contratos de datos fijan la estructura en los límites del pipeline. SQLite actúa como fuente de verdad para mensajes (UUID, texto, rol, parent_id, timestamp, conversation_id). Grafo Neo4j: nodos como Conversation/Message/Segment/Concept/Topic, aristas como HAS_MESSAGE/NEXT/CONTAINS_MESSAGE/EVIDENCE_FOR/BELONGS_TO.

La clave es EVIDENCE_FOR: conceptos vinculados directamente a evidencia a nivel de mensaje. El esqueleto cronológico NEXT/PREVIOUS acelera la inferencia sin ordenar en base de datos.

Base de datos de staging (SQLite separada) almacena estados intermedios del pipeline para auditoría completa.

Bucle de memoria conceptual y clustering de temas

Bucle de memoria conceptual: crear/adjuntar/refinar/rechazar — el ciclo de gestión de hipótesis. Clustering de temas vía UMAP + HDBSCAN + Optuna para enlaces ponderados evita sobrecompresión y explosión de conceptos.

LongMemEval e inferencia multiagente con estado

LongMemEval (más de 100M tokens): 4 fases de depuración, Exploration vs Execution. Multiagente con estado: Planner/Scout/Synthesizer para recuperación jerárquica.

Jardinero agentico, invalidación y MCP

Jardinero agentico — pipeline dedicado de mantenimiento de grafos. Invalidación/reparación para hechos bitemporales. MCP — interfaz de memoria soberana.

Escala: 106.7M tokens, 632.868 unidades semánticas, 2.4M aristas.

Lecciones clave:

  • Alto razonamiento rompe SGR; usa Mapeador semántico y bajo esfuerzo;
  • RAG plano → Lodo de grafos; exige spans de evidencia y ontología temporal;
  • ConceptHypothesis con Pydantic StrictBase — base para compresión gestionada;
  • SQLite como fuente de verdad + Neo4j para linaje y cronología;
  • Multiagente + Jardinero para escala de 100M+ tokens.

— Editorial Team

Advertisement 728x90

Leer después