김신건의 로그 - 위키 / ai

[LLM Eval] HELM: Holistic Evaluation of Language Models

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

HELM (Holistic Evaluation of Language Models) 는 Stanford CRFM (Center for Research on Foundation Models) 이 2022년 발표한 LLM 종합 평가 프레임워크입니다. 기존 벤치마크가 정확도 단일 지표에 편중되는 문제를 지적하며, 여러 시나리오 × 여러 메트릭의 행렬 로 모델을 평가하는 것을 특징으로 합니다.

원 논문 제목이 곧 방법론입니다. Holistic (전체적): 정확도만이 아니라 공정성, 편향, 견고성, 효율성까지 함께 보겠다는 선언.

왜 등장했는가

2022 년 시점 LLM 평가의 문제:

단일 태스크 평가 (MMLU, HellaSwag 등) 는 특정 능력만 봄
정확도 지표만 리포트 (calibration, robustness, bias 등은 무시)
모델 비교가 임의적 (논문마다 다른 태스크 조합, 다른 세팅)
재현성 부족 (프롬프트, 파라미터, few-shot 개수가 논문마다 다름)

HELM 은 이를 표준화된 시나리오 세트 + 표준화된 메트릭 세트 + 표준화된 프롬프트/실행 방식 으로 해결하려 했습니다.

7 가지 핵심 메트릭 축

원 논문의 7 축입니다. 각 시나리오에 대해 이 7 가지를 모두 측정하려 시도합니다.

축	의미	예시
Accuracy	정답 맞추는 능력	정확도, F1, exact match
Calibration	확신도 vs 실제 정확도 일치	ECE (Expected Calibration Error)
Robustness	입력 변형에도 안정적인가	Typo, paraphrase, adversarial 변형 아래 성능
Fairness	인구통계 집단별 성능 균등한가	이름/방언에 따른 성능 편차
Bias	스테레오타입 재생산 여부	성별/인종 등에 대한 연관성 통계
Toxicity	유해 텍스트 생성 여부	Perspective API 등으로 측정
Efficiency	추론 비용, 학습 비용	초당 토큰, 학습에 든 FLOPs

이 7 가지는 완전한 목록이 아니라 출발점 이라고 논문 스스로 명시했습니다. 이후 버전에서 확장되었습니다.

시나리오 (Scenario)

HELM 이 커버하는 태스크 유형입니다. 각 시나리오는 데이터셋 + 태스크 정의 + 평가 방식으로 구성됩니다. 초기 버전 42 개 시나리오를 대략 6 개 카테고리로 나눌 수 있습니다.

Question Answering: NaturalQuestions, NarrativeQA, TruthfulQA, QuAC 등
Information Retrieval: MS MARCO 등
Summarization: CNN/DailyMail, XSum
Sentiment Analysis / Classification: IMDB, RAFT
Toxicity Detection: CivilComments
Reasoning: MMLU, GSM8K, MATH, BBQ (bias)

이후 버전에서 코드 (HumanEval, MBPP), 롱-컨텍스트 (LongBench 계열), 멀티모달 등이 추가되었습니다.

HELM Variants (2023~)

원 HELM (이하 HELM Classic) 은 모든 시나리오 × 모든 메트릭을 시도했기 때문에 매우 비쌉니다 (수천~수만 달러 규모의 API 비용). 이를 축소한 파생 버전들이 나왔습니다.

HELM Lite (2023 말~)

실전에서 자주 쓰이는 시나리오만 10 개 내외 로 축소
MMLU (multiple-choice), GSM8K, MATH, NaturalQuestions, WMT, LegalBench 등
하루~며칠 단위로 리더보드 업데이트
빠른 반복 평가에 적합
https://crfm.stanford.edu/helm/lite/

HELM Instruct

지시 따르기 (instruction following) 평가에 초점
Open-ended generation 을 사람 또는 LLM-as-judge 로 평가
MT-Bench, AlpacaEval 등과 유사한 접근
https://crfm.stanford.edu/helm/instruct/

HELM Safety

안전성 (harmful content, jailbreak 저항성) 중심
유해 요청에 대한 거부, jailbreak 프롬프트 아래 견고성 등

도메인 특화 HELM

MedHELM: 의료 도메인 (2024)
LegalBench 통합
AIR-Bench: 리스크 카테고리별

리더보드는 https://crfm.stanford.edu/helm/ 최상단에서 여러 트랙을 선택할 수 있습니다.

시나리오 × 메트릭 매트릭스

핵심 아이디어를 도식으로 표현하면:

	MMLU	HellaSwag	TruthfulQA	HumanEval	…
Accuracy	✓	✓	✓	pass@1	…
Calibration	✓	✓	✓	-	…
Robustness	✓ (typo)	✓	✓	✓	…
Fairness	✓ (이름 치환)	-	-	-	…
Bias	-	-	✓ (BBQ)	-	…
Toxicity	-	-	-	-	…
Efficiency	tok/s, FLOPs	…	…	…	…

모든 셀이 다 채워지진 않습니다 (해당 메트릭이 그 시나리오에 적용 불가한 경우 존재). HELM 은 어떤 셀이 비어 있는지도 명시적으로 보여주어 평가의 불완전성을 드러냅니다.

리더보드 (2026 기준)

https://crfm.stanford.edu/helm/lite/ 최신 리더보드에서 확인 가능합니다. 상위권에는 GPT-5, Claude Opus 4, Gemini 2.5 계열 등이 위치하며, 오픈 웨이트 (Llama, Qwen, DeepSeek) 도 근접해 있습니다. 정확한 순위는 시점마다 바뀌므로 링크 참조가 정답입니다.

실행 방법 (helm-run)

pip install crfm-helm

# 실행할 conf 파일 정의
cat > run-specs.conf << EOF
[
  {description: "mmlu:subject=philosophy,model=openai/gpt-4o", priority: 1},
  {description: "narrativeqa:model=openai/gpt-4o", priority: 1},
]
EOF

# 실행
helm-run \
  --conf-paths run-specs.conf \
  --suite my-eval \
  --max-eval-instances 100 \
  --num-threads 4

# 결과 요약 통합
helm-summarize --suite my-eval

# 웹 UI 로 결과 확인
helm-server --suite my-eval
# http://localhost:8000

지원 모델 provider: OpenAI, Anthropic, Google, Meta, Microsoft, Cohere, HuggingFace Hub, vLLM, Together, DeepSeek, Mistral 등. 자체 서빙 모델도 LocalModel 로 붙일 수 있습니다.

다른 벤치마크와 비교

