사례 연구: cwkPippa의 기억 구성

네 개의 계층

JSONL 기준 데이터 — 모든 채팅 대화와 도구 호출은 아빠에게 보이기 전에 ~/pippa-db/sessions/{conversation_id}.jsonl에 기록돼. 시스템의 기준 데이터이며 저장 상태에서는 Fernet으로 암호화해.
SQLite 캐시 — 대화, brain, 메시지 순서를 빠르게 찾는 인덱스야. JSONL에서 파생하므로 지운 뒤 다시 만들 수 있어.
ChromaDB 임베딩 — Obsidian vault와 대화 기록을 의미로 검색해. Ollama를 통해 BGE-M3(1024차원, 다국어, 로컬)로 임베딩해.
Obsidian vault — 피파가 정제한 장기 정체성과 교훈이 들어 있어. 채팅의 내용을 영구 기록으로 올릴 가치가 있을 때 피파가 아빠의 승인을 받아 직접 정리해.

검색 계약

피파가 답할 때 문맥 엔진은 먼저 vault의 진입점인 instructions.md를 읽고, 이어서 정체성과 core 파일, 필요할 때만 여는 인덱스 파일을 조립해. 대화 기억과 도구 출력은 SQLite 인덱스를 거쳐 JSONL에서 가져와. vault 위의 벡터 검색은 '내가 X에 관해 어디에 썼더라?' 같은 드문 쿼리에 사용해.

검색 방식이 두 가지인 이유

vault는 큰 인덱스 파일만 필요할 때 열고 나머지는 전체를 읽어. 피파가 이미 구조를 아니 의미 유사도 검색이 필요하지 않아. 반면 대화 기록은 모두 읽기에는 너무 크므로 벡터 검색이 제 역할을 해.

여기서 얻을 일반 원칙

JSONL 기준 데이터와 파생 인덱스의 조합은 데이터베이스 선택이 바뀌어도 살아남는 내구성 패턴이야.
정체성에 중요한 내용은 자동 정제보다 사람이 직접 다듬은 의미 기억이 더 나아.
전체 읽기와 벡터 검색은 각 데이터의 모양에 맞을 때 한 시스템 안에서 자연스럽게 공존할 수 있어.

Code

cwkPippa 문맥 엔진의 로드 순서·python

def load_context() -> str:
    parts = [
        read('instructions.md'),     # entry catalog
        read('Pippa.md'),            # 정체성
    ]
    for path in sorted(glob('core/*.md')):
        parts.append(read(path))
    for path in sorted(glob('index/*.md')):
        size = stat(path).st_size
        if size <= 10_000:
            parts.append(read(path))
        else:
            parts.append(f'-- on-demand: {path} ({size} bytes) — use the Read tool when needed')
    return '\n\n'.join(parts)

보여 주기 전에 JSONL 기준 데이터에 추가하기·python

def write_event(conversation_id: str, event: dict):
    path = SESSIONS_DIR / f'{conversation_id}.jsonl'
    with path.open('a') as f:
        f.write(json.dumps(event) + '\n')   # SSE 청크가 UI 도달 전에 durable

네 개의 계층

검색 계약

검색 방식이 두 가지인 이유

여기서 얻을 일반 원칙

Code

External links

Exercise

Progress

댓글 0