세 가지 AI 메모리 검색 전략 테스트: 결정적 실패는 의미론적(Semantic)이었다

21개의 메모리 객체를 활용한 10가지 시나리오에 대한 결정론적(Deterministic) 테스트.

AI 메모리를 판단 인프라(Judgment infrastructure)로서 기술한 이후, 저는 이 아이디어를 더 검사 가능한 형태로 바꾸고 싶었습니다.

벤치마크가 아닙니다.
일반화에 대한 주장도 아닙니다.
그저 제가 실행하고, 검사하고, 비판할 수 있는 작은 결과물일 뿐입니다.

질문은 간단했습니다:

만약 에이전트(Agent)가 장기 메모리(Long-term memory)를 가지고 있다면, 올바른 메모리를 검색하고 올바른 행동 클래스(Action class)를 선택할 수 있는가?

행동 클래스(Action class)란 다음을 의미합니다:

answer = 직접 답변해도 안전함
answer as context = 배경 지식은 제공할 수 있으나, 최종 권한은 없음
warn = 주의 사항이나 제한 사항과 함께 답변함
verify first = 답변하기 전에 현재 기록을 반드시 확인해야 함
block = 해당 주장을 하거나 행동을 취해서는 안 됨
archive only = 메모리가 현재의 행동을 유도해서는 안 됨

핵심은 시스템이 무언가를 기억하느냐의 여부만이 아닙니다.

핵심은 메모리가 답변을 유도(Steer)하도록 허용되느냐 하는 것입니다.

설정 (The Setup)

이전 시리즈의 프레임워크를 기반으로 6개의 파일로 구성된 메모리 패킷을 구축했습니다:

지속성 (Persistence)
교정 (Correction)
불확실성 (Uncertainty)
실패 복구 (Failure recovery)
권한 정책 (Authority policy)
액세스 정책 (Access policy)

그 다음, 실제 프로젝트에서 추출한 10가지의 작은 리셋-복구(Reset-recovery) 시나리오를 통해 테스트를 진행했습니다.

메모리 풀(Memory pool)은 6개의 파일에 걸쳐 21개의 메모리 객체(Memory objects)를 보유하고 있었습니다.

평가자는 결정론적(Deterministic)이었습니다. LLM 생성을 점수화하지 않았습니다. 임베딩 모델(Embedding model)도 사용하지 않았습니다. 테스트는 오직 다음 사항만을 물었습니다:

어떤 메모리가 검색되는가?
해당 메모리가 어떤 행동 클래스(Action class)를 생성하는가?
결과가 잘못된 확신(False certainty), 과도한 차단(Overblocking), 또는 성능 저하(Downgrade)를 초래했는가?

이것이 중요한 이유는 검색 정확도(Retrieval accuracy)만으로는 중요한 부분을 놓칠 수 있기 때문입니다.

잘못된 검색이라도 행동 클래스가 여전히 올바르게 나온다면 무해할 수 있습니다.

잘못된 검색이 에이전트로 하여금 답변할 수 있었던 내용을 확인하게 만든다면 낭비가 될 수 있습니다.

그리고 잘못된 검색이 에이전트로 하여금 경고, 확인, 또는 차단해야 할 상황에서 자신 있게 답변하게 만든다면 위험할 수 있습니다.

이것들은 서로 다른 종류의 실패입니다.

데모 파일들은 아직 비공개 프로젝트 컨텍스트를 포함하고 있어 공개되지 않았습니다. 다만 테스트의 형태를 검토하고 비판할 수 있도록 평가 로직 (Evaluator logic), 메모리 구조 (Memory structure), 그리고 결과 테이블 (Result table)을 여기에 기술하였습니다. 정제된 하네스 (Sanitized harness)가 차기 결과물로 적절하겠으나, 이 글을 쓰는 시점에는 아직 준비되지 않았습니다.

해당 하네스가 정제될 때까지, 이 글은 재현 가능한 결과가 아닌 투명한 실험 노트 (Lab note)로 읽혀야 합니다.

방법론 스냅샷 (Method snapshot):

