생성형 AI 결과 품질은 무엇으로 평가합니까?

평가는 성공 기준을 적는 데서 시작합니다

생성형 AI 기능의 품질 논의가 길어지는 가장 큰 이유는 「잘 된다」의 뜻이 사람마다 다르기 때문입니다. Anthropic은 평가를 설계하기 전에 성공 기준부터 적으라고 권하며, 좋은 기준의 조건으로 구체적일 것, 측정할 수 있을 것, 달성 가능할 것, 업무 목적과 관련 있을 것을 듭니다. 「좋은 성능」이 아니라 「문의 유형 분류가 정확할 것」처럼 적어야 합니다.

대부분의 업무는 기준 하나로 끝나지 않습니다. 정확성과 함께 일관성, 질문과의 관련성, 어조, 개인정보 보호, 제공된 근거의 활용, 응답 시간, 비용을 함께 봐야 하는 경우가 많습니다. 업무 유형별로 무엇을 어떻게 잴지 표로 먼저 정해 두면 논의가 짧아집니다.

기준선도 함께 정합니다. 지금 사람이 같은 업무를 하면 어느 정도로 정확한지, 기존 규칙 기반 도구는 어땠는지를 알아야 AI 성적이 충분한지 판단할 수 있습니다. 기준선이 없으면 어떤 숫자가 나와도 좋은지 나쁜지 말할 수 없습니다.

평가 세트를 만듭니다

평가 세트는 실제 업무 입력과 그에 대한 기대 결과를 짝지은 목록입니다. 만든 사람이 떠올린 질문만으로는 실제 분포를 반영하지 못하므로 운영 기록이나 실제 문의에서 표본을 뽑습니다. Anthropic은 여기에 경계 사례를 섞으라고 권합니다. 관련 없거나 존재하지 않는 입력 데이터, 지나치게 긴 입력, 부적절하거나 유해한 요청, 사람끼리도 판단이 갈리는 모호한 사례가 그것입니다. 문서 기반 답변이라면 답하면 안 되는 질문을 반드시 넣습니다.

또 하나의 원칙은 소수의 정교한 수작업 평가보다 자동 채점이 가능한 많은 문항이 낫다는 것입니다. 문항을 자동 채점이 가능한 형태로 설계해 두면 변경할 때마다 부담 없이 다시 돌릴 수 있습니다. 처음부터 세트를 크게 잡을 필요는 없습니다. 자주 나오는 유형을 고르게 담는 것이 먼저이고, 운영하면서 놓친 유형을 더해 가는 방식이 현실적입니다. 다만 유형별 문항이 몇 개뿐이면 우연히 맞거나 틀린 결과에 판단이 흔들리므로, 중요한 유형일수록 문항을 넉넉히 둡니다.

기대 결과는 업무를 실제로 하는 담당자가 정해야 합니다. 개발자가 정답을 적으면 업무 맥락이 빠지기 쉽습니다. 담당자끼리도 정답이 갈리는 문항은 버리지 말고 따로 표시해 두면, 그 업무가 애초에 자동화하기 어려운 영역인지 판단하는 근거가 됩니다. 실제 데이터에서 표본을 뽑으면 개인정보가 섞이기 쉬우므로, 식별 정보를 지우고 평가 세트의 보관 위치와 접근 권한을 정합니다.

채점 방법은 셋을 나눠 씁니다

Anthropic은 모델 채점을 쓸 때 구체적인 채점 기준을 주고, 「맞음·틀림」이나 5점 척도처럼 답을 좁게 받고, 채점 모델이 판단 근거를 먼저 생각하게 하라고 권합니다. 공식 예시도 답을 만든 모델과 다른 모델로 채점하는 것을 일반적인 모범 사례로 적고 있습니다. 그리고 신뢰성을 먼저 확인한 뒤 규모를 키우라고 합니다. 일부 문항을 사람이 같이 채점해 모델 채점과 얼마나 일치하는지 보고, 일치하지 않으면 채점 기준부터 고칩니다.

채점 기준은 맞음·틀림으로 판정할 수 있는 문장으로 씁니다. 요약이라면 「원문의 결론과 날짜가 빠짐없이 들어 있는가」, 「원문에 없는 내용을 덧붙이지 않았는가」처럼 적습니다. 「잘 요약했는가」처럼 쓰면 채점 모델도 사람도 기준이 흔들립니다.

Amazon Bedrock에도 이런 평가를 돌리는 기능이 있습니다. 자동 평가, 사람 평가, 다른 모델을 채점자로 쓰는 평가를 지원하고, RAG 평가는 검색만 평가하는 방식과 검색과 생성을 함께 평가하는 방식으로 나뉘며 기대 검색 결과와 기대 답변을 데이터로 넣게 되어 있습니다.

결과는 하나의 평균 점수로 보지 말고 문항 유형별로 나눠 봅니다. 평균이 올라도 특정 유형, 예컨대 답하면 안 되는 질문에서 점수가 떨어졌다면 위험은 오히려 커진 것입니다.

변경할 때마다 다시 잽니다

평가 세트의 진짜 가치는 회귀를 잡는 데 있습니다. 프롬프트 한 줄, 모델 버전, 검색 대상 문서가 바뀌면 이전에 맞던 답이 틀릴 수 있습니다. 변경 절차에 평가를 묶어 두면 이 문제가 출시 전에 드러납니다.

1. 변경 제안
2. 평가 세트 실행
3. 기준선과 비교
4. 통과 시 배포
5. 운영 오답을 세트에 추가

출시 뒤에는 평가 세트 밖의 신호도 함께 봅니다. 사용자가 답을 고쳐 쓴 비율, 같은 질문을 다시 묻는 비율, 오답 신고 건수 같은 운영 지표는 평가 세트가 놓친 유형을 알려 줍니다. 이 신호로 찾은 사례를 세트에 더하면 세트가 실제 업무 분포를 점점 더 잘 반영하게 됩니다. 모델 지원 종료로 모델을 바꿔야 할 때도 같은 세트가 판단 근거가 됩니다. 평가를 돌릴 때마다 날짜, 바꾼 내용, 유형별 점수를 함께 기록해 둡니다. 언제 무엇을 바꿔 성적이 어떻게 움직였는지가 남아 있어야 나중에 문제가 생겼을 때 원인을 거슬러 올라갈 수 있습니다.

참고 자료

• Anthropic — Define success criteria and build evaluations
• AWS — Amazon Bedrock evaluations
• AWS — Amazon Bedrock RAG 평가