5장. 평가와 개선

학습 목표

• 성공 기준을 관찰 가능한 통과 조건이 있는 루브릭으로 바꾸고, 치명적 오류를 따로 정한다.
• 실제 분포와 경계 사례를 반영한 테스트 세트를 만들고, 개선용과 확인용을 나눈다.
• 기준마다 코드·사람·LLM 채점 중 알맞은 방법을 고르고, LLM 평가자를 사람 판정으로 보정한다.
• 변경 전후를 같은 세트로 비교해 회귀를 찾고, 결과를 묶음별로 나눠 읽는다.
• 실패 사례를 유형과 발생 단계로 분류해 다음 수정을 정한다.

들어가며

해외영업팀이 쓰는 사내 번역 도우미의 프롬프트에 누군가 “더 자연스럽게 옮길 것”이라는 한 줄을 더했습니다. 팀장은 결과 몇 건을 훑어보고 문장이 한결 매끄러워졌다며 만족했습니다. 한 달 뒤 계약 서류 검토에서 문제가 드러났습니다. 납품 기한을 뜻하는 표현이 ‘까지’와 ‘부터’로 뒤바뀐 번역이 여러 건 나왔고, 모두 수정 전에는 정확히 옮기던 종류의 문장이었습니다. 팀장이 훑어본 몇 건에는 기한 표현이 하나도 없었습니다. 팀은 잘못한 것이 없다고 느꼈습니다. 분명히 좋아진 결과를 보았으니까요. 문제는 무엇을 보았느냐가 아니라 무엇을 보지 않았느냐였습니다. 평가는 바로 그 보지 않은 부분을 보게 만드는 장치입니다. OpenAI의 평가 모범 사례도 “잘 돌아가는 것 같다”를 평가 전략으로 삼는 것을 대표적인 안티패턴으로 꼽습니다.

이 장은 그 느낌을 숫자로 바꾸는 법을 다룹니다. 성공 기준을 평가 항목과 루브릭으로 옮기고, 테스트 세트를 만들어 개선용과 확인용으로 나누고, 기준마다 채점 방법을 고르고, LLM 평가자의 한계를 관리하고, 변동성을 재고, 같은 세트로 전후를 비교하고, 회귀를 관리하고, 실패를 분류해 다음 수정을 정하는 순서입니다. 마지막으로 에이전트처럼 여러 단계를 거치는 시스템을 평가하는 법을 보고, 깊이 읽기에서 점수와 현실의 괴리, 사람 채점의 일관성을 다룹니다.

핵심 개념

평가는 같은 시험지로 다시 보는 것이다

학생이 공부법을 바꾼 뒤 실력이 늘었는지 알려면 같은 난이도의 시험지로 다시 봐야 합니다. 매번 다른 문제를 몇 개 풀어 보고 “잘 본 것 같다”고 느끼는 것은 평가가 아닙니다. 프롬프트도 같습니다. 고정된 테스트 세트로 전후를 비교해야 개선인지 회귀인지 압니다. OpenAI 가이드는 프롬프트를 바꾸거나 모델을 올릴 때 평가 묶음으로 동작을 측정하라고 권하고, 평가 모범 사례는 일찍, 자주 평가하라는 “평가 주도 개발”을 권합니다.

성공 기준을 평가 항목으로

Anthropic 문서는 좋은 성공 기준이 구체적이고(“좋은 성능” 대신 “정확한 감성 분류”), 측정 가능하고, 달성 가능하고, 업무와 관련 있어야 한다고 설명합니다. 그리고 대부분의 작업은 여러 기준을 함께 봐야 한다고 덧붙입니다. 정확도만이 아니라 일관성, 어조, 개인정보 보호, 컨텍스트 활용, 지연, 비용도 기준이 될 수 있습니다.

기준을 평가 항목으로 옮길 때 하나를 더 정합니다. 치명적 오류입니다. 평균 점수로 뭉뚱그리면 어조 점수가 높은 답이 금액을 틀려도 통과할 수 있습니다. 금액, 날짜, 금지된 약속처럼 하나만 틀려도 결과를 쓸 수 없는 항목은 가중 평균에서 빼서 “하나라도 실패하면 불합격”으로 처리합니다.

루브릭을 쓰는 법

1장의 성공 기준을 채점표로 옮긴 것이 루브릭입니다. 좋은 루브릭은 항목마다 무엇을 보면 통과인지가 분명합니다. Anthropic 문서가 드는 예는 “답변의 첫 문장에 회사명이 있어야 하며, 없으면 자동으로 오답이다”입니다.

