프롬프트를 변경하는 것은 릴리스 프로세스를 거치기에는 너무 사소하게 느껴질 수 있습니다. 모델을 교체하거나, 검색 청킹 (retrieval chunking)을 변경하거나, 도구 호출 (tool call)을 추가하는 것은 단순한 구현 세부 사항처럼 보일 수 있습니다. 하지만 고객 대상 AI 기능의 경우, 이러한 각각의 변화는 사용자가 보는 것, 비용, 소요 시간, 그리고 어떤 실패가 발생할 수 있는지를 변화시킬 수 있습니다.

그렇기 때문에 릴리스 전에 던져야 할 유용한 질문은 "데모가 좋아 보이는가?"가 아닙니다. 바로 이것입니다: 어떤 사용자 작업이 퇴보할 수 있는가, 우리는 그것을 어떻게 알아챌 것인가, 그리고 누가 릴리스를 보류할지 결정할 수 있는가?

이 질문을 던지기 위해 플랫폼을 구매할 필요는 없습니다. 버전이 지정된 작은 예시 세트와 명시적인 임계값 (thresholds)만으로도 다음 결정을 더 방어 가능하게(defensible) 만들기에 충분합니다.

하나의 릴리스 결정부터 시작하세요

"어시스턴트를 평가하라"는 식으로 시작하지 마세요. 실제로 배포될 좁은 범위의 변경 사항을 선택하세요. 예를 들어:

비밀번호 재설정 및 플랜 권한 질문에 대해 새로운 검색 구성 (retrieval configuration)을 트래픽의 10%에 배포할 수 있는가?

이렇게 하면 팀에게 의사 결정권자, 범위, 그리고 롤백 경계 (rollback boundary)가 부여됩니다. 또한 평가 세트가 흥미로운 프롬프트들의 무제한적인 수집물이 되는 것을 방지합니다.

이미 알고 있는 일반적인 작업과 실패 사례를 포함하세요

유용한 시작 세트는 작지만 의도적으로 혼합되어 있어야 합니다. 지원 어시스턴트의 경우, 다섯 가지 카테고리만으로도 매우 다른 리스크를 드러내기에 충분합니다:

1. 비밀번호 재설정 요청과 같은 일반적인 성공 사례.
2. 정책을 지어내는 대신 답변을 사용할 수 없다고 말하는 것이 올바른 동작인 검색 실패 (retrieval miss) 사례.
3. 지시 사항 충돌 (instruction conflict) 또는 프롬프트 인젝션 (prompt injection) 시도.
4. 불필요한 개인 데이터 없이 명확한 설명이 필요한 불완전한 고객 요청.
5. 승인된 출처나 에스컬레이션 (escalation)이 필요한 가격 또는 권한 주장.

목표는 벤치마크 점수가 아닙니다. 목표는 일반적인 경로와 알려진 실패 방식이 동일한 검토 과정에서 가시화되도록 만드는 케이스 세트입니다.

선호하는 답변뿐만 아니라 동작을 정의하세요

각 예시마다 관찰 가능한 기대 동작 (expected behavior)을 문서화하세요. "도움이 되는 답변"은 관찰할 수 없습니다. "리셋 경로를 두 단계로 설명하고 계정 상태를 안다고 주장하지 마세요"는 관찰 가능합니다.

이는 여러 평가자가 스타일(style)에 대해서는 의견이 갈리더라도, 응답이 취소 정책을 날조(fabricate)했거나, 숨겨진 지침을 공개했거나, 필수 인용을 누락했다는 점에는 동의할 수 있을 때 중요합니다. 이것들은 서로 다른 담당자와 서로 다른 출시 영향(release implications)을 가진 서로 다른 실패 클래스 (failure classes)입니다.

품질이 낮은 답변과 출시 차단 실패를 분리하세요

모든 불완전함이 배포 (rollout)를 중단시켜야 하는 것은 아닙니다. 팀은 현재 진행 중인 변경 사항에 대해 어떤 실패가 수용 불가능한지 사전에 결정해야 합니다. 날조된 상업 정책은 치명적일 수 있습니다. 추가적인 설명이 한 번 더 필요한 답변은 치명적이지 않을 수 있지만, 여전히 추적할 가치가 있습니다.

이를 통해 중요한 결과를 도출할 수 있습니다. 즉, 높은 통과율 (pass rate)을 기록하더라도 여전히 "보류 (hold)\

JSONL 파일과 간단한 스크립트를 사용하여 이를 수행할 수 있습니다. 핵심적인 습관은 입력값(inputs)에 버전을 매기고, 게이트(gate)가 왜 승인(approved)했는지, 보류(held)했는지, 또는 예외(exception)를 허용했는지 그 이유를 기록하는 것입니다.

게이트를 인증서가 아닌 의사결정 보조 도구로 취급하십시오

그 어떤 테스트 세트(test set)도 AI 시스템이 안전하거나 규정을 준수함을 증명할 수는 없습니다. 테스트 세트는 보안 검토(security review), 법률 검토(legal review), 모니터링(monitoring) 또는 인간의 판단(human judgment)을 대체할 수 없습니다. 테스트 세트가 할 수 있는 일은 릴리스(release)에 관한 논의를 개인의 취향이나 기억에 의존하는 방식에서, 팀이 검토할 수 있는 증거(evidence) 기반의 방식으로 전환하는 것입니다.

작게 시작하고 싶은 팀들을 위해 무료 10가지 질문 준비도 스코어카드 (10-question readiness scorecard)와 합성 5개 사례 평가 샘플 (synthetic five-case evaluation sample)을 공개했습니다. 전체 LaunchGate 페이지에서 워크플로우(workflow)를 설명하고 있으며, 판매자 확인이 완료된 후 라이브 체크아웃(live checkout) 기능이 추가될 예정입니다.