김신건의 로그 - 위키 / ai

[LLM Eval] BIG-Bench (Beyond the Imitation Game)

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

BIG-Bench (Beyond the Imitation Game Benchmark) 는 2022년 Google + 132개 기관 442명의 공저로 발표된 대형 언어 모델 종합 평가 벤치마크 입니다. 204 개의 다양한 태스크 를 담고 있어, 하나의 스킬이 아닌 언어 모델의 광폭 능력 지도 를 그리는 것이 목표입니다.

이름은 튜링 테스트 (Imitation Game) 를 넘어서겠다는 뜻으로, 단일 태스크 벤치마크가 놓치는 능력들을 포괄합니다.

구성

태스크 유형

BIG-Bench 태스크는 크게 두 형태로 정의됩니다.

JSON tasks: 입력, 정답 (multiple-choice 또는 free-form generation) 이 JSON 으로 명시된 태스크. 자동 채점 가능.
Programmatic tasks: 파이썬 함수가 상호작용 (다중 턴, 조건부 프롬프트 생성) 을 정의. 훨씬 유연하지만 상대적으로 소수.

태스크 카테고리

204 개는 다음과 같은 keyword tag 로 분류됩니다 (한 태스크에 여러 태그).

태그	대표 태스크
논리 (logic)	logical deduction, formal fallacies, sports understanding
수학 (mathematics)	arithmetic, tracking shuffled objects, multi-step arithmetic
상식 (commonsense)	causal judgment, hyperbaton, disambiguation QA
다국어 (multilingual)	international phonetic alphabet transliterate, 다국어 QA
사회 편향 (bias)	BBQ (Bias Benchmark for QA), gender inclusive sentences
자기인식 (self-awareness)	self-evaluation tutoring, know unknowns
거짓 정보 (misinformation)	TruthfulQA (별도 벤치이지만 통합)
coding	date understanding, formal logic
소설 태스크	novel concepts, ruin names, understanding fables
긴 컨텍스트	disambiguation, tracking shuffled objects

채점

Multiple-choice: brier score, log-likelihood 정답 확률
Generation: exact match, BLEU, ROUGE, 태스크별 custom scorer

각 태스크는 인간 baseline (평균/최고) 도 함께 포함하여, 모델이 사람 수준에 도달했는지 판단합니다.

평가 파이프라인

flowchart LR
    Model["LLM 모델"] --> Harness["lm-evaluation-harness"]
    Harness --> BBH["BBH 태스크들<br/>(23개)"]
    BBH --> Prompt["Few-shot prompt<br/>(3-shot CoT)"]
    Prompt --> Gen["모델 생성"]
    Gen --> Score["자동 채점<br/>(exact match / custom)"]
    Score --> Report["정확도 리포트<br/>(태스크별 + 평균)"]
    Human["인간 baseline"] --> Report

flowchart TD
    BBH_Raw["BBH (23 태스크)"] -->|"GPT-4 급에서 포화"| BBEH["BBEH (23 대응)"]
    BBEH --> HardTask["추론 홉 증가<br/>오도 정보 삽입<br/>문제 길이 확장"]
    HardTask --> Result["최신 프론티어 모델<br/>평균 정확도 30% 미만"]

BIG-Bench Hard (BBH)

Suzgun et al. (2022) 은 204 개 태스크 중 당시 (GPT-3 급) 최선 모델이 사람 평균에도 못 미친 23 개 태스크 를 골라 BIG-Bench Hard (BBH) 를 만들었습니다.

대표 BBH 태스크 (일부):

Boolean Expressions: 논리식 truth value 계산
Causal Judgment: 인과관계 판단 (도덕적 시나리오 포함)
Date Understanding: 상대 날짜 계산 (“last Friday” 등)
Disambiguation QA: 대명사 지칭 애매성
Formal Fallacies: 형식논리 오류 식별
Geometric Shapes: SVG path -> 도형 이름
Hyperbaton: 형용사 순서 문법
Logical Deduction (three/five/seven objects): 순서 추론
Movie Recommendation: 최근접 유사 영화 찾기
Multi-Step Arithmetic: 다단계 계산
Navigate: 이동 후 시작점 여부
Object Counting: 물체 개수 세기
Penguins in a Table: 표에서 조건 필터링
Reasoning about Colored Objects: 색깔 물체 추론
Ruin Names: 이름의 한 글자 바꾸기
Salient Translation Error Detection: 번역 오류 탐지
Snarks: 풍자 이해
Sports Understanding: 스포츠 상식
Temporal Sequences: 일정 짜기
Tracking Shuffled Objects (three/five/seven): 물체 위치 추적
Web of Lies: 진실/거짓 진술 체인
Word Sorting: 단어 정렬

이 23개는 [[chain-of-thought|CoT]] 프롬프팅 효과를 검증하는 대표 벤치마크로 자리잡았습니다. Suzgun 논문 자체가 “CoT 로 몇 태스크는 사람 수준을 초과” 했다는 결과입니다.

BBEH (BIG-Bench Extra Hard)

Kazemi et al. (2025) 은 BBH 가 최신 프론티어 모델 (GPT-4o, Claude 3.5, Gemini 1.5) 에게 이미 포화 (> 85% 정확도) 되었다는 문제를 지적하며, 각 BBH 태스크의 더 어려운 변종 으로 대체한 BBEH 를 발표했습니다.

BBH 와 같은 23 개 카테고리 대응
문제 길이 확장, 추론 홉 (hop) 증가, 오도 정보 삽입
최신 모델도 평균 정확도 30% 미만 (초기 리포트 기준)

주요 모델 성능 추이

BIG-Bench / BBH 에서의 정확도 변화 (대략적 추이):

모델 세대	BBH 정확도 (대략)	특이점
GPT-3 (2020)	30-40%	사람 평균 이하 태스크 다수
GPT-4 (2023)	70-85%	대부분 태스크 사람 수준 근접
Claude 3.5 / GPT-4o (2024)	> 85%	포화 시작, BBH 변별력 감소
o1 / Gemini 2.0 (2024-25)	> 90%	BBH 실질적 의미 소멸, BBEH 필요성 대두

[!IMPORTANT] 이 수치들은 대략적인 경향입니다. 실제 벤치마크 결과는 few-shot 설정, 프롬프트 형식, 평가 도구 버전에 따라 달라집니다.

리더보드

원 BIG-Bench 는 GitHub 기반 커뮤니티 벤치마크 로 시작했지만, 이후 다음 플랫폼들이 리더보드를 제공합니다.

HELM Classic: BIG-Bench 태스크 일부 통합, [[helm-llm-benchmark|HELM]] 축으로 리포트
EleutherAI lm-evaluation-harness: BBH 자동 실행 지원 (--tasks bbh_*)
Papers With Code: BBH 별 순위표

한계

[!WARNING] 태스크 품질 편차가 큽니다. 442명 공저 방식이라 태스크마다 명세 완성도가 다르고, 일부는 정답 라벨이 애매합니다. 이 문제 때문에 실전에서는 BBH 로 축약해 쓰는 경우가 많습니다.

[!CAUTION] 데이터 오염 (contamination). 초기 발표 후 태스크가 공개되어 학습 데이터에 유입될 위험. GPT-4 이후 모델의 BBH 정확도가 갑자기 뛴 이유 중 하나로 지목됩니다. BBEH 는 이 문제를 부분 완화.

[!IMPORTANT] BIG-Bench 는 “언어 이해” 편중 입니다. 코드 실행, 멀티모달, agent 사용, 툴 호출은 초기 스코프에서 벗어나 있어, 오늘날 LLM 평가에는 다른 벤치마크와 병행이 필요합니다.

다른 벤치마크와 관계

벤치마크	초점	BIG-Bench 와 차이
**[[helm-llm-benchmark	HELM]]**	다면적 (accuracy + fairness + robustness …)
MMLU	지식 QA 57 과목	BIG-Bench 는 더 넓고 소설 태스크 포함, MMLU 는 학과 시험
MMLU-Pro	MMLU 강화	여전히 지식 QA 편중
GSM8K / MATH	수학	BIG-Bench 에 수학 태스크가 있지만 소규모
HumanEval / MBPP	코드 생성	BIG-Bench 는 코드 편중 아님
Chatbot Arena	사람 선호도	태스크 세분화 없음, BIG-Bench 는 세분

실전 사용

# EleutherAI lm-evaluation-harness 기준
pip install lm-eval

lm_eval \
  --model hf \
  --model_args pretrained=meta-llama/Llama-3.3-70B \
  --tasks bbh_boolean_expressions,bbh_navigate,bbh_causal_judgment \
  --num_fewshot 3 \
  --device cuda:0

bbh_* 태스크는 CoT 를 기본으로 활용하도록 few-shot 예시가 이미 구성되어 있습니다. Zero-shot 실험이라면 bbh_zero_shot_* 변종 사용.

재현 시 주의사항

few-shot 수 (0, 1, 3) 에 따라 결과가 크게 달라짐
프롬프트 템플릿 (CoT 유무, 언어) 명시
모델 버전 (체크포인트) 고정
평가 라이브러리 버전 고정 (lm-eval 버전별 결과 차이 존재)

인간 baseline 해석

BIG-Bench 는 태스크별로 인간 평균 과 인간 최고 두 baseline 을 제공합니다.

인간 평균: 일반 사람 (crowdsource) 의 평균 성능. 많은 태스크에서 50-75% 수준.
인간 최고: 전문가 또는 best worker. 대부분 태스크에서 85-99%.
모델 점수가 인간 평균을 초과하면 “superhuman” 이라 부르지만, 태스크 특성에 따라 다름.

BBH 의 23개 태스크는 원 BIG-Bench 에서 GPT-3 이 인간 평균에 못 미친 것들. 즉 BBH 의 human baseline 은 최소 GPT-3 보다 높다는 의미.

[!WARNING] 인간 baseline 은 crowdwork 설정에 따라 달라집니다. 태스크 지시문의 명확도, 평가자의 도메인 지식에 따라 동일 태스크라도 baseline 이 크게 다를 수 있습니다.

어떤 상황에 사용하나

상황	사용 여부	이유
새 모델의 일반 언어 능력 측정	BBH 사용	검증된 23개, 해석하기 쉬움
최신 프론티어 모델 변별	BBEH 사용	BBH 는 포화 상태
코드 생성 능력 평가	다른 벤치 (HumanEval, MBPP)	BIG-Bench 는 코드 편중 아님
다국어 능력	FLORES, mMMLU 병행	BIG-Bench 다국어 태스크는 소수
에이전트/툴 사용 능력	GAIA, SWE-bench	BIG-Bench 스코프 밖
연구 논문에서 표준 비교	BBH 선택	인용 수와 재현성 보장

[!TIP] BBH 를 단독으로 리포트하면 “어떤 few-shot 설정인지”, “어떤 평가 라이브러리 버전인지” 반드시 명시. 설정에 따라 결과가 5-15% 포인트 달라질 수 있음.

공개 기여 방법

BIG-Bench 는 GitHub PR 기반 공개 기여 모델로 운영됩니다.

# 새 태스크 기여 흐름
git clone https://github.com/google/BIG-bench
cd BIG-bench/bigbench/benchmark_tasks/

