인간의 선호도에 맞춘 LLM-as-a-Judge 정렬

주요 링크:

평가(Evaluation)는 LLM 애플리케이션을 지속적으로 개선하는 과정입니다. 이를 위해서는 애플리케이션의 성능을 측정할 방법이 필요합니다.

LLM 애플리케이션은 종종 자연어(Natural Language)로 출력을 생성하는데, 이는 하드코딩된 규칙(Hard-coded rules)을 사용하여 판단하기 어렵습니다. 예를 들어, 간결함(Conciseness)이나 참조 출력(Reference output) 대비 정확성(Correctness)과 같은 속성은 일반적인 단위 테스트(Unit tests)로 표현하기 어렵습니다.

"LLM-as-a-Judge"를 사용하는 것은 LLM 애플리케이션의 자연어 출력을 채점하는 대중적인 방법입니다. 이는 생성된 출력(및 기타 정보)을 별도의 LLM에 전달하고 해당 출력을 판단하도록 요청하는 방식입니다. 이 방식은 여러 맥락에서 유용함이 증명되었지만, 흥미로운 문제를 제기합니다. 즉, 이제 LLM-as-a-Judge가 잘 작동하는지 확인하기 위해 또 다른 라운드의 프롬프트 엔지니어링(Prompt engineering)을 수행해야 한다는 점입니다.

LangSmith는 이 증가하는 문제에 대한 새로운 솔루션을 제시합니다. 이제 LangSmith 평가기(Evaluators)는 "자기 개선(Self-improvement)" 기능을 갖추고 있습니다. 이를 통해 LLM-as-a-Judge 출력에 대한 인간의 수정 사항이 퓨샷 예시(Few-shot examples)로 저장되며, 이후 반복 과정에서 프롬프트에 다시 피드백됩니다.

💡

결과적인 영향은 프롬프트 엔지니어링 없이도 사용자의 선호도를 정확하게 반영하는 LLM-as-a-Judge 평가기를 더 쉽게 만들 수 있으며, 사용자가 LangSmith와 네이티브하게 상호작용함에 따라 시간이 지나면서 평가기가 적응하게 된다는 것입니다.

LLM-as-a-Judge

LLM 출력을 프로그래밍 방식으로 평가하는 것은 종종 어렵습니다. 이 문제의 큰 부분은 좋은 지표(Metrics)의 부족입니다. 물론 분류(Classification)나 개체명 인식(Named entity extraction) 또는 기타 "전통적인" 머신러닝(ML) 작업을 수행한다면 사용할 수 있는 표준 ML 지표들이 있습니다. 하지만 더 "생성적인(Generative)" 작업(대부분의 애플리케이션이 그러함)을 수행한다면 훌륭한 선택지가 많지 않습니다.

그리고 평가는 매우 중요합니다! 애플리케이션을 그냥 출시하고 결과가 좋기를 바랄 수는 없습니다. 실제 데이터로 성능을 평가하고, 앱을 수정하며, 그 수정 사항이 성능 저하 (Regression)를 일으키지 않는지 확인해야 합니다. 저희는 개발자들이 온라인 (online) 및 오프라인 (offline) 평가 단계 모두에 상당한 시간을 할애하는 것을 목격해 왔으며, 이에 맞춰 LangSmith를 구축했습니다.

LangSmith는 어떤 지표 (Metric)를 사용하는지에 대해 특정한 의견을 강요하지 않습니다 (거의 모든 사용자가 자신만의 맞춤형 지표를 정의하는 것을 보고 있습니다). 저희는 Elastic 및 Rakuten과 같은 환상적인 팀들과 협력하며 그들이 평가를 어떻게 수행하는지 직접 확인해 왔으며, 그 과정에서 관찰한 것 중 하나는 “LLM-as-a-Judge” 평가자의 사용이 증가하고 있다는 점입니다.

“LLM-as-a-Judge” 평가자란 단순히 LLM을 사용하여 출력값에 점수를 매기는 평가자를 의미합니다. 이는 애플리케이션을 프로그래밍 방식으로 평가하기 어렵고, 다른 유일한 대안이 인간의 라벨링 (Human labels)뿐일 때 매우 유용합니다. 저희가 확인한 주요 사용 사례는 다음과 같습니다:

• RAG 환각 (Hallucination) 탐지 (온라인 평가)
• RAG 정확성 (Correctness) 탐지 (오프라인 평가)
• LLM이 유해하거나 부적절한 답변을 생성했는지 탐지 (오프라인 및 온라인 평가)

이 방식이 왜 작동할까요? 애초에 LLM이 답변을 생성하고 있다면, 왜 결과를 채점하는 데 LLM을 사용하는 것이 실제로 효과가 있는 걸까요?

여기에는 두 가지 요인이 작용합니다. 첫째, 평가 과정에서 LLM은 생성 당시에는 가지고 있지 않았던 정보에 접근할 수 있습니다. 예를 들어, RAG 정확성을 판단할 때, 평가용 LLM에 정답 (Ground truth)을 제공하고 이를 비교하도록 요청합니다. 분명히 이는 생성 순간에는 없었던 정보입니다. 둘째, LLM에게는 정답을 직접 생성하는 것보다 답변의 정확성을 판단하는 것이 더 쉽습니다. 이러한 작업의 “단순화 (Simplifying)”가 LLM-as-a-Judge를 가능하게 만듭니다.

이 과정이 잘 작동할 수도 있지만, 몇 가지 복잡한 문제가 있습니다. 평가자 프롬프트 (evaluator prompt)를 위해 또 다른 라운드의 프롬프트 엔지니어링 (prompt engineering)을 수행해야 하며, 이는 많은 시간을 소모하게 만들어 팀이 적절한 평가 시스템을 구축하는 데 방해가 될 수 있습니다. LangSmith를 통해 우리는 이 평가 과정을 간소화하는 것을 목표로 했습니다.