벤치마크	초점	장점	단점
HELM	Holistic (다면적)	여러 축 동시 측정, 표준화	실행 비용 큼
MMLU / MMLU-Pro	지식 QA	간단, 널리 인용됨	단일 정답 편중, 오염 우려
BIG-Bench	다양성 극대화	200+ 태스크	태스크 품질 편차 큼
Chatbot Arena	사람 선호도	실사용자 판단, 편향 적음	태스크 세분화 없음, 오랜 축적 필요
AlpacaEval	Instruction following	LLM-as-judge 로 빠름	Judge 편향
MT-Bench	대화 품질	짧고 실용적	소규모 (80 문항)
LM Eval Harness	프레임워크	EleutherAI, 매우 널리 쓰임	표준 축이 아니라 도구
AGIEval	인간 시험 (SAT, LSAT)	실제 인간 기준	지역/언어 편중

HELM 은 벤치마크 그 자체이자 프레임워크입니다. 다른 벤치마크의 결과를 HELM 구조 안에서 재실행할 수 있게 통합해 왔습니다.

한계와 비판

오염 (contamination): MMLU 등 공개 벤치마크가 학습 데이터에 유출되어 점수가 부풀려질 수 있습니다. HELM 자체는 이를 감지하지 못합니다.
비용: 원 HELM Classic 은 GPT-4 급 모델을 완전 실행하려면 수만 달러가 필요합니다.
7 축의 임의성: 안전성/agentic 능력/멀티모달은 원 논문에 없었고 이후 추가되었지만 여전히 커버리지 논쟁.
단일 시드 실행: 확률적 생성이므로 결과가 흔들리며, 여러 시드로 여러 번 실행하는 것이 이상적이지만 비용 문제로 어려움.
자동 평가의 한계: LLM-as-judge 는 편향 (자기 편애, 길이 선호) 이 알려져 있습니다.

참고

관련 [[transfer-learning|Transfer Learning]] 은 HELM 이 평가하는 파운데이션 모델의 근본 기법입니다
관련 [[classification-metrics|분류 모델 지표]] 는 accuracy 축 세부 지표
관련 [[sagemaker-model-monitor|SageMaker Model Monitor]] 는 프로덕션 모니터링, HELM 은 모델 선정 단계
리더보드: https://crfm.stanford.edu/helm/
Paper: Liang et al. 2022, HELM
GitHub: https://github.com/stanford-crfm/helm
관련 커뮤니티: Open LLM Leaderboard, LM Eval Harness, Chatbot Arena

Function Calling / Tool Use: LLM 도구 사용

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

Function Calling (또는 Tool Use) 은 LLM 이 정의된 함수/도구를 호출 인자를 생성 하는 기능. JSON schema 로 함수 시그니처를 알려주면, LLM 이 사용자 질의에 맞는 함수와 인자를 JSON 으로 반환.

OpenAI (2023), Anthropic Claude, Google Gemini, 오픈소스 (Llama 3.1+) 모두 지원.

예시

함수 스펙 정의

{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Get current weather for a city",
        "parameters": {
            "type": "object",
            "properties": {
                "city": { "type": "string" },
                "unit": { "enum": ["C", "F"], "default": "C" }
            },
            "required": ["city"]
        }
    }
}

대화

사용자: “서울 날씨 알려줘”

LLM 응답:

{
    "tool_calls": [{
        "function": "get_weather",
        "arguments": { "city": "Seoul", "unit": "C" }
    }]
}

실행 후 결과 재주입

tool result: {"temp": 22, "condition": "sunny"}

LLM 이 최종 답변 생성: “서울은 현재 22°C 로 맑습니다.”

Agent 프레임워크

Function calling 을 반복적으로 활용:

ReAct: Reasoning + Acting 사이클
LangChain, LlamaIndex: 도구 오케스트레이션
MCP (Model Context Protocol): Anthropic 의 표준 (2024)

함정

오호출: LLM 이 없는 함수를 호출하려 함. 스키마 검증 필수.
인자 hallucination: 필수 필드 누락, enum 아닌 값 반환
무한 루프: 도구 결과가 계속 다음 도구 호출 트리거
토큰 낭비: 도구 스펙 자체가 큰 컨텍스트 소비

참고

관련 [[llm-rag|LLM RAG]]
관련 [[helm-llm-benchmark|HELM]]

LLM RAG: Retrieval-Augmented Generation

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

RAG (Retrieval-Augmented Generation) 는 LLM 생성 전에 외부 지식 베이스에서 관련 문서를 검색 하여 프롬프트에 삽입하는 패턴. 최신 정보, 도메인 지식, 사설 데이터 접근 필요할 때 사용.

왜 필요한가

최신 정보: LLM 학습 컷오프 이후 지식
도메인 데이터: 회사 내부 문서, 개인 지식
hallucination 감소: “출처” 를 명시
비용 절감: 파인튜닝 대신

파이프라인

  질의 → embed → vector search → 상위 K 문서 → prompt 조합 → LLM → 답변

핵심 구성 요소

1. 문서 chunk 화

문서를 청크 (500~~1000 토큰) 로 분할. 겹치는 슬라이딩 윈도우 (100~~200 토큰) 로 문맥 유지.

2. Embedding

각 청크를 벡터로 변환. text-embedding-3-small, bge-large-en, nomic-embed 등.

3. Vector Store

[[redis-vector-search|Redis Vector Search]]
Pinecone, Weaviate, Qdrant, Milvus
pgvector (PostgreSQL 확장)

4. Retrieval

Dense: cosine similarity, HNSW 인덱스
Sparse (BM25): 정확 매칭
Hybrid: 두 점수 결합
Reranker: cross-encoder 로 상위 K 재순위

5. Prompt Composition

Context:
[문서 1 요약]
[문서 2 요약]

Question: {질의}
Answer based on the context above.

최적화 기법

HyDE: 가상 답변 embedding 으로 검색
Multi-query rewriting: 질의 확장
Contextual compression: chunk 내 관련 부분만 추출
Query routing: 질의 종류별 다른 인덱스

평가 지표

Retrieval: recall@k, MRR
Generation: faithfulness (사실성), answer relevance
Ragas 프레임워크

참고

관련 [[redis-vector-search|Redis Vector Search]]
관련 [[function-calling|Function Calling]]
관련 [[helm-llm-benchmark|HELM]]

[Voice AI] Agent 패턴: Supervisor, Handoff, ReAct, HITL

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

복잡한 음성 에이전트 = 여러 sub-agent + 조정 패턴. 단일 LLM 으로 처리하기 어려운 흐름.

[!IMPORTANT] 각 sub-agent 내부는 VAD → STT → LLM → TTS 순차 파이프라인 위에서 동작. 본 페이지의 패턴은 상위 조정 (orchestration) 레이어.

