계층적 컨텍스트: AI 에이전트를 위한 지식 계층 구조

하나의 평탄한 기억 파일만 보유한 에이전트는 정보를 잊지 않습니다. 오히려 묻지 않은 정보까지 잊지 못하는 상태에 놓여 있습니다. 이 문제를 해결하는 방법은 각 지식 계층이 서로 다른 트리거를 통해 컨텍스트에 진입하도록 하는 다층적 컨텍스트 구조입니다.

이 실패 양상은 망각이 아니라, 그 반대입니다. 하나의 평탄한 저장소에서는 모든 사실이 같은 장소에 존재하며, 같은 방식으로 컨텍스트에 진입하며, 따라서 항상 같은 방식으로 이용 가능합니다. 에이전트에게 고객 이메일에 대해 물으면 답장 작성 중 라우터 구성을 서술하고, 서비스 문제를 해결해 달라고 하면 지난 달 인용된 스폰서십 요율을 언급합니다. 이 기억 무더기는 하나의 단일체(monolith)입니다: 하나의 관심사에 대한 변경이 다른 모든 관심사에 영향을 주며, 모든 쿼리의 피해 범위는 전역 코퍼스 전체입니다.

표준적인 조언은 행동론적입니다: 에이전트에게 현재 주제와 관련 있는 것이 무엇인지 가르치는 것입니다. 이는 하중 지지 벽면에 “주의 깊게 다루세요"라고 쓰는 것과 같은 소프트웨어적 등가물입니다 — 에이전트에게 지시할 수 있고 대부분 따르지만, 따르지 않는 날이 올 때까지입니다. 구조적 대안은 필요한 활동이 이미 진행 중일 때만 컨버세이션에 진입할 수 있는 지식입니다. 이 글은 해당 구조를 5층 지식 계층 구조로 정의합니다 — 각 계층이 무엇인지, 그 주입을 트리거하는 요소, 그 안에 무엇이 포함되는지, 그리고 어디에서 실패하는지 — 그리고 이를 구체적인 멀티 도메인 설정에 적용합니다: 일반 프로필 하나, 홈레브(homelab)용 하나, 개인적 사안용 하나, 업무용 하나, 교육용 하나.

계층 구조 명명

업계 표준 용어는 없으므로, 여기서는 정의가 명시적입니다. **지식 계층 구조(knowledge hierarchy)**는 에이전트가 아는 사항들의 분층된 배열로, 각 층은 세 가지 속성에서 차이가 납니다: 모델 컨텍스트에 진입하는 방식, 허용되는 크기, 그리고 정확성을 유지할 것으로 기대되는 기간. 지식 아키텍처 수준에서, 이웃한 패러다임들 — PKM, RAG, 위키, 그리고 기억 시스템 — 은 PKM vs RAG vs 위키 vs 기억 시스템 비교에서 비교되며, 어시스턴트가 실제로 구현하는 런타임 계약은 AI 어시스턴트의 기억 시스템에서 매핑됩니다. 이 두 가지는 모두 지식 관리 클러스터 내에 위치하며, 인간 지식 시스템의 기초, 방법, 도구를 다룹니다. 이 글은 배치(pullacement)를 강제 가능하게 만드는 트리거 기반 분류와 프로필 경계를 추가합니다.

계층 구조의 형태를 설명하는 두 가지 계보가 있습니다.

첫 번째는 CPU 메모리 계층 구조입니다. 프로세서는 잠재적으로 필요할 수 있는 모든 바이트를 동일한 레지스터에 저장하지 않습니다. L1 캐시 — 작고, 항상 상주하며, 의사결정 없이 접근 — L2, 메인 메모리, 그리고 디스크가 있으며, 각 계층은 더 크고, 도달 시간이 느리며, 상위 계층에 답이 없을 때만 접근됩니다. 설계 규칙은 “모든 것을 빠르게 유지한다"가 아닙니다. 그것은 대부분의 데이터는 중요하지 않으며; 중요할 때만 접근 비용을 지불하라입니다. 하나의 평탄한 메모리 파일을 가진 에이전트는 모든 것을 L1로 가득 채운 CPU와 같습니다: 레지스터 파일이 거대하여 모든 것이 가시적이며, 현재 명령어가 요청하지 않은 바이트도 포함됩니다. MemGPT는 에이전트에 대해 동일한 움직임을 수행하여, 빠른 저장소와 느린 저장소 간의 명시적인 이동이 있는 티어로 기억을 모델링했습니다.

