Audio-026, Stream RAG: Instant and Accurate Spoken Dialogue Systems with Streaming Tool Usage, ICML 2026

◼ Comment

  • MoshiRAG보다 먼저 나온 논문이고, 검색하는 시간을 줄일 수 있는 방법을 제시한다는 점
  • 사실 아이디어자체는 엄청 특별한 느낌은 아니긴하지만, 누구나 백그라운드 모델을 이런식으로 해볼 수 있다는 생각을 직접해본 느낌
    • 정확히는 RAG로 검색모듈만 붙이는 형태긴함
  • 여기서 제안하는 방법은 2개임
    • Fixed-Interval Streaming RAG
    • Model-triggered Streaming RAG
  • Fixed-Interval Streaming RAG
    • 예시) 사용자발화 :“2020년에 아카데미 작품상을 받은 영화가 뭐야?”
      • 1초 단위로 블럭을 만든다고 하자 (논문에서 fixed 방법은 1초, triggered은 0.5초)
      • 1초 시점: 2020년 -> 질의 생성 q1 -> 2020년 -> 검색 -> r1
      • 2초 시점: 2020년에 아카데미 -> 질의 생성 q2 -> 2020년 아카데미 -> 검색 -> r2
      • 3초 시점: 2020년에 아카데미 작품 -> 질의 생성 q3 -> 2020년 아카데미 작품 -> 검색 -> r3
      • 4초 시점: 2020년에 아카데미 작품상을 받은 -> 질의 생성 q4 -> 2020년 아카데미 작품상 -> 검색 -> r4
      • 5초 시점: 2020년에 아카데미 작품상을 받은 영화가 -> 질의 생성 q5 -> 2020년 아카데미 작품상 영화 -> 검색 -> r5
      • 끝난 시점: 2020년에 아카데미 작품상을 받은 영화가 뭐야? -> 질의 생성 q6 -> 2020년 아카데미 작품상 영화 -> 검색 -> r6
    • 이렇게 주기적으로 검색 질의 만들어서 검색한다는 것이다
    • 당연히 뒤로 갈수록 검색결과가 좋아질 것이다
    • Reflector는 이 검색결과 비교해서 r6와 같은 결과인 시점을 찾는다
    • 여기서 정확히는 r6 전체를 반환받을때까지 기다리면 그냥 r6을 써도 되는거니까
    • 전체 결과를 기다리는게 아니라 예로 상위 5개 문서정도까지만(r6-top5) 기다리고 r6-top2와 r3-top5을 비교해서 같으면 r3을 사겠다는 것이다.
    • 그러면 r6의 전체 결과를 기다릴 필요가 없다는 것
    • 그러면 딜레이는 q6가 만들어지기까지 시간과 Reflector가 r6-top5까지 만들고 이것과 r1-top5~r5-top5을 비교하는 시간이 딜레이 (물론 병렬로 돌아가고 있는 부분이긴함)
    • 근데 실제 검색모듈로 상위 5개 문서면 충분한거 아닌가? 최종 사용하는것은 top 몇개를 쓴다는거지? (언급 안됨)
    • 그냥 q1~q6 질의로 비교하는게 훨씬 빠를거 같은데
    • 여기서 질의 생성에 사용되는 모델은 Qwen2.5-Omni 임
    • 이 reference로 모델이 응답하게끔 하는 것은 따로 학습안됨. 그냥 in-context learning 식으로 작동하는걸 믿는 느낌
  • Model-triggered Streaming RAG
    • 예시) 사용자발화 :“2020년에 아카데미 작품상을 받은 영화가 뭐야?”
      • 1초 단위로 블럭을 만든다고 하자
      • 1초 시점: 2020년 -> 모델트리거 -> No Query (질의할 필요가 없음)
      • 2초 시점: 2020년에 아카데미 -> 모델트리거 -> 질의 생성 q2 -> 2020년 아카데미 -> 검색 -> r2
      • 3초 시점: 2020년에 아카데미 작품, 이전질의 -> 모델트리거 -> 질의 생성 q3 -> 2020년 아카데미 작품 -> 검색 -> r3 (r2 취소)
      • 4초 시점: 2020년에 아카데미 작품상을 받은, 이전질의 -> 모델트리거 -> No Query (이전 질의로도 충분함)
      • 5초 시점: 2020년에 아카데미 작품상을 받은 영화가, 이전질의 -> 모델트리거 -> No Query (이전 질의로도 충분함)
      • 끝난 시점: 2020년에 아카데미 작품상을 받은 영화가 뭐야?, 이전질의 -> 모델트리거 -> No Query (이전 질의로도 충분함, 여기서 No Query가 아닐수도 있음)
    • 모델 트리거 학습 데이터 만드는 방법
      • 질의: “2020년에 아카데미 작품상을 받은 영화가 뭐야?”
        • 0~1초: 2020년에
        • 0~2초: 2020년에 아카데미
        • 0~3초: 2020년에 아카데미 작품상을
        • 0~4초: 2020년에 아카데미 작품상을 받은
        • 0~5초: 2020년에 아카데미 작품상을 받은 영화가 뭐야
      • 논문에서는 실제로 500ms 간격의 부분 전사를 만듭니다.
        • 부분 발화 LLM이 만든 의사 정답 질의
        • 2020년에 2020
        • 2020년에 아카데미 2020 Academy Awards
        • 2020년에 아카데미 작품상을 2020 Academy Best Picture
        • …작품상을 받은 2020 Academy Best Picture winner
        • 전체 질문 2020 Academy Best Picture winning film
      • 웹 질의라면 두 질의로 검색했을 때 상위 5개 문서가 같은지 확인합니다.
        • 이전 질의: 2020 Academy Best Picture
        • 현재 의사 정답 질의: 2020 Academy Best Picture winner
        • 만약 이 2개의 상위 5개 문서가 같다면 NO_QUERY가 레이블이 되는 것
      • 이 데이터로 모델 트리거는 speech-to-text 형태의 모델을 학습 (Qwen2.5-Omni에 이어서)
        • ASR은 부분 발화의 경계와 pseudo-label을 만들기 위해 사용되고, 실제 query-generation 모델의 입력은 음성이다.
  • 쉽게 말하면 fixed는 모델 학습없이, 그냥 고정된 시간마다 질의만들고, 이를 검색태워서 응답에 활용
    • 응답에는 in-context learning으로 작동하기 때문에 당연히 성능 상승에 제한이 있음
    • 만약 LALM이 instruction following이 잘되는게 있으면, 질의 생성 정도만 따로 학습하면 나쁘지 않은 전략일듯
  • triggered 방식은 fixed 와 달리 학습데이터 만들어서, 질의 생성 및 instruction following이 잘되도록 학습한다
    • 질의 생성에서 NO Query 을 내뱉을 수 있기 때문에 백그라운드에서 검색이 병렬적으로 돌 필요는 없음 (이게 큰 장점인가 싶긴함)
    • 중요하다고 보는 것은 검색 레이턴시인데, 이게 fixed보다 크게 빨라질 이유는 없어보임 
      • tool result generation 실험 결과는 빨라지는거 같긴한데 이유로는
      • triggered는 0.5초 단위로 청킹
      • 불필요한 질의를 건너뜀
      • reflector를 기다릴 필요 없음 (인퍼런스시 reflector가 없기 때문)
      • 가장 최근 검색 결과를 바로 사용
    • 모델이 응답하는 쪽에서는 학습이 되어서 좀 더 장점이 있음
  • 하지만 전체적으로 입력 프롬프트가 길어지기 때문에 응답생성자체가 느려지는 한계가 있어보임
  • 검색에 의한 딜레이가 3.4초쯤 되고 응답생성이 2.5초쯤 됨 
    • 가장 큰 병목은 응답생성도 느려지는게 문제인거 같음

