Evaluations

Bedrock Evaluations 개요

평가 작업 5종 지도 · 워크플로우 · 경계

PART 1 · Bedrock Evaluations 개요

Bedrock Evaluations

"체감상 좋아졌다"를 수치로 바꾸는 관리형 평가 서비스

모델과 RAG를 같은 잣대로 채점한다

데이터셋을 제출하면 서버리스로 실행되고, 점수와 근거 설명이 S3에 남습니다.

모델 · RAG 두 축
서버리스 배치 잡
LLM-as-a-Judge
BYOI — 외부 모델·RAG도 평가

takeaway

평가 대상은 파운데이션 모델 · Marketplace 모델 · 커스텀 모델, 그리고 Knowledge Base와 외부 RAG까지 — 인프라 없이 평가 작업만 제출합니다.

PART 1 · Bedrock Evaluations 개요

평가 작업 5종 지도

모델 평가 3방식 + RAG 평가 2방식 — 무엇을 채점하느냐의 분기

PART 1 · Bedrock Evaluations 개요

평가 워크플로우 5단계

데이터셋 준비부터 개선까지 — 모든 평가 유형이 공유하는 한 흐름

1
데이터셋 준비
질문-정답 쌍 JSONL을 S3에 업로드 — 최소 30개 권장
2
작업 생성
콘솔 또는 API로 평가 유형 · 메트릭 · 채점 모델을 지정
3
실행
서버리스로 자동 실행 — 수 분에서 수십 분, 인프라 관리 없음
4
결과 확인
S3에 질문별 점수 + 근거 설명, 콘솔에 점수 히스토그램
5
개선
낮은 메트릭을 진단해 파이프라인을 조정하고 재평가

takeaway

자동 평가는 별도 요금 없이 생성·채점에 쓰인 LLM 토큰만 과금됩니다(BYOI는 생성분 제외) — Human 평가는 완료 태스크당 과금이 추가됩니다.

PART 1 · Bedrock Evaluations 개요

Bedrock Evaluations의 경계

릴리스 전 배치 평가는 Bedrock Evaluations, 실 트래픽 온라인 평가는 AgentCore Evaluations 담당

영역	담당	다루는 것
배치 평가 잡 (이 모듈)	Bedrock Evaluations	모델·RAG를 S3 데이터셋으로 채점 — 릴리스 전 품질 게이트
온라인 평가 · 에이전트 평가	AgentCore Evaluations	실 트래픽 샘플링 · Trajectory · 도구 선택 정확도
평가 메트릭 이론 · RAGAS	RAG 평가 모듈	3축 메트릭 정의 · LLM-as-a-Judge 원리 · 오픈소스 도구

takeaway

같은 LLM-as-a-Judge 패턴이라도 릴리스 전 배치 검증은 Bedrock Evaluations, 프로덕션 실시간 감시는 AgentCore Evaluations가 맡습니다.

모델 평가 3방식

Programmatic · LLM-as-a-Judge · Human

PART 2 · 모델 평가 3방식

모델 평가 3방식

채점자가 누구냐의 선택 — 알고리즘, 다른 LLM, 사람

빠른 것부터 정밀한 것 순으로

Programmatic으로 회귀를 빠르게 걸러내고, LLM-as-a-Judge로 품질을 채점하고, 뉘앙스가 필요할 때만 사람을 부릅니다.

Programmatic — 알고리즘 · 대량 반복
LLM-as-a-Judge — 점수 + 근거 설명
Human — 주관적 품질 · 뉘앙스

takeaway

셋은 배타적이 아니라 단계적입니다 — CI/CD의 상시 게이트는 자동 평가, 분기 릴리스 같은 큰 변경엔 사람 평가를 더합니다.

PART 2 · 모델 평가 3방식

Programmatic — 알고리즘 채점

LLM 없이 전통 NLP 알고리즘으로 채점하는 가장 빠른 방식

구성	내용
메트릭 3종	Accuracy(정확도) · Robustness(의미 강건성) · Toxicity(유해성)
채점 방식	BERT Score · F1 등 알고리즘 — LLM 호출 없이 결정론적 점수
태스크 유형 5종	Generation · Summarization · QuestionAndAnswer · Classification · Custom
데이터셋	빌트인 데이터셋 제공 또는 직접 준비한 JSONL 사용