# 새 폴더 생성 (kebab-case)
mkdir my_new_task
# task.json 또는 task.py 작성
# README.md: 태스크 설명, 인간 baseline, 동기 기술
# 테스트: python -m pytest bigbench/tests/

태스크는 JSON (간단한 QA) 또는 Python (복잡한 상호작용) 중 선택. 공식 GitHub 의 bigbench/benchmark_tasks/ 아래 기존 태스크를 참고.

[Prompting] Few-Shot Prompting

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

Few-shot prompting 은 프롬프트 안에 작업의 입력-출력 예시 K개 (보통 K = 2~16) 를 함께 제공해 모델이 그 형식과 규칙을 유추해 새 입력에 답하도록 하는 기법입니다. 예시로부터의 학습이지만 가중치 갱신이 없기 때문에 (no gradient update) 이를 in-context learning (ICL) 이라 부릅니다.

Brown et al. (2020) 의 GPT-3 논문이 “규모가 커지면 파인튜닝 없이도 예시 몇 개만으로 태스크를 수행한다” 는 관찰을 대중화했습니다.

언제 쓰이나

엄격한 출력 형식 강제: JSON 스키마, 특정 XML, 사내 보고서 양식
도메인 특화 어휘: 의료, 법률, 사내 용어의 특수 컨벤션
비표준 분류 라벨: 기존 상식과 다른 라벨 체계
zero-shot 오류가 반복될 때: 예시가 지시문보다 훨씬 빠르게 문제를 해결
입력이 짧고 반복 패턴이 강한 태스크: 구조적 예시의 효과가 극대화

기본 흐름

flowchart LR
    subgraph Prompt["Few-Shot 프롬프트"]
        E1["예시 1: Input - Output"]
        E2["예시 2: Input - Output"]
        EK["예시 K: Input - Output"]
        Q["본 질의: Input - ?"]
    end
    Prompt --> ICL["LLM\nIn-Context Learning"]
    ICL --> Ans["예측 Output"]

예시는 가중치를 바꾸지 않는다. 모델이 컨텍스트에서 패턴을 추출해 즉시 적용.

기본 구조

[선택] 시스템/지시문
[선택] 형식 스펙

[예시 1]
Input: ...
Output: ...

[예시 2]
Input: ...
Output: ...

...

[본 질의]
Input: {query}
Output:

Chat API 에서는 이를 role-alternating messages 로 옮기기도 합니다:

[
  {"role": "system", "content": "감정을 positive/negative 로 분류"},
  {"role": "user", "content": "이 식당은 정말 좋았어요"},
  {"role": "assistant", "content": "positive"},
  {"role": "user", "content": "다시는 가고 싶지 않네요"},
  {"role": "assistant", "content": "negative"},
  {"role": "user", "content": "{query}"}
]

K 값의 선택

K	특성	언제
0	Zero-shot	지시문이 명확하고 모델이 태스크를 잘 알 때
1	One-shot	형식만 맞추면 되는 단순 태스크
3-8	표준 few-shot	대부분의 실전 태스크
16-32	Many-shot	Complex reasoning, 다양한 클래스 커버
100+	Many-shot (Gemini/Claude long context)	컨텍스트 확장 후 등장한 실험적 영역

Diminishing return 이 K = 8 근처부터 관찰되는 경우가 많지만, Gemini 1.5 / Claude 3 이후의 초장문 컨텍스트에서는 K = 500 many-shot 이 여전히 유효하다는 결과 (Agarwal et al. 2024) 도 있습니다.

무엇이 성능을 결정하는가

Min et al. (2022) 의 “Rethinking the Role of Demonstrations” 이 반직관적 결과를 보였습니다.

라벨을 랜덤으로 섞어도 정확도가 크게 안 떨어짐 (in-context 예시는 형식/도메인 시그널이 더 중요)
하지만 입력 분포 와 라벨 분포 (어떤 클래스가 나올 수 있는지) 는 매우 중요
형식 (delimiter, template) 이 라벨보다 더 중요할 때가 많음

즉 few-shot 예시가 하는 일은 모델에게 “이 태스크의 표면 형식” 을 상기시키는 것이지, 실제로 “라벨 규칙을 학습” 하는 것은 아닐 수 있습니다 (완전한 결론은 아니지만 강력한 경향성).

예시 선택 전략

Liu et al. (2021) 는 kNN 유사도 기반 선택 이 유리함을 보임. 프로덕션에서는:

flowchart TD
    Pool["예시 풀\n(수백~수천개)"] --> Embed["예시 임베딩 변환"]
    Query["현재 질의"] --> QEmbed["질의 임베딩 변환"]
    Embed --> KNN["kNN 유사도 검색"]
    QEmbed --> KNN
    KNN --> TopK["Top-K 유사 예시 선택"]
    TopK --> Bal["라벨 균형 조정\n(Majority bias 방지)"]
    Bal --> Prompt["Few-shot 프롬프트 조합"]
    Query --> Prompt
    Prompt --> LLM["LLM 추론"]

RAG 스타일: 질의를 임베딩 후 pool 에서 top-k 유사 예시 선택
Diverse selection: 클러스터에서 골고루 뽑아 커버리지 확보
Hard example prioritization: 어려운 케이스 (edge case) 를 예시로 포함

함정과 편향

1. Recency bias

마지막 예시의 라벨이 답에 강하게 영향. 다양한 클래스를 골고루 섞고 마지막에 특정 편향된 라벨을 두지 않도록 주의.

2. Majority label bias

예시에 특정 클래스가 많으면 그쪽으로 편향. 균형된 분포로 샘플링.

3. Common token bias

빈도 높은 토큰 (예: “yes”) 을 답으로 선호. Calibrate Before Use (Zhao et al., 2021) 는 이를 완화하는 후처리:

p_calibrated(y | x) = p(y | x) / p(y | "")

빈 입력에 대한 확률로 나누어 편향을 정규화.

4. Order sensitivity

Lu et al. (2022) 는 같은 예시라도 순서만 바꿔도 정확도가 큰 폭으로 흔들림을 보였습니다. 여러 순서로 앙상블 하거나 정보이론적 지표로 좋은 순서 선택 을 시도.

5. Example selection

Liu et al. (2021) 는 kNN 유사도 기반 선택 이 유리함을 보임. 프로덕션에서는:

RAG 스타일: 질의를 임베딩 -> pool 에서 top-k 유사 예시 선택
Diverse selection: 클러스터에서 골고루 뽑아 커버리지 확보
Hard example prioritization: 어려운 케이스 (edge case) 를 예시로 포함

Chain-of-Thought 와 결합

Few-shot + [[chain-of-thought|CoT]] 는 CoT 원 논문의 정확한 방식. 예시 자체에 추론 사슬 을 포함:

Q: If John has 3 apples and gives 1 to Mary, how many left?
A: John started with 3. He gave away 1. 3 - 1 = 2. The answer is 2.

Q: {question}
A:

실전 예시

Python 으로 few-shot 분류 (OpenAI)

from openai import OpenAI

client = OpenAI()

def few_shot_classify(text: str, examples: list[dict]) -> str:
    """
    examples: [{"input": "...", "output": "positive/negative"}]
    """
    messages = [
        {"role": "system", "content": "고객 리뷰를 positive 또는 negative 로 분류합니다."}
    ]

    # few-shot 예시를 role-alternating 으로 추가
    for ex in examples:
        messages.append({"role": "user", "content": ex["input"]})
        messages.append({"role": "assistant", "content": ex["output"]})

    # 본 질의
    messages.append({"role": "user", "content": text})

    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=messages,
        temperature=0.0,
    )
    return response.choices[0].message.content.strip()

examples = [
    {"input": "정말 만족스럽습니다!", "output": "positive"},
    {"input": "다시는 구매 안 합니다.", "output": "negative"},
    {"input": "무난하고 가성비 좋네요.", "output": "positive"},
    {"input": "포장이 너무 엉망이었어요.", "output": "negative"},
]

result = few_shot_classify("배송이 생각보다 늦었지만 제품은 좋아요.", examples)
print(result)  # "positive"

JSON 스키마 강제 추출

SYSTEM = "다음 양식에 맞게 JSON 만 출력하시오. 추가 텍스트 없이."
EXAMPLES = [
    {
        "input": "홍길동, 010-1234-5678, hong@example.com",
        "output": '{"name":"홍길동","phone":"010-1234-5678","email":"hong@example.com"}',
    },
    {
        "input": "김철수, 010-9999-0000, chul@corp.co.kr",
        "output": '{"name":"김철수","phone":"010-9999-0000","email":"chul@corp.co.kr"}',
    },
]

messages = [{"role": "system", "content": SYSTEM}]
for ex in EXAMPLES:
    messages += [
        {"role": "user", "content": ex["input"]},
        {"role": "assistant", "content": ex["output"]},
    ]
messages.append({"role": "user", "content": "이영희, 010-7777-8888, lee@startup.io"})

Instruction-tuned 모델에서의 위상 변화

GPT-4, Claude, Gemini 등 instruction-tuned 계열은 zero-shot 성능이 이미 높아 대부분 태스크에서 few-shot 이득이 작아졌습니다. Few-shot 이 여전히 강한 곳은:

엄격한 출력 형식 (예: 특정 JSON 스키마)
도메인 특화 어휘 (의료, 법률의 특정 용어 컨벤션)
분류 태스크의 라벨 세트가 이상함 (기존 상식과 다른 라벨링)
입력이 짧고 반복 패턴이 강함

실전 팁

