일반 Evals에서 특정 모니터로: Annotation Queue Bridge

I’m happy to translate the text for you, but I’ll need the actual content you’d like translated. Could you please paste the article (or the portion you want translated) here? I’ll keep the source line exactly as you provided and preserve all formatting, markdown, and code blocks.

왜 일반적인 평가만으로는 충분하지 않은가

AI 신뢰성 논의에서 흔히 딜레마에 직면합니다: 품질이 중요하다는 것은 알지만, 어떤 실패가 가장 중요한지는 아직 모릅니다. 팀들은 종종 독성, 환각, 응답 길이와 같은 몇 가지 광범위한 평가를 배포하고 중요한 것을 잡아내길 기대합니다. 실제로는 프롬프트가 이미 그 검사를 통과했거나(모델이 지속적으로 해당 부분을 개선하도록 학습됨) 제품이 기본 평가에 포착되지 않는 다양한 방식으로 실패합니다.

일반적인 평가는 “마시기엔 괜찮지만”, 제품 수명 주기의 초기 단계를 넘어서는 지속성을 제공하지 못합니다. 실패 유형은 보편적인 표준이 아니라 각 제품마다 고유합니다. 그럼에도 불구하고 보편적인 표준은 AI 신뢰성에 여전히 유용할 수 있으며, 바로 annotation queues가 그 역할을 합니다.

Source: …

정밀한 평가 작성을 위한 닭‑달걀 문제

좋은 평가는 감지하려는 실패 사례의 예시가 필요합니다. 시스템에서 나쁜 상호작용은 실제로 어떻게 보이나요? 충분히 오래 운영하면서 관찰하기 전까지는 알 수 없으며, 평가 없이는 체계적으로 관찰할 수 없습니다.

팀은 종종 추측에 의존합니다: 무엇이 잘못될지 생각하고 평가 스크립트를 작성하고, 손수 만든 몇 개의 예시로 테스트하고, 배포하고, 다시는 보지 않습니다. 몇 달 후에 그 평가는 인간이라면 플래그를 달았을 모든 흔적을 조용히 통과하고 있었다는 것을 발견합니다. 실제 실패 패턴은 그들이 상상한 것과 전혀 달랐습니다.

시스템 큐: 일반 메트릭과 특정 모니터 사이의 다리

모든 프로젝트에는 다음과 같은 보편적인 실패 카테고리를 다루는 기본 체크가 포함됩니다:

• 탈옥 시도
• 사용자 불만
• 게으른 응답
• 맥락 누락
• 도구 호출 오류

이것들은 최종 모니터링 레이어가 아닙니다. 시스템 큐는 일반적인 실패를 포착하는 그물 역할을 하며, 주석 작업을 시작하게 해줍니다.

다음과 같이 생각해 보세요:

• 시스템 큐 = 모니터링 시스템 (잠재적으로 문제가 있는 트레이스를 표시)
• 평가 = 진단 (실제로 무엇이 잘못됐는지 판단)

인간 리뷰어가 표시된 각 트레이스를 열어 무엇이 잘못됐는지 판단하고, 간단한 주석을 추가합니다—예를 들어 “에이전트가 제품 변형을 혼동함”이라는 메모와 함께 thumbs‑down을 다는 식입니다. 그 주석은 구체적이며 실제 상호작용에 기반하고, 유사한 실패를 이름이 붙은 이슈로 클러스터링하는 데 사용되는 데이터가 됩니다. 예시:

• “에이전트가 반품 기간을 잘못 인용함”
• “에이전트가 업로드된 문서를 무시함”
• “에이전트가 진행 없이 도구 사이를 반복함”

어떤 이슈든지 모니터링 평가를 생성할 수 있습니다—주석이 달린 예시를 기반으로 만든 스크립트이며, 실제 트래픽에 적용되기 전에 인간 판단에 맞춰 최적화됩니다. 이렇게 하면 추측 없이 일반적인 것에서 구체적인 것으로 전환할 수 있습니다.

구체적인 예시: 가격 혼란

