# [[LLM-as-judge]]

## 📌 Brief Summary
LLM-as-judge는 인공지능 에이전트 하네스 환경에서 모델의 산출물이나 시스템의 동작을 평가하기 위해 대규모 언어 모델(LLM) 자체를 심사관(judge)으로 활용하는 추론적(Inferential) 제어 및 평가 방식이다 [1, 2]. 주로 AI 코드 리뷰, 의미론적 분석, 응답 품질의 지속적 샘플링 및 로그 이상 징후 탐지 등에 활용된다 [2, 3]. 이를 통해 인간 개발자가 모든 것을 검토하지 않고도 에이전트의 워크플로우를 테스트하고 신뢰할 수 있는 검증 루프를 구축할 수 있도록 돕는다 [1, 2].

## 📖 Core Content
* **추론적 피드백 센서로서의 역할:** 에이전트 하네스 내에서 LLM-as-judge는 의미론적 판단(Semantic judgment)이 필요한 문제를 다루는 '추론적 센서(Inferential sensor)'로 기능한다 [2, 4]. 린터(Linter)나 단위 테스트와 같이 빠르고 결정론적인 연산적(Computational) 센서와 달리, 문맥적 이해가 필요한 AI 코드 리뷰나 응답 품질 모니터링 등의 영역에서 에이전트의 상태를 감시하고 오류를 식별한다 [2, 3].
* **평가 및 CI 파이프라인 통합:** 다양한 에이전트 프레임워크와 관측 도구들은 LLM-as-judge를 기본 평가 메커니즘으로 채택하고 있다. `promptfoo`, `Weights & Biases Weave`, `Mastra` 등의 도구는 LLM-as-judge를 내장하여 에이전트 산출물의 회귀 테스트를 CI(지속적 통합) 파이프라인에 직접 통합할 수 있도록 지원한다 [1, 5, 6].
* **평가자 모델 역량에 대한 높은 의존성:** Red Hat의 평가 주도 개발(Eval-Driven Development) 사례 연구에 따르면, LLM-as-judge 역할을 수행하는 평가자 모델의 역량(Capability)은 평가의 정확도에 결정적인 영향을 미친다 [1]. 실제 실험에서 대형 모델(llama-3-3-70b)은 알려진 실패 사례를 모두 잡아낸 반면, 더 작은 모델들은 여러 실패 사례를 놓치는 한계를 보였다 [1]. 즉, 적절하고 강력한 모델을 평가자로 사용할 때만 시스템에 대한 실질적인 신뢰도를 높일 수 있다 [2].

## ⚖️ Trade-offs & Caveats
* **높은 비용 및 실행 지연:** LLM-as-judge는 GPU나 NPU 자원을 사용하기 때문에 전통적인 연산적 센서에 비해 실행 속도가 느리고 비용이 많이 든다 [2, 4]. 따라서 에이전트가 코드를 변경하는 모든 커밋(Commit)마다 LLM-as-judge를 실행하는 것은 경제적으로나 시간적으로 비효율적이다 [4].
* **비결정성(Non-determinism)과 평가 피로:** 확률론적 모델에 기반하므로 평가 결과가 항상 100% 동일하게 보장되지 않는 비결정성을 띤다 [2, 4]. 
* **설계적 제약:** 무분별한 LLM-as-judge의 사용은 막대한 평가 비용으로 인해 시스템 전체를 무너뜨릴 수 있으므로(eval cost collapse), 유의미한 리스크를 줄일 수 있는 핵심적인 위치에만 값비싼 검사를 추가하는 계층적 가드레일 설계가 필수적이다 [1].

---
*Last updated: 2026-05-05*

## 🛠️ 적용 사례 (Applied in summary)

<!-- CODE-GROUNDING:START -->
### 🔎 코드베이스 근거 (자동 추출 — E:\Wiki 레포)
**실제 구현/사용 위치:**
- `connectai/src/retrieval/evalHarness.ts:9` — * 의도적으로 LLM 을 쓰지 않는다 (재현 가능 + 무료 + CI 가능). LLM-as-Judge 기반의

_자동 생성: code_grounding.mjs · 재실행 시 갱신됨_
<!-- CODE-GROUNDING:END -->