가장 정보량 높은 예시 를 선택 (경계 케이스, 오답이 자주 나오는 케이스).
예시 순서 다양화 후 앙상블 (n=3~5 순서).
라벨 균형 유지: K=8 이면 각 라벨이 최대 2-3개.
명시적 구분자 (###, ---, Q:/A:) 로 예시 경계를 확실히.
형식만 배우는 것 같으면 temperature 를 낮추고 (0-0.2) 결정적 출력.
비용 관리: K 를 늘리면 입력 토큰이 선형 증가. K=8 → K=32 는 API 요금 4배.

함정

[!WARNING] Recency / Majority bias 로 인해 예상과 다른 라벨을 선호합니다. 마지막 예시나 빈번한 라벨로 치우치는 경향이 있습니다. 예시 순서를 무작위로 섞거나 여러 순서의 앙상블을 고려하세요.

[!CAUTION] 비용이 선형으로 증가합니다. K = 16 예시를 모든 요청에 붙이면 입력 토큰이 크게 늘어납니다. RAG 스타일 동적 선택으로 관련 예시만 붙이는 방식이 비용 효율적입니다.

[!IMPORTANT] 예시 품질이 결과 품질을 결정합니다. 잘못된 예시 하나가 전체 성능을 끌어내릴 수 있습니다. 예시 pool 은 사람이 검증한 고품질 샘플로 구성하세요.

[Prompting] Zero-Shot Prompting

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

Zero-shot prompting 은 프롬프트에 예시 없이 태스크 지시문만 제공해 모델이 태스크를 수행하도록 하는 기법입니다. K=0 few-shot 이지만 의미가 다르며, 모델이 사전학습 + instruction tuning 으로 얻은 일반화 능력에 의존합니다.

Radford et al. (2019) 의 GPT-2 논문에서 “unsupervised multitask learners” 라는 표현으로 처음 대중화되었고, InstructGPT (2022) 이후 실용화되었습니다.

언제 쓰이나

표준 태스크: 요약, 번역, 감정 분석, 텍스트 분류
자연어 인터페이스 (챗봇): 사용자 발화가 매번 달라 few-shot 이 비실용적
비용 최소화: 대량 배치 처리에서 입력 토큰 절감
탐색적 실험 초기: 새 태스크를 설계할 때 반복 실험 시작점
프로덕션 간단 태스크: 모델이 이미 잘 아는 태스크에서 예시 없이도 충분

기본 흐름

flowchart LR
    Inst["지시문\n(태스크 설명)"] --> Model["Instruction-tuned LLM"]
    Input["입력 텍스트"] --> Model
    Model --> Output["예측 출력"]

예시가 없다. 지시문 + 입력만으로 추론. 모델의 instruction tuning 품질이 곧 zero-shot 성능.

기본 구조

{지시문}

{입력}

예:

다음 문장의 감정을 positive 또는 negative 중 하나로만 답하시오.

문장: 이 식당은 서비스도 좋고 음식도 맛있었습니다.
답:

왜 zero-shot 이 가능한가

사전학습 데이터에 이미 태스크가 섞여 있음: 인터넷 코퍼스에는 “번역: … -> …”, “요약: …”, “질문: … 답: …” 형태가 자연스럽게 포함되어, 모델이 pattern 을 학습.
Instruction tuning (FLAN, T0, InstructGPT): 다양한 태스크의 지시문 + 정답 쌍 으로 파인튜닝. 미지의 지시문에도 일반화.
RLHF: 사람 선호도 기반 강화학습으로 지시 준수 능력 강화.

flowchart TD
    PT["사전학습\n(웹 텍스트 수조 토큰)"] --> IT["Instruction Tuning\n(FLAN, T0, SFT)"]
    IT --> RLHF["RLHF / DPO\n(사람 선호도 학습)"]
    RLHF --> ZS["Zero-shot 능력\n(미학습 태스크도 수행)"]

Few-shot 대비 장단점

기준	Zero-shot	Few-shot
입력 토큰	매우 짧음	K 배 증가
비용	낮음	예시 개수만큼 증가
형식 준수	지시문에만 의존	예시가 강력한 앵커
엣지 케이스	지시문에 안 쓰면 놓침	예시로 커버 가능
성능 (단순 태스크)	Instruction-tuned 모델이면 대등	소폭 우위
성능 (복잡/특이 태스크)	지시문만으론 부족	예시로 disambiguate

Zero-shot CoT

Kojima et al. (2022) 는 프롬프트 끝에 “Let’s think step by step” 을 붙이는 것만으로 CoT 를 유도할 수 있음을 보였습니다.

Q: {question}
A: Let's think step by step.

Multi-Arith 정확도 17.7% → 78.7% (InstructGPT-003). 자세한 내용은 [[chain-of-thought|Chain-of-Thought]] 참조.

sequenceDiagram
    participant U as 사용자
    participant L as LLM

    U->>L: 문제 + "단계별로 풀이하시오"
    L-->>L: 내부 추론 단계 생성
    L-->>U: 1단계 풀이 ... 최종 답

한국어에서는:

“차근차근 생각해 봅시다.”
“단계별로 풀이해 봅시다.”
“먼저 문제를 정리하고, 단계별로 계산합니다.”

Instruction tuning 의 영향

Zero-shot 성능은 모델의 instruction tuning 품질에 강하게 의존합니다.

FLAN (Wei et al., 2021)

Google 의 137B LaMDA-PT 를 62개 NLP 태스크의 지시문으로 파인튜닝. 미학습 태스크에서 zero-shot 성능이 raw LM 대비 큰 폭 개선.

T0 (Sanh et al., 2022)

Multitask prompted training. 다양한 프롬프트 템플릿을 학습하여 새 지시문 형태에도 robust.

InstructGPT / RLHF

Ouyang et al. (2022) 는 사람 라벨러의 지시문 예시로 SFT + PPO. ChatGPT 계보의 시작. Zero-shot 이 사실상 표준이 된 계기.

오늘의 instruction-tuned 모델

OpenAI GPT-4o, GPT-5, o1/o3
Anthropic Claude 3.5/3.7/4/Opus 4
Google Gemini 2.5 Pro/Flash
Meta Llama 3.3, Llama 4
DeepSeek V3, R1
Mistral Large 2, Ministral

모두 zero-shot 시나리오를 기본으로 튜닝되어 있고, 실전 사용의 90%+ 는 zero-shot 형태입니다.

잘 쓰는 지시문의 원칙

구체적 태스크 정의: “이 텍스트를 요약하시오” 보다 “다음 뉴스 기사를 3문장 이하 한국어로 요약하시오”.
출력 형식 명시: JSON 객체로 답하되 {"summary": ..., "keywords": [...]} 형태.
제약 명시: “고유명사를 그대로 유지”. “300자 이내”.
역할 부여 (선택): “당신은 시니어 백엔드 엔지니어입니다”. 스타일 조정에는 유효, 정확도에는 미미.
분리자 사용: <입력>...</입력>, ###, --- 로 지시문과 데이터 경계 명확화.
부정보다 긍정 지시: “하지 마세요” 보다 “이렇게 하세요”. 부정문은 놓치기 쉬움.

Claude 계열에는 XML 구분자가 특히 효과적입니다:

<instruction>
다음 고객 이메일의 의도를 분류하시오.
분류 결과: INQUIRY, COMPLAINT, REFUND_REQUEST, OTHER 중 하나
</instruction>

<email>
{email_body}
</email>

분류:

실전 예시

감정 분석

당신은 한국어 고객 리뷰 분석기입니다.
아래 리뷰의 감정을 POSITIVE, NEGATIVE, NEUTRAL 중 하나로만 답하시오.

리뷰: "배송은 빠른데 포장이 엉망이었어요. 제품 자체는 괜찮습니다."
감정:

예상 출력: NEUTRAL

구조화 JSON 추출

다음 채용 공고에서 정보를 추출해 JSON 으로 반환하시오.
형식: {"role": "...", "company": "...", "skills": [...], "location": "..."}

텍스트: (주)테크스타트에서 시니어 백엔드 엔지니어를 채용합니다.
주요 기술: Java, Spring Boot, Kubernetes. 서울 강남 근무.

JSON:

Zero-shot CoT: 수학 문제

다음 문제를 단계별로 풀이하시오.

문제: 사과가 32개 있다. 4명이 균등하게 나누면 각자 몇 개씩 받는가?
단계별 풀이:

Python 에서 zero-shot 호출

from openai import OpenAI

client = OpenAI()

def zero_shot(instruction: str, input_text: str) -> str:
    response = client.chat.completions.create(
        model="gpt-4o",
        temperature=0.0,
        messages=[
            {"role": "system", "content": instruction},
            {"role": "user", "content": input_text},
        ],
    )
    return response.choices[0].message.content.strip()

# 감정 분석
result = zero_shot(
    instruction="고객 리뷰를 POSITIVE, NEGATIVE, NEUTRAL 중 하나로 분류하시오.",
    input_text="배송이 빠르고 포장도 깔끔해서 아주 만족합니다.",
)
print(result)  # "POSITIVE"

성능 한계

한계 상황	원인	대안
사내 고유 분류 체계	지시문으로 표현 어려움	few-shot 예시 추가
10개 이상 라벨 분류	라벨 집합이 너무 큼	few-shot 또는 파인튜닝
엄격한 구조 출력	형식 오류율 높음	[[function-calling
도메인 특화 어휘	사전학습에 희소	few-shot + [[llm-rag
수치 추론 및 계산	직접 계산 실수	zero-shot CoT 또는 code interpreter

함정

[!WARNING] 모호한 태스크에서 오답률이 급등합니다. 라벨 후보가 표준적이지 않거나 (예: 5단계 감정, 자체 스키마), 도메인 특수 어휘가 나오면 예시 없이 정확히 맞추기 어렵습니다. 이럴 때는 최소한 one-shot 이라도 붙여야 합니다.

[!CAUTION] 잘못된 지시문에 순응합니다. 지시문에 모순이 있어도 모델은 대개 뭐라도 답하려 합니다. 이상한 라벨 조합, 존재하지 않는 태스크 이름에도 그럴싸한 답을 내니, 지시문 자체의 검증이 필요합니다.

[!WARNING] Zero-shot 은 재현성이 낮을 수 있습니다. temperature=0 이어도 시스템 프롬프트, 컨텍스트 캐시, provider 백엔드 상태에 따라 결과가 흔들립니다. 여러 시드로 평균 내는 편이 안전.

[!IMPORTANT] 모델별로 최적 지시문 스타일이 다릅니다. GPT 는 markdown 을 잘 따르고, Claude 는 XML 구분자에 강하고, Gemini 는 구조화된 프롬프트에 반응이 좋습니다. 이식성이 필요하면 공통 최소분모 형식으로.

언제 zero-shot 을 쓰나

간단한 요약, 번역, 감정 분석 (표준 태스크)
자연어 인터페이스 (챗봇): 사용자 발화가 매번 달라 few-shot 이 무의미
비용 최소화: 대량 배치 처리
탐색적 태스크 정의: 프롬프트 반복 실험 초기 단계

언제 zero-shot 대신 few-shot 이 낫나

출력 스키마가 매우 엄격 (JSON 스펙, 특정 XML)
도메인 특화 (법률, 의료, 사내 용어)
분류 라벨이 비표준
예시가 지시문보다 훨씬 짧고 명확할 때
모델이 instruction tuning 이 약한 (base model) 계열일 때

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

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

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

음성 응답 허용 지연(Time to First Audio)은 일반적으로 1.5-2초 이하를 목표로 하는데, 기존 RAG 파이프라인의 직렬 구조는 이 예산을 쉽게 초과합니다.

언제 쓰이나

도메인 지식 필요 음성 에이전트: 콜센터, 의료 Q&A, 사내 챗봇
실시간 대화 + 사실 근거: 환각을 줄이고 정확한 출처 기반 답변 필요
다회차 음성 대화: 이전 발화 컨텍스트 + 외부 지식 결합

전체 파이프라인

sequenceDiagram
    participant User as 사용자
    participant VAD as VAD
    participant STT as STT
    participant RAG as RAG
    participant LLM as LLM
    participant TTS as TTS

    User->>VAD: 음성 스트림
    VAD-->>STT: End-of-Speech 감지
    STT-->>RAG: 전사 텍스트
    Note over STT,RAG: partial 수신 시 미리 prefetch
    RAG-->>LLM: 질문 + 관련 청크
    LLM-->>TTS: 응답 토큰 (streaming)
    TTS-->>User: 음성 청크 (streaming)

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

지연 분해

단계	일반	최적
STT (Whisper 등)	200-500ms	50ms (streaming + local)
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
LLM TTFT (first token)	200-800ms	100ms (cached prefix)
TTS (first audio)	100-300ms	50ms (streaming)
RAG overhead	200-1000ms	< 100ms

지연 예산 할당

flowchart LR
    Budget["총 예산\n1500ms"] --> STT_b["STT\n100ms"]
    Budget --> RAG_b["RAG\n100ms"]
    Budget --> LLM_b["LLM TTFT\n200ms"]
    Budget --> TTS_b["TTS first audio\n100ms"]
    Budget --> Margin["마진\n1000ms"]

VAD (Voice Activity Detection)

발화 시작/종료를 감지하는 첫 단계. End-of-Speech 감지 정확도가 UX 를 결정합니다.

import webrtcvad

class VADHandler:
    def __init__(self, aggressiveness: int = 3, sample_rate: int = 16000):
        self.vad = webrtcvad.Vad(aggressiveness)  # 0~3, 3 = 가장 민감
        self.sample_rate = sample_rate
        self.frame_ms = 30  # 10, 20, 30ms 중 하나
        self.speech_frames: list[bytes] = []
        self.silence_count = 0
        self.SILENCE_THRESHOLD = 20  # 연속 silence frame 수

    def process_frame(self, frame: bytes) -> str | None:
        """Return 'START', 'CONTINUE', 'END', or None"""
        is_speech = self.vad.is_speech(frame, self.sample_rate)
        if is_speech:
            self.silence_count = 0
            self.speech_frames.append(frame)
            return "CONTINUE"
        else:
            self.silence_count += 1
            if self.silence_count >= self.SILENCE_THRESHOLD and self.speech_frames:
                audio = b"".join(self.speech_frames)
                self.speech_frames = []
                return "END"  # 발화 종료
        return None

예측적 프리페치 (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.

Streaming TTS 패턴

LLM 응답을 기다렸다가 한번에 TTS 에 넘기면 추가 지연이 발생합니다. 토큰 단위로 스트리밍해 첫 문장이 완성되는 즉시 TTS 를 시작합니다.

async def stream_response(llm_stream, tts_client):
    """LLM 토큰을 문장 단위로 누적, 문장 완성 즉시 TTS 로 전달"""
    buffer = ""
    SENTENCE_END = {".", "!", "?", "。", "！", "？"}

    async for token in llm_stream:
        buffer += token
        # 문장 끝 감지
        if buffer and buffer[-1] in SENTENCE_END:
            sentence = buffer.strip()
            if sentence:
                # 문장 완성 즉시 TTS 트리거 (비동기)
                asyncio.create_task(tts_client.speak(sentence))
            buffer = ""

    # 남은 텍스트 처리
    if buffer.strip():
        await tts_client.speak(buffer.strip())

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

짧은 청크는 검색 정밀도를 높이고 LLM 이 짧고 자연스러운 음성 응답을 생성하도록 유도합니다.

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 응답이 길어짐. 짧은 청크 (100-300 tokens).

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

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

VAD 미사용 = 발화 종료 감지가 느려 STT 에 불필요한 silence 포함. 지연 증가.

[!CAUTION] Semantic cache 유사도 임계값을 낮추면 오답 반환 위험이 생깁니다. 0.92 이하에서는 의미가 다른 질의의 캐시 결과를 반환할 수 있습니다. 도메인 특성에 맞게 검증 후 설정하세요.

[Prompting] One-Shot Prompting

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

One-shot prompting 은 프롬프트에 정확히 1개의 입력-출력 예시 를 함께 제공하는 프롬프팅입니다. K=1 인 [[few-shot-prompting|few-shot]] 의 특수 케이스이자 [[zero-shot-prompting|zero-shot]] 과 few-shot 사이의 경계입니다.

GPT-3 논문 (Brown et al., 2020) 이 zero-shot / one-shot / few-shot 세 축으로 실험 테이블을 구성하면서 명확한 용어로 자리잡았습니다.

In-Context Learning 스펙트럼

flowchart LR
    ZS["Zero-Shot\nK=0\n예시 없음\n지시문만"] --> OS["One-Shot\nK=1\n예시 1개"]
    OS --> FS["Few-Shot\nK=2+\n예시 2개 이상"]
    FS --> FT["Fine-Tuning\n가중치 업데이트\n별도 학습"]
    style OS fill:#f0f4ff,stroke:#4466cc

방법	예시 수	형식 강제력	비용
Zero-Shot	0	낮음	최소
One-Shot	1	중간	소폭 증가
Few-Shot	2+	높음	K 배 증가
Fine-Tuning	수천	매우 높음	학습 비용

언제 쓰나

One-shot 이 유용한 지점은 좁습니다.

출력 형식만 강제 하고 싶을 때 (JSON 스키마, 특정 어투)
예시 하나로 충분한 단순 매핑 (레이블 몇 개 안 되는 분류, 도메인 없는 정렬 등)
컨텍스트 예산이 빡빡 해서 예시를 더 많이 못 넣을 때
파일럿 실험: few-shot 으로 확장하기 전에 K=1 로 형식만 맞춰 보기

기본 구조

{지시문}

Input: {예시 입력}
Output: {예시 출력}

Input: {실제 질의}
Output:

Chat API 에서는 user/assistant 각 1회 왕복 예시:

[
  {"role": "system", "content": "다음 문장을 formal 한국어로 다시 써 주세요."},
  {"role": "user", "content": "야 이거 어떻게 해?"},
  {"role": "assistant", "content": "이것을 어떻게 처리하면 좋을까요?"},
  {"role": "user", "content": "{실제 입력}"}
]

Zero-Shot / Few-Shot 과 비교

축	Zero-shot	One-shot	Few-shot
예시 수	0	1	2 이상
형식 강제력	낮음 (지시문만)	중간	높음
도메인 규칙 학습	안 됨	어렵	가능
입력 비용	최소	소폭 증가	K 배 증가
Recency bias	없음	유일한 예시 = 강한 앵커	마지막 예시 편중

핵심: One-shot 예시는 유일하므로 그 자체가 강한 앵커 로 작용합니다. Recency bias 를 다양화로 완화할 방법이 없어, 예시가 대표성을 잃으면 오히려 zero-shot 보다 성능이 나빠질 수 있습니다.

Min et al. 재조명

Min et al. (2022) “Rethinking the Role of Demonstrations” 결과가 one-shot 에도 적용됩니다:

예시의 입력 도메인 이 실제 질의와 다르면 큰 손해
예시의 라벨 을 랜덤으로 바꿔도 성능이 크게 안 떨어지는 경우 (형식 시그널이 지배)
예시가 형식 스펙만 알려주고 실제 규칙은 지시문이 전달

이는 one-shot 에서 특히 강하게 나타납니다: 한 예시가 모든 신호를 담당하기 때문.

Chain-of-Thought 와 결합

One-shot + [[chain-of-thought|CoT]] 는 흔한 조합. 사슬 예시 1개를 넣어 형식과 추론 스타일 모두 유도:

Q: If a train leaves at 3pm and travels 60 mph for 2 hours, where is it?
A: The train travels 60 miles per hour. After 2 hours it has gone 60 * 2 = 120 miles.
   The answer is 120 miles from the start.

Q: {question}
A:

이 방식이 zero-shot CoT (“Let’s think step by step”) 보다 정확도가 높을 때가 많습니다. 형식과 사슬 스타일을 모두 명시하기 때문.

예시 선택 기준

One-shot 은 예시 하나가 결과를 좌우하므로 선택이 매우 중요합니다.

대표성: 실제 질의 분포의 중앙에 있는 예시
정보량: 지시문에서 놓친 규칙을 예시가 채워줌
간결성: 너무 긴 예시는 컨텍스트 낭비 + 모델 주의 분산
명확한 라벨: 애매한 경계 케이스는 오히려 혼선

프로덕션에서는 입력을 임베딩해 유사도 top-1 예시 를 동적으로 선택하는 retrieval-based one-shot 이 실전에서 강합니다.

실전 예시

감성 분류

prompt = """Classify the sentiment of the review as Positive or Negative.

Review: "The food was absolutely amazing and the staff was super friendly!"
Sentiment: Positive

Review: "{review}"
Sentiment:"""

구조화 출력 (JSON 스키마 강제)

prompt = """Extract the key information from the meeting note as JSON.

Note: "Team sync on Jan 5. Attendees: Alice, Bob. Action items: Alice to send report by Jan 10."
JSON: {"date": "Jan 5", "attendees": ["Alice", "Bob"], "action_items": [{"owner": "Alice", "task": "send report", "due": "Jan 10"}]}

Note: "{meeting_note}"
JSON:"""

코드 변환 (Python to TypeScript)

prompt = """Convert the Python function to TypeScript.

Python:
def add(a: int, b: int) -> int:
    return a + b

TypeScript:
function add(a: number, b: number): number {
    return a + b;
}

Python:
{python_code}

TypeScript:"""

Retrieval-Based One-Shot (동적 예시 선택)

정적으로 예시를 고르지 않고, 입력과 가장 유사한 예시를 예시 풀에서 검색해 삽입. [[llm-rag|RAG]] 와 결합한 패턴이다.

from sentence_transformers import SentenceTransformer
import numpy as np

model = SentenceTransformer("all-MiniLM-L6-v2")

# 예시 풀 (질의, 정답) 쌍
example_pool = [
    ("What is the capital of France?", "The capital of France is Paris."),
    ("How do I sort a list in Python?", "Use list.sort() or sorted(list)."),
    # ... 수백~수천 개
]

# 오프라인: 예시 임베딩
example_embeddings = model.encode([ex[0] for ex in example_pool])

def select_one_shot_example(query: str) -> tuple[str, str]:
    q_emb = model.encode([query])
    scores = np.dot(example_embeddings, q_emb.T).squeeze()
    best_idx = scores.argmax()
    return example_pool[best_idx]

query = "What is the tallest mountain in the world?"
ex_input, ex_output = select_one_shot_example(query)

prompt = f"""Answer the geography question.

Q: {ex_input}
A: {ex_output}

Q: {query}
A:"""

One-Shot 결정 플로우

flowchart TD
    Start["새 프롬프트 설계"] --> Q1{"출력 형식만\n강제하면 되나?"}
    Q1 -->|Yes| Q2{"structured output\nAPI 지원?"}
    Q2 -->|Yes| SO["response_format / JSON schema\n(One-shot 불필요)"]
    Q2 -->|No| OS["One-Shot 사용"]
    Q1 -->|No| Q3{"도메인 규칙\n학습 필요?"}
    Q3 -->|No| OS
    Q3 -->|Yes| Q4{"컨텍스트 예산?"}
    Q4 -->|"빡빡"| OS
    Q4 -->|"여유 있음"| FS["Few-Shot (K>=3)"]

언제 One-shot 이 최적인가

예시가 실제 질의와 매우 유사할 때 (retrieval-augmented one-shot)
지시문 + 예시 조합이 API 응답 스키마를 명확히 고정할 때
CoT 스타일을 정확히 지정하고 싶을 때 (사슬 예시 1개)
컨텍스트 예산이 매우 제한적 (모바일 온디바이스 등)

함정

[!WARNING] 잘못된 예시는 zero-shot 보다 나쁩니다. 지시문에는 없는 이상한 형식/스타일을 예시가 강제하면 모델이 그것을 따라갑니다. One-shot 은 그 예시가 유일한 신호이므로 잘못된 예시의 영향이 특히 큽니다.

[!CAUTION] 엣지 케이스를 커버 못 합니다. 한 예시로 모든 케이스를 담을 수 없어, 예상 밖 입력에는 모델이 형식만 따르고 규칙은 놓치는 경우가 자주 발생합니다.

[!IMPORTANT] Instruction-tuned 최신 모델 (GPT-4o, Claude 3.5+, Gemini 2.0+) 에서는 zero-shot 만으로 충분한 경우가 많아졌습니다. 형식 강제가 목표라면 one-shot 대신 structured output (response_format, JSON schema) 을 쓰는 편이 안정적입니다.

Function Calling / Tool Use: LLM 도구 사용

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

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

실제 함수 실행은 LLM 이 아닌 애플리케이션 코드가 담당. LLM 은 오직 “어떤 함수를, 어떤 인자로 호출할지” 만 결정한다.

언제 쓰이나

외부 API 연동 (날씨, 주식, 검색)
데이터베이스 쿼리 자동화
LLM 이 직접 수행 불가능한 작업 (계산, 코드 실행, 파일 읽기)
[[agent-patterns|AI 에이전트]] 구현 (ReAct, Plan-and-Execute)
구조화된 데이터 추출

전체 흐름

sequenceDiagram
    participant User as 사용자
    participant App as 애플리케이션
    participant LLM as LLM API
    participant Tool as 실제 도구

    User->>App: "서울 날씨 알려줘"
    App->>LLM: 메시지 + tool 정의 전송
    LLM-->>App: tool_call (get_weather, city=Seoul)
    App->>Tool: get_weather("Seoul")
    Tool-->>App: {temp: 22, condition: "sunny"}
    App->>LLM: tool 결과 재주입
    LLM-->>App: "서울은 현재 22도로 맑습니다"
    App-->>User: 최종 답변

JSON Schema 로 도구 정의

OpenAI 형식

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "특정 도시의 현재 날씨 조회. 도시명은 영어로.",
    "parameters": {
      "type": "object",
      "properties": {
        "city": {
          "type": "string",
          "description": "도시 이름 (예: Seoul, Tokyo)"
        },
        "unit": {
          "type": "string",
          "enum": ["C", "F"],
          "description": "온도 단위",
          "default": "C"
        }
      },
      "required": ["city"],
      "additionalProperties": false
    },
    "strict": true
  }
}

Anthropic (Claude) 형식

{
  "name": "get_weather",
  "description": "특정 도시의 현재 날씨 조회",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string" },
      "unit": { "type": "string", "enum": ["C", "F"] }
    },
    "required": ["city"]
  }
}

[!TIP] description 이 가장 중요하다. LLM 은 description 을 읽고 어떤 도구를 언제 호출할지 결정. 명확하고 구체적인 설명이 할루시네이션을 줄인다.

OpenAI vs Anthropic vs Gemini 비교

항목	OpenAI	Anthropic Claude	Google Gemini
필드명	`tools`, `function`	`tools`, `input_schema`	`tools`, `function_declarations`
결과 전달	`tool_call_id` + `role: tool`	`tool_use_id` + `role: user`	`function_response`
병렬 호출	`tool_calls[]` (배열)	응답에 여러 `tool_use`	`function_calls[]`
strict mode	`"strict": true` (JSON 강제)	없음	없음
멀티턴	`tool_call_id` 로 매칭	`tool_use_id` 로 매칭	`id` 로 매칭

실전 코드

OpenAI Python SDK

from openai import OpenAI
import json

client = OpenAI()

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "현재 날씨 조회",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string"},
                    "unit": {"type": "string", "enum": ["C", "F"]}
                },
                "required": ["city"]
            }
        }
    }
]