4가지 핵심 패턴

flowchart TB
    Q[Agent Patterns]
    Q --> S[Supervisor]
    Q --> H[Handoff]
    Q --> R[ReAct]
    Q --> HITL[Human-in-the-Loop]

1. Supervisor

flowchart TB
    User --> Sup[Supervisor Agent]
    Sup --> Choose{어느 sub-agent?}
    Choose -->|결제 문의| Pay[Payment Agent]
    Choose -->|환불| Ref[Refund Agent]
    Choose -->|기술 지원| Tech[Tech Agent]
    Pay --> Sup
    Ref --> Sup
    Tech --> Sup
    Sup --> User

class SupervisorAgent:
    """질의 → 적절 sub-agent 라우팅"""

    sub_agents = {
        "payment": PaymentAgent(),
        "refund": RefundAgent(),
        "tech_support": TechAgent(),
    }

    async def handle(self, user_input: str) -> str:
        # LLM 으로 의도 분류
        intent = await self._classify_intent(user_input)
        agent = self.sub_agents[intent]
        return await agent.handle(user_input)

    async def _classify_intent(self, text: str) -> str:
        result = await llm.structured_output(
            schema=IntentSchema,
            messages=[{"role": "user", "content": text}],
        )
        return result.intent

작은 분류 모델 (gpt-4o-mini, Haiku) 가 intent classifier, 세부 agent 가 더 큰 모델.

2. Handoff

sequenceDiagram
    User->>Booking: 예약 문의
    Booking->>Booking: 예약 처리
    Note over Booking: 결제 단계
    Booking->>Payment: HANDOFF (context 전달)
    Payment->>User: "결제 진행하겠습니다"
    User->>Payment: 카드 정보
    Payment->>Payment: 결제 처리
    Payment-->>Booking: HANDOFF BACK
    Booking->>User: "예약 + 결제 완료"

OpenAI Swarm 의 handoff 패턴:

from swarm import Swarm, Agent

booking_agent = Agent(
    name="Booking",
    instructions="식당 예약을 도와줍니다.",
    functions=[lookup_restaurant, check_availability, transfer_to_payment],
)

payment_agent = Agent(
    name="Payment",
    instructions="결제를 처리합니다.",
    functions=[charge_card, transfer_to_booking],
)

def transfer_to_payment():
    return payment_agent

def transfer_to_booking():
    return booking_agent

client = Swarm()
response = client.run(agent=booking_agent, messages=messages)

Function return 으로 agent 교체. 깔끔.

3. ReAct (Reason + Act)

Thought: 사용자가 "내일 오후 회의 잡아줘" 라고 했다.
Action: search_calendar(date="내일")
Observation: 14:00-15:00 비어있음
Thought: 14시에 잡으면 되겠다. 참석자는 누구?
Action: ask_user("참석자는 누구신가요?")
Observation: "민수씨와 영희씨요"
Thought: 그들의 가용성 확인 필요
Action: check_availability(["민수", "영희"], "내일 14:00")
Observation: 모두 OK
Thought: 회의 생성
Action: create_meeting(...)
Observation: 회의 생성됨, ID=m_42
Thought: 사용자에게 알림
Action: respond("내일 오후 2시에 민수씨, 영희씨와 회의 잡았습니다.")

async def react_loop(user_input, max_steps=10):
    messages = [{"role": "user", "content": user_input}]
    for step in range(max_steps):
        response = await llm.chat(messages, tools=tools)

        if response.finish_reason == "stop":
            return response.content   # 최종 답변

        if response.tool_calls:
            for tc in response.tool_calls:
                result = await execute_tool(tc)
                messages.append({"role": "tool", "tool_call_id": tc.id, "content": result})

    raise ReActLoopExceededError()

음성에서는 너무 많은 step = 지연 폭증. max_steps 3-5 권장.

4. Human-in-the-Loop (HITL)

sequenceDiagram
    User->>Agent: "1억 송금"
    Agent->>HITL: critical action approval request
    HITL->>Human[운영자]: 알림 ("승인 필요")
    Human-->>HITL: approve / reject
    HITL-->>Agent: result
    Agent->>User: "송금 완료" 또는 "보안 확인 필요"

@agent.tool
async def transfer_money(amount: int, to: str):
    if amount > 10_000_000:
        approval = await request_human_approval(
            action=f"송금 {amount:,}원 → {to}",
            timeout=30,
        )
        if not approval:
            return "송금이 보류되었습니다. 보안팀 확인 후 처리됩니다."

    await bank_api.transfer(amount, to)
    return f"{amount:,}원이 송금되었습니다."

고위험 작업 (금액 큰 송금, 데이터 삭제, 외부 noti) 에 인간 승인.

패턴 조합

flowchart TB
    User --> Sup[Supervisor]
    Sup -->|일반| Single[Single Agent + ReAct]
    Sup -->|복잡 → 전문| Hand[Handoff Chain]
    Hand --> Risk{고위험?}
    Risk -->|예| HITL[HITL Approval]
    HITL --> Exec[실행]

LangGraph 예시 (다중 agent + state machine)

from langgraph.graph import StateGraph, END

class State(TypedDict):
    user_input: str
    intent: str
    result: str

def classify(state):
    state["intent"] = classify_intent(state["user_input"])
    return state

def payment(state):
    state["result"] = handle_payment(state["user_input"])
    return state

def refund(state):
    state["result"] = handle_refund(state["user_input"])
    return state

graph = StateGraph(State)
graph.add_node("classify", classify)
graph.add_node("payment", payment)
graph.add_node("refund", refund)

graph.set_entry_point("classify")
graph.add_conditional_edges(
    "classify",
    lambda s: s["intent"],
    {"payment": "payment", "refund": "refund", "other": END},
)
graph.add_edge("payment", END)
graph.add_edge("refund", END)

app = graph.compile()

흔한 함정

[!WARNING]

모든 query 에 ReAct = 단순 FAQ 도 3-step. 의도 분류 후 복잡한 것만.

Handoff 후 context 손실 = 사용자가 같은 정보 반복. handoff 시 summary 전달.

너무 많은 sub-agent = supervisor 가 분류 어려움. 5-7개 이내.

HITL 없이 critical action = 사고. 임계 정의 + 자동 승인 vs 인간.

[Voice AI] LLM Serving: vLLM, PagedAttention, continuous batching

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

LLM Serving = 자체 호스팅 LLM 을 낮은 TTFT + 높은 throughput 으로 제공. 음성 에이전트의 LLM 단계 지연 결정.

