AI의 지속적 메모리(persistent memory)는 갈 길이 멀다

정확합니다. 에이전트 메모리와 종종 혼동되는 또 다른 지속성 계층이 있는데, 바로 사용자의 라이브 환경입니다. 메모리 원장은 '내가 X에 로그인했다'는 건 기억할 수 있지만, 프로필, 쿠키, 탭, 출처, 인간의 개입 상태를 다시 구축하지 않고는 안전하게 재현할 수 없습니다. 저는 로컬 지속성 브라우저/MCP 계층인 Hronaut을 유지 관리하고 있는데, 우리는 이걸 모델 컨텍스트와 분리된 작업 공간 상태로 취급합니다: 격리된 작업 공간, 명시적 권한, 가시적 탭, 그리고 쓰기 후 증거. 그 분리...

저도 그런 걸 하나 만들었는데, AI 채팅 기능(AI용 왓츠앱)도 있어서 전부 같은 메모리, 컨텍스트, 코드를 공유하고 서로 대화할 수 있습니다.

각 플랫폼/프로젝트와 앱 내의 모든 앱, 각 앱에 대한 모든 문서를 유지하고, 태그와 인용 및 검증 시스템을 갖췄으며, 모든 항목과 로드맵 항목을 기록합니다. 커밋은 수동으로 트리거하거나 AI가 완료하고, 혹은 AI에 의해 자동으로 트리거됩니다. 데이터베이스는 세션에서 병합된 문서들로 업데이트됩니다...

우리는 나이에 따른 감쇠가 잘못된 기본값이라는 걸 발견했습니다. 6개월 전의 은행 승인이 어제 먹은 점심 취향보다 더 중요할 수 있거든요. 쓰기 작업에는 유형 + 출처 + 유효 날짜 + 누가 대체할 수 있는지가 필요합니다. 검색은 최신 권한을 우선시해야지, 최신 텍스트를 우선시해서는 안 됩니다. 그러면 모순은 순위를 두고 경쟁하는 두 임베딩이 아니라 해결되지 않은 상태가 됩니다.

우리가 해야 할 일은 꿈꾸는 게 실제로 무슨 역할을 하는지 알아내는 것뿐입니다!

나도 에이전트 프로젝트에 영구 메모리(persistent memory)를 쓰고 있는데, 보통 문제가 생기는 건 한 프로젝트에선 맞았던 선호 사항이 다음 프로젝트에도 그대로 적용될 때임. 기록상으론 뭐가 잘못된 건지 표시가 안 되어 있으니까. '짧은 답변 선호'라고만 되어 있으면 누가 짧게 해달라는 건지 알 수가 없어서, 읽을 때 판단하는 게 아니라 항목 자체에 스코프(scope)를 지정해야 함.

동의함. 상태 관리 문제 맞음. 그래서 사람들이 메모리를 벡터 DB 문제로만 보지 말고 데이터베이스 문제로 접근해야 한다고 생각함. Lakebase(Databricks의 관리형 Postgres)가 딱임. 이건 진짜 트랜잭션 데이터베이스라서 중복 제거, 모순 해결, 통합 같은 작업이 그냥 트랜잭션 내에서 upsert나 행 교체로 처리됨. 그냥 임베딩을 계속 추가하면서 리랭커(reranker)가 알아서 해주길 바라는 방식이 아님. pgvector가 같은 DB에 있으니까 '의미론적...'

평가 세트에 명시적인 '망각(forgetting)' 케이스를 추가하고 싶음. 선호 사항을 저장하고 요약에 포함시킨 다음, 시스템에 그걸 잊으라고 시키는 거지. 요약이나 파생된 메모리가 계속 컨텍스트에 다시 집어넣는다면 원본 항목을 삭제하는 것만으론 부족함. 이건 단순히 회상(recall)이 정확한지를 넘어 메모리 수명 주기를 제어할 수 있는지를 테스트하는 거임.

네가 나열한 것들이 어려운 부분인 건 맞는데, 설계 단계에선 안 보이지만 시스템 전체를 말아먹을 수 있는 운영상의 실패 지점이 있어. 바로 '아무것도 반환하지 않은 메모리'와 '고장 난 메모리'를 구분할 수 없다는 거야. 나도 persistent store를 가진 에이전트를 운영 중인데, 하루 종일 빈 결과값만 반환하는데도 아무도 눈치채지 못했어. 서비스는 정상이었고, 쿼리도 잘 작성됐고, 응답도 잘 나왔거든. '없음'이라는 결과도 정당한 답변일 수 있으니까. 메모리 시스템에 던지는 대부분의 쿼리는...

내가 계속 부딪히는 문제는 저장 공간이 아니라 데이터의 '신선도'야. 기록될 당시엔 사실이었지만 아무도 다시 확인하지 않는 메모리 말이지. 코드의 경우엔, 저장소 구조의 일부로 기록해서 설명하는 대상과 같은 커밋에서 변경되도록 하는 방식을 썼어. 그 외의 모든 것들에 대해선, 모든 메모리에 타임스탬프와 출처를 남기는 게 정답이야. 그래야 에이전트가 이게 최신 사실인지, 아니면 화석 같은 정보인지 구분할 수 있으니까.

네가 나열한 메커니즘들 다 실존하는 거긴 한데, 결국 난 주제별로 그냥 마크다운 파일만 쓰게 됐고 벡터 DB는 아예 안 씀. 중복 제거, 모순 처리, 데이터 소멸 같은 것들은 사람이 직접 파일을 열어서 줄 수정하는 순간 연구 과제에서 제외됨. 뭐가 잘못됐는지 바로 보이니까. 관리형 메모리 서비스들은 절대 못 해주던 거임. 비싼 아키텍처는 상태를 쓰는 사람이 여러 명일 때나 제값 하는 거지. 사용자 한 명이나 클라이언트 프로젝트 하나 정도면, 그냥...