루브릭을 쓸 때의 원칙은 다음과 같습니다.

1. 관찰 가능한 조건으로 쓴다. “친절하다” 대신 “사과 표현과 해결 방법이 모두 있다”.
2. 척도는 좁게 쓴다. 정답/오답이나 1~5점처럼 판정이 분명한 출력을 받는다. 1~100점은 기준을 더 흐리게 만든다.
3. 점수마다 기준 사례를 붙인다. 1~5점 척도라면 3점짜리와 4점짜리 실제 예를 하나씩 붙여, 채점자가 같은 점수의 의미를 공유하게 한다.
4. 한 항목에 한 가지만 묻는다. “정확하고 간결한가”는 두 항목으로 나눈다.
5. 필요하면 여러 루브릭을 쓴다. Anthropic 문서는 하나의 기준에도 전체를 보려면 여러 루브릭이 필요할 수 있다고 말한다.

테스트 세트 만들기

Anthropic 문서는 평가 설계의 세 원칙을 제시합니다.

1. 작업에 맞춘다. 실제 작업의 분포를 반영하고 경계 사례를 잊지 않는다.
2. 가능하면 자동화한다. 객관식, 문자열 일치, 코드 채점, LLM 채점처럼 자동으로 채점할 수 있게 문항을 설계한다.
3. 양을 우선한다. 손으로 정밀하게 채점한 소수의 문항보다, 신호가 조금 약해도 자동 채점되는 많은 문항이 낫다.

경계 사례로는 관련 없거나 존재하지 않는 입력, 지나치게 긴 입력, 부적절하거나 해로운 사용자 입력, 사람도 판단이 갈리는 모호한 사례를 넣습니다. OpenAI 문서는 전형적인 사례, 경계 사례, 공격적인 사례를 함께 넣으라고 하고, 데이터 원천으로 운영 데이터, 과거 데이터, 전문가가 만든 데이터, 합성 데이터 등을 듭니다. 개발하면서 로그를 남겨 두면 좋은 평가 사례를 캐낼 수 있다고도 덧붙입니다.

시작 규모에 겁먹을 필요는 없습니다. Anthropic의 에이전트 평가 글은 실제 실패에서 뽑은 20~50개 과제로 시작하라고 권하고, 같은 회사의 멀티 에이전트 조사 시스템도 실제 사용에서 뽑은 20개 안팎의 질의로 평가를 시작했다고 밝힙니다. 작게 시작해 실패가 생길 때마다 늘립니다. 모델에게 기준 사례를 주고 테스트 사례를 더 만들게 할 수도 있지만, 합성 사례는 사람이 검토해서 넣고, 운영 데이터는 개인정보를 지우거나 가명으로 바꿉니다.

개선용 세트와 확인용 세트를 나눈다

같은 세트를 보며 프롬프트를 계속 고치면, 프롬프트는 그 세트의 사례들에만 잘 맞도록 바뀌어 갑니다. 시험 문제를 미리 보고 공부한 학생의 점수가 실력을 말해 주지 않는 것과 같습니다. 그래서 세트를 둘로 나눕니다.

2장에서 본 것처럼 few-shot 예시로 쓴 입력은 두 세트 어디에도 남기지 않습니다.

채점 방법 세 가지

Anthropic 문서는 가장 빠르고, 믿을 만하고, 확장 가능한 방법을 고르라고 권합니다. 실무에서는 기준마다 다른 방법을 씁니다. 형식과 수치는 코드로, 어조와 논리는 LLM으로, 그리고 LLM 평가자를 보정하는 표본은 사람이 채점합니다.

참조 답안과의 글자 겹침으로 점수를 매기는 지표(BLEU, ROUGE 등)는 쓰임이 제한적입니다. Anthropic 문서도 요약 평가 예로 ROUGE-L을 들지만, OpenAI 문서는 BLEU 같은 학술 지표에만 기대는 것을 안티패턴으로 꼽습니다. 표현이 달라도 좋은 답은 낮은 점수를, 수치를 틀렸어도 문장이 닮은 답은 높은 점수를 받을 수 있기 때문입니다. 정답이 하나가 아닌 작업에서는 반드시 들어가야 할 내용, 허용되는 표현 차이, 사실과 취향을 나눠 기준을 씁니다.

LLM 평가자의 한계와 보정