언제 쓰나

정답이 명확한 분류·요약 태스크의 대량 회귀 테스트에 적합합니다 — 채점 비용이 없고 결과가 재현됩니다.

PART 2 · 모델 평가 3방식

LLM-as-a-Judge — 동작 흐름

두 모델의 역할 분리 — 답하는 Generator, 채점하는 Evaluator

1
프롬프트 데이터셋
JSONL의 각 prompt를 Generator 모델에 전달
2
Generator 응답
평가 대상 모델이 응답 생성 — BYOI면 이 단계를 건너뛰고 지참한 응답 사용
3
Evaluator 채점
채점 모델이 메트릭별 프롬프트로 응답을 심사
4
점수 + 설명
점수와 채점 근거 설명을 함께 출력 — 콘솔 히스토그램 · S3 리포트

takeaway

BYOI(Bring Your Own Inference)로 응답 데이터를 직접 지참하면 Bedrock 밖의 모델도 같은 잣대로 평가할 수 있습니다.

PART 2 · 모델 평가 3방식

빌트인 메트릭 11종

품질 8종 + 책임 AI 3종 — API 표기는 Builtin.Correctness처럼 Builtin. 접두사

품질 8종

Correctness — 정답과 일치하는가
Completeness — 요구를 빠짐없이 다루는가
Faithfulness — 근거에 충실한가 (환각 탐지)
Helpfulness — 실제로 유용한가
Coherence — 논리적으로 일관된가
Relevance — 질문과 관련 있는가
FollowingInstructions — 지시를 따르는가
ProfessionalStyleAndTone — 문체가 전문적인가

책임 AI 3종

Harmfulness — 유해한 내용이 있는가
Stereotyping — 고정관념·편향이 있는가
Refusal — 부적절한 요청을 거부하는가

takeaway

11종을 전부 켤 필요는 없습니다 — Correctness · Faithfulness · Helpfulness 3종으로 시작하고, 책임 AI 3종은 안전성 릴리스 게이트로 조합합니다.

PART 2 · 모델 평가 3방식

커스텀 메트릭 — 나만의 채점 기준

빌트인에 없는 도메인 기준은 채점 프롬프트로 직접 정의

템플릿 변수

{{prompt}}: 데이터셋의 사용자 질문 (선택)
{{prediction}}: Generator의 응답 — 유일한 필수 변수
{{ground_truth}}: 기대 정답 (선택)

채점 프롬프트 예시

markdown

# 커스텀 메트릭 "포괄성(Comprehensiveness)" — 채점 기준을 자연어로 정의
당신은 질문과 응답을 보고 답변의 포괄성을 심사합니다.
정확성 · 완결성 · 명료성 · 유용성을 기준으로
하나의 종합 점수를 매기고, 근거를 간단히 설명하세요.

질문:
{{prompt}}

심사할 응답:
{{prediction}}

PART 2 · 모델 평가 3방식

Human — 사람 평가

자동 채점이 놓치는 뉘앙스를 사람이 판정하는 두 가지 경로

자체 작업 팀

우리 회사 직원 · 도메인 전문가

도메인 지식이 필요한 판정에 적합
내부 데이터를 외부에 노출하지 않음
평가 UI는 Bedrock이 제공
커스텀 메트릭 이름으로 평가 항목 정의

AWS 관리형 팀

AWS가 운영하는 평가 인력

평가 인력 확보·운영을 AWS에 위임
대량 평가를 빠르게 처리
별도 인력 비용 발생
범용 품질 판정에 적합

takeaway

주관적 선호·브랜드 톤 같은 기준은 여전히 사람이 정확합니다 — 자동 평가로 거르고, 사람 평가로 확정하는 조합이 실무 패턴입니다.

RAG 평가

Retrieve only · Retrieve & Generate · 인용 메트릭

PART 3 · RAG 평가

RAG 평가 2가지 유형

검색만 볼지, 최종 답변까지 볼지 — 평가 범위의 선택

Retrieve only

검색 품질만 평가

질문에 맞는 문서를 가져오는지 검증
메트릭 — Context Relevance · Context Coverage
청킹 · 임베딩 · 검색 설정 튜닝에 사용
생성 모델 비용 없이 빠른 반복

Retrieve & Generate

검색 + 생성 통합 평가

