프롬프트 평가 체계와 도구

한 줄 요약

프롬프트가 좋아졌는지는 샘플 몇 개를 읽고 판단하지 말고, 고정 평가셋에서 구버전과 신버전을 나란히 실행한 뒤 형식 안정성, 작업 적합성, 품질 루브릭, 쌍대 선호, 통계적 차이, 실패 유형, 비용을 함께 봐야 한다.

먼저 읽을 결론

가장 설득력 있는 검증 방식은 paired multi-metric evaluation이다. 같은 입력을 구버전 Prompt A와 신버전 Prompt B에 모두 넣고, 결과를 다음 순서로 판정한다.

1. JSON Schema / hard gate로 출력 형식 검증
2. 고정 평가셋에서 Prompt A/B paired 실행
3. 품질 루브릭으로 absolute scoring
4. Blind pairwise comparison으로 직접 선호 비교
5. 사람 평가 일부로 LLM judge calibration
6. paired bootstrap, McNemar, sign test 등으로 통계 판정
7. 응답 분포, 다양성, 중복률, 과도한 편향을 sanity check
8. 실패 유형별 before/after 감소율 보고

도구는 목적에 따라 나눠 보는 편이 좋다. 빠른 프롬프트 A/B와 회귀 테스트는 promptfoo가 가장 직접적이다. 평가셋, 프롬프트 버전, 운영 trace, 사람 평가, dashboard까지 관리하려면 Langfuse, Braintrust, LangSmith를 본다. Python 테스트 코드 중심이면 DeepEval이 맞고, RAG나 multi-step pipeline이 있으면 Ragas, TruLens, Phoenix류를 보조로 붙인다.

왜 저장했나

프롬프트 개선은 착시가 쉽다. 신버전이 더 길고 정중해졌다고 해서 품질이 오른 것은 아니다. 오히려 모든 출력이 비슷해지거나, 답이 과하게 긍정적으로 수렴하거나, 필요한 필드를 빠뜨리거나, 비용과 지연시간이 커질 수 있다.

따라서 "더 좋아졌다"는 말은 감상이 아니라 평가 기준이어야 한다. 형식이 맞는지, 질문에 정확히 답했는지, 실제 사용 목적에 도움이 되는지, 특정 실패 유형이 줄었는지, 비용 증가를 감당할 만한지까지 같이 봐야 한다.

정리한 질문

정형화된 프롬프트 체계 안에서 출력이 의도한 형태와 품질로 안정적으로 나오게 하려면, 프롬프트 변경 전후의 개선 효과를 어떻게 검증해야 하며 어떤 repository나 서비스를 쓰는 것이 좋은가?

평가 구조

Prompt B가 Prompt A보다 낫다고 말하려면, 같은 입력 조건에서 B가 아래 차원 중 핵심 항목을 개선해야 한다.

평가 층위	핵심 질문	대표 지표	판정 방식
형식 안정성	의도한 구조로 나왔는가?	JSON/schema pass rate, 필수 필드 누락률, 길이 제한 위반률	코드 검증
작업 적합성	요청한 작업을 정확히 수행했는가?	relevance score, instruction-following score, off-topic rate	루브릭 평가
출력 품질	실제 사용 가능한 수준인가?	completeness, specificity, clarity, usefulness	사람 평가 + LLM judge
도메인 유용성	의사결정이나 업무에 도움이 되는가?	핵심 정보 포함률, 누락률, 실행 가능한 제안 수	루브릭 / 태깅
일관성	입력 조건과 출력이 모순되지 않는가?	contradiction rate, context consistency score	코드 + judge
다양성 / 현실성	너무 균질하거나 한쪽으로 쏠리지 않는가?	variance, entropy, duplicate rate, JS/KS distance	분포 분석
안정성	문구 변화와 반복 실행에도 버티는가?	repeated-run variance, paraphrase robustness	robustness test
운영성	비용과 속도가 허용 가능한가?	cost/output, latency, token count	로그 분석