도구	특징
vLLM	PagedAttention, 표준. 한국에서도 압도적
TGI (Hugging Face)	안정, 옛 표준
SGLang	structured output 강함, 2024+
LMDeploy	InternLM, 중국
TensorRT-LLM	NVIDIA 전용, 최고 성능

PagedAttention

flowchart LR
    Q1[Request 1<br/>'안녕'] --> KV1[KV cache]
    Q2[Request 2<br/>'오늘 날씨'] --> KV2[KV cache]
    KV1 --> Page["Memory Pages (16 tokens 단위)"]
    KV2 --> Page
    Page --> GPU[GPU memory]

기존 (LLaMA, TGI 옛)	PagedAttention (vLLM)
요청 시작 시 최대 길이 만큼 KV cache 예약	Page 단위 동적 할당
짧은 응답도 2K-32K 토큰 메모리	실제 사용 만큼만
GPU 메모리 심한 단편화	< 4% 낭비
Throughput 낮음	2-4x 향상

운영체제의 Virtual Memory + paging 의 LLM inference 적용. 모든 modern serving 의 기본.

Continuous Batching

flowchart TB
    Static["Static batching:<br/>요청 8개 모일 때까지 대기<br/>한 batch 끝날 때까지 다음 안 받음"]
    Cont["Continuous batching:<br/>매 step 마다 batch 재구성<br/>새 요청 즉시 합류, 완료된 거 즉시 빠짐"]
    Static --> Slow[GPU idle 많음, latency 높음]
    Cont --> Fast[GPU 100% 활용, latency 낮음]

step 단위 dynamic batching = vLLM, TGI 등의 2026 표준.

TTFT (Time-to-First-Token) vs TPS

flowchart LR
    Req[Request 도착] -->|"prefill (전체 prompt 처리)"| F1[First token]
    F1 -->|"decode (1 토큰씩)"| T2[Token 2]
    T2 -->|decode| T3[Token 3]
    Note["TTFT = prefill 시간<br/>TPS = decode 속도"]

지표	의미	목표
TTFT	첫 토큰까지	< 200ms (음성)
TPS	초당 토큰	> 50 tok/s
Throughput	동시 요청 처리	GPU 효율

음성 에이전트 = TTFT 가 결정적. sentence aggregator 가 첫 문장 받으면 TTS 시작.

SSE 스트리밍 (Server-Sent Events)

GET /v1/chat/completions
Accept: text/event-stream

data: {"choices": [{"delta": {"content": "안"}}]}\n\n
data: {"choices": [{"delta": {"content": "녕"}}]}\n\n
data: {"choices": [{"delta": {"content": "하세요"}}]}\n\n
data: [DONE]\n\n

from openai import AsyncOpenAI
client = AsyncOpenAI(base_url="http://localhost:8000/v1")

stream = await client.chat.completions.create(
    model="llama-3.1-8b-instruct",
    messages=messages,
    stream=True,
)

async for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        sentence_aggregator.feed(delta)

자세한 SSE 는 [[SSE]] 의 일반.

vLLM 시작

pip install vllm

# OpenAI 호환 server
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3.1-8B-Instruct \
    --max-model-len 8192 \
    --gpu-memory-utilization 0.9 \
    --enable-chunked-prefill \
    --enable-prefix-caching \
    --port 8000

옵션	의미
`--max-model-len`	최대 context
`--gpu-memory-utilization`	GPU 메모리 사용률 (0.9 권장)
`--enable-chunked-prefill`	긴 prompt 를 청크로 분할 (latency 균형)
`--enable-prefix-caching`	같은 prefix 의 KV cache 재사용 (system prompt!)
`--tensor-parallel-size N`	N GPU 분산
`--pipeline-parallel-size N`	pipeline 분산

Prefix Caching (system prompt 재사용)

flowchart LR
    Req1["Req 1: SYS+'안녕'"] --> Cache["Prefix Cache (SYS)"]
    Req2["Req 2: SYS+'오늘'"] --> Cache
    Req3["Req 3: SYS+'주문'"] --> Cache
    Note["같은 system prompt 의 KV cache 재사용<br/>→ TTFT 60-90% 단축"]

모든 요청이 같은 긴 system prompt 면 prefix caching 으로 prefill 시간 거의 0. 음성 에이전트의 고정 페르소나 prompt 와 완벽 매칭.

Quantization

종류	메모리	정확도
FP16	100%	기준
FP8 (H100+)	50%	~99%
INT8 (smoothquant)	50%	~98%
INT4 (AWQ, GPTQ)	25%	~95%
INT4 + KV cache FP8	작음	~93%

# AWQ 4-bit 모델
python -m vllm.entrypoints.openai.api_server \
    --model TheBloke/Llama-3.1-8B-Instruct-AWQ \
    --quantization awq

자세한 quantization 은 [[quantization]] 참고.

모델 크기 vs 음성 적합성

모델	한국어	TTFT (8B GPU)	적합
Llama-3.1 8B Instruct	보통	150ms	일반
Llama-3.1 70B AWQ	우수	400ms	복잡 task
Qwen2.5 7B Instruct	우수	130ms	한국어 강함
EXAONE 3 7.8B	최우수 (한국어)	150ms	한국어 voice agent
Phi-3.5 mini (3.8B)	보통	60ms	edge, latency critical
GPT-4o-mini (API)	우수	200ms (API)	일반
Gemini Flash 2.0 (API)	우수	250ms (API)	일반

흔한 함정

[!WARNING]

prefix caching 없이 큰 system prompt = 매 요청 prefill 1초+. 활성화 필수.

streaming 안 함 = 응답 끝나길 기다림. 항상 stream=True.

GPU memory util 너무 높음 (0.95+) = OOM 위험. 0.85-0.9.

연속 batching 없는 옛 서빙 = throughput 1/5. vLLM 으로.

[Voice AI] Pipecat vs LiveKit Agents: 프레임워크 비교

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

2026 시점 voice agent 프레임워크 4가지 선택지:

	Pipecat	LiveKit Agents	Vapi / Retell	자체 구축
카테고리	OSS framework	OSS SFU + framework	Managed	직접
운영	self-host	self-host 또는 LiveKit Cloud	호스팅	self
학습 곡선	중간	중간	낮음	높음
비용	인프라만	인프라만 (LK Cloud 옵션)	비쌈 ($0.13-0.30/min)	인프라
유연성	높음	높음	낮음 (블랙박스)	최고
시간	1-2주	1-2주	1-2일	1-3개월

Pipecat

flowchart LR
    Frame[Frame] --> P1["Input Processor (mic)"]
    P1 --> P2[VAD Processor]
    P2 --> P3[STT Processor]
    P3 --> P4[LLM Processor]
    P4 --> P5[Aggregator]
    P5 --> P6[TTS Processor]
    P6 --> P7["Output Processor (speaker)"]