사용자가 받는 최종 답변을 검증
메트릭 — Correctness · Faithfulness 등 8종
생성 모델 · 프롬프트까지 포함한 종단 품질
릴리스 전 최종 게이트로 사용

takeaway

Retrieve only로 검색부터 잡고, Retrieve & Generate로 종단을 확인합니다.

PART 3 · RAG 평가

RAG 메트릭 맵

검색 · 생성 · 책임 AI · 인용 — 네 축의 메트릭 구성

축	메트릭	무엇을 잡아내나
검색 (Retrieve only)	ContextRelevance · ContextCoverage	가져온 문서가 질문과 관련 있는가 · 필요한 근거를 빠짐없이 가져왔는가
생성 (R&G)	Correctness · Completeness · Helpfulness · LogicalCoherence · Faithfulness	정답 일치 · 완결성 · 유용성 · 논리성 · 근거 충실(환각)
책임 AI (R&G)	Harmfulness · Stereotyping · Refusal	유해성 · 편향 · 거부 동작
인용 (Citation)	Citation Precision · Citation Coverage	인용이 정확한가 · 근거를 빠짐없이 인용했는가

takeaway

축의 순서가 곧 진단 순서입니다 — 검색 축이 무너지면 생성 축 점수는 의미가 없으므로 검색부터 확인합니다.

PART 3 · RAG 평가

RAG 평가 데이터셋 형식

conversationTurns 구조 — 모델 평가의 평면 형식과 다른 점에 주의

json

// RAG 평가 데이터셋 — 한 줄이 하나의 평가 케이스 (JSONL)
{
  "conversationTurns": [{
    "prompt": {
      "content": [{ "text": "예약 당일 취소 시 수수료는?" }]     // ①
    },
    "referenceResponses": [{
      "content": [{ "text": "당일 취소 시 1만원의 수수료가 부과됩니다." }]  // ②
    }]
  }]
}

// BYOI(외부 RAG 평가)면 output 필드에 응답과 검색 결과를 함께 지참
// "output": { "text": "...", "knowledgeBaseIdentifier": "...",
//             "retrievedPassages": { "retrievalResults": [...] } }   // ③

① prompt — 사용자 질문. 실제 서비스에 들어오는 표현 그대로 담습니다
② referenceResponses — 전문가가 작성한 기대 답변, 채점의 기준점(ground truth)
③ BYOI output — 외부 RAG의 응답·검색 결과를 지참하면 Bedrock 밖 시스템도 평가 가능

PART 3 · RAG 평가

Knowledge Base vs 외부 RAG

평가 대상이 Bedrock 안에 있느냐에 따라 달라지는 준비물

Bedrock Knowledge Base 평가

Bedrock 안의 RAG

추론 — Bedrock이 Knowledge Base를 직접 호출해 응답 생성
준비물 — 질문 + 기대 답변만 준비
용도 — Knowledge Base 설정(청킹·검색) 튜닝

외부 RAG 평가 (BYOI)

Bedrock 밖의 RAG — 응답 지참

추론 — 내 파이프라인이 만든 응답을 데이터셋에 지참
준비물 — 질문 + 기대 답변 + 실제 응답 + 검색 결과
용도 — 자체 구축 RAG · 타사 시스템의 벤치마크

takeaway

이 파트는 콘솔·API에서 RAG 평가 잡을 구성하는 기능 관점입니다 — 메트릭 정의·계산 방식·LLM-as-a-Judge 원리 등 RAG 평가 방법론 심화는 RAG 평가 모듈에서 다룹니다.

평가 작업 실행

데이터셋 원칙 · API · 결과 해석

PART 4 · 평가 작업 실행

좋은 데이터셋의 조건

평가의 품질은 데이터셋의 품질을 넘지 못하는 구조

실사용 질문

구어체·모호한 표현 포함 — CloudWatch 로그의 실제 질문에서 수집

카테고리 균형

주제별 최소 5개씩 균등 분포 — 한 주제 쏠림은 착시를 만듦

검증 가능한 정답

전문가가 작성한 명확한 기대 답변 — 채점의 기준점

엣지 케이스

복합 질문 · 부정형 · 비교 질문 — 실패가 시작되는 지점

크기 가이드

최소 30개로 시작해 프로덕션에서는 100개 이상을 목표로 합니다 — 같은 데이터셋을 유지해야 버전 간 비교가 성립합니다.