두 번째는 인지적 기억 분류학으로, 지식을 절차적 기억(어떻게 하는지), 의미적 기억(세상에 대한 사실), 에피소딕 기억(무엇이, 언제, 누구에게 일어났는지)으로 나눕니다. 이 분류학은 유형별로 실패 양상이 다르기 때문에 중요합니다: 낡아진 절차적 지식은 워크플로의 버그이고, 낡아진 의미적 지식은 잘못된 사실이며, 유출되는 에피소딕 지식은 프라이버시 사건입니다. 위치가 아닌 콘텐츠 유형으로 조직된 계층 구조는 어떤 실패가 위험한지 알려줍니다.

이 글의 조직 축은 위 두 가지 중 어느 것도 아닙니다. 지식을 컨텍스트에 진입하게 하는 원인에 따라 분류합니다. 주입 트리거(injection trigger)는 메커니즘이며, 실제 강제할 수 있는 것은 바로 이 메커니즘입니다. 에이전트 시스템은 정확히 네 가지 트리거를 제공합니다:

• 항상(Always). 무조건적으로 모든 턴에 주입됩니다.
• 작업 트리거(Task trigger). 현재 활동이 선언된 조건과 일치할 때 로드됩니다.
• 의미적 검색(Semantic recall). 현재 메시지가 저장된 것과 유사할 때 표면화됩니다.
• 명시적 참조(Explicit reference). 작업이 파일이나 쿼리를 지정하기 때문에 가져와집니다.

계층 구조의 모든 계층은 그것을 공급하는 트리거로 정의됩니다. 이것이 전체 설계이며, 이 글의 나머지 부분은 하나의 표를 상세히 설명하는 것입니다.

다섯 계층

표의 트리거 열을 가로가 아닌 세로로 읽으십시오. 계층 0과 계층 1은 L1 캐시입니다: 항상 상주하는 특권을 위해 작다는 대가를 지불합니다. 계층 2는 명령어 캐시입니다: 분기 조건, 즉 스킬의 트리거와 일치하는 작업에 의해 인출됩니다. 계층 3은 디스크입니다: 작업의 단계가 명시적으로 지정된 파일을 읽을 때까지 컨텍스트에 아무것도 진입하지 않기 때문에 거대할 수 있습니다. 계층 4는 미묘한 것입니다 — 이는 유사도에 의해 접근되는 메인 메모리며, 이는 목록 중 사용자가나 작업이 내린 결정을 포함하지 않는 유일한 트리거입니다. 유사도는 확률적 게이트이며, 이것이 가장 엄격한 외부 통제가 필요한 이유이며, 프로필 섹션이 이를 제공합니다. 이 글 상단의 캐비닛 이미지는 동일한 아이디어를 인코딩합니다: 티어가 높을수록 그 내용이 더 자유롭게 컨버세이션에 진입하며, 유리 파티션은 한 도메인의 선반이 끝나는 곳을 표시합니다.

계층 0: 정체성

SOUL.md 또는 에이전트가 시스템 프롬프트라고 부르는 것. 그 역할은 무엇을이 아니라 누구인지를 정의하는 것입니다: 톤, 가치, 거부 경계, 그리고 기억 정책. 기억 정책이 여기에 속하는 이유는 기억이 조회되기 전에 발효되어 있어야 하는 유일한 지침이기 때문입니다. 서버 이름, 고객 이름, 요율을 나열하기 시작하는 정체성 파일은 이미 실패한 것입니다 — 계층 1의 콘텐츠에 계층 0의 배지를 착용한 것이며, 이제 모든 컨버세이션에 타나와, 특히 나타서서는 안 되는 컨버세이션에도 포함됩니다.

계층 1: 상주 기억

지속적인 메모리 파일: 일반 노트와 사용자 프로필. 이 계층을 지배하는 두 가지 규칙이 있으며, 이는 작동하는 계층 구조를 무더기와 구분하는 규칙입니다.

첫째, 포인터, 사실 아님. 한 도메인만 서비스하는 사실은 여기에 속하지 않습니다. 올바른 항목은 사실 자체가 아니라 표지판(signpost)입니다:

인프라 사실: wiki/infra/ + 기억 뱅크 'homelab'.
고객 및 계약: wiki/business/clients/ + 뱅크 'business'.

표지판은 도메인 중립적이므로 모든 곳에 운반하는 것이 안전합니다. 그것이 가리키는 사실은 목적지를 명시한 활동에 의해만 로드됩니다.

