음성 에이전트가 CRM 필드를 완벽하게 채웠는데 결제가 하나도 안 됐네요
Our voice agent filled every CRM field correctly yet none of the payments went through
핵심 요약
음성 에이전트가 높은 신뢰도로 잘못된 정보를 입력해 결제 오류가 발생한 사례와 그 해결책을 논의합니다.
- 신뢰도 점수의 함정 — 모델이 잘못 들은 내용을 확신하며 입력하는 문제 발생함
- 검증 레이어 도입 — 정규식과 체크섬으로 오류를 걸러내지만 지연 시간 발생함
- 데이터 검증 한계 — 형식이 올바른 잘못된 값은 여전히 걸러내기 어려움
- 실시간 확인 필요 — 상담 중 숫자 되묻기나 키패드 입력 유도가 효과적임
우리 보이스 에이전트가 추심 전화 돌릴 때만 해도 신뢰도 점수 90% 넘게 찍히길래 다 잘 돌아가는 줄 알았거든? 근데 운영팀 누군가가 CRM 데이터 무작위로 뽑아서 실제 녹음본 들어보니까 상태가 진짜 개판이더라.
에이전트가 계좌번호 받아 적는데 숫자 하나를 틀려. 근데 모델은 자기가 들은 게 맞다고 확신하니까 신뢰도는 여전히 높게 나옴. 예를 들어 고객이 "fifteen twenty"라고 말하면 1520으로 알아들어야 하는데, 모델은 이걸 두 개 필드로 쪼개서 저장해버리는 식임. 이름 물어보면 그냥 비슷하게 들리는 흔한 이름으로 대충 때려 맞춤. 확신 없을 때 하는 짓이 딱 그거잖아, 정답이 아니라 확률 높은 단어 고르는 거.
근데 문제는 그 뒤에 있는 시스템들이 이걸 아무도 못 걸러냄. CRM 기록상으로는 멀쩡해 보이거든. 결국 3일 뒤에 결제 튕기고 나서야 난리 나는데, 아무도 이게 에이전트 탓인 줄 모름. 우리는 필드 완성률 높다고 자축하고 있었는데, 사실 절반은 개소리였던 거지 ㅋㅋ
그래서 지금은 에이전트랑 CRM 사이에 검증 레이어를 하나 더 넣었어. IFSC 코드는 정규식으로 맞추고, 계좌번호는 길이랑 체크섬 확인하고, 이름은 문자 단위 신뢰도 떨어지면 일단 보류함. 검증 통과 못 하면 상담원 연결해서 통화 중에 바로 확인하게 바꿨지. 3일 뒤에 결제 실패하고 나서야 뒤늦게 아는 것보다는 훨씬 나으니까.
근데 이거 때문에 필드 하나당 1초씩 더 걸림. 안 그래도 추심 전화라 고객들 빡쳐 있는데 1초가 어디냐고. 게다가 이렇게 해도 잘못된 데이터 70% 정도밖에 못 걸러냄. 형식은 맞는데 그냥 엉뚱한 사람 계좌인 경우는 검증 단계에서 답도 없거든.
결국 모델 단에서 해결해야 할 문제를 뒤에서 땜질하고 있는 꼴인데, gnani나 몇몇 업체들은 아예 음성 스택 내부에서 엔티티 추출을 하더라고. '음성 인식 후 검증'이 아니라 처음부터 그렇게 하면 이 개고생 안 해도 될 텐데, 정작 그렇게 하는 곳을 나만 모르는 건가?
