Smriti

자체 호스팅 지식 그래프 및 AI 에이전트 메모리 계층 — 단일 바이너리, 단일 SQLite 파일, 클라우드 의존성 제로.

LLM 위키를 위한 Git. 원자적 다중 쓰기 트랜잭션, 모든 주장에 대한 출처 강제, 해시 체인이 포함된 추가 전용 이벤트 로그, 무결성 검증기 등을 갖추어 에이전트가 작성한 지식을 구조적으로 감사할 수 있습니다.

2.5µs KV 검색 · 235ns 그래프 탐색 · 0 클라우드 의존성

[screenshot: web-ui-dashboard.gif]

cargo install smriti

Smriti가 필요한 이유 (Obsidian / Zep / Mem0 / Letta / Neo4j와 비교)

* Obsidian은 트랜잭션 보장이 없는 파일 시스템입니다. Smriti의 강점은 새로운 것이 아니라 로컬 우선 Rust 런타임에서의 쓰기 시간 규율입니다.

연구 기반

모든 무결성 기능은 arXiv 논문을 인용하므로 설계를 문헌까지 추적할 수 있습니다:

• 이중 시간 엣지 및 이벤트 로그 T / T′ — Zep / Graphiti, arXiv:2501.13956

• 구조적 중첩 검증 (주장 ↔ 출처) — FACTUM, arXiv:2601.05866 및 Citation-Grounded Code Comprehension, arXiv:2512.12117

• 모순 신뢰도 점수 — MemoTime, arXiv:2510.13614 및 EvoReasoner / EvoKG, arXiv:2509.15464

• 신념 수정 및 memory_store의 충돌 정책 — AGM 공리, arXiv:2603.17244

• 그래프 + BM25 하이브리드 검색 — Graph-Based Memory Survey, arXiv:2602.05665

• 타입 지정 그래프 계층 (의미론적/시간적/인과적) — MAGMA, arXiv:2601.03236

• 제텔카스텐 스타일 에이전트 메모리 — A-MEM, arXiv:2502.12110 (NeurIPS 2025)

• 환각 근거 요구 사항 — arXiv:2510.24476

무결성 계층 (v0.2)

4개의 MCP 도구가 Smriti를 CRUD 저장소에서 불변성을 가진 위키로 변환합니다:

• wiki_transaction_submit — SQLite SAVEPOINT 내에서 원자적으로 적용되는 생성/업데이트/링크/출처 작업 배치. 모든 콘텐츠 쓰기는 claim_spans 배열을 포함해야 하며, 그렇지 않으면 거부됩니다 (기본적으로 출처 강제).

• wiki_verify — 참조 무결성 실행 + 저장된 모든 주장의 중첩 점수 재검증 + 이벤트 로그 해시 체인 탐색. 통과/실패를 반환합니다. 절대 변경하지 않습니다.

• contradictions_detect — w1·의미론적 + w2·최신성 + w3·권위 가중치 점수를 사용하여 최근 메모리에 대한 쌍별 스캔을 수행합니다. 후보는 검토 받은 편지함으로 이동하며, Smriti는 절대 자동으로 해결하지 않습니다.

• contradictions_list — 검토 받은 편지함.

CLI는 이 모든 것을 미러링합니다:

smriti verify                    # integrity sweep
smriti pending-tx                # list transactions awaiting review
smriti commit-tx <id>            # commit a pending transaction
smriti reject-tx <id> -r "..."   # reject with reason
smriti detect-contradictions     # scan for candidates
smriti contradictions            # show review inbox

Smriti란 무엇인가?

Smriti(산스크리트어: स्मृति, 기억)는 단일 SQLite 파일 위에서 지식 그래프, 전문 + 의미론적 검색 인덱스, MCP 서버를 실행하는 단일 Rust 바이너리입니다. 두 명의 사용자를 위해 설계되었습니다: AI 비서가 읽을 수 있는 개인용 제2의 뇌를 원하는 지식 노동자와 AI 에이전트를 위한 지속적이고 구조화된 메모리 계층이 필요한 개발자입니다.

메모는 타입이 지정된 위키 링크를 통해 서로 연결됩니다. 메모에 [[rel:causal|Decision X]]라고 쓰면 Smriti가 지식 그래프에 causal 방향성 엣지를 자동으로 기록합니다. 그러면 에이전트는 모든 메모를 다시 읽지 않고도 "이 결정으로 이어진 것은 무엇인가?"와 같은 질문에 답하기 위해 해당 그래프를 탐색할 수 있습니다.

빠른 시작

# Install
cargo install smriti

# Create your first notes — links and tags are extracted automatically
smriti new                    # interactive guided prompt
smriti create "Acme Corp" --content "Key client. Met via [[Sarah Chen]]." --tags client

# Search
smriti search "Acme"

# Open the web dashboard
smriti serve
# → http://localhost:3000

메모, 그래프, 검색 인덱스는 ~/.local/share/smriti/smriti.db에 저장됩니다. cp 명령어로 백업하세요.

사용 사례

클라이언트 지식 그래프

모든 클라이언트, 연락처, 참여를 연결된 메모로 추적하세요. 통화 전 Claude에게 브리핑할 때, Claude는 역사, 결정, 미해결 항목 등 전체 맥락을 읽어 들입니다. 당신이 다시 설명할 필요가 없습니다.

