[메모리] 문맥 전환 감지 임베딩 유사도 한계 매턴 검색 회귀

이번 글은 성공담이 아니라 해보고 접은 이야기다. 그래도 왜 접었는지가 남으면 다음에 같은 길을 덜 헤맬 것 같아 적는다.

아이디어

에이전트가 사용자의 장기기억(메모리)을 참고해 답한다. 문제는 "언제 기억을 다시 불러오고 갱신할까"다. 가장 단순한 방법은 매 채팅마다 부르는 것이다. 확실하지만 무식하다.

그래서 이런 생각을 했다. 사용자가 축구 이야기를 하다가 영양제로 넘어가는 것처럼 문맥(주제)이 바뀌는 순간에만 기억을 갱신하면 되지 않을까. 문맥이 그대로면 굳이 다시 부를 필요가 없다.

문맥 변화는 임베딩으로 잡으려 했다. 최근 대화쌍 3개와 사용자의 최신 입력을 임베딩해서 유사도를 재고, 유사도가 충분히 낮으면 "주제가 바뀌었다"고 판단하는 식이다.

무엇이 막혔나

현실의 유사도 값이 뒤죽박죽이었다. 주제가 바뀐 지점에서 낮아지고 이어지는 지점에서 높아지길 기대했는데, 그런 깔끔한 경계가 없었다.

원인을 더듬어 보면, 비교하는 두 쪽의 형태가 애초에 달랐다. 한쪽은 "사용자 발화 + 봇 응답"이 묶인 대화쌍이고, 다른 한쪽은 사용자가 방금 친 짧은 한 줄이다. 길이도, 화자 구성도, 문체도 다른 둘을 같은 임베딩 공간에서 코사인 유사도로 비교하니 숫자가 주제 전환이 아니라 그 형태 차이에 더 휘둘렸다.

문턱값(threshold)을 어디에 둬도 오탐과 누락이 같이 늘었다. 형태를 맞춰 다시 설계할 수도 있었지만, 더 파고들 만큼 확신이 들지 않았다.

어떻게 했나

결국 문맥 변화 감지를 접었다. 지금은 매 턴 사용자 발화를 임베딩해서 관련 기억을 검색하는, 그 단순한 방식으로 돌아갔다. "문맥 바뀔 때만"이라는 영리함을 버리고, 매번 하는 무식함을 택했다.

대신 얻은 것도 있다. 분기 로직이 사라지니 동작이 예측 가능해졌고, "왜 이 턴엔 기억이 안 갱신됐지" 같은 디버깅거리가 없어졌다.

정리

• "필요할 때만"이라는 최적화는, 그 "필요"를 싸고 정확하게 판정할 수 있을 때만 이득이다
• 임베딩 유사도로 비교할 거면, 비교하는 양쪽의 형태(길이·화자·문체)부터 맞춰야 한다 — 형태가 다르면 유사도는 의미가 아니라 형태를 잰다
• 영리한 트리거가 불안정하면, 단순하고 예측 가능한 매번-실행이 나을 때가 있다
• 접은 것도 기록이다. 왜 안 됐는지가 다음 시도의 출발점이 된다

문맥이 바뀌는 순간을 기계가 알아채게 만드는 건, 생각보다 경계가 흐린 문제였다.