왜 내 에이전트는 프로젝트를 잊어버리는가: 메모리 계층 불일치

세션 1. 인증 헬퍼(auth helpers)는 어디에 있나요?
src/lib/auth/

...

같은 질문. 같은 프로젝트. 6번의 세션이 지난 후.

에이전트가 더 멍청해진 것이 아닙니다.

답변이 머무를 장소가 없었을 뿐입니다.

대부분의 팀은 에이전트의 메모리(Memory)를 하나의 요소, 즉 대화창(Conversation window)으로 취급합니다.

에이전트에게 무언가를 말하면 채팅이 끝날 때까지 그것을 유지하지만, 채팅이 종료되면 지식도 함께 사라집니다.

그것은 네 가지 메모리 유형 중 하나일 뿐입니다. 나머지 세 가지가 실제로 정보 보존(Retention)이 이루어지는 곳이지만, 거의 아무도 이를 채우지 않습니다.

증상은 망각처럼 보이지만, 사실은 잘못된 분류입니다.

에이전트가 당신이 지난주에 답변했던 것을 다시 물어볼 때, 본능적으로 "기억력이 없다"고 생각하게 됩니다.

에이전트는 충분한 메모리를 가지고 있습니다. 당신이 답변을 잘못된 선반에 올려두었을 뿐입니다.

저는 동일한 장기 프로젝트에 대해 수백 번의 세션 동안 다계층 메모리(Multi-tier memory) 설정을 실행해 보았습니다. 패턴은 일정했습니다. 망각은 거의 모델의 한계 때문이 아닙니다. 그것은 배치(Placement)의 오류입니다.

네 가지 계층 (The four tiers)

에이전트의 메모리를 하나의 서랍이 아닌 네 개의 선반이라고 생각하십시오.

계층 1. 작업 메모리 (Working memory). 실시간 대화입니다. 빠르고 풍부하지만, 대화창이 압축되거나 세션이 종료되는 순간 사라집니다. 이것이 대부분의 팀이 사용하는 유일한 계층입니다. 또한 재시작 시 살아남을 수 없는 유일한 계층이기도 합니다.

계층 2. 세션 핸드오프 (Session handoff). 에이전트가 세션 끝에 작성하고 다음 세션 시작 시 읽는 짧은 메모입니다. 정확히 하나의 경계(Boundary)를 넘어 생존합니다. "우리가 무엇을 하고 있었고 무엇이 남았는지"에 대한 내용이 여기에 속합니다.

계층 3. 지속 가능한 프로젝트 메모리 (Durable project memory). 모든 세션에 걸쳐 유효한 사실들입니다. 컨벤션(Conventions), 결정 사항, 코드 자체로는 설명되지 않는 선택의 이유 등이 포함됩니다. 이것이 반복적인 질문을 막아주는 계층입니다. 또한 거의 모든 사람이 비워두는 계층이기도 합니다.

계층 4. 참조 (Reference). 코드, 문서, 외부 지식입니다. 기본적으로 로드되지 않습니다. 작업에 필요할 때 요청에 따라 불러옵니다. 규모가 크고 권위가 있으며, 대화창으로 끌어오는 데 비용이 많이 들기 때문에 관련이 있을 때만 사용합니다.

불일치 (The mismatch)

실패의 원인을 한 문장으로 요약하면 다음과 같습니다.

팀들은 지속적인 사실(durable facts)을 Tier 1에 쏟아붓고는, Tier 1이 증발할 때 놀란 척을 합니다.

채팅에서 설명한 관습은 Tier 1 선반에 놓인 Tier 3 사실입니다.

"Y 때문에 X를 하지 않기로 결정했습니다"라는 내용은 Tier 1의 옷을 입고 있는 Tier 3입니다.

컨텍스트 윈도우(window)가 압축될 때 그 사실도 함께 사라지며, 에이전트는 이를 다시 유도하거나 다시 질문하게 됩니다.

모델은 잊어버린 것이 아닙니다. 당신이 영구적인 것을 일시적인 용도로 설계된 곳에 저장했을 뿐입니다.

무엇을 어디에 둘 것인가 (What goes where)

제가 사용하는 배치 규칙은 지루하지만 효과적입니다.

• 사실이 오직 이 작업(task)에만 유효하다면, Tier 1에 남겨두세요.
• 사실이 이번 세션(session)의 나머지 동안 유효하다면, Tier 2에 기록하세요.
• 사실이 프로젝트의 수명 동안 유효하다면, Tier 3로 승격시키세요.
• 사실이 방대하고 권위 있으며 가끔씩만 관련이 있다면, Tier 4에 두고 검색(retrieve)하여 사용하세요.

어려운 점은 규칙이 아닙니다. 어려운 점은 사실이 나타날 때마다 "이것이 얼마나 오랫동안 유효한가"를 묻는 규율(discipline)입니다.

그 질문 하나가 시스템의 대부분을 차지합니다.

무엇이 문제를 해결하지 못하는가 (What does not fix it)

대부분의 팀이 가장 먼저 시도하는 반사적인 대응들입니다.

더 큰 대화 윈도우(conversation window). 그것은 더 긴 Tier 1을 살 수 있게 해줄 뿐입니다. Tier 3를 제공하지는 않습니다. 사실은 여전히 압축 시점에 사라지며, 단지 더 빨리 사라지느냐 아니면 나중에 사라지느냐의 차이일 뿐입니다.

매 세션마다 더 상세한 프롬프트(prompt)를 작성하는 것. 그것은 당신이 Tier 3의 업무를 영원히 수동으로 수행하는 것입니다. 당신이 잊어버리는 날까지는 유지되겠지만, 당신은 결국 잊게 될 것입니다.

"기억하는" 두 번째 에이전트. 이제 당신은 두 개의 Tier 1 선반을 갖게 되었고, 동일한 오분류(misfiling) 문제가 두 배로 실행될 뿐입니다.

이것들 중 나쁜 도구는 없습니다. 잘못된 계층(tier)을 겨냥한 올바른 도구들일 뿐입니다.

제가 붙여넣지 않은 부분 (The part I am not pasting)

저는 이 아래에 특정한 배선(wiring)을 실행합니다. 각 계층에 무엇이 사는지, Tier 1 사실이 어떻게 Tier 3로 승격되는지, 계층이 언제 가지치기(pruned)되는지, 그리고 검색(retrieval)이 Tier 4에서 무엇을 가져올지 결정하는 방식에 관한 것입니다.

그 메커니즘이 핵심적인 작업이며, 새로운 실패 모드, 즉 로드되는 모든 세션을 오염시킬 때까지 무한히 커지는 Tier 3를 만들지 않고 제대로 구현하는 것은 매우 어렵습니다.

위의 계층 모델은 당신의 사고방식을 바꾸는 부분입니다.

승격(Promotion) 및 제거(Eviction) 정책이 실제 구현의 핵심적인 부분입니다.

질문

제가 접하는 "에이전트가 기억력이 없다"라는 대부분의 불만 사항은 Tier 3가 한 번도 채워진 적이 없는 경우입니다.

그래서 저는 당신의 망각이 실제로 어디에서 발생하는지 알고 싶습니다.

당신의 에이전트가 알고 있어야 할 내용을 다시 물어볼 때, 정답이 어느 계층(Tier)에 있어야 했으며, 실제로 당신은 그것을 어느 계층에 저장했습니까?

당신의 에이전트가 마지막으로 잊어버린 내용을 댓글로 남겨주세요. 잘못된 파일 분류(Misfiling) 패턴이 제 데이터 외의 사례에서도 동일하게 나타나는지 확인하고 싶습니다.