형식 검증은 LLM judge보다 deterministic validator가 낫다. 반대로 자연스러움, 구체성, 실무 유용성 같은 주관식 품질은 루브릭과 쌍대 비교가 필요하다.

평가셋 설계

평가셋은 한 번 만들고 계속 재사용한다. 프롬프트를 바꿀 때마다 평가셋까지 바꾸면 비교가 불가능하다.

평가셋 종류	목적	예시
Core set	일반적인 정상 케이스	대표 입력, 대표 작업, 흔한 사용자 요청
Edge set	어려운 케이스	모호한 입력, 긴 문맥, 복합 질문, 충돌 조건
Failure regression set	과거 실패 방지	형식 깨짐, 너무 일반적인 답, 누락, 모순
Robustness set	문구 변화 안정성	같은 요청의 paraphrase, 순서 변경, 길이 변화

처음에는 50~100개 케이스로 시작해도 실패 패턴을 볼 수 있다. 운영 판단에는 작업 유형, 난이도, 사용자 세그먼트를 나누어 200~500개 이상의 paired case를 쌓는 편이 안정적이다. 정확한 표본 수는 기대 개선폭과 점수 분산에 따라 달라지므로, 고정 숫자보다 bootstrap confidence interval의 폭을 같이 본다.

실험 조건도 고정한다.

항목	고정 이유
모델 버전	모델 변화와 프롬프트 변화를 분리하기 위해
temperature / top_p	창의성, 변동성 차이를 통제하기 위해
max tokens	길이 편향을 줄이기 위해
system / developer instruction	숨은 지시문 차이를 제거하기 위해
입력 데이터	난이도와 문맥 차이를 통제하기 위해
출력 schema	형식 안정성 비교 기준을 통일하기 위해
judge prompt / judge model	평가자 drift를 막기 위해
실행 날짜와 snapshot	재현성 기록을 남기기 위해

품질 지표

형식 안정성

정형 출력에서는 품질 점수보다 형식 pass rate가 먼저다.

지표	설명	목표 예시
Schema valid rate	JSON Schema 또는 지정 포맷 통과율	≥ 99%
Required field completion	필수 필드 누락 없음	100%
Allowed value compliance	선택지, 척도, 코드값이 허용 범위 안에 있음	≥ 99%
Length compliance	응답 길이, 문장 수, 글자 수 조건 준수	≥ 95~99%
Language compliance	지정 언어 준수	≥ 99%
No extra text rate	JSON 외 설명문, 사족, markdown 미출력	≥ 99%

OpenAI Structured Outputs처럼 schema 준수를 강제하는 기능을 쓰거나, 최소한 후처리 validator를 둔다. JSON 유효성만 맞는 것과 schema conformity는 다르다.

내용 품질

형식이 맞아도 답변이 부실하면 실제 제품이나 업무에 쓰기 어렵다.

차원	좋은 출력	나쁜 출력
Relevance	질문의 의도에 직접 답한다.	질문과 무관하거나 일반론만 말한다.
Completeness	필요한 이유, 조건, 근거, 예외를 포함한다.	핵심 항목이 빠져 있다.
Specificity	입력의 구체 속성과 제약을 반영한다.	어디에나 붙는 뻔한 문장이다.
Usefulness	다음 행동이나 판단에 도움이 된다.	읽어도 무엇을 해야 할지 모른다.
Consistency	입력 조건과 출력이 일관된다.	앞뒤가 모순된다.
Naturalness	대상 사용자가 읽기 자연스럽다.	보고서 문체, 번역투, AI식 정리문에 가깝다.
Non-duplication	표현과 논리가 충분히 다양하다.	여러 출력이 거의 같은 문장을 반복한다.
Bias control	불필요한 고정관념이나 단정을 만들지 않는다.	특정 집단이나 상황을 근거 없이 단정한다.

