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:
- 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:
- 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.
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
Aún no hay comentarios.