지식과 기억, 왜 서로 다른 서랍에 담았는가

KnowledgeBase::index_all()은 디렉터리 전체를 걸어 파일마다 백링크를 지우고 처음부터 다시 채우는 완전 재색인 함수입니다. 이 크레이트 어디에도 decay 관련 코드는 없습니다 — "생애주기가 없다"는 설명 그대로, 감쇠라는 개념 자체가 존재하지 않습니다.

/// Memory entry type — 9 types derived from the SOAR/ACT-R cognitive model.

SOAR와 ACT-R은 인간의 기억을 절차 기억·의미 기억·일화 기억 등으로 나누어 설명하는 대표적인 인지 아키텍처 모델입니다. "9개 타입"이 정확히 그 아래 나열되어 있습니다.

/// Whether this type is stored globally (cross-Space).
pub fn is_global(&self) -> bool {
    matches!(self, MemoryType::UserProfile | MemoryType::Preference)
}

이 함수가 설계 의도를 정확히 담고 있습니다. 다만 정직하게 덧붙이면 — 삭제 직전 커밋 기준으로 이 함수를 실제로 호출하는 코드는 크레이트 안에 없었습니다. 워크스페이스 격리는 이 함수의 분기가 아니라, 워크스페이스마다 memory.db 파일 자체를 따로 두는 방식으로 이루어지고 있었습니다. 의도는 코드에 명시돼 있고, 배선까지 끝난 건 이 시점 다음이었을 수 있습니다.

SELECT rowid, id, -bm25(memories_fts) as score
FROM memories_fts WHERE memories_fts MATCH ?1
ORDER BY score DESC LIMIT ?2

위 공식을 직접 구현하지는 않았습니다. SQLite FTS5에 내장된 bm25() 함수를 그대로 씁니다. 이 코드가 실제로 하는 일은 CJK(한중일) 문자를 한 글자씩 쪼개 OR로 묶는 질의 전처리 — 검증된 랭킹 함수를 직접 재구현하지 않고 그대로 재사용한 선택입니다.

*scores.entry(*id).or_default() += 1.0 / (k + rank as f64 + 1.0);
// ...
let fused = reciprocal_rank_fusion(tier_results, 60.0);

공식과 상수 모두 그대로입니다. k=60이 실제 호출부에 하드코딩되어 있습니다.

[features]
default = []
sqlite-memory = ["dep:rusqlite", "dep:sqlite-vec"]

#[cfg(feature = "sqlite-memory")]
pub mod sqlite;

기본값은 꺼져 있습니다. 이 feature를 켜야 앞서 본 BM25·RRF·벡터 검색·Flash Attention 코드가 통째로 컴파일에 포함됩니다.

#[cfg(feature = "sqlite-memory")]
if let Some(ref sqlite) = self.sqlite_store {
    return sqlite.list_by_tier(tier, limit);   // 빠른 경로
}
// ... 없으면 JSON 파일을 전부 읽어 브루트포스로 처리

SQLite가 설정돼 있으면 검색·조회를 그쪽에 위임하고, 없으면 JSON 파일을 전부 읽는 느린 폴백으로 떨어집니다. 이론상의 선택지가 아니라 실제로는 거의 항상 켜져 있었습니다 — 마이그레이션 직전 oxios-kernel은 이 feature를 기본으로 켜서 넘겨주고 있었습니다(default = ["sqlite-memory"]).

max_chunk_size: 512, overlap: 64, min_chunk_size: 50

다만 이 시점 코드베이스에서는 두 함수가 하나로 합쳐 호출되지는 않고 있었습니다 — 각자 독립된 유틸리티로 존재하며, 서로 다른 상황(균일한 크기가 필요할 때 vs 문장을 살려야 할 때)에 쓰도록 설계된 두 개의 조각입니다.

pub struct TextVector { tf: HashMap<String, f64> }  // 문서빈도(IDF) 없음 — 정규화된 TF뿐

impl EmbeddingProvider for TfIdfEmbeddingProvider {
    async fn embed(&self, text: &str) -> Result<EmbeddingVector> {
        Ok(EmbeddingVector::Sparse(TextVector::from_text(text).tf_map().clone()))
    }
}

이름은 "TF-IDF"지만 실제로는 IDF가 없습니다. 코퍼스 전체에서 얼마나 흔한 단어인지는 세지 않고, 문서 안에서의 등장 비율(TF)만 계산합니다 — 흔한 단어와 희귀한 단어가 같은 무게로 취급됩니다.

let f32_vec = match vec.to_f32_dense() {
    Some(v) => v,
    None => return Ok(None),   // Sparse(TF-IDF)는 여기서 항상 None
};

TF-IDF 벡터는 to_f32_dense()가 항상 None을 돌려줍니다. 그 결과가 그대로 위로 전파돼 벡터 검색과 재순위 둘 다를 건너뛰게 만듭니다.

//! Flash Attention — block-wise attention for O(N) memory usage.
//! Triton-inspired CPU implementation...
//! Reference: "FlashAttention: Fast and Memory-Efficient
//! Exact Attention with IO-Awareness" (Dao et al., 2022)

실제로 러닝 맥스를 유지하며 블록 단위로 소프트맥스를 다시 스케일링하는 online-softmax 로직이 그대로 구현되어 있습니다 — 라이브러리 호출이 아니라 직접 짠 코드입니다. 같은 크레이트에는 전체 행렬을 그대로 계산하는 naive_attention도 있어서, 둘의 차이를 자체 테스트로 검증합니다.

