AI 에이전트의 자기 강화형 기억 루프: 원인 및 해결책
기억 속에 남은 결론이 새로운 증거가 될 때
지속적 메모리는 에이전트를 매번 설명을 반복해야 하는 도구에서, 맥락을 앞으로 나르게 하는 존재로 바꿔놓습니다. 하지만 동시에 스테이트리스(stateless) 채팅에서는 피할 수 있는 실패 모드를 열어놓습니다. 하나의 해석이 메모리로 저장된 뒤 사실처럼 검색되고, 더 강한 버전을 정당화하는 근거가 될 수 있기 때문입니다.
이것은 자기 강화형 메모리 루프(self-reinforcing memory loop)입니다. 이 메커니즘은 악의, 고장난 플러그인, 혹은 특이한 프롬프트를 요구하지 않습니다. 표준 캡처 파이프라인이 어시스턴트의 출력을 저장하고, 표준 검색 파이프라인이 이를 컨텍스트로 제시하며, 모델은 검색된 텍스트가 대체로 증거이기 때문에 이를 증거로 취급할 뿐입니다.
이것은 환각(hallucination)과 한 가지 중요한 측면에서 다릅니다. 환각은 대화 끝남과 함께 사라지지만, 영구적인 메모리로 승격된 환각은 그것을 생성한 세션보다 오래 살아남고, 몇 주 뒤 관련 없는 컨텍스트에서 다시 나타날 수 있으며, 단순히 반복만으로도 그럴듯한 신빙성을 얻게 됩니다. 보다 넓은 메모리 모델에서 이 문제는 — 작업 메모리, 구조화된 상태, 검색 메모리를 세 가지 독립적인 계약으로 보는 모델 안에서 위치하며, AI 시스템 메모리 허브의 일부입니다. AI 어시스턴트의 메모리 시스템을 참조하십시오. 여기에서는 오래된 또는 모순되는 메모리를 가장 흔한 프로덕션 실패로 이미 지적하고 있습니다. 이 글은 왜 그 구체적인 실패가 계속 재발하는지를 한 단계 더 깊이 탐구합니다.
모든 메모리 시스템에 대해 물어야 할 질문은 단순히 ‘기억하느냐’가 아닙니다. 미래 추론의 증거로 무엇이 허용되는지를 묻는 것입니다. 이를 잘 답변하려면 사용자가 명시적으로 서술한 것, 도구가 실제로 관측한 것, 외부 문서가 보고한 것, 그리고 모델이 단순히 추론하거나 요약한 것을 구별해야 합니다. 이러한 범주들이 “메모리"라는 단일한, 미분화된 풀(pool)로 무너지는 순간, 생성된 결론은 관측과 구별 불가능해집니다 — 메모리 시스템은 사실상 추론을 전제(laundered an inference into a premise)로 세탁해버린 것입니다. 이 구분을 강제하여 한 프로바이더를 실행하는 실용적인 단계별 안내에 대해 보려면 Mnemosyne for Hermes Agent: Local Memory Quickstart를 참조하십시오. 그리고 8개 이상의 메인스트림 프로바이더가 이 정확한 축(axis)에서 어떻게 다른지 보려면 Agent Memory Providers Compared를 참조하십시오.
자기 강화형 메모리 루프란 무엇인가?
가장 단순한 버전은 고정된 형태를 가지고 있습니다. 사용자가 무언가를 서술하면, 에이전트는 그로부터 결론을 추론하고, 메모리는 그 결론을 저장합니다. 미래 세션이 그것을 회상하면, 에이전트는 회상된 진술을 증거로 취급하여 더 강한 결론을 도출하고, 그것을 다시 메모리에 기록합니다. 그런 다음 사이클은 반복되며, 새로운 관측이 파이프라인에 단 한 번도 들어오지 않았음에도 매번 조금 더 확신에 찬 주장으로 발전합니다.
캐시 설정 변경 후 배포가 실패했다고 에이전트에게 말하는 개발자를 생각해 보십시오. 합리적인 추론은 그 캐시 설정이 아마도 실패를 일으켰다는 것입니다. 이것이 현재 컨텍스트 내에 머물러 있다면 유용한 추론입니다. 문제는 자동 메모리 추출기가 “캐시 설정이 배포 실패를 일으켰다"는 평평한(flat) 주장을 사실로 저장할 때 시작됩니다. 일주일 후, 두 번째로 관련 없는 배포가 실패하면, 에이전트는 저장된 주장을 검색하여 캐시 계층이 불안정성의 기록이 있다고 추론하고, 이것은 훨씬 더 일반적인 믿음으로 기록됩니다. 세 번째 패스에 이르면, 저장된 메모리는 “캐시 계층은 신뢰할 수 없는 것으로 알려져 있고 교체되어야 한다"고 읽혀집니다 — 새로운 증거가 전혀 없는 상태에서 만들어진 확신에 찬 조직적 주장입니다.
왜 지속적 에이전트 메모리가 데이터베이스보다 이것을 악화시키는지
전통적인 애플리케이션 데이터베이스에는 명시적인 쓰기 경로가 있습니다. 필드가 변경되는 이유는 알려진 사용자, API 호출, 또는 트랜잭션에 의해 변경되었기 때문입니다. 에이전트 메모리 시스템은 일반적으로 훨씬 많은 작성자(writers)를 가집니다 — 사용자, 어시스턴트, 도구 결과, 자동 턴 캡처 훅, 사실 추출기, 세션 요약기, 성찰 패스, 통합(consolidation) 프로세스, 때로는 다른 에이전트 등 — 그리고 동일한 수의 읽기자(readers)도 가집니다. 여기에는 자동 프롬프트 주입, 의미적 검색, 서브 에이전트 도구 등이 포함됩니다. 한 읽기자의 출력이 다른 작성자의 입력이 될 수 있는 순간, 이 시스템은 단순한 저장소가 아니라 피드백 루프가 되며, “누가 이 데이터를 언제 썼는가"에 대한 일반적인 데이터베이스 직관은 더 이상 적용되지 않습니다.
메모리 피드백의 주요 형태
자기 강화는 하나의 메커니즘이 아닙니다. 그것은 최소 7가지의 관련 있지만 구분되는 패턴으로 나타납니다. 메모리 프로바이더는 하나에는 저항성이 강하면서 다른 하나에는 취약할 수 있습니다.
어시스턴트 자기 에코(assistant self-echo)
가장 단순한 경우는 어시스턴트 메시지가 자동으로 보존될 때 발생합니다. 모델의 이전 답변이 다음 답변의 컨텍스트 증거가 되는 것입니다. 이것이 자동으로 답변을 틀리게 만드는 것은 아니지만, 그 인식론적 상태(epistemic status)는 변합니다 — 생성된 언어가 영구적인 컨텍스트가 된 것입니다. 가장 안전한 일반적인 규칙은 사용자 및 도구 관측은 메모리 후보가 될 수 있지만, 어시스턴트의 결론은 별도의 승격(promotion) 단계 없이 자동으로 사실로 만들어져서는 안 된다는 것입니다.
요약-요약 드리프트(summary-of-summary drift)
장기간 실행되는 에이전트는 대화를 반복적으로 압축합니다 — 원시 대화에서 요약으로, 요약에서 장기 메모리로, 메모리에서 사용자 프로필로 — 그리고 각 변환 과정에서 수식어가 조용히 제거될 수 있습니다. “보통 PostgreSQL을 사용하지만 작은 도구에는 SQLite도 괜찮다"는 “사용자는 PostgreSQL을 선호한다"로, 그 다음 “사용자는 PostgreSQL을 사용한다"로, 그리고 “사용자의 프로젝트들은 PostgreSQL을 사용한다"로 변할 수 있으며, 그 시점에서 향후 SQLite 제안은 사용자의 아키텍처 선호를 위반하는 것으로 플래그가 찍힙니다. 그 체인의 단일 단계 중 어느 것도 극단적이지는 않지만, 누적 효과는 완전히 그럴듯한 종이 기록(paper trail)을 가진 잘못된 믿음이 됩니다.
성찰 증폭(reflection amplification)
일부 프로바이더는 저장된 메모리에 대해 고차원적(higher-order) 추론을 의도적으로 수행합니다 — Hindsight의 reflect가 문서화된 예시입니다 — 그리고 에이전트는 검색만 있는 것이 아닌 종합(synthesis)이 필요하기 때문에 이것은 진정 유용합니다. 위험은 도출된 결론이 그것의 출처인 원시 관측과 함께 구별하는 마커 없이 저장될 때 시작됩니다. 그러면 이후의 읽기자는 세 개의 관측과 그 관측에 대한 하나의 해석인 것을, 네 개의 서로 독립적인 것처럼 보이는 사실로 봅니다.
검색 증폭(retrieval amplification)
검색 자체는 성찰 단계가 전혀 없어도 편향을 도입합니다. 자주 검색되는 메모리는 더 많은 프롬프트에 등장하고, 더 자주 언급되고, 더 자주 재캡처되며, 더 많은 관련 메모리를 생성합니다. 그리고 그것들은 다시 더 자주 검색됩니다. 메모리는 이미 두드러졌기 때문에 일부로 두드러집니다 — 증거 루프가 아닌 인기(popularity) 루프입니다.
모순 붕괴(contradiction collapse)
메모리 시스템이 유사도만으로 두 개의 충돌하는 진술 중 어느 쪽이 참인지를 결정할 때 위험한 패턴이 나타납니다. Mnemosyne가 구체적인 실생활 예시를 제공합니다. 프로덕션 감사(audit)에서 유사도 기반 충돌 처리가 통합(consolidation) 패스 동안 243개 저장 항목 중 142개를 무효화(invalidated)한 것으로 밝혀졌는데, 이는 시스템이 “이 두 진술이 비슷해 보인다"는 것을 하나를 다른 것이 대체(superseded)했다는 증거로 취급했기 때문입니다. 새로운 Mnemosyne 릴리스는 이제 유사도를 증거가 아닌 후보 모순(candidate contradiction)으로 취급합니다 — 실제 무효화에는 성공적인 검증 단계가 필요합니다 — 이것은 통합 패스를 가진 어떤 프로바이더에게든 올바른 일반적인 방향입니다. 근본적인 교훈은 Mnemosyne를 훨씬 넘어 일반화됩니다. 두 진술이 하나가 틀렸기 때문에而不是, 날짜, 환경, 분기(branch), 또는 배포가 다르기 때문에 다를 수 있으므로 의미적 유사도는 모순의 증거가 아니기 때문입니다.
사용자-모델 강화(user-model reinforcement)
사실 목록이 아니라 사용자의 실행 모델(running model)을 유지하는 시스템은 동일한 문제의 더 날카로운 버전에 직면합니다. “사용자는 간결한 답변을 선호한다"거나 “사용자는 AWS에 배포한다"는 유용하고 낮은 위험입니다. 그러나 “사용자는 기술 X를 싫어한다"거나 “사용자는 항상 아키텍처 Y를 선택한다"는 추론된 특성(trait)이며, 에이전트의 이전 해석에 부분적으로 기반되어 있다면, 실존하는 사람을 하나의 상호작용의 카리커처(caricature)로 점진적으로 바꿔놓을 수 있습니다.
에이전트 자기-모델 강화(agent self-model reinforcement)
가미한 은근한 경우는 자신을 모델링하는 에이전트입니다. 에이전트가 행동을 수행하고, 그 행동을 설명하며, 메모리 시스템은 그 설명으로부터 자기-모델을 구축합니다. 그 자기-모델은 다음 세션에 피드백되어, 에이전트가 그 자기-모델에 따라 행동하고 그것을 더욱 강화합니다. 유용한 자기-모델은 시간이 지남에 따라 에이전트의 행동을 안정화시킬 수 있습니다. 틀린 것은 에이전트를 틀린 행동 주변에서 동일한 효과로 안정화시킵니다 — 루프가 어떤 방향으로 잠금(lock in)되었는지 신경 쓰지 않으니까요.
왜 확신(confidence)이 진행 중에 증가하는 경향이 있는가
대규모 언어 모델은 검색된 문장이 원래 자신의 다른 인스턴스(instance)에 의해 생성된 것인지 자동으로 알지 못합니다. “사용자: 서버 X에 네트워크 문제가 있을 것 같다"는 잠정적으로(tentative) 읽히지만, “관련 메모리: 서버 X에 네트워크 문제가 있다"는 결정된 것처럼(settled) 읽힙니다. 둘 다 동일한 불확실한 추측으로 거슬러 올라갈 수 있음에도 불구하고요. 헤지(hedged)된 주장에서 선언적(declarative) 메모리 객체로의 그 문법적 전환은 출처 세탁(source laundering)이며, 여러 도출된 메모리가 서로 일치하게 될 때 복리처럼 쌓입니다 — 세 개의 의미적으로 유사한 메모리는 독립적인 교차 검증(independent corroboration)처럼 보일 수 있지만, 세 개 모두 단일 대화에서 기원했을 수 있습니다.
프로덕션 시스템에서 나타나는 결과
실용적인 피해는 몇 가지recognizable한 형태를 취합니다. 거짓 확신(false certainty)은 메모리가 이를 이미 결정된 것으로 제시하기 때문에 에이전트가 가정을 검증하기를 멈추는 것을 의미합니다. 선호 드리프트(preference drift)는 잠정적인 선호가 절대적 지시로 점차 경화(hardening)되는 것을 의미합니다. 잘못된 사용자 프로필은 하나의 특별한 상호작용이 장기적 행동 특성으로 일반화되는 것을 의미합니다. 도구-행동 캐스캐이드(tool-action cascades)는 가장 비용이 높은 버전입니다. 잘못된 기억된 전제가 잘못된 진단을 이끌고, 그것이 도구 호출을 이끌며, 그것이 실제 구성 변경을 이끕니다. 지속적 에이전트는 오류가 외부 세계에 도달할 수 있기 때문에 메모리 오류의 비용을 정확히 높입니다. 중복 메모리 인플레이션(duplicate-memory inflation)과 상태 고착(stale-state lock-in)은 모두 시간이 지남에 따라 프롬프트 예산과 검색 품질을 낭비하며, 파괴적 통합(destructive consolidation)은 추론된, 더 새로운 것처럼 보이는 진술이 더 오래되었지만 더 권위 있는 관측을 조용히 대체하도록 허용할 수 있습니다.
삭제(deletion)는 여기서 구체적인 경고를 필요로 합니다. 현대 프로바이더는 하나 캡처된 항목에서 여러 도출된 구조를 자주 구축합니다 — 작업 메모리, 추출된 사실, 요약, 임베딩, 그래프 엣지, 정준(canonical) 사실, 프로필 항목 등 — 그리고 원본 메모리를 삭제한다고 해서 모든 도출된 표현이 그것과 함께 사라진다는 보장은 없습니다. 메모리 삭제는 API가 성공을 반환했다고 해서 작동한다고 가정하는 것이 아니라, 종단간(end-to-end)으로 테스트되어야 합니다.
임베딩 품질보다 프로베넌스(provenance)가 더 중요하다
대부분의 메모리 엔지니어링 노력은 검색에 투입됩니다 — 벡터 유사도, BM25, 하이브리드 검색, 리랭커(reranker), 그래프 탐색, 시간 가중치 — 그리고 그것들은 모두 진정 유용하지만, 그 어느 것도 근본적인 문제를 해결하지 못합니다. 왜냐하면 검색 품질은 어떤 메모리가 표면화되는지만 영향을 미칠 뿐, 표면화된 메모리가 주어진 자신감(confidence)을 받을 자격이 있는지 여부는 해결하지 못하기 때문입니다.
프로덕션 메모리 객체는 콘텐츠 외에도 메타데이터를 포함해야 합니다: 출처, 출처 유형, 타임스탬프, 범위, 신뢰도, 무엇으로부터 도출되었는지, 검증 상태, 그리고 대체(superseded)되었는지 여부. 실무에서 작동하는 대략적인 티어링(tiering)은 명시적인 사용자 진술과 직접적인 도구 관측을 가장 높게, 신뢰할 수 있는 외부 데이터를 그 다음으로, 결정론적 추출(deterministic extraction)을 그 다음으로, 요약을 그 다음으로, 그리고 신뢰 계층의 맨 아래에 모델 추론과 성찰 출력을 배치합니다. 추론이 무가치해서가 아니라, 그것이 구축된 관측의 신뢰 수준을 조용히 상속받아서는 안 되기 때문입니다. 검색과 통합은 그렇게 순수한 의미적 유사도로 순위 매기는 것이 아니라 그 계층 구조를 존중할 수 있습니다.
더 안전한 아키텍처 패턴
대부분의 개인용 및 엔지니어링 에이전트에 대해, 의도적으로 지루한(boring) 메모리 파이프라인이 완전히 자동화된 것보다 뛰어난 성과를 보입니다. 핵심 설계 결정은 에이전트가 기본적으로 모든 대화를 영구적인 진실로 변환하지 않는다는 것입니다 — 후보 메모리는 보존되기 전에 분류되며, 관측은 보존되고, 추론은 일시적(transient)으로 유지되며, 불확실한 경우들은 조용히 기록되는 대신 사용자에게 되돌려 보내집니다.
고가의(고도로 중요한) 환경에서, 인간 승인 게이트(human approval gate)는 그 마찰에도 불구하고 가치가 있습니다: 후보 메모리가 대기(pending) 상태로 이동하고, 인간이 그것을 검토하며, 명시적인 승인만이 영구 메모리에 커밋하고 거절은 폐기합니다. Hermes의 자체 memory.write_approval: true 설정은 이 정확한 이유 때문에 내장된 MEMORY.md 쓰기 작업을 스테이징(stages)하며, 같은 아이디어는 Mnemosyne에서 프로바이더 특정 스테이징 쓰기(staged writes)로 나타납니다 — 다만 Hermes 외부 메모리 플러그인 전체에 걸쳐 통일되고 프로바이더 독립적인 승인 계약이 아직 존재하지 않는다는 점은 주목할 가치가 있습니다. 따라서 이 경로는 어디에서나 작동한다고 가정하기보다는 실행 중인 정확한 버전을 대상으로 테스트되어야 합니다.
현재 프로바이더가 이 문제를 해결하는 방법
아무 프로바이더도 피드백 루프를 완전히 제거하지는 않습니다. 각각은 편의와 통제 사이에 다른 트레이드오프를 만듭니다.
Hermes의 자체 내장 MEMORY.md 및 USER.md 파일은 의도적으로 작고 인간이 읽기 쉽습니다. 이는 특별한 도구 없이도 감사(audit)하기 쉽게 만듭니다 — 트레이드오프는 규모(scale)이며, 이는 의미적 장기 메모리 데이터베이스가 아니기 때문입니다. [Hermes Agent Memory System](https://www.glukhov.org/ko/ai-systems/hermes/hermes-agent-memory-system/ “제한된 2-파일 코어 메모리에서 플러그인형 외부 프로바이더에 이르기까지 Hermes Agent 메모리 아키텍처에 대한 심층 기술 가이드”})은 그 제한된 설계를 완전히 다룹니다.
Mnemosyne는 더 거버넌스(governance) 지향적인 외부 프로바이더 중 하나입니다. 정확히 어떤 것이 기록되는지 대해 독립적인 통제를 노출시키기 때문입니다: sync_roles: []로 대화 자동 저장을 완전히 비활성화하면서 명시적인 메모리 작업은 사용 가능하게 유지하고, 도구 결과 로깅은 기본적으로 꺼져 있으며, 더 새로운 빌드들은 컨텍스트 압축 경계(context-compression boundaries) 주위에 옵트인(opt-in) 자기 에코 억제(self-echo suppression)를 추가합니다. Mnemosyne for Hermes Agent: Local Memory Quickstart은 보존적인 구성을 끝에서 끝으로 안내합니다.
Hindsight의 기본 Hermes 통합은 비교적으로 자동적입니다 — autoRecall과 autoRetain 모두 기본적으로 true입니다 — 이는 편리하지만 피드백 경로의 수를 증가시킵니다. 프로베넌스가 편의보다 더 중요하고, auto_retain=false를 설정하는 것을 유지하면서 검색(recall)을 켜 두는 것은 고려할 가치가 있습니다. Hindsight for Hermes Agent는 그 쓰기 경로 선택, 뱅크 미션(bank missions), 그리고 “What Gets Remembered” 섹션에서 승인 큐(approval-queue)의 공백을 다룹니다. Holographic과 ByteRover 모두 기본적으로 auto_extract를 꺼서, 자동 기록부-메모리 파이프라인이 아니라 명시적인 사실 저장소로 주로 작동할 수 있습니다. 피드백 루프가 주요 관심사라면 이것은 이점입니다. Honcho의 unified 관측 모드는 자신의 메시지에서 매칭되는 자기-관측 루프를 구축하지 않으면서도 AI가 사용자를 모델링할 수 있기 때문에 그 directional 기본값보다 더 보수적입니다. 에이전트 자기-모델 강화에 대해 특히 우려하는 모든 사람에게 심각한 고려의 가치가 있습니다. Agent Memory Providers Compared에는 각 프로바이더의 캡처 정책 및 승인 지원을 포함한 전체적인 프로바이더별 비교가 있습니다.
벤치마크보다 중요한 구성 질문
리콜 벤치마크는 에이전트가 올바른 정보를 검색할 수 있는지를 측정합니다. 프로덕션 시스템은 다른 세트의 질문에 대한 답변을 필요로 합니다: 무엇이 자동으로 기록되는가, 어시스턴트 출력이 메모리가 될 수 있는가, 도구 결과가 자동으로 보존되는가, 요약이 사실로 저장되는가, 도출된 사실이 도출된 것으로 마킹되는가, 오래된 메모리가 자동으로 대체될 수 있는가, 사용자가 보존된 모든 것을 검사할 수 있는가, 삭제가 도출된 표현도 제거하는가, 자동 검색이 자동 보존에서 독립적으로 비활성화될 수 있는가, 인간 승인 게이트가 있는가, 그리고 에이전트 자체가 그 게이트를 우회할 수 있는가. 그 열 가지 질문은 장기 리콜 벤치마크의 추가 5점보다 일반적으로 더 진단력이 강합니다.
개인 엔지니어링 에이전트를 위한 내가 선호하는 정책
셀프 호스팅된 엔지니어링 어시스턴트에 대해, 자동 대화 보존, 자동 어시스턴트 보존, 그리고 자동 도구 결과 보존은 모두 기본적으로 꺼져 있어야 하며, 자동 검색은 켜져 있거나 선택적이어야 하고, 명시적인 기억(remember)은 켜져 있어야 하며, 세션 히스토리 검색은 켜져 있어야 하며, 도출된 결론은 영구적이지 않고 기본적으로 일시적으로 유지되어야 합니다. 영구 저장소는 다른 세션으로 가져갈 가치가 있는 사실을 포함해야 하며, 원본 세션 히스토리는 에이전트가 요약이 아닌 실제 증거가 필요할 때 별도로 검색 가능해야 합니다. 메모리는 간결하게 보존된 지식이 되고, 세션 검색은 원본 증거가 됩니다 — 둘은 절대 하나의 미분화된 풀로 혼합되어서는 안 됩니다.
메모리 프로바이더 테스트 방법
프로바이더가 기억하는지 테스트하는 것은 쉬운 절반입니다. 더 어렵고 유용한 절반은 프로바이더가 기억하기를 거부하는지, 그리고 요청되면 완전히 잊는지 테스트하는 것입니다.
아무것도 기억하라고 요청하지 않고 에이전트에게 일반적인 사실을 말하고, 새로운 세션을 시작하며, 자동 캡처가 비활성화되어야 한다면 그 값이 나타나지 않는지 확인하십시오. 그런 다음 다른 사실을 기억하라고 명시적으로 요청하고, 새로운 세션을 시작하며, 그것이 올바르게 검색되는지 확인하십시오 — 이 테스트 쌍은 쓰기 경로 정책을 검색 메커니즘과 분리합니다. 별도로, 에이전트에 추론을 만들足够한 정보를 주되, 그 추론을 본인이 진술하지 않은 다음, 메모리 데이터베이스를 직접 검사하십시오. 그 추론은 독립적인 사실로 조용히 나타나서는 안 됩니다. 독특하고 고유한 도구 명령을 실행하고, 나중에 메모리에서 검색하여 도구 결과 로깅이 구성대로 작동하는지 확인하십시오. 사실을 저장하고, 삭제한 다음, 프로바이더가 사용할 수 있는 모든 레이어 — 작업 메모리, 의미적 리콜, 사실 테이블, 그래프 노드, 요약, 임베딩, 프로필 컨텍스트 —를 검사하십시오. 성공적인 delete API 응답은 데이터가 실제로 사라졌다는 충분한 증거가 아니기 때문입니다. 마지막으로, 두 개의 모순된 사실을 저장하고, 프로바이더가 타임스탬프와 함께 둘 다 유지하는지, 하나를 대체된 것으로 마킹하는지, 오래된 레코드를 파괴하는지, 아니면 검증을 요청하는지 검사하십시오 — 그 단일한 테스트는 어떤 기능 목록보다 프로바이더의 인식론적 모델(epistemic model)에 대해 더 많은 것을 드러냅니다.
핵심 설계 규칙
모델이 생성한 결론은 같은 모델이 그것을 기억했기 때문에 더 강한 증거가되어서는 안 됩니다. 메모리 시스템은 프로베넌스, 제어된 쓰기 경로, 도출된 지식의 명시적 처리, 그리고 사용자가 볼 수 있는 레코드만이 아니라 실제로 모든 도출된 표현에 도달하는 삭제를 필요로 합니다. 가장 발전된 메모리 프로바이더는 반드시 가장 많이 기억하는 것이 아닙니다 — 장기 실행 에이전트에 대해, 더 나은 프로바이더는 종종 기억하지 말아야 할 때를 아는 것입니다.