도메인 태그

주관식 출력은 "좋다/나쁘다"만 보지 말고, 해당 업무에서 필요한 정보가 실제로 들어 있는지 태깅한다.

태그	의미
`task_understanding`	요청과 맥락을 제대로 이해했는지
`key_point_coverage`	핵심 항목을 빠뜨리지 않았는지
`constraint_following`	금지 조건, 형식 조건, 범위 제한을 지켰는지
`actionability`	다음 행동으로 옮길 수 있는 내용인지
`evidence_quality`	근거, 출처, 판단 기준이 충분한지
`risk_awareness`	예외, 한계, 부작용을 다뤘는지
`user_fit`	대상 사용자와 사용 맥락에 맞는지
`novelty_or_insight`	뻔한 요약을 넘어 유용한 통찰이 있는지

평가 방식

1단계: Hard gate

먼저 기계적으로 틀린 응답을 탈락시킨다.

- JSON parse 가능
- JSON Schema 통과
- 필수 필드 모두 존재
- 값이 허용 범위 안에 있음
- open-ended 응답은 지정 길이 안에 있음
- 지정 언어 준수
- 불필요한 설명문 없음
- 개인정보, 혐오, 안전 위반, 허위 사실 없음

이 단계에서 실패한 응답은 평균 품질 점수로 상쇄하면 안 된다. schema invalid, 필수 필드 누락, 허용값 위반, 개인정보나 안전 위반은 즉시 fail gate로 처리한다.

2단계: 루브릭 점수

각 응답을 1~~5점 또는 1~~7점 척도로 평가한다.

점수	기준
1	질문과 거의 무관하거나 형식만 맞고 쓸 수 없다.
2	일부 답하지만 너무 일반적이거나 이유가 부족하다.
3	기본 출력으로 쓸 수 있으나 품질이나 유용성이 제한적이다.
4	요청에 정확히 답하고 구체적 이유, 조건, 맥락을 포함한다.
5	실제 의사결정이나 실행에 유용한 근거, 제안, 리스크, 다음 행동을 제공한다.

권장 차원은 relevance, completeness, specificity, usefulness, consistency, naturalness, non_genericity다.

3단계: Blind pairwise comparison

가장 중요한 비교는 같은 입력에 대한 A/B 응답 중 어느 쪽이 더 나은지다.

입력: 동일한 사용자 요청, 동일 문맥, 동일 제약
응답 A: 구버전 프롬프트 결과
응답 B: 신버전 프롬프트 결과

평가자에게 어느 쪽이 구버전인지 숨김
A/B 순서를 무작위화
일부 샘플은 순서를 바꿔 재평가해 position bias 측정
판정값: A wins / B wins / tie / both bad

LLM judge는 긴 응답을 좋게 보는 verbosity bias, 앞쪽 응답을 선호하는 position bias가 생길 수 있다. 그래서 blind, randomization, swap evaluation을 같이 쓴다.

통계 기준

각 케이스의 차이를 먼저 계산한다.

delta_i = Score_B_i - Score_A_i

mean_delta = 평균(delta_i)
win_rate_B = B가 A보다 나은 비율
loss_rate_B = B가 A보다 나쁜 비율
net_win_rate = win_rate_B - loss_rate_B
critical_failure_delta = B_failure_rate - A_failure_rate

지표별 분석은 이렇게 나눈다.

지표 유형	예시	권장 분석
Binary pass/fail	schema 통과, 필수 필드 통과	McNemar test, paired proportion difference
Ordinal score	1~5 루브릭 점수	Wilcoxon signed-rank, sign test
Continuous score	종합 점수, embedding similarity	paired t-test 또는 paired bootstrap
Pairwise preference	B win / A win / tie	sign test, binomial test, bootstrap CI
분포 차이	점수 분포, 다양성, 응답 길이	KS test, JS divergence, entropy, variance ratio
실패 유형	off-topic, generic, contradiction	failure rate difference + error taxonomy

