𝗦𝗮𝗹𝗶𝗲𝗻𝗰𝗲 𝗶𝘀 𝗡𝗼𝘁 𝗖𝗮𝗿𝗿𝘆 𝗩𝗮𝗹𝘂𝗲
현저성(Salience)은 전달 가치(Carry Value)가 아닙니다.
대부분의 사람들은 에이전트 메모리를 잘못 구축합니다.
그들은 저장에 집중합니다. 벡터 스토어나 영리한 요약기를 사용하죠. 모든 것을 저장하면 에이전트가 모든 것을 알게 될 것이라고 생각합니다.
그들은 틀렸습니다.
수백 개의 세션이 쌓이면 그 모든 것을 읽을 수 없습니다. 에이전트가 아무런 정보 없이 새로운 세션을 시작하면 시간을 낭비하게 됩니다. 반대로 너무 많은 노이즈와 함께 시작하면 실수를 저지릅니다.
문제는 선택입니다. 대부분의 사람들은 현저성(salience)과 전달 가치(carry value)를 혼동합니다.
- 현저성은 지난 세션에서 무엇이 강렬했는지를 알려줍니다.
- 전달 가치는 다음 세션이 작동하는 데 무엇이 필요한지를 알려줍니다.
변수 이름에 대한 격렬한 논쟁은 현저성이 높습니다. 하지만 그 이름이 향후 코드에 영향을 미치지 않는다면 전달 가치는 제로입니다. 이를 계속 가져간다면 그저 노이즈를 추가하는 꼴이 됩니다.
저는 다음과 같은 규칙을 기반으로 메모리 파이프라인을 운영합니다:
우선 기계적 현저성(Mechanical salience)을 확보하세요. 결정론적 스코어러(deterministic scorer)를 사용하여 중요한 순간을 찾으세요. 단순한 코멘트보다 수정 사항에 더 높은 가중치를 두어야 합니다. 모든 하이라이트는 원본 트랜스크립트와 연결되어야 합니다. 모델이 출처 없이 사실을 지어내게 두지 마세요.
그다음은 합성(Synthesis)입니다. LLM은 하이라이트에 의미의 층을 더하는 용도로만 사용하세요. 하이라이트 자체가 부실하다면, 요약은 그저 자신만만한 헛소리가 될 뿐입니다.
검색 시점의 브리프(retrieval-time brief)를 활용하세요. 모든 프로젝트에 대해 INDEX.md와 같은 파일을 만드세요. 에이전트는 세션 시작 시 이 파일을 읽습니다. 어떤 모델도 이 브리프를 즉석에서 만들어내서는 안 됩니다. 사용자가 직접 열고 편집할 수 있는 일반 파일이어야 합니다.
더 나은 메모리를 구축하려면 단순히 중요한 항목들의 목록 그 이상이 필요합니다. 다음과 같은 것들이 필요합니다:
- 두 가지 점수: 얼마나 강렬했는지(salience)와 나중에 얼마나 중요한지(carry value)를 나타내는 점수.
- 메모리 클래스: 활성 결정(active decisions), 운영 제약 사항(operating constraints), 미결 사항(open loops)을 분리하세요.
- 만료일: 모든 메모리 조각은 사라져야 할 이유가 있어야 합니다. 만료 기한이 없으면 컨텍스트가 시스템을 가로막습니다.
- 트리거: 메모리 조각이 언제 나타나야 하는지 정확히 정의하세요.
목표는 복구 비용(recovery cost)을 최소화하는 것입니다.
복구 비용이란 에이전트가 중단된 지점까지 따라잡는 데 걸리는 토큰 수나 시간을 의미합니다. 메모리 파이프라인이 그저 보여주기식(theater)이라면, 복구 비용은 계속 높게 유지될 것입니다.
더 큰 저장소를 만드는 것을 멈추고, 더 나은 선택 시스템을 구축하기 시작하세요.
Source: https://dev.to/jugeni/salience-is-not-carry-value-notes-from-a-running-session-memory-pipeline-4dda
Optional learning community: https://t.me/GyaanSetuAi