AI 평가 완전 초보자 가이드: 단계별 진행 (2025)
이 영상은 AI 제품, 특히 LLM 기반 챗봇을 평가하는 방법을 단계별로 상세히 설명하는 초보자용 가이드입니다. 실제 고객 지원 챗봇 구축 사례를 통해 평가 기준 정의, 휴먼 라벨링, LLM 판사 활용, 그리고 이 모든 과정을 확장하는 방법까지 실용적인 접근 방식을 보여줍니다. AI 제품의 품질을 측정하고 개선하는 데 필수적인 AI 평가의 중요성을 강조하며, PM(프로덕트 매니저)이 이 과정에서 핵심적인 역할을 수행해야 함을 역설합니다.
1. AI 평가(Evals)란 무엇이며 왜 중요한가?
영상의 시작은 AI 평가의 중요성을 강조하는 것으로 시작합니다. Aman은 LLM(거대 언어 모델)이 환각(hallucination) 현상을 일으킬 수 있다는 점을 지적하며, 이는 기업의 브랜드와 수익에 부정적인 영향을 미칠 수 있다고 경고합니다. 그는 AI 제품을 판매하는 기업의 최고 제품 책임자(CPO)들조차 AI 평가의 중요성을 강조한다고 언급하며, AI 제품을 성공적으로 구축하기 위해서는 평가가 필수적인 요소라고 말합니다.
"이 회사들의 CPO는 평가가 정말 중요하다고 말하고 있습니다. 여러분은 AI 평가가 정확히 무엇인지 고민해 봐야 합니다."
"LLM이 환각 현상을 일으킬 때, 회사의 명성이나 브랜드에 부정적인 영향을 미치지 않도록 평가가 정말 중요하다고 LLM을 판매하는 사람들이 직접 말하고 있다면, 우리는 AI 평가를 어떻게 활용해서 의미 있는 제품을 만들 수 있을지 생각해 봐야 합니다."
궁극적으로 AI 평가는 AI 시스템의 품질을 측정하는 도구이며, 이는 PM이 갖춰야 할 가장 중요한 기술 중 하나라고 강조됩니다.
2. 모든 PM이 알아야 할 네 가지 AI 평가 유형
Aman은 AI 평가를 네 가지 주요 유형으로 분류하여 설명합니다. 이러한 평가 유형들은 AI 시스템 개발 초기부터 프로덕션 단계까지 전 과정에 걸쳐 활용될 수 있습니다.
-
코드 기반 평가(Code-based eval):
- 가장 기본적인 형태로, 메시지 내 특정 문자열 존재 여부 등을 확인하는 이진(binary) 통과/실패 기준을 가집니다.
- 예를 들어, "유나이티드 항공" 챗봇에게 "델타 항공" 예약을 문의했을 때, "델타 항공" 관련 정보를 제공하지 않도록 하는 식입니다.
- 최근 코드 생성 기술의 발전으로 코드 기반 평가를 쉽게 만들 수 있게 되었습니다.
-
휴먼 평가(Human eval):
- PM이나 해당 분야의 전문가가 직접 AI의 응답을 평가하는 방식입니다.
- "답변이 좋았는가?", "기준을 충족했는가?" 등을 판단하며, 인간의 판단이 개입하는 중요한 단계입니다.
- PM의 역할은 최종 제품 경험에 대한 "판단"을 내리는 것이므로, 이 과정에서 세부 사항에 깊이 관여하는 것이 중요하다고 강조됩니다.
"PM의 역할은 최종 제품 경험이 어떠해야 하는지에 대한 판단을 내리는 것입니다. 그래서 휴먼 평가에 대한 세부 사항에 집중하는 것이 제품의 성공 또는 실패를 결정합니다."
"휴먼 평가를 단순히 외부 계약자나 라벨러에게 완전히 아웃소싱하는 것은 유용하다고 생각하지 않습니다. PM은 직접 스프레드시트에서 작업을 해야 합니다."
-
LLM 판사(LLM-judge):
- LLM 시스템이 사람처럼 데이터에 라벨을 붙이는 평가 방식입니다.
- 규모 있는 평가를 수행할 때 가장 널리 사용되는 방법으로, LLM을 훈련시켜 사람과 유사하게 응답을 평가하도록 하는 것입니다.
-
사용자 평가(User eval):
- 실제 사용자로부터 데이터를 수집하는 것으로, 비즈니스 지표와 가장 밀접하게 연결됩니다.
- 사용자가 애플리케이션과 상호작용하거나 피드백을 제공하는 방식입니다.
Aman과 Peter는 이 네 가지 평가 유형 중 특히 휴먼 평가의 중요성을 강조하며, 이 과정에서 PM이 직접 세부 사항에 주의를 기울여야 한다고 조언합니다. 그들은 과거 자율 주행차 개발 경험에서도 매일 데이터를 확인하고 수동으로 라벨링하며 "자동차가 이렇게 했어야 했나?"를 판단했던 경험을 공유합니다.
3. 실습: 고객 지원 챗봇 평가 구축하기 🛠️
이제 이론적인 설명을 마치고, 실제 고객 지원 챗봇을 예시로 들어 평가 과정을 단계별로 시연합니다. 이 데모에서는 달리기 신발 브랜드 'On Running Shoes'를 위한 챗봇을 구축하는 과정을 따라갑니다.
3.1. 챗봇 프롬프트 작성하기
가장 먼저 챗봇이 작동하도록 프롬프트를 작성해야 합니다. Aman은 Anthropic의 "Workbench"라는 콘솔 시스템을 사용하여 프롬프트를 작성하는 방법을 보여줍니다. 이 도구는 초기 프롬프트 작성을 돕고 모범 사례를 기반으로 프롬프트를 생성해 줍니다.
프롬프트 작성 시, 챗봇이 수행할 작업과 필요한 맥락(context)을 명확히 정의하는 것이 중요합니다. 예를 들어, 'On Running Shoes' 고객 지원 챗봇의 경우, 다음과 같은 정보가 프롬프트에 포함되어야 합니다.
- 사용자 질문(User's question): 사용자가 묻는 내용.
- 제품 정보(Product information): 신발 가격, 설명, 이름 등.
- 정책 정보(Policy information): 반품 규정 등.
Aman은 Anthropic 콘솔에서 "On Running Shoes 고객 상호작용을 처리하는 고객 지원 봇을 위한 프롬프트 디자인"이라고 입력하여 기본 프롬프트를 자동으로 생성하는 과정을 시연합니다. 이 프롬프트는 {{user_question}}, {{product_information}}, {{policy_information}}과 같은 변수(variables)를 사용하여 유연하고 재사용 가능하도록 설계됩니다.
이제 실제로 On 웹사이트에서 제품 정보와 반품 정책을 가져와 프롬프트 변수에 입력합니다. Peter는 "클라우드 몬스터 신발을 두 달 전에 샀는데 이제 반품하고 싶어요"라는 가상의 질문을 입력하고 챗봇의 응답을 확인합니다.
챗봇은 "클라우드 몬스터를 두 달 전에 구매하신 것을 이해합니다. 안타깝게도 저희 반품 정책은 30일 이내이므로 반품 기간이 초과되었습니다"라고 답변합니다. Peter는 답변이 정책에 부합하고 도움이 되지만, 조금 더 간결했으면 좋겠다고 말하며 개선의 여지를 발견합니다.
"저는 클라우드 몬스터 신발을 두 달 전에 샀는데 이제 반품하고 싶어요. 더 이상 마음에 들지 않아요."
"두 달 전에 구매하신 클라우드 몬스터를 반품하고 싶으신 것을 이해합니다. 안타깝게도 저희 반품 정책은 30일이므로 반품 기간이 초과되었습니다."
3.2. 평가 기준(Rubric) 생성하기
챗봇의 답변을 평가하기 위해 평가 기준(evaluation criteria)을 정의하는 것이 다음 단계입니다. PM이라면 스프레드시트에 익숙할 것이라며, 스프레드시트가 LLM 평가에 가장 좋은 도구라고 Aman은 말합니다.
예시 챗봇의 평가 기준은 다음과 같이 세 가지 차원으로 정의됩니다.
- 제품 지식(Product knowledge): 챗봇이 제품에 대해 잘 알고 있는가?
- 규칙 준수(Following the rules): 챗봇이 주어진 규칙(정책 등)을 잘 따르는가?
- 어조(Tone): 챗봇의 응답 어조가 적절한가?
각 기준에 대해 '좋음(Good)', '보통(Average)', '나쁨(Bad)'으로 정의하고, 팀원들이 일관성 있게 평가할 수 있도록 구체적인 정의를 마련해야 합니다. 이는 프롬프트 작성 후 데이터를 얻기 시작하면서, 골든 데이터셋(golden dataset)을 구축하는 데 활용됩니다.
Peter는 "클라우드 몬스터를 3주 전에 샀는데 박스를 잃어버렸습니다"라는 새로운 질문을 입력합니다. 챗봇은 "3주 이내라 반품 기간 안에 있지만, 고객 지원팀에 연락하는 것을 추천합니다"라고 답변합니다.
여기서 논쟁이 발생합니다.
- Peter는 정책에 박스를 잃어버렸을 경우에 대한 내용이 없으므로, 챗봇의 답변은 현 정책 하에서는 '좋음'이지만, 정책 자체가 개선되어야 한다고 주장합니다.
- Aman은 챗봇이 고객 지원팀으로 책임을 넘기는 것은 더 많은 업무를 유발할 수 있으므로, 정책에 해당 내용이 없다면 더 직접적으로 "정책에 해당하지 않는다"고 답변하는 것이 나을 수 있다고 반박합니다.
이러한 논의를 통해 "박스를 버렸을 경우를 처리할 정책이 필요하다"는 개선 사항과 "고객 지원팀에 연락하는 방법을 알려주지 않았다"는 정책 준수 문제(나쁨)가 도출됩니다. 또한, 챗봇의 어조가 "좀 더 활기차고 쾌활한 'On 봇'의 어조"와는 달리 "너무 격식 있고 딱딱하다"고 평가되어 '보통'에서 '나쁨'으로 평가됩니다.
이처럼 데이터를 직접 보고 평가하며, 팀원들과 논의를 통해 좋은 것과 나쁜 것을 결정하는 과정이 매우 중요하다고 Aman은 강조합니다. 그는 이 과정이 구글 스프레드시트에서 이루어지므로 "섹시하지는 않지만, 팀과 함께 올바른 평가를 수행하는 것이 가장 중요"하다고 말합니다.
"스프레드시트는 LLM을 평가하는 데 사용할 수 있는 궁극적인 제품이라고 생각합니다."
"이것이 바로 평가를 하는 과정입니다. 우리는 데이터를 보고 평가하며, 무엇이 좋은지 나쁜지에 대해 논쟁하고 있습니다. 그리고 그것을 기반으로 LLM 판사를 구축하기 시작할 것입니다."
"이러한 작업은 구글 시트에서 이루어지므로 별로 섹시하지 않습니다. 하지만 아마 팀과 함께 가장 중요하게 올바르게 수행해야 할 것 중 하나일 것입니다. 왜냐하면 시작이 좋지 않으면 나머지 평가도 끔찍할 것이기 때문입니다."
3.3. 휴먼 라벨을 골든 데이터셋에 추가하기 (초기 데이터셋 구축)
이제 초기 5개의 예시 질문과 답변을 스프레드시트에 정리하고 각 기준(제품 지식, 정책 준수, 어조)에 따라 휴먼 라벨(좋음/보통/나쁨)을 부여합니다. Aman은 여기서 LLM이 수학에 약하다는 재미있는 사실을 발견합니다. "45분 전에 주문했는데 배송지를 변경할 수 있나요?"라는 질문에 챗봇은 "60분 창을 넘겼으므로 불가능하다"고 답변했는데, 45분은 60분 이내가 명백하므로 이는 잘못된 답변이며 '나쁨'으로 평가됩니다. 이는 LLM이 정책을 가지고 "만들어 낸" 것이라고 Aman은 지적합니다.
Peter는 이렇게 '나쁨'으로 평가된 항목 옆에 메모를 남기고, 나중에 LLM을 사용하여 이 메모들을 요약해 제품 개선에 필요한 상위 3가지 사항을 도출하는 방법을 제안합니다. Aman은 이러한 노트와 라벨이 프롬프트 개선에 활용될 수 있으며, 이는 자가 개선 에이전트를 만드는 과정이라고 덧붙입니다.
3.3.1. 골든 데이터셋 규모에 대한 가이드라인
Peter는 초기 제품 개발 시 얼마나 많은 예시가 필요한지에 대해 질문합니다. Aman은 다음과 같은 가이드라인을 제시합니다.
- 내부 테스트 또는 소규모 사용자 출시: 최소 5~10개 예시로 시작. 이 단계에서는 추가 투자가 필요한지 여부를 판단하기 위한 초기 확신을 얻는 것이 목표입니다.
- 프로덕션 출시 및 높은 신뢰도 필요: 산업에 따라 100개 이상의 예시가 필요할 수 있습니다.
이러한 접근 방식은 반복 속도(speed of iteration)와 결과에 대한 신뢰도(confidence in result) 사이의 균형을 맞추는 것입니다. 데이터가 많을수록 신뢰도는 높아지지만, 반복 속도는 느려집니다. 따라서 팀의 상황에 맞춰 적절한 데이터 규모를 결정해야 합니다.
3.3.2. 프롬프트 업데이트 시뮬레이션
다시 Anthropic 콘솔로 돌아와 "답변이 너무 길고 어조가 덜 친절하다"는 피드백을 바탕으로 프롬프트를 개선합니다. Aman은 Claude에게 "더 친절하고 덜 격식 있게 만들라"고 지시하여 프롬프트를 최적화하는 기능을 시연합니다. 흥미롭게도 Claude는 이 요청을 처리하기 위해 머메이드(Mermaid) 그래프를 생성하여 '친절함'을 정의하는 코드까지 생성하며 복잡한 다단계 프롬프트 반복 흐름을 보여줍니다.
하지만 개선된 프롬프트로 다시 챗봇을 실행한 결과, 답변이 여전히 길고 친절하지 않으며 오히려 더 길어지기까지 합니다. Aman은 이러한 결과가 LLM이 실제 데이터와 미묘한 차이(nuance)를 이해하고 프롬프트를 개선하는 데 어려움을 겪을 수 있음을 보여준다고 말합니다. 따라서 휴먼 라벨과 평가가 이러한 프롬프트 최적화에 더 나은 결과를 제공할 수 있다고 강조합니다.
"여전히 별로 친절하게 들리지 않습니다. 사실 더 길어진 것 같네요. 이러한 LLM의 흥미로운 점은 프롬프트를 반복하는 데 실제 데이터와 약간의 미묘한 차이가 필요하다는 것입니다."
PM의 역할은 이처럼 프롬프트를 수십 번 반복하고, 평가를 실행하며, 다시 프롬프트를 수정하는 과정을 끊임없이 반복하는 것이라고 Peter는 정리합니다.
4. LLM 판사 프롬프트로 평가 확장하기
골든 데이터셋을 구축하고 휴먼 라벨링에 대한 감을 잡았다면, 이제 평가를 확장해야 할 때입니다. Arise와 같은 플랫폼을 활용하여 이 과정을 자동화하고 LLM 판사(LLM-judge) 시스템을 구축할 수 있습니다.
Aman은 앞서 스프레드시트에 만들었던 5개 예시의 골든 데이터셋 CSV 파일을 Arise 플랫폼에 업로드합니다. 이 플랫폼에서는 동일한 데이터를 사용하여 평가 기준을 LLM 판사를 위한 프롬프트로 인코딩할 수 있습니다.
"이제 우리는 이 데이터셋을 가지고 우리가 이전에 스프레드시트에서 보았던 것과 유사한 평가 기준을 우리의 LLM 판사 유형 시스템을 구축하는 데 사용할 수 있습니다."
그는 Arise에서 "평가지침: 이 LLM은 주어진 질문, 제품 정보 및 정책을 기반으로 한 고객 지원 에이전트의 응답을 평가합니다. 응답의 정확성, 완전성, 어조 및 고객 지원 역할의 효과를 평가하십시오. 응답이 제공된 맥락과 지침을 얼마나 잘 준수하는지 점수를 매기십시오. 응답에 대한 자세한 평가와 함께 좋음, 보통 또는 나쁨 라벨을 제공하십시오"와 같이 LLM을 위한 평가 프롬프트를 작성합니다. 이 프롬프트는 챗봇의 답변(output), 질문(question), 제품 정보(product information), 정책(policy)을 입력으로 받아 '좋음', '보통', '나쁨'으로 점수를 매기도록 지시합니다.
Aman은 이전에 정의했던 세 가지 평가 기준(제품 지식, 정책 준수, 어조)을 LLM 판사에게 적용하고, GPT-5와 같은 다른 LLM 모델을 사용하여 동일한 질문에 대한 응답을 다시 생성하고 평가하도록 합니다. 이 과정을 통해 챗봇의 응답과 함께 LLM 판사가 부여한 '정책 준수', '제품 지식', '어조' 등의 평가 점수와 그에 대한 설명(explanation)까지 확인할 수 있습니다.
"LLM 판사를 사용하여 AI 평가를 할 때는, 특히 초기에, LLM이 설명도 함께 생성하도록 하는 것을 강력히 추천합니다. 왜냐하면 이는 마치 인간이 LLM이 라벨을 부여하는 이유에 대해 노트를 주는 것과 같기 때문입니다."
하지만 GPT-5는 모든 질문에 대해 '좋음'으로 평가하는 경향을 보입니다. 심지어 너무 길고 불필요하게 장황한 답변에도 '좋음'을 부여합니다. Aman은 이는 LLM 판사가 인간의 판단과 일치하지 않을 수 있음을 보여주는 사례이며, 따라서 인간의 라벨과 LLM 판사의 라벨을 비교하고 조정하는 과정이 필수적이라고 강조합니다.
5. LLM 판사를 인간의 판단에 맞추기
LLM 판사가 모든 답변에 '좋음'을 부여하는 것과 같은 문제가 발생했을 때, 우리는 LLM 판사의 평가를 신뢰할 수 없습니다. 이때 필요한 것이 LLM 판사를 인간의 판단에 맞춰 정렬(align)하는 과정입니다.
이 과정은 다음과 같습니다.
- 초기 휴먼 라벨링: 앞서 스프레드시트에서 했던 것처럼, 5~10개 정도의 소규모 예시에 대해 인간이 직접 라벨을 부여합니다. 이를 통해 LLM 판사가 신뢰할 만한지 여부를 파악합니다.
- LLM 판사 평가: LLM 판사에게 이 데이터를 평가하도록 합니다.
- 일치율(Match Rate) 확인: 인간이 부여한 라벨과 LLM 판사가 부여한 라벨이 얼마나 일치하는지 확인합니다.
Aman은 Arise 플랫폼에서 인간 라벨링 기능을 사용하여 챗봇 응답의 '어조'와 '제품 지식'에 대한 인간 라벨을 직접 부여합니다. 그는 챗봇의 긴 답변 때문에 '어조'를 '나쁨'으로 평가합니다.
이제 인간 라벨과 LLM 판사의 라벨을 비교합니다. 결과는 다음과 같습니다.
- 제품 지식: 100% 일치
- 어조: 100% 불일치 (LLM 판사는 '좋음'으로 평가했지만, 인간은 '나쁨'으로 평가)
이 결과는 '어조'에 대한 LLM 판사의 평가 프롬프트에 개선의 여지가 있음을 명확히 보여줍니다. LLM 판사에게 "답변이 너무 길면 좋은 답변이 아니라고 판단하라"는 등의 구체적인 기준을 추가하여 프롬프트를 수정해야 합니다. 이러한 개선 사항은 다시 Anthropic 콘솔과 같은 개발 환경으로 가져가서 챗봇의 시스템 프롬프트(예: "너무 길게 답변하지 말라")를 개선하는 데 활용될 수 있습니다.
"LLM 판사가 인간 라벨과 그리고 여러분이 부여하는 판단과 일치하도록 하고 싶습니다."
"제품 지식은 100% 일치하지만, 어조는 우리 인간 라벨과 한 번만 일치했습니다. 이는 우리가 가지고 있던 인간 라벨을 기반으로 평가를 개선할 여지가 있음을 보여주는 예시입니다."
"어조 평가 프롬프트를 개선해야 합니다. 기본적으로 답변이 얼마나 긴지에 대해 더 엄격하게 만들어야 합니다."
6. 결론: AI 평가 전체 과정 요약
Aman과 Peter는 시연 내용을 바탕으로 AI 평가의 전체 과정을 다음과 같이 요약합니다.
- 프롬프트 작성: 챗봇의 초기 프롬프트를 작성하고 필요한 정보(정책, 제품 정보 등)를 수집합니다.
- 평가 기준 생성: 제품 지식, 정책 준수, 어조와 같은 평가 기준을 정의합니다. 이는 스프레드시트 형태로 만들 수 있습니다.
- 수동 평가(휴먼 라벨링): 소규모(5~10개)의 예시 질문과 답변에 대해 수동으로 라벨을 부여하고 팀원들과 논의하며, 이 과정에서 프롬프트와 기준을 반복적으로 개선합니다. 이 단계는 시간이 많이 소요되지만 가장 중요합니다.
- 초기에는 10개 내외의 데이터로 시작하고, 프로덕션 출시 시에는 100개 이상의 데이터를 목표로 합니다.
- LLM 판사 활용: Arise와 같은 플랫폼을 사용하여 평가를 확장합니다. LLM 판사를 위한 평가 프롬프트를 작성하고, 휴먼 라벨이 부여된 데이터와 LLM 판사의 평가를 비교하여 일치율을 확인합니다.
- LLM 판사 정렬: LLM 판사의 평가가 인간의 판단과 일치하도록 평가 프롬프트를 개선합니다. 특히 낮은 일치율을 보인 기준에 집중합니다.
- 배포 및 실제 사용자 평가: 챗봇을 소규모 사용자 그룹(예: 1% 트래픽)에게 AB 테스트로 출시하고, 실제 사용자 피드백(사용자 평가)을 수집합니다. 하지만 사용자 피드백 해석 시, 단순한 '좋아요/싫어요'가 아닌, 그 이면에 있는 복잡한 사용자 감정과 시스템 성능을 분리하여 해석해야 한다는 점을 주의해야 합니다.
"이것이 실전에서 평가가 어떻게 보이는지입니다."
"사람들은 항상 은총알(silver bullet)을 찾고 있지만, PM이 이 과정을 이해하는 것이 AI 제품이 실제로 작동하고 실생활에서 형편없지 않게 되는 데 정말 중요하다고 생각합니다."
이 영상은 AI 제품 개발이 복잡하고 지저분할 수 있지만, PM이 이러한 평가 과정을 깊이 이해하고 직접 참여하는 것이 성공적인 AI 제품을 만드는 데 필수적임을 강조하며 마무리됩니다.