AIP-C01 영역 5 — 평가·검증·문제 해결

평가 시스템은 점수뿐 아니라 무엇을 평가했고 무엇이 실패했는지 설명해야 한다. 먼저 품질 기준·평가 데이터·비교 조건을 정하고, 검색·생성·도구·운영 문제를 각각 진단한다. 이후 같은 실패 사례와 정상 사례를 재검증해 변경의 효과를 확인한다.

5.1 평가 시스템: 점수보다 평가 계약과 실패 처리

공식 작업 5.1에는 아홉 기술이 포함된다. 품질 평가에서 에이전트의 실제 작업 완료, 보고, 배포 검증까지 각각 다른 질문을 다룬다. AIP 영역 5 공식 자료와 함께 읽는다.

5.1.1 다차원 품질과 합격 조건

관련성(Relevance)은 답변이 질문에 맞게 응답했는지를 평가한다. 사실적 정확성(factual accuracy)은 기준 시점의 사실과 맞는지, 충실도(Faithfulness)는 제공된 근거가 답변을 뒷받침하는지를 살핀다. 일관성(consistency)은 같은 조건에서 나온 여러 응답이 서로 모순되지 않는지를, 논리적 일관성(logical coherence)은 한 응답 안의 설명이 논리적으로 이어지는지를 다룬다. 유창성(fluency)은 표현이 자연스럽고 읽기 쉬운지를 평가한다. 유창하지만 틀린 답변과, 사실은 맞지만 질문에 답하지 않은 응답은 구분해야 한다. 평가 데이터에는 질문, 적용 조건, 정답과 허용 가능한 답, 근거, 언어, 위험 등급, 평가 버전을 기록한다. 정답이 여러 개인 과제에서는 표현이 글자 단위로 같아야 한다고 요구하지 않는다.

대규모 언어 모델(large language model, LLM) 심사자는 루브릭과 근거로 채점하는 도구이며 절대적인 사실 원천이 아니다. 생성 모델과 평가 모델을 구별하고 자체 응답/BYOI를 가져오는 경우에도 입력 계약·데이터 권한·평가자 지원을 확인한다. 심사자 버전·평가 프롬프트가 바뀌면 점수 비교 조건도 바뀐다. 사람 판정과 일치도·중요 오류 누락을 점검하고 평가 대상 답 속 지시가 심사 규칙을 바꾸지 않게 한다.

가중 평균(weighted average)은 여러 평가 지표를 하나로 요약한 값이다. 안전·개인정보·핵심 정답 실패를 높은 유창성 점수로 상쇄해서는 안 된다. 예제 구현은 관련성·정확성·유용성 가중 2, 나머지 3 축 가중 1의 평균을 요청한다. 자체 재계산식은 (2R+2A+2H+C+F+K)/9이며 점수 범위·누락·숫자 타입을 먼저 검증한다. 모델이 계산한 overall_score를 그대로 신뢰하지 않는다. 모델 평가와 RAG 평가, LLM 평가자, 평가자 지표의 의미 참조.

5.1.2 모델 비교와 A/B·카나리의 목적 차이

오프라인 평가(offline evaluation)는 같은 평가 세트, 정책, 근거, 버전 조건에서 후보 모델의 품질·비용·지연 시간을 비교하는 방법이다. A/B 테스트(A/B testing)는 사용자나 요청을 통제된 방식으로 나누어 서로 다른 구성의 결과를 비교한다. 카나리 배포(canary deployment)는 실제 트래픽의 일부에 새 버전을 적용하고 문제를 확인하면서 적용 범위를 늘리는 방식이다. 카나리 배포를 했다는 사실만으로 통계적으로 원인과 결과를 비교할 수 있는 것은 아니다. 오프라인 평가에서 가장 좋았던 모델도 실제 운영 데이터에서 다시 검증해야 한다.

요청 길이·유형·고객 집단·시간대가 다르면 평균 점수 비교가 왜곡될 수 있다. 비용에는 생성뿐 아니라 심사·검색·재시도·검토를 넣고 지연은 첫 토큰까지 걸린 시간(time to first token, TTFT)·전체·꼬리 지연을 나눈다. 실패 응답을 제외한 평균만 보고하지 않는다. 토큰당 품질·초당 품질은 자체 지표의 방향과 한계가 있으며 모델별 가격이 달라 토큰수만으로 비용을 비교할 수 없다. 자동 평가 보고서 해석는 입력 수와 성공 응답 수의 차이로 생기는 누락 편향을 보완한다.