Abstract

종단 간 음성 입력–음성 출력 대화 시스템은 기존의 ASR–LLM–TTS 파이프라인을 대체할 수 있는 강력한 대안으로 부상하고 있으며, 훨씬 낮은 지연 시간으로 더욱 자연스럽고 표현력 있는 응답을 생성한다. 그러나 이러한 시스템은 사실적 근거가 제한되어 있어 여전히 환각에 취약하다. 텍스트 기반 대화 시스템에서는 웹 검색이나 지식 그래프 API와 같은 도구를 통합하여 이러한 문제를 해결하고 있지만, 본 연구에서는 도구 사용을 음성 입력–음성 출력 시스템에 직접 확장하는 최초의 접근법을 제안한다.

도구 통합의 핵심적인 문제는 응답 지연 시간을 크게 증가시켜 자연스러운 대화 흐름을 방해한다는 점이다. 이를 완화하기 위해, 사용자가 발화를 마치기 전부터 사용자 음성과 병렬로 도구 질의를 예측함으로써 사용자가 체감하는 지연 시간을 줄이는 새로운 프레임워크인 스트리밍 검색 증강 생성(Streaming Retrieval-Augmented Generation, Streaming RAG)을 제안한다.

구체적으로, 진행 중인 사용자 발화에서 언제 도구를 호출해야 하는지를 모델이 학습하도록 하고, 오디오 질의와 검색된 텍스트 결과를 결합한 음성 요약을 생성하도록 하는 사후 학습 파이프라인을 개발한다. 이를 통해 정확성과 응답성을 동시에 향상시킨다. 제안 방법을 평가하기 위해, 공개된 CRAG 데이터셋의 질의를 음성 형태로 변환하여 구축한 벤치마크인 AudioCRAG를 제시한다.

실험 결과, 제안하는 Streaming RAG 접근법은 질의응답 정확도를 상대적으로 최대 200% 향상시켰으며, 절대 정확도는 11.1%에서 34.2%로 증가하였다. 또한 도구 사용 지연 시간을 20% 감소시켜 사용자 경험을 더욱 향상시켰다. 중요한 점은 제안하는 Streaming RAG가 입력 모달리티에 독립적이어서 타이핑 입력에도 동일하게 적용될 수 있다는 것이다. 이는 더욱 에이전트적이고 실시간으로 동작하는 AI 어시스턴트로 나아가는 기반을 제공한다.

1 서론

음성 대화 시스템(Spoken Dialogue Systems, SDS)은 일상에서 사용되는 다양한 기술의 기반으로, Alexa와 Siri와 같은 지능형 비서뿐만 아니라 고객 서비스의 대화형 음성 응답 시스템에도 활용되고 있다. SDS의 활용 범위가 휴대전화와 웨어러블 기기로 빠르게 확대됨에 따라, 강건하고 확장 가능하며 일반화 능력이 높은 솔루션의 필요성이 그 어느 때보다 커지고 있다.

전통적으로 SDS는 음성 활동 검출(Voice Activity Detection, VAD), 자동 음성 인식(Automatic Speech Recognition, ASR), 자연어 이해(Natural Language Understanding, NLU), 자연어 생성(Natural Language Generation, NLG), 텍스트 음성 변환(Text-to-Speech, TTS) 등 여러 모듈로 구성된 캐스케이드 파이프라인에 의존해 왔다. 그러나 각 모듈은 오류와 지연이 발생할 수 있는 지점을 추가한다(Glass, 1999; Huang et al., 2024).

최근에는 하나의 통합된 아키텍처 안에서 음성 입력으로부터 직접 음성 응답을 생성하는 종단 간(End-to-End, E2E) SDS가 제안되고 있다(Xie and Wu, 2024; Nguyen et al., 2023; Meng et al., 2024; Zhang et al., 2024; Arora et al., 2025b). 이러한 E2E 접근법은 모듈 간 오류 전파를 완화할 뿐만 아니라 비음소적 정보도 더욱 효과적으로 포착한다. 그 결과 추론 시간과 계산 오버헤드를 크게 줄일 수 있으며, 더욱 자연스럽고 효율적인 대화 경험을 제공할 수 있다.

이러한 발전에도 불구하고, 현재의 E2E SDS는 정적인 학습 데이터로부터 모델 내부에 내재화된 지식에 의존한다는 근본적인 한계를 가진다. 이로 인해 모델의 응답이 사실적 근거를 충분히 갖추지 못하거나 최신 정보를 반영하지 못하는 경우가 많다. 이러한 문제는 호텔 예약이나 최신 사건에 관한 질문에 답하는 것과 같이 행동 수행 또는 지식 탐색이 필요한 작업에서 특히 중요하다.

반면 텍스트 기반 대화형 어시스턴트는 검색 증강 생성(Retrieval-Augmented Generation, RAG)을 통해 외부 도구를 통합함으로써 이러한 한계를 극복하기 시작했다(Yang et al., 2024; Chen et al., 2023a,c; Gao et al., 2024a,b). 이들은 웹 검색, 지식 그래프(Knowledge Graph, KG), 실시간 API와 같은 정보원으로부터 관련 정보를 동적으로 검색한다.

그러나 이러한 도구 사용을 E2E SDS에 통합하는 연구는 아직 충분히 이루어지지 않았다. 외부 도구는 사실적 정확도를 크게 향상시킬 수 있지만, 도구 호출 과정에서 추가적인 지연이 발생하는 경우가 많다. 이는 어색한 침묵을 유발하여 자연스러운 대화 흐름을 방해한다. 따라서 다음과 같은 연구 질문이 제기된다.

지능적이면서도 자연스럽게 느껴지는 SDS를 개발하기 위해, 정확성과 응답성 사이의 균형을 어떻게 달성할 수 있는가?

본 논문에서는 저자들이 아는 한 최초로, 외부 도구 호출을 낮은 지연 시간으로 원활하게 통합하는 음성 입력–음성 출력 언어 모델을 제시한다. 핵심 아이디어는 사용자가 발화를 마치기 전부터 사용자 음성과 병렬로 도구 질의를 생성하는 Streaming RAG 전략이다(그림 1).

