AI 에이전트의 메모리 접근 방식이 잘못된 걸까?

정말 좋은 프레임워크네요. 저도 벡터 DB를 메모리로 쓰는 지름길에 빠졌었는데, 어느 정도까진 잘 되다가 결국 한계가 오더라고요.

실제로 도움이 됐던 것들:

• 에피소드 메모리와 의미 메모리를 명확히 분리하세요. 에피소드 메모리는 이번 세션/작업에서 무슨 일이 있었는지, 의미 메모리는 추출된 사실/선호도를 의미합니다. 워크플로우의 다른 지점에서 이들을 검색하는 게 큰 차이를 만듭니다.
• 검색 단계 전에 '메모리 스코어러'를 작성하세요. 저장된 메모리가 현재 작업과 실제로 관련이 있는지 묻는 작은 LLM 호출을 추가하는 거죠.

통찰력 있는 의견 감사합니다. 특히 에피소드 메모리와 의미 메모리를 구분하고 검색 전에 메모리 스코어러를 도입한다는 아이디어가 좋네요. 단순히 top-k 결과를 주입하는 것보다 훨씬 깔끔한 접근 방식인 것 같습니다. 현재 CogniCore는 무엇을 저장할지 결정할 때(성공/실패 결과, 리플렉션, 카테고리, 메타데이터 등) 주로 규칙 기반 방식을 사용하고 있지만, 더 적응형인 전략을 적극적으로 모색 중입니다. 저희가 관심 있는 방향 중 하나는 결정론적 규칙을 결합하는 것입니다.

네, 하이브리드 접근 방식이 일리가 있네요. 규칙을 저렴한 1차 필터로 사용하고, 실제로 통과한 것들에 대해서만 LLM 평가기를 호출하는 거죠. 모든 것에 무거운 판단 과정을 돌릴 필요는 없으니까요.

제가 계속 궁금한 건 피드백 루프를 어떻게 닫느냐는 거예요. 예를 들어 평가기가 10번 실행 전에 뭔가를 저장할 가치가 있다고 판단했다면, 그게 정말 옳은 결정이었는지 어떻게 알 수 있죠? 그게 도움이 된 건지, 아니면 그냥... 방해가 안 된 것뿐인지요? 그 간극은 작업별 평가 없이는 측정하기가 참 어려운 것 같아요.

메모리를 저장하는 건 쉽지만, 저장할 가치가 있었다는 걸 증명하는 건 훨씬 어렵죠. 저희가 탐구 중인 아이디어 중 하나는 각 메모리에 시간이 지남에 따라 진화하는 '유틸리티 점수'를 부여하는 겁니다. 검색 여부, 성공적인 결과에 기여했는지 여부, 무시되었는지, 혹은 부정적인 전이(negative transfer)를 유발했는지에 따라 점수가 바뀌죠. 저장을 일회성 결정으로 보지 않고, 시스템이 메모리의 수명 주기 동안 지속적으로 재평가하게 만드는 겁니다. 결국 런타임 신호와 작업 평가의 조합이 답이 되지 않을까 싶습니다.

유틸리티 점수 아이디어 흥미롭네요. 저장을 일회성 쓰기가 아닌 지속적인 판단 과정으로 보는 건 메모리가 실제로 작동해야 하는 방식에 훨씬 가깝게 느껴집니다.

부정적인 전이 신호는 주의 깊게 지켜봐야 할 것 같아요. 성능을 적극적으로 저해하는 메모리는 그냥 사용되지 않고 방치되는 메모리보다 더 나쁘니까요. 그리고 피해가 발생하기 전까지는 둘을 구분하기가 어려울 것 같고요.

런타임 신호와 작업 평가를 결합하는 게 말이 되네요. 솔직히 그보다 더 깔끔한 해결책은 없을 것 같습니다. 좋은 논의네요.