에이전트가 잘하고 있는지 어떻게 확인할까, 평가 공부 노트

 

 

예약 시스템에 AI 에이전트를 붙이는 설계를 공부하다가 계속 같은 질문에서 막혔습니다.
"그래서 이 에이전트가 잘하고 있는지는 어떻게 알지?"
데모를 몇 번 돌려보면 대체로 잘 되는 것처럼 보입니다.
그런데 몇 번 잘 되는 것과 믿고 맡길 수 있는 것은 전혀 다른 이야기더라고요.

그래서 평가(Eval)라는 주제를 따로 공부하고 정리해봤습니다.
특정 도구나 벤치마크 이야기는 일부러 빼고, 기획자 입장에서 이해한 개념 위주로 적어요.
틀린 부분이 있을 수 있어서 계속 고쳐 나갈 노트라고 생각해주세요.

 

기존 소프트웨어는 입력이 같으면 출력도 같습니다.
그래서 "이 입력에는 이 결과가 나와야 한다"는 테스트를 한 번 써두면 됩니다.

에이전트는 사정이 다릅니다.
같은 질문에도 답이 조금씩 달라지고, 중간에 어떤 도구를 부를지도 상황에 따라 바뀝니다.
그래서 "몇 번 해보니 괜찮던데요"라는 감각만으로는 한계가 금방 옵니다.

예약처럼 실제 결과가 남는 일을 다룰 때는 더 그렇습니다.
말투가 어색한 정도는 괜찮지만, 취소하면 안 되는 예약을 취소해버리면 곤란하니까요.

평가는 결국 이런 질문에 답하는 장치 같아요.
이 에이전트가 어떤 상황에서 잘하고, 어떤 상황에서 틀리는가.
이번에 프롬프트를 바꾼 게 실제로 나아진 건가, 아니면 내가 그렇게 느끼는 건가.

 

가장 먼저 부딪힌 벽은 채점 기준이었습니다.
그런데 고객 문의에 답하는 일은 좋은 답이 여러 개일 수 있어요.

예를 들어 "내일 예약 취소할게요"라는 문의에 이런 답들이 가능합니다.
"취소 처리해드렸어요."
"내일 오후 3시 예약 말씀이시죠? 취소하면 되돌릴 수 없어서 한 번만 확인할게요."
둘 중 어느 쪽이 더 좋은지는 서비스가 정한 정책에 따라 달라집니다.

그래서 글자가 똑같은지 비교하는 방식은 거의 쓸모가 없었습니다.
대신 좋은 답이 갖춰야 할 조건을 쪼개서 하나씩 확인하는 방식이 현실적으로 보였어요.

제가 이해한 기준은 크게 세 층입니다.

첫째는 결과가 맞는가입니다. 실제로 예약이 취소됐는지, 엉뚱한 예약이 바뀌지는 않았는지를 봅니다.
둘째는 과정이 맞는가입니다. 예약을 조회하지 않고 바로 취소하진 않았는지, 확인 단계를 건너뛰진 않았는지를 봅니다.
셋째는 말이 맞는가입니다. 취소 규정을 정확히 안내했는지, 모르는 것을 아는 척하지 않았는지를 봅니다.

 

평가의 출발점은 테스트 케이스 모음이라고 이해했습니다.
처음부터 수백 개를 만들 필요 없이, 대표적인 상황 열 개 남짓으로 시작해도 배울 게 많다고 해요.

예약 도메인으로 몇 개를 상상해봤습니다. 아래는 모두 제가 가정한 예시입니다.

하나는 취소 문의입니다.
입력은 "내일 3시 예약 취소하고 싶어요" 정도입니다.
좋은 답은 본인의 예약을 먼저 조회하고, 취소 마감 규정을 맞게 안내하고, 처리 전에 한 번 확인하는 것입니다.
다른 사람의 예약을 건드리거나 확인 없이 바로 취소하는 건 절대 안 되는 쪽에 적어둡니다.

또 하나는 시간 변경입니다.
"내일 3시를 5시로 바꿀 수 있어요?"라는 문의입니다.
좋은 답은 5시에 빈 자리가 있는지 확인하고, 변경 내용을 보여주며 동의를 받는 것입니다.
자리가 없다면 가까운 다른 시간을 제안하는 것까지가 좋은 답이겠죠.
확인도 없이 5시가 비어 있다고 말해버리는 건 절대 안 되는 쪽입니다.

세 번째는 불가능한 요청입니다.
영업이 끝난 시간에 예약을 잡아달라거나, 업장이 제공하지 않는 서비스를 요청하는 경우입니다.
좋은 답은 안 되는 이유를 짧게 설명하고 가능한 대안을 함께 주는 것입니다.
그냥 예약해드렸다고 거짓으로 답하는 것이 가장 나쁜 결과입니다.
다른 업장의 예약 정보를 알려달라는 요청도 여기에 넣으면 테넌트 경계를 지키는지 볼 수 있습니다.

