AI Information

◼ 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 벤치마크로 ...

 이 논문은 “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 필요성 ...

 이 논문은 Toolformer: Language Models Can Teach Themselves to Use Tools (Schick et al., 2023)입니다. 지금 흔히 말하는 LLM + Tool Use / Agent / Function Calling 계열의 대표적인 초기 논문 중 하나입니다. 핵심 아이디어는 의외로 단순합니다. LLM이 언제 도구를 호출해야 하는지 사람이 라벨링하지 말고, “그 도구의 결과를 받았을 때 다음 토큰 예측이 더 쉬워지는가?”를 이용해서 스스로 학습 데이터를 만들자. 이게 논문의 거의 전부라고 보면 됩니다. 1. 무슨 문제를 풀려고 하나? LLM은 많은 것을 알지만 분명한 약점이 있습니다. 예를 들어: 정확한 계산 최신 정보 특정 factual knowledge 날짜 계산 번역 검색 같은 문제입니다. 예를 들어 Out of 1400 participants, 400 passed the test. This is ___%. 라고 하면 LM 내부에서 계산하게 하지 말고, Out of 1400 participants, 400 [Calculator(400 / 1400) → 0.29] 29% passed the test. 처럼 calculator를 호출하면 됩니다. 문제는 여기서 생깁니다. 언제 calculator를 불러야 하지? 그리고 Calculator? Search? QA? Translation? 중 어떤 tool을 불러야 하지? 또 tool을 호출한다면 무슨 query를 보내야 하지? Toolformer는 이것들을 전부 LM 자체에게 학습시키려고 합니다. 2. Toolformer가 사용하는 Tool 논문에서는 5개를 사용합니다. Tool 역할 Question Answering factual question에 답함 Wikipedia Search Wikipedia 검색 Calculator 계산 Calendar 현재 날짜 Machine Translation 다른 언어 → 영어 번역 예를 들어 모델이 The name der...

LLM은 답하기 전에 “이 문제를 내가 아는지” 알 수 있을까? 이번 글에서는 Query-Level Uncertainty in Large Language Models 논문을 정리한다. 이 논문의 핵심 질문은 아주 단순하다. LLM이 실제 답을 생성하기 전에, 이 질문을 자신이 맞힐 수 있는지 판단할 수 있을까? 기존의 LLM uncertainty 연구는 대부분 답변을 생성한 뒤 그 답이 얼마나 신뢰할 만한지를 측정했다. 반면 이 논문은 질문만 보고 미리 uncertainty를 추정 하는 방법을 제안한다. 1. 기존 uncertainty estimation과 무엇이 다른가? 기존 방식은 보통 질문 x 에 대해 답변 y 를 생성한 다음 uncertainty를 계산한다. U(x, y) 예를 들어 Perplexity, Semantic Entropy, P(True) 같은 방법들은 기본적으로 생성된 답변 정보를 사용한다. 그런데 이러한 방식에는 비용 문제가 있다. 특히 Semantic Entropy처럼 여러 개의 답변을 샘플링해야 하는 방법은 하나의 질문에 대해 여러 번 generation을 수행해야 한다. Reasoning task처럼 답변 길이가 긴 경우에는 비용이 더 커진다. 이 논문은 이를 다음과 같이 바꾼다. U(x) 즉 답변을 생성하지 않고 질문 자체만 보고 모델이 이 문제를 풀 수 있을지 추정 한다. 저자들은 이를 Query-Level Uncertainty 라고 부른다. 2. “모델이 이 문제를 안다”는 것은 무엇인가? 먼저 ground truth가 필요하다. 논문에서는 질문을 모델에게 실제로 입력한 뒤 greedy decoding으로 답을 생성한다. 모델이 정답을 맞히면: Answerable 틀리면: Non-answerable 이라고 정의한다. 즉 이 논문에서 말하는 knowledge는 철학적인 의미의 “모델이 지식을 가지고 ...

논문 한눈에 보기 제목: Towards Fully Exploiting LLM Internal States to Enhance Knowledge Boundary Perception ACL 2025 Long Paper 이 논문은 다음 질문을 다룹니다. LLM이 답변을 생성하기 전부터, 자신이 그 질문에 답할 수 있는지를 hidden state만으로 판단할 수 있는가? 결론부터 말하면: 질문의 마지막 토큰 hidden state에 작은 분류기를 붙이면, 답변을 생성하기 전에도 모델의 정답 가능성을 상당히 잘 예측할 수 있다. 다만 답변 생성 후 hidden state를 사용하면 조금 더 정확하다. 그리고 모델의 과도한 자신감을 줄이기 위해, 질문을 여러 형태로 바꿔 물었을 때 confidence가 일관적인지를 검사하는 C³ 라는 보정 방법도 제안합니다. 1. 이 논문에서 말하는 Knowledge Boundary Knowledge Boundary는 쉽게 말해 다음 두 영역의 경계입니다. 모델이 실제로 알고 있어서 정답을 낼 수 있는 질문 모델이 알지 못해서 오답을 낼 가능성이 높은 질문 좋은 모델이라면: 실제 능력 모델의 판단 바람직한 행동 정답 가능 “알고 있다” 답변 정답 불가능 “모른다” 거절·검색·도구 호출 정답 불가능 “알고 있다” 과신, hallucination 정답 가능 “모른다” 지나친 보수성 논문에서는 모델 confidence와 실제 정답 여부가 일치하는 비율을 Alignment 라고 부릅니다. 또 두 종류의 오류를 구분합니다. Overconfidence: 틀리면서 안다고 판단 Conservativeness: 맞힐 수 있으면서 모른다고 판단 이 중 검색 필요성 판단에서는 특히 Overconfidence 가 중요합니다. 틀릴 질문인데 모델이 자신 있다고 판단하면 검색하지 않고 hallucination을 만들기 때문입니다. 2. 핵심 아이디어 기존 방법은 보통 모델이 답변을 생성한 다음, 답변 token의 hidden state를 보고 그 답변이 맞...

