LLM as a Judge를 domain specific하게 활용할때의 문제점

요약

1. 도메인 전문가를 활용해 피드백을 받아야한다.
2. 처음에는 pass/fail로 평가하자.
3. 실제 서비스에서 발생할 수 있는 다양한 문제상황들에 대한 평가 데이터셋을 구축하자.

---

LLM을 통해 평가할때 발생하는 문제들

1. 도메인 전문가를 포함하지 않는 경우
2. 주관적이고 해석하기 어려운 scoring 시스템.
3. 너무나 많은 metric.

---

도메인 전문가를 참여시켜야 하는 이유

• 기술적으로 수용 가능한 것을 정의하고 목적에 맞게 잘 나아갈 수 있다.
• 전문가 관점에 맞춰 일관성을 유지할 수 있다.
  ex) 정신건강 AI 비서를 위한 심리학자, 법률 문서를 분석하는 AI 변호사

도메인 전문가가 pass/fail 판정을 내리고 비평 작성하기

pass/fail로만 작성하는 이유

• 명확성과 집중
  • pass/fail 이진결정은 AI가 사용자의 기대를 충족했는지 여부인 핵심 요소만 고려하게함
• 빠르게 평가 가능
• 기대치를 명확하게 정리
  • 도메인 전문가의 비평을 통해 AI가 어떻게 해야하는지 기대치가 명확해짐
• 효율적인 자원 활용
  • 처음부터 복잡한 평가 기준을 만들 필요가 없다.
  • 핵심적인 문제에 집중하면서 후에 필요하다면 세부적인 평가 기준을 추가하자.

비평(Critique)

• 비평의 필요성
  • pass/fail만으로 알 수 없는 AI의 성능을 개선할 구체적인 방향을 제시
  • 세부적인 평가를 가능하게 하고, 개선방향을 제시하며, 단순성과 깊이의 균형을 유지
• 비평의 핵심요소
  • pass의 경우
    • 개선 가능성이 있는 부분을 추가하기
  • fail의 경우
    • AI가 실패한 핵심 요소를 구체적으로 지적
    • 어떤점에서 기대에 미치지 못했는지를 구체적으로 설명
• 비평의 예시
  

---

다항척도 적용하지 않기

1~5점과 같은 복잡한 점수 체계를 사용하면 안되는 이유

• 사용하기 어려움
  • 3점이 2점보다 어떻게 더 나은지 설명할 수 없음
    → 어떻게 개선해야할지 명확하지 않음
• 대부분의 경우 이런 지표는 의미가 없음
  • 도메인 전문가가 평가한 결과를 보면 이런 점수는 상관관계가 대부분 없다.
• 지표의 함정
  • 이러한 지표를 따르다보면 실제로 중요한 것이 무엇인지 혼동하게 됨

---

다양한 데이터 셋을 통해 테스트하기

• 실제 운영 서비스에 생길 문제들을 반영하는 데이터 셋이 필요
• AI의 약점을 식별할 수 있는 데이터 셋
• 기능, 시나리오, 페르소나로 문제들을 정의해서 데이터셋 구성
  - 기능 : 요약, 번역, 추천 등
  - 시나리오 : 사용자가 잘못된 데이터 제공, 검색시 여러개가 일치하는 경우 등
  - 페르소나 : 신규 및 고령 사용자, 비 원어민 등
  

얼마나 많은 예제를 평가해야 하는가?

• 약 30개의 예제를 검토 후 새로운 fail 패턴이 나오지 않을 때까지 계속 추가
• LLM출력에 대한 인간의 판단전에 평가 기준을 완전히 결정하는 것은 불가능합니다.

평가는 얼마나 자주해야 하는가?

• 오류가 발생되었을때 유사한 사례를 찾아 위 과정을 반복

에러 분석 수행

• 아래와 같이 시나리오 별로 오류율을 확인해 의미있는 패턴을 찾아내야 한다.
  

---

LLM as a Judge의 방법이 실패하는 경우

• AI의 task 범위가 너무 넓을때
  ex) 모든걸 해주는 챗봇
• 도메인 전문가가 없고 비평을 만들지 않을 경우

결론

이 과정의 진짜 가치는 데이터를 살펴보고 신중하게 분석하는 것이다.
데이터에 대한 분석이 있어야 탄탄한 LLM as a Judge 시스템을 구축할 수 있다.

---

Reference

https://hamel.dev/blog/posts/llm-judge/