5.1.3 사용자 피드백은 표본·맥락·주석 기준이 필요

평점(rating)은 어떤 답변·모델·프롬프트(prompt)·시점·업무에 대한 것인지 함께 기록한다. 감정 분석(sentiment analysis)은 불만 주제를 찾는 데 도움을 주지만, 부정 감정이 곧 오답, 긍정 감정이 곧 안전한 정답은 아니다. 자발적 피드백은 불만이 큰 사용자나 열성 사용자에 편향될 수 있어 무응답 집단과 실제 해결 결과도 본다.

전문가 주석에는 구체 기준·예시·중복 표본·불일치 조정·개인정보 접근권한이 필요하다. 동의 없는 민감정보를 외부 심사자에게 전송하지 않는다. 원문을 학습에 재사용할 수 있는지와 품질 조사 목적으로 볼 수 있는지도 별도다. API Gateway/DynamoDB는 수집·저장의 수단이지 평가의 대표성이나 법적 근거를 만들어 주지 않는다. 강좌 관련 항목 Ground Truth 주석 흐름은 교육 선택지이며 실제 작업을 만들지 않았다.

5.1.4 회귀와 품질 게이트는 재현 가능한 배포 조건

회귀 테스트(regression testing)에서는 평가 세트, 프롬프트, 모델, 검색 인덱스(index), 가드레일(guardrail)의 버전을 함께 고정한다. 품질 게이트(quality gate)는 배포 전에 충족해야 할 조건이다. 여기에는 필수 안전 항목, 최소 품질 기준, 오류율·지연 시간·비용의 상한, 평가 실패 시 처리 방법과 승인 책임자를 정한다. 평가를 실행하지 않았거나 결과가 누락됐다면 통과가 아니라 ‘결과 미확인’ 또는 ‘평가 오류’로 처리해야 한다. CodePipeline이나 Step Functions로 절차를 자동화할 수 있지만, 자동화 도구가 평가 기준 자체의 타당성까지 보장하지는 않는다.

테스트 데이터에 맞추어 계속 프롬프트를 바꾸면 평가 세트에 과적합(overfitting)될 수 있다. 개발용·검증용·봉인된 회귀 세트를 분리하고 새 실패 사례는 버전으로 추가한다. 롤백은 모델 이름뿐 아니라 호환되는 프롬프트·도구·스키마·정책을 복원한다. Model Registry, AWS Step Functions 오류 처리를 연결한다.

5.1.5 RAG·사람·모델 심사의 결합

검색 전용 평가(retrieval-only evaluation)는 필요한 근거를 찾았는지 확인한다. 검색·생성 평가(retrieval-and-generation evaluation)는 검색한 근거를 활용해 좋은 답변을 만들었는지까지 살핀다. 원문이 없거나 오래된 문제와 근거를 무시한 생성 오류를 분리한다. 사람 평가는 업무 적합성과 고위험 경계에서 중요하지만 비용·일관성·처리 시간의 제약이 있어 자동 검증과 조합한다. 적대적 평가는 허가된 격리 데이터·모의 도구로 수행하며 실제 부작용을 발생시키지 않는다.

평가자 01 정규화 점수와 예제 구현의 사용자 지정 110점수를 섞지 않는다. 점수 방향도 정확성과 유해성에서 다를 수 있다. 참조자료가 없는데 평가자가 자신 있게 사실적 정확성 점수를 줘도 검증된 정답으로 간주하지 않는다. RAG 평가, LLM 평가자 참조.

5.1.6 검색·인용 지표의 분모

재현율(Recall)@k는 정한 관련 문서 중 상위 k에 포함된 비율, 정밀도(Precision)@k는 상위 k 중 관련 문서 비율로 정의할 수 있다. 여러 정답 근거가 있거나 정답 목록이 불완전하면 수치의 한계를 표시한다. 순위 지표는 정답 후보가 얼마나 위에 있는지를, 검색 지연은 실제 반환까지 시간을 본다. 청크 중복으로 적중을 부풀리지 않는다.