def get_weather(city: str, unit: str = "C") -> dict:
    # 실제 날씨 API 호출
    return {"temp": 22, "condition": "sunny", "city": city}

# 1단계: LLM 호출
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "서울 날씨 알려줘"}],
    tools=tools,
    tool_choice="auto"
)

message = response.choices[0].message

# 2단계: tool_calls 처리
if message.tool_calls:
    messages = [
        {"role": "user", "content": "서울 날씨 알려줘"},
        message,  # assistant 의 tool_call 메시지
    ]

    for tc in message.tool_calls:
        args = json.loads(tc.function.arguments)
        result = get_weather(**args)
        messages.append({
            "role": "tool",
            "tool_call_id": tc.id,
            "content": json.dumps(result, ensure_ascii=False)
        })

    # 3단계: 결과 재주입 후 최종 답변
    final = client.chat.completions.create(
        model="gpt-4o",
        messages=messages
    )
    print(final.choices[0].message.content)

Anthropic Python SDK

import anthropic
import json

client = anthropic.Anthropic()

tools = [
    {
        "name": "get_weather",
        "description": "현재 날씨 조회",
        "input_schema": {
            "type": "object",
            "properties": {
                "city": {"type": "string"},
            },
            "required": ["city"]
        }
    }
]

response = client.messages.create(
    model="claude-opus-4-5",
    max_tokens=1024,
    tools=tools,
    messages=[{"role": "user", "content": "서울 날씨 알려줘"}]
)