네 번째는 정보가 부족한 요청입니다.
"다음 주에 예약 잡아줘"처럼 날짜도 서비스도 없는 말입니다.
좋은 답은 임의로 정하지 않고 필요한 것을 되묻는 것입니다.

이렇게 쓰다 보니 케이스 하나에 들어갈 항목이 정리됐습니다.
입력, 그 상황의 배경(예약 데이터와 정책), 좋은 답의 조건, 절대 안 되는 것.
이 네 가지만 있어도 누가 봐도 같은 기준으로 채점할 수 있어요.

쉬운 케이스만 모으면 점수는 높게 나오지만 아무것도 알려주지 않습니다.
애매한 표현, 오타, 한 번에 두 가지를 요청하는 경우처럼 틀리기 쉬운 상황을 일부러 넣어야 한다고 합니다.

 

케이스가 쌓이면 자동 채점이 필요해집니다.
자동으로 하기 좋은 것은 규칙으로 확인되는 부분입니다.
취소가 실제로 처리됐는지, 조회 도구를 먼저 불렀는지, 응답에 반드시 들어가야 할 정보(예: 취소 마감 시간)가 있는지 같은 것들입니다.
이런 항목은 합격과 불합격이 분명해서 매번 같은 기준으로 빠르게 돌릴 수 있어요.

말의 품질은 규칙만으로 보기 어렵습니다.
이 부분에는 다른 모델에게 채점 기준을 주고 점수를 매기게 하는 방식도 있다고 공부했습니다.
다만 이 채점자도 틀릴 수 있어서, 점수를 그대로 믿으면 안 된다는 설명이 인상 깊었어요.

제 결론은 이렇습니다.
자동 채점은 넓고 빠르게 보는 용도, 사람 검토는 깊고 믿을 수 있게 보는 용도입니다.
자동 채점이 낮게 준 것과 높게 준 것을 일부씩 뽑아 직접 읽어보면 채점 기준 자체가 잘못됐는지도 발견할 수 있다고 해요.

결제나 환불, 다른 사용자 정보와 관련된 케이스는 점수가 아무리 높아도 눈으로 한 번 더 보는 쪽이 맞겠다고 생각했습니다.

 

평가가 가장 빛나는 순간은 무언가를 바꿨을 때라고 합니다.
프롬프트를 고치거나, 모델을 바꾸거나, 도구 설명을 다듬었을 때가 그렇습니다.

한 군데를 고쳤더니 다른 곳이 망가지는 일은 생각보다 자주 생깁니다.
예를 들어 "더 친절하게 답해주세요"라고 한 줄을 추가했더니, 불가능한 요청에도 일단 해드릴게요 하고 받아주는 쪽으로 기울 수 있습니다.

그래서 바꿀 때마다 같은 케이스 세트를 다시 돌려서 전과 비교합니다.
이전에 통과하던 케이스가 갑자기 실패하면 그게 회귀(regression)입니다.
평균 점수가 올랐더라도 어떤 케이스가 새로 깨졌는지를 같이 봐야 한다는 점도 기억해두려고 합니다.

 

공부하면서 가장 크게 느낀 건 평가가 개발자만의 일이 아니라는 점입니다.
채점을 돌리는 장치는 개발자가 만들더라도, 무엇이 좋은 답인지를 정하는 일은 서비스를 아는 사람의 몫이었어요.

취소 마감을 넘긴 고객에게는 어떻게 답하는 것이 좋을까요?
규정대로 단호하게 안내하는 게 맞을까요, 예외 문의 경로를 같이 알려주는 게 맞을까요?
이건 코드가 정해주지 않고 정책과 서비스 철학이 정합니다.

 

기획자가 맡을 수 있는 일은 세 가지로 정리했습니다.

첫째, 실제 문의와 운영 상황에서 대표 케이스와 어려운 케이스를 고르는 일입니다.
둘째, 케이스마다 좋은 답의 조건과 절대 안 되는 것을 말로 써두는 일입니다.
셋째, 사람이 읽어봐야 할 샘플을 함께 읽고 기준을 고치는 일입니다.

 

평가는 "이 에이전트를 믿어도 되는가"를 감이 아니라 근거로 말하게 해주는 도구 같습니다.
열 개 남짓한 케이스를 직접 써보고, 실제 문의가 쌓이는 만큼 늘려가는 정도로 시작해도 충분해 보여요.

아직 잘 모르겠는 것도 많습니다.

케이스가 몇 개쯤이면 충분하다고 말할 수 있을까요.
다른 모델에게 채점을 맡길 때 그 채점자의 신뢰도는 어떻게 확인해야 할까요.
운영 중에 쌓이는 실제 대화를 평가에 어디까지 써도 되는지는 개인정보 측면에서도 따로 정리가 필요할 것 같습니다.

다음에는 가정한 예약 서비스로 케이스 열 개를 직접 써보고, 어디서 기준이 모호해지는지 기록해보려고 합니다.