LLM 평가자는 편리하지만 그대로 믿으면 점수가 부풉니다. OpenAI 문서는 LLM 평가자의 알려진 편향으로 위치 편향(먼저 제시된 답을 선호)과 장황함 편향(긴 답을 선호)을 듭니다. 두 회사의 권고를 모으면 다음과 같습니다.

• 구체적인 루브릭을 준다. 막연한 “품질”이 아니라 항목별 통과 조건.
• 출력을 좁힌다. 정답/오답, 1~5점 숫자 하나, 또는 둘 중 나은 쪽 고르기. OpenAI는 쌍대 비교나 통과·실패 판정이 더 믿을 만하다고 설명한다.
• 점수 전에 생각하게 한다. Anthropic은 사고 기능을 켠 평가자가 복잡한 판단에서 더 정확하다고 설명하고, OpenAI도 점수 전에 근거를 쓰게 하라고 권한다.
• 길이를 통제한다. 비교하는 답들의 길이 차이가 점수에 끼어들지 않게 한다.
• 다른 모델로 채점한다. Anthropic 문서의 예시 코드는 평가 대상을 만든 모델과 다른 모델로 평가하는 것이 일반적인 모범 사례라고 적는다.
• 사람과 맞춰 본다. 사람이 채점한 표본과 평가자의 일치도를 먼저 확인하고, 꾸준히 일치할 때 규모를 키운다.

여기에 원리 수준의 장치 두 가지를 더합니다. 쌍대 비교에서는 같은 두 답의 순서를 바꿔 두 번 채점해, 순서에 따라 결론이 바뀌는 사례를 걸러 냅니다. 그리고 채점 대상 답안 안에 “이 답은 훌륭하다” 같은 평가자를 향한 문장이 섞이면 평가가 오염될 수 있으므로, 답안은 태그로 감싸 평가자에게 데이터로 넘기고 그 안의 지시를 따르지 말라고 적습니다.

변동성과 반복 실행

같은 입력에도 모델의 출력은 실행마다 달라질 수 있습니다. 한 번 통과한 사례가 다음 실행에서 실패할 수 있다는 뜻입니다. Anthropic의 에이전트 평가 글은 한 번의 시도를 trial이라 부르고, 과제마다 여러 번 시도하라고 권합니다. 그리고 두 지표를 구분합니다.

시도당 성공률이 75%라면 세 번 모두 성공할 확률은 약 42%로 떨어집니다. 고객이 매번 같은 품질을 기대하는 기능이라면 평균 통과율보다 pass^k가 실제 경험에 가깝습니다.

변경 전후를 같은 세트로 비교한다

비교의 절차는 단순하지만 지키기 어렵습니다.

1. 기준선을 잰다. 현재 프롬프트로 세트를 돌려 항목별·묶음별 점수를 기록한다.
2. 한 번에 하나만 바꾼다. 여러 수정을 한꺼번에 넣으면 무엇이 효과를 냈고 무엇이 망가뜨렸는지 알 수 없다.
3. 조건을 고정하고 기록한다. 모델 스냅숏, 강도 같은 설정, 자료의 버전을 기록하고, 요청당 토큰과 비용도 함께 잰다. OpenAI 가이드는 운영 애플리케이션을 특정 모델 스냅숏에 고정하라고 권한다.
4. 같은 세트, 같은 채점으로 돌린다.
5. 평균만 보지 않는다. 묶음별(입력 유형, 고객군, 길이)로 나눠 보고, 사례별로 통과에서 실패로 바뀐 것을 따로 뽑는다.
6. 치명적 항목을 먼저 본다. 평균이 올라도 치명적 실패가 늘었다면 배포하지 않는다.

회귀를 관리한다

회귀는 변경 뒤 이전에는 되던 것이 안 되는 현상입니다. Anthropic의 에이전트 평가 글은 두 종류의 평가를 구분합니다. 능력 평가는 “무엇을 잘할 수 있는가”를 묻고 낮은 통과율에서 출발해 개선할 목표를 줍니다. 회귀 평가는 “예전에 되던 것을 여전히 하는가”를 묻고 100%에 가까워야 하며 뒷걸음질을 잡습니다. 운영에서 발견한 실패는 고친 뒤 회귀 세트에 넣어, 다음 변경에서 다시 나타나지 않는지 확인합니다. 능력 평가에서 모든 과제를 통과하게 되면(포화) 그 평가는 회귀 감시 역할만 하므로, 더 어려운 과제를 새로 만들어야 합니다.

