레퍼런스
오류
이 페이지가 존재하는 이유는 하나의 구분 때문입니다. 실패한(failed) 실행과 오류가 난(errored) 실행은 서로 다른 것이며, 하나를 다른 하나로 제시하면 실제로는 하니스가 넘어졌을 뿐인데 개발자에게 변경이 나쁘다고 말하는 셈이 됩니다.
실패는 결과입니다. 오류는 그렇지 않습니다.
FAIL은 게이트가 평가되었고 근거가 임계값에 미치지 못했다는 뜻입니다. 이는 변경에 대한 품질 결과입니다.
RUN_ERROR는 실행이 완료되지 않았다는 뜻입니다. 게이트는 평가되지 않았고 변경에 대해 아무것도 측정되지 않았습니다. 이것은 결정 상태가 아니며, PARTIAL과 CANCELLED도 마찬가지입니다. 이들은 시스템에 대해 무엇이 결정되었는지가 아니라 실행에 무슨 일이 있었는지를 설명합니다.
미완료 실행이 보고하는 것
미완료 실행에 대한 게이트는 1이 아니라 5로 종료합니다. 근거가 나쁜 것이 아니라 누락된 것이며, 두 경우에는 다른 대응이 필요합니다. 실패한 게이트는 여러분의 변경을 살펴보라고 요구하고, 미완료 게이트는 여러분의 인프라를 살펴보라고 요구합니다.
측정할 수 없었던 케이스
오류가 난 케이스는 버려지지 않고 범위로 반영됩니다. 모든 지표는 전체, 적격, 관측, 누락의 네 가지 집계를 기록하며, 구간은 보지 못한 케이스를 고려합니다.
이것은 들리는 것보다 중요합니다. 채점되지 않은 케이스를 0으로 세는 지표는 시스템 자체의 장애를 모델의 품질 실패로 떠넘기며, 시스템이 실패하기 시작할 때 조용히 줄어드는 분모는 실패하는 시스템이 상승하는 점수를 보고하게 되는 경로입니다. 둘 다 호출의 13.8%가 HTTP 500을 반환한 운영 중인 어시스턴트에서 관찰되었습니다.
일시적 실패
시스템은 실패가 일시적이었다고 선언할 수 있으며, 일시적 실패는 품질 결과로 기록되지 않고 재시도됩니다. 제공자 타임아웃은 프롬프트에 대한 근거가 아닙니다.
선언은 명시적입니다. 호출 가능 시스템은 retryable=True와 함께 TransientError를 발생시킵니다. retryable의 기본값은 False이며, 이것이 없는 TransientError는 다른 예외와 마찬가지로 케이스에 기록되므로, 그 케이스는 재시도되지 않고 누락으로 처리됩니다. HTTP 시스템과 심사 제공자는 선언이 필요 없습니다. 타임아웃, 끊어진 연결, 429 또는 5xx는 자동으로 재시도됩니다. 어느 경우든 호출은 백오프를 두고 최대 네 번까지 시도되며, 그래도 실패한 케이스는 누락으로 처리됩니다. 진행 상황과 동시성에서 두 경우를 모두 보여 줍니다.
설정 오류
종료 코드 2는 호출이나 설정이 잘못되어 아무것도 실행되지 않았다는 뜻입니다. 할당량 거부도 그중 하나입니다. 이는 이유가 명시된 설정 오류로, 첫 케이스가 수행되기 전에 거부되며, 결코 결정 상태가 아닙니다. 상업적 사실이 품질 판정의 옷을 입고 나타나서는 안 됩니다.
실패한 것 진단하기
oloproof diagnose RUN_ID --intervention gold-context --criterion answer_correct개입은 실패한 케이스를 어떤 조건에서 다시 실행할지(gold-context, top-k 또는 reranker)이며, criterion은 어느 평가기의 실패를 대상으로 할지 정합니다. 진단은 실패 요인을 집계, 그 뒤에 있는 시나리오 ID, 그리고 진단이 세운 가정과 함께 보고합니다. 진단은 원인이 아니라 요인을 지목합니다. 엔진은 어떤 것이 다른 것을 만들어 냈다고 단언하지 않으며, 진단을 렌더링하는 어떤 화면도 마찬가지입니다.