그러나 스트리밍 질의를 단순하게 구현하면 다음과 같은 두 가지 문제가 발생한다.

  1. 불완전한 부분 발화로부터 생성된 질의는 부적절할 수 있으며, 그 결과 불필요한 도구 출력이 검색되거나 부정확한 응답이 생성될 수 있다.

  2. 불필요한 도구 호출이 발생하여 계산 자원이 낭비될 수 있다.

본 연구에서는 이러한 문제를 해결하기 위한 효과적인 모델링 기법을 제안하며, 주요 기여는 다음과 같다.

기여 1

본 연구에서는 음성 입력–음성 출력 시스템에 도구를 통합하기 위한 정형화된 프레임워크를 제안하고, 웹 검색 및 KG API를 활용하면 사실 기반 질의응답 성능이 크게 향상된다는 것을 실험적으로 보인다.

최신 모델인 Qwen-OMNI(Xu et al., 2025), OpusLM(Tian et al., 2025), Kimi-Audio(Ding et al., 2025)를 평가한 결과, 외부 도구 통합은 정확도를 상대적으로 최대 140% 향상시켰으며, 절대 정확도는 11.1%에서 26.3%로 증가하였다.

그러나 도구 사용은 상당한 지연도 유발하여, 첫 번째 토큰이 생성되기까지의 응답 시간을 2.3배 증가시켰다.

기여 2

이 문제를 해결하기 위해, 사용자가 발화를 끝내기 전부터 사용자 음성과 병렬로 도구 질의를 실행할 수 있도록 하는 최초의 프레임워크인 Streaming Retrieval-Augmented Generation(Streaming RAG)을 제안한다.

이 프레임워크 안에서 다음과 같은 두 가지 새로운 방법을 제시한다.

  1. 고정 간격 Streaming RAG(Fixed-Interval Streaming RAG)
    음성 입력이 진행되는 동안 일정한 간격으로 도구 질의를 실행한다. 이후 전체 질의에 대한 검색 결과와 비교하여 검색 품질을 신중하게 검증함으로써 최종 응답의 품질을 보장한다. 이 방법은 별도의 사후 학습 없이도 어떤 음성 입력–음성 출력 모델에 적용할 수 있다.

  2. 모델 트리거 Streaming RAG(Model-Triggered Streaming RAG)
    변화하는 사용자 발화의 내용을 바탕으로 모델이 최적의 질의 실행 시점을 지능적으로 결정하도록 사후 학습한다. 이를 통해 불필요한 도구 호출을 줄이고 계산 자원을 절약한다.

실험 결과, 제안하는 Model-Triggered Streaming RAG는 도구를 사용하지 않는 기준 모델과 비교하여 정확도를 상대적으로 200% 이상 향상시켰으며, 절대 정확도는 11.1%에서 34.2%로 증가하였다. 동시에 도구 결과 생성 지연 시간을 20% 줄였다.

Streaming RAG는 음성 입력–음성 출력 시스템을 위해 설계되었지만, 캐스케이드형 SDS뿐만 아니라 사용자가 텍스트를 입력하는 챗봇에도 적용할 수 있다.

기여 3

마지막으로, CRAG 데이터셋(Yang et al., 2024)의 텍스트 질의를 음성으로 녹음하여 구축한 벤치마크인 AudioCRAG를 제안한다. AudioCRAG는 음성 입력–음성 출력 시스템의 도구 사용 능력을 강건하게 평가할 수 있도록 설계되었다.

향후 연구를 지원하기 위해 학습 코드와 AudioCRAG-Human 벤치마크를 공개할 예정이며, 이를 통해 외부 도구가 통합된 음성 비서 연구의 발전을 지원하고자 한다.

2 관련 연구

2.1 도구 사용 벤치마크

텍스트 기반 대화 시스템의 도구 사용 능력을 평가하기 위한 최근의 벤치마크 연구들은 주로 사실 기반 질의응답과 시뮬레이션 환경에서의 과업 수행 능력을 평가하는 데 초점을 맞추어 왔다(Chen et al., 2023b; Ouyang et al., 2025; Cheng and Dou, 2025; Cohen et al., 2025; Xiong et al., 2024a). 관련 연구에 대한 자세한 논의는 부록 A와 B에 제시한다.

CRAG 벤치마크(Yang et al., 2024)는 대표적인 사례로, 4,409개의 질의–응답 쌍으로 구성되며 웹 검색과 지식 그래프 검색을 위한 모의 API를 제공한다. 최근의 벤치마크들(Meta CRAG-MM Challenge Organizers, 2025; Ma et al., 2024; Jang et al., 2025)은 도구 증강 대화 시스템 평가를 멀티모달 입력과 장문맥 시나리오로 확장하였다.

이러한 벤치마크들은 도구 증강 대화 시스템의 평가를 크게 발전시켰지만, 대부분 텍스트 기반 출력에 한정되어 있으며 음성 입력–음성 출력 시스템에서 발생하는 고유한 문제를 충분히 다루지 못한다.

2.2 종단 간 음성 대화 시스템

최근 여러 종단 간 음성 대화 시스템이 제안되었으며(Xu et al., 2025; Xie and Wu, 2024; Arora et al., 2025a; Nguyen et al., 2023; Meng et al., 2024; Zhang et al., 2024; Arora et al., 2025b), 이들은 뛰어난 의미 이해 능력과 높은 품질의 음성 응답을 보여주었다. 그러나 이러한 시스템들은 아직 외부 도구를 사용하는 능력을 갖추도록 학습되거나 평가되지 않았다.

또 다른 연구 방향으로는 직접적인 음성-텍스트 검색을 위한 종단 간 RAG가 있다(Feng et al., 2025). 이 방법은 멀티모달 임베딩을 활용하여 음성 발화가 관련 텍스트를 직접 검색할 수 있도록 한다. 이 방법은 RAG를 사용하지 않는 모델보다 우수한 성능을 보이지만, 주로 음성-텍스트 시나리오에 한정된다.

또한 실제 응용에 중요한 지식 그래프나 기타 API에 접근할 수 있는지는 아직 검증되지 않았다. 검색 범위도 제한적이다. 해당 연구의 실험에서는 검색 대상이 단 10개의 문단으로 제한되어 있지만, 최신 RAG 벤치마크는 수천 개의 웹 페이지를 대상으로 검색해야 한다.

최근 일부 연구(Maben et al., 2025)는 캐스케이드 파이프라인을 사용하여 음성 입력–음성 출력 환경에 도구를 통합하는 웹 인터페이스를 개발하였다. 그러나 종단 간 음성 입력–음성 출력 시스템에 대한 포괄적인 실험적 분석과, 특히 사용자가 체감하는 지연 시간에 대한 체계적인 분석은 여전히 충분히 이루어지지 않았다.

본 연구에서는 이러한 한계를 해결하기 위해 종단 간 음성 입력–음성 출력 시스템에 도구를 통합하기 위한 포괄적인 프레임워크를 개발하고, 최신 모델들의 도구 사용 능력을 정량적으로 평가할 수 있는 벤치마크를 설계한다. 또한 자연스러운 대화 흐름에서 지연 시간이 중요하다는 점을 고려하여, 도구 사용 성능을 향상시키는 동시에 사용자가 체감하는 지연 시간을 줄이는 새로운 Streaming RAG 방법을 제안한다.