인용 정밀도(citation precision)는 답변에 붙인 인용이 해당 주장을 실제로 뒷받침하는지를 평가한다. 인용 범위(citation coverage)는 근거가 필요한 주장 중 인용과 근거가 연결된 비율을 평가한다. 링크가 열린다고 그 자료가 주장을 뒷받침하거나, 시점이 맞거나, 사용할 권리가 있거나, 사용자가 열람할 수 있는 것은 아니다. 확인하지 못한 주장을 분모에서 빼면 성능이 실제보다 높게 보일 수 있다. 예제의 supported(근거가 뒷받침함), contradicted(근거와 모순됨), not_mentioned(근거에 언급되지 않음) 세 상태를 구분한다. not_mentioned를 자동으로 거짓이나 정답으로 바꾸지 않는다. 검색 필터·리랭킹·질의 분해, 청킹의 설계 절충, 자동 평가 보고서 해석에서 관련 조건을 확인할 수 있다.

5.1.7 에이전트는 실제 과업과 승인 준수로 평가

‘처리했습니다’라는 문장이 아니라 올바른 대상·도구·인수로 허가된 과업이 확정됐는지 평가한다. 모의 상태에서 완료율·불필요 호출·재시도·시간·토큰(token) 비용·승인 누락·오류 복구를 측정한다. 금융 이체 같은 과업은 실계정 실행 대신 격리된 합성 데이터와 모의 도구를 사용한다. 중간 계획이 훌륭해도 대상 계좌·권한·최종 상태가 틀리면 실패다.

다단계 평가(multi-step evaluation)에는 어느 단계에서 실패했는지와 이후 영향, 작업 인계(handoff), 중복 실행으로 인한 변경, 사람 승인(human approval)의 준수 여부를 포함한다. Agent 평가 제품의 정확 API·지원 범위는 별도이며 강좌의 개요 설명으로 모두 검증했다고 하지 않는다. AgentCore 구성요소와 MCP, 도구 실행 책임 참조.

5.1.8 보고서에는 실패·분포·업무 의미를 남긴다

전체 평균과 함께 유형·언어·고객 집단별 표본 수, 실패 사례, 평가 불능, 비용·지연, 평가자 버전을 보여준다. 비교 차이가 표본 잡음인지 검토하고 그래프 축·산식을 명확히 한다. 이해관계자별 상세 접근권한을 나누며 보고서에 원문 개인정보를 무조건 포함하지 않는다. 운영자는 수정 가능한 원인, 사업 담당자는 해결 성과, 준수 담당자는 검토·승인 증거를 필요로 한다.

강좌 관련 항목의 사실 오류 40% 감소와 규정 99.8% 준수는 가상 시나리오의 목표이지 이 교재 또는 AWS의 실측 보장 수치가 아니다. 규정 준수는 점수만으로 법률적으로 확정되지 않는다.

5.1.9 배포 검증: 섀도우·블루그린·점진 노출

합성 사용자 워크플로(synthetic user workflow)는 실제 사용자 대신 만든 시나리오로 로그인, 검색, 도구 실행, 답변과 오류 처리, 접근 권한을 함께 시험하는 방법이다. 섀도우 테스트(shadow testing)는 새 구성의 결과를 사용자에게 보여 주지 않고 기존 구성과 비교한다. 다만 복제한 요청이 실제 도구를 실행하거나 개인정보를 처리하고 추가 비용을 발생시키지 않도록 통제해야 한다. 블루/그린 배포(blue/green deployment)는 기존 환경과 새 환경을 준비해 전환과 복귀가 가능하도록 하고, 카나리 배포(canary deployment)는 일부 실제 트래픽부터 적용한다. 각 방식에서 성공, 중지, 복구 조건을 미리 정한다.

출력의 표현 변화와 의미 드리프트를 구별한다. 검색 문서가 최신으로 바뀌어 정답이 달라진 것을 모델 회귀로 오인하지 않고, 이전 버전이 항상 안전하다고도 가정하지 않는다. 배포 전·중·후 동일 ID 체인으로 비교하고 실제 회복까지 확인한다. 이번에는 설계만 읽고 배포하지 않았다.

