Audio-025, MoshiRAG: Asynchronous Knowledge Retrieval for Full-Duplex Speech Language Models, ICML 2026

◼ Comment

  • 이 모델은 Moshi 모델에 백그라운드 모델을 붙여서 학습한 모델이다.
  • 내가 생각한 문제점
    • 일단 모든 백그라운드 응답이 moshi가 제대로 답변하기 전까지 온다는 가정
    • 어쩔때 interaction으로 보내야하는지 판단하는게 애매함. 
    • 그냥 학습데이터에서 검색이 필요하다고 판단하면 모두 보내는 형식으로 만들어졌음.
    • 사실 moshi가 그럴 필요없이 바로 대답할 수 있는 경우도 있을텐데
    • 혹시 모델이 답하기전에 미리 검색여부를 알 수 없을까 이런것 <ret>까지 기다리지 않고 미리미리 유저 발화에서 미리 캐치할 수 없나
  • 직관적으로는 다음과 같이 생각한다.
    • Moshi는 7B 모델이고 full-duplex 모델로 동작하는데, 사실성을 원하는 질문같은 경우 (QA와 같은) 성능이 좀 떨어진다.
    • 모델 키우고 데이터 넣고 이러는게 하나의 해결책이겠지만, 텍스트 llm과 달리 full-duplex는 인퍼런스 속도가 더욱 중요하다.
    • 따라서 RAG 방식으로 백단에서 모델이 있고 이를 활용하겠다는 것이다.
    • 근데 또 llm과 다르게, RAG 혹은 백그라운드 모델이 정보를 줄동안 moshi는 무언가를 말하고 있어야한다는 것이다.
  • 여기서 나오는 용어가 있다.
    • TTFAT: 사용자 질문이 끝나고 첫번째 응답 토큰이 나올때까지 걸리는 시간
    • keyword delay: TTFAT뒤에, 즉 첫번째 응답 토큰이 나오고 검색한 결과의 첫 키워드가 나올때까지 걸리는 시간
    • E2EKD = TTFAT + keyword delay
    • retrieval delay = 검색이 필요하다는 신호 (<ret>)가 나오고 검색이 될때까지 걸리는 시간
    • 여기서 RAG 방식이 작동하려면 retrieval delay < E2EKD 구조가 되어야한다는 것
    • 즉 모델(Moshi)가 구체적인 응답을 내뱉기전에 검색이 되어야한다는 말임
  • 학습 데이터를 어떻게 만드는지 살펴보자
    • QA 데이터 샘플을 기존의 데이터에서 하나 추출 (Natural Questions, HotpotQA, TriviaQA)
      • Question: 한국의 수도는 어디야?
      • Answer: 서울
    • 여기서 토픽을 LLM으로 추출 (어떤 LLM인지 언급안됨)
      • 토픽: 한국의 수도
    • 1번째 턴
      • user LLM의 역할 (gemma3 27B)
        • 토픽: "한국의 수도"가 주어지고 이에 대한 질문을 만들라고 함
        • 예) "Moshi야. 한국의 수도에 대해 얘기해볼까?"
      • Reference LLM의 역할 (gemma3 27B)
        • "Moshi야. 한국의 수도에 대해 얘기해볼까?" 에 대한 응답을 생성하게함 (짧게 말하라는 등의 프롬프트가 따로 있음)
        • 예) "대한민국의 수도는 서울이다. 서울은 대한민국의 정치, 경제, 문화 중심지이다."
      • Moshi LLM의 역할 (gemma3 27B)
        • 컨텍스트: "Moshi야. 한국의 수도에 대해 얘기해볼까?"
        • 레퍼런스: "대한민국의 수도는 서울이다. 서울은 대한민국의 정치, 경제, 문화 중심지이다."
        • 위 2개가 주어지고 응답하게함 (자세한 프롬프트는 본문 참고)
        • 예) 
          • Lead: 네, 간단히 말하면 (시간 끌어주는 기능)
          • Body: 한국의 수도는 서울이에요.
          • Tail: 더 궁금한거 없어? (reference없어도 말할 수 있는 부분)
    • 2번째 턴
      • user LLM
        • 토픽: 한국의 수도
        • 컨텍스트: 
          • "Moshi야. 한국의 수도에 대해 얘기해볼까?"
          • 네, 간단히 말하면 한국의 수도는 서울이에요. 더 궁금한거 없어?
        • 다음 질문 생성
          • 예) "서울은 언제부터 수도였어?"
      • Referecne LLM
        • 컨텍스트
          • "Moshi야. 한국의 수도에 대해 얘기해볼까?"
          • 네, 간단히 말하면 한국의 수도는 서울이에요. 더 궁금한거 없어?
          • "서울은 언제부터 수도였어?"
        • 이에 대한 답변을 하게함
        • 예) "서울은 조선이 한양을 수도로 정한 1394년부터 한반도의 주요 수도 역할을 해왔다."
      • Moshi LLM
        • 컨텍스트
          • "Moshi야. 한국의 수도에 대해 얘기해볼까?"
          • 네, 간단히 말하면 한국의 수도는 서울이에요. 더 궁금한거 없어?
          • "서울은 언제부터 수도였어?"
        • 레퍼런스: "서울은 조선이 한양을 수도로 정한 1394년부터 한반도의 주요 수도 역할을 해왔다."
        • 이에 대한 Lead, Body, Tail 생성
        • 만약 레퍼런스를 사용안한다고 판단하면 그냥 하나의 문장 생성 (?)
  • 이렇게 만든 데이터를 multi-channel TTS 모델을 통해 데이터를 만듬
    • 멀티턴 대화 약 2분, single-turn QA 약 15초
  • 학습
    • 실제 검색이 얼마나 걸릴지 모르니까 식 3처럼, dlead 안에서 다양한 분포를 뽑음
    • dlead란 데이터에서 lead 부분의 발화를 말하는 시간이라 보면 됨
    • 그러면 대화턴에서 중간에 검색결과가 들어온 형태가 될텐데, 식 1처럼 hidden latent space을 그냥 더하는 형태
    • <ret>가 안나오거나, 이것에 대한 응답받기전에는 그냥 일반 Moshi 처럼 작동한다
      • 일반 Moshi라는건, 식 1처럼 text(model), speech(model), speech(user)가 입력으로 동시에 들어와서 더한 hidden representation이 입력 representation이 되는 것
    • <ret>에 의한 결과가 나왔다고 해보자.
      • 검색 결과가 250개 reference 토큰이라고 해보자. 
      • reference 토큰 임베딩 r1,...,r250은 각 step별로 하나씩 더해진다.
        • 입력1=h1+r1
        • ...
        • 입력250=h250+r250
      • Moshi 에서는 12.5Hz을 사용하고, 이는 1초=12.5개토큰 -> 1개 토큰은 1/12.5=0.08초이다.
        • 따라서 250개 reference 토큰을 모두 입력에 반영하려면 0.08*250=20초가 필요하다는 것
        • 250개의 각각 토큰이 0.08초에 하나씩 입력되려면 Moshi 응답이 20초이상이어져야하는데, 실제로는 이럴 가능성이 낮다.
      • 따라서 ARC-C Encoder라는 것을 사용하여 길이를 4배 압축한다
        • 위 예시에서 250개토큰 = 20초 -> 5초로 압축한다는 것
        • r1~r250 => r1~r62 정도로 개수가 압축이 된다는것
        • 그래도 이 경우에는 5초가 필요하긴한데, 응답이 5초가 안되면 어떻게 되는거지? (아마 뒷 부분 토큰은 안들어가는것 같음)
        • 따라서 모델 응답이 End of Sentence 이런 토큰나오면 뒷 부분의 reference 임베딩은 버려지는거 같음
    • 그림 4처럼 학습된가고 보면 됨.
    • 학습 objective는 SFT로, moshi가 말하는 부분에 loss가 걸리는거 같음.
    • full-duplex라 moshi는 sliecne을 포함해서 항상 말하고 있으니 모든 step에서 학습된다고 볼 수도 있음. (안나와있음)
  • 실제 인퍼런스 할때는 그림3처럼 작동하는데
    • 음성이 들어오면 streaming ASR은 돌아가고 있고
    • <ret>나오면 retrieval system에 streaming ASR한것이 들어가서 결과 받아와서 reference text encoder 태워서 hidden embeddingd들 한 step씩 넣어줌
    • 예)
      • User: 한국의 수도가 어디야? 
      • Moshi: 한국의 수도는 서울이에요. 
      • User: 서울은 언제부터 수도였어? 
      •  이거이면 Moshi는 Moshi Text쪽으로 대체하고 User은 ASR로 텍스트화한거 이 2개를 대화형태로 만들어서 보내는 것

Abstract

최근 speech-to-speech language model은 대화형 AI의 자연스러움을 향상시키기 위해 등장하였다. 특히 full-duplex 모델은 실시간 상호작용이 가능하다는 점에서 차별화되며, 침묵, 끼어들기(interruption), backchannel과 같은 현상을 자연스럽게 처리할 수 있다. 그러나 이러한 모델의 사실성(factuality) 을 향상시키는 것은 여전히 해결되지 않은 과제이다. 모델의 크기를 키우면 이 문제를 완화할 수 있지만, 실시간 추론 비용이 지나치게 커진다.

본 논문에서는 MoshiRAG를 제안한다. 이는 소형 full-duplex 인터페이스와 선택적 retrieval을 결합하여 더 강력한 외부 지식원을 활용하는 모듈형 접근법이다. 제안하는 비동기(asynchronous) 프레임워크는 모델이 지식이 필요한 질의를 스스로 식별하고, 외부 정보에 기반하여 응답을 생성할 수 있도록 한다. 또한 응답을 시작하는 시점과 핵심 정보를 전달하는 시점 사이에 존재하는 자연스러운 시간적 간격을 활용하여, 자연스러운 대화 흐름을 유지하면서도 retrieval 과정을 완료할 수 있다.

이러한 접근법을 통해 MoshiRAG는 full-duplex 시스템의 고유한 상호작용성을 유지하면서도, 현재 공개된 non-duplex speech language model 가운데 최고 수준과 비교 가능한 사실성을 달성한다. 더 나아가, 제안한 구조는 재학습 없이도 다양한 retrieval 방법을 plug-and-play 방식으로 사용할 수 있으며, 도메인 밖(out-of-domain)의 수학적 추론 과제에서도 우수한 성능을 보인다.

큰 모델로 full-duplex를 하는건 추론, 지연시간 문제가 있기 때문에, RAG을 통한 비동기 프레임워크로 full-duplex을 하면 사실성이 높아진다.

1. Introduction

인공지능(AI) 시스템을 위한 음성 인터페이스를 구축하여 다양한 상황에서 사람을 지원하는 것은 오랫동안 미래 기술의 핵심 비전으로 여겨져 왔다. 사용하기 편리한 음성 인터페이스는 사용자가 실제 인간 비서와 대화하는 것처럼 AI 시스템과 자연스럽게 의사소통할 수 있는 경험을 제공해야 한다. 초기 접근법은 일반적으로 자동 음성 인식(ASR), 텍스트 기반 대화 관리(dialogue management), 음성 합성(TTS)과 같은 여러 구성 요소를 결합하여 대화 시스템을 구축하였다. 최근에는 음성을 텍스트로 변환하는 과정에서 발생하는 운율(prosody), 리듬(rhythm), 억양(intonation) 등의 정보 손실을 줄이고, 단계별(cascaded) 파이프라인으로 인해 발생하는 지연(latency)과 상호작용의 단절을 줄이기 위해 end-to-end 접근법으로 연구의 흐름이 이동하고 있다.

최근 제안된 다양한 프레임워크 가운데 full-duplex 모델은 "말하면서 동시에 듣는(listen while speaking)" 능력을 갖춘다는 점에서 기존의 turn-based 방식과 구별된다. Turn-based 방식은 문장과 같은 비교적 큰 단위의 음성을 처리하며, 각 단위가 끝난 뒤에야 듣기 상태와 말하기 상태를 전환할 수 있다(Figure 1). 

반면 full-duplex 모델은 음성 입력을 받는 동시에 응답을 생성할 수 있기 때문에 사용자 입력에 더 빠르게 반응할 수 있으며, 실제 인간 대화에서 나타나는 복잡한 상호작용을 더욱 잘 모델링할 수 있다. 그러나 이러한 full-duplex 접근법은 실시간 음성 처리와 생성이 필요하다는 새로운 어려움도 함께 가져온다. 또한 최근 연구들은 native audio 모델이 질의응답과 같이 높은 사실성이 요구되는 작업에서 텍스트 모델보다 더 낮은 성능을 보인다고 보고하였다. 이러한 사실성의 저하는 적어도 일부는 학습에 사용할 수 있는 음성 데이터의 양(단어 기준)이 텍스트 데이터보다 훨씬 적기 때문으로 설명된다.

이러한 문제를 해결하면서도 상호작용성을 유지하기 위해, 본 논문에서는 full-duplex speech language model인 Moshi를 확장한 MoshiRAG를 제안한다. 이는 Retrieval-Augmented Generation(RAG) 기능을 갖춘 최초의 full-duplex 음성 모델이다. RAG는 대규모 언어 모델(LLM)의 사실성을 향상시키기 위한 대표적인 방법으로 널리 사용되어 왔지만, 지속적인 음성 상호작용이 요구되는 full-duplex 음성 시스템에서는 엄격한 실시간 제약 때문에 거의 연구되지 않았다.

본 논문에서는 음성 응답이 시작되는 시점과 핵심 정보가 실제로 전달되는 시점 사이에 존재하는 자연스러운 시간 간격(Figure 2의 keyword delay)을 활용하여 이 문제를 해결한다. 

이를 위해 모델이 지식이 필요한 질문을 받았을 때 retrieval trigger 신호를 예측하도록 하는 특수한 fine-tuning 데이터를 설계하였다. 이 신호가 발생하면 비동기적으로 정보 검색 시스템이 동작하여 현재 대화 문맥과 관련된 참고 문서를 검색한다. 검색된 정보는 응답에서 핵심 내용이 시작되기 전에 생성 과정에 주입된다. 또한 retrieval 과정 전체가 2초 이내에 완료되도록 설계하였으며, 이는 기존 speech language model의 keyword delay보다 짧은 시간이다(Table 1).

이와 같은 구조는 상호작용성을 유지하면서 사실성을 향상시킬 뿐 아니라, 사용하는 retrieval 백엔드의 종류에 독립적이라는 장점도 가진다. 즉, LLM 기반 retriever나 검색 엔진 등 다양한 retrieval 방법을 별도의 재학습 없이 손쉽게 연결할 수 있으며, 합리적인 시간 안에 텍스트 형태의 참고 정보를 제공할 수 있다면 그대로 사용할 수 있다. 이러한 설계는 향후 시스템의 확장성과 유연성을 높여준다.

실험 결과, MoshiRAG는 질의응답(QA) 벤치마크에서 기존 Moshi의 사실성을 크게 향상시키면서도, full-duplex 벤치마크에서 측정한 음성 대화의 상호작용성 역시 우수하게 유지하였다. 

  • 또한 추론 시 더 강력한 retrieval 백엔드로 단순히 교체하는 것만으로도 성능을 더욱 향상시킬 수 있음을 보였다. 
  • 마지막으로, 학습 과정에서 보지 못한 수학적 추론 문제에서도 우수한 일반화 성능을 확인하였다. 
  • 이는 Moshi가 수학 문제를 해결하기 위해 외부 LLM을 하나의 도구(tool)처럼 활용할 수 있음을 보여주는 초기 사례로 볼 수 있다. 
이러한 결과는 향후 full-duplex 모델이 보다 일반적인 tool-use 능력을 갖출 수 있는 가능성을 시사하며, 실시간 음성 인터페이스와 강력한 문제 해결 메커니즘을 결합함으로써 더욱 강력하고 신뢰할 수 있으며 사용자 친화적인 음성 AI 비서를 구축할 수 있음을 보여준다.

마지막으로, 저자들은 MoshiRAG의 추론 코드를 공개하고, 여러 데모 영상을 함께 제공한다.

2. Related Work

dGSLM(Nguyen et al., 2023)이 end-to-end 다중 화자(multi-speaker) 대화 모델링을 처음 제안한 이후, duplex 모델은 음성 대화 시스템에서 중요한 연구 방향으로 자리 잡고 있다. 사용자와 시스템의 음성을 함께 모델링하기 위해, 한 가지 접근법은 time-multiplexing 방식을 사용하는 것이다. 이 방식에서는 사용자 입력을 일정 길이의 음성 청크(chunk)로 나누어 처리하고, 동일한 길이의 응답을 번갈아 생성한다. 반면 Moshi와 같은 dual-channel 구조를 사용하는 모델은 입력 음성과 출력 음성을 각각 별도의 채널에서 높은 프레임 속도로 동시에 처리함으로써, 실시간 full-duplex 대화를 가능하게 한다.

음성 대화 모델의 사실성(factuality) 을 향상시키기 위해 최근에는 RAG(Retrieval-Augmented Generation)를 적용하는 연구도 활발히 이루어지고 있다. 또한 StreamRAG와 KAME와 같은 동시기 연구들은 음성 대화에서 존재하는 시간적 여유를 활용하여 정보 검색을 수행하는 방식을 제안하였다. 그러나 StreamRAG는 미리 구축된 고정된 문서 집합(pre-indexed corpus)만을 사용하는 non-full-duplex 환경에 한정되어 있으며, 실시간 full-duplex 대화가 요구하는 엄격한 시간 제약을 고려하지 못한다. 반면 KAME는 full-duplex 환경을 지원하지만, 정보원으로 LLM만 사용할 수 있고 대화 문맥과 무관하게 일정한 시간 간격마다 LLM을 반복 호출하여 정보를 생성하기 때문에 계산량이 크게 증가하는 문제가 있다.

  • StreamRAG, KAME 한번 봐야겠다
  • Stream RAG: Instant and Accurate Spoken Dialogue Systems with Streaming Tool Usage
  • KAME: TANDEM ARCHITECTURE FOR ENHANCING KNOWLEDGE IN REAL-TIME SPEECH-TO-SPEECH CONVERSATIONAL AI

이에 비해 MoshiRAG는 필요한 경우에만 동적으로 retrieval을 수행하므로 훨씬 효율적이다. 또한 LLM 기반 지식뿐만 아니라 웹 검색까지 지원하여, RAG를 개방형(open-domain) full-duplex 대화 환경으로 확장한다. RAG 외에도 Audio-CoT와 같은 audio 및 speech 모델의 chain-of-thought 추론을 활용하는 연구들도 제안되고 있다. 이러한 방법들은 본 논문에서 제안하는 프레임워크와 상호 배타적인 것이 아니라, 향후 자연스럽게 함께 결합될 수 있는 기술로 볼 수 있다.

3. System Design

MoshiRAG 프레임워크는 Moshi(Defossez et al., 2024)를 기반으로 구축되었다. Moshi의 응답 생성 과정에 외부 정보를 통합하기 위해, 먼저 사람과 기계 사이의 음성 대화에서 존재하는 시간적 제약(timing constraints) 을 분석한다. 이를 바탕으로, 실시간 상호작용을 담당하는 full-duplex front-end와 비동기적으로 동작하는 retrieval back-end가 병렬로 수행되는 프레임워크를 제안한다. 이를 통해 모델은 실시간 상호작용성을 유지하면서도, 외부에서 검색한 지식을 응답 생성 과정에 실시간으로 반영할 수 있다.

3.1. Timing Constraints

먼저 사람과 기계의 음성 대화에서 사용되는 지연(latency) 관련 용어를 정의한다(Figure 2).

  • Time-to-first-audio-token (TTFAT): LLM에서 널리 사용하는 Time-to-first-token (TTFT) 의 음성 버전이다. 사용자의 발화가 끝난 시점부터 모델이 첫 번째 오디오 토큰을 생성하기까지의 시간을 의미한다.¹

  • Keyword delay: 모델이 음성 응답을 시작한 시점부터, 사용자의 질문에 대한 핵심 정보(예를 들어 질문의 답을 직접 포함하는 핵심 단어)가 처음 등장하는 시점까지의 시간이다. 자세한 정의는 Section 5.2에서 설명한다.

  • End-to-end keyword delay (E2EKD): 사용자의 질문이 끝난 시점부터 핵심 단어가 실제로 응답에서 언급될 때까지의 전체 시간이다. 정의에 따라 E2EKD = TTFAT + Keyword delay 이다.

  • Retrieval delay: 모델이 retrieval trigger를 예측한 시점부터 retrieval 과정이 완료될 때까지 걸리는 시간이다.

이 가운데 E2EKD는 사용자가 의미 있는 정보를 얼마나 빨리 받는지를 결정하는 중요한 지표이다. 

  • Retrieval을 사용하는 시스템에서는 retrieval이 사용자의 질문이 끝난 이후에 시작된다고 가정하면, retrieval delay가 E2EKD보다 짧아야만 검색된 정보를 응답에 제때 반영할 수 있다.
  • 즉 질문 끝나고 나서 첫번째 응답 토큰이 나오는게 TTFAT이고 그 이후 중요 keyword 나올때까지가 keyword delay임
  • 즉 질문 끝나고나서 E2EKD(TTFAT+keyword delay)안에 검색한 결과의 키워드가 나와야한다는 것
  • retrieval delay=스페셜토큰(<ret>)나오고 검색시스템 던져서 결과받을때까지의 시간인데, 
    • 실제로 질문이 끝나자마자 스페셜토큰(<ret>)이 나오는 형태로 학습데이터가 구성되었기 때문에 Retrieval delay < E2EKD 구조가 되어야 한다는 것

저자들의 예비 분석 결과, 기존 speech language model의 E2EKD는 대부분 3초 이상인 것으로 나타났다(Table 1). 따라서 MoshiRAG에서는 데이터 생성과 모델 학습 과정 모두에서 retrieval delay를 최대 2초 이내로 제한하였다. 이를 통해 외부 지식을 실시간으로 응답에 반영하면서도 자연스러운 대화 품질을 유지할 수 있도록 설계하였다.

¹ 이 정의는 내용 생성 지연(content generation latency) 만을 측정하며, codec이나 vocoder와 같은 토큰을 실제 음성으로 변환하는 시간은 본 연구의 범위와 무관하므로 포함하지 않는다.

3.2. System Overview

본 논문에서는 front end를 사용자와 직접 음성을 주고받는 모듈로 정의하고, back end를 사용자와 직접 상호작용하지 않는 모듈로 정의한다. 예를 들어, 전통적인 ASR–Dialogue–TTS 구조에서는 ASR과 TTS 모듈이 front end에 해당하며, 텍스트 기반의 dialogue management 시스템은 back end에 해당한다. 사용자 경험을 향상시키기 위해 front end는 사용자 입력에 즉각적으로 반응해야 한다. 반면 back end는 대화 흐름을 계획하거나, 올바른 정보를 선택하거나, 대화 주제를 관리하는 등 사실성(factuality) 과 추론(reasoning) 을 우선시할 수 있으며, 사용자와 직접 상호작용하지 않기 때문에 상대적으로 시간적인 제약이 적다.

본 연구에서는 원래의 Moshi 모델(약간의 수정만 적용)을 full-duplex front end로 사용하고, 이와 병렬로 동작하는 비동기 정보 검색 시스템(asynchronous information retrieval system) 을 back end로 사용한다. 또한 대부분의 정보 검색 시스템은 텍스트를 입력으로 사용하므로, 사용자 음성을 검색에 활용하기 위해 streaming ASR을 추가로 사용하여 음성을 텍스트로 변환한다. 

이 ASR 역시 사용자의 음성을 직접 입력받기 때문에 정의상 front end에 속한다. 전체 시스템의 개념도는 Figure 3에 제시되어 있다.

Front end와 back end가 동기화되지 않은(asynchronous) 상태로 동작하기 때문에, 시스템은 사람이 듣고 말하는 동시에 생각하는 것(thinking while listening and speaking) 과 유사한 방식으로 동작할 수 있다.

음성 대화 중에는 front-end의 Moshi가 Mimi codec encoder가 생성한 사용자 음성 토큰을 입력으로 받아, 자기회귀(autoregressive) 방식으로 텍스트 전사(text transcription) 와 응답 음성 토큰을 각각 별도의 채널에서 예측한다. 기존 Moshi와 비교하여 추가된 구성 요소는 두 가지뿐이다.

  • Retrieval trigger token (<ret>)

  • Reference text encoder

Figure 3과 Figure 4에서 보이듯이, 모델이 <ret> 토큰을 예측하면 ASR이 생성한 사용자 전사와 Moshi가 생성한 assistant 전사를 모두 모아 현재까지의 대화 문맥(conversation context) 을 구성하고, 이를 retrieval back end로 전달한다. Retrieval이 진행되는 동안에도 front-end Moshi는 계속해서 full-duplex 방식으로 사용자 음성을 입력받고 응답을 생성하므로, 대화는 중단되지 않는다.

저자들은 <ret>가 예측된 이후부터 retrieval이 완료되기 전까지 생성되는 내용을 pre-RAG content라고 정의한다. 학습 데이터에서는 pre-RAG content가 주로 다음과 같은 내용을 포함한다.

  • 사용자의 질문에 대한 대략적인(coarse) 답변

  • "좋은 질문이네요."와 같은 자연스러운 filler 문장

이러한 내용은 별도의 외부 지식이 없어도 생성 가능하다.

Retrieval이 완료되면, 검색된 문서는 reference text encoder를 통해 임베딩으로 변환되고 Moshi 내부에 주입된다. 이후 모델은 응답의 나머지 부분, 즉 핵심 정보가 포함된 부분을 외부 지식에 기반하여 생성할 수 있으며, pre-RAG content 이후에 더욱 정확하고 상세한 답변을 이어서 생성한다.

3.3. Building Blocks

Figure 3에서 보이듯이, MoshiRAG는 다음의 세 가지 주요 구성 요소로 이루어진다.

  • RAG 학습 데이터로 fine-tuning된 7B Moshi 모델

  • 1B 규모의 streaming ASR 모델

  • Retrieval back end

이들 구성 요소는 모두 텍스트(text) 를 통해 서로 통신한다. 이러한 모듈형(modular) 구조는 각 구성 요소를 독립적으로 학습할 수 있도록 하며, 특정 구성 요소를 다른 모델로 교체하거나 업그레이드하더라도 나머지 시스템에는 영향을 주지 않는 장점을 제공한다. 각 구성 요소는 아래와 같다.

3.3.1. RAG가 결합된 Moshi 모델

기존 Moshi(Defossez et al., 2024)는 RQ-Transformer(Lee et al., 2022)를 사용하여 모델의 음성 출력에 해당하는 텍스트 토큰과 오디오 토큰을 자기회귀적으로 모델링한다. 이 구조는 12.5Hz로 동작하는 주 “temporal” Transformer와, 각 시간 단계마다 8개의 오디오 토큰을 예측하는 “depth” Transformer로 구성된다. Temporal Transformer에는 사용자 오디오 토큰도 함께 입력된다.

형식적으로, 시간 단계 (i)에서 temporal Transformer에 입력되는 벡터 (h_i)는 다음과 같다.

여기서 (\mathrm{emb}^{r}_{m,i})는 시간 단계 (i)에서 역할 (r), 즉 model 또는 user, 그리고 모달리티 (m), 즉 text 또는 speech에 해당하는 임베딩을 의미한다.

검색이 활성화되지 않은 경우, MoshiRAG는 기존 Moshi와 동일하게 동작한다. 시간 단계 (i_{\mathrm{ret}})에서 (\langle\mathrm{ret}\rangle) 신호가 예측되고, 검색 지연이 (d)초라고 가정하자. 검색된 참조 텍스트는 길이 (l)의 임베딩 시퀀스

로 인코딩된다. 이 임베딩은 학습 가능한 단일 선형 계층을 통해 투영된 뒤, (l)개의 temporal step에 걸쳐 스트리밍 방식으로 temporal Transformer 입력에 더해진다. 참조 정보를 반영한 입력 (h'_i)는 다음과 같다.


이며, (f_r)은 Moshi의 프레임률이다.

검색된 참조 문서가 긴 경우에는 문제가 발생할 수 있다. 예를 들어 Moshi의 프레임률이 12.5Hz일 때, 250개 토큰으로 구성된 참조 문서는 약 20초 길이의 임베딩 시퀀스에 해당할 수 있다. 이는 일반적인 음성 대화에서 한 턴의 길이를 크게 초과한다.

이를 해결하기 위해 저자들은 사전 학습된 시퀀스 압축 네트워크인 ARC-Encoder(Pilchen et al., 2025)를 사용하여 참조 시퀀스의 길이를 4분의 1로 줄인다. 다른 참조 인코더 선택에 대한 실험은 부록 B.1에서 추가로 다룬다.

각주 5의 구체적인 임베딩 정의는 다음과 같다.

로 주어진다. 여기서 (s^r_{i,j})는 역할 (r)의 시간 단계 (i)에서 (j)번째 계층의 오디오 토큰이며, (\mathrm{Emb}^{r}_{\mathrm{speech},j})는 해당 오디오 토큰 계층의 임베딩 테이블이다.

  • <ret>가 안나오거나, 이것에 대한 응답받기전에는 그냥 일반 Moshi 처럼 작동한다
    • 일반 Moshi라는건, 식 1처럼 text(model), speech(model), speech(user)가 입력으로 동시에 들어와서 더한 hidden representation이 입력 representation이 되는 것
  • <ret>에 의한 결과가 나왔다고 해보자.
    • 검색 결과가 250개 reference 토큰이라고 해보자. 
    • reference 토큰 임베딩 r1,...,r250은 각 step별로 하나씩 더해진다.
      • 입력1=h1+r1
      • ...
      • 입력250=h250+r250
    • Moshi 에서는 12.5Hz을 사용하고, 이는 1초=12.5개토큰 -> 1개 토큰은 1/12.5=0.08초이다.
      • 따라서 250개 reference 토큰을 모두 입력에 반영하려면 0.08*250=20초가 필요하다는 것
      • 250개의 각각 토큰이 0.08초에 하나씩 입력되려면 Moshi 응답이 20초이상이어져야하는데, 실제로는 이럴 가능성이 낮다.
    • 따라서 ARC-C Encoder라는 것을 사용하여 길이를 4배 압축한다
      • 위 예시에서 250개토큰 = 20초 -> 5초로 압축한다는 것
      • r1~r250 => r1~r62 정도로 개수가 압축이 된다는것
      • 그래도 이 경우에는 5초가 필요하긴한데, 응답이 5초가 안되면 어떻게 되는거지? (아마 뒷 부분 토큰은 안들어가는것 같음)
      • 따라서 모델 응답이 End of Sentence 이런 토큰나오면 뒷 부분의 reference 임베딩은 버려지는거 같음

3.3.2. Streaming ASR

Retrieval을 수행하기 위해서는 사용자의 음성을 텍스트로 변환해야 한다.

이를 위해 저자들은 0.5초 지연(latency) 을 갖는 사전학습된 streaming ASR 모델을 사용한다. 이 모델은 약 1B parameter 규모로, MoshiRAG의 다른 구성 요소와 비교했을 때 계산 비용은 매우 작다.

여기서 0.5초 지연이 생기기는 함

3.3.3. Retrieval Back End

모델이 <ret> 토큰을 출력하면 먼저 0.5초 동안 기다려 streaming ASR이 사용자의 발화를 완전히 전사하도록 한다.

이후 지금까지의 대화 transcript를 retrieval back end로 전달한다. Retrieval back end는 텍스트를 입력받아 텍스트를 출력하는(text-in, text-out) 시스템이며, Moshi가 다음 응답을 생성하는 데 도움이 되는 reference document를 충분히 짧은 시간 안에 반환해야 한다.

본 논문에서는 두 가지 retrieval 방식을 사용한다.

  • LLM 기반 Retrieval

    LLM에게 현재까지의 대화 문맥을 입력으로 제공하고, Moshi의 다음 응답에 직접 도움이 되는 짧고 사실적인(reference) 문서를 생성하도록 프롬프트를 작성한다. 이 reference에는 사람이 읽기 어려운 형식이나 불필요한 서식은 포함하지 않는다. 사용한 프롬프트는 Appendix Table 15에 제시되어 있다.

  • Search 기반 Retrieval

    웹 검색 도구인 Tavily를 이용하여 실시간 정보를 검색한 뒤, 검색 결과의 핵심 내용을 reference document 형태로 반환한다. Perplexity와 같은 다른 검색 도구도 존재하지만, Tavily는 이미 간결하게 요약된 결과를 제공하기 때문에 추가적인 후처리가 거의 필요하지 않다.

저자들의 목표는 특정 데이터베이스만 검색하는 전통적인 RAG가 아니라 다양한 분야의 질문에 대응할 수 있는 음성 비서를 만드는 것이므로, 일반적인 RAG에서 사용하는 고정된 문서 데이터베이스 대신 범용 LLM과 웹 검색 도구를 retrieval backend로 사용하였다.

범용 LLM을 써서 데모라도 일단 만들어보는것을 목표로해보자.

4. Data and Training

4.1. Data Generation

MoshiRAG의 학습은 합성(synthetic) 데이터를 이용하여 수행된다. 먼저 LLM을 사용하여 특정 주제(topic)에 대한 텍스트 기반 대화 스크립트(conversational script) 와, 이에 대응하는 reference document를 생성한다. 이후 이러한 스크립트를 2명의 화자가 참여하는 음성 대화로 변환한다. 전체 데이터 생성 과정은 다음과 같다.

4.1.1. Topics

지식이 필요한 질의(knowledge-intensive queries)가 포함된 대화를 생성하기 위해, 저자들은 기존 QA 데이터셋으로부터 다양한 대화 주제(topic) 를 수집하였다.

구체적으로,

  • Natural Questions의 training set에서 약 307k개

  • HotpotQA에서 약 90k개

  • TriviaQA에서 약 76k개

의 주제를 추출하여 총 474k개의 QA 기반 주제를 구성하였다.

또한 QA 데이터셋 외에도 전문적인 분야의 대화를 만들기 위해 LLM을 활용하였다. 여러 차례의 LLM과의 상호작용을 통해 16개의 대분류(category) 와 111개의 전문 분야(domain) 를 선정한 뒤, Gemma 3 27B에게 각 분야마다 50개의 대화 주제를 생성하도록 하여 추가로 약 5.5k개의 전문 분야 주제를 생성하였다.

세부적인 주제 분류 체계와 생성 과정은 Appendix D에서 설명한다.

4.1.2. Conversation Scripts with References

각 주제에 대해 LLM을 사용하여 사람과 Moshi 사이의 자연스러운 멀티턴 대화 스크립트를 생성하였다. 또한 각 스크립트에는 지식이 필요한 응답을 지원하기 위한 reference document가 함께 생성된다. 예시는 Appendix Table 14에 제시되어 있다.

이러한 스크립트에서는 지식이 필요한 Moshi의 응답마다 명시적으로 reference document를 연결하여 실제 RAG 동작을 모사한다.

RAG가 적용되는 하나의 응답은 다음의 세 부분으로 구성된다.

  • Lead: 외부 지식이 필요하지 않는 도입부

  • Body: reference에 기반하여 생성되는 핵심 내용

  • Tail: 응답을 마무리하는 선택적인 마무리 부분

이 구조는 학습 시 Body가 시작되기 전에 reference 정보를 주입할 수 있도록 설계되었으며, 이는 Section 3.2에서 설명한 asynchronous RAG 메커니즘과 동일한 구조이다.

이러한 대화 스크립트를 생성하기 위해 저자들은 Gemma 3 27B 모델을 세 개 사용하였으며, 각각 다음과 같은 역할을 담당한다.

  • User LLM

  • Moshi LLM

  • Reference LLM

User LLM은 현재 주제(topic) 와 이전 대화 내용은 볼 수 있지만 reference document는 볼 수 없다. 이는 사용자가 reference 내용을 미리 알고 있는 상황을 방지하기 위함이다.

반대로 Moshi LLM과 Reference LLM은 주제는 직접 볼 수 없지만, 이전 대화 내용과 reference 정보는 모두 제공받는다. 따라서 실제 사람과 AI의 대화처럼, Moshi는 사용자의 발화만을 통해 현재 주제를 추론해야 한다.

대화 스크립트는 한 줄(line)씩 순차적으로 생성된다. 먼저 현재까지 생성된 내용을 각 역할에 맞게 정리한 뒤(예를 들어 User LLM에는 reference를 제거한 형태를 제공), 적절한 LLM을 호출하여 다음 한 줄을 생성한다. 이러한 과정을 User LLM이 대화를 종료(EOC) 할 때까지 반복한다.

대화의 다양성과 모델의 강건성(robustness)을 높이기 위해 세 가지 프롬프트 버전을 설계하였다.

  • v1: 선택된 주제를 중심으로 하는 일반적인 대화

  • v2: 사용자가 Moshi에게 더 자주 반박하거나 도전하는 형태의 대화

  • v3: 사용자가 중간에 잡담(small talk)이나 주제와 무관한 이야기를 섞어 말하는 대화

각 프롬프트 버전에 대해 모든 주제마다 하나의 멀티턴 대화를 생성하였으며, 대화 시작 부분에는 Moshi의 인사말을 추가하였다.¹

또한 QA 데이터셋에 대해서는 별도로 Single-turn 데이터셋도 구축하였다. 이 데이터셋에서는 QA 데이터셋의 질문을 그대로 사용자 질문으로 사용하고, LLM이 reference document와 Moshi의 응답을 생성한다.

최종적으로 약 190만 개(1.9M) 의 대화 데이터를 생성하였다. 학습 데이터와 검증 데이터의 통계는 각각 Table 4와 Table 5에 제시되어 있으며, v1 설정에서 사용한 실제 프롬프트는 Appendix Table 15에 수록되어 있다.

아래의 흐름대로 데이터가 만들어진다

  • QA 데이터 샘플 하나 추출
    • Question: Where is Emily Cooper from? Answer: Chicago. 란 데이터가 있다면 Emily Cooper's hometown 란 토픽을 추출
    • LLM으로 토픽 추출 (어떤 LLM인지 공개되진 않음)
  • user LLM에게 토픽이 주어지고 이에 맞는 question 생성함 (Gemma3 27B)
    • 대화 시작이 질문으로 시작하는 형태의 데이터인가봄 
    • 사람이라면, 본인이 말할 토픽은 알고 대화를 시작했을 것이기 때문에 토픽이 주어짐
    • Topic + 이전 대화 기록 이 주어지고 응답을 하게하는거고 Reference들은 주어지지 않음
    • Emily Cooper's hometown 가 주어지고, 아래와 같은 형태의 질문이 만들어짐
    • 예시1) Hey Moshi, I recently started watching Emily in Paris. Do you know where Emily Cooper is from?
    • 예시2) Where is Emily Cooper from?
  • Referece LLM에 대해 컨텍스트주고 응답을 시킴 (Gemma3 27B)
    • 이때 topic은 안주어지고, 대화 컨텍스트만 주어지는 형태 
    • 모델은 유저의 토픽을 모르는채 대화를 했을 것이기 때문에 토픽은 안주어짐
    • Where is Emily Cooper from? 가 입력이 되겠고
    • Emily Cooper is originally from Chicago before moving to Paris for work. 이런 응답을 추출함
    • 즉 백그라운드모델인 Gemma3 27B가 GT을 뽑아주는 역할로, 이 응답을 Reference로 간주함
  • Moshi LLM 역할 (Gemma3 27B)
    • 모델은 유저의 토픽을 모르는채 대화를 했을 것이기 때문에 토픽은 안주어짐
    • 컨텍스트: Where is Emily Cooper from? 
    • Reference: Emily Cooper is originally from Chicago before moving to Paris for work.
    • 을 모델에게 주어주고 아래처럼 응답하게함. 아래 프롬프트 참고
    • Lead
      • That's a good question.
    • Body
      • Emily Cooper is from Chicago before moving to Paris.
    • Tail
      • It's one of the key parts of the show.
  • 지금 상황을 보면
    • User: 
      • Where is Emily Cooper from? 
    • Reference:
      • Emily Cooper is originally from Chicago before moving to Paris for work.
      • 이거는 다음턴부터는 날리는 것. 즉 Moshi 응답 생성에만 쓰임.
    • Moshi:
      • (Lead) That's a good question.
      • (Body) Emily Cooper is from Chicago before moving to Paris.
      • (Tail) It's one of the key parts of the show.
    • 그 다음 User, Moshi 응답을 컨텍스트로 User LLM은 다음 응답을 생성하고, Moshi도 그 다음 응답을 생성하다가 User LLM이 대화 끝내는 토큰 내뱉을때까지 생성됨
  • 최종 학습 데이터에서는 Moshi 응답 맨 앞에 스페셜 토큰 붙이는게 아니라, 앞의 텍스트 토큰을 <ret>로 바꾸는 식임
    • 원래 Moshi가 계속 말하는게 아니라, user가 말하고 있을때는 slience 토큰(텍스트)이 나오고 있을 것이다. 
    • <slience> 마지막 부분을 <ret>로 바꾼다는 개념이다.
    • <slience> <slience> <ret> That's a good question. mily Cooper is from Chicago before moving to Paris. It's one of the key parts of the show.

4.1.3. Speech Synthesis

생성된 텍스트 대화를 음성으로 변환하기 위해, 저자들은 원래 Moshi 논문에서 instruction tuning 데이터를 생성할 때 사용했던 것과 유사한 다중 채널(multi-channel) TTS 모델을 사용하였다.

기존 Moshi와 동일하게,

  • Moshi의 음성은 하나의 고정된 화자를 사용하고,

  • 사용자의 음성은 내부 데이터셋에서 임의로 화자를 선택하였다.

생성된 음성 데이터의 평균 길이는

  • 멀티턴 대화: 약 2분

  • Single-turn QA: 약 15초

이다.

¹ 일부 벤치마크는 사용자가 먼저 말을 시작하는(user-first) 설정을 사용한다. 이에 대응하기 위해 학습 시에는 30% 확률로 Moshi의 초기 인사말을 제거하여 다양한 대화 시작 형태를 학습하도록 하였다.

4.2. 학습

데이터 생성 파이프라인은 두 화자 간의 음성 대화와 함께, 특정 Moshi 턴에 연결된 참조 문서를 생성한다. 그러나 Moshi 모델을 학습할 때는 ($\langle\mathrm{ret}\rangle$) 토큰을 예측해야 하는 시점과 검색 과정에 걸리는 시간, 즉 식 (2)의 ($i_{\mathrm{ret}}$)과 검색 지연 (d)를 알 수 없다.

그러게? 언제 검색된 결과가 올지 모르니까 학습할땐 어떻게 하지?

($\langle\mathrm{ret}\rangle$) 토큰의 위치를 정하기 위해, 저자들은 멀티채널 TTS 모델이 제공하는 음성과 텍스트 간 강제 정렬 정보를 활용한다. 구체적으로, RAG가 적용되는 Moshi 턴에서 lead 구간의 첫 번째 텍스트 토큰 바로 앞에 위치한 텍스트 토큰을 ($\langle\mathrm{ret}\rangle$) 토큰으로 대체한다.

검색 지연은 다음의 샘플링 전략을 통해 모사한다.

여기서 (d')는 학습 중 사용하는 모의 검색 지연이고, (d_{\mathrm{lead}})는 lead 구간의 길이이며, (p \sim \mathcal{U}(0,1))은 무작위 변수이다. 이 설계에서는 대부분의 경우 검색 지연이 ((1.0, d_{\mathrm{lead}}-1.0)) 구간에서 샘플링된다. 따라서 body 구간에서 핵심 정보가 언급되기 전에 최소 1초의 여유 시간을 확보할 수 있다. 한편, 0.2의 폴백 확률을 두어 검색이 비정상적으로 빠르거나 느린 경계 상황까지 학습 분포에 포함한다.

  • 즉 실제 delay가 얼만큼 걸릴지 모르니까 다양하게 분포를 설정해서 학습하겠다는 것으로 보면됨
  • lead의 문장을 실제 음성이 얼마나 말하는지를 dlead 라고 보면됨. 즉 검색결과는 사실상 dlead 이전에 온다는 가정이 있음
  • 80% 확률로는 식3의 두번째인 U(1.0, dlead-1.0)에서 추출하고
  • 20% 확률로는 식1의 첫번째인 U(0,dlead)에서 추출함
  • 이렇게 그림5처럼의 지연분포를 만들었고, 인퍼런스때보다 더 다양한 지연을 포함한다는것
  • 근데 dlead보다 늦어진 검색결과를 받으면 어떻게 되는거지? 이 부분은 고려안된거 같긴함

그림 5는 학습 시점과 추론 시점의 검색 지연 분포를 보여준다. 두 분포는 서로 겹치지만, 학습 시점의 분포가 더 넓기 때문에 모델이 다양한 경계 상황에 노출되고, 이는 잠재적으로 강건성을 높인다. 또한 추론 시점의 검색 지연은 거의 항상 키워드 지연보다 짧다. 이는 3.1절에서 설명한 시간 제약이 대부분의 경우 충족됨을 의미한다.

MoshiRAG는 기존 Moshi 모델로 초기화하며, 참조 텍스트 인코더를 제외한 모든 파라미터를 학습 가능하게 설정한다. 각 참조 문서에는 0.2의 확률로 드롭아웃을 적용한다. 참조 문서가 드롭되는 경우, 식 (2)의 임베딩을 다음과 같이 설정한다.

여기서

이며, ($h_{\mathrm{dropout}}$)은 학습 가능한 벡터이다.

  • 학습 샘플 100개가 있다면 20%을 참조 문서를 못받았다고 가정하는 것
    • 80개: 실제 참조 문서 임베딩을 Moshi에 입력
    • 20개: 참조 문서를 일부러 제거
    • 실제 서비스상, 항상 검색결과가 안정적으로 받는것은 아니기 때문이라고 함
  • 이럴 경우, reference가 없으니 아무것도 안더하는게 아니라 h_dropout이란 특별한 벡터를 더해주는 것 (참조 문서가 제공되지 않았다는 신호)
    • h_dropout도 학습되는 벡터임
    • 단 h_dropout을 쓸때는 여러 step에 들어가는게 아니라, 검색 결과가 도착할 시점 맨 처음에만 더해주는 것
  • 이걸 통해서 다음을 구분할 수 있음
    • 아직 검색 결과가 도착하지 않은 상태
    • 검색이 끝났지만 참조 문서가 없는 상태

원시 오디오 신호에는 80밀리초 크기의 윈도우를 사용하는 윈도우 기반 필터링을 적용한다. 각 오디오 구간의 RMS 값이 (-65) dBFS보다 낮으면 해당 구간을 0으로 설정한다.

Moshi 모델은 합성 데이터셋에서 100,000번의 업데이트 동안 학습된다. 학습률은 (2 \times 10^{-6}), 배치 크기는 32로 설정한다. 그 밖의 학습 세부사항은 Defossez et al. (2024)의 설정을 따른다.

5. 실험

별도로 명시하지 않는 한, 검색 백엔드로 데이터 생성 단계와 동일한 프롬프트를 사용하는 Gemma 3 27B 모델을 사용한다. 해당 프롬프트는 표 15에 제시되어 있다. 기존 벤치마크는 주로 단일 턴 상황에 초점을 맞추고 있으며, MoshiRAG의 멀티턴 대화 능력은 평가하지 않는다는 점에 유의한다.

5.1. 사실성

사실성은 음성 질의응답 데이터셋을 사용하여 평가한다. 각 데이터셋은 음성으로 제시된 질문과 이에 대응하는 정답 텍스트로 구성된다. 저자들은 OpenAudioBench의 오디오 파일을 사용하고, 해당 벤치마크의 평가 프로토콜을 따른다. 구체적으로 Llama Questions, Web Questions, TriviaQA 데이터셋에서 MoshiRAG의 응답이 정답인지 여부를 LLM judge를 통해 평가한다.

근데 이것에 대한 단점은 앞에 lead가 있어야한다는 점 같긴한데, 이것에 대한 평가는 이뤄지지 않긴함

추가로, HaluEval 코퍼스를 기반으로 더 어려운 평가 세트를 구축한다. HaluEval의 qa 하위 집합에서 앞의 1,000개 샘플을 수집하고, 멀티채널 TTS 모델을 사용해 질문을 음성으로 합성한다. 이때 사용자 음성은 CommonVoice 코퍼스에서 무작위로 샘플링한다. MoshiRAG와 비교 대상 음성 언어 모델들의 결과는 표 1에 정리되어 있다.

실험 결과, Moshi에서 MoshiRAG로 확장했을 때 성능이 크게 향상되며, 특히 더 어려운 벤치마크에서 향상 폭이 두드러진다. 이러한 개선은 주로 RAG 통합에서 비롯된 것으로 볼 수 있다. 실제로 MoshiRAG는 동일한 RAG 학습 데이터로 미세조정한 일반 Moshi 모델보다도 훨씬 높은 성능을 보인다.

전체적으로 MoshiRAG는 대부분의 기존 음성 언어 모델과 비슷하거나 더 나은 성능을 달성한다. 비교 모델의 대부분은 full-duplex 모델이 아니며, GPT-4o Audio를 제외하면 MoshiRAG가 전반적으로 경쟁력 있는 결과를 보인다.

표 1의 ref. 열은 검색 백엔드가 제공한 참조 정보 자체의 정확도를 나타낸다. 평균적으로 이 점수는 MoshiRAG의 최종 음성 응답 정확도보다 약 5% 높다. 이는 검색된 정보를 Moshi에 통합하는 과정에서 일부 정보 손실이 발생한다는 것을 보여주며, 향후 개선 가능성이 있음을 시사한다.

  • ref의 정확도를 100% 반영하지는 못하지만 그래도 기존의 오디오 모델들과 비교해서 가장 좋은 느낌을 보여준다.
  • Vanilla Moshi에 비해서는 엄청 좋은것을 보여줌
  • Qwen3-Omni-A3B-Ins랑 비슷한 수준같음. 근데 이건 Full-duplex 모델임

한편 ref. 점수는 MoshiRAG가 달성할 수 있는 성능의 상한으로도 볼 수 있다. 다행히 더 강력한 지식원을 사용하면 이 상한도 높일 수 있다. 검색 백엔드를 GPT-4.1이나 Tavily 검색으로 교체하면, TriviaQA와 HaluEval처럼 더 어려운 데이터셋에서 성능이 크게 향상된다. 이 설정에서 MoshiRAG는 GPT-4o Audio를 제외한 모든 비교 음성 언어 모델보다 높은 성능을 보인다.

5.2. 지연 시간 및 계산 비용

사실성뿐만 아니라, 사용자의 요청을 처리하는 데 필요한 시간과 계산량 역시 음성 언어 모델에서 중요한 요소이다. 저자들은 3.1절에서 정의한 TTFAT를 측정하기 위해, 공개적으로 사용 가능한 각 모델을 단일 H100 GPU에서 실행하고 첫 번째 오디오 토큰이 출력될 때까지 걸린 시간을 기록한다. 다만 MoshiRAG와 Step-Audio-Chat은 예외이다. MoshiRAG의 경우 프런트엔드 모델은 한 개의 GPU에서, 로컬 검색 백엔드는 다른 한 개의 GPU에서 실행하며, Step-Audio-Chat은 네 개의 GPU에서 실행한다.

키워드 지연을 계산하기 위해서는 먼저 Gemma 3 27B 모델을 사용해 각 모델의 응답에서 핵심 키워드를 추출한다. 이때 사용한 프롬프트는 부록의 표 17에 제시되어 있다. 이후 parakeet-tdt-0.6b-v2 ASR 모델이 제공하는 타임스탬프를 이용해, 해당 키워드가 음성 응답에서 처음 등장하는 시점을 구한다.

계산 비용은 DeepSpeed 패키지의 FLOPs profiler를 사용해 추정하며, 오디오 1초를 생성하는 데 필요한 평균 부동소수점 연산량을 보고한다. 모든 지표는 데이터셋별 결과를 매크로 평균하여 표 1에 제시한다.

기존 Moshi와 비교하면, MoshiRAG에서 사용하는 대화 템플릿, 즉 RAG가 적용되는 턴의 lead 부분 때문에 키워드 지연이 약 1초 증가한다. 그럼에도 MoshiRAG의 E2EKD는 거의 모든 비교 시스템보다 짧다.

또한 검색 과정의 추가 비용까지 포함하더라도, MoshiRAG의 계산량은 비슷한 규모의 다른 모델들과 대체로 유사한 수준을 유지한다. 이러한 결과는 MoshiRAG가 지연 시간과 계산 효율성 측면에서 합리적인 절충을 유지하면서도 높은 사실성 성능을 달성한다는 것을 보여준다.

5.3. 상호작용성

음성 비서와 인간 사용자 간의 상호작용성을 평가하는 것은 오랫동안 어려운 미해결 문제로 남아 있다. 저자들은 특정 대화 상황에서 모델의 행동을 평가하는 Full-Duplex-Bench(Lin et al., 2025)를 사용하여 이 측면을 측정한다. 이 벤치마크는 사전에 녹음된 사용자 음성을 입력으로 사용하고, 모델이 해당 음성 입력에 어떻게 반응하는지를 평가하며, 특히 턴테이킹 행동에 초점을 둔다.

구체적으로 pause 트랙은 사용자가 발화를 끝내기 전에 모델이 턴을 가져가지 않는지를 측정한다. 따라서 takeover rate(TOR)는 낮을수록 좋다.

  • 사용자가 발화가 다 안끝났는데, 모델이 발화를 해버리면 TOR이 높아지는 개념

Backchannel 트랙은 사용자가 말하는 동안 모델이 생성하는 백채널의 초당 빈도와, 그 발생 시점의 분포가 실제 인간 간 대화의 분포와 얼마나 유사한지를 함께 평가한다. 시간적 분포의 유사도는 Jensen–Shannon divergence(JSD)로 측정한다. 적절한 백채널 빈도에 대해서는 아직 합의된 기준이 없지만, 기존의 많은 음성 언어 모델이 백채널을 거의 생성하지 않기 때문에 이 벤치마크에서는 더 높은 백채널 빈도를 선호한다.

Turn taking 트랙은 사용자가 발화를 끝낸 뒤 모델이 얼마나 신속하게 턴을 가져가는지를 평가한다.

마지막으로 user interruption 트랙은 모델이 말하는 도중 사용자가 끼어들었을 때 모델이 얼마나 적절하게 대응하는지를 5점 척도의 GPT 점수로 평가한다. 또한 모델이 과도한 지연 없이 대화를 자연스럽게 재개할 수 있는지도 함께 측정한다.

표 2에서 볼 수 있듯이, MoshiRAG는 모든 평가 조건에서 기존 Moshi보다 일관되게 더 낮은 TOR을 보인다. RAG 학습 데이터로 미세조정한 Moshi도 비슷한 행동을 보이므로, 이러한 효과는 주로 학습 데이터 분포에서 비롯된 것으로 볼 수 있다. 즉, 더 길고 지식 집약적인 턴을 포함한 학습 데이터가 모델로 하여금 보다 보수적으로 턴을 가져가도록 만들고, 그 결과 TOR이 감소한다.

동시에 MoshiRAG는 Freeze-Omni와 Gemini보다 일관되게 더 낮은 지연 시간을 유지한다. 이는 기존 Moshi가 지닌 full-duplex 시스템의 실시간 상호작용 장점을 그대로 보존한다는 것을 의미한다.

또한 MoshiRAG와 RAG 데이터로 미세조정한 Moshi는 모두 기존 Moshi보다 사용자 끼어들기에 훨씬 더 잘 대응한다. 이러한 향상은 사용자가 더 자주 반박하거나, 무관한 발언을 삽입하거나, 잡담을 하는 상황을 포함한 v2 및 v3 학습 데이터에서 비롯된 것으로 보인다. 이런 데이터는 모델이 변화하는 대화 주제와 맥락에 빠르게 적응하고, 사용자의 가장 최근 요청에 신속히 대응하도록 돕는다.

  • 반면 MoshiRAG는 TOR이 낮아졌다. 이는 더 긴 대화 턴과 복잡한 상호작용이 포함된 데이터로 학습하면서, 사용자의 발화가 완전히 끝날 때까지 조금 더 기다리는 보수적인 턴테이킹을 학습했기 때문이라고 저자들은 해석한다.

5.4. 보지 못한 과제로의 일반화

MoshiRAG는 주로 질의응답 형태의 데이터로 학습되지만, 제안한 시스템 구조를 통해 학습 분포 밖의 질의에도 일반화할 수 있다. 검색 백엔드가 질문을 성공적으로 처리할 수만 있다면, MoshiRAG는 검색 기능을 외부 도구처럼 활용하여 학습 데이터의 범위를 넘어서는 능력을 얻을 수 있다.

이 가설을 검증하기 위해, 저자들은 수학 추론에 특화된 음성 언어 모델인 STITCH에서 사용한 수학 추론 데이터셋을 채택한다. 또한 HaluEval을 구성할 때와 동일한 절차를 사용하여 수학 문제를 음성 질문으로 변환한다. 

결과는 표 3에 제시되어 있다.

MoshiRAG는 아직 수학 추론을 위해 명시적으로 학습된 모델의 성능에는 미치지 못한다. 그러나 GLM-4-Voice나 기존 Moshi처럼 추론에 특화되지 않은 음성 언어 모델보다 훨씬 높은 성능을 보인다. 이는 MoshiRAG가 QA 중심의 학습 과제를 넘어 의미 있는 일반화 능력을 보인다는 것을 나타낸다.

흥미롭게도, LLM이 생성한 참조 문서를 그대로 사용하는 것보다, Moshi에 주입하기 전에 LLM에게 해당 참조를 한 번 더 요약하도록 지시했을 때 표 3의 성능이 향상되었다.

  • 대신 이러면 인퍼런스 시간이 늘어나서 lead가 끝나기전에 참조문서가 제대로 들어갈 수 있나? 

저자들은 초기 LLM 생성 참조 문서에 지나치게 많은 수치 정보, 기호 표현, 긴 추론 과정이 포함되는 경우가 많기 때문이라고 추측한다. 프롬프트에서 이를 피하도록 지시했음에도 이러한 내용이 남아 있으며, 이는 참조 정보의 통합을 어렵게 만든다. 실제로 표 3에서 참조 자체의 정답률인 ref.와 MoshiRAG의 최종 응답 정답률인 resp. 사이에 큰 차이가 나타난다.

참조 내용을 요약하여 압축하면 MoshiRAG가 핵심 개념에 더 집중할 수 있고, 결과적으로 더 정확한 응답을 생성할 수 있다.

6. 결론

본 연구에서는 full-duplex 음성 언어 모델에 RAG를 통합한 최초의 시도인 MoshiRAG를 제안한다. 제안한 시스템은 지식이 필요한 사용자 질의를 마주했을 때 Moshi가 비동기 검색 과정을 시작하도록 하면서도, 사용자와 모델 간의 대화는 중단 없이 계속 진행할 수 있게 한다.

사용자의 질문이 끝난 시점부터 모델이 핵심 정보를 실제로 말하기까지 자연스럽게 발생하는 시간적 간격을 활용함으로써, 검색 과정은 더 많은 지식을 가진 LLM이나 웹 검색을 통해 근거 정보를 얻을 수 있다. 이후 Moshi는 이렇게 얻은 사실 기반 참조 정보를 활용하여 응답을 생성한다.

이 접근법은 사실성을 크게 향상시키며, 공개된 대부분의 turn-based 음성 언어 모델보다 더 높은 성능을 보인다. 동시에 full-duplex 시스템이 본래 가지고 있는 높은 상호작용성도 유지한다.

또한 실험 결과, MoshiRAG는 명시적으로 학습하지 않은 수학 추론 과제에서도 높은 성능을 보였다. 이는 MoshiRAG의 도구 사용 능력이 학습 분포 밖의 과제에도 일반화될 수 있음을 보여준다.

현재 MoshiRAG에서 검색을 시작할지 여부는 전적으로 학습 데이터에 의존한다. 향후 연구에서는 검색 결정을 질의의 난이도와 연결하거나, 강화학습을 사용하여 검색이 필요한지를 판단하도록 개선할 계획이다.

또한 사용할 수 있는 검색 도구의 종류를 늘리고, 모델이 사용자 입력에 따라 적절한 도구를 직접 선택할 수 있도록 확장할 예정이다. 동시에 모델 자체의 강건성을 높이는 것도 중요하며, 특히 검색 과정에서 오류가 발생하더라도 안정적으로 대응할 수 있도록 개선할 필요가 있다.

Reference

댓글

댓글 쓰기