3 방법론

RAG 기반 음성 대화 시스템은 오디오 질문 (Q)를 입력으로 받아 음성 답변 (A)를 출력한다. 오디오 질문의 ASR 전사 결과를 ($X^{\mathrm{asr}}$), 생성된 음성 답변의 ASR 전사 결과를 ($X^{\mathrm{res}}$)라고 하자. 답변은 음성 입력–음성 출력 모델에 의해 생성되며, 이 과정에서 모델 내부에 저장된 지식과 외부 정보원으로부터 검색된 정보를 함께 활용한다. 외부 정보를 통합하기 위해서는 모델이 외부 도구 (T)로부터 관련 결과 (R)을 검색할 수 있도록 도구 질의 ($Q^T$)를 생성해야 한다.

3.1 음성 입력–음성 출력 LLM을 위한 도구 통합

그림 2는 외부 도구를 음성 입력–음성 출력 시스템에 통합하기 위해 본 논문에서 제안하는 정식화 방법을 보여준다. 본 연구에서는 다음의 두 단계로 구성된 추론 방식을 도입한다.

1단계: 질의 생성

질의 생성 단계에서 시스템은 오디오 질문을 처리하고, 각 외부 도구로부터 관련 정보를 검색하기 위한 질의를 생성한다. 이는 다음 사후확률을 최대화하는 방식으로 이루어진다.

생성된 질의의 예시는 부록의 표 7에 제시되어 있다.

2단계: 응답 생성

응답 생성 단계에서는 도구로부터 검색된 결과 (R)을 원래의 오디오 질문과 결합한 뒤 모델의 입력으로 제공한다. 이후 모델은 다음 사후확률을 최대화하여 최종 음성 응답을 생성한다.

최종 출력 생성이 입력 오디오에 조건화되도록 함으로써, 이 정식화는 텍스트 기반 API와 상호작용할 수 있는 단순하고 효과적인 방법을 제공할 뿐만 아니라 음성 입력–음성 출력 시스템의 핵심적인 장점도 유지한다. 구체적으로, 모듈 간 오류 전파를 줄이고 운율이나 화자의 의도와 같은 비음소적 정보를 더욱 효과적으로 포착할 수 있다.

  • 모델의 작동방식이
    • 사용자 음성: “현재 애플 주가는 얼마야?”
    • 1단계 질의 생성: Apple current stock price
      • 모든 질의에 대해 이걸 생성하는지는 뒤에서 나오나?
    • 도구 결과: 애플의 최신 주가 정보
    • 2단계 응답 생성: 원래 음성과 검색 결과를 함께 보고 “현재 애플 주가는 약 …달러입니다”라는 음성을 생성

3.2 Streaming RAG

3.1절에서 제안한 RAG 기반 시스템은 외부 도구를 활용하여 사실적 정확도를 크게 향상시킬 수 있다. 그러나 이러한 도구 호출은 종종 상당한 지연 시간을 유발한다. 이는 사용자가 빠르고 자연스러운 응답을 기대하며, 짧은 침묵조차도 대화의 자연스러운 흐름을 방해할 수 있는 음성 입력–음성 출력 응용에서 특히 문제가 된다.

이 문제를 해결할 수 있는 한 가지 단서는 오디오 입력의 특성에 있다. 오디오 입력은 연속적인 스트림 형태로 도착한다. 이러한 스트리밍 특성을 이용하면 사용자가 발화를 마치기 전에 도구 호출을 시작할 수 있으며, 이를 통해 지연 시간을 줄일 수 있다.

  • 사용자가 말하는거 들으면서 미리미리 검색할지 말지 정할수는 없을까?
  • 즉 모델이 답하기전에 미리 알 수 없을까 이런것
  • 여기서 이걸 다루는구나

사용자가 체감하는 지연 시간을 최소화하기 위해, 본 연구에서는 Streaming RAG를 제안한다. Streaming RAG는 오디오 입력이 수신되는 동안 도구 질의를 생성하고 실행하는 최초의 프레임워크이다.

이 접근법은 다음의 세 가지 핵심 설계 요소로 구성된다.

  1. Trigger: 언제 새로운 도구 질의를 시작할 것인가

  2. Threads: 병렬로 실행할 도구 질의 스레드의 수

  3. Reflector: 중간 도구 결과가 최종 출력을 생성하기에 충분한지를 판단하는 모듈

각 구성 요소에 대해 서로 다른 설계 방식을 탐색함으로써, 다음 절들에서는 스트리밍 도구 질의 생성을 위한 두 가지 상호보완적 방법을 제안한다. 하나는 고정된 간격으로 질의를 실행하는 방식이고, 다른 하나는 모델이 질의 실행 시점을 결정하는 방식이다.

3.2.1 Fixed-Interval Streaming RAG

이 접근법에서는 오디오 입력이 진행되는 동안 고정된 청크 간격마다 도구 호출이 실행되도록 트리거를 설정한다.

입력 음성 (Q)는 다음과 같이 (B)개의 블록으로 나뉜다.

각 블록은 ($N_{\mathrm{block}}$)개의 프레임을 포함한다.

3.1절에서 설명한 ($P(Q^T \mid Q)$)를 근사하기 위해, 본 연구에서는 블록 단위 예측 전략을 사용한다. 구체적으로, 각 오디오 블록 (b)를 처리한 뒤 모델은 현재 블록까지 누적된 입력 음성 ($Q_{1:b}$)에 조건화하여 도구 질의 ($\hat{Q}_b^T$)를 예측한다.

이 전략에서는 그림 3(a)에 나타난 것처럼 총 (B)개의 병렬 도구 호출 스레드가 동시에 실행된다. 각 스레드는 대응하는 블록 ($b \in [1,B]$)에 대해 도구 질의 예측 ($\hat{Q}_b^T$)를 생성한다.

각 블록 이후에 생성된 도구 질의 ($\hat{Q}_b^T$)는 캐시에 저장된다. 도구 호출의 지연 시간이 크기 때문에, 일반적으로 도구 응답이 준비되기 전에 사용자가 발화를 마치게 된다.

사용자의 발화가 끝나면, 명시적인 reflector 모듈인 reflect()가 캐시에 저장된 중간 질의 ($\hat{Q}_b^T$)와 최종 질의 ($\hat{Q}_B^T$)를 비교한다. 이를 통해 더 이른 시점의 도구 호출이 사용자 질문 (Q)에 답하기 위한 충분한 정보를 제공하는지 판단한다.

Reflector는 캐시에 저장된 모든 중간 질의를 체계적으로 평가하고, 중간 질의 ($\hat{Q}_b^T$)가 최종 질의 ($\hat{Q}_B^T$)와 동일한 결과를 제공한다고 판단되는 가장 이른 도구 호출 시점 ($b^\star$)를 다음과 같이 찾는다.