예제 구현의 주의점과 남은 제품 상세

예제에는 문자열과 Markdown 경계가 섞여 있고 _rank_models가 제공되지 않으며 마지막 효율성 함수는 값 없는 return으로 끝난다. 실행 가능한 완성본이 아니다. JSON 파싱 오류 딕셔너리를 정상 평가처럼 확장하는 흐름, 오류 원문 출력, 모델 호출 실패 문자열을 다시 채점하는 흐름을 구분해야 한다.

S3 응답·참조 예시는 의도적 오답·과거 정보가 섞인 테스트 데이터다. 가용성·Select 기능·객체수·출시연도를 현행 상품 설명으로 복제하지 않는다. 정답 참조 자체도 버전·권위를 검증해야 한다. 단어수×1.3은 비용 산출용 정확 토큰이 아니고, 평가자의 가중 산술은 앱에서 재검산해야 한다. 평가 작업/API·카나리 구현·에이전트 전용 지표·통계 검정 상세는 잔여다.

5.2 문제 해결 — 증상과 원인을 분리하고 최소 재현으로 좁히기

근거: 공식 출처 AIP D5. 의료 도우미는 가상 시나리오다. 영상의 8000 토큰·40%/95%감소·99.9%가용성·60%검색향상은 예제 조건·목표이며 현행 모델 한도나 검증된 실적이 아니다. 아래 자체 진단 예시는 의료 판단이 아니라 시스템 처리 원리를 설명한다.

5.2.1 불완전한 답: 입력 누락·출력 제한·연결 단절을 나눈다

우선 실제 요청에 필요한 데이터가 들어갔는지, 입력 컨텍스트 한도를 넘었는지, 출력 상한·중지 시퀀스가 작동했는지, 스트림이 중간에 끊겼는지를 구분한다. 저장 원문이 충분해도 파서/광학 문자 인식(optical character recognition, OCR)·청킹(chunking)·검색·템플릿에서 빠졌을 수 있다. 모델 응답이 짧다는 이유만으로 컨텍스트 한도 문제라 단정하지 않는다. 요청 구조·토큰 사용·종료 이유·필수 항목과 원문 구간을 대조한다.

슬라이딩 창(sliding window)은 긴 문서를 서로 겹치는 구간으로 나누어 처리하지만 구간 사이 인물·시간·단위·부정·예외를 유지해야 한다. 중복으로 정보를 두 번 집계하지 않고 원문 위치와 버전을 남긴다. 문서의 자연스러운 절·방문 날짜·치료 에피소드 같은 경계는 문맥을 보존할 수 있으나 초대형 단락과 표·코드는 추가 분할이 필요하다. 동적 청킹이 항상 고정 청킹보다 우수하다고 가정하지 않고 질문별 근거 검색과 최종 답 품질로 평가한다.

자체 예: 현재 약물과 과거 중단 약물이 다른 창으로 나뉘면 둘을 현재 약물로 합치는 오류가 생길 수 있다. 최근 정보 우선순위도 오래된 필수 금기·알레르기를 삭제하는 규칙이 되어서는 안 된다. 이는 설명용 예시이며 실제 환자 판단은 별도 전문가 검토가 필요하다. 청킹의 설계 절충, Converse 요청과 스트림, CountTokens를 재사용한다.

5.2.2 통합 오류: 응답 코드·권한·스키마·부하의 증거

AccessDenied는 호출 주체·자격 증명 및 액세스 관리(AWS Identity and Access Management, IAM)·리소스 정책·서비스 제어 정책(service control policy, SCP)·리전·모델 조건 등을 조사할 출발점이며 한 정책이 원인이라고 단정하지 않는다. Validation은 모델 ID·지원 리전·필수·허용 필드·범위·콘텐츠 구조를 확인한다. Throttling·quota·timeout·서버오류·스트림 오류는 대응과 재시도 조건이 다르다. 예외 클래스가 공통 ClientError 일 수 있으므로 구조화된 서비스 오류 코드·요청 ID와 실제 응답을 확인한다.