실무 판정 기준 예시는 다음처럼 사전에 정한다.

Prompt B 채택 조건 예시

1. Critical hard gate
   - JSON/schema pass rate ≥ 99%
   - 필수 필드 누락률 = 0%
   - 허용값 위반률 ≤ 1%
   - 심각한 안전/편향/개인정보 위반 = 0건

2. 품질 개선
   - 종합 품질 점수 delta ≥ +0.3 / 5점 척도
   - 95% bootstrap CI가 0을 넘음
   - relevance, specificity, usefulness 중 최소 2개 이상 개선

3. 쌍대 비교
   - B win rate - A win rate ≥ +10%p
   - tie 제외 시 B win rate ≥ 60%

4. 실패율 감소
   - generic response rate 20~30% 이상 감소
   - off-topic, contradiction, duplicate 중 어느 것도 증가하지 않음

5. 분포 현실성
   - 평균 점수만 좋아지는 것이 아니라 variance와 사용자/케이스별 차이가 유지됨
   - 모든 출력이 한쪽 톤이나 결론으로 과도하게 수렴하지 않음

6. 운영성
   - 비용과 latency 증가가 허용 범위 이내
   - 토큰 증가 대비 품질 개선이 명확함

숫자는 예시지만, 기준은 평가 전에 정해야 한다. 결과를 본 뒤 기준을 바꾸면 개선 효과를 과대평가하기 쉽다.

분포와 실패 유형

프롬프트 출력은 개별 샘플만 좋아 보여도 전체적으로 망가질 수 있다. 특히 자동 생성 결과가 너무 비슷해지거나, 모든 답이 긍정적이거나, 특정 케이스에서만 과하게 길어질 수 있다.

봐야 할 분포 지표는 다음과 같다.

- score mean: 평균 품질 점수
- score variance: 점수 분산
- pass/fail rate: hard gate 통과율
- entropy: 선택지나 태그 다양성
- duplicate or near-duplicate rate: 유사 출력 반복률
- segment separation: 사용자 유형 / 케이스별 차이 유지 여부
- sentiment distribution: 긍정 / 중립 / 부정 비율
- reason-code distribution: 이유 / 결함 / 태그 분포
- baseline distance: JS divergence, KS statistic 등

사람이 작성한 baseline이 있으면 가장 좋다. 없으면 과거 운영 데이터, 파일럿 샘플, 전문가가 만든 expected distribution, 최소한의 sanity check를 둔다.

평가 리포트 구조

프롬프트 변경 전후 비교 리포트는 아래 구조가 실무에 맞다.

1. Executive Summary
   - Prompt B 채택 / 보류 / 기각
   - 핵심 개선 지표
   - 남은 리스크

2. 실험 조건
   - 모델 버전
   - temperature/top_p/max_tokens
   - 평가셋 버전
   - Prompt A/B 버전
   - 실행 일자
   - 샘플 수
   - judge 버전

3. Hard Gate 결과
   - schema pass rate
   - 필수 필드 누락률
   - 허용값 위반률
   - 언어/길이 위반률

4. 품질 점수 결과
   - relevance
   - completeness
   - specificity
   - usefulness
   - consistency
   - naturalness
   - non-genericity

5. Pairwise 결과
   - B win / A win / tie / both bad
   - net win rate
   - confidence interval
   - position-swap consistency

6. 실패 유형 분석
   - generic response
   - off-topic
   - contradiction
   - unsupported assumption
   - duplicated phrasing
   - missing key field

7. 분포 분석
   - 점수 평균/분산
   - 케이스별 차이
   - reason-code distribution
   - baseline과의 거리

8. 운영 지표
   - 평균 토큰
   - latency
   - 비용
   - retry rate

9. 결론
   - 릴리즈 여부
   - 조건부 릴리즈라면 guardrail
   - 다음 prompt iteration 대상

