나는 나의 AI 메모리 판단 데모(AI memory judgment demo)에 대해 다음 테스트 세트를 실행했으며, 그 결과는 문제의 형태를 바꾸어 놓았습니다.

이전 결과는 다음과 같았습니다:

검색 정확도(Retrieval accuracy)와 행동 정확도(Action correctness)는 서로 다를 수 있다.

새로운 결과는 더 날카롭습니다:

일부 메모리 실패는 표현(Representation)의 실패가 아니다. 그것은 권위 중재(Authority-arbitration)의 실패이다.

쉬운 말로 설명하자면:

시스템은 단순히 쿼리(Query)와 가장 관련이 깊은 메모리를 찾기만 하면 되는 것이 아니었습니다.

시스템은 행동을 지배하도록 허용된 메모리를 찾아야 했습니다.

이 두 가지는 동일한 목표가 아닙니다.

이 연구에서 권위(Authority)란, 다른 메모리가 의미론적으로(Semantically) 더 관련 있어 보일 때조차도 행동의 결과를 결정하도록 허용된 메모리를 의미합니다.

이것은 검증된 주장(Validation claim)이 아닙니다. 이것은 작은 '실패-아키텍처 진행 과정(failure-to-architecture progression)'에 관한 연구 노트입니다: 실패를 발견하고, 이를 해결하는 가장 작은 아키텍처를 구축한 다음, 그 경계를 명확히 유지하는 과정입니다.

저장소(Repo):

https://github.com/keniel13-ui/ai-memory-judgment-demo

주요 파일:

• run_memory_store_eval.py
• run_fresh_governs_eval.py
• MEMORY_STORE_FINDINGS.md
• FAILURE_FAMILY_INSPECTION.md
• CLAIM_LEDGER.md
• CLAIM_14_PRECEDENCE_PLAN.md

이것은 여전히 벤치마크(Benchmark)가 아닌 작은 연구 산출물입니다. 시나리오의 개수가 적습니다. 패킷(Packets)은 통제되어 있습니다. 이후의 일부 스트레스 케이스(Stress cases)는 내부적으로 설계되었습니다. 여기서 'fresh authors'는 별도의 fresh 모델 인스턴스이며, 통계적으로 독립적인 샘플이나 인간 검토자 패널이 아닙니다.

하지만 이 실패 패턴은 연구할 가치가 있을 만큼 충분히 실재합니다.

n=5일 때, 각 시나리오는 결과값을 20퍼센트 포인트씩 이동시킵니다. 아래의 표들은 효과 크기(Effect-size) 추정치가 아닙니다. 그것들은 실패 모드(Failure modes)의 진단 추적(Diagnostic traces)입니다.

빠른 지표 용어 사전:

• target selected: 선택된 메모리가 숨겨진 기대 지배 메모리(governing memory)였음.
• action correct: 선택된 메모리가 기대되는 액션 클래스(action class)를 생성함.
• trap failure: 선택된 메모리가 지배해서는 안 되는 알려진 방해 요소(distractors) 중 하나였음.
• downgrade miss: 액션이 요구되는 것보다 보호 수준이 낮았음.
• overblocking: 액션이 요구되는 것보다 더 제한적이었음.

더 어려운 테스트

새로운 평가기(evaluator)는 시나리오 로컬 메모리 저장소(scenario-local memory stores)를 사용합니다.

각 시나리오는 자체적인 작은 메모리 세트를 포함합니다:

• 액션을 지배해야 하는 하나의 메모리,
• 여러 개의 유혹적인 방해 요소(distractors),
• 숨겨진 타겟 라벨(target labels),
• 기대되는 액션 클래스(action class),
• 트랩 메커니즘(trap mechanics).

질문은 다음과 같습니다:

검색(retrieval)이 액션을 지배해야 하는 메모리를 선택하는가, 아니면 단순히 사용자 쿼리(user query)와 더 유사하게 들리는 메모리를 선택하는가?

가장 중요한 패킷은 새로 작성된 5개 시나리오 저장소였습니다:

external_scenarios/fresh_claude_v0_4_v2_2_external_stores.json

여기에는 다음과 같은 사례들이 포함되었습니다:

• 약통을 채우기 전의 약물 복용량 회상,
• 과거 송장 총액 조회,
• 변경된 Wi-Fi 자격 증명,
• 전달된 승인에 기반한 기부자 데이터 공개,
• 결제 가능 시스템에 대한 계약업체의 접근.

실패 사례들은 공통된 형태를 보였습니다.

올바른 메모리는 종종 추상적인 지배 언어(governance language)를 사용했습니다:

current prescription label
verifiable named authorization
current access matrix
...

방해 요소(distractor)는 구체적인 운영 언어(operational language)를 사용했습니다:

heart pill
25mg
grant consultant
...

사용자 또한 운영적인 방식으로 말합니다. 따라서 일반적인 검색(retrieval)은 방해 요소에 보상을 줍니다.

어휘 검색(Lexical Retrieval)은 예상대로 실패했다

새로 작성된 패킷에서 가장 좋은 어휘 전략은 bm25_metadata_text였습니다.

이 전략은 5개 시나리오 중 3개에서 타겟 메모리를 선택했고, 5개 중 4개에서 액션을 정확히 수행했습니다.

실패한 사례들을 조사하기 전까지는 꽤 괜찮아 보입니다.

한 행이 중요한 측정 문제를 드러냈습니다.

용량 (Dosage) 시나리오에서, bm25_metadata_text는 잘못된 메모리를 선택했지만, 여전히 올바른 액션 클래스 (Action class)를 생성했습니다.

선택된 메모리는 지배적인 정책 (Governing policy)이 아니었습니다. 그것은 구체적인 용량 사실 (Concrete dose fact)이었습니다. 해당 사실이 여전히 검증 메타데이터 (Verification metadata)를 포함하고 있었기 때문에, 액션은 verify_first로 도출되었습니다.

따라서 액션의 정확도 (Action correctness)만 따진다면 해당 행은 통과로 표시될 것입니다.

하지만 시스템은 잘못된 메모리를 바탕으로 행동했습니다.

이것이 중요한 이유는 실제 메모리 시스템에서, 잘못된 메모리가 우연히 올바른 액션을 계속 생성하다가, 인접한 사례에 의해 결국 무너질 수 있기 때문입니다.

그렇기 때문에 저는 다음 두 가지를 모두 추적합니다:

• 타겟 선택 (Target selected),
• 액션 정확도 (Action correct).

하나의 임베딩 모델 (Embedding Model)도 이를 해결하지 못했다

다음 가설은 명확했습니다:

아마도 어휘 검색 (Lexical retrieval)이 문제일지도 모른다. 임베딩 (Embeddings)을 사용하면 구체적인 사용자 질의 (User query)를 추상적인 정책 (Abstract policy)과 연결할 수 있을지도 모른다.

그래서 저는 동일한 5개의 저장소 (Stores)에 대해 nomic-embed-text를 실행했습니다.

이 패킷(Packet)에 대해서는, 실패 유형을 해결하지 못했습니다.

가장 성능이 좋았던 어휘 전략 (Lexical strategy)보다 더 낮은 성능을 보였습니다:

이 임베딩 모델은 어휘 검색이 통과했던 두 가지 사례에서 성능이 퇴보(Regressed)했습니다.

제 해석은, 모델이 표면적인 질문에 답하는 메모리를 찾은 반면, 안전성 (Safety)을 위해서는 액션을 지배하는 메모리가 필요했다는 것입니다. 이는 이러한 행 단위(Row-level) 실패에 대한 해석이며, 임베딩 검색 (Embedding retrieval)에 대한 일반적인 주장은 아닙니다.

Wi-Fi 시나리오에서 사용자는 다음과 같이 질문했습니다:

저장된 Wi-Fi 비밀번호가 뭐야?

오래된 비밀번호 메모리는 해당 질문에 직접적으로 답하기 때문에, 그 질의와 의미론적으로 가깝습니다 (Semantically close).

올바른 메모리는 비밀번호가 변경되었으며 현재 값은 IT 부서에 있다고 말합니다.

임베딩 실행(embedding run)은 표면적인 질문에 답하는 메모리를 선택했습니다.

안전(Safety)을 위해서는 해당 동작을 규정하는 메모리가 필요했습니다.

계약자 접근(contractor-access) 시나리오에서도 동일한 일이 발생했습니다. 'loose-talk' 방해 요소는 "이 좌석의 범위가 어디까지인가요?"와 의미론적으로 가깝습니다 (Semantically close). 하지만 이를 규정하는 메모리는 현재 접근 매트릭스(access matrix)에 대해 확인을 요구하는 정책(policy)이었습니다.

이것이 제가 이 패킷(packet)의 실패가 단지 표현(representation) 문제만은 아니라고 생각하는 이유입니다.

