GenAI 애플리케이션은 "돌아간다"와 "믿고 쓸 수 있다" 사이의 거리가 멉니다. AIP-C01 도메인 5(테스트, 검증 및 문제 해결, 11%)는 이 거리를 좁히는 방법을 묻습니다. ROUGE나 BLEU 같은 전통적인 지표만으로는 부족하고, RAG 평가, LLM-as-a-judge, 에이전트 평가, 그리고 "답이 이상할 때 어디부터 확인하는가"를 알아야 합니다. 이번 포스팅에서는 Amazon Bedrock Evaluations의 평가 유형과 지표, RAG와 에이전트의 문제를 단계별로 진단하는 방법, 배포 전후 품질 관리까지 정리합니다.
GenAI 평가가 전통 ML 평가와 다른 점
분류 모델은 정답 레이블과 비교해 정확도를 계산하면 됩니다. 하지만 생성형 모델의 답변은 정답이 하나가 아니고, 같은 내용을 다른 단어로 표현해도 맞는 답입니다. 그래서 공식 가이드 5.1.1은 관련성, 사실 정확성, 일관성, 유창성처럼 답변의 질을 직접 보는 기준을 요구합니다.
평가 방법은 크게 세 가지이며, 하나만 쓰기보다 섞어서 씁니다.
| 방법 | 방식 | 장점 | 한계 | |------|------|------|------| | 자동 지표 | ROUGE, BERTScore, 정확도 등 계산 | 빠르고 저렴, 반복 가능 | 의미·사실 여부를 잘 못 봄 | | LLM-as-a-judge | 평가 모델이 기준에 따라 점수와 이유 제시 | 의미 수준 평가를 대량으로 | 평가 모델의 편향, 비용 | | 사람 평가 | 작업자가 평점·비교 | 미묘한 품질·업무 적합성 판단 | 느리고 비쌈, 규모 한계 |
Amazon Bedrock Evaluations 한 번에 정리
Bedrock Evaluations는 모델과 RAG 시스템을 평가하는 관리형 기능입니다. 평가 데이터셋(프롬프트, 선택적으로 정답)을 S3에 JSONL로 올리고 작업을 만들면, 결과가 콘솔 요약과 S3 보고서로 나옵니다. LLM-as-a-judge 모델 평가 데이터셋은 한 줄에 프롬프트 하나를 담으며, 정답과 분류용 카테고리는 선택 사항입니다.
카테고리를 붙여 두면 결과 보고서에서 "환불 질문은 점수가 높은데 배송 질문은 낮다"처럼 유형별 약점을 바로 찾을 수 있습니다.
| 평가 유형 | 대상 | 대표 지표 | |-----------|------|-----------| | 모델 평가(자동) | 모델 응답 | 정확도(Accuracy), 견고성(Robustness), 유해성(Toxicity) | | 모델 평가(LLM-as-a-judge) | 모델 응답 | Correctness, Completeness, Faithfulness, Helpfulness, Relevance, Following instructions, Harmfulness 등 + 사용자 정의 지표 | | 모델 평가(사람) | 모델 응답 | 자체 작업 팀의 평점·선호 비교 | | RAG 평가(검색만) | Knowledge Base 검색 결과 | Context relevance, Context coverage | | RAG 평가(검색 + 생성) | 검색 결과와 생성 답변 | Correctness, Completeness, Faithfulness, Citation precision, Citation coverage 등 |
시험에 자주 나오는 지표의 뜻을 정확히 구분해 둡니다.
: 답변이 주어진 문맥(검색된 문서)에 없는 내용을 지어냈는지. 할루시네이션 측정의 핵심입니다. : 검색된 청크가 질문과 관련 있는지. : 검색된 청크가 정답에 필요한 정보를 모두 담고 있는지. 정답(ground truth)이 있어야 계산됩니다. 과 : 인용한 출처가 실제로 맞는지, 답변의 주장이 인용으로 충분히 뒷받침되는지.
Bedrock 밖의 모델이나 직접 만든 RAG 시스템도 평가할 수 있습니다. 응답을 미리 생성해 데이터셋에 넣는 "자체 추론 응답 가져오기" 방식을 쓰면 Bedrock은 호출 단계를 건너뛰고 평가만 수행합니다.
LLM-as-a-judge 잘 쓰는 법
LLM-as-a-judge 작업에는 답변을 만드는 생성 모델과 점수를 매기는 평가 모델, 두 개의 모델이 필요합니다. 평가 모델은 지표마다 정해진 프롬프트로 점수를 매기고 이유를 설명하므로, 낮은 점수를 받은 답변의 원인을 바로 읽을 수 있습니다.
기본 제공 지표 외에 "브랜드 말투 준수", "필수 고지 문구 포함"처럼 업무 기준을 사용자 정의 지표로 만들 수 있습니다. 평가 모델은 자기와 비슷한 모델의 답을 후하게 보거나, 긴 답을 선호하는 경향이 있을 수 있습니다. 생성 모델과 다른 모델을 평가자로 쓰고, 일부 샘플은 사람이 다시 채점해 평가 모델의 점수와 얼마나 일치하는지 확인합니다(보정, calibration). 공정성 평가(공식 가이드 3.4.2)도 같은 방식으로 자동화합니다. 성별이나 지역만 바꾼 질문 쌍을 만들어 답변 품질이 달라지는지 평가 모델로 비교합니다.
RAG 진단: 검색 문제인가, 생성 문제인가
RAG 답변이 틀렸을 때 가장 먼저 할 일은 모델이 실제로 어떤 문서를 받았는지 확인하는 것입니다. API로 검색만 따로 실행해 상위 청크를 보거나, 응답의 인용(citations)을 확인합니다.
필요한 정보가 검색 결과에 없다면 검색 문제입니다.
청크가 너무 커서 핵심이 묻히거나 너무 작아서 문맥이 끊김: 청킹 전략(고정 크기, 계층적, 시맨틱)과 크기를 조정합니다. 표와 다단 레이아웃이 깨져서 추출됨: 파싱 방식을 FM 파서나 Bedrock Data Automation으로 바꿉니다. 다른 부서·버전의 문서가 섞여 나옴: 메타데이터를 붙이고 메타데이터 필터로 검색 범위를 좁힙니다. 제품 코드나 고유명사가 검색되지 않음: 키워드 검색을 함께 쓰는 하이브리드 검색을 켭니다. 관련 청크가 상위 결과 밖에 있음: 검색 결과 수를 늘리고 리랭커 모델로 순서를 다시 매깁니다. 임베딩 모델을 바꾼 뒤 성능이 떨어짐: 기존 벡터와 새 질문 벡터가 호환되지 않으므로 전체 문서를 다시 임베딩해야 합니다. 최신 정보가 안 나옴: 데이터 소스 동기화(수집 작업)가 최신인지 확인합니다.
필요한 정보가 검색되었는데도 답이 틀렸다면 생성 문제입니다. 프롬프트에 "제공된 문서에 근거해서만 답하고, 없으면 모른다고 답하라"를 명시하고 인용을 요구합니다. 문맥이 너무 길어 중간 내용을 놓치거나 컨텍스트 창을 넘어 잘리는 경우(공식 가이드 5.2.1)에는 넘기는 청크 수를 줄이거나 요약합니다. 운영 중에는 Guardrails의 contextual grounding check로 근거 없는 답변을 걸러냅니다.
!검색 문제인가, 생성 문제인가?
에이전트 평가: 작업 완료율과 도구 사용 정확도
공식 가이드 5.1.7은 에이전트를 답변 품질만이 아니라 "일을 제대로, 효율적으로 끝냈는가"로 평가하라고 요구합니다.
작업 완료율: 목표를 끝까지 달성한 시나리오의 비율 도구 사용 정확도: 올바른 도구를 올바른 파라미터로 호출했는지 추론 품질: 다단계 흐름에서 각 판단이 합리적이었는지 효율: 작업 하나에 든 단계 수, 지연 시간, 토큰 비용
예를 들어 "주문 ORD-123을 취소하고 환불 금액을 알려줘"라는 시나리오라면 기대하는 순서는 → → 입니다. 방법은 이처럼 목표와 기대하는 도구 호출 순서를 담은 테스트 시나리오를 만들어 실행하고, 로 받은 trace의 실제 호출 순서·파라미터와 비교하는 것입니다. 엉뚱한 도구를 고르면 도구 설명(description)을 고치고, 같은 호출을 반복하면 최대 반복 횟수를 두고, 파라미터 오류가 잦으면 Lambda에서 입력 스키마 검증을 강화합니다. 운영 중에는 도구 호출 실패율과 반복 횟수를 CloudWatch 지표로 수집해 평소와 다른 패턴을 감지합니다(4.3.4).
배포 전후 품질 관리: 골든 데이터셋, 품질 게이트, 카나리
골든 데이터셋은 대표 질문과 기대 답변, 근거 문서를 묶은 고정 평가 세트입니다. 프롬프트, 모델, 청킹 설정이 바뀔 때마다 같은 세트로 평가해 이전보다 나빠지지 않았는지 확인합니다.
품질 게이트: CodePipeline에서 변경이 들어오면 Bedrock 평가 작업을 실행하고, faithfulness나 correctness가 기준보다 낮으면 배포를 멈춥니다. 카나리·A/B 테스트: 트래픽 일부만 새 버전으로 보내 사용자 평점과 업무 지표를 비교합니다. Prompt Management의 버전이나 AppConfig 설정으로 전환하고, 문제가 있으면 즉시 되돌립니다. 배포 검증(5.1.9): 합성 사용자 시나리오를 실행하고, 같은 질문에 대한 이전 답변과 새 답변을 비교(output diffing)해 의미가 달라졌는지 확인합니다. 지속 평가: 호출 로그에서 샘플을 뽑아 주기적으로 LLM-as-a-judge로 채점하고 점수를 CloudWatch 지표로 올려 알람을 겁니다.
자주 만나는 오류와 진단 도구
| 증상 | 원인 | 확인·해결 | |------|------|-----------| | 입력이 너무 길다는 ValidationException | 컨텍스트 창 초과 | 토큰 수 사전 계산, 청크 수 축소, 대화 기록 요약 | | 답변이 중간에 끊김 | 이 | 상향 또는 출력 형식 축소 | | JSON 파싱 실패 | 출력 형식 불일치 | 스키마 검증, 도구 사용(tool use)으로 구조화 출력 강제 | | 특정 유형의 질문에서만 이상한 답 | 프롬프트 혼동 | CloudWatch Logs Insights로 호출 로그의 프롬프트·응답 검색, 프롬프트 버전 비교 | | 어느 구간이 느린지 모름 | 분산 호출 구조 | X-Ray로 Lambda → Knowledge Base → Bedrock 구간별 지연 추적 | | 같은 질문에 답이 매번 크게 달라짐 | 가 높음 | 값을 낮추고 같은 입력을 여러 번 실행해 일관성 확인 | | 정상 질문이 Guardrails에 막힘 | 필터 강도 과다, 거부 주제 정의가 넓음 | Guardrails trace로 어떤 정책이 개입했는지 확인 후 조정 |
시험 핵심 정리
"RAG 답변이 검색 문서에 없는 내용을 지어냈는지 측정" -- Faithfulness (RAG 평가) "검색된 청크가 질문과 관련 있는지" -- Context relevance (검색만 평가) "검색 결과가 정답에 필요한 정보를 모두 담았는지" -- Context coverage (정답 데이터 필요) "인용 출처가 정확한지" -- Citation precision / Citation coverage "의미 수준의 품질을 대량으로 자동 채점" -- Bedrock Evaluations LLM-as-a-judge "업무 고유 기준으로 채점" -- 사용자 정의 지표(custom metrics) "외부 모델·외부 RAG 결과 평가" -- 자체 추론 응답 가져오기(bring your own responses) "평가 모델 점수의 신뢰성 확인" -- 사람 평가 샘플로 보정 "필요한 정보가 검색되지 않음" -- 청킹·메타데이터 필터·하이브리드 검색·리랭킹 점검 "임베딩 모델 교체 후 검색 품질 저하" -- 전체 문서 재임베딩(재인덱싱) "에이전트가 엉뚱한 도구를 호출" -- trace로 호출 순서 확인 + 도구 설명 개선 "프롬프트 변경 후 품질 저하 방지" -- 골든 데이터셋 + CI/CD 품질 게이트