연구 동기 (Motivating research)

우리가 솔루션을 구현하게 된 데에는 두 가지 연구 동기가 있었습니다.

첫 번째는 새로운 것이 아닙니다. 언어 모델 (language models)은 퓨샷 러닝 (few-shot learning)에 능숙합니다. LLM에 올바르게 수행된 사례들을 제공하면, 모델은 올바른 동작을 모방할 것입니다. 이 방법은 우리의 고객 LLM 애플리케이션에서 널리 채택되고 있습니다. 특히 LLM이 어떻게 행동해야 하는지 지침 (instructions)으로 설명하기 어렵거나, 출력이 특정 형식을 갖추어야 하는 경우에 매우 효과적입니다. 평가는 이 두 가지 기준에 모두 부합합니다!

두 번째 연구는 새로운 것입니다. Berkeley의 Shreya Shankar가 작성한 "Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences"라는 논문입니다. 이 논문은 동일한 문제를 다루고 있으며, 비록 우리와는 다른 솔루션을 제안하지만, LLM 평가를 인간의 선호도 (human preferences)와 프로그래밍 방식으로 정렬하기 위한 방법으로서 피드백 수집 (feedback collection)을 사용하도록 동기를 부여하는 데 도움을 주었습니다.

그렇다면, 우리는 이 두 가지 아이디어를 어떻게 가져와서 "자기 개선형 (self-improving)" 평가자를 구축했을까요?

우리의 솔루션: LangSmith에서의 자기 개선형 평가 (Self-improving evaluation in LangSmith)

최근의 연구와 LLM-as-a-Judge 평가자의 광범위한 채택을 바탕으로, 우리는 LangSmith 평가자를 위한 새로운 "자기 개선형 (self-improving)" 시스템을 개발했습니다. 이 접근 방식은 LLM 평가를 인간의 선호도와 정렬하는 과정을 간소화하여, 광범한 프롬프트 엔지니어링 (prompt engineering)의 필요성을 제거하는 것을 목표로 합니다. 작동 방식은 다음과 같습니다:

먼저, LLM-as-a-Judge를 설정합니다 (온라인 또는 오프라인): 사용자는 LangSmith에서 온라인 또는 오프라인 평가를 위해 LLM-as-a-Judge 평가자를 쉽게 설정할 수 있습니다. 이 시스템은 시간이 지남에 따라 개선되도록 설계되었으므로, 초기 설정에는 최소한의 구성만 필요합니다. 설정 시 퓨샷 예시 (few-shot examples)가 프롬프트에 어떻게 형식화되어 포함될지 지정할 수 있습니다.

피드백을 남기도록 합니다: LLM 평가자는 생성된 출력물에 대해 피드백을 제공하며, 정확성 (correctness), 관련성 (relevance) 또는 이전 단계에서 판사 (judge)의 일부로 지정된 기타 기준들을 평가합니다.

사용자는 앱 내에서 해당 피드백을 직접 수정할 수 있습니다: 사용자는 LLM의 평가를 검토하면서 LangSmith 인터페이스 내에서 피드백을 직접 수정하거나 바로잡을 수 있습니다. 이 단계는 인간의 선호도 (human preferences)와 판단을 포착하는 데 매우 중요합니다.

이러한 수정 사항은 퓨샷 예시로 저장됩니다: LangSmith는 이러한 인간의 수정 사항을 퓨샷 예시 (few-shot examples)로 자동 저장합니다. 이를 통해 팀이나 애플리케이션의 특정 선호도 및 표준을 반영하는, 인간과 정렬된 (human-aligned) 평가 데이터셋이 지속적으로 구축됩니다. 또한 이 흐름의 일부로 수정 사항에 대한 **설명 (explanations)**을 남길 수도 있습니다.

다음 평가 실행 시, 해당 예시들(및 선택적으로 설명들)을 저장하고 이를 생성 과정에 반영합니다: 이후의 평가 실행 시, 시스템은 저장된 이러한 예시들을 LLM-as-a-Judge의 프롬프트에 포함합니다. 언어 모델의 퓨샷 학습 (few-shot learning) 능력을 활용함으로써, 평가자는 시간이 지남에 따라 인간의 선호도에 점점 더 정렬됩니다.

더 자세한 기술적 단계별 안내를 원하시면, 이 가이드(how-to guide)를 참조하십시오.

이러한 자기 개선 사이클 (self-improving cycle)을 통해 LLM-as-a-Judge는 실제 피드백을 기반으로 평가를 적응시키고 정교화할 수 있으며, 수동적인 프롬프트 조정이나 시간이 많이 소요되는 프롬프트 엔지니어링 (prompt engineering)을 제거할 수 있습니다. 이제 팀은 자신의 입력이 시간이 지남에 따라 시스템의 성능을 직접적으로 향상시킨다는 점을 인지한 상태에서, 필요한 경우에만 평가를 검토하고 수정하는 데 집중할 수 있습니다.

결론

LLM-as-a-Judge 평가자는 생성형 AI (Generative AI) 시스템을 평가하는 강력한 도구이지만, 프롬프트 엔지니어링 (Prompt Engineering) 및 인간 선호도 정렬 (Human Preference Alignment) 측면에서 새로운 과제를 제기해 왔습니다. LangSmith의 자기 개선형 평가자 (Self-improving evaluators)는 퓨샷 학습 (Few-shot learning)과 사용자 수정 사항을 활용하여, 지속적인 수동 개입 없이도 정확하고 관련성 높은 평가를 위해 인간의 피드백을 통합하는 우아한 해결책을 제공합니다.