(b^\star) 이후에 실행된 모든 병렬 도구 호출은 즉시 종료된다. 그리고 해당 중간 질의 (\hat{Q}{b^\star}^T)로부터 검색된 결과 (R{b^\star})를 사용하여 최종 음성 응답 (A)를 생성한다.

즉, 3.1절의 (P(A\mid Q,R)) 대신 다음 사후확률을 최대화한다.

본 연구에서는 단순하지만 효과적인 휴리스틱을 사용하는 reflector 모듈을 적용한다.

  • 웹 질의의 경우, 중간 웹 질의와 최종 웹 질의에서 검색된 상위 5개 웹 문서가 일치하는지 확인한다.

  • KG 질의의 경우, 중간 KG 질의와 최종 KG 질의의 결과가 동일한지 확인한다.

이러한 휴리스틱은 이른 시점의 질의 ($\hat{Q}_{b^\star}^T$)를 사용해 검색한 정보가 최종 질의 ($\hat{Q}_B^T$)까지 기다렸을 때 얻을 정보와 일관됨을 보장한다. 따라서 응답 품질에 대한 강한 보장을 제공한다.

도구 호출 지연의 대부분은 웹 문서를 청크로 나누고, 각 청크를 다시 순위화하는 과정에서 발생한다. 따라서 이러한 검사를 이용하면 모델 성능을 저하시키지 않으면서도 상당한 지연 시간 절감이 가능하다.

이 전략의 핵심 장점은 플러그 앤 플레이 방식이라는 점이다. 음성 입력–음성 출력 모델에 추가적인 사후 학습을 수행할 필요가 없으며, 추론 시점에 다양한 아키텍처에 직접 적용할 수 있다.

그러나 몇 가지 중요한 고려 사항이 있다.

  • 첫째, 고정된 간격마다 병렬 도구 호출을 생성하면 식 (1)과 같이 계산량이 증가한다. 이는 웨어러블 기기처럼 자원이 제한된 장치에 배포할 때 문제가 될 수 있다.
  • 둘째, 중간 도구 호출의 충분성을 판단하기 위해 식 (2)의 외부 reflector 모듈에 의존해야 하므로, 달성 가능한 지연 시간 개선 폭이 제한될 수 있다.

User가 말하고 그 다음에 검색을 해버리면, 검색에 걸리는 시간땜에 모델이 말하는 지연이 생긴다는 것

따라서 이를 해결하기 위해 User가 말하고 있을때 미리미리 검색을 하겠다는 것이다

그럼 뭐를 갖고 검색을 하냐? 그냥 주기적으로 지금까지 말한 것으로 검색하겠다는것

예시) 사용자발화 :“2020년에 아카데미 작품상을 받은 영화가 뭐야?”

  • 1초 단위로 블럭을 만든다고 하자
  • 1초 시점: 2020년 -> 질의 생성 q1 -> 2020년 -> 검색 -> r1
  • 2초 시점: 2020년에 아카데미 -> 질의 생성 q2 -> 2020년 아카데미 -> 검색 -> r2
  • 3초 시점: 2020년에 아카데미 작품 -> 질의 생성 q3 -> 2020년 아카데미 작품 -> 검색 -> r3
  • 4초 시점: 2020년에 아카데미 작품상을 받은 -> 질의 생성 q4 -> 2020년 아카데미 작품상 -> 검색 -> r4
  • 5초 시점: 2020년에 아카데미 작품상을 받은 영화가 -> 질의 생성 q5 -> 2020년 아카데미 작품상 영화 -> 검색 -> r5
  • 끝난 시점: 2020년에 아카데미 작품상을 받은 영화가 뭐야? -> 질의 생성 q6 -> 2020년 아카데미 작품상 영화 -> 검색 -> r6
  • 이렇게 주기적으로 검색 질의 만들어서 검색한다는 것이다
  • 당연히 뒤로 갈수록 검색결과가 좋아질 것이다
  • Reflector는 이 검색결과 비교해서 r6와 같은 결과인 시점을 찾는다
  • 여기서 정확히는 r6 전체를 반환받을때까지 기다리면 그냥 r6을 써도 되는거니까
  • 전체 결과를 기다리는게 아니라 예로 상위 5개 문서정도까지만(r6-top5) 기다리고 r6-top2와 r3-top5을 비교해서 같으면 r3을 사겠다는 것이다.
  • 그러면 r6의 전체 결과를 기다릴 필요가 없다는 것
  • 그러면 딜레이는 q6가 만들어지기까지 시간과 Reflector가 r6-top5까지 만들고 이것과 r1-top5~r5-top5을 비교하는 시간이 딜레이
  • 근데 실제 검색모듈로 상위 5개 문서면 충분한거 아닌가? 최종 사용하는것은 top 몇개를 쓴다는거지? (언급 안됨)
  • 그냥 q1~q6 질의로 비교하는게 훨씬 빠를거 같은데
  • 여기서 질의 생성에 사용되는 모델은 Qwen2.5-Omni 임
이 reference로 모델이 응답하게끔 하는 것은 따로 학습안됨. 그냥 in-context learning 식으로 작동하는걸 믿는 느낌

3.2.2 모델 트리거 Streaming RAG

Fixed-Interval Streaming RAG의 한계를 해결하고 효율성과 응답성을 더욱 최적화하기 위해, 본 연구에서는 보다 적응적인 접근법인 Model-Triggered Streaming RAG를 제안한다.

이 방식에서는 트리거가 학습된다. 즉, 모델은 그림 3(b)에 나타난 것처럼 사용자 발화에서 새로운 정보나 추가 정보가 등장했을 때만 도구 질의를 실행하도록, 최적의 질의 시점을 스스로 결정하도록 학습된다.

이 정식화에서도 모델은 앞선 방식과 마찬가지로 고정된 청크 간격으로 사용자 입력을 받는다. 각 블록 (b)를 처리한 뒤, 모델은 새로운 도구 호출이 필요한지를 지능적으로 판단한다. 모델은 다음 두 가지 중 하나를 선택할 수 있다.

  1. 새로운 도구 질의가 필요하지 않다면 NO_QUERY를 예측한다.

  2. 새로운 도구 질의가 필요하다면 해당 질의를 생성한다.

이 결정을 내리기 위해 모델은 현재 블록까지 누적된 입력 음성 ($Q_{1:b}$)뿐만 아니라, 가장 최근에 생성된 도구 질의 ($\hat{Q}^{\mathrm{prev}}_b$)에도 조건화한다. 여기서 가장 최근 질의는 다음과 같이 정의된다.

새로운 질의가 생성되어

인 경우, 시스템은 이전 질의 (\hat{Q}^{\mathrm{prev}}_b)에 대해 진행 중이던 모든 도구 호출을 즉시 종료한다. 이를 통해 언제나 단 하나의 도구 호출 스레드만 실행되도록 한다. 생성된 질의의 예시는 부록 표 8에 제시되어 있다.