Frame 이 processor 파이프라인을 흐름. Linux pipe 의 기능적 추상. 컴포넌트 한 줄 교체.

from pipecat.pipeline.pipeline import Pipeline
from pipecat.services.deepgram import DeepgramSTTService
from pipecat.services.openai import OpenAILLMService
from pipecat.services.cartesia import CartesiaTTSService
from pipecat.transports.services.daily import DailyTransport
from pipecat.vad.silero import SileroVADAnalyzer

transport = DailyTransport(room_url, token, "Bot", DailyParams(
    audio_in_enabled=True,
    audio_out_enabled=True,
    vad_analyzer=SileroVADAnalyzer(),
))

pipeline = Pipeline([
    transport.input(),
    DeepgramSTTService(api_key="..."),
    OpenAILLMService(api_key="...", model="gpt-4o-mini"),
    CartesiaTTSService(api_key="...", voice_id="..."),
    transport.output(),
])

runner = PipelineRunner()
await runner.run(PipelineTask(pipeline))

Pipecat 의 Frame 종류

Frame	의미
`AudioRawFrame`	오디오 청크
`TextFrame`	텍스트
`TranscriptionFrame`	전사
`LLMResponseStartFrame` / `EndFrame`	LLM 응답 경계
`TTSStartFrame` / `EndFrame`	TTS 시작/종료
`UserStartedSpeakingFrame`	사용자 발화 시작
`UserStoppedSpeakingFrame`	종료
`InterruptionFrame`	끼어들기

Frame 종류 추가 = 새 processor 추가. 확장이 깔끔.

LiveKit Agents

flowchart TB
    User1["사용자 1"] -->|WebRTC| SFU[LiveKit SFU]
    User2["사용자 2"] -->|WebRTC| SFU
    SFU -->|Room API| Agent["Voice Agent<br/>(headless participant)"]
    Agent --> STT
    Agent --> LLM
    Agent --> TTS

LiveKit SFU 가 WebRTC + room 인프라. Agent 가 room 에 headless participant 로 합류 → 다중 사용자 회의 / 룸 기반 voice agent 자연스러움.

from livekit.agents import VoiceAssistant, AutoSubscribe, JobContext, WorkerOptions, cli
from livekit.agents.llm import ChatContext
from livekit.plugins import openai, silero, deepgram, cartesia

async def entrypoint(ctx: JobContext):
    await ctx.connect(auto_subscribe=AutoSubscribe.AUDIO_ONLY)

    initial_ctx = ChatContext().append(
        role="system",
        text="당신은 친절한 한국어 음성 어시스턴트입니다. 짧게 답하세요."
    )

    assistant = VoiceAssistant(
        vad=silero.VAD.load(),
        stt=deepgram.STT(language="ko"),
        llm=openai.LLM(model="gpt-4o-mini"),
        tts=cartesia.TTS(voice="...", language="ko"),
        chat_ctx=initial_ctx,
        min_endpointing_delay=0.5,
        allow_interruptions=True,
    )

    assistant.start(ctx.room)
    await assistant.aclose()

Pipecat vs LiveKit Agents 결정

flowchart TD
    Q1{시나리오}
    Q1 -->|1:1 콜봇, 전화| Pipecat
    Q1 -->|다중 사용자 방, WebRTC 우선| LK[LiveKit Agents]
    Q1 -->|화상 회의 + AI 참여자| LK
    Q1 -->|복잡한 frame 변환| Pipecat
    Q1 -->|이미 LiveKit SFU 운영| LK

	Pipecat	LiveKit Agents
Transport	Daily, Twilio, Plivo, FastAPI 등 다양	LiveKit SFU 중심
추상 단위	Frame + Processor	Function 기반
회의 / 룸	단순	강력 (Multi-participant)
Python	우선	Python + Node + Go
학습	약간 가파름	친절한 docs

Managed (Vapi, Retell)

flowchart LR
    You[당신] -->|시스템 프롬프트만| Vapi[Vapi / Retell]
    Vapi -->|호스팅 파이프라인| Tel[Twilio 전화]
    Vapi -->|기본 STT/LLM/TTS| Pipeline

	장점	단점
Vapi	5분 만에 PoC	블랙박스, $0.13-0.30/min
Retell	빠른 시작, 음성 좋음	동일, latency 가시성 낮음

Build vs Buy 기준 (Hamming AI 가이드)

flowchart TD
    Q{기준}
    Q -->|"월 < 10K 분"| Buy[Vapi / Retell]
    Q -->|"월 10-50K 분"| Mid["Pipecat / LiveKit (자체)"]
    Q -->|"월 > 50K 분"| Build[자체 + 깊은 최적화]
    Q -->|"엄격한 컴플라이언스 (HIPAA, FINRA)"| Build
    Q -->|"500ms 미만 지연 필수"| Build
    Q -->|"기존 system 깊은 통합"| Build
    Build --> Save["최대 80% 비용 절감 가능"]

[!IMPORTANT] PoC = Vapi/Retell. 확장 시 → Pipecat/LiveKit 마이그레이션 흐름이 일반.

복원력 설계

flowchart TB
    Q[복원력 요소]
    Q --> Fail[Independent failure points: STT, LLM, TTS]
    Q --> Strat[전략]
    Strat --> Retry[Retry + backoff]
    Strat --> Fallback["Fallback (다른 vendor)"]
    Strat --> Graceful["Graceful: #quot;잠시 후 다시#quot;"]
    Strat --> Health["Health check + circuit breaker"]

각 단계 독립 실패 → 우아하게 처리. 자세한 건 [[retry-with-backoff]] / [[circuit-breaker]].

흔한 함정

[!WARNING]

Managed 만 사용 = 비용 폭증 + 가시성 0. 1000분+ 면 self-host.

Pipecat 의 Frame 무시 = 직접 콜백으로 짜다가 경합 / 순서 문제. Frame 모델 활용.

LiveKit 의 transcription frame = STT 결과가 partial vs final 분리 안 보임. 명시 처리.

자체 구축 시 turn detection = VAD 만으로 한계. 시맨틱 모델 필요. Pipecat / LK 가 내장한 이유.

[Voice AI] Voice RAG: 지연 병목 + 예측적 프리페치

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Voice RAG = 음성 에이전트에 RAG (Retrieval-Augmented Generation) 결합. 벡터 DB 조회 가 지연 누적 의 큰 원인이 되므로 예측적 프리페치 같은 패턴 필수.

기본 흐름