PART 4 · 평가 작업 실행

create_evaluation_job — API 실행

Knowledge Base 통합 평가 한 번의 호출 — 채점 모델 지정이 필수

python

bedrock = boto3.client("bedrock", region_name="us-east-1")
response = bedrock.create_evaluation_job(
    jobName="restaurant-rag-eval-001",
    roleArn="arn:aws:iam::123456789012:role/BedrockEvalRole",
    applicationType="RagEvaluation",                          # ①
    inferenceConfig={"ragConfigs": [{"knowledgeBaseConfig": {
        "retrieveAndGenerateConfig": {"type": "KNOWLEDGE_BASE",
            "knowledgeBaseConfiguration": {"knowledgeBaseId": "KB-RESTAURANT-001",
                "modelArn": "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-sonnet-4-6"}}}}]},
    evaluationConfig={"automated": {
        "evaluatorModelConfig": {"bedrockEvaluatorModels": [  # ②
            {"modelIdentifier": "anthropic.claude-sonnet-4-5-20250929-v1:0"}]},
        "datasetMetricConfigs": [{"taskType": "QuestionAndAnswer",
            "metricNames": ["Builtin.Correctness",            # ③
                "Builtin.Faithfulness", "Builtin.Helpfulness"],
            "dataset": {"name": "restaurant-eval-dataset", "datasetLocation": {"s3Uri": "s3://restaurant-eval/dataset.jsonl"}}}]}},
    outputDataConfig={"s3Uri": "s3://restaurant-eval/results/"})

① applicationType — RagEvaluation 또는 ModelEvaluation, 잡의 종류를 먼저 선언
② evaluatorModelConfig — 채점 모델 지정(큐레이션 목록 한정 — Claude는 Sonnet·Opus·Haiku 4.5 세대까지), Knowledge Base·judge 평가의 필수 필드
③ metricNames — Builtin. 접두사로 빌트인 메트릭 조합, RAG 필수 3종부터 시작

PART 4 · 평가 작업 실행

콘솔 · API · CLI 선택

탐색은 콘솔, 운영 자동화는 API라는 역할 분담

방식	강점	한계
콘솔	시각적 설정 · 점수 히스토그램 · 채점 근거 열람	자동화 불가 — 수동 반복
API (boto3)	CI/CD 통합 · 스케줄 실행 · 파이프라인 단계 삽입	초기 코드 작성 필요
CLI	스크립트 통합 용이	복잡한 설정은 JSON 파일 필요

takeaway

IAM 역할에는 S3 읽기/쓰기 · InvokeModel · RetrieveAndGenerate 권한이 모두 필요합니다 — 권한 부족은 불분명한 FAILED로 끝나니 먼저 점검합니다.

PART 4 · 평가 작업 실행

결과 해석

점수를 행동으로 바꾸는 경험 규칙

S3 리포트: 질문별 메트릭 점수 + 채점 근거 설명 + 전체 평균 — JSON 출력
콘솔 히스토그램: 점수 분포 한눈에 — 평균이 같아도 분포가 갈리면 원인이 다름
Faithfulness < 0.8: 환각 위험 신호 — 프롬프트에 근거 강제, temperature 하향
Correctness < 0.7: 검색 실패 신호 — 청킹·임베딩·Top-K 재점검

takeaway

임계값은 절대 기준이 아니라 경험 규칙입니다 — 중요한 것은 같은 데이터셋에서의 추이입니다.

반복 개선 루프

baseline · 진단 · 조정 · 재평가 · CI/CD 게이트

PART 5 · 반복 개선 루프

개선 루프

한 바퀴 돌 때마다 한 가지만 바꾸는 사이클

takeaway

변수를 두 개 이상 함께 바꾸면 무엇이 효과였는지 알 수 없습니다 — 루프의 속도보다 인과의 추적이 먼저입니다.

PART 5 · 반복 개선 루프

증상별 조정 가이드

낮은 메트릭에서 조정 지점으로 가는 진단표

증상	유력 원인	조정
Context Relevance ↓	청크가 너무 큼	chunk_size 축소 (500 → 300)
Context Relevance ↓	임베딩 품질	임베딩 모델 교체 (Titan V2 · Cohere)
Faithfulness ↓	프롬프트 근거 강제 부족	"반드시 문서 근거로" 지시 강화
Faithfulness ↓	temperature > 0	temperature=0 고정
Correctness ↓	검색 잡음	Top-K 축소 · 메타데이터 필터 추가