LLM은 언제 검색해야 할까? KBM: Knowledge Boundary를 활용한 Adaptive Retrieval 대규모 언어 모델에 외부 검색을 결합하는 RAG는 최신 정보와 희귀 지식을 보완하는 대표적인 방법이다. 하지만 모든 질문에 검색을 수행하는 방식은 비효율적이다. 모델이 이미 알고 있는 질문에도 검색을 붙이면 불필요한 비용과 지연이 발생하고, 검색 결과에 포함된 노이즈 때문에 오히려 답변 품질이 낮아질 수도 있다. EMNLP 2025 Findings에 발표된 “KBM: Delineating Knowledge Boundary for Adaptive Retrieval in Large Language Models” 는 이러한 문제를 해결하기 위해, 언어 모델이 알고 있는 질문과 모르는 질문의 경계를 학습하는 Knowledge Boundary Model , 즉 KBM을 제안한다. 논문의 핵심 질문은 다음과 같다. 모델이 스스로 답할 수 있는 질문과 외부 검색이 필요한 질문을 구분할 수 있는가? 모든 질문에 RAG가 필요한 것은 아니다 일반적인 RAG 시스템은 사용자 질문을 받으면 우선 검색을 수행한다. 질문 ↓ 문서 검색 ↓ 검색 결과 + 질문 ↓ LLM 답변 이 방식은 모델의 내부 지식이 부족한 경우 효과적이지만, 이미 답을 알고 있는 질문에도 동일한 검색 과정이 적용된다. 논문에서는 검색이 답변에 미치는 영향을 세 가지로 구분한다. Beneficial 검색을 사용한 뒤 답변 성능이 향상되는 경우다. 모델이 원래 몰랐던 사실을 외부 문서에서 얻은 상황이 여기에 해당한다. Neutral 검색을 사용해도 성능이 거의 변하지 않는 경우다. 모델이 이미 알고 있던 정보를 검색을 통해 다시 제공받는 상황이다. Harmful 검색을 사용한 뒤 오히려 성능이 떨어지는 경우다. 검색 결과가 부정확하거나 질문과 관련이 적으면, 모델이 내부적으로 알고 있던 올바른 지식까지 방해받을 수 있다. 따라서 검색은 항상 성능을 높이는 것이 아니다. 이상적인 시스템은 질...

LLM은 언제 검색해야 할까? ADAPT-LLM: <RET> 토큰을 이용한 선택적 정보 검색 대규모 언어모델을 이용해 질문에 답하는 방법은 크게 두 가지로 나눌 수 있다. 첫 번째는 모델이 학습 과정에서 습득한 내부 지식만으로 답하는 Closed-book QA 방식이다. 별도의 검색 과정이 없으므로 빠르고 간단하지만, 모델이 알지 못하거나 오래된 정보에는 제대로 답하기 어렵다. 두 번째는 질문과 관련된 문서를 검색한 뒤, 검색 결과를 모델에 제공하는 Open-book QA 또는 RAG 방식이다. 외부 정보를 활용할 수 있다는 장점이 있지만 검색 비용과 지연이 발생하며, 검색된 문서의 품질이 낮으면 오히려 답변을 방해할 수도 있다. 이 논문은 두 방법 중 하나를 항상 고정해서 사용하는 대신, 질문마다 검색이 필요한지 모델이 직접 결정하도록 하는 방법 을 제안한다. 제안된 모델의 이름은 ADAPT-LLM 이다. 핵심 아이디어 ADAPT-LLM은 질문을 받으면 다음 두 행동 중 하나를 선택한다. 1. 모델이 답을 안다고 판단하면 바로 답변한다. 2. 외부 정보가 필요하다고 판단하면 <RET> 토큰을 출력한다. 예를 들어 모델이 질문에 답할 수 있다면 다음과 같이 응답한다. Question: Who wrote Hamlet? Answer: William Shakespeare 반면 모델이 추가 정보가 필요하다고 판단하면 답변 대신 특수 토큰을 생성한다. Question: ... Answer: <RET> <RET> 은 retrieval이 필요하다는 뜻이다. 백엔드는 이 토큰을 감지하면 정보검색 시스템을 실행하고, 검색된 문서를 질문과 함께 모델에 다시 입력한다. 전체 추론 과정은 다음과 같다. 질문 ↓ ADAPT-LLM ├─ 직접 답변 │ └─ <RET> ↓ 문서 검색 ↓ 질문 + 검색 문서 ↓ ADAPT-LLM 재호출 ...