sequenceDiagram
    User->>STT: 발화
    STT->>RAG: 질문 텍스트
    RAG->>Embed: 임베딩
    Embed->>VectorDB: kNN search
    VectorDB-->>RAG: top-K chunks
    RAG->>LLM: prompt + chunks
    LLM-->>TTS: 응답 토큰
    TTS-->>User: 음성

각 단계가 직렬. RAG 추가 200-1000ms → 종단 지연 2초+.

지연 분해

단계	일반	최적
Embedding	50-200ms	30ms (로컬 small 모델)
Vector DB query	30-200ms	10ms (Redis vector, ES kNN)
Re-ranking	100-500ms	50ms (cross-encoder small)
LLM prompt assembly	5-20ms	5ms
RAG overhead	200-1000ms	< 100ms

예측적 프리페치 (Speculative Retrieval)

flowchart LR
    Partial[Partial transcript] --> Predict[가능 의도 예측]
    Predict --> Pre["미리 fetch (병렬)"]
    Final[Final transcript] --> Match{예측 매칭?}
    Match -->|예| UsePre[프리페치 결과 사용]
    Match -->|아니오| Re[다시 fetch]

class SpeculativeRAG:
    def __init__(self):
        self.prefetched: Dict[str, Future] = {}

    async def on_partial(self, partial: str):
        """partial 받자마자 예측 fetch 시작"""
        if len(partial.split()) < 3:
            return   # 너무 짧으면 skip

        # 이미 fetch 중인 것이 있고 유사하면 재사용
        if any(self._similar(partial, k) for k in self.prefetched):
            return

        # 미리 fetch (병렬)
        fut = asyncio.create_task(self._retrieve(partial))
        self.prefetched[partial] = fut

    async def on_final(self, final: str) -> List[Chunk]:
        """final 시 prefetched 결과 활용 또는 새로 fetch"""
        # 가장 유사한 prefetched 찾기
        best = max(self.prefetched.keys(),
                   key=lambda k: self._similarity(k, final),
                   default=None)
        if best and self._similarity(best, final) > 0.85:
            return await self.prefetched[best]
        return await self._retrieve(final)

partial 받자마자 추측 fetch → final 시 대부분 즉시 사용 가능. RAG overhead → 0 에 가깝게.

캐시 계층

flowchart TB
    Q[Query] --> L1["L1: in-memory recent (LRU)"]
    L1 -.miss.-> L2[L2: Redis semantic cache]
    L2 -.miss.-> L3[L3: Vector DB]
    L3 --> Pop[populate L2 + L1]

Semantic Cache

class SemanticCache:
    """비슷한 질문의 결과 재사용"""
    def __init__(self, similarity_threshold=0.92):
        self.cache = {}   # embedding → result
        self.threshold = similarity_threshold

    async def get(self, query: str):
        emb = await embed(query)
        for cached_emb, result in self.cache.items():
            sim = cosine_similarity(emb, cached_emb)
            if sim > self.threshold:
                return result
        return None

자세한 건 [[Redis Vector Search]] 의 semantic cache.

RAG 인덱스 선택 (음성 환경)

	Pinecone	Redis Vector	ES kNN	Qdrant
Latency (kNN)	30-100ms	5-20ms	20-50ms	10-30ms
운영	managed	익숙	익숙	중간
Hybrid (BM25 + vector)	X	별도	우수 (RRF)	가능

음성 에이전트 + 한국어 hybrid search = ElasticSearch kNN + nori 가 강력.

청크 전략 (음성 친화)

# 일반 RAG: 큰 청크 (500-1000 tokens)
# 음성 RAG: *짧은 청크* (100-300 tokens) → LLM 응답 짧게 유도

def chunk_for_voice(doc: str) -> list[str]:
    """문장 단위 + 의미 단위 분할"""
    sentences = nltk.sent_tokenize(doc, language='korean')
    chunks = []
    cur = ""
    for s in sentences:
        if len(cur) + len(s) > 300:
            chunks.append(cur)
            cur = s
        else:
            cur += " " + s
    if cur:
        chunks.append(cur)
    return chunks

Re-ranking 의 trade-off

flowchart LR
    VS[Vector Search top 50] --> Re[Re-ranker]
    Re --> Top5[top 5]
    Re --> Cost[+100-500ms]

정확도 ↑ vs 지연 ↑. 음성 에이전트는 작은 cross-encoder (Cohere rerank-v3 light, BAAI bge-reranker-base) 권장.

흔한 함정

[!WARNING]

RAG 매 turn 동기 fetch = 매 응답 200-1000ms 증가. 예측적 프리페치.

거대 청크 = LLM 응답이 길어짐. 짧은 청크.

Cross-encoder rerank 무조건 = 500ms+ 부담. trade-off 결정.

결과 그대로 prompt = 토큰 폭증. 요약 또는 selection.

[Voice AI] 음성 에이전트 아키텍처: Cascading / Streaming / S2S + Latency Budget

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

실시간 음성 AI 의 3가지 패턴. 각자 지연 vs 유연성 vs 비용 트레이드오프.

3 패턴 비교

flowchart TB
    subgraph Cascading["1. Cascading (순차)"]
        C1[STT] --> C2[LLM] --> C3[TTS]
        Note1["2-4초 지연 (직렬)"]
    end
    subgraph Streaming["2. Streaming (병행)"]
        S1[STT chunks] -.partial.-> S2[LLM streaming]
        S2 -.tokens.-> S3[TTS streaming]
        Note2["< 1초 지연 (병행)"]
    end
    subgraph S2S["3. Speech-to-Speech"]
        D1[Audio In] --> D2[Multimodal Model]
        D2 --> D3[Audio Out]
        Note3["< 300ms (직접 처리)"]
    end

	Cascading	Streaming	S2S
종단 지연	2-4초	< 1초	< 300ms
구현 난이도	쉬움	중간	어려움 (제약)
유연성	최고 (각 단계 교체)	높음	낮음 (벤더 lock)
비용	낮음	중간	높음
Function calling	OK	OK	제한
톤/감정 보존	X	X	예
한국어	모델 마다	모델 마다	일부 (Realtime API 한국어)
사용	MVP / 일반	프로덕션 표준	고급 UX

1. Cascading (순차)

sequenceDiagram
    User->>STT: 발화 (3초)
    Note over STT: 발화 종료 대기 + 전사 (500ms)
    STT->>LLM: 전체 텍스트
    Note over LLM: 응답 생성 (1500ms)
    LLM->>TTS: 전체 응답
    Note over TTS: 음성 합성 (800ms)
    TTS->>User: 음성 시작
    Note over User,TTS: 총: ~3초 지연

async def cascaded_pipeline(audio_url):
    transcript = await stt.transcribe(audio_url)   # 발화 끝나길 기다림
    response = await llm.chat(transcript)           # 전체 응답
    audio = await tts.synthesize(response)          # 전체 합성
    return audio

