<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Llm on 노준탁 — AI 노트</title>
    <link>https://ai.klavierhye.cc/ko/tags/llm/</link>
    <description>Recent content in Llm on 노준탁 — AI 노트</description>
    <generator>Hugo -- 0.147.7</generator>
    <language>ko</language>
    <lastBuildDate>Tue, 22 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://ai.klavierhye.cc/ko/tags/llm/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Guardrail이 너무 많으면 큰 모델이 더 나빠진다: Orchestration 13,528줄을 지운 이야기</title>
      <link>https://ai.klavierhye.cc/ko/posts/too-many-guardrails/</link>
      <pubDate>Tue, 22 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://ai.klavierhye.cc/ko/posts/too-many-guardrails/</guid>
      <description>&lt;p&gt;&lt;em&gt;이 글은 한국어 전화 Voice Agent 현장 노트 7부작 중 &lt;strong&gt;7부&lt;/strong&gt;이자 마지막 편이다. 내가 리드했던 프로젝트 — 공공 서비스 전화 상담용 실시간 한국어 voice agent(STT → LLM → TTS) — 를 만들면서 겪은 일을 정리해 왔다. STT 평가 → Rule vs 모델 → Latency → 조용한 실패 → Guardrail → 평가 지표 → &lt;strong&gt;단순화&lt;/strong&gt;. &lt;a href=&#34;https://ai.klavierhye.cc/ko/posts/how-guardrails-pile-up/&#34;&gt;5부&lt;/a&gt;에서는 dialog layer의 규칙이 어떻게 쌓였는지를, &lt;a href=&#34;https://ai.klavierhye.cc/ko/posts/llm-eval-metric-chose-architecture/&#34;&gt;6부&lt;/a&gt;에서는 평가가 왜 계속 그 규칙들에 점수를 몰아줬는지를 다뤘다. 이번 글은 그 규칙들을 걷어낸 이야기다.&lt;/em&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>평가 지표가 아키텍처를 골랐다: 정답지 기반 QA가 Guardrail에 점수를 몰아준 방식</title>
      <link>https://ai.klavierhye.cc/ko/posts/llm-eval-metric-chose-architecture/</link>
      <pubDate>Tue, 01 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://ai.klavierhye.cc/ko/posts/llm-eval-metric-chose-architecture/</guid>
      <description>&lt;p&gt;&lt;em&gt;이 글은 한국어 전화 Voice Agent 현장 노트 7부작 중 &lt;strong&gt;6부&lt;/strong&gt;다. 내가 리드했던 프로젝트 — 공공 서비스 전화 상담용 실시간 한국어 voice agent(STT → LLM → TTS) — 를 만들면서 겪은 일을 정리한다. STT 평가 → Rule vs 모델 → Latency → 조용한 실패 → Guardrail → &lt;strong&gt;평가 지표&lt;/strong&gt; → 단순화. &lt;a href=&#34;https://ai.klavierhye.cc/ko/posts/how-guardrails-pile-up/&#34;&gt;5부&lt;/a&gt;에서는 실패한 QA row 하나마다 dialog layer에 규칙이 하나씩 쌓인 과정을 다뤘다. 이번 글은 그 규칙들에 계속 점수를 몰아준 평가 이야기다.&lt;/em&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>실패한 QA 한 줄마다 규칙 하나: LLM 대화 시스템에 Guardrail이 쌓이는 과정</title>
      <link>https://ai.klavierhye.cc/ko/posts/how-guardrails-pile-up/</link>
      <pubDate>Tue, 11 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://ai.klavierhye.cc/ko/posts/how-guardrails-pile-up/</guid>
      <description>&lt;p&gt;&lt;em&gt;이 글은 한국어 전화 Voice Agent 현장 노트 7부작 중 &lt;strong&gt;5부&lt;/strong&gt;다. 내가 리드했던 프로젝트 — 공공 서비스 전화 상담용 실시간 한국어 voice agent(STT → LLM → TTS) — 를 만들면서 겪은 일을 정리한다. &lt;a href=&#34;https://ai.klavierhye.cc/ko/posts/stt-eval-real-calls/&#34;&gt;1부&lt;/a&gt;는 STT 평가가 나를 속인 방식, &lt;a href=&#34;https://ai.klavierhye.cc/ko/posts/dont-let-the-llm-read-numbers/&#34;&gt;2부&lt;/a&gt;는 rule이 모델을 이기는 곳, &lt;a href=&#34;https://ai.klavierhye.cc/ko/posts/bigger-model-faster-voice-latency/&#34;&gt;3부&lt;/a&gt;는 latency, &lt;a href=&#34;https://ai.klavierhye.cc/ko/posts/silent-failures-voice-ai/&#34;&gt;4부&lt;/a&gt;는 exception 한 번 없이 조용히 실패한 것들을 다뤘다. 이번 글은 dialog layer 이야기다. 그 안의 규칙이 실패한 QA row 하나마다 하나씩 불어난 과정을 따라간다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;3월 25일 하루에만 dialog service에 commit을 32개 했다. 첫 commit이 00:56, 마지막이 16:59였고, 그중 26개의 제목이 &amp;ldquo;Fix&amp;quot;로 시작한다. 11:00에는 한 요청 유형의 첫 안내 멘트를 바꿨다. 정작 물어야 할 질문 앞에 주의 사항이 세 문장이나 붙어 있던 것을 짧고 자연스러운 질문 하나로 줄였다. 그리고 11:07에 되돌렸다. Commit message에는 &amp;ldquo;original detailed greeting for QA compatibility&amp;quot;로 돌아간다고 적혀 있다. 전화로 들으면 짧은 쪽이 분명 나았다. 그런데도 진 이유는 하나, 정답지가 옛 멘트를 기준으로 쓰여 있었기 때문이다. (이 commit message를 다시 읽는 건 꽤 민망한 일이었다.)&lt;/p&gt;</description>
    </item>
    <item>
      <title>아무것도 죽지 않았다: 프로덕션 음성 AI 스택의 조용한 실패들</title>
      <link>https://ai.klavierhye.cc/ko/posts/silent-failures-voice-ai/</link>
      <pubDate>Tue, 21 Jul 2026 00:00:00 +0000</pubDate>
      <guid>https://ai.klavierhye.cc/ko/posts/silent-failures-voice-ai/</guid>
      <description>&lt;p&gt;&lt;em&gt;이 글은 한국어 전화 Voice Agent 현장 노트 7부작 중 &lt;strong&gt;4부&lt;/strong&gt;다. 내가 리드했던 프로젝트 — 공공 서비스 전화 상담용 실시간 한국어 voice agent(STT → LLM → TTS) — 를 만들면서 겪은 일을 정리한다. &lt;a href=&#34;https://ai.klavierhye.cc/ko/posts/stt-eval-real-calls/&#34;&gt;1부&lt;/a&gt;는 STT 평가가 나를 어떻게 속였는지, &lt;a href=&#34;https://ai.klavierhye.cc/ko/posts/dont-let-the-llm-read-numbers/&#34;&gt;2부&lt;/a&gt;는 rule이 모델을 이기는 곳, &lt;a href=&#34;https://ai.klavierhye.cc/ko/posts/bigger-model-faster-voice-latency/&#34;&gt;3부&lt;/a&gt;는 latency를 다뤘다. 이번에는 exception 한 번 던지지 않고 조용히 실패한 것들 이야기다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;웹 앱이 망가지면 누군가는 500 페이지라도 본다. Voice agent가 망가지면 전화를 건 사람은 아무것도 듣지 못한다. 침묵에 대고 &amp;ldquo;여보세요?&amp;ldquo;를 두어 번 하다가, 몇 초 기다리고, 끊는다. Stack trace는 caller에게 닿지 않고, 많은 경우 나한테도 닿지 않는다.&lt;/p&gt;</description>
    </item>
    <item>
      <title>LLM에게 숫자 읽기를 맡기지 마라: Voice Pipeline에서 Rule이 모델을 이기는 곳</title>
      <link>https://ai.klavierhye.cc/ko/posts/dont-let-the-llm-read-numbers/</link>
      <pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://ai.klavierhye.cc/ko/posts/dont-let-the-llm-read-numbers/</guid>
      <description>&lt;p&gt;&lt;em&gt;이 글은 한국어 전화 Voice Agent 현장 노트 7부작 중 &lt;strong&gt;2부&lt;/strong&gt;다. 내가 리드했던 프로젝트 — 공공 서비스 전화 상담용 실시간 한국어 voice agent(STT → LLM → TTS) — 를 만들면서 겪은 일을 정리한다. &lt;a href=&#34;https://ai.klavierhye.cc/ko/posts/stt-eval-real-calls/&#34;&gt;1부&lt;/a&gt;에서는 STT 평가가 나를 어떻게 속였는지를 다뤘다. 이번에는 LLM을 둘러싼 텍스트 이야기다: 들어오고 나가는 숫자, STT가 &lt;em&gt;거의&lt;/em&gt; 맞게 듣는 이름, 그리고 LLM 호출이 latency를 감수할 만한 자리.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;3월의 어느 금요일 새벽 2시 17분, TTS normalizer 버그 하나를 고쳤다. 27,000원 같은 금액을 &amp;ldquo;이, 칠, 공, 공, 공 원&amp;quot;처럼 한 자리씩 읽어 버리는 버그였다. 그리고 30분쯤 뒤, 한국어 숫자 읽는 rule을 손으로 짜는 건 그만두고 그 일을 LLM에게 넘겼다. 어차피 한국어는 내 regex보다 LLM이 더 잘하니까. (새벽 세 시를 앞둔 사람의 논리였다.)&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