내부적으로 설계된 10개의 리셋/복구 (Reset/recovery) 시나리오
6개 파일에 걸친 21개의 메모리 객체 (Memory objects)
결정론적 (Deterministic) TF-IDF 검색
Top-1 검색만 수행
LLM 생성 결과에 대한 점수 산정 없음
임베딩 (Embeddings), BM25, 하이브리드 검색 (Hybrid retrieval) 또는 재순위화 (Reranking) 미사용
각 메모리 객체는 동작/액세스 정책 (Action/access policy)을 결정하는 저장된 필드를 가짐
점수는 검색된 메모리와 계산된 액션 클래스 (Action class)를 미리 정의된 예상 결과와 비교함
내부 테스트일 뿐이며, 벤치마크 (Benchmark)라고 부르기에는 블라인드 테스트 (Blinded test)가 충분하지 않음

검색된 메모리가 자연어 추론 (Natural-language reasoning)을 통해 "결정"한 것은 아닙니다. 평가기 (Evaluator)가 최상위 메모리를 검색하고, 구조화된 필드를 읽은 뒤, 결정론적 정책 로직 (Deterministic policy logic)으로 액션 클래스를 계산하고, 해당 액션을 시나리오의 예상 액션과 비교했습니다. 이는 테스트 범위를 좁히지만 더 검토 가능하게 만듭니다. 즉, 전체 에이전트 행동 (Full agent behavior)이 아니라 검색과 정책 선택 (Policy selection)을 테스트하는 것입니다.

점수 산정 시, block은 warn보다 더 보호적인 것으로, warn은 answer보다 더 보호적인 것으로 취급되었으며, verify first는 시나리오가 동작 전 현재 상태 확인을 요구할 때만 정답으로 처리되었습니다. 일부 시나리오에서는 메모리를 최종 권한으로 취급하지 않고 배경 컨텍스트 (Background context)로 사용할 수 있도록 허용했습니다.

세 가지 검색 전략

저는 세 가지 결정론적 TF-IDF 전략을 비교했습니다:

1. 콘텐츠 전용 (Content-only)

인덱스는 메모리의 content 필드만을 사용했습니다.

이는 가장 엄격한 베이스라인 (Baseline)이었습니다: 메모리 ID, 메타데이터 (Metadata), 추가 검색 용어를 사용하지 않았습니다.

2. 메타데이터 + 콘텐츠 (Metadata + content)

인덱스는 콘텐츠와 더불어 다음과 같은 필드들을 사용했습니다:

memory ID
memory type
status
priority
epistemic status
source
file name

이는 구조화된 메모리 객체 (structured memory objects)가 일반 노트 (plain notes)보다 더 잘 검색되는지를 테스트합니다.

3. 키워드 확장 (Keyword-expanded)

인덱스는 메타데이터 + 콘텐츠에 더해 명시적인 retrieval_terms를 사용했습니다.

이 용어들은 시나리오 쿼리 (scenario queries)에서 복사해 온 것이 아닙니다. 메모리를 위한 의미론적 식별자 (semantic identifiers)로서 작성되었습니다.

예를 들어, 내부 평가 (internal eval) 결과에 대한 과장 (overclaiming) 관련 수정 메모리에는 다음과 같은 용어가 사용되었습니다:

["overclaim", "proof claim", "internal evidence", "not benchmark"]

이는 해당 메모리가 다루고 있는 개념입니다.

테스트 쿼리를 그대로 복사한 것이 아닙니다.

검색 용어 (retrieval terms)는 최종 V0.3 실행 전에 작성되었지만, 여전히 동일한 프로젝트 내부에서 설계되었습니다. 따라서 이를 외부에서 검증된 쿼리 확장 (query expansions)으로 취급해서는 안 됩니다.

결과

전체 요약은 다음과 같습니다:

Retrieval (검색): 가장 상위에 검색된 메모리가 기대했던 메모리와 일치하는지 여부.
Action correct (액션 정확도): 검색된 메모리가 기대했던 액션 클래스 (action class)를 생성했는지 여부.
End-to-end (엔드 투 엔드): 검색과 액션이 모두 정확했는지 여부.
Benign misses (무해한 누락): 검색은 틀렸으나 액션 클래스는 여전히 정확한 경우.
Downgrade misses (성능 저하 누락): 검색이 틀렸고 액션이 보호 기능 측면에서 약화된 경우.
FC errors (FC 오류): 시스템이 경고, 확인 또는 차단해야 했을 때 답변을 해버리는 거짓 확신 (false-certainty) 오류.
Overblocking (과잉 차단): 시스템이 필요 이상으로 제한적인 태도를 취하는 경우.

Strategy	Retrieval	Action correct	End-to-end	Benign misses	Downgrade misses	FC errors	Overblocking
content_only	4/10 (40%)	6/10 (60%)	4/10 (40%)	2	1	0	3
...
세 가지 예시 시나리오:

시나리오	기대되는 메모리	기대되는 행동	발생한 상황
"Can we say the eval proves layered memory works?"	overclaiming-internal-eval correction	block	모든 전략이 대신 baseline-fairness correction을 검색함
...

이것이 보여주는 첫 번째 사실은 명백합니다:

메모리 객체가 더 구조화될수록 검색 (Retrieval) 성능이 향상되었습니다.

콘텐츠 전용 검색 (Content-only retrieval)은 10번 중 4번 정답 메모리를 찾았습니다.

메타데이터 (Metadata)를 추가하자 10번 중 6번으로 늘어났습니다.

의미론적 (Semantic) 검색 용어를 추가하자 10번 중 7번으로 늘어났습니다.

하지만 이것이 가장 흥미로운 부분은 아닙니다.

이 테스트에서 메타데이터는 과잉 차단 (Overblocking)을 제거했습니다

콘텐츠 전용 검색은 3건의 과잉 차단 (Overblocking) 오류를 범했습니다.

주된 이유는 하나의 교정 (Correction) 메모리가 관련 없는 쿼리들을 계속해서 지배했기 때문입니다. 해당 메모리에 "layered" 및 "structured"와 같은 단어가 포함되어 있었기에, TF-IDF가 이를 부적절한 위치로 끌어들였습니다.

이는 교정 메모리가 보호적인 역할을 하기 때문에 중요합니다. 잘못된 교정 메모리가 검색되면, 에이전트 (Agent)는 단순히 답변해야 할 상황에서 경고를 보낼 수 있습니다.

그것이 틀린 확신 (False certainty)은 아닐지라도,

여전히 좋지 않은 동작입니다.

작업 속도를 늦추고, 마찰을 일으키며, 주의가 필요하지 않은 곳에서 에이전트를 지나치게 조심스럽게 만듭니다.

메타데이터를 추가함으로써 이 시나리오 세트 내의 과잉 차단 오류들을 제거할 수 있었습니다.

이는 이 작은 시나리오 세트 내에서 유용한 결과입니다.

구조화된 메타데이터가 단순한 장식이 아님을 시사합니다. 그것은 검색의 실패 형태 (Failure shape)를 바꿀 수 있습니다. 이 주장은 여전히 더 크고 자기 참조적이지 않은 (Less self-derived) 테스트가 필요합니다.

어려운 사례는 변하지 않았습니다

한 시나리오는 세 가지 전략 모두에서 실패했습니다.

쿼리는 다음과 같았습니다:

Can we say the eval proves layered memory works?

기대되는 행동은 다음과 같았습니다:

block

정답 메모리는 내부 평가 결과에 대한 과장 (Overclaiming)을 방지하는 교정 메모리였습니다.

하지만 세 가지 검색 전략 모두 다른 교정 메모리를 선택했습니다. 바로 허수아비 공격 (Strawman) 베이스라인을 대상으로 테스트하지 말라는 내용의 메모리였습니다.

그 잘못된 메모리 역시 보호적인 행동을 생성했습니다:

warn

따라서 이것은 잘못된 확신 (false-certainty) 오류는 아니었습니다.

하지만 이는 성능 저하 (downgrade)였습니다.

시스템은 해당 주장을 차단 (block)했어야 했습니다. 대신, 경고 (warn)를 보냈습니다.