MVP 에는 OK. 프로덕션은 streaming 으로 진화.

2. Streaming (현재 표준)

sequenceDiagram
    User->>STT: 발화 (3초)
    par
        STT-->>LLM: partial "안녕"
        STT-->>LLM: partial "안녕하세요"
        STT-->>LLM: FINAL "안녕하세요, 오늘 회의"
        LLM-->>TTS: 토큰 "오늘은"
        LLM-->>TTS: 토큰 "수요일입니다"
        TTS-->>User: 오디오 청크 1
        TTS-->>User: 오디오 청크 2
    end
    Note over User: 음성 종료 후 < 1초 응답

async def streaming_pipeline(audio_stream):
    async for transcript_chunk in stt.stream(audio_stream):
        if transcript_chunk.is_final:
            async for token in llm.stream(transcript_chunk.text):
                sentence = aggregator.feed(token)
                if sentence:
                    async for audio_chunk in tts.stream(sentence):
                        yield audio_chunk

[!IMPORTANT] 모든 단계 스트리밍 + sentence aggregator. 2026 시점 프로덕션 음성 AI 의 표준.

3. Speech-to-Speech (S2S)

sequenceDiagram
    User->>Realtime: 오디오 stream (WebRTC / WS)
    Note over Realtime: GPT-4o / Gemini Live<br/>(직접 오디오 처리)
    Realtime-->>User: 오디오 stream (< 300ms)

모델	출시	한국어	특징
OpenAI Realtime API (GPT-4o)	2024-10	우수	WebRTC / WS, function calling 부분
Gemini Live (gemini-live-2.5)	2024-12	우수	Google AI Studio
Moshi (Kyutai)	OSS	영어	full-duplex, 자체 호스팅

[!CAUTION] S2S 의 function calling 제약 = enterprise 시스템 연동 어려움. function 이 필수면 cascading + streaming 채택. [arXiv 참조].

Latency Budget (지연 예산)

flowchart LR
    Mic["마이크 (사용자 발화 끝)"] -->|VAD endpointing 200-500ms| STT
    STT -->|"STT (100-500ms)"| LLM
    LLM -->|"LLM TTFT (200-2000ms)"| TTS
    TTS -->|"TTS TTFA (200-800ms)"| Speaker
    Speaker -->|<= 1000ms| User

단계	일반	최적
Network (Mic → Server)	30-100ms	20ms
VAD endpointing	500ms	200ms (시맨틱)
STT (final)	200-500ms	100ms
LLM TTFT (Time-to-First-Token)	500-2000ms	200ms
Sentence aggregation	50-200ms	0 (streaming)
TTS TTFB	200-800ms	90ms (Cartesia)
Network (Server → Speaker)	30-100ms	20ms
총	2-4초	< 700ms

[!IMPORTANT] 800ms 가 “로봇 같지 않게 느껴지는” 임계. 사람 평균 응답 300-500ms. 모든 단계 동시 최적화 필요.

단계별 최적화

flowchart TB
    Opt[지연 줄이기]
    Opt --> S1[STT: 시맨틱 endpointing, partial 안 기다림]
    Opt --> S2[LLM: 작은 모델, TTFT 최우선, KV-cache]
    Opt --> S3[TTS: streaming + Cartesia급 모델]
    Opt --> Net[Network: WebRTC < WebSocket < HTTP]
    Opt --> Hop[Hop 축소: 같은 region, edge]

결정 트리

flowchart TD
    Q1{지연 요구}
    Q1 -->|< 300ms 필수| S2S_check{Function calling 필수?}
    Q1 -->|< 1초 OK| Stream[Streaming pipeline]
    Q1 -->|2-3초 OK + MVP| Cascade[Cascading]
    S2S_check -->|아니오| S2S[S2S 모델]
    S2S_check -->|예| Stream

한국 시장 권장

시나리오	권장
콜봇 (상담)	Streaming: CLOVA STT + GPT-4o-mini + CLOVA Voice
고급 음성 AI	Streaming: Deepgram + GPT-4o + Cartesia
비용 절감	Cascading: Whisper + GPT-3.5 + Edge TTS
톤/감정 critical	S2S: GPT-4o Realtime

흔한 함정

[!WARNING]

STT/LLM/TTS 각자 다른 region = network hop 누적 → 500ms+. 같은 region.

batch 모델로 시작했다가 latency 못 맞춤 = 처음부터 streaming 모델.

LLM 응답 끝나길 기다리고 TTS 시작 = TTS 의 streaming 의미 없음.

VAD 없이 STT = STT 가 전사 못 끝남. 발화 종료 감지 필수.

[Voice AI] 음성 우선 프롬프트 + Function Calling + Structured Output

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

음성 우선 프롬프트 설계

음성 답변 = 귀로 듣는다. 텍스트 답변과 완전 다르게 짜야 한다.

flowchart LR
    Text["텍스트 답변 (긴 답변 OK)"] --> A1["**bold**, # 헤딩, 표"]
    Voice["음성 답변 (짧고 자연스럽게)"] --> A2["1-2 문장, 의문문으로 turn 넘김"]
    A1 --> Diff
    A2 --> Diff
    Diff{둘은 완전 다름}

음성 프롬프트의 핵심 원칙

원칙	의미
짧게	한 답변 1-2 문장. 50-80 글자
자연스럽게	”$5 = ‘오 달러’” (숫자 정규화 사전 정의)
마크다운 금지	`*`, `#`, `-` 등 모두 음성에 안 들어감*
listicle 분해	”1, 2, 3…” 대신 대화로 분배
turn 넘기기	질문으로 끝내거나 “도와드릴까요?”
에스컬레이션	”사람 상담원 연결해드릴까요?” 명시

SYSTEM_PROMPT = """
당신은 친절한 한국어 콜센터 상담원입니다.

응답 규칙:
- 한 응답은 *1-2 문장* 으로 짧게
- 자연스러운 구어체 사용 ("입니다" 보다 "이에요")
- 숫자는 풀어쓰기 (예: "100만 원" 보다 "백만 원")
- 마크다운, 영어 약어, 코드 사용 금지
- 모르는 정보면 "확인이 어렵네요. 사람 상담원 연결해드릴까요?"
- 답변 끝에 *질문* 으로 turn 을 사용자에게 넘김

페르소나:
- 침착하고 공감하는 톤
- 고객을 "고객님" 으로 호칭
- 절대 "AI" 라고 본인을 칭하지 말 것
"""

Function / Tool Calling