이 접근법은 몇 가지 중요한 장점을 가진다.

  • 첫째, 중복되는 병렬 스레드를 효과적으로 제거하여 계산 오버헤드를 크게 줄인다. 이는 자원이 제한된 장치에 시스템을 배포할 때 특히 중요하다.
  • 둘째, 식 (2)의 외부 reflector 모듈이 더 이상 필요하지 않다. 모델은 가장 최근의 도구 질의 (\hat{Q}^{\mathrm{prev}}_B)로부터 얻은 결과 (R)을 신뢰하고, 다음 확률을 최대화하여 음성 응답 (A)를 생성한다.

따라서 시스템 구조도 더 단순해진다.

이 방법은 앞선 방법에서 항상 검색을 하지 않고, 모델 트리거로 검색 시점을 정한다

예시) 사용자발화 :“2020년에 아카데미 작품상을 받은 영화가 뭐야?”

  • 1초 단위로 블럭을 만든다고 하자
  • 1초 시점: 2020년 -> 모델트리거 -> No Query (질의할 필요가 없음)
  • 2초 시점: 2020년에 아카데미 -> 모델트리거 -> 질의 생성 q2 -> 2020년 아카데미 -> 검색 -> r2
  • 3초 시점: 2020년에 아카데미 작품, 이전질의 -> 모델트리거 -> 질의 생성 q3 -> 2020년 아카데미 작품 -> 검색 -> r3 (r2 취소)
  • 4초 시점: 2020년에 아카데미 작품상을 받은, 이전질의 -> 모델트리거 -> No Query (이전 질의로도 충분함)
  • 5초 시점: 2020년에 아카데미 작품상을 받은 영화가, 이전질의 -> 모델트리거 -> No Query (이전 질의로도 충분함)
  • 끝난 시점: 2020년에 아카데미 작품상을 받은 영화가 뭐야?, 이전질의 -> 모델트리거 -> No Query (이전 질의로도 충분함, 여기서 No Query가 아닐수도 있음)

사후 학습

모델트리거를 어떻게 학습할 것인가?

모델을 학습하기 위해, 본 연구에서는 텍스트 기반 도구 사용 벤치마크를 음성 형식으로 변환한다. 자세한 내용은 부록 G에 제시한다.

먼저 사전 학습된 ASR 모델을 이용해 단어 수준 타임스탬프를 계산한다. 이후 각 블록 (b)까지의 부분 ASR 전사 결과 ($X^{\mathrm{asr}}_b$)에 대해, LLM을 사용하여 각 도구에 대응하는 질의 ($Q^T_b$)를 생성하고 이를 의사 정답으로 사용한다.

모델이 언제 새로운 질의를 실행해야 하는지 학습하도록 하기 위해, 유사도 기반 라벨링 전략을 사용한다. 구체적으로 현재 블록의 의사 정답 질의 ($Q^T_b$)와, 블록 (b) 이전에 생성된 가장 최근의 비어 있지 않은 도구 질의 라벨 ($\hat{Q}^{\mathrm{prev}}_b$)를 비교한다.

라벨 함수는 다음과 같이 작동한다.

  1. 현재 질의가 이전 질의와 충분히 유사하다면, 특별한 라벨인 NO_QUERY를 부여한다. 이를 통해 새로운 도구 호출이 필요하지 않음을 모델에 학습시킨다.

  2. 두 질의가 충분히 다르다면, 실제 의사 정답 질의 (Q^T_b)를 라벨로 사용하여 새로운 도구 호출을 실행하도록 학습시킨다.

이를 식으로 나타내면 다음과 같다.

  • 모델트리거는 No Query or 새 질의 둘중 하나 생성하는 개념

KG 질의의 경우, 현재 질의가 이전 질의와 정확히 같으면 NO_QUERY 라벨을 부여한다.

웹 질의의 경우, 현재 질의와 이전 질의로 검색한 상위 5개 문서가 변하지 않았다면 NO_QUERY 라벨을 부여한다.

본 연구에서는 두 가지 핵심 능력을 목표로 하는 멀티태스크 미세조정 전략을 사용한다.

첫째, 스트리밍 도구 질의 생성을 학습한다. 이를 위해 모든 블록 ($b\in[1,B]$)에 대해 다음 확률을 최적화한다.

  • 질의 생성을 하라는 능력의 학습

이를 통해 모델은 언제 새로운 도구 질의를 실행할지를 지능적으로 판단할 수 있게 된다.

둘째, 응답 생성을 학습한다. 이를 위해 3.1절과 같이 다음 확률을 최적화한다.

  • reference 참조해서 말하는 능력을 학습

이를 통해 생성되는 음성 출력의 명료성을 향상시킨다.

사후 학습에서 중요한 부분 중 하나는 중간 질의 예측 오류로부터 모델이 회복하는 능력을 향상시키는 것이다.

예를 들어 다음 오디오 질문을 생각해 보자.

“Who founded Rare Beauty in 2019?”

모델이 초기 부분 발화를 잘못 해석하여 이전 질의 (\hat{Q}^{\mathrm{prev}}_b)를 다음처럼 생성할 수 있다.

Red Bull founder

이 경우 모델은 이후 블록에서 계속 NO_QUERY를 생성할 수 있으며, 그 결과 올바른 정보를 검색하려는 추가 시도가 중단될 수 있다.

이 문제는 학습 시에는 모델이 항상 올바른 이전 질의 ($\hat{Q}^{\mathrm{prev}}b$)를 입력받지만, 추론 시에는 부분 발화 (Q{1:b})가 모호하여 잘못된 질의를 생성할 수 있기 때문에 발생한다. 따라서 모델은 추론 중 이러한 오류에서 회복하는 방법을 충분히 학습하지 못한다.

이를 해결하기 위해, 본 연구에서는 사후 학습 중 일부러 잘못된 이전 질의를 주입하는 새로운 전략을 도입한다. 구체적으로 식 (4)의 이전 질의 ($\hat{Q}^{\mathrm{prev}}_b$)를 잘못된 질의 ($Q^{\mathrm{neg}}_b$)로 교체한다.

중요한 점은 음성 표본을 사용할 때 학습 라벨을 NO_QUERY로 두는 것이 아니라, 다시 의사 정답 질의 ($Q^T_b$)를 사용한다는 것이다.

이 방식은 중간 질의 예측이 잘못되더라도 모델이 오류를 인식하고 올바른 새 질의를 다시 생성하도록 명시적으로 학습한다. 그 결과 정확도를 유지하면서도 지연 시간을 줄일 수 있다. 관련 제거 실험은 표 5에 제시되어 있다.

