# 메모리 OS 아키텍처: 추론 역설에서 계층적 메모리 그래프로
o4-mini 같은 강력한 모델이 높은 reasoning_effort에서 구조화된 객체 추출 시 스키마 엄격성을 깨뜨립니다. Pydantic 스키마를 고수하지 않고 구조를 '개선'하려 합니다: 객체 병합, JSON 필드 수정, 개념 타입 모호화. 300개 이상의 프롬프트 테스트에서 역관계가 드러났습니다: 추론이 많아질수록 결정성이 떨어집니다.
SGR (스키마 가이드 추론)에서 response_format과 엄격한 StrictBase (extra='forbid', Optional/default 없음)를 사용해 부분적으로 해결되지만, 모델이 여전히 제약과 싸웁니다. 시맨틱 매퍼 도입으로 reasoning_effort를 줄이고, 데이터 계약, 검증, 후처리에 규율을移行했습니다.
결과:
- 토큰 비용 48% 감소;
- 추출 품질 5.2 → 7.11 상승;
- message_id로 완전 추적 가능.
검증기는 JSON 스키마를 재귀적으로 확인: additionalProperties: false, 모든 필드가 required. 이는 에이전트 메모리의 핵심 신호로, 추출 시 LLM 지능은 스키마 실행에만 사용하고 창의성은 배제합니다.
대규모 데이터셋에서 플랫 RAG의 실패와 관리형 메모리로의 전환
플랫 RAG는 데모에서는 빛나지만 Jocker(3,253 대화, 24,639 메시지) 같은 대형 코퍼스에서 무너집니다: 혈통 없음, 시간적 의미 없음, 업데이트 규칙 없음. 검색은 소스 연결 없는 유사 청크만 끌어당겨 그래프 슬러지를 만듭니다 — 세분화 부족한 수천 노드 (Jocker 리팩토링 전 26,000+).
계층 분리가 필수입니다:
- 검색: top-k 유사 청크;
- 메모리: 지식 객체, 링크, 시간 변화, 수정, 열화.
이 없으면 시스템이 복잡 쿼리에서 환각이 가득한 청크 인덱스로 전락합니다.
핵심 온톨로지: ConceptHypothesis를 일등 시민으로
핵심 온톨로지에서 타입화된 객체와 관계를 시작합니다. 느슨한 엔티티/요약 대신 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]이 객체는 증거 스팬, 관계, 신뢰도, 수정 횟수를 담습니다. 시간적 추론(이벤트, 모순)은 청크 부산물이 아닌 일등 기능입니다.
데이터 계약과 스테이징: SQLite를 유일한 진실 원천으로
데이터 계약은 파이프라인 경계에서 구조를 고정합니다. SQLite는 메시지(UUID, 텍스트, 역할, parent_id, 타임스탬프, conversation_id)의 진실 원천입니다. Neo4j 그래프: Conversation/Message/Segment/Concept/Topic 노드, HAS_MESSAGE/NEXT/CONTAINS_MESSAGE/EVIDENCE_FOR/BELONGS_TO 엣지.
핵심은 EVIDENCE_FOR: 개념이 메시지 수준 증거에 직접 연결. 연대기적 NEXT/PREVIOUS 스켈레톤으로 DB 정렬 없이 추론 가속.
스테이징 데이터베이스 (별도 SQLite)는 파이프라인 중간 상태를 완전 감사 가능하게 보관합니다.
개념 메모리 루프와 토픽 클러스터링
개념 메모리 루프: 생성/연결/정제/거부 — 가설 관리 사이클. 토픽 클러스터링은 UMAP + HDBSCAN + Optuna로 가중 링크를 통해 과압축과 개념 폭발 방지.
LongMemEval과 상태 유지 멀티에이전트 추론
LongMemEval (1억 토큰+): 4 디버그 단계, 탐색 vs 실행. 상태 유지 멀티에이전트: Planner/Scout/Synthesizer로 계층 검색.
에이전틱 가드너, 무효화, MCP
에이전틱 가드너 — 전용 그래프 유지 파이프라인. 이중 시간 사실 무효화/수리. MCP — 주권 메모리 인터페이스.
규모: 1억 6,700만 토큰, 63만 2,868 의미 단위, 240만 엣지.
주요 교훈:
- 높은 추론이 SGR 깨뜨림; 시맨틱 매퍼와 낮은 노력 사용;
- 플랫 RAG → 그래프 슬러지; 증거 스팬과 시간 온톨로지 요구;
- Pydantic StrictBase의 ConceptHypothesis — 관리 압축 기반;
- SQLite 진실 원천 + Neo4j 혈통/연대기;
- 멀티에이전트 + 가드너로 1억 토큰+ 규모.
— Editorial Team
아직 댓글이 없습니다.