# stop_reason == "tool_use" 인 경우 처리
if response.stop_reason == "tool_use":
    tool_use = next(b for b in response.content if b.type == "tool_use")
    result = get_weather(**tool_use.input)

    final = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=1024,
        tools=tools,
        messages=[
            {"role": "user", "content": "서울 날씨 알려줘"},
            {"role": "assistant", "content": response.content},
            {
                "role": "user",
                "content": [{
                    "type": "tool_result",
                    "tool_use_id": tool_use.id,
                    "content": json.dumps(result, ensure_ascii=False)
                }]
            }
        ]
    )

병렬 Tool Call

LLM 이 여러 도구를 동시에 호출해야 할 때 배열로 반환:

{
  "tool_calls": [
    {"id": "call_1", "function": {"name": "get_weather", "arguments": "{\"city\": \"Seoul\"}"}},
    {"id": "call_2", "function": {"name": "get_weather", "arguments": "{\"city\": \"Tokyo\"}"}},
    {"id": "call_3", "function": {"name": "get_stock",  "arguments": "{\"symbol\": \"AAPL\"}"}}
  ]
}

병렬로 실행 후 결과를 한꺼번에 재주입:

import asyncio

async def handle_parallel_tools(tool_calls):
    tasks = []
    for tc in tool_calls:
        args = json.loads(tc.function.arguments)
        if tc.function.name == "get_weather":
            tasks.append(get_weather_async(**args))
        elif tc.function.name == "get_stock":
            tasks.append(get_stock_async(**args))
    return await asyncio.gather(*tasks)

MCP (Model Context Protocol)

Anthropic 이 2024년 발표한 표준화 프로토콜. Function calling 의 생태계 문제(각 공급사마다 다른 형식)를 해결.

flowchart LR
    LLM["Claude / GPT / Gemini"] <-->|"MCP 프로토콜"| Server["MCP Server"]
    Server --> FS["파일 시스템"]
    Server --> DB["데이터베이스"]
    Server --> API["외부 API"]
    Server --> Git["Git / GitHub"]

MCP 의 특징:

표준 클라이언트-서버: LLM 이 MCP client, 도구 공급자가 MCP server
stdio / HTTP 전송: 로컬 프로세스 또는 원격 서버
세 가지 원시(primitive): tools (함수), resources (파일/데이터), prompts (프롬프트 템플릿)
인증: OAuth 2.0 지원

MCP 서버 예시 (Python)

from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp import types

server = Server("weather-server")

@server.list_tools()
async def list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="get_weather",
            description="현재 날씨 조회",
            inputSchema={
                "type": "object",
                "properties": {"city": {"type": "string"}},
                "required": ["city"]
            }
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict) -> list[types.Content]:
    if name == "get_weather":
        city = arguments["city"]
        weather = await fetch_weather(city)  # 실제 API
        return [types.TextContent(type="text", text=str(weather))]

async def main():
    async with stdio_server() as (read, write):
        await server.run(read, write, server.create_initialization_options())

Agent 루프 패턴

Function Calling 을 반복 사용하는 [[agent-patterns|에이전트 패턴]]:

flowchart TD
    Start["사용자 요청"] --> Think["LLM: 생각 (Thought)"]
    Think --> Decide{도구 필요?}
    Decide -->|"Yes"| Call["도구 호출"]
    Call --> Observe["결과 관찰 (Observation)"]
    Observe --> Think
    Decide -->|"No"| Answer["최종 답변"]

이 패턴이 ReAct (Reasoning + Acting). LangChain, LlamaIndex, Claude Code 등이 내부적으로 사용.

JSON Schema 베스트 프랙티스

{
  "name": "search_products",
  "description": "상품 검색. 반드시 카테고리를 지정해야 정확한 결과 반환.",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "검색어 (한국어 가능)"
      },
      "category": {
        "type": "string",
        "enum": ["electronics", "clothing", "food", "books"],
        "description": "상품 카테고리. 모르면 'electronics' 기본값 사용."
      },
      "max_price": {
        "type": "number",
        "description": "최대 가격 (원화). 제한 없으면 null."
      },
      "page": {
        "type": "integer",
        "minimum": 1,
        "default": 1
      }
    },
    "required": ["query", "category"]
  }
}

주요 원칙:

description 이 핵심: LLM 은 description 으로 판단. 누락 시 오호출 급증
enum 활용: 자유 텍스트 대신 enum 으로 범위 제한
required 최소화: 선택 필드는 LLM 이 생략 가능 (default 활용)
additionalProperties: false: 정의 안 된 필드 차단 (strict mode)

흔한 함정

[!WARNING]

오호출 (Hallucinated call): LLM 이 없는 함수 호출 시도. 반드시 name 검증 후 실행.

인자 할루시네이션: 필수 필드 누락, enum 외 값 반환. JSON Schema 검증 레이어 필수 (jsonschema 라이브러리).

무한 루프: 도구 결과 → 다음 도구 호출 반복. 최대 반복 횟수 제한 설정.

도구 스펙이 너무 큼: 도구 정의만으로 수천 토큰 소비. 도구 수 최소화 (7-10개 이하 권장).

결과 미검증: 도구가 반환한 데이터를 그대로 LLM 에 재주입. XSS/injection 위험. 결과 sanitize 필수.

tool_choice=“required” 오남용: LLM 이 항상 도구를 호출하도록 강제 → 필요 없는 상황에서도 호출.

LLM RAG: Retrieval-Augmented Generation

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

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

LLM 파인튜닝 대신 검색으로 외부 지식을 주입하므로 추가 학습 비용 없이 최신 정보를 반영할 수 있다.

왜 필요한가

최신 정보: LLM 학습 컷오프 이후 지식 (뉴스, 법령 개정 등)
도메인 데이터: 회사 내부 문서, 개인 지식 베이스
hallucination 감소: 검색된 “출처” 를 명시해 사실성 검증 가능
비용 절감: 파인튜닝 대비 데이터 갱신이 쉬움 (벡터 DB 업서트만 하면 됨)