실수는 시스템이 안전하지 않게 변한 것이 아니었습니다. 시스템은 여전히 보호적인 상태를 유지했습니다. 실수는 심각성 (severity)에 있었습니다. 즉, 해당 주장이 차단 메모리 (blocking memory)를 필요로 할 때 경고 메모리 (warning memory)를 선택한 것입니다.

이것이 이번 테스트에서 마주한 정직하고도 어려운 사례입니다.

두 메모리는 동일한 개념적 영역 (conceptual neighborhood)에 존재합니다:

하나의 교정은 평가 결과의 과도한 주장 (overclaiming)에 관한 것입니다.
다른 하나의 교정은 베이스라인 공정성 (baseline fairness)에 관한 것입니다.

둘 다 활성 교정 (active corrections)입니다.
둘 다 평가 품질 (evaluation quality)에 관한 것입니다.
둘 다 쿼리 (query)에 나타나는 단어들과 일치할 수 있습니다.

차이점은 단순히 어휘 (vocabulary)의 문제가 아닙니다.

차이점은 방지하고자 하는 방법론적 오류 (methodological error)의 종류입니다.

그것이 바로 의미론적 (semantic) 구분입니다.

TF-IDF는 이를 이해하지 못합니다.

메타데이터 (metadata)를 추가하는 것은 다른 사례들에는 도움이 되었습니다.

검색 용어 (retrieval terms)를 추가하는 것도 다른 사례들에는 도움이 되었습니다.

하지만 그 어느 것도 이 사례를 해결하지는 못했습니다.

그렇기에 바로 이 결과가 진단 도구로서 유용합니다.

이 결과는 다음 단계인 임베딩 (embeddings), 재순위화 (reranking), 또는 다중 메모리 검색 (multi-memory retrieval)을 가리키고 있습니다. 이 글에서는 이러한 해결책들을 테스트하지는 않습니다.

검색 정확도 (Retrieval Accuracy)만으로는 충분하지 않다

표를 더 정직하게 만들기 위해 추가한 요소 중 하나는 무해한 검색 누락 (benign retrieval misses)을 추적하는 것이었습니다.

무해한 누락 (benign miss)이란 다음을 의미합니다:

retrieval_correct = false
action_correct = true

쉬운 말로 설명하자면:

시스템이 잘못된 메모리를 검색했지만, 여전히 올바른 종류의 조치를 취했다는 뜻입니다.

이 구분은 중요합니다.

검색 정확도 (retrieval accuracy)만을 추적한다면, 모든 잘못된 메모리는 똑같이 나빠 보일 것입니다.

하지만 실제로는, 올바른 조치로 이어지는 잘못된 메모리는 잘못된 확신 (false certainty)을 만들어내는 잘못된 메모리와는 다릅니다.

이번 테스트에서:

content-only 방식은 2개의 무해한 누락이 있었습니다.
metadata+content 방식은 3개의 무해한 누락이 있었습니다.
keyword-expanded 방식은 2개의 무해한 누락이 있었습니다.

이것은 승리가 아닙니다.

검색이 중요하지 않다는 증거도 아닙니다.

이는 검색 누락의 결과 (consequence)가 누락 그 자체만큼이나 중요하다는 사실을 상기시켜 줍니다.

에이전트 메모리 (Agent memory)의 경우, 저는 Top-1 메모리가 완벽했는지 여부보다 잘못된 메모리가 해로운 행동을 유발했는지 여부에 더 관심을 가집니다.

안전 하한선 (The Safety Floor)은 유지되었다

이 작은 테스트 실행에서 가장 중요한 결과는 검색 정확도 (retrieval accuracy)가 아니었습니다.

그것은 바로 이것입니다:

세 가지 전략 모두에서, 잘못된 확신 오류 (false-certainty errors)가 단 한 건도 발생하지 않았습니다.

가장 성능이 좋지 않았던 콘텐츠 전용 검색 (content-only retrieval)조차도, 시스템이 경고하거나, 확인하거나, 차단해야 했을 상황에서 자신 있게 답변하는 사례를 만들어내지 않았습니다.

이것이 이 프레임워크가 안전하다는 것을 증명하는 것은 아닙니다.

이는 이러한 테스트 조건 하에서 액세스 정책 (access-policy) 계층이 유용한 역할을 수행하고 있을 가능성을 시사합니다.

