여러 에이전트에 하나의 추출 설정을 적용하면 전부 망가진다

처음에 메모리 기능을 출시했을 때는 모든 걸 통틀어 설정 하나만 썼거든. 그러다 보니 어떤 에이전트도 제대로 된 메모리를 못 쓰고 전부 어중간한 성능만 내는 꼴이 됐지.

에이전트 유형별로 뭐가 다른가

똑같은 고객이랑 같은 주에 대화하는 서포트 에이전트랑 영업 에이전트를 예로 들어보자.

서포트 에이전트는 티켓 맥락, 채널 기록, 상호작용 전반의 감정 변화 추이가 필요해. 이 사람이 같은 문제로 세 번이나 전화했고 점점 더 짜증이 났다는 걸 알아야 하고, 해결된 문제는 과감하게 잊어버려야 해. 새로운 대화에서 낡은 티켓 맥락이 튀어나오면 독이 되거든. 에이전트가 2주 전에 해결된 문제를 들먹이면 고객은 "아무것도 안 했구나"라고 생각할 테니까.

영업 에이전트는 거래 상태, 이해관계자 매핑, 거절 이력, 경쟁사 언급 내용이 필요해. 잃어버린 거래는 절대 잊으면 안 돼. 나중에 비슷한 계정이 파이프라인에 들어왔을 때 그 실패 패턴이 엄청난 자산이 되거든. 거절 이력도 계속 반복되니까 무기한 보관해야 하고.

고객은 같은데 추출 규칙이랑 저장 우선순위는 완전히 다른 거야.

설정이 결정하는 것들

전역 설정이 아니라 에이전트별로 네 가지를 정해.

추출 규칙은 대화에서 뭘 뽑아내고 어떻게 유형을 나눌지 결정해. 서포트 추출은 문제 상태, 해결 단계, 채널 전환, 감정을 잡아내지. 영업 추출은 거래 단계 변화, 이해관계자 관계, 거절 내용, 경쟁사 정보를 잡아내고.

메모리 유형 가중치는 각 유형에 검색 예산을 얼마나 배정할지 조절해. 서포트 에이전트는 최신성이랑 순서가 맥락이라 시간적 이벤트나 에피소드에 가중치를 많이 둬. 영업 에이전트는 거래 그래프가 맥락이라 사실 관계나 엔티티 관계에 가중치를 많이 두고.

감쇠 윈도우는 에이전트별 메모리 유형마다 달라. 서포트 에이전트는 해결된 문제를 며칠 내로 날려버리지만, 영업 에이전트는 실패 패턴을 몇 달씩 들고 있어.

검색 랭킹은 세 가지 저장소(의미론적 유사성을 위한 벡터, 엔티티 관계를 위한 그래프, 출처 증명을 위한 파일)에서 나온 결과물을 턴당 토큰 예산에 어떻게 배분할지 결정해. 서포트는 최신성이랑 감정을 높게 치고, 영업은 엔티티 관계랑 거래 단계를 높게 치지.

기본 설정 하나가 조용히 망하는 이유

문제는 틀린 정보를 아주 당당하게 가져온다는 거야.

서포트에 맞춘 설정 하나로 영업 대화를 처리하면 감정이나 문제 상태만 뽑아내. 영업 통화 메모리가 "고객이 가격에 대해 우려함"이 되어버리는 거지. "엔지니어링 VP가 지연 시간을 차단 요소로 지목함, 벤치마크 요청 보냄, 목요일에 팔로업 예정" 같은 핵심 정보는 다 날아가고.

영업에 맞춘 설정 하나로 다 돌리면 모든 걸 무기한 보관해. 서포트 에이전트가 3개월 전 해결된 티켓 맥락을 가져와서 "API 연동에 문제 있으셨죠?"라고 아는 척하는데, 정작 고객은 결제 문제로 전화한 상황이 벌어지는 거야.

CDN이랑 데이터베이스에 똑같은 캐싱 정책 쓰는 거랑 똑같은 꼴이지.

생성 과정

이런 설정을 일일이 손으로 짤 필요는 없어. 에이전트를 등록할 때 하는 일, 도메인, 성공의 기준을 설명하면 시스템이 알아서 맥락 아키텍처, 추출 규칙, 유형 가중치, 감쇠 윈도우, 검색 랭킹을 다 만들어내거든. 물론 나중에 수정도 가능하고, 대부분 팀은 실제 운영 환경에서 에이전트가 뭘 가져오는지 보고 감쇠 윈도우를 조정해.

설정은 검색뿐만 아니라 추출까지 관여해. 데이터가 저장소에 들어가는 시점에 이미 뭘 추출할지, 어떻게 유형을 나눌지, 얼마나 보관할지 결정이 끝난 상태거든. 나중에 검색 설정을 바꿔봤자 이미 있는 걸 재정렬할 뿐, 애초에 추출되지 않은 정보는 살려낼 수가 없어.

내가 확인해볼 것

여러 에이전트 유형에 설정을 하나만 쓰고 있다면, 각 에이전트가 최근에 검색한 결과 100개씩 뽑아봐. 결과가 나왔냐 아니냐가 아니라, '제대로 된 종류'의 결과가 나왔는지를 읽어보라고. 전체적인 적중률은 괜찮아 보여도 에이전트별로 뜯어보면 특정 에이전트만 잘 나오고 나머지는 희생당하고 있을 가능성이 커.