파이프라인 전체 흐름

flowchart LR
    Q["사용자 질의"] --> E["쿼리 임베딩\n(Embedding Model)"]
    E --> V["벡터 DB 검색\n(ANN 인덱스)"]
    V --> R["상위 K 문서 검색\n(Dense / Sparse / Hybrid)"]
    R --> RR["Reranker\n(Cross-encoder)"]
    RR --> P["프롬프트 조합\nContext + Question"]
    P --> L["LLM\n(GPT-4o, Claude, Gemini)"]
    L --> A["최종 답변"]

인덱싱 파이프라인 (오프라인)

flowchart LR
    D["원본 문서\n(PDF, HTML, DB)"] --> C["Chunking\n500-1000 tokens"]
    C --> EM["Embedding 모델\nbge-large, text-embedding-3"]
    EM --> VS["Vector Store\n(Pinecone, pgvector, Qdrant)"]

핵심 구성 요소

1. 문서 Chunking 전략

문서를 청크 단위로 분할. 청크 크기와 전략이 검색 품질에 직결된다.

전략	크기	장점	단점
고정 크기	500 tokens	단순	문맥 경계에서 끊김
슬라이딩 윈도우	500 + 50 overlap	문맥 손실 최소화	중복 저장
문단/섹션 기반	가변	의미 단위 유지	크기 불균일
계층적 chunking	문단 + 섹션	요약 + 상세 동시	복잡한 인덱싱

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50,
    separators=["\n\n", "\n", ".", " ", ""],
)
chunks = splitter.split_text(document)

2. Embedding 모델

각 청크를 고밀도 벡터 (dense vector) 로 변환. 의미적으로 유사한 텍스트는 벡터 공간에서 가깝게 위치한다.

모델	차원	언어	특징
`text-embedding-3-small`	1536	다국어	OpenAI, 저비용
`text-embedding-3-large`	3072	다국어	OpenAI, 고성능
`bge-large-en-v1.5`	1024	영어	오픈소스, MTEB 상위
`bge-m3`	1024	다국어	오픈소스, 한국어 우수
`nomic-embed-text`	768	영어	오픈소스, 로컬 실행 가능

from openai import OpenAI

client = OpenAI()

def embed(text: str) -> list[float]:
    response = client.embeddings.create(
        model="text-embedding-3-small",
        input=text,
    )
    return response.data[0].embedding

3. Vector Store

임베딩 벡터를 저장하고 ANN (Approximate Nearest Neighbor) 검색을 제공하는 데이터베이스.

솔루션	유형	특징
Pinecone	관리형	완전 관리, 서버리스 플랜
Qdrant	오픈소스	Rust, 고성능, 페이로드 필터
Weaviate	오픈소스	멀티벡터, GraphQL
Milvus	오픈소스	대규모, CNCF 프로젝트
pgvector	PostgreSQL 확장	기존 PG 통합, HNSW 지원
**[[redis-vector-search	Redis Vector Search]]**	Redis 모듈

# pgvector 예시
import psycopg2
from pgvector.psycopg2 import register_vector

conn = psycopg2.connect("postgresql://...")
register_vector(conn)

cursor = conn.cursor()
cursor.execute("""
    SELECT content, embedding <=> %s AS distance
    FROM documents
    ORDER BY distance
    LIMIT 5
""", (query_embedding,))
results = cursor.fetchall()

4. Retrieval 방법

방법	설명	장점
Dense (벡터)	코사인 유사도, HNSW	의미적 유사성
Sparse (BM25)	단어 빈도 기반	정확한 키워드 매칭
Hybrid	Dense + Sparse 결합 (RRF)	양쪽 장점
Reranker	Cross-encoder 재순위	정확도 향상

RRF (Reciprocal Rank Fusion): Dense 와 Sparse 검색 결과 순위를 합산해 최종 순위 산출. 별도 학습 없이 Hybrid 효과.

5. Reranker

Dense 검색으로 상위 20-50개를 뽑은 뒤, Cross-encoder 모델로 질의-문서 쌍을 직접 스코어링해 재순위한다.

cross-encoder/ms-marco-MiniLM-L-12-v2 (오픈소스)
Cohere Rerank API (관리형)

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-12-v2")

pairs = [(query, doc) for doc in candidate_docs]
scores = reranker.predict(pairs)
ranked_docs = [doc for _, doc in sorted(zip(scores, candidate_docs), reverse=True)]
top_k = ranked_docs[:5]

6. Prompt Composition

검색된 문서를 LLM 프롬프트에 조합.

You are a helpful assistant. Answer the question based ONLY on the provided context.
If the answer is not in the context, say "I don't know."

Context:
[Document 1]: {chunk_1}
[Document 2]: {chunk_2}
[Document 3]: {chunk_3}

Question: {user_query}
Answer:

고급 RAG 패턴

HyDE (Hypothetical Document Embeddings)

질의를 임베딩하는 대신, LLM 이 “가상의 답변” 을 먼저 생성한 뒤 그 답변을 임베딩해 검색. 질의와 문서 간 임베딩 공간 불일치 문제를 완화한다.

hypothesis = llm.generate(f"Write a hypothetical answer to: {query}")
hypothesis_embedding = embed(hypothesis)
results = vector_store.search(hypothesis_embedding, k=5)

Multi-Query Rewriting

질의를 여러 관점으로 재작성해 다수의 검색 결과를 합산.

queries = llm.generate(f"Rewrite the following query from 3 different perspectives:\n{query}")
all_results = [vector_store.search(q) for q in queries]
# RRF 로 합산

Query Routing

질의 종류에 따라 다른 인덱스나 도구로 라우팅.

flowchart TD
    Q["사용자 질의"] --> R["Router LLM"]
    R -->|"최신 뉴스"| WS["웹 검색 도구"]
    R -->|"내부 문서"| VS["내부 Vector DB"]
    R -->|"계산 필요"| CALC["계산기 도구"]
    R -->|"일반 질의"| LLM2["LLM 직접 답변"]

평가 지표

지표	측정 대상
Recall@K	K 개 검색 결과에 정답 포함 비율
MRR	Mean Reciprocal Rank, 정답 순위
Faithfulness	답변이 컨텍스트에 근거한 정도
Answer Relevance	답변이 질의에 적절한 정도
Context Precision	검색된 문서 중 관련 비율

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_recall

result = evaluate(
    dataset=test_dataset,
    metrics=[faithfulness, answer_relevancy, context_recall],
)
print(result)

함정

[!WARNING] 청크 경계에서 문맥이 잘린다. 고정 크기 chunking 은 문장 중간이나 표 안에서 잘릴 수 있다. 슬라이딩 윈도우 (overlap) 나 문단 기반 chunking 으로 보완해야 한다.

[!CAUTION] Reranker 후보군이 부족하면 역효과. Dense 검색 1차 후보를 top-5 만 뽑으면, 실제 정답이 애초에 후보에 없을 수 있다. 1차 검색은 top-20 이상, Reranker 로 top-5 압축하는 패턴이 일반적이다.

[!IMPORTANT] RAG 는 hallucination 을 줄이지 무조건 없애지 않는다. LLM 이 컨텍스트를 무시하고 학습 지식을 사용하는 경우가 있다. “컨텍스트에만 근거해 답하라” 지시 + Faithfulness 평가로 지속 모니터링이 필요하다.

[Prompting] Chain-of-Thought (CoT)

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

Chain-of-Thought (CoT) prompting 은 대형 언어 모델이 최종 답을 내기 전에 중간 추론 단계를 자연어로 생성하도록 유도 하는 프롬프팅 기법입니다. 산술, 상식, 논리, 다단계 질문 응답 등 다단계 추론이 필요한 태스크에서 정확도를 크게 향상 시킵니다.

Wei et al. (Google Brain) 이 2022년 1월 논문에서 처음 체계화했고, GSM8K (초등 산술 문장 문제) 에서 PaLM 540B 의 정확도를 17.9% → 58.1% 로 끌어올린 결과가 인상적이었습니다.

왜 필요한가

기존 few-shot prompting 은 입력 → 답 을 그대로 요구했는데, 다단계 계산이 필요한 문제에서는 모델이 중간 사고를 생략한 채 답만 뱉으며 자주 틀렸습니다. CoT 는 모델이 사람이 문제를 푸는 순서 (읽고, 정리하고, 계산하고, 결론) 를 언어로 명시적으로 서술 하게 만들어, 이 서술 자체가 다음 토큰 예측의 문맥이 되어 정확도가 오른다는 발견입니다.

기본 예시 (Few-shot CoT)

표준 few-shot (틀림):

Q: Roger has 5 tennis balls. He buys 2 more cans of tennis balls.
   Each can has 3 tennis balls. How many tennis balls does he have now?
A: 11.

Q: The cafeteria had 23 apples. If they used 20 to make lunch and bought 6 more,
   how many apples do they have?
A: 27.   ← 오답 (정답 9)

Chain-of-Thought (정답):

Q: Roger has 5 tennis balls. He buys 2 more cans of tennis balls.
   Each can has 3 tennis balls. How many tennis balls does he have now?
A: Roger started with 5 balls. 2 cans of 3 tennis balls each is 6 balls.
   5 + 6 = 11. The answer is 11.

Q: The cafeteria had 23 apples. If they used 20 to make lunch and bought 6 more,
   how many apples do they have?
A: The cafeteria started with 23 apples. They used 20, so 23 - 20 = 3.
   Then they bought 6 more, so 3 + 6 = 9. The answer is 9.   ← 정답

같은 예시 개수, 같은 모델, 형식만 바꿨는데 정답률이 오릅니다.

Zero-shot CoT

Kojima et al. (2022) 는 예시 없이 지시문만 으로도 CoT 를 유도할 수 있음을 보였습니다.

프롬프트 끝에 다음 마법 문장을 붙입니다:

Q: {question}
A: Let's think step by step.

이 한 줄이 InstructGPT-003 의 MultiArith 정확도를 17.7% → 78.7% 로 끌어올렸습니다. 한국어에서는 “차근차근 생각해 봅시다” 또는 “단계별로 풀이해 봅시다” 등으로 옮깁니다.

두 단계 프롬프트 (two-stage) 로 쓰기도 합니다:

Reasoning extraction: “Let’s think step by step” 으로 추론 생성
Answer extraction: 위 추론을 이어 붙이고 “Therefore, the answer is” 로 답만 추출

창발성 (emergent ability)

Wei et al. 논문의 핵심 관찰: CoT 는 일정 규모 이상 에서만 효과가 나타납니다.

~62B 이하 모델: CoT 가 오히려 성능을 떨어뜨림 (틀린 추론을 확신 있게 씀)
~62B 이상: CoT 로 정확도 급상승 (특히 100B+ 에서 gap 이 커짐)

이것이 “emergent abilities” 논쟁의 대표 사례입니다 (Schaeffer et al. 2023 이 metric artifact 라고 반박한 논문도 있음). 실제로 오늘날 소형 모델도 instruction tuning + CoT-style SFT 를 거치면 CoT 를 어느 정도 흉내낼 수 있어, “임계 규모” 는 절대적이지 않습니다.