sequenceDiagram
    autonumber
    User->>Agent: "내 주문 상태 확인해줘"
    Agent->>LLM: prompt + tool definitions
    LLM-->>Agent: function_call: get_order_status(user_id=42)
    Agent->>API: GET /orders?user=42
    API-->>Agent: { status: "shipped", eta: "내일" }
    Agent->>LLM: tool_result
    LLM-->>Agent: "고객님 주문은 배송 중이며, 내일 도착 예정이에요."
    Agent->>TTS: 음성 합성
    TTS->>User: 음성 응답

OpenAI Function Calling

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_order_status",
            "description": "사용자의 주문 상태를 조회합니다",
            "parameters": {
                "type": "object",
                "properties": {
                    "user_id": {"type": "integer", "description": "사용자 ID"},
                    "order_id": {"type": "string", "description": "주문 ID (선택)"}
                },
                "required": ["user_id"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "transfer_to_human",
            "description": "사람 상담원에게 연결합니다",
            "parameters": {
                "type": "object",
                "properties": {
                    "reason": {"type": "string"},
                    "priority": {"type": "string", "enum": ["low", "high"]}
                },
                "required": ["reason"]
            }
        }
    }
]

response = await client.chat.completions.create(
    model="gpt-4o-mini",
    messages=messages,
    tools=tools,
    tool_choice="auto",
    stream=True,
)

병렬 Function Calling

# 같은 응답에서 여러 함수 동시 호출 가능
{
  "tool_calls": [
    { "id": "call_1", "function": { "name": "get_weather", "arguments": "..." } },
    { "id": "call_2", "function": { "name": "get_traffic", "arguments": "..." } }
  ]
}

# 병렬 실행
results = await asyncio.gather(
    get_weather(...),
    get_traffic(...),
)

직렬 보다 수배 빠름. 독립 호출이면 활용.

결과를 대화에 자연스럽게

@function_tool
async def get_order_status(user_id: int) -> dict:
    order = await db.get_order(user_id)
    return {
        "status": order.status,
        "eta": order.eta,
        # 함수 결과는 *데이터* 만. *음성 문장* 은 LLM 이 합성
    }

# 잘못된 예: 함수가 문장 반환
@function_tool
async def get_order_status_bad(user_id: int) -> str:
    order = await db.get_order(user_id)
    return f"주문 {order.id} 는 {order.status} 상태이며 ETA {order.eta} 입니다."
    # ← TTS 가 "ETA" 를 영어로 발음하거나 어색

Structured Output

LLM 응답을 JSON schema 강제:

class IntentExtraction(BaseModel):
    intent: Literal["order_status", "refund", "complaint", "transfer", "other"]
    user_id: Optional[int]
    order_id: Optional[str]
    urgency: Literal["low", "normal", "high"]

response = await client.chat.completions.parse(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": user_text}],
    response_format=IntentExtraction,
)

intent = response.choices[0].message.parsed
# intent.intent == "order_status"  ← 타입 안전

슬롯 채우기 (Slot Filling)

# 사용자가 부분 정보만 주면 → 부족한 슬롯 묻기
class BookingRequest(BaseModel):
    restaurant: Optional[str]
    date: Optional[str]
    party_size: Optional[int]
    is_complete: bool = False

# 첫 발화: "내일 5명 예약하고싶어"
# extracted: { date: "내일", party_size: 5, restaurant: None, is_complete: false }

# LLM 이 부족한 정보 *질문*
if not extracted.restaurant:
    response = "어느 식당으로 예약 도와드릴까요?"

페르소나 일관성

PERSONA = """
이름: 민지
성격: 친절, 차분, 약간 유머
역할: 카페 음성 주문 도우미
말투: 격식 있는 존댓말 ("이에요", "괜찮으세요?")
금지: 비속어, 정치/종교, 의료 조언
"""

SYSTEM = f"""
{PERSONA}

응답 규칙:
- 항상 페르소나 일관성 유지
- 메뉴 외 질문은 정중히 거절 + 본업으로 유도
"""

흔한 함정

[!WARNING]

시스템 프롬프트가 길고 마크다운 = TTS 가 안 읽지만, LLM 의 응답이 마크다운 따라함. 출력 형식 명시.

숫자 발음 = “1500000원” → “일오영영영영영원”. 별도 정규화 또는 SSML.

function 결과로 긴 텍스트 반환 = LLM 이 그대로 읽음. 데이터만.

tool calling 중 interruption 허용 = DB write 중간에 끊김. disallow_interruptions.

김신건의 로그 - 위키 / ai

[LLM Eval] HELM: Holistic Evaluation of Language Models

정의

왜 등장했는가

7 가지 핵심 메트릭 축

시나리오 (Scenario)

HELM Variants (2023~)

HELM Lite (2023 말~)

HELM Instruct

HELM Safety

도메인 특화 HELM

시나리오 × 메트릭 매트릭스

리더보드 (2026 기준)

실행 방법 (helm-run)

다른 벤치마크와 비교

한계와 비판

참고

Function Calling / Tool Use: LLM 도구 사용

정의

예시

함수 스펙 정의

대화

실행 후 결과 재주입

Agent 프레임워크

함정

참고

LLM RAG: Retrieval-Augmented Generation

정의

왜 필요한가

파이프라인

핵심 구성 요소

1. 문서 chunk 화

2. Embedding

3. Vector Store

4. Retrieval

5. Prompt Composition

최적화 기법

평가 지표

참고

[Voice AI] Agent 패턴: Supervisor, Handoff, ReAct, HITL

정의

4가지 핵심 패턴

1. Supervisor

2. Handoff

3. ReAct (Reason + Act)

4. Human-in-the-Loop (HITL)

패턴 조합

LangGraph 예시 (다중 agent + state machine)

흔한 함정

관련 위키

[Voice AI] LLM Serving: vLLM, PagedAttention, continuous batching

정의

PagedAttention

Continuous Batching

TTFT (Time-to-First-Token) vs TPS

SSE 스트리밍 (Server-Sent Events)

vLLM 시작

Prefix Caching (system prompt 재사용)

Quantization

모델 크기 vs 음성 적합성

흔한 함정

관련 위키

[Voice AI] Pipecat vs LiveKit Agents: 프레임워크 비교

정의

Pipecat

Pipecat 의 Frame 종류

LiveKit Agents

Pipecat vs LiveKit Agents 결정

Managed (Vapi, Retell)

Build vs Buy 기준 (Hamming AI 가이드)

복원력 설계

흔한 함정

관련 위키

[Voice AI] Voice RAG: 지연 병목 + 예측적 프리페치

정의

기본 흐름

지연 분해

예측적 프리페치 (Speculative Retrieval)

캐시 계층

Semantic Cache