도구 선택

1순위: promptfoo

promptfoo는 프롬프트 A/B 테스트, assertion, LLM-as-judge, CI/CD 회귀 테스트를 가장 빨리 붙이기 좋다. 공식 문서는 promptfoo를 LLM 앱을 평가하고 red-team하는 오픈소스 CLI와 라이브러리로 설명하며, 여러 프롬프트와 입력을 matrix view로 비교할 수 있다고 설명한다.

테스트도 바로 만들기 쉽다.

- JSON schema 통과 여부
- 필수 필드 누락 여부
- 값 범위 준수 여부
- 응답 글자 수
- 핵심 조건 포함 여부
- 입력 조건과 출력의 모순 여부
- 응답이 너무 generic한지 LLM judge로 평가
- 대상 사용자와 출력 톤이 맞는지 평가

2026-03-09 Promptfoo는 OpenAI 인수 계획을 발표했고, 공개 문서는 현재 Promptfoo를 OpenAI의 일부로 표시한다. Promptfoo 쪽 발표는 오픈소스 suite를 계속 유지하겠다고 설명한다. 다만 도입 전에는 라이선스, self-host/local 실행 방식, 데이터가 외부로 나가는지 확인해야 한다.

Langfuse

Langfuse는 self-host가 가능하고, trace, dataset, experiment, evaluator, score analytics를 한곳에서 관리하기 좋다. 실제 운영 응답에서 실패 사례를 골라 regression dataset으로 승격하는 흐름에 잘 맞는다.

민감한 데이터가 있어 외부 SaaS 전송이 부담스럽다면 Langfuse self-host + promptfoo local 조합을 우선 검토한다.

Braintrust

Braintrust는 팀 단위 평가 운영에 강하다. 공식 문서는 playground에서 빠르게 반복하고, 좋은 configuration을 immutable experiment snapshot으로 승격하고, CI/CD에서 회귀를 잡고, production scoring으로 live traffic을 모니터링하는 전체 평가 cycle을 제시한다.

PM, 리서처, 데이터 사이언티스트, 엔지니어가 함께 평가하고, 프롬프트 릴리즈 승인 리포트가 필요하면 좋은 후보다.

LangSmith

LangSmith는 LangChain/LangGraph 기반이면 자연스럽다. 공식 문서는 curated dataset으로 offline evaluation을 실행해 버전을 비교하고 회귀를 잡으며, deployment 뒤에는 online evaluation으로 실제 traffic을 모니터링할 수 있다고 설명한다. 평가자는 human, code rules, LLM-as-judge, pairwise comparison을 지원한다.

DeepEval

DeepEval은 Python/pytest 스타일 평가에 적합하다. 공식 문서는 Pytest-style assertion, 50개 이상 ready-to-use metric, LLM-as-a-judge, agent, tool-use, conversational, safety, RAG, multimodal metric을 제공한다고 설명한다.

프롬프트 평가 metric을 코드로 세밀하게 관리하고 싶거나, Python 테스트/CI가 이미 있다면 좋다. 비개발자 협업 dashboard는 별도 플랫폼을 붙이는 편이 낫다.

보조 후보

도구	맞는 상황
Phoenix / Arize	observability와 prompt version 비교를 함께 보고 싶을 때
Opik by Comet	production trace, cost, latency, prompt optimization까지 보고 싶을 때
Weave	W&B 기반 실험 관리 문화가 이미 있을 때
Giskard	보안, red teaming, business logic failure까지 잡고 싶을 때
Ragas	검색 기반 응답 생성이나 RAG 평가가 필요할 때
TruLens	RAG/agent pipeline의 trace-level 평가가 중요할 때
DSPy	검증보다 metric 기반 prompt/program 자동 최적화가 목표일 때
Azure Foundry / Vertex AI / Bedrock	특정 cloud 표준 안에서 평가해야 할 때

