반품 주문에 관한 답변이 보내도 될 것처럼 보입니다. 문법이 맞고, 친절하며, 짧습니다. 이 설명을 위한 사례에서 자동 점수는 만점을 줍니다. 그런데 어시스턴트는 결제 시스템을 확인하지 않고 고객에게 환불이 완료됐다고 알립니다.
문장은 어색하지 않습니다. 좋은 결과의 정의가 약한 것입니다.
수집한 평가 시연에서 한 팀은 소프트웨어 문서를 쓰는 에이전트의 점수를 만듭니다. 흥미로운 순간은 업무를 아는 사람이 품질의 의미를 설명하고, 도구가 그 설명을 기준으로 바꿀 때입니다. 나중에 낮은 점수가 나오자 적절한 의문이 생깁니다. 에이전트를 고쳐야 할까요, 아니면 평가를 고쳐야 할까요?
기준표는 업무에 관한 하나의 이론입니다. 그 이론을 검증해야 합니다.
실격 오류부터 정하기
팀은 흔히 채점하기 쉬운 차원인 명확성, 어조, 구조, 완전성부터 시작합니다. 유용하지만 보통 충분하지 않습니다.
예시의 환불 답변에서는 “결제 영수증 없이 환불 완료를 주장하지 않는다”가 문장의 품질보다 우선합니다. 데이터 동기화에서는 “청구 이메일을 계정 소유자의 이메일로 잘못 매핑하지 않는다”가 필드 매핑 설명의 문장력보다 중요합니다.
업무 전문가에게 명백히 좋은 사례, 명백히 잘못된 사례, 지식이 있는 사람끼리 의견이 갈릴 수 있는 사례를 요청하세요. 각 판단의 근거와 원본 레코드를 보존하세요. 바뀔 수 있는 규칙에 의존한다면 평가 라벨과 함께 규칙의 버전도 기록하세요.
첫 검토는 작게 시작해도 됩니다. 모호해서는 안 됩니다.
- 업무 소유자
좋은 사례, 나쁜 사례, 의견이 갈린 사례
- 정확한 검사 식별 · 권한 · 목적지
코드가 사실을 확인
- 의미적 기준표
해석이 필요한 것만 평가
- 불일치 검토
라벨과 기준 수정
| 검사 항목 | 더 적합한 담당 | 이유 |
|---|---|---|
| 필요한 권한의 존재 | 코드와 권위 있는 레코드 | 정확하고 영향이 큰 사실입니다 |
| 목적지 ID와 원본 식별 정보의 일치 | 코드와 테스트 레코드 | 모델이 식별자를 추측해서는 안 됩니다 |
| 답변이 고객 질문에 응답하는지 | 사람이 검토한 기준표, 필요하면 모델 평가자 | 의미 해석이 필요합니다 |
| 상황에 맞는 어조인지 | 사람이 검토한 기준표, 필요하면 모델 평가자 | 허용 가능한 형태가 여러 가지입니다 |
기존 워크플로에 AI를 도입하는 가이드에서도 판단과 실행을 나누는 경계를 살펴볼 수 있습니다. 모델의 확신이 권한으로 바뀌지는 않습니다. 후보 선택 뒤에도 코드는 원래 값을 복사하고 제약을 확인해야 합니다.
점수는 기준표의 사각지대를 물려받습니다
반론은 타당합니다. “사람이 모든 에이전트 실행을 검토할 수는 없습니다. 확장 가능한 평가자가 필요합니다.” 맞습니다. 문제는 그 평가자가 무엇을 확장하느냐입니다.
기준표가 잘 다듬어진 답변에 점수를 주면서 주문이 실제로 환불됐는지 확인하지 않는다면, 자동화는 누락도 함께 확장합니다. 소수점 둘째 자리까지 표시한 숫자는 정밀해 보입니다. 여전히 잘못된 것을 측정할 수 있습니다.
Google Cloud의 평가자 평가 문서는 실용적인 확인 방법을 설명합니다. 사람이 평가한 사례를 준비하고 모델 기반 지표를 실행한 뒤 점수를 비교합니다. 한 사람의 견해가 항상 옳다는 뜻은 아닙니다. 모델 점수에 무게를 싣기 전에 외부 기준이 필요하다는 뜻입니다.
평균 일치율만 보지 말고 불일치도 살펴보세요. 고객 지원 책임자가 거부한 답변을 평가자가 통과시켰다면 빠진 기준이 무엇인지 물어보세요. 전문가 두 명이 의견을 달리한다면 두 라벨을 남기고 해석이 갈린 규칙을 찾으세요. 조용히 평균을 내서 이견을 지우지 마세요.
사례 표본은 기준 문구만큼 중요합니다. 일상적인 성공 사례만 모으면 어려운 사례를 건드리지 않고도 평가자가 믿을 만해 보일 수 있습니다. 불완전한 레코드, 충돌하는 지시, 멈춰서 질문해야 하는 사례를 넣으세요. 기준표 작성자가 맞춰 보지 않은 별도 사례 집합도 남겨, 익숙한 예시에 맞춘 변경이 다른 곳에서도 통하는지 확인하세요. 업무 규칙이 바뀌면 라벨과 예상 결과를 모두 갱신하세요. 고정된 테스트 집합은 어제의 정책에 보상을 줄 수 있습니다.
평가를 결과에 연결해 두기
동기화 에이전트의 기준표는 고객 결과를 따라야 합니다. 올바른 연락처가 바뀌었나요? 동의를 존중했나요? 실패한 레코드를 중대한 동작을 반복하지 않고 재실행할 수 있나요?
Brevo 커넥터 가이드는 API 호출 성공과 누락된 속성이 공존할 수 있는 이유를 설명합니다. 에이전트가 엔드포인트를 호출했는지만 검사하면 결과를 놓칩니다. 목적지만 검사하면 우연히 올바른 값에 도착한 금지된 경로를 놓칠 수 있습니다. 경로에 위험이 있다면 둘 다 중요합니다.
좁은 업무 하나와 몇 가지 실패 유형에서 시작하세요. 업무 소유자와 함께 사례에 라벨을 붙이고, 정확한 검사는 코드에 두며, 언어나 판단이 필요한 곳에만 모델 평가자를 쓰세요. 프롬프트, 모델, 도구를 바꾼 뒤 같은 사례를 다시 실행하세요. 나중에 생긴 실패가 기준표에 대해 무엇을 알려주는지 기록하세요.
처음에는 전문가의 시간이 듭니다. 그 대가로 나중의 모든 점수에 설명 가능한 의미가 생깁니다.
대시보드는 점수를 보여줍니다. 무엇을 센 것인지는 기준표만 알려줍니다.
자주 묻는 질문
AI 에이전트의 평가 기준은 누가 정해야 하나요?
업무와 그 결과를 아는 사람이 허용할 결과와 실격 오류를 정의해야 합니다. 엔지니어는 이 판단을 반복 가능한 검사로 만들고 모델 평가자가 사람의 평가와 일치하는지 확인할 수 있습니다.
모델 평가자의 높은 점수는 에이전트가 잘 작동한다는 증거인가요?
아닙니다. 점수는 테스트한 사례에 대해 기준표와 얼마나 일치하는지를 나타냅니다. 기준표가 약하거나 사례가 대표성이 없거나 평가자의 보정이 부족하면 해로운 결과에도 높은 점수가 나올 수 있습니다.
모델 평가자 대신 코드로 확인할 것은 무엇인가요?
정확한 권한, 레코드 식별자, 필수 도구 호출, 목적지 상태는 가능한 한 코드로 확인해야 합니다. 모델 평가자는 정확한 규칙으로 판단하기 어려운 의미적 품질에 유용합니다.