음성 에이전트가 말 듣는 동안 추론과 도구 호출을 미리 끝내 대기 시간을 줄인다

무엇인가

이 논문이 푸는 문제는 도구를 쓰는 음성 에이전트가 사용자가 말을 마친 뒤에도 기다리게 만든다는 것이다. 답에 필요한 정보는 발화 도중에 이미 등장하는데, 기존 캐스케이드 파이프라인은 모델 연산과 외부 도구 실행이라는 준비 작업을 발화 종료 이후에 배치한다. 부분 발화에서 추론을 시작하는 선행 연구도 있지만, SHANKS는 생성 에피소드를 음성 청크 단위로 잘라 도구 호출 인자가 완성되기 전에 생성을 끊을 수 있고, SIA는 새 이벤트가 들어올 때 진행 중 생성을 인터럽트해 호출이 발행되기 전에 중단될 수 있다. 결국 계산 시간이 발화 업데이트에 묶여, 미리 끝내둘 수 있는 일의 양이 제한된다는 것이 저자들의 진단이다.

어떻게 동작하나

제안 방법인 Heartbeat Thinking의 핵심은 새 입력을 새 호출로 처리하면서 이미 진행 중인 호출과 디스패치된 도구는 끝까지 실행하게 두는 것이다. 듣는 동안 Δ초마다 새 Thinker 호출이 최신 부분 트랜스크립트와, 완료된 추론 및 도구 결과를 담은 공유 레코드를 읽는다. 동시 실행 호출 수는 최대 K개로 제한되며 슬롯이 모두 차 있으면 트리거는 건너뛴다. 새 발화나 도구 결과는 다음 호출의 입력으로 들어갈 뿐 진행 중인 생성을 방해하지 않는다. 한 호출은 아무 행동도 하지 않거나, 추론만 반환하거나, 구조화된 인자를 붙여 도구를 요청할 수 있다. 완료된 추론은 도구를 비동기로 디스패치하기 전에 기록되므로 모델 실행과 도구 실행이 겹칠 수 있고, 이후 호출은 반환된 결과를 이용해 빠진 인자를 채우거나 의존 호출을 새로 시작할 수 있다. 트랜스크립트가 갱신되지 않은 시점에도 준비가 전진한다는 뜻이다. 프롬프트는 같은 이름과 인자를 가진 대기 중이거나 완료된 호출을 반복하지 않도록 지시하고, 도구 실행 큐는 Thinker 스케줄링과 분리해 관리한다.

무엇과 다른가

응답 핸드오프는 투기적 준비와 최종 응답 생성을 분리하는 장치다. 발화 종료가 감지되면 스케줄러는 새 호출을 멈추고, 미완료 Thinker 작업과 대기열에 있던 호출을 포함한 투기적 도구 작업을 취소한다. Responder는 최종 트랜스크립트, 대화 히스토리, 도구 스키마, 그리고 컨텍스트 조립 시점에 확보한 완료된 준비의 스냅샷을 받는다. 그 이후에 나오는 투기적 출력은 버려진다. Responder는 ReAct 과정을 통해 준비 내용을 전체 요청과 대조하고, 이후 발화와 모순되는 해석을 기각하고, 적용 가능한 완료 결과를 재사용하며, 결과가 없는 필수 호출은 자신의 프로세스 안에서 직접 실행한다. 덕분에 미완료 준비를 기다리지 않고 응답을 시작할 수 있고, Thinker와 Responder에는 서로 다른 모델을 선택할 수도 있다.

어떻게 쓰나

실험은 함수 호출을 다루는 SpeechFCEval, 비유창성이 섞인 발화에서의 의도 추종을 다루는 FDBench v3, 지식 근거 답변을 다루는 AudioCRAG에서 수행됐다. 비교 대상은 Speech-to-Speech, Pipecat, LiveKit, 그리고 Heartbeat와 같은 업데이트 스케줄을 쓰되 윈도우 이후 도착한 출력을 버리는 SHANKS-style Window Thinking이다. 구성은 Thinker로 Qwen3.6-35B-A3B, Responder로 DeepSeek-V4-Flash(0731), Δ=500ms, K=2다. 주 지표인 투기적 도구 커버리지(STC)는 Responder가 같은 호출을 반복하지 않고도 완료된 매칭 투기 호출이 커버한 참조 호출의 비율이며, AudioCRAG에서는 추가 검색 없이 완료된 투기 결과를 재사용한 샘플 비율로 측정한다.

전제와 한계

결과적으로 STC는 세 벤치마크 모두에서 Window Thinking을 앞섰고, 각각 10.56, 16.00, 42.37 퍼센트포인트 높았다. FDBench에서는 커버리지가 34.67%에서 50.67%로 오르고 Quality가 72.0%에서 77.0%, Pass@1이 57.0%에서 65.0%로 상승했지만 Pass@1은 여전히 Speech-to-Speech와 LiveKit보다 낮다. 반면 SpeechFCEval의 과제 성능은 67.95%에서 66.85%로, AudioCRAG는 57.24%에서 55.49%로 소폭 하락했다. 지연 측면에서 FDBench의 Correct Tool Call Latency는 −4.37초로 Window Thinking의 −2.74초, 캐스케이드 베이스라인의 2.45~3.52초보다 이르고, Final Response Latency는 6.90초에서 4.39초로 36.4% 줄어 평가된 캐스케이드 중 가장 빠른 Pipecat보다도 45.7% 낮다. STC 우위는 테스트한 세 Responder 모두에서 유지됐다. 다만 FDBench 녹음의 4.0%는 도구 호출 인자가 올바른데도 잘못되거나 오래된 결과를 사용해 답을 만들었고, 저자들은 호출의 정확성과 결과 활용을 별개 문제로 본다.

개발자 관점에서 이 논문은 발화 중의 대기 시간을 재사용 가능한 준비로 바꾸는 구체적 패턴을 제시한다. 구현에서 중요한 것은 Thinker와 Responder의 역할 분리, 완료된 추론 레코드와 요청된 호출 및 반환 결과를 담는 공유 상태, Thinker 스케줄링과 분리된 비동기 도구 큐, 그리고 핸드오프 시점의 취소·스냅샷 경계다. 동시에 커버리지가 늘어도 최종 품질이 자동으로 좋아지지는 않았으므로, Responder가 투기 결과를 검증하고 재사용하는 로직을 별도로 평가해야 한다. 지연 이득 역시 도구 실행 시간과 발화 길이에 좌우된다.

저자들이 밝힌 한계는 명확하다. 스케줄링 간격이 고정되어 있고 동시 Thinker 호출 수에 상한이 있으며, 부분 트랜스크립트의 변화나 도구 호출 완료에 기반한 적응적 스케줄링은 탐구하지 않았다. Responder는 컨텍스트 조립 시점의 준비 스냅샷만 받고 그 이후에 반환된 도구 결과는 제외되므로, 실행 시간이 들쭉날쭉한 도구의 늦은 결과를 점진적으로 전달하는 문제는 향후 과제로 남는다. 지연 분석도 FDBench v3에 국한되어 있어 도구 워크로드를 바꿔가며 투기 커버리지, 추론 비용, 응답 지연 사이의 트레이드오프를 더 평가할 필요가 있다고 적는다.