주의할 레거시 도구

도구	2026-07-01 기준 주의점
OpenAI Evals	OpenAI deprecations 문서에 따르면 2026-06-03 deprecation이 발표됐고, 기존 evals는 2026-10-31 read-only, dashboard와 API는 2026-11-30 shutdown 예정이다.
Humanloop	공식 migration 문서에 따르면 platform은 2025-09-08 sunset됐고, 계정과 Files, Versions, Logs, Evaluations, settings가 삭제된다고 안내됐다.
Microsoft Prompt flow	Microsoft Learn은 Prompt flow in Microsoft Foundry와 Azure Machine Learning Prompt flow가 2027-04-20 retired될 예정이라고 안내한다. 신규 도입은 Foundry 최신 evaluation 방향을 보는 편이 안전하다.

바로 쓰는 judge prompt skeleton

너는 프롬프트 출력 품질 평가자다.

아래에는 동일한 입력과 동일한 제약 조건에 대한 두 개의 응답이 있다.
어느 응답이 실제 사용 목적에 더 적합한지 평가하라.

평가기준:
1. 요청에 직접 답하는가
2. 입력의 구체 조건을 반영하는가
3. 필요한 근거, 제약, 예외, 다음 행동을 포함하는가
4. 입력 조건과 모순되지 않는가
5. 너무 일반적이거나 장황하지 않은가
6. 대상 사용자가 읽기 자연스러운가
7. 길다고 무조건 좋게 평가하지 말 것
8. 긍정적이라고 무조건 좋게 평가하지 말 것

출력은 반드시 JSON으로 한다.

{
  "winner": "A" | "B" | "tie" | "both_bad",
  "confidence": 1-5,
  "reason": "짧은 근거",
  "A_defects": [],
  "B_defects": [],
  "quality_dimensions": {
    "relevance": {"A": 1-5, "B": 1-5},
    "specificity": {"A": 1-5, "B": 1-5},
    "usefulness": {"A": 1-5, "B": 1-5},
    "consistency": {"A": 1-5, "B": 1-5},
    "naturalness": {"A": 1-5, "B": 1-5}
  }
}

Skill Artifact

이 노트는 독립 배포용 skill 저장소가 아니라, 프롬프트를 개선하거나 평가 suite를 만들 때 agent에게 읽히는 운영 가이드로 쓴다.

Agent는 이 페이지를 다음 상황에서 참고한다.

프롬프트 변경 전 성공 기준과 평가셋을 정의할 때
구버전과 신버전 프롬프트를 paired 방식으로 비교할 때
hard gate, 루브릭, pairwise judge, 통계 분석을 분리해 설계할 때
promptfoo, Langfuse, Braintrust, LangSmith, DeepEval 중 도구를 고를 때
과도한 일반론, 중복 출력, 입력 조건 모순, 형식 위반을 실패 유형으로 관리할 때

Canonical public note: 프롬프트 평가 체계와 도구

주의점

LLM judge는 빠르지만 최종 진실이 아니다. 초기 50~100개 샘플은 사람이 직접 보정해 judge가 길이, 긍정성, 문체를 과대평가하지 않는지 확인한다.
사람 baseline 없이 synthetic output만 신뢰하면 현실성이 부족할 수 있다. 최소한 파일럿 human data나 전문가 expected distribution을 둔다.
promptfoo, Langfuse, Braintrust, LangSmith 같은 도구의 기능과 가격, self-host 조건은 바뀔 수 있다. 도입 전 공식 문서를 다시 확인한다.
공개 노트는 방법과 도구 선택을 압축했다. 원문의 긴 링크 목록과 도구별 세부 설명은 raw source에 보존했다.

검증이 필요한 주장

