결과와 실행 참조

실행이 HTTP 시스템에 무엇을 보내고 무엇을 돌려받기를 기대하는지, 각 케이스가 지표의 분모에 어떻게 들어가는지, 결정 상태와 그 이유를 설명하는 이유 코드, 종료 코드, 그리고 어떤 데이터가 로컬에 남고 어떤 데이터가 호스팅 워크스페이스로 옮겨지는지를 정리합니다. 그 바탕이 되는 개념은 개념을, 정책 필드는 구성 참조를 읽으세요.

HTTP 시스템 계약

HTTP 시스템(oloproof.yaml의 system.http)은 케이스마다 한 번, 반복마다 한 번 호출됩니다.

URL, 메서드, 출력 경로, 아티팩트 매핑은 시스템 버전에 들어가지만, 서버가 하는 일은 들어가지 않습니다. 서버의 동작이 바뀔 때마다 system.version을 바꾸세요. 이유는 구성 참조를 보세요.

서로 다른 세 가지 어휘

결과에는 세 종류의 상태가 있으며, 서로를 대신하지 않습니다.

정상적으로 끝난 실행은 DECIDED이고, 조기 중단으로 끝났으면 DECIDED_EARLY입니다. Ctrl-C나 작업 취소로 중단된 실행은 CANCELLED이고, 하네스가 예외를 일으킨 실행은 RUN_ERROR입니다. 둘 다 실행을 PARTIAL로 남기고, 끝난 케이스를 보존하며, 다음 실행이 캐시된 레코드를 재사용하게 합니다. 오류를 보세요.

최소 임계값 T와 구간 [L, U]에 대해, 규칙은 L >= T이면 PASS, U < T이면 FAIL, 그 밖에는 INSUFFICIENT_EVIDENCE입니다. 최대 임계값은 대칭입니다. 구간을 읽기 전에 규칙은 결정을 내려야 하는지부터 확인합니다. 먼저 MANUAL_REVIEW의 이유를, 다음으로 INSUFFICIENT_EVIDENCE의 이유를 봅니다. 이유가 있는 첫 단계가 결정하며, 찾은 이유를 모두 나열합니다.

이유 코드

모든 결정에는 하나 이상의 이유 코드가 붙습니다.

MANUAL_REVIEW

INSUFFICIENT_EVIDENCE

PASS와 FAIL

호스팅 워크스페이스 전용

푸시된 실행을 직접 결정하는 워크스페이스는 ppi_not_verified(결정의 근거가 되는 구간을 검증하지 않았음), execution_not_verified(출력이 등록된 러너에서 나오지 않았음), workspace_cannot_decide(정책 사본이 없거나 증거를 읽을 수 없었음)로 결정을 보류할 수 있습니다. 게이팅을 보세요.

각 케이스가 분모에 들어가는 방식

모든 지표는 네 가지 개수를 보고합니다. n_total(스위트의 케이스), n_eligible, n_observed, n_missing이며, n_eligible = n_observed + n_missing입니다. n_eligible 밖의 케이스는 이유와 함께 exclusions 아래에 나열됩니다.

누락 케이스는 버려지지 않고 경계 지어집니다. 통과율의 경우 구간의 하한은 모든 누락 케이스를 실패로, 상한은 성공으로 취급하므로, 누락 케이스가 많은 실행은 구간이 넓어 까다로운 규칙을 통과할 수 없습니다. 경계 있는 평균은 같은 방식으로 선언한 범위의 양 끝을 대입합니다. 누락 케이스를 경계 지을 수 없는 방법(예: 순위 통계량)은 그것을 버리고 그 가정을 기록하며, 그 위의 규칙은 max_missing_fraction을 선언할 때까지 missingness_unbounded를 읽습니다.

observed_count 규칙은 실행된 스위트에 대해 실패를 세며 구간을 읽지 않습니다. 관측된 실패에 모든 누락 케이스를 더해도 여전히 max_failures 안에 들어갈 때만 통과합니다.

승인된 구간이 없는 지표

규칙은 감사를 통해 승인된 방법의 구간으로만 결정합니다. 그런 구간이 없으면 지표는 여전히 계산되어 표시되지만, 그 위의 규칙은 검증되지 않은 방법을 빌려 오지 않습니다.

종료 코드

oloproof gate, 정책을 지정한 oloproof run, 그리고 결정을 내리는 다른 명령은 모두 같은 코드를 씁니다.

여러 개가 해당하면 1, 5, 4, 3 중 처음 것이 보고됩니다. block_on에서 빠진 상태는 종료 코드를 바꿀 수 없습니다. block_on: [FAIL]과 warn_on: [INSUFFICIENT_EVIDENCE]에서는 결정되지 않은 규칙이 경고하고 게이트는 0으로 종료합니다. 따라서 종료 코드 0은 정책이 차단하는 일이 일어나지 않았다는 뜻일 뿐, 모든 규칙이 통과했다는 뜻이 아닙니다. 게이팅을 보세요.

작업이 실행되는 곳과 데이터가 가는 곳

로컬, 기본값

oloproof run, oloproof gate, SDK는 여러분의 컴퓨터에서 실행됩니다. 모든 레코드(케이스, 출력, 아티팩트, 판정, 지표, 결정)는 oloproof.yaml 옆의 .oloproof/store.sqlite에, 또는 설정되어 있으면 OLOPROOF_HOME 아래에 기록됩니다. Oloproof로는 아무것도 보내지 않습니다. 네트워크 트래픽은 구성이 일으키는 것뿐입니다. HTTP 시스템의 URL로 가는 호출, 그리고 모델 심사 모델이나 모델 분류기가 제공자에게 하는 호출이며, 제공자는 심사하는 케이스 내용을 받고 그에 대해 요금을 청구합니다.

호스팅 워크스페이스로 푸시하기

oloproof push는 실행의 증거를 oloproof login으로 연결한 워크스페이스로 보냅니다. 기본적으로 지표, 구간, 결정, 집계 슬라이스, 그리고 모든 레코드의 식별자, 상태, 소요 시간, 사용량을 보내지만 내용은 보내지 않습니다. 원본 내용은 무엇이든 컴퓨터를 떠나기 전에 필드별로 가려지며, 가려진 레코드는 어떤 범주가 보류되었는지 밝힙니다. 범주는 oloproof.yaml의 egress:에 나열될 때만 전송됩니다.

레코드 다이제스트는 가린 후에 다시 계산하지 않으므로, 호스팅된 레코드는 여전히 원래 증거를 가리키며 그 증거는 여러분의 컴퓨터에 남습니다. 가림은 암호화가 아니며, 아주 작은 슬라이스에 대한 지표는 여전히 그 뒤의 케이스를 식별할 수 있습니다.

검토자가 호스팅 검토 대기열에서 케이스에 레이블을 붙일 때, 검토자의 브라우저는 여러분 쪽에서 실행 중인 oloproof collect에서 케이스 내용을 가져옵니다. 내용은 워크스페이스를 거치지 않습니다. 워크스페이스가 쓰는 제공자 키는 oloproof credentials set으로 저장하며, oloproof credentials list는 이름만 보여 주고 값은 절대 보여 주지 않습니다. 관리형 작업은 Oloproof가 운영하는 워커에서 실행되며, 그 워커는 여러분의 Python 코드를 실행하지 않습니다. oloproof job은 결과를 보고하고 게이트에 따라 종료합니다.

호스팅 워크스페이스에서 엔진은 캐시된 실행, 판정, 분석을 절대 재사용하지 않습니다. 푸시가 그 캐시를 쓸 수 있기 때문입니다. 엔진은 그것을 다시 계산합니다.