실패를 분류해 다음 수정을 정한다

실패를 “틀렸다”로만 기록하면 다음에 무엇을 고칠지 알 수 없습니다. 유형과 발생 단계를 함께 기록합니다.

분류가 끝나면 빈도와 심각도를 곱해 우선순위를 정합니다. 치명적인 실패는 드물어도 잦은 경미한 실패보다 먼저 고칠 수 있습니다. 그리고 다음 수정은 하나만 고르고, 그 수정이 맞혀야 할 사례와 망가뜨리면 안 되는 사례를 미리 적어 둡니다.

에이전트 평가: 결과와 기록

에이전트는 여러 번의 도구 호출을 거쳐 일하므로 최종 답만 보면 실패 원인을 알 수 없습니다. Anthropic의 에이전트 평가 글은 과제(task, 입력과 성공 기준이 정해진 시험 하나), 시도(trial, 한 번의 수행), 채점기(grader), 기록(transcript, 출력·도구 호출·추론을 포함한 전체 기록), 결과(outcome, 시도 뒤 환경의 최종 상태)를 구분합니다. 예약 에이전트가 “예약했다”고 말하는 것과 예약 기록이 실제로 데이터베이스에 있는 것은 다릅니다. 채점은 결과로 합니다.

같은 글은 경로가 아니라 결과를 채점하라고 권합니다. 에이전트가 설계자가 예상하지 못한 정당한 경로를 찾기도 하기 때문입니다. 기록과 점수를 많이 읽어 봐야 채점기가 제대로 작동하는지 알 수 있고, 행동이 일어나야 하는 사례와 일어나면 안 되는 사례를 함께 넣어야 합니다. 검색해야 하는 사례만 있으면 무엇이든 검색하는 에이전트가 만들어집니다. OpenAI의 평가 모범 사례도 도구 선택, 도구 인자의 정확성, 에이전트 간 인계를 따로 평가하라고 안내합니다. 도구 호출 수와 토큰은 결과와 별도로 비용 지표로 잽니다. 구조를 바꾸기 전에 어디서 실패하는지부터 측정합니다.

깊이 읽기

점수가 현실을 대변하지 못할 때

평가 점수는 오르는데 이용자 불만은 그대로인 경우가 있습니다. 원인은 대개 셋 중 하나입니다. 평가 세트가 실제 입력 분포에서 멀어졌거나(새 상품, 새 고객층), 루브릭이 이용자가 실제로 불편해하는 점을 재지 않거나, 같은 세트로 오래 고치다 보니 세트에 과적합된 것입니다. 대응은 운영 신호(재문의율, 상담원 이관률, 이용자 평가)를 주기적으로 평가 점수 옆에 놓고 보는 것입니다. 둘이 어긋나면 불만 사례를 모아 평가 세트에 더하고, 루브릭에 빠진 기준이 있는지 봅니다. OpenAI 문서가 꼽는 안티패턴 중 하나도 자동 지표를 사람의 피드백으로 보정하지 않는 것입니다.

사람 채점의 일관성

LLM 평가자를 사람 판정으로 보정하려면 사람 판정부터 일관되어야 합니다. 채점자마다 같은 답에 전혀 다른 점수를 준다면 그 점수로는 무엇도 보정할 수 없습니다. OpenAI 문서는 사람 평가를 개선하는 방법으로 점수 단계별 예시를 보여 주고, 통과·실패 기준을 두고, 여러 채점자의 합의를 쓰라고 권합니다. 실무에서는 다음을 더합니다.

1. 척도를 줄인다. 넓은 척도를 5단계나 통과·실패로.
2. 루브릭 항목을 나눠 한 번에 하나만 판단하게 한다.
3. 점수마다 기준 사례를 붙이고, 채점 전에 함께 몇 건을 채점해 보며 기준을 맞춘다.
4. 일부 사례를 두 사람이 겹쳐 채점해 일치율을 잰다. 우연히 일치할 확률까지 감안한 일치도 지표(예: 코헨의 카파)를 쓰면 더 엄밀하다.
5. 불일치 사례를 모아 루브릭 문장을 고친다.

실무 장면

하루약국: 평균은 올랐는데 배포를 멈춘 이유