주요 확장

Self-Consistency (Wang et al., 2022)

CoT 한 번만 샘플링하지 말고, temperature > 0 으로 여러 개 (예: 40 개) 샘플링 후 최종 답을 다수결 로 뽑습니다.

$$ \hat{y} = \arg\max_y \sum_{i=1}^{N} \mathbb{1}[\text{answer}(z_i) = y] $$

여기서 $z_i$ 는 $i$ 번째 chain-of-thought, $\text{answer}(z_i)$ 는 그 chain 의 최종 답. GSM8K 에서 PaLM 의 성능이 SC 로 74.4% → 스코어링 대폭 개선.

Least-to-Most (Zhou et al., 2022)

문제 분해 후 순차 해결. 프롬프트 두 개:

Decomposition: “이 문제를 더 쉬운 하위 문제로 나눠 봐”
Solving: 하위 문제를 순서대로 풀고 답을 다음 하위 문제에 참조

Compositional generalization (긴 조합 문제) 에서 CoT 를 크게 상회.

Tree of Thoughts (Yao et al., 2023)

CoT 는 선형 사슬. ToT 는 여러 추론 분기 를 탐색합니다. 각 노드에서 여러 다음 스텝을 생성하고 self-evaluation 으로 점수를 매긴 뒤 BFS/DFS 로 탐색. Game of 24, Creative Writing 등에서 강함.

Program-Aided (PAL, PoT)

자연어 대신 Python 코드 로 중간 추론을 씁니다. 계산은 언어 모델이 아니라 인터프리터가 실행 -> 산술 오류가 원천 차단.

# Q: A juggler can juggle 16 balls. Half of them are golf balls,
#    and half of the golf balls are blue. How many blue golf balls?
total_balls = 16
golf_balls = total_balls / 2
blue_golf_balls = golf_balls / 2
answer = blue_golf_balls   # 4

Auto-CoT (Zhang et al., 2022)

예시를 사람이 손으로 만들지 않고, 클러스터링 + Zero-shot CoT 로 자동 생성한 예시를 few-shot 에 삽입. 사람 수작업 비용 절감.

ReAct (Yao et al., 2022)

Reasoning + Acting. CoT 사이에 도구 호출 (검색, 계산기, API) 을 끼워 넣습니다. 오늘날 [[function-calling|Function Calling]] 기반 agent 의 원류.

2024-2025 진화: Reasoning models

CoT 를 사후 학습 (RL) 으로 내재화하고, 추론 시 훨씬 길고 정교한 사슬을 생성하도록 훈련한 계열이 등장했습니다.

OpenAI o1 / o3 / o4-mini (2024-2025): 강화학습으로 CoT 능력 향상, hidden reasoning tokens 로 답 이전에 광범위한 내부 사슬 소비
DeepSeek-R1 (2025): 오픈웨이트 reasoning model, PPO/GRPO 로 CoT 학습
Claude 3.7 / 4 Extended Thinking: 사용자에게 노출 가능한 thinking tokens
Gemini 2.5 Thinking

이 계열에서는 프롬프트에 “step by step” 을 굳이 붙일 필요가 없습니다. 모델이 이미 알아서 확장 추론합니다. 오히려 지시가 이중이 되면 사슬이 산만해질 수 있습니다.

함정

[!WARNING] CoT 는 정확도를 항상 올리지 않습니다. 태스크가 사실 조회 (facts), 스타일 변환, 짧은 감정 분류 등 단발성 답변에 가까운 태스크 라면 CoT 가 오히려 노이즈를 늘려 정확도가 떨어질 수 있습니다.

[!CAUTION] CoT 는 사후 정당화 (post-hoc rationalization) 를 할 수 있습니다. 모델이 먼저 답을 내리고, 그럴듯한 사슬을 만들어 맞춰 쓰는 경우가 관측됩니다. 사슬이 논리적으로 완결돼 보인다고 실제 그렇게 추론했다고 신뢰하면 안 됩니다 (Turpin et al. 2023 “Language Models Don’t Always Say What They Think”).

[!IMPORTANT] 비용 팽창. 다단계 사슬은 출력 토큰이 늘어 API 요금이 몇 배 커집니다. Self-Consistency 는 여기에 샘플 수 배수를 더 곱합니다. 프로덕션에서는 답만 필요한 경우 사슬을 max_tokens 로 잘라내는 것이 아니라, 요약된 최종 답을 뽑는 answer extraction 을 별도로 두는 편이 안전합니다.

[!WARNING] 작은 모델에는 역효과 였다는 초기 관찰 (Wei 2022) 이 여전히 부분적으로 유효합니다. SLM (< 10B) 에는 CoT 를 유도하는 대신 instruction-tuned SFT 데이터에 이미 CoT-style 응답이 포함되어 있는지가 관건입니다.

실전 팁

예시 개수: 4-8 shot 이 대개 최적. 그 이상은 return diminishing.
예시 순서: 최근 예시가 답에 큰 영향 (recency bias). 다양한 라벨을 섞습니다.
분리 구분자: Q: / A: 형식 또는 messages array 로 role 분리.
답 추출: 정규식으로 최종 숫자만 뽑기 ( ... The answer is (\d+) 등).
temperature: 단답 CoT 는 0-0.3, Self-Consistency 는 0.5-0.8.
평가는 sample 여러 개 평균: CoT 는 분산이 큽니다. n=3~5 로 여러 번 돌린 평균이 신뢰할 만합니다.

CoT 변형 계보

flowchart TD
    Std[Standard Few-shot]
    CoT["Few-shot CoT (Wei 2022)"]
    ZSCoT["Zero-shot CoT (Kojima 2022)"]
    SC["Self-Consistency (Wang 2022)"]
    LtM["Least-to-Most (Zhou 2022)"]
    ToT["Tree of Thoughts (Yao 2023)"]
    PAL["PAL / PoT (Gao 2022)"]
    ReAct["ReAct (Yao 2022)"]
    RM["Reasoning Models (o1/R1/Claude)"]

    Std --> CoT
    Std --> ZSCoT
    CoT --> SC
    CoT --> LtM
    CoT --> ToT
    CoT --> PAL
    CoT --> ReAct
    SC --> RM
    ToT --> RM
    ReAct --> RM

위 계보는 논문 발표 순서를 대략 반영합니다. 하위로 내려갈수록 추론 구조가 복잡해지며, “Reasoning Models” 계열에서는 이 기법들이 강화학습으로 내재화됩니다.

벤치마크별 CoT 효과

CoT 가 특히 효과적인 태스크와 그렇지 않은 태스크:

벤치마크	태스크 성격	CoT 효과
GSM8K	초등 산술 문장 문제	매우 큼: PaLM 540B 17.9% → 58.1%
MATH	고등 수학 경시 문제	큼: 다단계 증명에 적합
ARC-Challenge	4지선다 과학	중간: Self-Consistency 병행 시 효과적
StrategyQA	암묵적 다단계 추론	큼
CommonsenseQA	상식 추론	중간
HotpotQA	다단계 Wikipedia 추론	큼
TriviaQA	단순 사실 조회	거의 없음
NaturalQuestions	단순 사실 조회	없음 또는 음수

단순 사실 조회에서 CoT 가 오히려 노이즈를 늘려 정확도가 낮아지는 케이스도 관측됩니다.

프롬프트 구성 흐름

flowchart LR
    U[사용자 질문] --> PB[프롬프트 빌더]
    PB --> E1["예시 1: Q + 추론 + A"]
    PB --> E2["예시 2: Q + 추론 + A"]
    PB --> TQ[대상 질문]
    TQ --> LLM[LLM 생성]
    LLM --> CH[중간 추론 사슬]
    CH --> AE[답 추출]
    AE --> OUT[최종 답]

two-stage 방식에서는 1단계에서 사슬만 생성하고, 2단계에서 사슬을 붙여 “따라서 답은” 형태로 답만 추출합니다. 이렇게 하면 답 파싱이 안정적이고 출력 길이를 제어하기 쉽습니다.

Self-Consistency 샘플링 전략

샘플 수	temperature	권장 상황
5	0.5	빠른 검증, 비용 절감 우선
20	0.7	중간 신뢰도, 프로덕션 일반
40	0.7-0.8	논문 수준 평가, 비용 큼

다수결 집계는 numeric answer 에만 정규식으로 추출합니다. 자유 형식 답변에는 LLM-as-judge 로 별도 합의를 구합니다.

프로덕션 구현 체크리스트

answer extraction: 최종 답만 파싱 (정규식 또는 extraction prompt 분리)
max_tokens 설정: 사슬이 너무 길면 잘림 방지를 위해 여유분 확보
fallback: CoT 사슬이 비어 오면 zero-shot 재시도
응답 캐시: 동일 질문 반복이면 CoT 결과 캐시로 비용 절감
eval 로그: temperature > 0 이므로 n=5 결과 평균으로 정확도 측정
streaming: 긴 사슬은 streaming 응답으로 사용자 경험 개선

다른 프롬프팅 기법과 관계

기법	관계
[[zero-shot-prompting	Zero-Shot Prompting]]
[[one-shot-prompting	One-Shot Prompting]]
[[few-shot-prompting	Few-Shot Prompting]]
[[function-calling	Function Calling]]
[[llm-rag	LLM RAG]]