1. 관찰 – 에이전트가 때때로 잘못된 가격을 제시합니다.
2. 초기 평가 – 가격 데이터베이스와 응답을 비교하는 평가를 작성합니다. 가격 자체는 기술적으로 정확하기 때문에 통과합니다.
3. 실제 실패 – 실제 운영에서는 에이전트가 사용자가 문의한 SKU를 잘못 읽어, 잘못된 제품 변형에 대해 올바른 가격을 인용합니다.

annotation queues를 사용하면 “Frustration” 큐가 사용자가 에이전트를 바로잡는 트레이스를 표시합니다. 검토자는 이를 다음과 같이 주석을 달습니다: “에이전트가 제품 변형을 혼동함.” Latitude는 다섯 개의 유사한 주석을 하나의 이슈로 클러스터링합니다. 그런 다음 에이전트가 가격을 인용하기 전에 올바른 변형을 식별했는지 확인하는 평가를 생성합니다. 이 평가는 실제 문제 사례에서 만들어졌기 때문에 실제 문제를 잡아냅니다.

이 평가를 미리 작성할 수 없었습니다—실패가 변형 혼동 형태일 것이라는 것을 사전에 알 수 없었기 때문입니다. 여러분은 환상적인 기능을 기대했지만, 현실은 보통 그렇듯 다르게 나타났습니다.

주석을 보정 데이터로 전환하기

일반 평가 결과를 검토하면서 만든 모든 주석은 나중에 생성하는 특정 평가를 위한 보정 데이터가 됩니다. 인간과 자동 평가가 동일한 트레이스를 모두 점수화하면 Latitude와 같은 플랫폼이 정렬 메트릭을 계산할 수 있으며, 이는 평가가 인간 판단과 일치하는지를 나타냅니다:

• 높은 정렬 → 신뢰할 수 있는 평가
• 낮은 정렬 → 더 많은 주석을 추가하고 재‑최적화

문제를 발견하기 위해 수행한 작업은 이를 모니터링하는 평가를 검증하기도 합니다. 아무것도 낭비되지 않습니다.

실용적인 워크플로우

1. 기본 시스템 큐부터 시작 – 트래픽의 **5–10 %**를 샘플링하도록 설정합니다.
2. 일일 검토 – 매일 약 15 분 동안 각 큐를 검토할 사람을 지정합니다.
3. 간단한 주석 – 부정 표시와 짧은 메모(예: “에이전트가 오래된 가격을 제공함”)만 있으면 충분합니다; 실패에 대한 컨텍스트가 포착되었는지 확인하세요.
4. 문제 클러스터링 및 명명 – 충분한 주석이 쌓인 후, 예상하지 못한 자동 클러스터링된 실패 패턴을 확인하려면 Issues 페이지를 확인하세요.
5. 목표 평가 생성 – 가장 영향력 있는 문제를 선택하고 평가를 만들며 정렬 메트릭을 모니터링합니다. 정렬이 낮으면 주석을 더 추가하고 시스템이 다시 최적화하도록 합니다.
6. 반복 – 사이클을 반복합니다. 각 반복은 막연한 우려를 정확하고 보정된 모니터로 전환합니다. 시간이 지나면 일반 시스템 큐의 중요성이 감소합니다—큐를 제거해서가 아니라, 이제 특정 평가가 실제로 중요한 실패를 다루기 때문입니다.

Conclusion

일반적인 메트릭이 전부는 아니지만, 이를 annotation queues(주석 대기열)로 생각하면 신뢰할 수 있는 AI 제품을 설계하기 위한 견고한 출발점을 제공합니다. 볼륨을 신호로 변환하여—수천 개의 generic‑eval‑flagged 트레이스를 소수의 주석이 달린 실행 가능한 예제로 바꿈으로써—광범위하고 추측에 기반한 모니터링에서 정확하고 신뢰할 수 있는 평가로 연결되는 다리를 구축하게 되며, 시스템이 확장될수록 신뢰성을 유지할 수 있습니다.