둘째, 단단한 예산, 강제 집행. 저장소에 문자 제한이 없으면 채워지며, 채움은 항상 최근에 논의된 주제이므로 — 인프라 주가 조용히 일반 컨텍스트를 인프라로 추방하거나 둘러싸게 됩니다. 거의 가득 찬 예산은 분류(triage)를 강제하며, 분류는 이 계층을 정직하게 유지하는 유일한 메커니즘입니다. Hermes 구현은 작동하는 예시입니다: 세션 시작 시 동결된 블록으로 주입되는 MEMORY.md(2,200자 제한)와 USER.md(1,375자)는 Hermes Agent Memory System에 문서화되어 있습니다.

계층 2: 절차적 지식

스킬은 에이전트가 어떻게를 인코딩하는 방법입니다: 절차, 함정, 그리고 — 이 글에 중요하게 — 더 깊은 계층으로의 포인터. 홈레브 행정용 스킬은 재고를 가진 위키 디렉토리와 검색할 기억 뱅크를 명시합니다. 고객 업무용 스킬은 계약 저장소와 비즈니스 뱅크를 명시합니다. 스킬의 설명이 그 트리거입니다: 절차, 그리고 따라서 그 포인터가 컨텍스트에 진입할지 결정하는 분기 조건입니다.

이는 계층 구조를 운영적으로 작동하게 하는 계층이며, “어떤 활동이 일어나고 있는가"와 “그 활동이 볼 수 있는 데이터가 무엇인가” 사이의 이음(seam)이기 때문입니다. 고객 이메일에 대한 작업은 고객 스킬을 로드합니다; 고객 스킬은 비즈니스 뱅크와 계약 디렉토리를 명시합니다; 홈레브 뱅크와 인프라 디렉토리는 작업이 걸어간 경로에서 단순히 참조되지 않습니다.

실패 양상은 데이터 크리프입니다: 실제 고객 목록이나 실제 IP 테이블을 스킬 본문에 붙여넣는 것. 그러면 데이터는 절차가 로드될 때마다 항상 로드되며, 절차의 트리거는 데이터의 노출 경계가 됩니다. 스킬은 데이터에 대한 경로를 운반하며, 민감한 것은 아무것도 하지 않습니다.

계층 3: 참조 데이터

위키, 노트 트리, 레코드 시스템. 이는 최소한의 제약과 최소한의驚喜를 가진 계층이며, 결정론적 접근 경로가 있는 유일한 계층이기 때문입니다: 작업의 단계가 명시적으로 해당 파일을 읽기 때문에 컨텍스트에 진입합니다. 테이블, 재고, 계약, 런북, 통계 — 데이터베이스나 구성 관리 시스템에 보관할 것. 코퍼스이 LLM 유지보수될 때, LLM 위키 패턴이 적용됩니다: 종합(synthesis)은 수신 시점에 발생하고, 결과는 구조화되고 연결된 페이지로 저장됩니다.

참조 데이터가 계층 4에 속하지 않는 이유는 검색 품질이 테이블에는 잘못된 도구이기 때문입니다. 의미적 검색은 “고객 X가 마감일 대해 무엇을 확인했는가"에는 우수하지만, “호스트 Y의 서비스 포트는 무엇인가"에는 최악입니다 — 후자는 정확히 한 행의 올바른 답을 가지며, 세 개의 가장 가까운 단락을 반환하는 리랭커는 부담이 됩니다. 참조 데이터에는 결정론적 조회가, 에피소드에는 유사성이 우세합니다. 분리하면, 각 계층의 접근 패턴이 콘텐츠 형태와 일치합니다.

실패 양상은陈旧化이며, 이는 아키텍처 문제가 아닌 유지보수 문제입니다: 레코드가 현실에서 이탈하고, 모든 것을 올바르게 수행하는 에이전트는 잘못된 테이블로 작업합니다. 완화책은 어떤 레코드 시스템이든 필요한 것과 동일합니다 — 파일당 하나의 작성자, 변경 로그, 감사 주기 — 이 외에 LLM 위키 유지보수: Drift, Contradictions and Review에서 다루는 дрейф 탐지와 모순 확인 연습도 포함됩니다.

계층 4: 검색된 기억

