fix: 평가 완료성과 전수 실행 검증

[hellices]

배경

PR #2 병합 후 추가 리뷰에서 Evaluate gate가 live 결과의 점수 비율만 확인하고 다음 두 조건을 검증하지 않는 문제가 확인됐습니다.

• top-level evaluation status가 completed인지 여부
• evaluator별 처리 건수가 configured JSONL 전체 행 수와 일치하는지 여부

또한 clean CI runner에서 AZURE_SEARCH_LOCATION repository variable이 azd 환경으로 전달되지 않는 설정 누락을 보완합니다.

변경 내용

• live per_testing_criteria_results 사용 시 status=completed 필수
• JSONL의 비어 있지 않은 행 수 계산
• 필수 evaluator별 passed + failed + errored + skipped 합계와 dataset 행 수 비교
• 처리 건수 부족·초과 시 fail-closed
• evaluator error 기존 차단 유지
• aggregate/per-sample legacy 결과 형식 호환 유지
• CI job env에 ${{ vars.AZURE_SEARCH_LOCATION || 'centralus' }} 추가
• provision 전 azd env set AZURE_SEARCH_LOCATION 적용

검증

• pytest 169개 통과
• Ruff lint·format 통과
• Bicep template·parameter build 통과
• POSIX·PowerShell 훅 구문 검사 통과
• 별도 코드 리뷰 중요 이슈 없음

라이프사이클 영향

완료되지 않은 평가나 dataset 일부만 처리한 평가 결과로 Operate가 시작되는 경로를 차단합니다. Build → Evaluate → Operate 순서는 유지됩니다.

[hellices]

⚠️ 이 코멘트의 actionable finding 없음 결론은 추가 실행 검증 후 철회했습니다. 최종 검토는 #3 (comment) 로 대체되었습니다.

[hellices]

ℹ️ 이 중간 검토 코멘트는 추가 재현 결과를 반영한 최종 통합 코멘트로 대체되었습니다: #3 (comment)

[hellices]

최종 통합 검토 — 앞선 두 코멘트를 이 내용으로 대체합니다

앞선 첫 코멘트의 actionable finding 없음 결론은 잘못되어 철회합니다. 두 번째 코멘트의 skipped 관찰과 추가 실행 검증 결과를 아래와 같이 통합합니다.

Warning — skipped를 completeness에는 포함하고 score에서는 제외합니다

src/lifecycle_ops/evaluation/gate.py:178-186은 evaluator 처리 건수를 다음 네 counter의 합으로 검증합니다.

passed + failed + errored + skipped

반면 점수 계산(src/lifecycle_ops/evaluation/gate.py:137-145)의 분모는 passed + failed + errored이며 skipped를 제외합니다.

고정 head baa18cf4ac8a94a5bfcc5e6496723bf9fe0cc4ad와 8행 dataset에서 passed=1, skipped=7, 나머지 0을 직접 실행한 결과, completeness 검사를 통과하고 score=1.0, gate_passed=true, errors=[]가 반환됐습니다. 즉 evaluator 판정을 받은 sample이 1/8뿐이어도 현재 gate는 성공할 수 있습니다.

Foundry가 실제 이 경로에서 skipped > 0을 반환하는지는 확인하지 못했으므로 조건부 지적입니다. 그러나 전수 evaluator 판정이 gate의 전제라면 skipped > 0을 실패 처리해야 합니다. skip을 허용하려는 제품 정책이라면 score 분모와 허용 조건·비율을 명시하고, 1 passed + 7 skipped 회귀 테스트로 의미를 고정해 주세요.

Suggestion — evaluator counter를 정수·비음수로 검증하지 않고 합계를 절삭합니다

src/lifecycle_ops/evaluation/gate.py:178-182는 counter를 _to_float()로 읽은 뒤 다음과 같이 합계를 절삭합니다.

evaluated = int(passed + failed + errored + skipped)

8행 dataset에서 다음 malformed payload들이 실제로 gate를 통과했습니다.

• passed=9, skipped=-1, 나머지 0 → score=1.0, gate_passed=true: 음수 skipped가 초과 count를 상쇄하며 score 분모에는 포함되지 않습니다.
• passed=8.7, 나머지 0 → int(8.7) == 8로 completeness 통과, score=1.0, gate_passed=true
• passed=7.9, failed=0.2, 나머지 0 → 합계 8.1이 절삭되어 통과, score 약 0.9753

대조군으로 passed=9, failed=-1은 score 1.125가 되어 후단 범위 검증에서 실패했습니다. 즉 completeness 검증 자체가 잘못된 counter를 차단하는 것이 아니라, failed는 우연히 score 경로에서 걸리고 score 분모에 없는 skipped 음수는 그대로 통과합니다.

실제 Foundry가 소수·음수 counter를 반환한다는 증거는 없으므로 서비스 출력의 확정 버그가 아니라 외부 결과에 대한 fail-closed hardening 문제입니다. 각 counter를 finite, non-negative integer로 검증하고 int(...) 절삭 없이 검증된 정수끼리 합산해 주세요. 위 성공 재현 사례와 음수 counter에 대한 회귀 테스트도 권장합니다.

Suggestion — top-level 상태 검증이 결과 형식에 종속됩니다

src/lifecycle_ops/evaluation/gate.py:158-162는 per_testing_criteria_results가 list가 아니면 top-level status를 읽기 전에 반환합니다. 고정 head에서 status="failed"이면서 metrics.relevance.score=1.0인 aggregate payload가 gate_passed=true가 되는 것을 재현했습니다.

legacy 형식 호환 의도는 이해하지만, status 키가 존재하는 경우에는 결과 형식과 독립적으로 완료 상태를 검증하면 live 결과가 legacy 경로로 조용히 downgrade되는 가능성을 줄일 수 있습니다. 반대로 per_testing_criteria_results가 있고 status만 누락된 live payload는 exit 2로 정상 차단됨을 확인했습니다.

PR은 병합되지 않은 채 닫혀 있으며, 이 변경은 현재 main에 포함되어 있지 않습니다. reopen 또는 후속 PR 작성 시 위 사항을 함께 반영하는 것을 권합니다.

Verdict: COMMENT — Warning과 Suggestion을 남기지만 PR이 closed/unmerged이고, blocking Critical로 판정하지 않아 REQUEST_CHANGES는 사용하지 않습니다.