[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 는 편향 (자기 편애, 길이 선호) 이 알려져 있습니다.

평가 파이프라인

flowchart TD
    Def["시나리오 정의"] --> Conf["run-specs.conf 작성"]
    Conf --> Run["helm-run (API 호출)"]
    Run --> Cache["결과 캐시"]
    Cache --> Sum["helm-summarize (집계)"]
    Sum --> Dash["helm-server 대시보드"]
    Dash --> Cmp["모델 비교 (7축)"]

시나리오별 추천 벤치마크

목적에 따라 집중할 시나리오가 다름.

목적	추천 시나리오	이유
지식 QA / 상식	MMLU, TruthfulQA	광범위한 도메인 지식
수학 / 추론	GSM8K, MATH	다단계 논리 추론
코드 생성	HumanEval, MBPP	실행 가능 코드
긴 문맥 처리	LongBench, SCROLLS	컨텍스트 창 활용
안전성	ToxiGen, BBQ	편향, 독성
지시 따르기	MT-Bench, AlpacaEval	대화형 assistant 품질
의료	MedQA, MedHELM	임상 추론
법률	LegalBench	법률 문서 이해

HELM 결과 해석

단일 점수 vs 프로파일

HELM 은 단일 평균 순위보다 시나리오별 프로파일을 중시. 모델 A 가 MMLU 에서 높아도 TruthfulQA 에서 낮으면 실사용 신뢰성에 문제가 됨.

신뢰 구간

단일 시드 실행 특성상 결과에 통계적 불확실성이 존재. 1-2% 차이는 의미 없을 수 있음. Elo 기반 Chatbot Arena 는 더 많은 샘플에서 통계적 신뢰도 제공.

오염 탐지 방법

# n-gram overlap 기반 간이 탐지 (13-gram 기준)
from nltk.util import ngrams as make_ngrams

def ngram_overlap(train_text: str, test_text: str, n: int = 13) -> float:
    train_set = set(make_ngrams(train_text.split(), n))
    test_set = set(make_ngrams(test_text.split(), n))
    if not test_set:
        return 0.0
    return len(train_set & test_set) / len(test_set)

# 5% 이상이면 오염 의심

대규모 스캔에는 Min-Hash 또는 Bloom filter 활용. HELM 자체는 오염 탐지 기능 없음.

참고

관련 [[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

[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)	일반

Speculative Decoding

작은 draft model 이 여러 토큰을 연속 생성하고, 큰 target model 이 한 번의 forward pass 로 전부 검증. 드래프트가 맞으면 한 번에 여러 토큰 확보, 틀리면 target 이 재생성.

flowchart LR
    D["Draft model (소형)"] -->|"토큰 N개 예측"| V["Target model (대형)"]
    V -->|"k개 수락"| OUT[출력]
    V -->|"k+1번째 거절: 재생성"| D

항목	값
적합한 draft 크기	target 파라미터의 10-20%
평균 수용률	60-85%
decode 속도 향상	2-3x
TTFT 영향	없음 (prefill 미변경)

vLLM 옵션: --num-speculative-tokens 5 --speculative-model /path/to/draft

draft 와 target 의 tokenizer 가 반드시 동일해야 함. 다르면 token ID mismatch.

Docker 배포

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model meta-llama/Llama-3.1-8B-Instruct \
    --max-model-len 8192 \
    --enable-prefix-caching \
    --gpu-memory-utilization 0.9

multi-GPU (tensor parallel):

docker run --runtime nvidia --gpus all \
    -p 8000:8000 --ipc=host \
    vllm/vllm-openai:latest \
    --model meta-llama/Llama-3.1-70B-Instruct \
    --tensor-parallel-size 4

운영 지표

flowchart LR
    vLLM["vLLM /metrics"] -->|scrape| Prom[Prometheus]
    Prom --> Graf[Grafana]
    Graf -->|"TTFT p99 대시보드"| Dashboard[대시보드]
    Graf -->|"임계값 초과시"| Alert[알림]

지표	의미	경보 기준
`vllm:time_to_first_token_seconds`	TTFT	p99 > 500ms
`vllm:e2e_request_latency_seconds`	전체 지연	p99 > 3s
`vllm:num_requests_running`	처리 중 요청 수	> max batch size
`vllm:num_requests_waiting`	대기 큐	> 50
`vllm:gpu_cache_usage_perc`	KV cache 점유율	> 90%

--disable-log-requests 플래그로 액세스 로그 비활성화. Prometheus 스크레이프는 /metrics 엔드포인트.

흔한 함정

[!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 agent 의 E2E 레이턴시는 각 단계가 직렬로 합산된다:

단계	일반적 범위	메모
VAD 종료 감지	200-500ms	너무 빠르면 발화 중 끊김
STT 첫 응답	300-600ms	streaming 시 단축됨
LLM 첫 토큰	500-2000ms	모델 크기, 네트워크 의존
TTS 첫 청크	200-500ms	streaming TTS 시 단축됨
버퍼 / 전송 지연	50-200ms	WebRTC jitter buffer
합계 최적화 전	1.2-3.8초	-

flowchart LR
    VAD["VAD 종료 감지"] --> STT["STT 인식"]
    STT --> LLM["LLM 첫 토큰"]
    LLM -->|"streaming 출력"| TTS["TTS 합성"]
    TTS --> Out["사용자 출력"]

LLM 첫 토큰 도착 즉시 TTS streaming 을 시작하면 LLM 생성 + TTS 합성이 병렬로 겹쳐 전체 체감 레이턴시가 줄어든다.

레이턴시 최적화 전략

Streaming 파이프라인: LLM 토큰 스트림 + TTS 동시 시작. Pipecat LLMResponseAggregatorService + TTSService 직결 시 자동 streaming.
VAD 임계값 튜닝: 민감도 높으면 발화 중 끊김, 둔감하면 레이턴시 증가. threshold=0.5, min_silence_duration_ms=300 이 출발점.
모델 선택: 짧은 응답은 GPT-4o-mini, 복잡한 추론만 GPT-4o. 한국어 TTS 는 Cartesia 가 ElevenLabs 보다 레이턴시 낮은 경우 많음.
지역 배포: STT / TTS API 와 서버 리전을 맞춤. 한국 사용자면 ap-northeast-2 우선.
WebRTC 우선: WebSocket 보다 P2P 최적 라우팅. LiveKit SFU 가 이를 담당.
워밍업 요청: 첫 발화 전 LLM / TTS 서비스에 더미 요청해 cold start 제거.

스택 선택 체크리스트

체크포인트	Vapi / Retell	Pipecat	LiveKit Agents
1주 내 PoC	✅	보통	보통
다중 참여자 룸	제한적	제한적	✅
커스텀 VAD / STT	제한적	✅	✅
자체 인프라 운영	불가	✅	✅
비용 예측 가능성	선불 요금	인프라만	인프라만
HIPAA / 컴플라이언스	미확인	self-host 가능	self-host 가능
Python 생태계 우선	-	✅	보통
Node / Go 지원	-	제한적	✅

프로덕션 운영 팁

[!NOTE] Pipecat / LiveKit 모두 asyncio 기반. 블로킹 I/O 를 asyncio loop 안에서 직접 호출하면 전체 파이프라인이 멈춘다. asyncio.to_thread 또는 전용 executor 로 분리.

헬스 체크: /health 엔드포인트 + LiveKit room 상태 폴링. 에이전트가 죽으면 참여자는 침묵만 들음.
그레이스풀 종료: SIGTERM 수신 시 현재 발화 완료 후 종료. Pipecat PipelineRunner.stop_when_done() 활용.
분산 추적: 각 Frame 에 call_id, turn_id 메타데이터 부착해 로그 연결.
요금 폭발 방지: 무응답 30초 후 자동 종료. Vapi / Retell idle timeout 설정 확인.
에코 처리: AEC (Acoustic Echo Cancellation) 는 transport layer 담당. Daily.co 는 내장, 직접 WebRTC 구현 시 별도 처리 필요.

[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 가 전사 못 끝남. 발화 종료 감지 필수.

인프라 요구사항

네트워크

음성 에이전트는 낮은 레이턴시가 생명입니다.

프로토콜	지연	용도
WebRTC	최저	브라우저 / 모바일 클라이언트. 미디어 서버 (LiveKit, Daily) 경유.
WebSocket	낮음	서버-서버 또는 기기 연결. 텍스트/바이너리 양방향 스트림.
HTTP chunked	높음	단순 구현 가능하나 지연 큼. 프로토타입에만 권장.

VAD (Voice Activity Detection) 선택

발화 종료를 얼마나 정확히, 얼마나 빠르게 감지하느냐가 전체 latency budget 의 핵심입니다.

VAD 방식	지연	설명
에너지 기반	매우 낮음	단순 볼륨 임계값. 오탐 많음.
Silero VAD	낮음	경량 ML 모델 (5 MB). 정확도-속도 균형. 가장 많이 쓰임.
시맨틱 endpointing	중간	STT partial 결과를 LLM 으로 “문장이 끝났는가” 판단. 가장 자연스러움.

Sentence Aggregator

STT 의 partial transcript 를 LLM 에 넘길 적절한 단위로 묶는 컴포넌트.

너무 짧게 끊으면: LLM 이 컨텍스트 없이 처리 → 어색한 응답
너무 길게 기다리면: TTS 시작이 늦어짐

일반적으로 문장 완성 (마침표, 쉼표 후 길이 임계) 기준으로 aggregation.

프로덕션 체크리스트

배포 전 검증 항목:

항목	검증 방법
p50 / p95 / p99 latency	실제 통화 10,000 건 이상 메트릭 수집
Barge-in	사용자가 응답 도중 끊을 때 TTS 즉시 중단 + STT 재개
VAD 오탐 / 미탐	배경 소음 환경 테스트 (사무실, 카페)
LLM fallback	타임아웃 시 “잠시만 기다려 주세요” 응답
TTS 오류 복구	TTS API 오류 시 기본 합성 폴백
동시 세션 수	서버당 최대 동시 통화 수 부하 테스트
오디오 코덱	Opus 16 kHz mono (WebRTC 표준), G.711 (전화망)

모니터링 메트릭

flowchart LR
    Mic["사용자 발화 종료"] -->|VAD delay| STT_start["STT 시작"]
    STT_start -->|STT latency| LLM_start["LLM 호출"]
    LLM_start -->|TTFT| TTS_start["TTS 첫 청크"]
    TTS_start -->|TTFB| Speaker["스피커 출력 시작"]

추적해야 하는 메트릭:

VAD endpointing delay: 실제 발화 종료 ~ STT 시작
STT latency: 오디오 수신 ~ final transcript
LLM TTFT (Time-to-First-Token): 프롬프트 전송 ~ 첫 토큰 수신
TTS TTFB (Time-to-First-Byte): 텍스트 전송 ~ 첫 오디오 청크
종단 latency: VAD 종료 ~ 스피커 첫 소리

각 단계를 OpenTelemetry span 으로 기록하면 병목이 어느 단계인지 즉시 파악됩니다.

[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] BIG-Bench (Beyond the Imitation Game)

정의

구성

태스크 유형

태스크 카테고리

채점

평가 파이프라인

BIG-Bench Hard (BBH)

BBEH (BIG-Bench Extra Hard)

주요 모델 성능 추이

리더보드

한계

다른 벤치마크와 관계

실전 사용

재현 시 주의사항

인간 baseline 해석

어떤 상황에 사용하나

공개 기여 방법

관련 위키

[Prompting] Few-Shot Prompting

정의

언제 쓰이나

기본 흐름

기본 구조

K 값의 선택

무엇이 성능을 결정하는가

예시 선택 전략

함정과 편향

1. Recency bias

2. Majority label bias

3. Common token bias

4. Order sensitivity

5. Example selection

Chain-of-Thought 와 결합

실전 예시

Python 으로 few-shot 분류 (OpenAI)

JSON 스키마 강제 추출

Instruction-tuned 모델에서의 위상 변화

실전 팁

함정

관련 위키

[Prompting] Zero-Shot Prompting

정의

언제 쓰이나

기본 흐름

기본 구조

왜 zero-shot 이 가능한가

Few-shot 대비 장단점

Zero-shot CoT

Instruction tuning 의 영향

FLAN (Wei et al., 2021)

T0 (Sanh et al., 2022)

InstructGPT / RLHF

오늘의 instruction-tuned 모델

잘 쓰는 지시문의 원칙

실전 예시

감정 분석

구조화 JSON 추출

Zero-shot CoT: 수학 문제

Python 에서 zero-shot 호출

성능 한계

함정

언제 zero-shot 을 쓰나

언제 zero-shot 대신 few-shot 이 낫나

관련 위키

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

정의

언제 쓰이나

전체 파이프라인

지연 분해

지연 예산 할당

VAD (Voice Activity Detection)

예측적 프리페치 (Speculative Retrieval)

캐시 계층

Semantic Cache

Streaming TTS 패턴

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

청크 전략 (음성 친화)

Re-ranking 의 trade-off