AI Information

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

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  

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

◼ 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는 철학적인 의미의 “모델이 지식을 가지고 ...