let fa1 = FlashAttention::new(FlashAttentionConfig { block_size: 2, ..Default::default() });
let fa2 = FlashAttention::new(FlashAttentionConfig { block_size: 32, ..Default::default() });
// ...
assert!((v1 - v2).abs() < 1e-4, "Block size shouldn't affect output: {} vs {}", v1, v2);

블록을 잘게 쪼개든 크게 묶든 결과가 같아야 한다는 걸 테스트로 못박아뒀습니다 — "타일링해도 정답은 안 바뀐다"는 Flash Attention 논문의 핵심 주장을 이 크레이트 안에서 직접 재현·검증한 셈입니다.

let mut rng_state = 42u64;
rng_state = rng_state.wrapping_mul(6364136223846793005).wrapping_add(1442695040888963407);
let val = ((rng_state >> 33) as f32 / (1u64 << 31) as f32) - 1.0;

rand 같은 외부 크레이트를 쓰지 않고, LCG(선형 합동 생성기)를 직접 굴려 테스트용 벡터를 만듭니다. 시드가 고정돼 있어(42u64) 매번 같은 벡터가 나오고, benchmark() 메서드는 이 벡터들로 naive와 flash를 둘 다 돌려 속도차와 결과 일치 여부(5% 이내)를 런타임에 스스로 검증합니다.

let candidates = self.recall(query, max_recall * 3).await?;  // RRF 결과의 3배를 미리 뽑음
let queries = vec![query_vec];
let keys: Vec<Vec<f32>> = candidate_vecs.iter().map(|(_, v)| v.clone()).collect();

let attention_output = fa.attention(&queries, &keys, &keys);  // Key = Value로 자기 자신을 참조
let output = attention_output.first()...;

let mut scored: Vec<(MemoryEntry, f32)> = candidate_vecs.into_iter().zip(keys.iter())
    .map(|((entry, _), key_vec)| (entry, cosine_similarity(output, key_vec)))
    .collect();
scored.sort_by(|a, b| b.1.partial_cmp(&a.1)...);  // 이 코사인 유사도로 최종 정렬

설명하신 여섯 가지 핵심 동작은 정확히 다 있습니다. 실제 액션 목록은 그보다 훨씬 넓어서, 체크리스트(checklist_add/complete), 대화 로그(chat_append), 일지(journal_add), 습관 추적(habits) 같은 21개 동작이 더 있습니다 — 노트 도구로 시작했다가 개인 운영체제 수준으로 자라난 흔적입니다.

// 타입마다 시작 티어가 다름
UserProfile · Preference · Decision · Fact  → 처음부터 Hot
Knowledge · Skill · Episode · Session · Conversation → 처음부터 Warm

// 보호 등급이 감쇠 "속도"를 직접 곱함
None → ×1.0   Low → ×0.5   Medium → ×0.2   High → ×0.05   Permanent → ×0.0(불변)

보호 등급이 한 단계씩 오를 때마다 감쇠 속도가 눈에 띄게 느려지도록 설계되어 있습니다 — High가 되면 사실상 20배 느리게 잊히고, Permanent는 아예 멈춥니다.

candidates.sort_by(|a, b| {
    a.protection.cmp(&b.protection)          // 1순위: 보호 등급 낮은 것부터
        .then(a.decay_score.partial_cmp(&b.decay_score)...)  // 2순위: 더 잊힌 것부터
});
// 정렬된 순서대로 Hot 정원을 넘은 만큼 Warm으로 강등

Hot 자리에 50건보다 많이 몰리면, 보호 등급이 낮고 decay_score가 낮은(오래 안 꺼내본) 순서로 밀려납니다 — Hot/Warm/Cold는 "얼마나 중요한가"가 아니라 정원이 있는 자리다툼이고, 감쇠·보호가 그 다툼의 순위를 매겨주는 겁니다.

//! Ebbinghaus-inspired decay engine for memory importance scoring.
//! Implements a forgetting curve: R(t) = e^(-rate × t)

let effective_rate = base_rate * multiplier * protection_mult / access_boost;
let retention = (-effective_rate * hours_since_access).exp();

자주 꺼낸 기억이 덜 잊히는 이유는 access_boost가 감쇠율을 나누기 때문입니다 — 접근이 많을수록 분모가 커져 유효 감쇠율이 낮아집니다.

/// Effective importance = base_importance × (1 + ln(1 + access_count)) × decay_score.
importance * (1.0 + (1.0 + access_count as f32).ln()) * decay_score

"보존도(retention) × 접근 횟수의 로그"라는 설명과 결이 같습니다 — 다만 실제로는 로그값에 1을 더한 배수를 base_importance와 decay_score 양쪽에 곱하는 형태입니다.

모듈 문서는 정확히 "4-phase background memory consolidation"이라 못박고 있고, DreamCheckpoint는 completed_phase·cached_signals·cached_plan·cached_state를 저장하며 age.num_hours() >= 1일 때만 처음부터 다시 시작합니다. 다만 Phase 4(Prune & Index) 구현 내부에는 하이퍼볼릭 임베딩 재구성과 Flash Attention 재순위가 각각 "Phase 5", "Phase 6"이라는 이름으로, PageRank 점수 계산(감쇠 0.85, 30회 반복)은 Phase 2 안에 더 세분화되어 있습니다 — 코드 자체가 "4단계"와 "실제로는 더 잘게 나뉜 하위 단계들" 사이에서 스스로도 정확히 통일돼 있지는 않습니다.