재시도(retry)는 일시적인 오류에 적용하고, 백오프(backoff), 지터(jitter), 전체 대기 시간과 횟수를 제한한다. 권한 오류를 무한히 재시도하거나 오류를 없애려고 자동으로 권한을 확대해서는 안 된다. 시간 초과(timeout) 뒤 작업의 실행 여부를 모른다면 먼저 상태를 확인해 중복 실행을 막는다. 회로 차단(circuit breaking)은 실패가 누적된 대상의 호출을 잠시 막고, 부하 차단(load shedding)은 과도한 요청을 제한해 시스템을 보호한다. 대체 경로인 폴백(fallback)도 데이터 처리 위치, 접근 권한, 품질과 안전 조건을 지켜야 한다. 진단용 로그와 지표를 수집하되 비밀번호·키·토큰·환자 원문을 로그에 넣지 않는다. Step Functions 오류 처리, IAM 인증과 인가, 모델 호출 로깅을 참고한다.

5.2.3 프롬프트 품질: 실패 유형과 버전을 고정한 실험

같은 질문에 답이 달라지면 사실이나 질문 조건이 바뀌었는지 먼저 살핀다. 이어 검색 근거, 모델, 파라미터(parameter), 템플릿(template)의 버전이 바뀌었는지 확인한다. 단순히 ‘더 자세하게’라는 문구를 추가하는 대신 모호한 목적·충돌하는 지침·변수 누락·잘못된 예시·문맥 순서·지원하지 않는 출력 계약을 분리한다. 실패 사례와 정상 회귀 세트에서 한 변화의 영향을 평가하고 필요한 경우 되돌린다.

자동 프롬프트 최적화의 제안은 검토·평가·승인 전에는 배포하지 않는다. 생성된 단계별 설명은 내부 인과 증거가 아니므로 도구 실행·근거·검증 가능한 계산을 우선 확인한다. 사용자 입력·검색 문서를 지시로 승격하지 않는다. 같은 평가 세트에 반복 적응하는 과적합을 피하고 봉인된 검증 범위를 유지한다. 프롬프트 관리, 프롬프트 구성과 퓨샷, 평가자 지표의 의미와 기존 D1 프롬프트 버전 설명을 재사용한다.

5.2.4 검색 문제: 수집에서 답변까지 단계별 진단

원문 존재·읽기 권한 → 파싱·문자 인코딩 → 청크 경계 → 임베딩(embedding) 모델·차원 → 색인 완료 → 질의 전처리 → 권한·메타데이터 필터 → 검색 후보 → 리랭킹 → 컨텍스트 조립 → 생성의 순서로 증거를 확인한다. 이는 독립 진단 절차이며 강좌의 문장 순서를 복제한 것이 아니다. 검색 전용 평가에서 근거가 없으면 생성 모델부터 바꾸는 것은 비효율적이다.

지역 민감 해싱(locality-sensitive hashing, LSH)·계층형 탐색 그래프(Hierarchical Navigable Small World, HNSW)·역파일 인덱스(inverted file index, IVF)·곱 양자화(product quantization, PQ) 등 근사 최근접 이웃 검색(approximate nearest neighbor, ANN) 선택지는 정확도·지연·메모리·구축·갱신 비용이 다르다. 모든 벡터(vector) 엔진이 모든 옵션을 지원한다고 가정하지 않는다. PQ 등 압축은 메모리를 줄일 수 있지만 검색 품질 변화를 측정해야 한다. 임베딩 시각화의 군집만으로 품질을 확정하지 않고 대표 쿼리의 근거 포착과 지연으로 평가한다. 분포 변화와 모델 변경에 따른 좌표계 변화를 혼동하지 않는다.

키워드·시맨틱·하이브리드 경로를 따로 시험하고 숫자·부정·정확 코드·희귀 용어를 포함한다. 원문 삭제·권한 변경이 색인·캐시에 전파됐는지도 검사한다. 검색 필터·리랭킹·질의 분해, Knowledge Bases 동기화, RAG 평가 참조.

5.2.5 유지 관리: 템플릿·스키마·trace를 같은 변경에 연결

