2023년 6월, UC Berkeley의 Lianmin Zheng과 동료들이 논문 하나를 냅니다. GPT-4를 판사로 써서 LLM 응답을 평가했더니, 인간 전문가 평가자들과 85% 일치했다는 내용이었습니다. 인간끼리의 일치율(81%)보다도 높았습니다. 이 한 수치가 평가 패러다임을 바꿨습니다. BLEU 점수로 돌아가던 평가 파이프라인들이 LLM-as-a-Judge로 마이그레이션을 시작했습니다. 그런데 "LLM이 LLM을 평가한다"는 게 정확히 무슨 의미인지, 세 가지 패러다임 중 언제 어떤 것을 써야 하는지는 잘 정리되지 않았습니다. 1편에서는 기존 지표가 왜 무너졌는지, 그리고 세 가지 평가 패러다임 각각의 원리와 트레이드오프를 해부합니다.
1편이 다루는 것 → BLEU·ROUGE·BERTScore의 구체적 실패 지점과 수치 → LLM-as-a-Judge 등장 배경 — MT-Bench(Zheng et al. 2023) 핵심 결과 → Pointwise·Pairwise·Listwise 세 패러다임 원리·구현·트레이드오프 전체 → 각 패러다임의 숨겨진 실패 모드 (순환 선호, 적대적 조작, 스코어 인플레이션) → 언제 무엇을 쓸지 — 실무 결정 기준
1. 기존 평가 지표가 무너진 이유
LLM 평가의 역사는 "좋은 지표를 찾는 역사"입니다. 모든 지표는 특정 가정 하에서 작동하고, LLM이 그 가정의 경계를 넘으면 지표가 무너집니다.
BLEU — 올바른 답을 틀렸다고 부르는 지표
BLEU(Bilingual Evaluation Understudy, Papineni et al. 2002)는 n-gram 겹침을 측정합니다. 생성된 텍스트에서 참조 텍스트에 있는 n-gram이 얼마나 나타나는지를 봅니다.
참조: "The cat sat on the mat."
생성: "The feline rested on the rug."
의미: 완전히 동일
BLEU: 낮음 — cat/sat/mat 없음
더 극단적인 예시가 있습니다. 문자 'A'를 쓰지 않고 헤엄치는 물고기에 대한 시를 써달라는 요청에 AI가 완벽한 시를 냈다면, 참조 답안과 단어가 하나도 겹치지 않아 BLEU는 0점을 줄 수 있습니다. Zhang et al.(2019)의 BERTScore 논문에 따르면 전통적 n-gram 지표는 60% 이상의 paraphrase 케이스에서 의미적 동치를 포착하지 못합니다. 번역, 요약, 창의적 생성처럼 표현의 다양성이 핵심인 태스크에서 BLEU는 본질적으로 부적합합니다.
ROUGE — 소환사의 길을 잃은 지표
ROUGE(Recall-Oriented Understudy for Gisting Evaluation, Lin 2004)는 원래 텍스트 요약 평가를 위해 설계됐습니다. Recall 중심이라 참조 텍스트의 내용이 생성문에 얼마나 포함됐는지를 봅니다.
실패 지점이 명확합니다. ROUGE는 사실 오류를 탐지하지 못합니다. 유창하게 환각된 응답이 참조 텍스트의 단어를 많이 포함하면 높은 ROUGE를 얻습니다. 의료 요약 생성 연구(Croxford et al. 2024)에서 ROUGE는 유창하게 표현됐지만 근거 없는 환각 주장을 패널티 없이 통과시켰습니다.
BERTScore — 더 나아졌지만 충분하지 않은
BERTScore(Zhang et al. 2019)는 BERT의 문맥 임베딩을 사용해 의미적 유사성을 측정합니다. "cat"과 "feline"이 벡터 공간에서 가깝다는 것을 압니다. BLEU보다 분명히 진보했지만 세 가지 구조적 한계가 있습니다.
첫째, 도메인 민감성. BERTScore의 인간 판단과의 상관관계는 전문 도메인(법률, 의료)에서 40% 이상 떨어집니다. 도메인 특수 어휘를 BERT가 충분히 표현하지 못하기 때문입니다.
둘째, 아키텍처 편향. BERT와 유사한 트랜스포머 아키텍처를 쓰는 모델이 그렇지 않은 모델보다 BERTScore에서 유리합니다. 평가 지표가 특정 아키텍처를 선호하는 구조적 편향입니다.
셋째, 다중 참조 불일치. 참조 텍스트가 여러 개일 때 어떤 참조를 선택하느냐에 따라 결과가 달라집니다.
[세 지표 공통 실패 패턴]
1. 참조 답안 의존 — 좋은 참조가 없으면 평가 자체가 불가능
2. 의미 이해 부재 — 지시 준수, 안전성, 창의성 측정 불가
3. 고차원 품질 포착 실패 — 논리적 일관성, 사실 정확성, 적절성 측정 불가
4. 태스크 불가지론 — 번역 지표로 에이전트 응답을 평가하는 구조적 문제
2. LLM-as-a-Judge의 등장 — MT-Bench가 세운 기초
2023년 MT-Bench 논문(Zheng et al., NeurIPS 2023)은 핵심 질문을 던졌습니다. "강력한 LLM을 판사로 쓰면 인간 판단을 대체할 수 있는가?"
실험 설계는 간단했습니다. 8개 카테고리(글쓰기, 롤플레이, 추론, 수학, 코딩, 추출, STEM, 인문학)에 걸친 80개 멀티턴 질문을 구성하고, 여러 LLM의 응답을 인간 전문가 58명과 GPT-4 판사가 각각 평가했습니다.
결과는 명확했습니다.
GPT-4 판사 vs 인간 전문가 일치율:
비기 제외(S2 설정): 85%
인간 간 일치율: 81%
→ GPT-4 판사가 인간보다 인간에 가깝다
더 흥미로운 결과가 있었습니다. GPT-4 판정이 인간 평가자와 다를 때, 그 판정을 인간에게 보여주면 75%가 "합리적"이라고 인정했고, 34%는 자신의 판단을 바꿨습니다. 판사 LLM이 인간 평가자의 실수를 교정하는 방향으로 기능했습니다.
이 결과가 제시한 것은 단순한 "자동화"가 아닙니다. 확장 가능하고(Scalable), 설명 가능하며(Explainable), 인간 선호에 근접하는(Aligned) 평가 메서드의 가능성이었습니다. LLM-as-a-Judge가 주류로 진입한 순간입니다.
3. 세 가지 패러다임 — Pointwise, Pairwise, Listwise
LLM-as-a-Judge는 단일한 방법이 아닙니다. 평가 목적에 따라 세 가지 다른 패러다임으로 구현됩니다. 각각 다른 질문에 답합니다.
Pointwise: "이 응답의 품질은 절대적으로 얼마인가?"
Pairwise: "A와 B 중 어느 것이 더 나은가?"
Listwise: "이 N개 응답을 최상에서 최하로 순위 매기면?"
3.1 Pointwise — 절대 평가
원리: 단일 응답을 루브릭의 각 차원에 대해 독립적으로 점수화합니다. 다른 응답과의 비교 없이 응답 자체의 절대적 품질을 측정합니다.
from anthropic import Anthropic
import json
client = Anthropic()
POINTWISE_SYSTEM = """당신은 AI 응답 품질 평가 전문가입니다.
응답의 길이나 형식이 아닌, 순수하게 내용의 품질만 평가합니다."""
POINTWISE_TEMPLATE = """
다음 응답을 아래 기준으로 평가하세요.
[질문]
{question}
[평가할 응답]
{response}
[평가 기준]
각 기준을 1(매우 낮음)~5(매우 높음)로 채점하고,
반드시 근거를 제시한 뒤 점수를 부여하세요.
1. 정확성: 사실 오류 없이 정확한 정보를 제공하는가?
2. 관련성: 질문에서 요청한 내용을 직접적으로 다루는가?
3. 완전성: 중요한 내용이 누락 없이 포함됐는가?
4. 명확성: 이해하기 쉽고 논리적으로 구조화됐는가?
5. 유용성: 사용자가 실제로 도움을 받을 수 있는가?
주의사항:
- 응답이 길다는 이유만으로 높은 점수를 주지 마세요
- 마크다운 포맷이 아닌 내용의 실질적 품질을 평가하세요
- 각 기준은 독립적으로 평가하세요
반드시 JSON 형식으로만 출력하세요:
{{
"accuracy": {{"score": 1-5, "rationale": "..."}},
"relevance": {{"score": 1-5, "rationale": "..."}},
"completeness": {{"score": 1-5, "rationale": "..."}},
"clarity": {{"score": 1-5, "rationale": "..."}},
"usefulness": {{"score": 1-5, "rationale": "..."}},
"overall": <가중 평균, 소수점 1자리>,
"summary": "2-3문장 종합 평가"
}}
"""
def pointwise_judge(
question: str,
response: str,
judge_model: str = "claude-opus-4-7",
) -> dict:
raw = client.messages.create(
model=judge_model,
max_tokens=1024,
system=POINTWISE_SYSTEM,
messages=[{
"role": "user",
"content": POINTWISE_TEMPLATE.format(
question=question,
response=response,
)
}]
).content[0].text
return json.loads(raw)
Pointwise의 장점
참조 답안이 없어도 됩니다. 참조를 구하기 어려운 창의적 글쓰기, 오픈엔드 질문, 에이전트 행동 평가에 적합합니다. 개별 응답을 독립적으로 처리하므로 대규모 배치 처리에 유리하고, 시간에 따른 절대적 품질 추세 추적이 가능합니다.
Pointwise의 실패 모드
가장 심각한 문제는 점수 인플레이션입니다. 실제로 운영해보면 대부분의 응답이 3.8~4.5 범위로 수렴합니다. 판사 LLM이 모든 응답에 후하게 점수를 주는 경향이 있어 품질 차이를 민감하게 구분하지 못합니다.
두 번째 문제는 판사 간 절대값 불일치입니다. 판사 모델이 달라지면 같은 응답에 다른 절대 점수를 부여합니다. 특정 판사로 측정한 4.2점이 다른 판사의 3.8점과 같은 품질일 수 있습니다. 이 때문에 판사 모델을 바꾸는 것은 단순 설정 변경이 아닌 전체 평가 스케일 재보정을 의미합니다.
세 번째는 루브릭 없는 Pointwise는 노이즈라는 점입니다. "1점에서 10점으로 품질을 평가하라"는 요청만으로는 판사마다 다른 기준을 적용합니다. 명확하게 분리된 루브릭 차원이 없으면 점수는 숫자에 불과합니다.
3.2 Pairwise — 비교 평가
원리: 두 응답을 동시에 제시하고 어느 것이 더 나은지를 판단합니다. 절대 점수가 아닌 상대적 우위를 묻습니다. MT-Bench에서 가장 높은 인간 일치율을 보인 방식입니다.
PAIRWISE_SYSTEM = """당신은 두 AI 응답의 상대적 품질을 비교하는 전문 평가자입니다.
반드시 내용의 실질적 품질만을 기준으로 판단하세요.
응답의 위치(A가 먼저인지 B가 먼저인지)에 관계없이 공정하게 평가하세요."""
PAIRWISE_TEMPLATE = """
두 AI 응답 중 어느 것이 더 나은지 평가합니다.
[질문]
{question}
[응답 {label_a}]
{response_a}
[응답 {label_b}]
{response_b}
[평가 절차]
1단계: 응답 {label_a}의 강점과 약점을 분석하세요.
2단계: 응답 {label_b}의 강점과 약점을 분석하세요.
3단계: 두 응답을 직접 비교해 어느 쪽이 더 나은 이유를 설명하세요.
4단계: 최종 판정을 내리세요.
다음 기준으로 평가하세요:
- 더 정확하고 신뢰할 수 있는 정보
- 질문에 더 직접적으로 답변
- 더 실용적이고 실행 가능한 내용
- 더 명확하고 이해하기 쉬운 설명
JSON으로만 출력:
{{
"analysis_a": "응답 {label_a} 분석 (2-3문장)",
"analysis_b": "응답 {label_b} 분석 (2-3문장)",
"comparison": "두 응답 직접 비교 (2-3문장)",
"winner": "{label_a}" | "{label_b}" | "tie",
"confidence": "high" | "medium" | "low",
"reasoning": "판정 근거 (1-2문장)"
}}
"""
def pairwise_judge(
question: str,
response_a: str,
response_b: str,
judge_model: str = "claude-opus-4-7",
swap_positions: bool = True,
) -> dict:
"""
swap_positions=True: AB, BA 두 번 실행 후 일관성 확인
"""
def _single_eval(label_a, ra, label_b, rb):
raw = client.messages.create(
model=judge_model,
max_tokens=1024,
system=PAIRWISE_SYSTEM,
messages=[{
"role": "user",
"content": PAIRWISE_TEMPLATE.format(
question=question,
label_a=label_a, response_a=ra,
label_b=label_b, response_b=rb,
)
}]
).content[0].text
return json.loads(raw)
result_ab = _single_eval("A", response_a, "B", response_b)
if not swap_positions:
return {"winner": result_ab["winner"], "consistent": None, "detail": result_ab}
# BA 순서로 재실행
result_ba = _single_eval("B", response_b, "A", response_a)
# AB에서 A 이김 = BA에서 A도 이겨야 함 (BA에서 A = 원래 response_a)
ab_winner_original = result_ab["winner"] # "A" or "B" or "tie"
# BA에서 레이블 역전 보정
if result_ba["winner"] == "A":
ba_winner_original = "B" # BA에서 A가 이겼다 = 원래 B(response_b)가 이겼다
elif result_ba["winner"] == "B":
ba_winner_original = "A" # BA에서 B가 이겼다 = 원래 A(response_a)가 이겼다
else:
ba_winner_original = "tie"
consistent = ab_winner_original == ba_winner_original
final_winner = ab_winner_original if consistent else "tie"
return {
"winner": final_winner,
"consistent": consistent,
"ab_result": result_ab,
"ba_result": result_ba,
"cost_api_calls": 2,
}
Pairwise의 장점
상대 비교는 인간에게 더 자연스러운 판단 방식입니다. "이 응답이 7점인가?"보다 "A와 B 중 어느 게 더 나은가?"라는 질문이 더 쉽고 일관된 답을 이끌어냅니다. MT-Bench에서 Pointwise보다 인간 일치율이 높게 나온 이유입니다. 미묘한 품질 차이도 포착합니다. 두 응답이 모두 괜찮지만 하나가 약간 더 나은 경우, Pointwise는 둘 다 4점을 주지만 Pairwise는 차이를 포착합니다.
Pairwise의 실패 모드
O(n²) 복잡도. n개 응답을 모두 비교하려면 n(n-1)/2번의 비교가 필요합니다. 10개 응답이면 45번, 100개면 4,950번입니다. 대규모 평가에서 비용이 폭발합니다.
순환 선호(Circular Preference). FairJudge 연구에서 문서화된 문제입니다. A가 B를 이기고, B가 C를 이기고, C가 A를 이기는 순환이 발생할 수 있습니다. 이 경우 일관된 순위를 결정하기 어렵습니다.
실제 발생 가능한 순환:
응답 A > 응답 B (A가 더 정확)
응답 B > 응답 C (B가 더 상세)
응답 C > 응답 A (C가 더 간결)
→ 절대적 1등이 없음
적대적 조작에 취약. COLM 2025 연구에서 중요한 발견이 나왔습니다. 생성 모델이 판사 LLM이 선호하는 표면적 특성(verbose tone, authoritative markers, 특정 포맷)을 학습해 내용은 낮은 품질이어도 판사를 조작할 수 있습니다. Pairwise에서 이런 방식으로 선호가 뒤집히는 비율이 **35%**였던 반면, Pointwise는 **9%**에 그쳤습니다. 이는 Pairwise가 더 조작하기 쉬운 구조임을 시사합니다.
Score-Comparison Inconsistency. Pointwise 점수와 Pairwise 판정이 모순되는 경우가 발생합니다. Pointwise에서 8점을 받은 응답이 7점 응답과의 Pairwise 비교에서 질 수 있습니다. 이는 두 패러다임이 서로 다른 것을 측정하고 있음을 보여줍니다.
3.3 Listwise — 순위 평가
원리: 여러 응답을 동시에 컨텍스트에 넣고 1등부터 N등까지 순위를 매깁니다.
LISTWISE_TEMPLATE = """
다음 {n}개의 응답을 최상에서 최하 순으로 순위를 매기세요.
[질문]
{question}
{responses_block}
[평가 절차]
1단계: 각 응답의 핵심 강점과 약점을 파악하세요.
2단계: 응답들을 상호 비교해 상대적 품질을 판단하세요.
3단계: 1위부터 {n}위까지 순위를 결정하고 근거를 설명하세요.
중요: 응답 ID(1, 2, 3...)는 임의 번호입니다.
번호 순서가 아닌 내용의 품질만을 기준으로 순위를 매기세요.
JSON으로만 출력:
{{
"ranking": [<1위 ID>, <2위 ID>, ..., <{n}위 ID>],
"rationale": {{
"<ID>": "이 응답의 품질 평가 (1-2문장)",
...
}},
"key_differentiators": "상위와 하위를 가른 핵심 요소 (1-2문장)"
}}
"""
def listwise_judge(
question: str,
responses: list[str], # 평가할 응답 리스트
judge_model: str = "claude-opus-4-7",
shuffle: bool = True, # 제시 순서 무작위화
) -> dict:
import random
if shuffle:
# 순서 편향 완화를 위해 제시 순서 무작위화
indices = list(range(len(responses)))
random.shuffle(indices)
shuffled_responses = [(i+1, responses[idx]) for i, idx in enumerate(indices)]
reverse_map = {i+1: idx for i, idx in enumerate(indices)}
else:
shuffled_responses = [(i+1, r) for i, r in enumerate(responses)]
reverse_map = {i+1: i for i in range(len(responses))}
responses_block = "\n\n".join([
f"[응답 {num}]\n{resp}"
for num, resp in shuffled_responses
])
raw = client.messages.create(
model=judge_model,
max_tokens=1024,
messages=[{
"role": "user",
"content": LISTWISE_TEMPLATE.format(
n=len(responses),
question=question,
responses_block=responses_block,
)
}]
).content[0].text
result = json.loads(raw)
# 무작위화된 ID를 원래 인덱스로 역변환
original_ranking = [reverse_map[rank_id] for rank_id in result["ranking"]]
result["ranking_original_indices"] = original_ranking
return result
Listwise의 장점
단일 API 호출로 N개 응답을 처리합니다. Pairwise의 O(n²) 호출 대비 효율적입니다. 여러 응답이 동시에 컨텍스트에 있어 상대적 품질 파악이 직관적입니다. 프롬프트 최적화, A/B/C 테스트, 모델 선발에 적합합니다.
Listwise의 실패 모드
컨텍스트 위치 편향. 컨텍스트 앞에 위치한 응답이 더 주목받는 경향이 있습니다. 위 코드에서 shuffle=True로 완화하지만 완전히 제거되지는 않습니다.
N이 커질수록 신뢰성 저하. 응답 수가 많아지면 판사 LLM이 전체를 동시에 처리하기 어렵습니다. 보통 5~7개 이상에서 판단 일관성이 떨어집니다.
순서 효과. 처음 본 응답이 이후 응답 평가에 앵커로 작용합니다. 1번으로 제시된 응답이 3번 응답보다 유리할 수 있습니다.
4. 세 패러다임 비교 — 수치로 보기
항목 Pointwise Pairwise Listwise
| 호출 수 (n개 응답) | n | n(n-1)/2 | 1~few |
| 참조 답안 | 선택적 | 불필요 | 불필요 |
| 적대적 조작 취약성 | 9% (flip rate) | 35% (flip rate) | 중간 |
| 절대 품질 추적 | ✅ | ❌ | ❌ |
| 미묘한 차이 포착 | ⚠️ | ✅ | ✅ |
| 확장성 | ✅ 높음 | ❌ 낮음 | ✅ 높음 |
| 순환 선호 위험 | 없음 | 있음 | 낮음 |
| 인간 일치율(MT-Bench) | 높음 | 가장 높음 | 중간 |
5. 언제 무엇을 써야 하는가
이론적 비교보다 실무적 결정 기준이 더 중요합니다.
[결정 트리]
목표가 "이 응답이 기준을 만족하는가"?
→ Pointwise (절대 품질 게이트, CI 합격/불합격)
목표가 "A와 B 중 어느 것이 더 나은가"?
→ Pairwise + Position Swap (A/B 테스트, 모델 비교)
단, 비교 응답이 10개 이상이면:
→ Listwise로 1차 필터 후 상위만 Pairwise
목표가 "N개 옵션 중 최선을 골라라"?
→ Listwise (프롬프트 선발, 후보 순위화)
단, N > 7이면 토너먼트 방식으로 분할
목표가 "시스템 품질을 지속 모니터링"?
→ Pointwise (시계열 추적, 드리프트 탐지)
목표가 "RLHF/RLAIF 선호 데이터 수집"?
→ Pairwise (브래들리-테리 모델을 위한 이진 비교)
실무에서 가장 흔한 실수는 단일 패러다임으로 모든 것을 해결하려는 것입니다. 지속적 품질 모니터링에는 Pointwise, 모델 교체 결정에는 Pairwise, 프롬프트 선발에는 Listwise를 조합하는 것이 현실적입니다.
6. PREPAIR — 두 패러다임을 합치는 접근
Pairwise의 높은 인간 일치율과 Pointwise의 낮은 조작 취약성을 동시에 얻으려는 시도가 PREPAIR(Pointwise REasoning within PAIRwise, KAIST AI 2024)입니다. 두 응답을 비교하기 전에 각각을 독립적으로 분석하는 단계를 삽입합니다.
PREPAIR_TEMPLATE = """
두 응답을 비교하기 전에 각각을 독립적으로 평가합니다.
[질문]
{question}
--- 1단계: 응답 A 독립 분석 ---
[응답 A]
{response_a}
응답 A의 강점, 약점, 정확성, 유용성을 분석하세요.
[응답 A 분석]: (여기에 작성)
--- 2단계: 응답 B 독립 분석 ---
[응답 B]
{response_b}
응답 B의 강점, 약점, 정확성, 유용성을 분석하세요.
[응답 B 분석]: (여기에 작성)
--- 3단계: 비교 판정 ---
위 독립 분석을 바탕으로 두 응답 중 어느 것이 더 나은지 판정하세요.
독립 분석에서 확인한 사실만을 근거로 사용하세요.
JSON:
{{
"analysis_a": "...",
"analysis_b": "...",
"winner": "A" | "B" | "tie",
"reasoning": "..."
}}
"""
PREPAIR의 원리는 독립 분석 단계에서 각 응답의 실제 품질을 먼저 파악하게 함으로써, 이후 비교 판정에서 표면적 특성(장황함, 권위적 어조)에 끌리는 것을 방지합니다.
✅ 1편 정리
항목 핵심
| BLEU·ROUGE 한계 | n-gram 겹침 = 의미 동치 아님, 60%+ 파라프레이즈 미포착 |
| BERTScore 한계 | 전문 도메인에서 상관관계 40% 하락, 아키텍처 편향 |
| LLM-as-a-Judge 근거 | MT-Bench: GPT-4 판사 85% 인간 일치 (인간 간 81%보다 높음) |
| Pointwise 핵심 | 절대 품질 추적, 인플레이션·루브릭 설계가 관건 |
| Pairwise 핵심 | 높은 인간 일치율, O(n²) 비용·적대적 조작(35%)에 취약 |
| Listwise 핵심 | 효율적, N>7에서 신뢰성 저하, 컨텍스트 위치 편향 |
| PREPAIR | Pointwise 분석 + Pairwise 판정 결합, 조작 취약성 완화 |
LLM-as-a-Judge 완전정리 시리즈 — 완결
- ✅ 1편 — 왜 기존 지표는 죽었고, 세 패러다임은 무엇인가 https://cell-devlog.tistory.com/265
- ✅ 2편 — 판사는 어디서 거짓말하나: 7가지 편향 해부 https://cell-devlog.tistory.com/266
- ✅ 3편 — 편향 잡는 법: Position Swap부터 Cross-family까지 https://cell-devlog.tistory.com/267
- ✅ 4편 — G-Eval vs Prometheus 2 vs PAJAMA vs Themis https://cell-devlog.tistory.com/268
- ✅ 5편 — 판사를 평가하기: Cohen's κ, Bradley-Terry, 황금 세트 설계 https://cell-devlog.tistory.com/269
- ✅ 6편 — 프로덕션 파이프라인: 샘플링·CI 게이트·캘리브레이션 주기 https://cell-devlog.tistory.com/270
- ✅ 7편 — 한계와 대안: LLM 판사가 절대 못 하는 것들 https://cell-devlog.tistory.com/271
'AI Agent' 카테고리의 다른 글
| LLM as a Judge 완전정리 3편 — 편향 잡는 법: 전략별 코드와 효과 비교 (0) | 2026.05.26 |
|---|---|
| LLM as a Judge 완전정리 2편 — 판사는 어디서 거짓말하나: 7가지 편향 해부 (0) | 2026.05.26 |
| LLM-as-Judge 완전 가이드 3편—에이전트 자동 평가 루프와 CI/CD 통합, Judge를 진짜 파이프라인에 박아라 (0) | 2026.05.22 |
| LLM-as-Judge 완전 가이드 2편 — 편향 제거부터 Jury 패턴까지, 프로덕션에서 살아남는 법 (0) | 2026.05.22 |
| AI 에이전트 Durable Execution 실전 2편 — Human-in-the-Loop·멀티에이전트·Serverless (0) | 2026.05.21 |