AI Information

Abstract 본 논문에서는 영어 및 한국어 음성의 이해, 질의응답, 생성을 위한 최고 수준의 90억 파라미터 음성 언어 모델(Speech Language Model; SpeechLM)인 Raon-Speech 와, 자연스러운 실시간 대화를 지원하는 고성능 풀듀플렉스 확장 모델 Raon-SpeechChat 을 제안한다. Raon-Speech는 사전학습된 대규모 언어 모델(LLM)의 강력한 텍스트 능력을 유지하면서, 음성을 이해하고 생성할 수 있는 SpeechLM으로 성공적으로 확장한다. Raon-Speech는 엄선된 영어 및 한국어 음성·텍스트 데이터 138만 시간으로 학습되며, 다음의 세 단계 학습 과정을 거친다. (1) 음성 모듈 정렬, (2) 지식 증류를 활용한 엔드투엔드 SpeechLM 사전학습, (3) 다중 과업 선호도 최적화 기반 후속 학습. 영어 및 한국어 음성과 텍스트를 포함하는 42개 벤치마크에서, Raon-Speech는 Qwen2.5-Omni와 Fun-Audio-Chat을 비롯한 최근의 유사 규모 오디오 파운데이션 모델 8개와 비교했을 때 음성 중심 과업에서 가장 강력한 종합 성능을 보였으며, 동시에 우수한 텍스트 질의응답 성능을 유지하였다. 이를 기반으로 한 Raon-SpeechChat은 시간 정렬된 실제 및 합성 대화 데이터 11만 9천 시간을 이용한 지속 학습을 통해 자연스러운 풀듀플렉스 대화를 지원한다. 학습은 다음의 상호보완적인 세 단계로 구성된다. (1) 인과적 인코더 적응, (2) 풀듀플렉스 사전학습, (3) 음성 및 역할 제어를 위한 풀듀플렉스 미세조정. 여러 풀듀플렉스 벤치마크에서 Raon-SpeechChat은 FDB v1.0이 평가하는 턴테이킹 및 사용자 끼어들기에 민감한 행동에서 가장 뚜렷한 강점을 보였으며, 더 광범위한 풀듀플렉스 평가에서도 경쟁력 있는 성능을 유지하였다. 저자들은 모든 모델 체크포인트, 학습 및 추론 파이프라인, 그리고 인터랙티브 데모를 오픈소스로 공개한다. 1. 서론 음성은 인간의 인지에서 중심적인 역...

◼ Comment 이 논문도 방법은 MoshiRAG랑 비슷한데, 먼저 나온 논문이다. 일단 학습 데이터는 어떻게 만들었는지 자세히는 안 써있지만 일반 QA(MMLU-pro, GSM8K, HSSBench) 를 기반으로 대화 데이터를 합성하고 여기서 중간중간 llm 결과 (simulator로 부름)를 받아온 데이터를 만들었음 모델 학습 유저 중간 중간 입력에 대해 만든 llm 백그라운드 모델 결과를 그냥 embedding 단에서 더해서 학습하게 함 단점 백그라운드 결과의 각 토큰을 그대로 쓰다보니 moshirag가 언급한 컨텍스트가 길어지는 문제가 해결되지 않음 그리고 trigger이 없고, reflector 또한 없기 때문에, 그냥 첫 응답시 그냥 과거 정보로 추출한 백그라운드 결과를 사용함 그러다가 새로운 백그라운드 결과가 들어오면 그걸 처음부터 다시 사용 이런식이다 보니 중복된 결과가 많이 들어올거 같은 문제가 들음 음성모델 응답또한 실제로 제대로 나오는지 의문? 그냥 정답 자체는 계속 정보가 들어오니 언젠간 나올거 같긴한데, 자연스러운 대화가 아닐거 같음 ABSTRACT 실시간 음성-대-음성(Speech-to-Speech, S2S) 모델은 자연스럽고 지연 시간이 짧은 대화 응답을 생성하는 데 뛰어나지만, 깊이 있는 지식과 의미적 이해가 부족한 경우가 많다. 반면 자동 음성 인식, 텍스트 기반 대규모 언어 모델(LLM), 그리고 텍스트-대-음성 합성을 결합한 캐스케이드 시스템은 더 우수한 지식 표현 능력을 제공하지만, 높은 지연 시간으로 인해 자연스러운 상호작용의 흐름을 방해한다. 본 논문에서는 이러한 두 패러다임 사이의 격차를 해소하기 위한 새로운 하이브리드 아키텍처를 제안한다. 제안하는 프레임워크는 즉각적인 응답성을 확보하기 위해 사용자의 음성을 S2S Transformer로 처리하는 동시에, 해당 질의를 강력한 백엔드 LLM으로 전달한다. 이후 LLM이 생성한 텍스트 응답을 실시간으로 주입하여 S2S 모델의 음성 생성을 유도한다. 이를 통해 캐스케이드 ...

◼ 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개 문서정도까지만(...

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