https://news.hada.io/topic?id=15268


 

실제 입출력 샘플에서 몇 가지 assertion 기반 단위 테스트 생성하는게 좋을 수 있다:

  • 최소 3가지 기준의 단순한 assertion 을 만드는 것으로부터 평가를 테스트로 만드는 것을 해볼 수 있음.
  • 모든 응답에 포함하거나 제외할 구문이나 아이디어를 지정하는 assertion 이 가장 간단할 것.

 

 

LLM-as-Judge는 (어느 정도) 작동할 수 있지만 만능은 아니라는 걸 기억:

  • 잘 구현되면 LLM-as-Judge는 인간의 판단과 상당한 상관관계를 달성할 수 있지만 노이즈가 끼기도 쉬움.
  • 특히 쌍별 비교(예: 대조군 vs 처리군)를 할 때 LLM-as-Judge는 일반적으로 방향을 올바르게 잡지만 승/패의 크기는 노이즈가 있을 수 있다.
  • LLM-as-Judge를 최대한 활용하기 위한 제안:
    • 쌍별 비교 사용:
      • LLM에게 단일 출력을 Likert 척도로 평가하도록 요청하는 대신 두 가지 옵션을 제시하고 더 나은 것을 선택하도록 요청
      • Likert 척도로 평가하는 것은 인지적으로 까다로움
      • 더 안정적인 결과로 이어지는 경향이 있음.
    • 위치 편향 제어:
      • 제시된 옵션의 순서가 LLM의 결정을 편향시킬 수 있다.
      • 이를 완화하려면 각 쌍별 비교를 두 번 수행하고 각 시간에 쌍의 순서를 바꾼다.
      • 스와핑 후에는 올바른 옵션에 승리를 귀속시켜야 함
    • 동점 허용:
      • 경우에 따라 두 옵션이 똑같이 좋을 수 있음
      • 따라서 LLM이 임의로 승자를 선택할 필요가 없도록 동점을 선언하도록 허용
    • Chain-of-Thought 사용:
      • 최종 선호도를 제시하기 전에 LLM에게 그 결정을 설명하도록 요청하면 평가 신뢰성이 향상될 수 있음.
      • 이를 통해 더 약하지만 LLM을 사용하면서 인간과 유사한 결과를 얻을 수 있기도 함.
      • CoT 로 인한 추가 지연 문제는 Batch Prompting 을 이용.
    • 응답 길이 제어:
      • LLM은 더 긴 응답으로 치우치는 경향이 있음
  • LLM-as-Judge의 간단하지만 효과적인 접근 방식의 예시:
    • LLM Judge 결과를 기록해보고, 잘못 판단한 것이 있다면 이 영역을 식별해서 개선.
    • 이걸 3번만 반복해도 인간과 LLM 의 일치도는 크게 올라간다고 함.
  • 그러나 LLM-as-Judge는 만능이 아님:
    • 가장 강력한 모델조차도 신뢰할 수 있게 평가하지 못하는 미묘한 언어적 측면이 있음

+ Recent posts