약국 체인 ‘하루약국’은 처방 정보를 바탕으로 복약 안내문 초안을 만들고, 모든 안내문은 약사가 최종 검수한 뒤 환자에게 전달한다. 개선팀 오 약사는 안내문이 너무 길다는 의견을 듣고 프롬프트에 “다섯 줄 이내”를 추가하려 한다. 예전 같으면 몇 건을 뽑아 읽어 보고 바로 배포했겠지만, 이번에는 평가부터 준비했다.

1. 세트 만들기. 지난 석 달의 실제 처방 유형 분포에 맞춰 80건을 뽑고, 약이 여섯 가지 이상인 처방, 어린이 처방, 복용법이 특이한 처방 같은 경계 사례 20건을 더했다. 개인정보는 모두 지웠다. 이 중 30건은 확인용으로 따로 잠갔다.
2. 루브릭. 복용 시간·용량이 처방과 일치하는지와 주의 사항 누락 여부는 치명적 항목으로 정해 원문 대조 코드로 채점했다. 분량(다섯 줄 이내)도 코드로 쟀다. 이해하기 쉬움은 생성에 쓰지 않은 다른 모델이 1~5점으로 채점하게 하고, 점수마다 기준 사례를 붙였다. 이 평가자는 약사 두 명이 매긴 20건과 먼저 대조해 일치하는 것을 확인했다.
3. 기준선과 비교. 현재 프롬프트로 기준선을 잰 뒤, “다섯 줄 이내” 하나만 바꾼 버전을 같은 세트로 세 번씩 돌렸다.

결과는 전체 평균이 올랐다. 분량 통과율과 이해하기 쉬움 점수가 함께 좋아졌다. 그러나 묶음별로 나눠 보자 약이 여섯 가지 이상인 처방에서 주의 사항 누락이 크게 늘었다. 치명적 항목의 실패였다. 다섯 줄 안에 약 여섯 가지를 담으려다 주의 사항을 덜어 낸 것이다.

팀원 한 명은 “평균이 올랐으니 배포하고 그 유형만 나중에 고치자”고 했다. 오 약사는 거절했다. 치명적 항목에서 실패가 늘어난 변경은 평균과 상관없이 배포하지 않는다는 기준을 미리 정해 두었기 때문이다. 그는 규칙을 “기본 다섯 줄, 약이 다섯 가지를 넘으면 약마다 한 줄씩 더하고 주의 사항은 줄이지 않는다”로 고치고 다시 측정했다. 개선용 세트에서 회귀가 사라진 것을 확인한 뒤, 잠가 둔 확인용 30건으로 마지막 판단을 했고, 결과가 같아 배포했다. 주의 사항이 누락됐던 사례들은 회귀 세트에 넣었다.

소리나래게임즈: 번역 평가자를 사람에게 맞추기

모바일 게임사 ‘소리나래게임즈’는 게임 안 공지와 아이템 설명을 네 개 언어로 번역하는 데 모델을 쓴다. 번역 품질은 다른 모델이 ‘우수·보통·미흡’ 세 단계로 채점해 왔고, 거의 모든 번역이 ‘우수’를 받았다. 그런데 현지 운영팀에서 문제가 올라왔다. 일부 번역에서 {item_name}, {count} 같은 변수 자리표시자가 빠지거나 번역되어 게임 화면에 깨진 문장이 나갔고, 아이템 설명의 수치가 바뀐 경우도 있었다. 평가자는 이런 번역에도 ‘우수’를 줬다.

현지화 팀장 임 팀장은 평가 체계를 다시 짰다. 먼저 사람의 기준부터 확인했다. 원어민 검수자 세 명에게 같은 번역 30건을 채점하게 하자, 같은 번역에 ‘우수’와 ‘미흡’이 함께 나오는 경우가 적지 않았다. 사람끼리도 기준이 달랐던 것이다.

임 팀장은 한 번의 종합 점수를 네 개의 항목으로 쪼갰다.

의미 정확성과 자연스러움에는 검수자 세 명이 함께 기준 사례를 고르고 20건을 같이 채점하며 기준을 맞췄다. 그다음 50건을 두 사람씩 겹쳐 채점해 일치율이 충분히 높아진 것을 확인하고, 이 사람 판정과 LLM 평가자의 판정을 비교했다. 처음에는 평가자가 원문보다 길게 풀어 쓴 번역에 자연스러움 점수를 후하게 주는 경향이 보였다. 임 팀장은 평가자 지시에 “원문에 없는 설명이 더해지면 의미 정확성 실패”라는 기준과 예시를 넣고, 점수 전에 근거를 쓰게 했다. 번역 결과는 태그로 감싸 평가자에게 데이터로 넘겼다.