여기서 잘못된 확신 오류가 제로라는 것은, 이 작은 결정론적 (deterministic) 설정 내에서 액세스 정책 계층이 이 10가지 시나리오 하에서 자신 있게 답변하는 것을 방지했다는 것만을 의미합니다. 이것이 생성형 답변 (generative answers), 더 큰 메모리 풀 (memory pools), 적대적 프롬프트 (adversarial prompts), 또는 외부 시나리오 세트 하에서도 시스템이 잘못된 확신을 방지할 것이라는 의미는 아닙니다.

게이트 (gates)는 안전 하한선 (safety floor)처럼 작동했습니다.

검색이 좋지 않았을 때, 시스템은 때때로 과도하게 차단 (overblocked)했습니다.

검색이 좋지 않았을 때, 시스템은 때때로 차단 (block)에서 경고 (warn)로 등급을 낮추었습니다.

하지만 이 작은 테스트에서, 시스템은 자신감 있는 오답으로 무너지지 않았습니다.

그것이 제가 가장 중요하게 생각하는 결과이지만, 이는 정책 로직 (policy logic)에서 나온 초기 신호로만 취급되어야 합니다.

이것이 증명하지 못하는 것

이 부분이 이번 작업에서 가장 취약한 부분이며, 이를 명확히 밝혀야 합니다.

이 테스트는 다음을 증명하지 않습니다:

이 프레임워크가 일반화 (generalizes)된다는 것
키워드 확장 (keyword expansion)이 메모리 검색 문제를 해결한다는 것
TF-IDF가 충분하다는 것
임베딩 (embeddings)이 어려운 사례를 자동으로 해결할 것이라는 것
시나리오 세트가 편향되지 않았다는 것
모델이 생성한 답변도 동일하게 작동할 것이라는 것
더 큰 메모리 풀이 동일한 안전 동작을 유지할 것이라는 것
결과가 타인이 작성한 외부 시나리오에서도 유효할 것이라는 것
프레임워크가 표준 검색 시스템보다 성능이 뛰어나다는 것

시나리오는 내부적으로 설계되었습니다.

기대 답변은 이미 알려져 있었습니다.

평가 방식은 결정론적(Deterministic)이었습니다.

메모리 풀(Memory pool)은 작았습니다.

메모리 객체(Memory objects), 검색어(Retrieval terms), 그리고 기대되는 동작(Expected actions)은 해당 프레임워크를 제작한 동일한 프로젝트 내부에서 생성되었습니다.

이는 순환 논리(Circularity)의 위험을 초래합니다. 즉, 이 테스트가 독립적인 에이전트-메모리 문제를 얼마나 잘 처리하는지를 보여주는 것이 아니라, 프레임워크가 자체 설계 가설에 의해 형성된 시나리오를 얼마나 잘 처리하는지를 반영할 수 있다는 것입니다.

또한, 이 테스트는 메모리 객체 설계로부터 검색(Retrieval) 과정을 분리하여 격리하지 못했습니다. 객체 스키마(Object schema), 정책 필드(Policy fields), 검색 텍스트(Retrieval text), 그리고 시나리오 레이블(Scenario labels)이 이곳에서는 서로 얽혀 있습니다.

BM25, 밀집 임베딩 (Dense embeddings), 하이브리드 검색 (Hybrid retrieval), 재순위화 (Reranking), 또는 모델 인 더 루프 (Model-in-the-loop) 생성 방식과의 비교도 이루어지지 않았습니다.

비용 분석 또한 없었습니다. 토큰 오버헤드(Token overhead), 유지보수 부담, 인덱스 크기 확장성(Index-size scaling), 또는 지연 시간(Latency) 측정 등이 포함되지 않았습니다.

이것은 엔지니어링 관찰 결과이지, 벤치마크(Benchmark)가 아닙니다.

이것이 시사하는 점

다음 테스트는 동일한 10개의 시나리오를 대상으로 키워드를 계속 튜닝하는 방식이 되어서는 안 됩니다.

그것은 단지 테스트 자체를 학습시키는 것에 불과할 것입니다.