턴별 자동 회상을 가진 기억 백엔드: 에이전트의 에피소딕 및 관계적 기억. 결정과 그 날짜, “고객 X가 Y를 확인했다”, “우리는 Z를 시도했고 작동하지 않았다”. 동적이고 자기 조직적인 시스템의 부분이 존재하는 곳이며 — 그리고 보안 스토리가 흥미로워지는 곳, 왜냐하면 의미적 검색은 확률적 게이트이며 확률적 게이트는 번리(bleed)하기 때문입니다.

“고객 X의 청구 질문"과 “billing 서버를 실행하는 호스트는 무엇인가"는 임베딩 공간에서 가깝습니다. 고객 레코드와 인프라 재고를 모두 가진 단일 뱅크는 후자를 전자에서 표면화할 확률이 적지 않습니다. 태그와 회상 제한으로 이를 좁힐 수 있으며, 그렇게 해야 합니다 — 그러나 혼합 코퍼스 위의 태그 필터는 규율이 아닌 구조입니다. 구조적 답안은 혼합을 중단하는 것입니다: 도메인당 하나의 뱅크, 따라서 회상의 번리 범위는 구조상 하나의 도메인입니다. 백엔드 자체를 선택하는 것 — 캡처 정책, 의존성, 셀프호스팅 제약 — 은 별개의 비교이며, Agent Memory Providers Compared에서 다룹니다.

이 계층을 연결할 때 두 가지 기계적 세부 사항이 중요합니다. 쓰기 경로와 읽기 경도는 별개의 컨트롤입니다: 뱅크는 회상에는 포함되면서도 유지(retention)에는 제외될 수 있으며, 이것이 모든 것을 읽지만 아무것도 쓰지 않는 프로필을 구축하는 방법입니다. 그리고 모든 뱅크는 자체 유지 미션을 가져야 합니다 — 그 뱅크가 존재하는 이유가 갖는 것의 짧은 진술. “고객 서신, 계약 조건, 협상 상태; 절대 인프라 상세 아님"이라는 미션을 가진 비즈니스 뱅크는 그에 따라 추출하며, 추출은 미션을 읽는 LLM 호출이기 때문입니다. OpenAI의 개인화 쿡북는 통합(consolidation)을 기억 수명 주기의 가장 민감하고 오류가 빈번한 단계로 취급합니다 — 유지 미션은 그 단계를 정직하게 유지하는 계약입니다.

프로필: 분리를 구조적으로 만드는 경계

여기까지, 계층 구조는 지식을 계층으로 분리합니다 — 필요하지만 충분하지 않습니다. 위 5개 계층은 하나의 에이전트 해부학입니다. 이 글이 처음에 던진 질문은 도메인에 관한 것입니다: 홈레브, 개인, 업무, 교육, 그리고 그것들을 가로지르는 일반 컨텍스트.

도메인 분리 메커니즘은 프로필입니다 — 에이전트의 완전하고 독립적인 인스턴스: 자신의 정체성 파일, 자신의 상주 기억, 자신의 스킬 디렉토리, 자신의 예약 작업, 그리고 결정적으로, 자신의 기억 뱅크 배선. 프로필은 컨버세이션에 달린 태그가 아닙니다; 동일한 머신을 공유할 뿐인 별개의 시스템입니다. agent -p homelab을 실행하면, 홈레브 도메인에 스코핑된 L0부터 L4까지 전체를 가진 프로세스를 얻으며, 비즈니스 뱅크는 구성에 전혀 없으므로 그 회상 풀에는 비즈니스 뱅크가 포함될 수 없습니다.

이는 유출 문제에 대한 두 가지 답안 사이의 차이입니다. “비즈니스 컨버세이션에서 인프라를 공개하지 마세요"는 프롬프트 지침 — 확률입니다. “비즈니스 프로필의 회상 풀에 인프라 뱅크가 포함되지 않는다"는 설정 — 보장입니다. 계층 구조는 무엇이 어디에 가는지를 알려주며, 프로필 경계는 컨버세이션 내에서 배치를 우회 불가하게 만듭니다.

실무 예시, 5개 도메인:

그 표에서 두 셀이 중추적 역할을 합니다.