Promptfoo의 OpenAI 인수 상태와 오픈소스 유지 방식은 2026-07-01 공식 페이지 기준으로 재확인했다. 이후 운영 방식은 다시 확인해야 한다.
OpenAI Evals, Humanloop, Microsoft Prompt flow 관련 종료 일정은 각 공식 문서 기준이다. 실제 마이그레이션 시점에는 최신 공지를 다시 확인해야 한다.
LLM synthetic output의 균질성, 과도한 긍정성, prompt sensitivity 위험은 인용 연구의 scope와 데이터셋에 따라 해석이 달라질 수 있다.
arXiv 논문과 일부 도구 문서는 peer review 상태, 버전, benchmark 조건을 확인해야 한다.
품질 threshold는 예시다. 실제 작업 유형, 난이도, 리스크 허용도, human baseline에 맞춰 조정해야 한다.

Source Fidelity Notes

Preserved key numbers: 초기 평가셋 50~100개, 운영 평가셋 200~500개, schema pass ≥99%, 필수 필드 누락률 0%, length compliance ≥95~99%, 품질 delta ≥+0.3/5점, bootstrap CI가 0 초과, net win rate +10%p, tie 제외 B win rate ≥60%, generic response rate 20~30% 이상 감소, OpenAI Evals 2026-10-31 read-only와 2026-11-30 shutdown 예정, Humanloop 2025-09-08 sunset, Microsoft Prompt flow 2027-04-20 retirement 예정.
Preserved frameworks / models: paired multi-metric evaluation, hard gate, quality rubric, blind pairwise comparison, LLM judge calibration, distribution sanity check, failure taxonomy, offline/online evaluation, evaluation flywheel.
Preserved templates / checklists: hard gate checklist, 품질 루브릭, 도메인 태그, 통계 분석표, 채택 기준 예시, 평가 리포트 구조, judge prompt skeleton, 도구별 추천 조합.
Omitted or compressed: 원문의 특정 설문 응답 사례, 일부 cloud provider별 세부 기능, 모든 논문과 커뮤니티 링크의 세부 문맥, 중복된 첫 번째 원문은 줄였다. raw source에는 원래 답변과 도구 비교 답변을 보존했다.
Omission risk: 공개 노트는 범용 프롬프트 평가 문서로 재정리했기 때문에, 특정 도메인 전용 지표가 필요한 경우에는 별도 루브릭을 추가해야 한다. 특정 도구의 최신 기능, 가격, 라이선스, 데이터 처리 방식은 도입 전에 다시 확인해야 한다.

출처 / 참고자료

사용자 제공 Korean research. Raw source preserved at ../../sources/ai/2026-07-01-prompt-evaluation.raw.md.
Promptfoo Intro
Promptfoo Assertions and Metrics
Promptfoo is joining OpenAI
Braintrust: Evaluate systematically
Langfuse Evaluation Overview
LangSmith Evaluation
DeepEval Introduction
OpenAI Structured Outputs
OpenAI API Deprecations
Anthropic: Define success criteria and build evaluations
Humanloop: Migrating from Humanloop
Microsoft Learn: Azure Machine Learning prompt flow
Synthetic Replacements for Human Survey Data?
G-Eval
Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
Ragas

프롬프트 평가 체계와 도구

프롬프트 평가 체계와 도구

한 줄 요약

먼저 읽을 결론

왜 저장했나

정리한 질문

평가 구조

평가셋 설계

품질 지표

형식 안정성

내용 품질

도메인 태그

평가 방식

1단계: Hard gate

2단계: 루브릭 점수

3단계: Blind pairwise comparison

통계 기준

분포와 실패 유형

평가 리포트 구조

도구 선택

1순위: promptfoo

Langfuse

Braintrust

LangSmith

DeepEval

보조 후보

주의할 레거시 도구

추천 조합

빠른 실무형

운영형

팀 의사결정형

Python 테스트 중심

바로 쓰는 judge prompt skeleton

Skill Artifact

주의점

검증이 필요한 주장

Source Fidelity Notes

출처 / 참고자료