takeaway

같은 메트릭 하락이라도 원인은 여러 갈래입니다 — 한 번에 한 행씩 적용하고 재평가해야 인과가 남습니다.

PART 5 · 반복 개선 루프

개선 우선순위

여러 메트릭이 낮을 때 무엇부터 잡을지의 판단

Faithfulness가 최저

환각이 가장 위험한 실패
프롬프트 · temperature부터 조정
근거 인용 강제 후 재평가

언제 — 최우선 해결

Correctness가 최저

검색 파이프라인 문제 신호
청킹 · 임베딩 · Top-K 점검
Retrieve only 잡으로 검색만 분리 평가

언제 — 검색부터 분리 진단

여러 메트릭 동시 하락

데이터 품질 자체를 의심
원본 문서의 최신성 · 누락 확인
데이터셋 정답의 오류 가능성도 점검

언제 — 데이터부터 확인

takeaway

우선순위의 기준은 위험도입니다 — 환각을 만드는 Faithfulness가 최우선이고, 동시 하락이면 데이터부터 의심합니다.

PART 5 · 반복 개선 루프

CI/CD 품질 게이트

사람이 잊어도 파이프라인이 평가를 잊지 않는 구조

1
변경 감지
프롬프트·파이프라인 변경 커밋이 평가를 자동 트리거
2
배치 평가
CodePipeline 단계에서 create_evaluation_job 실행
3
판정
baseline 대비 5% 이상 하락이면 배포 차단 (Quality Gate)
4
배포 · 추적
통과 시 배포, 주 1회 정기 평가로 CloudWatch에 추이 기록

takeaway

Step Functions로 "평가 → 판정 → 배포/롤백"을 묶으면 평가 없는 릴리스가 구조적으로 불가능해집니다.

PART 5 · 반복 개선 루프

개선 루프의 전제

같은 데이터셋 · 같은 잣대 — 배치 평가를 릴리스의 관문으로

같은 데이터셋, 같은 잣대 — 그래야 개선이 보인다

모델도 RAG도, 평가 없는 변경은 도박입니다 — 배치 평가를 릴리스의 관문으로 세우세요.

실습 — Bedrock Evaluations

⏱ 40분

LLM-as-a-Judge로 Claude와 Nova를 같은 데이터셋으로 비교 평가합니다

학습 목표

평가 데이터셋(JSONL) 준비와 S3 업로드
Model Evaluation 잡 생성 — LLM-as-a-Judge
평가 방법 비교와 전략 정리

Amazon Bedrock Evaluations

Bedrock Evaluations 개요

Bedrock Evaluations

모델과 RAG를 같은 잣대로 채점한다

평가 작업 5종 지도

평가 워크플로우 5단계

Bedrock Evaluations의 경계

모델 평가 3방식

모델 평가 3방식

빠른 것부터 정밀한 것 순으로

Programmatic — 알고리즘 채점

LLM-as-a-Judge — 동작 흐름

빌트인 메트릭 11종

품질 8종

책임 AI 3종

커스텀 메트릭 — 나만의 채점 기준

템플릿 변수

채점 프롬프트 예시

Human — 사람 평가

자체 작업 팀

AWS 관리형 팀

RAG 평가

RAG 평가 2가지 유형

Retrieve only

Retrieve & Generate

RAG 메트릭 맵

RAG 평가 데이터셋 형식

Knowledge Base vs 외부 RAG

Bedrock Knowledge Base 평가

외부 RAG 평가 (BYOI)

평가 작업 실행

좋은 데이터셋의 조건

실사용 질문

카테고리 균형

검증 가능한 정답

엣지 케이스

create_evaluation_job — API 실행

콘솔 · API · CLI 선택

결과 해석

반복 개선 루프

개선 루프

증상별 조정 가이드

개선 우선순위

Faithfulness가 최저

Correctness가 최저

여러 메트릭 동시 하락

CI/CD 품질 게이트

개선 루프의 전제

같은 데이터셋, 같은 잣대 — 그래야 개선이 보인다

실습 — Bedrock Evaluations

학습 목표