비즈니스 AI 시스템을 위한 시나리오 기반 평가 세트 설계법

구매 요청 지원 도구가 그럴듯한 신청서, 서로 다른 공급업체 식별자, 조회되지 않는 구매 정책, 도구를 조종하려는 문구가 삽입된 견적서를 한꺼번에 받았다고 하자. 매끈하게 작성된 예시 질문 몇 개로는 도구가 누락 증거를 알리고, 삽입된 지시를 무시하며, 권한 있는 사람에게 다음 단계를 넘기는지 확인하기 어렵다. 필요한 것은 어려운 질문 모음이 아니라 실제 업무 상태와 허용 범위를 되살리는 시나리오다.

좋은 평가 세트는 하나의 시스템 버전과 한정된 업무 흐름, 허용된 사용자·자료·도구, 평가가 지원할 의사결정을 먼저 고정한다. 그런 다음 일상 업무를 관찰된 비중에 맞춰 담되 드물지만 중대한 경계, 확인된 실패, 명시적으로 금지된 행동을 의도적으로 더한다. 결과를 보기 전에 보고할 슬라이스와 게이트, 채점 규칙을 정해야 높은 평균점수 뒤에 중요한 실패가 숨지 않는다.

시나리오 기반 평가 세트에는 무엇을 담아야 할까?

평가 세트는 대표 업무, 중요한 경계 사례, 확인된 실패, 금지 행동을 함께 덮는 범위 지도로 시작해야 한다. 먼저 승인된 업무 기록, 지원 문의, 사용자 조사와 도메인 전문가의 업무 순회 검토에서 과업군과 변형을 찾는다. 운영 자료가 부족하거나 출시 전이라면 비중을 꾸며내지 말고 가설과 불확실성을 표시한다. 여기서 제안하는 네 갈래 지도는 여러 평가 지침을 비즈니스 업무에 맞게 엮은 방법이지 단일 기관의 표준 분류가 아니다.

구매 요청 지원 도구라면 완전한 신청서뿐 아니라 필수 서류 누락, 신청서와 견적서의 금액·공급업체 불일치, 판단 근거 부재, 승인 우회 요청, 업로드 문서 안의 지시, 오래됐거나 서로 모순되는 정책 조회 결과를 포함한다. 확인된 과거 실패는 승인받은 합성 또는 비식별 재현본으로 줄여 보존한다. 지출 승인이나 발주 실행, 다른 사람의 기밀 공개처럼 금지할 행동은 조직별 책임자가 정의해야 하며 이 예시의 규칙을 그대로 가져와서는 안 된다.

각 평가 시나리오는 어떻게 기록해야 재현할 수 있을까?

각 시나리오는 다른 평가자가 같은 시작 조건을 복원하고 허용 결과와 금지 결과를 구분할 수 있는 사례 기록으로 남겨야 한다. 하나의 모범 문장만 정답으로 두지 말고 필수 사실과 상태 변화, 허용 가능한 대안 경로, 확인 질문·보류·거절·에스컬레이션이 필요한 조건을 적는다. 운영 자료를 쓸 때는 재사용 권한과 최소화 여부를 확인한다. 비결정적이거나 다단계인 시스템은 필요한 시행 횟수와 집계 규칙도 출력을 보기 전에 정한다.

• 식별 정보: 안정적인 사례 ID, 소유자, 상태, 버전 이력, 과업군, 범위 갈래, 슬라이스, 결과의 중대성, 개발용 또는 보호된 출시 테스트 구분
• 출처 정보: 운영·과거·도메인·합성·사람 작성 등 출처 범주, 사용 승인 기록, 접근이 허용될 때만 보관하는 원자료 연결 정보
• 실행 조건: 사용자 역할과 목표, 초기 업무 상태, 요청·파일·대화 이력, 승인된 지식, 권한, 도구와 도구 결과, 시스템 지시
• 판정 정보: 필수 결과, 허용 가능한 대안, 금지 출력·공개·도구 호출·상태 변경, 채점자, 루브릭, 게이트와 참조 해법
• 운영 정보: 모델, 프롬프트, 검색 자료, 정책, 권한, 도구, 평가 하네스 버전과 검토자 자격, 보정 버전, 이견 판정 경로

쓸모 있는 평가 사례는 어려운 질문을 던지는 데 그치지 않고, 한정된 업무와 성공·허용 변형·금지 행동을 다시 검사할 수 있게 만든다.

잘못된 행동에 점수를 주지 않으려면 어떻게 채점해야 할까?

각 사례에는 성공과 실패를 유효하게 구분할 수 있는 가장 좁은 채점 방식을 붙여야 한다. 객관적인 값, 스키마, 계산, 도구 인자, 기록 상태와 금지 행동은 결정적 검사로 확인하고, 필요한 사실이나 최종 상태는 한정됐지만 표현과 경로가 다양하면 참조 사실 또는 작동하는 참조 해법을 쓴다. 개방형 품질은 관찰 가능한 차원별 기준으로 나누고 모델 채점자는 해당 맥락의 자격 있는 사람 판단에 맞춰 보정한다. 전문 해석이 필요한 판단은 권한 있는 전문가에게 남긴다.

• 정확성·상태 검사: 예상 값만 보지 말고 검사가 빠뜨린 조건과 의도하지 않은 지름길이 없는지도 확인한다.
• 참조 해법: 사례의 해결 가능성과 필수 요소를 입증하는 용도로 쓰되 유효한 다른 표현이나 경로를 배제하지 않는다.
• 차원별 루브릭: 유용성, 완전성, 근거성처럼 서로 다른 품질을 분리하고 각 점수에 관찰 가능한 기준과 예시를 둔다.
• 부분 점수와 게이트: 의미 있는 과업 구성요소는 나눠 채점할 수 있지만 금지된 공개나 무단 행동은 평균으로 상쇄하지 않는다.
• 버전 고정: 루브릭, 게이트, 슬라이스, 시행 집계와 의사결정 규칙을 후보 출력 비교 전에 고정하고 변경 시 새 평가 버전으로 기록한다.

검토자는 어떻게 같은 기준을 일관되게 적용할 수 있을까?

검토의 일관성은 출력물을 보여주기 전에 업무 목적, 사용자 역할, 사용 가능한 증거, 허용 행동, 제품 경계와 루브릭 버전을 동일하게 제공하는 데서 시작한다. 점수마다 관찰 가능한 기준점과 긍정·부정·경계 예시를 두고, 사례 자체가 불완전하면 억지로 점수를 내는 대신 ‘판정 불가’를 선택하게 한다. 본 검토 전에는 보정 사례를 적용하고 과업 구성, 정책, 루브릭이나 검토자 집단이 바뀌면 다시 보정한다.

1. 비교 평가에서는 가능한 범위에서 시스템 정체와 출력 순서를 가린다.
2. 토론 전에 각 검토자의 점수와 근거를 독립적으로 기록한다.
3. 이견을 사례 결함, 불명확한 기준, 누락 맥락, 정당한 복수 답안 또는 미결정 제품 정책으로 분류한다.
4. 판정 책임자를 지정하되 정당한 복수 답안이나 아직 정하지 않은 정책을 억지 합의로 덮지 않는다.
5. 원래 라벨, 근거, 루브릭 버전과 최종 판정을 보존해 이후 검토와 자동 채점자 보정에 사용한다.

개발과 출시가 반복돼도 평가 세트의 증거 가치를 어떻게 지킬까?

평가 세트의 증거 가치는 반복 개선에 공개적으로 쓰는 개발 세트와 제한적으로 쓰는 보호된 출시 테스트를 분리할 때 지킬 수 있다. 개발 세트는 프롬프트, 검색, 도구, 정책과 업무 흐름을 고치는 데 유용하지만 팀이 사례에 맞춰 최적화했으므로 독립적인 출시 추정치가 아니다. 보호 세트의 소속은 일상 실행이나 출력 검토 전에 정하고, 정확한 사례·답·루브릭·결과가 변경 방향을 이끌지 않도록 접근을 통제한다.

• 두 세트 사이의 완전·근접 중복, 같은 원자료, 바꿔 쓴 사례와 동일 템플릿에서 나온 형제 사례를 점검한다.
• 사례 내용, 참조 답안, 루브릭과 결과에 누가 또는 어떤 시스템이 접근했는지 기록한다.
• 진단이나 수정에 쓰인 실패 사례는 개발·회귀 세트에 두고 보호 세트에서는 독립적으로 만든 비중복 사례로 같은 실패군을 시험한다.
• 보호 사례가 변경에 실질적으로 영향을 줬다면 개발·회귀 세트로 옮기고 버전이 붙은 대체 사례를 추가한다.
• 레지스트리에 소유자, 출처, 승인, 분할, 노출, 버전, 검토 이력, 변경 이유와 폐기 이유를 함께 남긴다.

업무 흐름, 사용자, 정책, 지식 자료, 모델, 프롬프트, 도구, 권한이나 운영 환경이 실질적으로 바뀌면 범위와 측정 방법을 다시 검토한다. 결과는 과업군, 범위 갈래, 슬라이스, 결과의 중대성과 게이트별로 나눠 보고해야 한다. 오프라인 통과는 의사결정 증거 중 하나일 뿐 사업 가치, 안전성, 공정성, 규정 준수나 운영 준비를 단독으로 입증하지 않는다. 모니터링, 사용자 조사, 사건 검토를 함께 보고 규제되거나 중대한 판단은 자격과 권한을 갖춘 담당자에게 남겨야 한다.