Salesforce Engineering 블로그에서 Agentforce의 “Agentic Memory”를 어떻게 설계했는지 솔직하게 풀어낸 글이 올라왔습니다. 대화 히스토리를 프롬프트에 길게 붙이는 방식이 왜 엔터프라이즈에서 한계가 있는지, 그 대신 메모리를 “프롬프트 텍스트”가 아니라 “구조화된 데이터 레이어”로 분리해 운영 가능(거버넌스/감사/수명주기 관리)하게 만드는 접근을 설명합니다.
글에서 특히 인상적인 포인트는 “세션 컨텍스트- 단기 메모리”와 “프로필 그래프에 붙는 장기 메모리”를 분리해, 채널/세션이 달라도 일관된 기억을 제공하되 엔터프라이즈 통제(검증, 삭제/갱신, 접근제어, 설명가능성)를 유지하는 구조입니다. 또한 무엇을 저장할지(너무 많이 저장하면 노이즈, 너무 적게 저장하면 효용 부족)와 정확성/신선도(서로 다른 소스 간 충돌, 오래된 정보의 재등장) 문제가 실무에서 가장 어렵다고 짚습니다.
요약하면, 이 글은 “메모리를 잘 쓴다, 기억을 잘 활용한다”를 아래처럼 엔지니어링 문제로 쪼개서 답합니다.
- 메모리를 구조화 레코드로 외부화하고, 타입/시간/출처/신뢰도(confidence)/수명주기 제어를 붙여 “검사 가능하고 관리 가능한 상태”로 만든다.
- 런타임에는 매 턴마다 지연/비용 제약이 있으니, 컴팩트한 메모리 + 사전 계산 임베딩 + 유사도 검색으로 후보를 좁히고, 세션 캐싱과 “작은 모델은 저렴한 단계(추출/검증), 큰 모델은 필요한 순간”이라는 비용 최적화를 적용한다.
- 저장(write)과 조회(read) 모두에 게이트(필터)를 둬 품질을 지키고, 벡터 유사도만이 아니라 의미 기반 검증(hybrid semantic validation)으로 중복/드리프트를 줄인다.
- 대화만이 아니라 Service Cloud의 상담 기록, 봇 대화, 커넥터로 들어오는 문서/데이터 등도 “메모리 후보”로 흡수할 수 있게 파이프라인을 설계했다는 점도 언급됩니다.
엔터프라이즈 에이전트를 실제로 운영해보신 분이라면 “왜 이게 필요하고, 어디서 사고가 나는지”를 거의 그 문제 그대로 다루고 있어서, Agentforce/에이전트 아키텍처 관심 있으시면 한 번 읽어보실 만합니다.
https://engineering.salesforce.com/how-agentic-memory-enables-durable-reliable-ai-agents-across-millions-of-enterprise-users/
Escrever um comentário...
0/9000