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

이미지
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 서론 음성 대화 시스템...

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...

Audio-024, OmniFlatten: An End-to-end GPT Model for Seamless Voice Conversation, ACL 2025

이미지
◼ Comment 텍스트 백본에 듀플렉스 모델을 학습하는 건데 3가지 스텝이 있음 modality alignment,  half-duplex dialogue learning,  full-duplex dialogue learning. 기본적으로 여기서는 토큰을 concat해서 넣는 방식임 한 timestep에서 텍스트와 오디오 토큰이 concat해서 들어감 (discrete token 사용) 근데 이게 같은 timestep을 표기하는거겠지? 즉 positional embedding이나 그런기법이 있나? => 이런건 여기서는 없는듯. 즉 그냥 LLM의 step과 똑같지만, 이해를 위해서 그림에서는 chunk를 묶어서 표현 modality alignment ASR Sample: [ASR][SOS]S_seq[EOS][SOT]T_seq[EOT] TTS Sample: [TTS][SOT]T_seq[EOT][SOS]S_seq[EOS] ASR, TTS 샘플로 모델을 SFT 한다.  내 생각은 pretraining 해도 될거 같은데 SFT로 학습하는게 ? 긴함 SFT이기 때문에 입력쪽에는 masking 걸려서 loss가 안흐르는듯 오픈소스 데이터로 Aishell-3, LibriTTS, TED-LIUM, VoxPopuli, Librispeech, MLS로 30% 사용하고 자체 데이터 70% 사용한다고함 half-duplex dialogue learning [User speech tokens] [User text tokens] [Assistant text tokens] [Assistant speech tokens] 이런식으로 데이터 넣어서 학습한다는 것임 기존의 대화 데이터에서 ASR, TTS을 활용해서 이런 쌍을 만드는듯 (데이터 증강) 이 데이터로 학습하면 알아서 ASR, text-to-text, TTS을 동시에 배우는 것임 이게 그림3로 학습하기전 중간 단계의 pretraining 개념이라 보면 되는거 같음 full-duplex stage1 위에...