Audio-030, MiniCPM-o 4.5: Towards Real-Time Full-Duplex Omni-Modal Interaction, Preprint 2026

이미지
Abstract 최근 멀티모달 대규모 언어 모델(MLLM)의 발전으로 AI의 능력은 정적인 오프라인 데이터 처리에서 실시간 스트리밍 상호작용으로 확장되었지만, 여전히 인간 수준의 멀티모달 상호작용과는 큰 격차가 존재한다. 핵심적인 병목은 더 이상 모달리티의 범위나 지연 시간 자체가 아니라, 상호작용 패러다임 그 자체에 있다. 첫째, 지각과 응답은 여전히 번갈아 수행되는 단계로 분리되어 있어, 모델이 생성 중 새롭게 들어오는 입력을 반영하여 적시에 조정하는 것을 방해한다. 둘째, 현재 대부분의 모델은 여전히 반응적으로 동작하며, 변화하는 멀티모달 환경에서 능동적으로 행동하기보다는 사용자의 명시적인 요청에만 응답한다. 우리는 인간과 유사한 멀티모달 상호작용을 향한 최신 시도인 MiniCPM-o 4.5를 제시하며, 이는 실시간 full-duplex omni-modal interaction을 통해 이러한 격차를 완화한다. MiniCPM-o 4.5는 실시간으로 동시에 보고, 듣고, 말할 수 있으며, 실시간 장면에 대한 지속적인 이해를 바탕으로 리마인더를 제공하거나 코멘트를 하는 등의 능동적인 행동도 수행한다. MiniCPM-o 4.5의 핵심 기술은 Omni-Flow로, omni-modal 입력과 출력을 하나의 공유된 시간축을 따라 정렬하는 통합 스트리밍 프레임워크이다. 이러한 구성은 기존의 turn-based 상호작용을 full-duplex의 시간 정렬된 프로세스로 변환하여, 지각과 응답을 동시에 수행할 수 있게 하고 동일한 프레임워크 내에서 능동적 행동이 나타날 수 있도록 한다. 총 9B 파라미터를 갖는 MiniCPM-o 4.5는 vision-language 능력에서 Gemini 2.5 Flash에 근접하며, 해당 규모의 오픈소스 모델 중 state-of-the-art 성능을 달성한다. 또한 omni-modal understanding에서 Qwen3-Omni-30B-A3B를 능가하고, 훨씬 높은 계산 효율성과 함께 더 나은 speech generation 성능을 제공...

NL-377, LLM Agents Already Know When to Call Tools - Even Without Reasoning, Preprint 2026

https://chatgpt.com/share/6a9532c4-9bfc-83ee-b862-74d3ccc63dba Reference https://arxiv.org/pdf/2605.09252

NL-366, SMART: Self-Aware Agent for Tool Overuse Mitigation, Findings of ACL 2025

https://chatgpt.com/share/6a8fd187-4b18-83ee-8bd6-246bf9221440 Reference https://arxiv.org/pdf/2502.11435

NL-366, ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs, ICLR 2024

https://chatgpt.com/share/6a8e92f5-4d98-83ee-bc7e-fa26870b2656 [User] 친구 생일 선물을 고르고 싶어. 친구가 헤일리 스타인펠드를 좋아해. 최근 작품을 참고해서 관련 굿즈를 추천해줘. [Available APIs] - actor_info(name) - movie_details(title) - merchandise_search(keyword) (인퍼런스시 top-5 api retriver에서 찾아오는 개념) [Assistant] Thought: 먼저 배우의 최근 작품을 알아봐야겠다. API: actor_info Args: {"name": "Hailee Steinfeld"} [API Observation] {"recent_movies": ["Spider-Man: Across the Spider-Verse", ...]} [Assistant] Thought: 최근 작품의 캐릭터 정보를 확인해야겠다. API: movie_details Args: {"title": "Spider-Man: Across the Spider-Verse"} [API Observation] {"role": "Gwen Stacy / Spider-Woman", ...} Reference https://arxiv.org/pdf/2307.16789  

NL-365, ToolkenGPT: Augmenting Frozen Language Models with Massive Tools via Tool Embeddings, NeurIPS 2023

https://chatgpt.com/share/6a8e8886-9598-83ee-9162-83a2599dac94 Reference https://arxiv.org/pdf/2305.11554