**공용 프로필의 뱅크 행은 “없음, 읽기 전용”**입니다. 일반 컨버세이션은 가로질러 질문을 하는 곳이며, 따라서 모든 도메인의 검색된 사실을 볼 수 있어야 합니다 — 그러나 어디에도 쓰지 않아야 합니다. 일반 세션의 잡담은 도메인의 지속 기억으로 추출하고 싶어하지 않는 정확히 그 물질이며, 읽기 전용 배선은 모델에서 선택을 완전히 제거합니다. 백엔드의 배선이 회상 전용 뱅크 목록을 지원하면(쓰기 뱅크와 별도), 이는 도메인 뱅크당 하나의 설정 줄입니다; 지원하지 않으면, 공용 프로필은 전역 일반 뱅크에서 회상하고 약화된 크로스 도메인 뷰를 받아들입니다.

도메인 프로필의 회상 행은 비어 있습니다. 각 도메인 프로필은 정확히 하나의 뱅크를 봅니다. 홈레브 프로필은 고객 계약 조항을 결코 회상하지 않을 것이며, 그것이 금지되었기 때문이 아니라, 그것이 쿼리하는 풀에 있지 않기 때문입니다. 이것이 전체 연습의 목적인 이중 분리입니다: 지침 없이 구조상 대칭적으로 작동합니다.

세 가지 운영적 결과가 따르며, 이것이 프로필 접근법이 단일 에이전트 접근법보다 비용이 더 들지만 도메인이 진정으로 분리된 모든 사람에게 가치가 있는 이유입니다.

• 트리거가 표면이 됩니다. 홈레브 작업이 -p homelab으로 시작하는 터미널에서 발생하고, 고객 작업이 업무 프로필로 라우팅되는 메시징 계정에서 발생한다면, 어떤 모자를 쓰고 있는지는 에이전트를 호출한 방식의 속성이며, 기억해야 하는 플래그가 아닙니다. 오도(실수로 홈레브 컨텍스트에서 고객 작업을 실행)는 잘못된 셸을 실행하는 것과 마찬가지로 가시적이 됩니다.
• 예약 작업이 경계를 상속합니다. Cron 작업과 위임된 하위 작업은 그것들을 소유하는 프로필 내부에서 실행됩니다. 홈레브 프로필에서 예약된 야간 인프라 체크는 홈레브 뱅크로 비즈니스 콘텐츠가 유입되지 않으며, 왜냐하면 그것이 결코 그것을 가지고 있지 않기 때문입니다.
• 파일시스템은 공유되며, 이것이 정직한 한계입니다. 프로필은 컨텍스트를 분리하지 접근은 분리하지 않습니다. 모든 프로필의 터미널은 모든 프로필의 파일을 읽을 수 있습니다; 경계는 디스크가 아닌 컨버세이션을 보호합니다. 따라서 진정으로 민감한 자료를 가진 계층은 자체 규율이 필요합니다: 위키 평문 대신 환경 파일 또는 시크릿 저장소에 자격 증명, 공개 저장소 밖의 위키, 그리고 OS가 도울 때 디렉토리별 권한. 프로필 경계를 컨텍스트용 방화벽으로 대우하십시오 — 그 일에는 우수하지만 — 데이터용 방화벽으로 오해하게 두지 마십시오.

평탄한 무더기에서 부트스트랩

계층 구조는 보통 아래에서 도달합니다: 하나의 메모리 파일로 시작하고 이제 모든 것을 그 안에 보관하는 에이전트. 마이그레이션 순서가 중요합니다, 왜냐하면 각 단계는 이전 단계가 완료되어야만 저렴하기 때문입니다.

첫째, 회상 풀을 분리합니다. 도메인당 하나의 기억 뱅크를 만드는 것은 콘텐츠 재작성이 아닌 구성 변경이며 — 그리고 이것이 가장 높은 레버리지를 가진 단계입니다, 왜냐하면 뱅크가 분리되는 날 회상 번리가 멈추기 때문입니다. 콘텐츠는 나중에 마이그레이션할 수 있습니다; 경계는 그것을 기다려서는 안 됩니다.

둘째, 계층 1에 예산을 세웁니다. 상주 파일에 문자 캡을 설정하고, 이미 그것들에 있는 것을 캡에 대해 감사하십시오. 도메인 특화 사실은 그들 거주지로의 포인터가 됩니다; 남은 것은 진정으로 모든 세션에 적용되는 것입니다.

셋째, 강등된 사실에 도착지를 주십시오. 도메인당 하나의 위키 디렉토리, 단일 작성자 및 변경 로그 규율과 함께, 계층 1이 방출한 것을 받습니다. 스킬은 그것을 가장 나중에 포인터를 집어들이며, 아직 존재하지 않는 디렉토리를 명시하는 스킬은 스킬이 없는 것보다 나쁘기 때문입니다.