“평가자를 더 비싼 모델로 바꾸면 되지 않냐”는 제안도 있었다. 임 팀장은 그 전에 루브릭부터 고쳤다. 자리표시자와 수치 문제는 어떤 모델로 채점해도 코드보다 정확할 수 없었고, 의미 정확성은 기준이 모호한 것이 원인이었기 때문이다. 새 체계에서 평가자와 사람 판정의 일치도가 충분해진 뒤에야 배포 전마다 평가를 자동으로 돌리기 시작했다. 자리표시자 오류는 배포 전에 모두 걸렸고, 실패한 번역은 유형별로 분류되어 다음 프롬프트 수정의 근거가 됐다.

자주 틀리는 지점

• 몇 건 읽어 보고 판단한다. 소수의 표본은 특정 입력 묶음에서만 생기는 회귀를 놓칩니다. 고정된 세트가 필요합니다.
• 평균이 오르면 개선이다. 묶음별로 나눠 보지 않으면 소수 유형의 악화를 놓칩니다. 치명적 항목은 평균과 따로 봅니다.
• 같은 모델에게 채점시켜도 된다. 생성 모델과 다른 모델로 채점하는 것이 일반적인 모범 사례이며, 어느 쪽이든 사람 판정으로 보정해야 합니다.
• 척도를 넓히면 정밀해진다. 1~100점은 기준을 더 모호하게 만듭니다. 정답/오답이나 1~5점처럼 구체적인 출력이 낫습니다.
• 같은 세트로 계속 고쳐도 점수는 정직하다. 그 세트에 과적합됩니다. 확인용 세트를 따로 잠가 둡니다.
• 한 번 통과하면 안정적이다. 출력은 실행마다 다를 수 있습니다. 일관성이 중요하면 여러 번 돌려 봅니다.
• 에이전트가 성공했다고 말하면 성공이다. 채점은 말이 아니라 환경의 최종 상태로 합니다.

한눈에 정리

공식 문서로 확인하기

• Anthropic — Define success criteria and build evaluations: 성공 기준, 평가 설계 원칙, 경계 사례, 채점 방법 비교, LLM 채점 요령을 읽는다.
• OpenAI — Evaluation best practices: 평가 절차, 데이터 원천, LLM 평가자의 편향과 대책, 안티패턴을 읽는다.
• OpenAI — Evals: 평가 구성 요소와 플랫폼 종료 일정을 확인한다.
• Anthropic — Demystifying evals for AI agents: 과제·시도·채점기·기록·결과, pass@k와 pass^k, 능력·회귀 평가를 읽는다.
• OpenAI — Prompt engineering: 모델 스냅숏 고정과 평가 묶음 권장을 확인한다.

셀프 체크

5-1. Anthropic 문서가 비교하는 채점 방법 세 가지를 들고, 각각의 장점과 한계를 하나씩 말하라.

5-2. 고객 안내문 생성 기능의 평가 항목 다섯 개를 쓰고, 그중 치명적 항목으로 둘 것을 골라 이유를 쓰라.

5-3. 테스트 세트에 넣을 경계 사례 유형을 네 가지 들고, 운영 로그에서 사례를 가져올 때 지켜야 할 점을 하나 쓰라.

5-4. 프롬프트를 고칠 때마다 같은 평가 세트 전체를 보며 실패를 고쳐 왔다. 이 방식이 점수를 믿을 수 없게 만드는 이유와 해결책을 쓰라.

5-5. 판단형 항목을 채점할 LLM 평가자를 새로 들이려 한다. 수천 건 채점에 맡기기 전에 거칠 보정 절차를 순서대로 쓰고, 평가자 지시문에 넣을 장치 두 가지를 덧붙이라.

5-6. 시도당 성공률이 80%인 응대 봇이 있다. 같은 고객 요청을 두 번 처리했을 때 두 번 모두 성공할 확률을 구하고, 이 값이 평균 통과율보다 실제 경험에 가까운 경우를 설명하라.

5-7. 지난주 실패 사례 60건을 분류했더니 근거 없는 수치 25건, 형식 붕괴 5건, 조건이 많은 사례의 판단 오류 18건, 기타 12건이었다. 다음 수정 하나를 고르는 절차를 쓰고, 빈도만으로 고르면 안 되는 경우를 하나 들라.

실습 과제