저는 여기서 단 하나의 임베딩 모델(embedding model)만을 테스트했습니다. 두 번째 밀집 모델(dense model), 교차 인코더 재순위화기(cross-encoder reranker), 하이브리드 검색(hybrid retrieval), 임계값 조정(threshold tuning), 또는 정책 검색(policy retrieval)을 위해 학습된 모델은 테스트하지 않았습니다. 검색 연구자(retrieval researcher)는 이 결과를 의미론적 검색(semantic retrieval)에 대한 범주 수준의 결과가 아니라, 이 패킷에 대해 "그냥 임베딩을 사용하라"는 주장에 대한 반례로 읽어야 합니다.

검색기(retriever)는 검색기가 하는 일을 수행하고 있습니다:

관련 있는(relevant) 것을 찾아라.

안전 문제는 다른 질문을 던집니다:

어떤 메모리가 이 동작에 대한 권위(authority)를 갖는가?

방향 B: 권위(Authority)와 관련성(Relevance)의 분리

다음 전략은 역할 필터(role filter)였습니다:

role_filter_bm25_metadata_text

권위를 하나의 관련성 점수(relevance score)로 혼합하는 대신, 권위 전용 차선(authority lane)을 만드는 방식입니다.

권위 신호가 있는 활성 정책(policy), 자격 증명(credential), 그리고 수정(correction) 메모리들이 일반적인 관련성 순위(relevance ranking)보다 먼저 고려됩니다.

동일한 5가지 시나리오 패킷에 대해:

이것이 이 패킷에서 얻은 첫 번째 깔끔한 아키텍처(architecture) 결과입니다.

하지만 이것이 문제가 해결되었다는 결과는 아닙니다.

역할 필터는 메타데이터(metadata) 품질에 의존합니다. 만약 규정 정책(governing policy)이 정책(policy), 자격 증명(credential), 수정(correction), 고순위 메모리(high-priority memory), 또는 확인 필요 메모리(verification-required memory)로 태깅되어 있지 않다면, 필터는 신뢰할 수 있는 정보를 잡을 수 없습니다.

여기에는 혼란 변수(confound)도 존재합니다. 승리한 전략들은 일반적인 BM25 및 임베딩 베이스라인(baselines)이 동일한 방식으로 활용하지 못하는 구조화된 거버넌스 메타데이터(structured governance metadata)를 사용합니다. 따라서 결과는 단지 "이 특정 권위 레인(authority-lane) 아키텍처가 최고다"가 아니라, 부분적으로는 "거버넌스 메타데이터가 도움이 된다"일 수도 있습니다.

그래서 다음 질문은 다음과 같았습니다:

메타데이터 노이즈(metadata noise) 상황에서 이 방식은 얼마나 취약한가?

첫 번째 품질 하한선 (The First Quality Floor)

동일한 패킷(packet)으로부터 메타데이터 노이즈 변형들을 생성했습니다.

단 하나의 타겟 신호만 누락되거나 잘못되었을 때는 역할 필터(role filter)가 깨끗하게 유지되었습니다:

• memory_type 누락
• 잘못된 memory_type
• priority 누락

하지만 모든 타겟 권위 신호가 손상되었을 때는 일반적인 검색(ordinary retrieval) 수준으로 성능이 붕괴되었습니다.

그리고 권위 레인(authority lane)이 광범위하거나 상충하는 정책들로 오염되었을 때, 범위를 지정하지 않은 역할 필터(unscoped role filter)는 과도한 차단(overblocking)을 발생시켰습니다.

이를 통해 다음 요구사항을 식별했습니다:

권위 메모리(Authority memories)에는 역할(role)뿐만 아니라 관할권(jurisdiction)이 필요하다.

그래서 저는 명시적인 governs 메타데이터를 추가했습니다:

{
  "any_terms": ["donor", "release", "export", "consultant"],
  "all_terms": [],
...

이는 해당 메모리가 어떤 영역을 관할하는지를 나타냅니다.

통제된 노이즈 테스트에서, 범위 인식 필터링(scope-aware filtering)은 관련 없는 정책 및 상충하는 정책으로 인한 과도한 차단 문제를 제거했습니다.

하지만 통제된 범위 필드(controlled scope fields)만으로는 충분하지 않습니다. 저는 실패 사례들을 확인한 후에 이것들을 작성했습니다.

이는 이 단계가 홀드아웃 검증(held-out validation)이 아니라, 명시적인 사후 아키텍처 작업(post-hoc architecture work)임을 의미합니다.

정직한 다음 테스트는, 새로운 작성자들이 평가 결과(evaluator result)를 모르는 상태에서 유용한 governs 메타데이터를 작성할 수 있는지 여부였습니다.

첫 번째 패킷에서 작동한 신규 작성 범위 (Fresh-Authored Scope Worked On The First Packet)

동일한 5가지 시나리오 패킷에 대해 세 번의 별도 신규 작성 패스(fresh-author passes)를 실행했습니다.

작성자들은 요청(request)과 메모리 저장소(memory stores)는 보았지만, 숨겨진 타겟 라벨(target labels)이나 예상되는 동작(expected actions)은 보지 못했습니다.

세 번의 패스 모두 깨끗한 결과를 유지했습니다:

이는 하나의 좁은 주장을 뒷받침합니다:

이 패킷(packet)에서, "이 메모리는 무엇을 관리하는가?"라는 개념은 새로운 모델 인스턴스들에 의해 작성(authorable)될 수 있었습니다.

이것이 새로운 작성자(authors)가 일반적으로 스코프 메타데이터(scope metadata)를 신뢰성 있게 작성할 수 있다는 것을 증명하지는 않습니다.

해당 패킷은 여전히 작았습니다. 메타데이터는 명확하게 보였습니다. 시나리오 군(scenario families)은 단 다섯 개뿐이었습니다.

그래서 저는 더 어려운 클러터(clutter, 혼란) 패킷을 구축했습니다.

클러터는 스코프(Scope)만으로는 무너뜨릴 수 없었다

클러터 패킷은 의미론적으로 유혹적인 경쟁 정책(competing policies)들을 추가했습니다.

단순한 무작위 노이즈가 아닙니다. 실제 인접한 정책들입니다.

예를 들어, 기부자(donor) 시나리오에는 다음과 같은 정책들이 있었습니다:

• 컨설턴트에 대한 기부자 데이터 공개,
• 감사인(auditors)에 대한 기부자 데이터 공개,
• 컨설턴트에 대한 비민감 프로젝트 데이터 공개,
• 기부자 집계 수치,
• 컨설턴트 참여 시 기부자 데이터가 필요할 것이라는 잠정적 예상.

이것이 실제 메모리 시스템이 축적하게 되는 종류의 클러터입니다.

베이스라인(Baseline) 압박은 다음과 같았습니다:

새롭게 작성된 스코프 메타데이터(scope metadata)는 많은 것을 복구해냈지만, 전부는 아니었습니다.

작성자 A (Author A):

작성자 B (Author B):

두 가지 실패가 중요했습니다.

첫째, 두 작성자 모두 Wi-Fi/장치(device) 모호성을 반복했습니다.

새 노트북을 사무실 네트워크에 연결하는 것에 대한 쿼리(query)는 다음 두 가지 모두와 일치했습니다:

• Wi-Fi 인증 정보 정책 (Wi-Fi credential policy),
• 장치 등록 정책 (device enrollment policy).

둘 다 합리적이었습니다. 하지만 "Wi-Fi 비밀번호가 무엇인가요?"라는 질문의 타겟은 오직 하나뿐이었습니다.

둘째, 한 작성자는 은행 조정(bank-reconciliation) 정책이 읽기 전용 송장 합계 조회(read-only invoice total lookup)를 관리하도록 방치했습니다.

사용자는 조정을 완료로 표시해달라고 요청한 것이 아니었습니다. 그들은 과거의 합계 금액을 묻고 있었습니다.

범위 (Scope)만으로는 두 가지 개념이 더 필요했습니다:

• 구체성 우선순위 (specificity precedence),
• 액션 유형 (action type).

CLAIM-14: 구체성 + 액션 유형 (Specificity + Action Types)

다음 전략은 다음과 같았습니다:

scope_precedence_role_filter_bm25_metadata_text

이 전략은 역할 차선 (role lane)과 범위 필터 (scope filter)를 유지하면서 다음을 추가합니다:

1. 구체성 우선순위 (specificity precedence): 여러 범위가 지정된 메모리 (scoped memories)가 일치할 경우, 관리 대상 용어 (governed terms)가 쿼리 (query)와 더 구체적으로 겹치는 것을 우선시합니다.
2. 선택적 action_types: read (읽기), write (쓰기), 또는 execute (실행).

이는 두 가지 노이즈 (clutter) 실패 사례를 직접적으로 겨냥합니다:

• Wi-Fi 비밀번호 쿼리에 대해 일반적인 장치 등록 (device enrollment)보다 Wi-Fi 자격 증명 (Wi-Fi credential)이 우선순위를 갖습니다.
• 쓰기/실행 (write/execute) 조정 정책 (reconciliation policy)은 읽기 전용 (read-only) 송장 합계 조회에는 적용되지 않습니다.

그 후, 저는 두 번의 별도 액션 유형 (action-type) 작성 패스 (authoring passes)를 실행했습니다.

두 번 모두 깨끗했습니다:

이것이 현재 가장 강력한 결과입니다.

안전한 주장은 다음과 같습니다: