진짜 검토 과정
지난주, 저는 고객 서비스 상담원을 위한 회귀 테스트를 조직하고 있었습니다. 가장 골치 아픈 질문은: 각 모델 미세 조정 후에 어떤 부분이 개선되었고 어떤 부분이 실제로 악화되었는지 어떻게 빠르게 알 수 있을까 하는 것이었습니다.
전통적인 단위 테스트는 적합하지 않습니다—LLM 출력은 자연어이며 고정된 어설티브 값이 없습니다. 여러 도구를 살펴본 끝에 마침내 LLM Evals Playbook이라는 아이디어를 선택했습니다. 단일 PDF가 아니라 실행 가능한 평가 프레임워크입니다. 핵심 프로세스는 평가 기준을 정의→ 테스트 데이터셋을 생성→ 평가 실행→ 결과 분석 및 반복입니다.
아래는 제가 처음 실행한 완전한 링크로, 각 단계에 대응하는 코드와 설정 파일이 포함되어 있습니다.
1단계: 평가 기준 정의
평가는 비즈니스 관점에서 시작해야 합니다. 제 시나리오는 고객 서비스 Q&A라서 세 가지 차원을 정의했습니다:
- 답변 정확성: 답변이 제공된 지식 기반에 기반하는지, 답변이 아닌 것인지는 불확실합니다.
- 무결성: 사용자의 문제의 모든 하위 이슈가 보장되는지 여부.
- 톤 준수: 친절하게 행동하고 책임을 회피하지 않는지.
각 차원은 1에서 5까지의 척도로 평가되며, 평가 기준에 대한 설명이 제공됩니다. 플레이북은 이러한 기준이 실행 가능해야 한다고 요구합니다; 예를 들어, "정확성"은 단순히 "올바름"이 아니라 "답변의 모든 정보는 지식 기반의 원본 텍스트에서 추적 가능해야 한다"고 써야 합니다.
여기서 가장 흔한 실수는 너무 모호한 기준입니다. 제 첫 번째 버전은 "답변은 정확해야 한다"라고 썼지만, 평가자마다 점수가 크게 달랐습니다. 이후 "지식 기반에 없는 엔티티나 데이터가 포함되어 있으면 2점 감점"으로 변경되어 일관성이 향상되었습니다.
2단계: 테스트 데이터셋 생성
Playbook은 데이터셋에 세 가지 유형의 샘플을 포함할 것을 권장합니다: 정상 문제, 엣지 문제(예: 맥락 누락), 그리고 대립적 문제(예: 부적절한 콘텐츠를 생성하도록 유도된 모델).
저는 제 사업에서 실제 사용자 로그를 사용해 50개의 일반 질문을 생성한 뒤, 20개의 엣지 질문과 10개의 대립 질문을 수동으로 만들었습니다. 대립적인 질문을 만들 때는 주의하세요—인터넷에서 직접 프롬프트 인젝션 템플릿을 복사하지 마세요. 이는 실제 비즈니스 시나리오와 자주 다르기 때문입니다.
핵심 실패 지점: 데이터셋은 평가 기준과 일치해야 합니다. 만약 기준이 '환각을 감지하지 않는다'고 요구하지만, 데이터셋 내 대부분의 질문이 단순한 쿼리이고 모델이 근거 없는 주장을 만들어내지 않는다면, 평가 결과는 독특함이 부족합니다. 올바른 방법은 먼저 소규모 샘플 분석으로 모델이 오류가 발생하기 쉬운 부분을 확인한 후 그에 맞게 데이터셋을 보완하는 것입니다.
3단계: 작전 평가
저는 LangChain의 Evaluator 프레임워크를 사용해 플레이북에 연결했습니다. 각 테스트 샘플의 평가 과정은 다음과 같습니다: 먼저 평가받는 에이전트가 질문에 답하고, 그 다음 평가자 LLM(예: GPT-4o)이 미리 설정된 기준에 따라 점수를 매깁니다.
점수 산정에는 이유가 따라와야 하며, 단순한 점수일 수는 없습니다. 예를 들어: "정확도 4점: 답변에는 가격이 199위안이라고 되어 있었지만, 지식 기반에는 1999위안이 나오고 1점을 차감했습니다." 완전성 5점 포함: 가격, 배송 시간, 애프터서비스 세 가지 하위 문제를 다룹니다. "이로 인해 이후 분석 시 정밀한 결함 위치를 파악할 수 있습니다.
4단계: 결과를 분석하고 반복한다
평가가 완료되면 제 출력은 CSV 테이블이 되며, 각 행에는 샘플 + 각 차원별 점수 + 추론이 표시됩니다. 분석 시 집중해야 할 주요 사항:
- 일반적으로 낮은 점수를 받는 차원: 무결성 평균이 2.5에 불과하면, 모델이 자주 정보를 놓친다는 의미입니다.
- 표본 점수가 크게 변동하는 경우: 평가자나 표본 간 차이가 있어 종종 불명확한 기준을 가리킵니다.
첫 실행 결과: 정확도 4.2, 완전성 3.0, 톤 4.8. 무결성이 낮은 이유는 모델이 사용자의 명시적인 질문에만 답변하고 관련 정보를 적극적으로 제공하지 않기 때문입니다(예: 사용자가 "배송은 언제 배송되나요?"라고 물으면 배송 시간에는 답하지만 물류 조회 방법은 명시하지 않습니다). 그래서 "사용자의 문제가 주문과 관련된 경우, 주문 번호를 적극적으로 추가하여 물류를 확인하세요."라는 프롬프트를 추가했습니다. 두 번째 검토 라운드에서는 완성도를 4.5로 향상시켰습니다.
실패와 오해가 가장 쉬운 영역
플레이북의 가장 큰 함정은 데이터셋과 표준 간의 단절입니다. 많은 사람들이 템플릿을 기반으로 몇 가지 기준을 작성한 뒤, HuggingFace에서 무작위로 데이터셋을 뽑아 리뷰를 실행합니다. 결과는 훌륭해 보이지만 실제 비즈니스 문제를 반영하지는 않습니다. 올바른 접근법은 표준과 데이터셋이 동일한 비즈니스 시나리오에서 나와야 하며, 소규모 검증을 먼저 해야 한다는 것입니다.
또 다른 흔한 실수는 리뷰를 일회성 수락으로 취급하는 것입니다. 플레이북의 가치는 연속 회귀에 있습니다: 모델 업데이트나 조정 후 매번 재실행해야 하며, 이는 "검토 - > 분석 - > 수정 - > 재평가"의 순환을 형성합니다. 한 번만 뛰고 그냥 두면 사실상 리뷰가 없습니다.
지금 착륙하고 싶다면, 먼저 무엇을 해야 할까요?
- 특정 비즈니스 시나리오를 선택하세요(예: 고객 서비스 Q&A, 코드 생성, 요약). 모든 능력을 다 포기하려고 하지 마세요.
- **2-3개의 실행 가능한 평가 차원을 정의하며, 각 차원에 대한 추론 기준을 명확히 명시합니다.
- 실제 샘플 10개를 수집해 수동으로 실행하세요: 스스로 기준을 사용해 기준이 명확한지, 데이터셋이 차별화되었는지 확인합니다. 이 단계는 한 시간도 채 걸리지 않습니다.
- **수동 실행 결과를 바탕으로 기준을 조정한 후 50-100개 샘플로 확장하세요.
- **자동화 프레임워크(LangChain, DeepEval 등)에 접속하고 루프를 시작하세요.
다음에 체계적인 학습을 위해 어디로 가야 할까요
더 완전한 평가 시스템을 구축하거나 평가를 에이전트 엔지니어링에 체계적으로 통합하는 방법을 배우고 싶다면, 더 체계적이고 오리지널 유료 논문과AI고급 프로그래밍 강좌를 더 읽어볼 수 있습니다.
아직 댓글이 없습니다