음성 에이전트에게 P50 메모리 검색 속도 15ms는 아무 의미가 없다

요즘 메모리 툴 만드는 놈들 죄다 '검색 지연 시간(retrieval delay)' 짧다고 광고하는데, 그거 하나만 봐서는 아무 의미 없다.

음성 에이전트에 메모리 기능 넣어보니까 바로 알겠더라.

내가 겪은 한계

음성 대화는 사용자 말이 끝나고 첫 오디오가 출력되기까지 시간 제한이 빡빡하다. 여기서 시간 너무 끌면 사용자는 전화 끊긴 줄 알고 다시 말하기 시작하는데, 그럼 '바지 인(barge-in)' 터지면서 다음 턴까지 다 꼬여버림.

캐스케이드 스택은 그 시간을 음성 감지, TTFT(첫 토큰 생성 시간), 음성 합성, 전송으로 쪼개 쓰는데, 이거 다 하고 나면 남는 시간이 거의 없어서 메모리는 그 좁은 틈에 딱 맞춰 들어가야 한다.

문제 1: P50은 지표로 쓸 게 못 됨

통화는 한 번의 턴이 아니라 여러 턴이 이어지는 거라, 통화 몇 번만 해봐도 P99에서 무조건 문제 터진다. 사용자는 제일 느린 턴을 체감하게 되고, 에이전트가 말하다가 갑자기 벙어리 된 것처럼 느껴짐.

나도 전체 평균이 아니라 턴별로 측정하고 나서야 꼬리 지연 시간(tail latency)을 잡을 수 있었다. 특히 링크 수백 개 달린 엔티티 그래프 탐색할 때가 문제임. 상호작용 200번 한 고객이랑 5번 한 고객은 검색 데이터 양이 차원이 다른데, 깨끗한 테스트 환경에서 P50만 보면 절대 안 보인다.

메모리 레이어 평가할 거면, 실제 데이터 넣고 동시성 환경에서 P99 수치 까보라고 해라.

문제 2: 검색이 응답을 가로막음

기본 흐름이 (음성 종료 - 전사 - 검색 - 프롬프트 구성 - 모델 호출) 순서인데, 이러면 사용자가 침묵하는 그 짧은 시간에 검색을 때려 박는 꼴이라 1ms가 아쉬운 상황에서 지연 시간이 그대로 체감된다.

해결책은 프리페칭(prefetching)이다. 스트리밍 전사로 사용자가 말하는 도중에 부분 결과를 받아서 미리 검색을 돌려놓으면, 말 끝날 때쯤엔 메모리가 이미 준비되어 있다. 프리페칭만 제대로 하면 검색 속도는 데이터 못 찾았을 때(miss)만 신경 쓰면 됨.

문제 3: 검색은 빠른데 결과가 너무 많으면 더 골치 아픔

이 정도 규모에선 주입된 토큰이 TTFT를 거의 선형적으로 늘려버린다. 15ms 만에 검색 끝내도 프롬프트에 토큰 수천 개 쏟아부으면, 검색으로 아낀 시간보다 토큰 처리하느라 늦어지는 시간이 더 커짐. 벤치마크 점수는 잘 나올지 몰라도 실제 턴은 망하는 거다.

나는 'Top K' 대신 '토큰 예산(token budget)'으로 생각하기 시작했다. 여러 저장소에서 랭킹 매기고 예산 꽉 찰 때까지 채운 다음, 토큰 값어치 없는 건 다 쳐내라. 그리고 음성 에이전트 쓸 거면 시스템 프롬프트에서 마크다운 다 빼라. 음성 합성 꼬이고, 쓸데없는 문자 때문에 프리필(prefill) 비용만 더 나간다.

문제 4: 사용자가 말하다가 마음 바꿈

예를 들어 "화요일에 예약해 줘. 아, 아니 목요일 오후로 해줘." 같은 경우.

이럴 때 검색 지연 시간이 짧아야 잘못 예측했을 때 복구 비용이 줄어든다. 나는 모든 프리페칭을 '추측성(speculative)'으로 처리하고, 모델에 넘기기 전에 최종 전사본이랑 대조해서 검증한다.

이거 만드는 놈들을 위한 조언

1. 실제 데이터 밀도가 반영된 저장소에서, 동시성 환경으로 턴별 P99를 측정해라.

2. 부분 전사본으로 프리페칭 돌려라.

3. 결과 개수가 아니라 토큰 단위로 메모리 예산을 짜고, 주입하는 데이터가 TTFT에 미치는 비용을 계산해라.

4. 특정 구간 최적화하기 전에 전체 체인부터 계측해라.

궁금한 거 있으면 다 물어봐라. 질문 환영 :)