많은 팀이 GenAI 프로젝트를 파일럿에서 프로덕션 단계로 전환하는 데 어려움을 겪습니다. 고객 만족에 필수적인 품질 요구 사항을 측정하거나 충족할 수 없어 어려움을 겪기 때문입니다. 프로덕션에 도달한 팀은 회귀 및 예측 불가능한 출력 품질 변화에 직면하여 안전하게 반복 작업을 수행하는 데 어려움을 겪는 경우가 많습니다.
Databricks는 고객이 Judge Builder와 같은 솔루션을 통해 체계적인 평가 인프라를 구축하도록 지원하여 이러한 문제를 해결하는 동시에 시간이 지남에 따라 복합적인 전략적 가치를 창출합니다. 이 게시물에서 논의하는 평가 방법론은 Agent Bricks 의 기반이 되는 동일한 연구 중심 접근 방식을 반영하며, Databricks AI 플랫폼 전반에서 에이전트 품질을 측정, 모니터링, 지속적으로 개선하는 방법의 토대를 형성합니다.
운영 측면에서 평가는 성능 변화를 정량화하고 특정 비즈니스 요구사항에 대한 배포 결정을 알려줌으로써 더 빠른 배포를 가능하게 합니다. 강력하고 지속적인 평가는 성능, 안전, 규정 준수 표준을 일관되게 충족하면서 기업 전체에 AI 애플리케이션을 확장하는 데 필요한 확신을 제공합니다.
전략적 측면에서 생성된 평가 데이터(사람의 피드백, 모델 판단, 에이전트 추적)는 재사용 가능한 자산이 됩니다. 고객은 이 데이터를 활용하여 미래의 모델을 훈련하고, 진화하는 에이전트 워크플로를 검증하며, 빠르게 발전하는 AI 환경에서 다음에 등장할 모든 것에 적응할 수 있습니다. 평가는 조직의 전문 지식을 지속적인 경쟁 우위로 체계화합니다.
강력한 AI 시스템 평가와 이에 상응하는 신뢰할 수 있는 AI 시스템을 구축하는 것은 여러 부서에 걸친 중요한 조직적 과제이며, 다음 각 차원에 걸쳐 명확 한 전략적 접근이 필요합니다.
- 조직의 Judge 포트폴리오 설계 및 우선순위 지정: 다양한 이해관계자가 측정할 가치가 있는 품질 차원에 대해 합의하도록 지원
- 전문 지식의 정확하고 신뢰성 있는 체계화: 최소한의 노력과 노이즈로 제한된 전문가 집단으로부터 주제 전문 지식을 포착하고 인코딩
- 기술적 실행: 심사자(judge)에 대한 신속한 반복 작업과 배포, 그리고 대규모의 강력한 측정, 감사 가능성, 거버넌스를 지원하는 툴링 구축
이 블로그 게시물의 나머지 부분에서는 이 세 가지 차원을 각각 살펴보고 고객이 이러한 문제를 해결하도록 돕는 방법을 알아봅니다. Judge Builder 는 이러한 경험을 바탕으로 구축되었으며 이 프로세스를 간소화하여 팀이 대규모로 심사자(judge)를 신속하게 개발, 테스트 및 배포할 수 있도록 지원합니다. 맞춤형 LLM 심사자(judge) 개발에 협력하는 데 관심이 있으시면 담당 어카운트 팀에 문의해 주세요.
조직의 Judge 포트폴리오 설계 및 우선순위 지정
LLM Judge는 단순한 측정을 넘어선 역할을 합니다. LLM Judge는 제품 사양의 역할을 하는 동시에 팀이 이를 기준으로 최적화함에 따라 실제 모델 동작을 근본적으로 형성합니다. 따라서 잘못 보정되거나 결함이 있는 Judge는 애플리케이션의 품질과 관련 없는 신호를 수집하고 완전히 잘못된 것을 위해 최적화하는 결과를 낳을 수 있습니다.
따라서 Judge를 만들고 보정하기 전에 팀은 먼저 어떤 Judge가 필요한지 결정해야 합니다. 이 논의에는 다양한 이해관계자가 참여해야 합니다. 일부 Judge는 여러 팀에서 공유할 수 있으므로, 고품질 Judge에 투자하면 조직 전체의 GenAI 개발을 가속화하고 큰 이점을 얻을 수 있습니다.
저희는 고객이 정확한 품질 차원에 초점을 맞춰 Judge를 정의하도록 조언합니다. 예를 들어, '응답이 관련성 있고, 사실에 기반하며, 간결한가'를 평가하는 Judge는 세 개의 개별 Judge로 분해해야 합니다.
단일 종합 Judge는 근본 원인을 파악하기 어렵게 만듭니다. 실패한 '전반적인 품질' 점수는 무언가 잘못되었다는 것을 알려주지만 무엇을 수정해야 하는지는 알려주지 않습니다. 분해된 Judge는 평가를 실행 가능한 디버깅으로 전환합니다. 품질이 저하되면 사실성 문제인지, 관련성 문제인지, 또는 서식 문제인지 즉시 알 수 있으며, 이에 따라 개선 노력을 집중할 수 있습니다. 하지만 이는 심사자(judge)의 급증으로 이어질 수도 있으므로 우선순위를 정하는 것이 중요합니다.
심사자(judge) 선택은 하향식과 상향식 고려 사항을 모두 결합해야 합니다:
하향식: 처음부터 관련성이 있는 것으로 알려진 품질 요구사항입니다.
- 이러한 고려 사항을 바탕으로 도출된 심사자는 지속적인 모니터링 작업에서 핵심적인 역할을 하는 경우가 많습니다.
- 예를 들어 규범적인 의학적 조언을 제공하지 않도록 하고, 비즈니스와 관련 없는 질문에 대한 답변을 거부하며, 서식 가이드라인을 준수하는 것 등이 있습니다.
- 이는 규제 요건, 비즈니스 이해관계자 관 점, 기업 스타일 요건 등을 포함하되 이에 국한되지 않는 다양한 정보를 기반으로 할 수 있습니다.
상향식: 이 접근 방식은 모델의 출력에서 관찰된 실제 실패 모드를 식별합니다.
- 이러한 심사자(judge)는 해결이 필요한 특정 문제를 정확히 찾아내는 데 중요하며, 성능 개선을 위해 오프라인 평가에서 많이 사용됩니다.
- 몇 가지 예로는 반복적인 출력, 구분 기호의 잘못된 사용, 비즈니스 전문 용어에 대한 오해 등이 있습니다.
- 이러한 실패 모드와 Judge를 파악하는 기법으로는 개방 코딩 및 축 코딩[1]과 같은 기법과, 실패의 고유한 범주를 발견하고 정의하기 위한 알고리즘 clusters 등이 있습니다.
예를 들어, 한 고객은 AI가 정확한 정보를 인용하도록 정확성에 대한 하향식 Judge를 구축했습니다. 에이전트 추적에 대한 상향식 분석을 통해 그들은 정확한 응답이 거의 항상 상위 두 개의 검색 결과를 인용한다는 패턴을 발견했습니다. 이 인사이트는 실측 정보 레이블을 사용할 수 없는 프로덕션 환경에서 정확성을 대리할 수 있는 새로운 심사자(judge)가 되었습니다. 두 가지 접근 방식을 조합하여 어느 하나만 사용하는 것보다 더 강력한 평가 시스템을 만들고 대규모 실시간 모니터링을 지원했습니다.
목표는 애플리케이션의 가장 우선순위가 높은 품질 차원을 정확하게 반영하는 최소한의 Judge 집합을 찾는 것입니다. 가장 효과적인 접근 방식은 하향식 인사이트와 상향식 인사이트를 모두 결합하여 Judge가 포괄적이면 서도 애플리케이션의 실제 성능과 관련이 있도록 보장하는 것입니다.
이것은 반복적인 프로세스입니다. 애플리케이션의 품질과 요구사항이 발전함에 따라 Judge 포트폴리오도 함께 발전할 것입니다. Judge를 시스템과 함께 성장하는 살아있는 결과물로 취급하세요.
전문 지식의 정확하고 신뢰성 있는 체계화
출력이 주관적이고, 문맥에 따라 다르며, 평가에 전문 지식이 필요한 도메인별 작업의 경우 '좋음'이 실제로 무엇을 의미하는지 정의하는 것은 매우 어렵습니다.
많은 기업 조직에는 구축 중인 애플리케이션의 품질을 평가할 만큼 충분한 지식을 갖춘 주제 전문가(SME)가 소수에 불과합니다. 이러한 SME는 소수이며 가치가 매우 높고 확장하기 어렵습니다. 구축하는 모든 Judge가 그들의 지식을 제대로 인코딩하도록 보장하면 전례 없는 규모로 애플리케이션을 평가할 수 있습니다.
이를 위해서는 신중한 구성과 보정이 필요합니다. 그렇지 않으면 심사자는 허용 가능한 결과물을 플래그 처리하거나, 실제 문제를 놓치거나, SME와는 다르게 요구사항을 해석할 수 있습니다.
발견: 중요한 것에 집중하기
중요한 예시를 수집하고 정성적 방법(예: )을 사용하여 엄격한 오류 분석을 수행합니다. 개방 코딩 및 축 코딩). 다음에 집중하세요:
- 엣지 케이스: 합격/불합격 결정이 모호한 경우
- 명확한 경계: 좋은 결과와 일반적인 실패 모드를 구분하여 정의
- 의견 불일치 지점 이해관계자들이 합리적으로 의견이 다를 수 있는 부분
Judge 주석 가이드라인: 인사이트를 명확한 기준으로 전환하기
오류 분석 결과와 필요한 모든 사전 Judge를 기반으로 주석 가이드라인을 만드세요. 여기에는 다음이 포함됩니다.
Judge를만들려는 관련 품질 차원 식별
참여자가 범주형 척도(주로 이진 또는 5점 리커트 척도)로 응답할 수 있는 비유도적이고 중립적인 진술 공식화. 잘못 작성된 가이드라인은 '응답의 품질이 높은가요?'라고 물을 수 있습니다. 잘 설계된 가이드라인은 '응답이 하나 이상의 소스 문서를 올바르게 인용합니까(예/아니오)'라고 명시하며, 이 Judge의 경우 서식 오류는 무시해야 한다는 점을 명확히 합니다.
SME에게 레이블을 제공하는 방법에 대한 명확하고 상세한 가이드라인 제공. 이 부분은 매우 철저해야 합니다. 예를 들어 Judge가 서식과 관련이 있고 서식이 올바르다면, 전체 답변이 틀렸더라도 성공으로 처리해야 합니다.
반복적 주석: 배치, 확인, 조정
SME가 한 번에 여러 예시에 주석을 달도록 하세요. 배치로 주석 작업을 하는 것을 권장하는 이유는 다음과 같습니다.
- 대부분의 조직은 이러한 유형의 레이블링 프로세스에 익숙하지 않아 적응 시간이 필요할 수 있습니다.
- 이를 통해 평가자 간 신뢰도 점수를 확인하여 SME가 작업에 대해 얼마나 일치된 이해를 하고 있는지 파 악할 수 있습니다.
합의 수준이 낮은 경우, 심사자(judge) 정의를 개선해야 하는지 또는 약간의 명확화만으로 충분한지 논의하여 파악해야 합니다.
의견 불일치는 정상적이며 예상되는 일입니다. 한 사례에서 세 명의 SME가 초기 예시에 대해 극심한 의견 불일치를 보였습니다. 동일한 결과물에 1점, 5점, 중립 등급을 매긴 것입니다. 배치 후 토론에서 문제가 드러났는데, Judge가 명시적으로 사실 정확성에만 초점을 맞췄음에도 불구하고 일부 SME는 서식 문제에 감점을 주었고, 다른 SME는 답변하지 않은 것에 점수를 주었습니다. 범위가 명확해지자 세 SME 모두 중립 점수로 의견을 모았습니다. 배치 주석 및 신뢰도 확인이 없었다면 이 혼란이 전체 데이터세트를 오염시켜 잘못된 것에 불이익을 주는 Judge를 생성했을 것입니다.
다행히 효과적인 Judge 생성 및 보정에는 수천 개의 예시가 필요하지 않습니다. 잘 선택된 20~30개의 예시만으로도 강력한 심사자(judge)를 만들 수 있습니다. 문제는 양이 아니라, 조직 내 도메인 전문가로부터 엣지 케이스와 결정 경계를 포착하는 체계적인 프로세스를 갖추는 것입니다. SME와 함께하는 3시간 세션만으로도 많은 Judge에 대해 충분한 보정을 제공할 수 있습니다.
전문가 피드백에서 프로덕션 심사자(judge)까지
평가 기준을 정의하고 도메인 전문가의 피드백을 수집했다면, 다음 과제는 이러한 인사이트를 프로덕션에 즉시 사용할 수 있는 Judge로 전환하는 것입니다.
여기에는 몇 가지 추가적인 기술적 과제가 있습니다. 즉, SME 피드백을 신뢰할 수 있는 Judge 동작으로 변환하고, 요구사항이 발전함에 따라 Judge 성능을 추적하기 위한 버전 관리를 하며, 대규모로 Judge를 실행하기 위한 배포 인프라를 구축하고, 여러 Judge를 동시에 관리하기 위한 오케스트레이션 시스템을 갖추는 것입니다.
이는 레이블이 지정된 데이터 세트에 대해 프롬프트를 최적화하여 안정적으로 일반화되는 Judge를 개발하고, 요구사항이 발전함에 따라 Judge를 버전 관리하며, 프로덕션에 배포하고, 품질 차원 전반에 걸쳐 여러 Judge를 오케스트레이션할 수 있음을 의미합니다.
프롬프트 최적화에는 수동 접근 방식과 자동 접근 방식이 있습니다. 수동 Judge 튜닝은 완전한 투명성과 제어권을 제공하지만 지루하고 비효율적일 수 있습니다. 자동 최적화 도구(DSPy 또는 MLflow의 프롬프트 옵티마이저 등)는 예시에 대해 다양한 프롬프트를 체계적으로 테스트하고 지능적으로 반복하여 강력한 기준선에 빠르게 도달할 수 있습니다. 트레이드오프는 제어권입니다. 일부 팀은 이러한 이유로 수동 접근 방식을 선호하지만, 일반적으로는 자동 프롬프트 옵티마이저 사용을 권장합니다.
접근 방식에 관계없이 기술 솔루션은 반복 작업을 빠르게 만들고 거버넌스를 견고하게 만들어야 합니다. 팀은 몇 주가 아닌 몇 시간 안에 심사자를 업데이트할 수 있어야 합니다. 프로덕션에 배포할 때 팀은 심사자가 안정적으로 보정되고 일관적으로 작동할 것이라는 확신이 필요합니다.
평가 기준을 통해 Judge를 생성하고 사람의 피드백과 지속적으로 일치시키는 직관적인 인터페이스를 제공하여 Judge를 사람의 피드백에 맞추는 프로세스를 간소화하는 Judge Builder를 발표하게 되어 기쁩니다.
자세한 내용은 MLflow 제품 업데이트 블로그 를 참조하세요.
핵심 내용
파일럿에서 프로덕션으로 성공적으로 전환하는 팀들은 Judge가 살아있는 결과물임을 인식합니다. Judge는 모델이 변경되고, 새로운 실패 모드가 나타나며, 비즈니스 요구사항이 바뀜에 따라 진화합니다. 이러한 팀들은 파일럿 단계에서 Judge를 한 번만 구축하는 대신, 시스템이 발전함에 따라 Judge를 지속적으로 발견, 보정, 배포하기 위한 가벼운 프로세스를 만듭니다. 이를 위해서는 세 가지 실질적인 노력이 필요합니다.
영향력이 큰 Judge에 먼저 집중하세요. 가장 중요한 규제 요건과 관찰된 실패 모드 하나를 식별하세요. 이것들이 첫 번째 Judge가 됩니다. 프로덕션에서 새로운 패턴이 나타나면 포트폴리오를 확장할 수 있습니다.
가벼운 SME 워크플로를 만드세요. 도메인 전문가와 함께 20~30개의 엣지 케이스를 검토하는 몇 시간만으로도 대부분의 Judge에 대한 충분한 보정이 가능합니다. 데이터의 노이즈를 제거하기 위해 SME 간의 의견을 엄격하게 일치시키고, MLflow와 같은 자동 프롬프트 옵티마이저를 사용하여 수집된 예시에 대해 프롬프트를 구체화하세요.
Judge를 살아있는 결과물로 취급하세요. 프로덕션 데이터를 사용하여 정기적인 Judge 검토 일정을 잡아 새로운 실패 모드를 파악하고 요구사항 변화에 따라 포트폴리오를 업데이트하세요.
저희가 관찰하는 가장 흔한 함정은 Judge 개발을 순전히 기술적인 문제로 취급하는 것입니다. 성공하는 팀은 기술 구현과 도메인 전문 지식 사이에 다리를 놓고, SME 지식을 포착하고 유지하기 위한 가볍지만 체계적인 프로세스를 만드는 팀입니다.
Databricks의 Judge Builder는 이 워크플로를 간소화하여 대규모로 심사자(judge)를 신속하게 개발하고 배포할 수 있도록 지원합니다. 투자는 최소한으로 이루어집니다. 종종 몇 시간의 SME 시간과 기본적인 도구만으로 충분합니다. 그 대가는 상당합니다. 신뢰할 수 있는 체계적인 평가와 파일럿에서 프로덕션으로 가는 명확한 경로를 얻게 됩니다. 팀이 맞춤형 에이전트를 구축하든 Agent Bricks 솔루션을 사용하든, 프로덕션으로 가는 길에는 품질을 측정 가능하고, 추적 가능하며, 개선 가능하게 만드는 것이 필요합니다.
저자: Pallavi Koppol, Alkis Polyzotis, Samraj Moorjani, Wesley Pasfield, Forrest Murray, Vivian Xie, Jonathan Frankle
(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)