모델 트리거 학습 데이터 만드는 방법

  • 질의: “2020년에 아카데미 작품상을 받은 영화가 뭐야?”
    • 0~1초: 2020년에
    • 0~2초: 2020년에 아카데미
    • 0~3초: 2020년에 아카데미 작품상을
    • 0~4초: 2020년에 아카데미 작품상을 받은
    • 0~5초: 2020년에 아카데미 작품상을 받은 영화가 뭐야
    • 논문에서는 실제로 500ms 간격의 부분 전사를 만듭니다.
  • 부분 발화LLM이 만든 의사 정답 질의
    2020년에2020
    2020년에 아카데미2020 Academy Awards
    2020년에 아카데미 작품상을2020 Academy Best Picture
    …작품상을 받은2020 Academy Best Picture winner
    전체 질문2020 Academy Best Picture winning film
  • 웹 질의라면 두 질의로 검색했을 때 상위 5개 문서가 같은지 확인합니다.
    • 이전 질의: 2020 Academy Best Picture
    • 현재 의사 정답 질의: 2020 Academy Best Picture winner
    • 만약 이 2개의 상위 5개 문서가 같다면 NO_QUERY가 레이블이 되는 것
  • 이 데이터로 모델 트리거는 speech-to-text 형태의 모델을 학습 (Qwen2.5-Omni에 이어서)
    • 즉 데이터 만들때 입력은 음성을 그대로 쓰고
    • 출력 및 검색을 위해서 ASR한것이 사용됨

모델이 질의 생성을 하기 위해서 아래와 같은 입력을 받게 됨

  • You are given an Audio Query and Query Time.

  • Your task is to generate a web query that can be used
  • to retrieve relevant web pages.

  • Rewrite the following query into a short and succinct form,
  • focusing on:
  • - main topic or domain
  • - key entities
  • - specific aspects of those entities

  • Do not simply output the original query.
  • Rephrase it into a concise and focused search query.

  • Do not include explanations.
  • Only output the rewritten query.

실제 모델이 응답을 하기 위해서 아래와 같은 입력을 받게 됨

  • System / Instruction:
  • You are given an Audio Question, References and Query Time.
  • Use the references if they are helpful.
  • Answer the question in as few words as possible.

  • Audio Question:
  • [사용자 원본 음성 Q]

  • Query Time:
  • 02/28/2024, 10:30:00 PT

  • References:
  • # web
  • [검색된 웹 문서들의 텍스트]

  • # knowledge graph
  • [KG API가 반환한 JSON 또는 텍스트]

  • Answer:

근데 reference가 올때까지 딜레이 있으면 모델이 응답을 아예 안하고 있을거고, 대화모델은 이 reference을 참조하여 말하게끔 지시를 받음

즉 3.2.1과 달리 3.2.2 방법은 질의 생성 및 응답을 위한 multi-task learning이 이뤄지는 것

4 실험 설정

4.1 평가 벤치마크

제안한 방법을 엄밀하게 평가하기 위해, 음성 질의와 시뮬레이션된 도구 상호작용으로 구성된 포괄적인 벤치마크 데이터셋을 구축한다. 먼저 CRAG 데이터셋(Yang et al., 2024)을 기반으로 음성 버전의 CRAG를 구축하고, 이를 AudioCRAG라고 명명한다. AudioCRAG는 다음의 두 가지 변형으로 구성된다.

  1. AudioCRAG-Synthetic
    음성 질의를 생성하기 위해 자체 TTS 시스템을 사용한다. 이후 엄격한 필터링 절차를 적용하여 최종적으로 1,862개의 고품질 음성 질의를 확보하였으며, 이를 AudioCRAG-Synthetic 벤치마크라고 부른다.

  2. AudioCRAG-Human
    평가의 현실성과 다양성을 더욱 높이기 위해, 618개의 사람이 직접 녹음한 음성 질의로 구성된 AudioCRAG-Human 벤치마크를 추가로 구축한다. 본 논문이 채택될 경우 AudioCRAG-Human 벤치마크를 공개하여, 보다 자연스럽고 신뢰할 수 있는 음성 비서의 개발을 지원할 예정이다.

이들 벤치마크의 구체적인 구축 과정은 부록 C절에서 설명한다. 또한 CRAG의 설정을 따라 웹 검색 도구와 지식 그래프 기반 도구를 모두 사용하며, 평가 방법 역시 CRAG의 견고한 평가 절차를 따른다. 자세한 내용은 부록 D절과 E절에 제시한다.

추가로, 음성 입력·음성 출력 모델을 후속 학습하기 위해 텍스트 기반 사실 질의응답 데이터셋인 TriviaQA(Joshi et al., 2017)에서 무작위로 추출한 16,000개의 질문을 사용한다. 자세한 내용은 부록 G절에서 설명한다.

4.2 평가 대상 최신 음성 입력·음성 출력 모델

본 연구에서는 최신 음성 입력·음성 출력 대화 시스템 세 가지를 포괄적으로 평가한다.

  • Qwen-OMNI(Xu et al., 2025)

  • Kimi-Audio(Ding et al., 2025)

  • OpusLM(Tian et al., 2025)

각 모델은 외부 도구를 사용하는 조건과 사용하지 않는 조건 모두에서 평가된다. 구체적인 실험 설정은 부록 F절에 제시한다.

또한 최종 응답 생성에 대한 Streaming RAG 후속 학습의 효과를 분석하기 위해, 표 4의 Tool Integration으로 표시된 절제 실험을 수행한다. 이 설정에서는 모델을 순차적 질의 생성, 즉 3.1절의

[
P(Q^T \mid Q)
]

와 출력 생성에 대해 후속 학습한다. 이를 통해 일반적인 도구 통합 후속 학습과 Streaming RAG 후속 학습의 차이를 비교한다.

추가로, 3.1절의 Open Book 설정에 대해 self-cascade 접근법을 사용하는 절제 실험을 수행한다. 이 방식은 다음의 3단계 추론 파이프라인으로 구성된다.

세 번째 단계에서는 최종 음성 출력을 얻기 위해 텍스트 출력을 teacher forcing 방식으로 제공한다. 따라서 이 self-cascade 접근법은 Qwen-OMNI와 같은 Thinker–Talker 구조나 OpusLM과 같은 Chain-of-Thought 기반 구조에만 적용할 수 있다.

이 절제 실험의 목적은 3.1절의 Response Generation 단계에서 RAG reference (R)를 직접 포함하는 것이 생성된 최종 음성 (A)의 품질에 어떤 영향을 미치는지 분석하는 데 있다.

맞아. 내가 5.4 안의 표 4, 표 5 분석을 별도 소절처럼 쪼개서 잘못 적었어. 논문 구조대로 보면 5장은 5.1~5.4까지만 있다. 섹션별로 다시 정리하면 아래와 같아.

5.1 Impact of Tool Integration and Streaming RAG on SOTA Models

Closed Book에서는 외부 도구 없이 내부 지식만 사용하기 때문에 모든 모델의 정확도가 낮다. AudioCRAG-Synthetic에서 Qwen2.5-7B는 11.1%, OpusLM은 18.4%, Kimi-Audio는 16.7%다.

Open Book으로 웹 검색과 KG 결과를 제공하면 정확도가 올라간다. Qwen2.5-7B는 11.1%에서 26.3%로 증가하고, Kimi-Audio도 16.7%에서 21.8%로 향상된다. 다만 검색과 reference 처리가 추가되면서 first-token latency가 크게 증가한다. Qwen2.5-7B는 1.34초에서 5.90초로 늘어난다.