smriti create "Acme Corp Q2 Review" \
  --content "Next steps: [[rel:temporal|Budget approval]] by June. Owner: [[Sarah Chen]]." \
  --tags client decision

결정 로그

맥락과 결과를 포함하여 결정을 기록하세요. rel:causal 링크 타입을 사용하면 에이전트가 왜 그런 결정이 내려졌는지 추적할 수 있습니다.

smriti create "Switched to Rust" \
  --content "Replaced Python service. Reason: [[rel:causal|Memory leak in prod]]." \
  --tags decision

일일 AI 맥락

현재 집중하고 있는 내용을 KV 저장소에 저장하세요. Claude는 MCP를 통해 매 세션 시작 시 이를 읽습니다.

smriti serve   # then ask Claude: "what's my current focus?" — Smriti answers via MCP

SOP 및 플레이북

반복 가능한 프로세스를 연결된 메모로 문서화하세요. 기존 마크다운 파일을 한 번의 명령어로 가져올 수 있습니다.

smriti import ./playbooks --recursive

MCP 통합

Smriti는 stdio를 통해 MCP 서버로 실행됩니다. claude_desktop_config.json에 추가하세요:

{
  "mcpServers": {
    "smriti": {
      "command": "smriti",
      "args": ["mcp", "--db", "/path/to/smriti.db"]
    }
  }
}

claude.ai 원격 MCP의 경우, smriti serve를 시작하고 MCP 클라이언트를 http://localhost:3000/mcp로 지정하세요.

MCP 도구

전체 MCP 참조: docs/mcp.md

성능

Apple Silicon, 인메모리 SQLite에서 Criterion을 사용하여 측정되었습니다. 실행: cargo bench

Smriti vs 대안

아키텍처

src/
├── models/     Note, Link, AgentMemory, ToolLog — Serde on every type
├── storage/    SQLite + FTS5 + sqlite-vec; WAL mode; single connection pool
├── parser/     [[wiki-link]] and #tag extraction via regex; no runtime deps
├── graph/      petgraph DiGraph; lazy GraphCache (Arc<RwLock>); typed BFS
├── mcp/        JSON-RPC 2.0 over stdio; dispatches to same handlers as REST
├── web/        Axum router; localhost-only CORS; embedded React SPA
├── cli/        clap v4 derive; 11 commands; shell completions; interactive new
├── sync/       WebDAV + filesystem sync with per-device conflict tracking
└── features/   Smart link suggestions; daily digest

설계 결정

Postgres가 아닌 SQLite를 선택한 이유. 한 명 또는 소규모 팀을 위한 지식 베이스는 실행 중인 데이터베이스 서버를 필요로 해서는 안 됩니다. WAL 모드의 SQLite는 초당 수백 건의 동시 읽기를 처리하며, 이는 개인 지식 그래프에 충분합니다. 전체 데이터베이스는 하나의 파일입니다: 백업은 cp, 마이그레이션은 mv입니다.

Python이 아닌 Rust를 선택한 이유. 에이전트 메모리는 모든 도구 호출의 핵심 경로에 있습니다. Python MCP 서버는 일반적으로 직렬화 오버헤드와 GIL 경합으로 인해 왕복당 50–200ms를 추가합니다. Smriti의 Rust 구현은 2.5µs 만에 KV 항목을 검색하여 에이전트의 응답 지연 시간에 메모리 작업이 영향을 주지 않도록 합니다.

둘 중 하나가 아닌 FTS5 + 벡터를 선택한 이유. 키워드 검색(BM25)은 알려진 용어에 대해 정확하며, 벡터 검색은 사용자가 생각하지 못한 의미론적으로 관련된 콘텐츠를 불러옵니다. 어느 하나만으로는 충분하지 않습니다. Smriti는 쿼리 시점에 가중치를 부여하는 상호 순위 융합을 통해 둘을 결합합니다. 이는 arXiv:2602.05665의 연구 결과와 일치하며, 하이브리드 검색이 다중 홉 추론 작업에서 순수 벡터보다 성능이 뛰어남을 보여줍니다.

memory_store에서의 신념 수정. 에이전트가 이미 존재하는 키를 저장할 때, 단순 덮어쓰기는 기록을 삭제합니다. Smriti는 4가지 AGM 충돌 해결 정책(arXiv:2603.17244)을 구현합니다: overwrite(기본값), reject(존재 시 실패), version_and_keep(이전 값 보관), invalidate(이전 값을 대체된 것으로 표시). 대체된 값은 memory_history를 통해 쿼리할 수 있습니다.

연구 기반

기여

git clone https://github.com/smriti-AA/smriti.git
cd smriti
cargo test --all-features   # should be green
cargo bench                 # performance baseline

개발 워크플로우는 CONTRIBUTING.md를 참조하세요. good first issue 라벨이 붙은 이슈는 전체 코드베이스를 이해할 필요가 없는 독립적인 저장소 또는 CLI 변경 사항입니다.

PR을 열기 전에: cargo clippy --all-features -- -D warnings 및 cargo fmt --check를 실행하세요.

라이선스

MIT