계층 구조가 부패하는 곳

아키텍처는 유지보수만큼만 좋으며, 각 계층은 특징적인 방식으로 부패합니다.

계층 1이 먼저 채워집니다. 그것은 가장 편리한 쓰기 경로를 가진 계층(“그냥 이것을 기억해”)이므로, 위장한 도메인 사실을 가장 먼저 축적합니다. 예산은 이를 가시적으로 만듭니다: 저장소가 90% 가득 차면, 포인터가 되어야 하는 항목에 대해 감사하십시오. 수정은 항상 동일한 움직임입니다 — 사실을 계층 3으로 강등, 표지판을 승격.

계층 2가 두 번째로 크리프합니다. 스킬은 절차와 데이터가 함께 살기를 원하는 곳이며, “절차가 데이터를 constantemente 참조한다"는 것이 쓰기 시점에 합리적으로 느껴지기 때문입니다. 체크는 기계적입니다: 스킬 본문에 무언가에 대한 *진실의 원천(source of truth)*인 테이블이 포함되면, 그것은 위키에 속하며, 스킬은 경로를 가져야 합니다.

계층 4가 조용히 이탈(drift)합니다. 검색된 기억은 부가(append) 지향적이고 자기 설명적이므로, 오래된 에피소드는 절대 수정되지 않고, 단지 지워집니다. 회상 프롬블(“이 메모리는 역사적 컨텍스트이며, 검증된 사실이 아님”)은 표준 완화책입니다. 더 깔끔한 완화책은 계층 3이 사용하는 것과 동일한 것입니다: 에피소드가 지속 가능한 사실이 되었을 때(“고객은 이 날짜에 이 조항으로 서명했다”), 그것은 레코드 시스템에 쓰이며, 거기서 가시적이고 편집 가능하며, 뱅크는 내러티브만 유지합니다. 이 이탈의 더 날카로운 변형 — 에이전트의 자체 추론이 증거로 다시 쓰이는 것 — 은 Self-Reinforcing Memory Loops in AI Agents에서 구체적으로 다뤄집니다.

프로필이 증식합니다. 5개 프로필은 관리 가능합니다; 15개는 함대(fleet)입니다. 규율은 새로운 프로필이 새로운 도메인이 나타날 때만 등장하는 것입니다 — 새로운 프로젝트, 새로운 도구, 또는 새로운 기분이 아니라. 프로젝트 수준의 분리는 참조 계층의 디렉토리 구조를 위한 것이며, 도메인 수준의 분리는 프로필을 위한 것입니다. 두 가지를 혼동하는 것이 프로필 조오(zoo)와 명확하지 않은 회상 스토리로 이어지는 방법입니다.

핵심: 하나의 배치 규칙

모든 지식 조각을 그 트리거가 필요와 일치하는 가장 얕은 계층에 두십시오: 항상 필요한 사실은 포인터로 상주 기억에, 절차는 스킬에, 참조 데이터는 파일에, 에피소드는 뱅크에 — 그리고 각 도메인의 뱅크를 다른 도메인의 프로필이 회상할 수 없는 프로필 뒤에 두십시오. 그러면 에이전트는 잘 설계된 시스템처럼 행동합니다: 올바른 활동이 요청했기 때문에 올바른 지식이 존재하고, 컨버세이션 내에 그것에 대한 경로가 없기 때문에 잘못된 지식이 부재하며, 두 가지를 함께 강제할 수 있는 유일한 것은 구성 변경입니다 — 당신이 의도적으로 수행하는 것이며, 따라서 그것이 일어날 때 볼 수 있는 것.

평탄한 무더기는 결코 규율 실패가 아니었습니다. 그것은 모든 사실이 하나의 트리거를 공유하는 아키텍처였으며, 그 트리거는 “항상"이었습니다. 트리거를 나누면, 유출은 모델의 판단의 문제가 cease됩니다. 불가능해집니다.

참고 문헌

• PKM vs RAG vs 위키 vs 기억 시스템 비교 — 개인 지식 저장소, 검색 파이프라인, 에이전트 기억의 근본 비교
• AI 어시스턴트의 기억 시스템 — 이 계층 구조가 내부에 있는 런타임 기억 스택
• 지식 시스템에서 검색 vs 표현 — 당신의 저장소의 형태가 그것이 답할 수 있는 것을 결정하는 이유
• AI 시스템 메모리 허브