Audio-029, PersonaPlex: Voice and Role Control for Full Duplex Conversational Speech Models, ICASSP 2026

이미지
◼ Comment 연구의 시작은 Full-duplex 모델의 어시스턴트 음성이 항상 고정되어 있기 때문에, 원하는 화자의 목소리를 입히고 싶어하는 듯 근데 생성된 오디오 토큰에 persona TTS을 입히면 안되나? 방법론은 그냥 프롬프트 넣는다는 것인데, 학습없이 사용하면 이게 잘 안되나봄? 그래서 voice prompt / text prompt 을 넣고 이것에 맞게 모델이 음성을 생성하도록 학습했다는 것 이때 user audio 채널은 440Hz 사인파를 넣었다고 함. (zero 값 대신 사용하는 듯) 따라서 학습 데이터가 필요하고 이는 합성 데이터로 만듬 기본적으로 대화 스크립트는 Qwen-3-32B, GPT-OSS-120B을 사용해서 만듬 서비스 도메인을 샘플링하고, 해당 도메인에서 시나리오 선택하고 설명을 줘서 만듬 예) 레스토랑에서 환불하는 시나리오 QA을 만들기 위한 텍스트 LLM prompt는  “당신은 현명하고 친근한 선생님입니다. 질문에 답하거나 조언을 제공할 때 명확하고 흥미롭게 설명하세요.” 로 고정함 Customer service을 만들기 위한 텍스트 LLM prompt는 시나리오에 맞는 프롬프트가 있음 TTS는 VoxCeleb, Libriheavy, LibriTTS, CommonAccent, Fisher 등을 이용해서 화자별 음성을 가져옴 (single-speaker voice sample) 대화 음성을 위해서는 Multi-speaker TTS (Dia)을 사용했다고 하는데, 이 모델은 speaker A, B 레퍼런스 보이스를 받아서 대화를 자연스럽게 만들 수 있다고 함 질의 응답 시나리오 오디오는 chatterbox TTS을 사용했다고 하는데, 이거는 single-speaker TTS로 사용한듯 학습 데이터는 105,410 대화, 1,840 시간의 고객 서비스 대화와 39,322개의 대화로 구성된 410시간의 일반적인 QA 이러한 모델을 평가하는 벤치마크가 없음 기존에는 FDB는 그냥 full-duplex 벤치마크로 ...

NL-364, Adaptive Tool Use in Large Language Models with Meta-Cognition Trigger, ACL 2025

 이 논문은 “LLM이 언제 외부 tool/RAG를 써야 하는가?” 를 모델의 내부 hidden representation을 이용해 판단하자 는 논문입니다. 논문 제목은 Adaptive Tool Use in Large Language Models with Meta-Cognition Trigger , ACL 2025 Long Paper이고, 제안 방법은 MeCo (Meta-Cognition-oriented trigger) 입니다. 핵심은 모델에게 단순히 "도구가 필요합니까? Yes/No" 라고 물어본 결과를 그대로 믿지 않고, 그 Yes/No를 생성할 때의 hidden state가 정말 확신에 찬 판단인지 다시 검사해서 tool-use 결정을 수정한다 는 것입니다. 1. 문제 설정 기존 tool-use/RAG 시스템에서는 보통 이런 식으로 합니다. Query ↓ LLM: tool 필요한가? ↓ Yes → Tool/RAG No → 자체 답변 문제는 LLM의 Yes/No 판단 자체가 틀릴 수 있다는 것입니다. 예를 들어 모델이 실제로는 모르는 질문인데 Do I need a search engine? → No 라고 할 수도 있습니다. 반대로 모델 내부 지식으로 충분히 풀 수 있는데 → Yes 라고 해서 쓸데없이 검색할 수도 있습니다. 불필요한 tool call은 latency와 tool/API 오류 가능성을 증가시키기 때문에 저자들은 “모델 자신의 tool-use 판단이 믿을 만한지를 hidden representation에서 알아내자” 고 제안합니다. 2. MeCo의 핵심 아이디어 전체 구조는 아래처럼 생각하면 됩니다. Query ↓ LLM ↓ "Yes, tool이 필요합니다" ↓ Yes token의 hidden state ↓ Meta-cognition probe ↓ meta-cognition score v ↓ 이 Yes 판단이 믿을 만한가? ↓ Yes 유지 or No로 뒤집기 즉 Tool 필요성 ...