Model-Triggered Streaming RAG를 적용하면 정확도와 latency가 모두 개선된다. Qwen2.5-7B는 Synthetic에서 34.2%, Human에서 37.4%를 기록한다. 또한 tool-use latency는 Synthetic에서 20.7%, Human에서 53.4% 절감된다. OpusLM도 정확도와 latency 측면에서 개선된다.

저자들은 특히 synthetic 데이터만으로 post-training했음에도 human-recorded benchmark에서도 성능이 향상된다는 점을 일반화 능력의 근거로 든다.

성능이 향상되는건 맞는거 같음

5.2 Analysis: Modality Gap Between Speech and Text Output

핵심은 동일한 speech input을 받더라도 text output이 speech output보다 훨씬 정확하다는 점이다.

예를 들어 Qwen2.5-7B의 Open Book 결과는:

  • Text output: 39.6%

  • Speech output: 26.3%

이다.

Kimi-Audio도:

  • Text output: 45.8%

  • Speech output: 21.8%

로 차이가 크다.

저자들은 특히 드문 고유명사나 entity를 직접 음성으로 생성하는 과정에서 오류가 많이 생긴다고 본다.

이를 완화하기 위해 self-cascade를 사용한다.

음성 질문 + reference
→ 텍스트 답변 생성
→ 그 텍스트를 조건으로 음성 생성

Qwen2.5-7B의 speech 정확도는 26.3%에서 33.8%로 올라가고, OpusLM은 0.0%에서 21.2%로 크게 회복한다.

하지만 Streaming RAG post-training은 이보다도 조금 더 높은 성능을 보인다.

  • Qwen2.5-7B: 34.2%

  • OpusLM: 23.6%

따라서 이 절의 결론은 단순히 reference를 넣는 것만으로는 부족하고, reference를 바탕으로 정확한 speech output을 생성하도록 post-training하는 것이 중요하다는 것이다.

어떻게 보면 애초에 LALM이 instruction following이 잘 안되는거 같기도함

5.3 Analysis of Latency Bottlenecks in Tool-Integrated Speech Dialogue

Qwen2.5-7B의 Open Book P50 latency는:

  • Query generation: 0.59초

  • Tool result generation: 2.78초

  • Response generation: 2.52초

  • Total: 5.90초

이다.

가장 큰 병목은 외부 웹 검색 결과를 만들고 문서를 chunking, reranking하는 과정이다.

Streaming RAG에서는:

  • Query generation: 0.59초

  • Tool result generation: 2.20초

  • Response generation: 2.52초

  • Total: 5.32초

로 감소한다.

즉 응답 생성 자체가 빨라진 것은 아니고, 사용자가 말하는 동안 검색을 미리 수행했기 때문에 발화 종료 후 남는 tool latency가 줄어든 것이다.

전체 first-token latency는 5.90초에서 5.32초로 약 9.8% 줄고, tool-use latency 기준으로는 20.7% 절감된다. 저자들은 웹 페이지 처리 과정이 가장 큰 latency 원인이라고 분석한다.

3.34초+가 검색땜에 느려지는거라 볼 수 있음. 응답 생성에도 사실 영향이 있는게 앞의 컨텍스트가 너무 길어지기 때문에 응답이 느려질수 있음

5.4 Ablation Study

그림 4: Fixed-Interval과 Model-Triggered 비교

Fixed-Interval Streaming RAG도 별도 post-training 없이 tool latency를 평균 10.7% 줄인다. 따라서 기존 모델에 바로 적용할 수 있다는 장점이 있다.

하지만 여러 block에서 동시에 검색을 실행하므로 평균적으로 많은 병렬 thread가 필요하다. 그림에서는 약 14개의 thread가 사용된다.

Model-Triggered Streaming RAG는 평균 latency 절감이 20.7%로 더 크고, latency가 줄어드는 질의 비율도 더 높다. 동시에 검색 thread는 하나만 유지한다.

  • Fixed-Interval은 학습을 안해도 되고, 단순 검색하는것보다 latency을 줄일 수 있음. 그러나 인퍼런스때 검색 병령 thread가 꽤많이 들듯
  • Model-Triggered은 학습해야하는데 성능 좋음

즉:

Fixed-Interval
- post-training 불필요
- reflector 필요
- 다수 병렬 thread 필요

Model-Triggered
- post-training 필요
- reflector 불필요
- 단일 thread
- 더 큰 latency 절감

이라는 차이다.

표 4: Post-training 방식 비교

표 4는 일반적인 Tool Integration post-training과 Streaming RAG post-training을 비교한다.

Qwen2.5-7B:

  • Tool Integration: 34.9

  • Streaming RAG: 34.2

OpusLM:

  • Tool Integration: 22.4

  • Streaming RAG: 23.6

성능 차이는 크지 않다. 따라서 streaming query generation을 추가로 학습해도 최종 응답 성능을 크게 해치지 않는다는 것이 저자의 결론이다.

표 5: Negative sampling의 효과

Qwen2.5-7B text output 기준:

  • Open Book: 39.6

  • Streaming RAG post-training: 39.8

  • Negative sampling 제거: 36.5

중간에 잘못된 query가 생성되면, 모델이 그 잘못된 query를 기준으로 이후에 계속 NO_QUERY를 출력할 수 있다. Negative sampling은 일부러 잘못된 이전 query를 넣고도 현재 음성에서 올바른 query로 회복하도록 학습한다.

표 5는 이 전략을 제거하면 정확도가 3.3%p 떨어진다는 것을 보여준다. 즉 Model-Triggered 방식에서는 중간 query 오류를 복구하는 학습이 중요하다는 결론이다.

6 결론 및 논의

본 연구에서는 외부 도구 사용을 종단간 음성 입력·음성 출력 대화 시스템에 직접 통합하는 최초의 포괄적인 접근법을 제안하였다. 또한 Model-Triggered Streaming RAG 파이프라인을 도입하여, 모델이 검색 결과를 더 효과적으로 활용하고 새로운 도구 질의를 언제 실행할지 스스로 판단할 수 있도록 하였다. 이를 통해 정확도와 응답성을 모두 향상시켰다.

새롭게 구축한 AudioCRAG 벤치마크에서의 실험 결과, 외부 도구를 통합하면 closed-book 모델과 비교해 사실 질의응답 정확도를 두 배 이상 높일 수 있었다. 또한 제안한 Streaming RAG 방식은 도구 사용으로 인한 latency를 약 20% 줄여, 보다 자연스러운 대화 흐름을 유지할 수 있었다.

종합하면, 본 연구는 정확하고 실시간으로 동작하며 외부 도구를 활용할 수 있는 음성 비서를 구현함으로써 음성 대화 시스템의 성능을 한 단계 발전시켰다. 또한 오픈 사이언스를 지원하기 위해 학습 코드와 AudioCRAG-Human 벤치마크를 공개할 예정이며, 이를 통해 향후 관련 연구와 개발을 지원하고자 한다. 

Reference

댓글

댓글 쓰기