템플릿(template)을 검사할 때는 필수 변수가 있는지, 타입(type)이 맞는지, 특수 문자를 올바르게 이스케이프(escape)했는지 확인한다. 빈 값, 길이, 언어, 도구 호출 형식도 검사 대상이다. JSON Schema는 구조와 타입을 검사하지만 내용의 사실 여부나 사용자의 열람 권한까지 확인하지는 않는다. 입력 변수를 채우기 전과 후의 버전을 민감하지 않은 메타데이터로 연결해 두고, 프롬프트 변경과 모델·문서 변경을 구분해야 문제의 원인을 추적할 수 있다.

CloudWatch Logs Insights·X-Ray/ADOT 등은 실제 계측·전파·샘플링이 있어야 연결된 증거를 만든다. 관측 파이프라인의 누락·과다수집·비용도 검사한다. 개선 요청 → 가설 → 작은 변경 → 고정 평가 → 검토 → 배포 → 회복 확인을 연결하고 조직 정책과 불일치하면 점수가 좋아져도 승인하지 않는다. 정확한 SDK/trace 지원은 제품별 잔여다.

예제 구현의 주의점: 잘못된 계수와 청크 누락을 방지

Claude가 cl100k_base를 정확히 사용한다는 주석은 공식 근거가 아니며 Titan에 p50k_base를 적용한 것도 근사다. 미확인 모델을 8K로 고정하면 오진한다. 입력 토큰 계산의 정확도와 지원 경계처럼 실제 모델·API에 맞는 입력 계산과 지원 한도를 확인한다.20%여유·75/90%위험선은 예시이지 안전 보장선이 아니다.

첫 헤더 이전의 서문이 분할에서 빠질 수 있고, 큰 단락·문장을 그대로 넣어 상한을 넘길 수 있다. 구분자 추가 토큰·겹침 토큰을 계산하고 청크 ID의 중복과 순서 보존을 검사한다. 이전 버퍼를 비우지 않은 채 큰 섹션을 먼저 추가하면 문서 순서가 뒤바뀔 수 있다. ‘재귀’ 분기 주석의 실제 요약은 구현되지 않았다. 첫 코드의 S3 테스트 문자열·표가 중간에서 끝난 사실과 교육용 S3 수치를 현재 제품 검증으로 사용하지 않는 경계를 유지한다.

API 진단기의 상위키만 가리는 sanitizer는 중첩 system/tools/문자열 JSON/오류 메시지를 놓칠 수 있다. 허용할 메타데이터를 명시하고 민감정보 검사·암호화·권한·보존을 별도 적용한다. naive UTC 시간에 timestamp를 적용할 때 로컬 시간대 오해도 점검한다. success=error 없음은 실제 업무 완료 증거가 아니다. _publish_metrics가 미제공이고 알 수 없는 오류의 반환 경로도 없다.

상황형 자기점검

다음 문항은 이 교재에서 직접 만든 학습 문제다. AWS 공식 문제·실제 기출·시험 복원 문제가 아니며 합격을 보장하지 않는다. 각 문항은 제시된 조건에서 가장 적절한 답 하나를 고른다. 정답을 보기 전에 다른 선택지가 요구 조건을 충족하지 못하는 이유도 설명해 보자.

1. 검색 분모와 생성 품질

자체 평가에서 한 질문의 관련 문서는 총 4개다. 상위 5개 검색 결과 중 서로 다른 관련 문서는 2개이고 나머지 3개는 무관하다. Precision@5와 Recall@5 및 해석은?

• A. 정밀도 40%, 재현율 50%이며 생성 답의 정확성은 별도 검사한다
• B. 정밀도 50%, 재현율 40%이며 답은 항상 정답이다
• C. 둘 다 100%다. 관련 문서를 한 개 이상 찾았다
• D. 생성 문장이 자연스러우면 검색 분모는 필요 없다

2. 잘린 답을 고치는 순서

답이 짧게 끝나며 실제 요청에는 필수 문서가 모두 포함돼 있다. API 종료 이유는 출력 토큰 상한 도달이고 JSON도 중간에서 끊겼다. 우선 조치는?

• A. AccessDenied로 분류하고 IAM 권한을 넓힌다
• B. 허용 컨텍스트 안에서 출력 예산·형식을 조정하고 완결성 검증 후 다시 평가한다
• C. 입력이 충분하므로 부분 JSON을 그대로 실행한다
• D. 출력 원인 확인 없이 벡터 인덱스를 모두 교체한다

전체 학습 목표와 영역별 자기점검