성공 확정은 식별 정보 확인 뒤에

일괄 평가의 한 반환 항목이 case_id를 gold-pair-078에서 gold-pair-079로 바꾸었다. 작업 번호는 여전히 원래 과제를 가리켰다. 실패 기록에서 재구성한 식별 필드는 다음과 같다.

task_id:      gold-pair-078::gold-pair-078-candidate-127
candidate_id: gold-pair-078-candidate-127
case_id:      gold-pair-079

이 항목은 후보 20개를 담은 배치에 속했다. JSON을 파싱할 수 있었고 구조 검사도 통과했다. 뒤이은 항목별 검사에서 오류를 찾았지만 배치 수신 기록에는 이미 status: ok가 쓰여 있었다.원본 실패 기록과 코드 위치

완전한 공식 평가로 이어지지는 않았지만 복구 위험을 남겼다. 옛 파일의 “성공”과 나중의 실패 기록이 충돌했다. 성공 수신 기록만 읽는 복구 프로그램은 이 배치를 다시 받아들일 수 있었다.

수정점은 명확했다. 모든 항목의 식별 정보를 확인한 뒤 성공을 기록해야 한다. 요청이 어느 과제에 속하는지는 호출자가 이미 아는 사실이다. 프로그램이 대조해야 하며 모델 스스로 보장하도록 맡길 수 없다.

타입과 구조만 정한 Schema는 서로 다른 두 문자열을 모두 허용한다. 동적 Schema로 식별 값을 더 제한할 수도 있다. 이 시스템은 반환 뒤 실제 요청을 직접 대조해 배치 검수를 마친다.

현재 구현은 최상위 case_id, 작업 범위, 항목 구조, 식별 정보를 순서대로 검사한다. 작업 범위는 개수와 집합을 함께 비교해 누락, 중복, 추가 작업을 찾는다. 이어 task_id, case_id, candidate_id, 후보 유형을 대조한다.

아래는 핵심 순서를 교육용으로 줄인 코드다. 실제 구현에는 단계별 Schema, 수신 기록, 재시도 처리도 있다.

expected = {task["task_id"]: task for task in requests}
if len(expected) != len(requests):
    raise InvalidBatch("请求自身包含重复任务")

ids = [item["task_id"] for item in response["items"]]
if len(ids) != len(expected) or set(ids) != set(expected):
    raise InvalidBatch("任务缺失、重复或新增")

for item in response["items"]:
    task = expected[item["task_id"]]
    for key in ("task_id", "case_id", "candidate_id"):
        if item[key] != task[key]:
            raise InvalidBatch(f"身份字段不一致：{key}")

commit_success(response)

번호로 연결하므로 반환 순서는 바뀌어도 된다. 중복된 식별 필드까지 대조하면 같은 대상을 하위 모듈마다 다른 과제로 보는 일을 막는다. 한 모듈은 task_id로 078을 찾고 다른 모듈은 case_id로 079에 묶는 상황이다.

프로그램은 079를 바로 078로 고치지 않았다. 어긋남만으로 모델이 번호를 잘못 옮겼는지 다른 과제를 이해했는지 알 수 없다. 전체를 실패로 판정하고 원본 반환을 보존해 두 가능성을 조사할 여지를 남겼다.

전체 검수에는 비용이 있다. 나머지 정상처럼 보이는 19개도 재사용하지 못한다. 그 대신 단순한 확정 경계를 얻는다. 부분 수락을 지원하려면 각 항목의 독립 검증, 누락 보완, 중복 확정 처리를 따로 정의해야 한다. 그것은 별도의 복구 설계다.

새 호출을 고친 뒤에도 옛 수신 기록은 남는다. 그래서 가져오기 코드도 각 항목을 다시 검사한다. 이전 실패 로그에 대응하는 식별 오류가 발견되면 전체 배치를 진단 자료로 보존하고 어떤 항목도 재개 가능한 체크포인트에 넣지 않는다.

이미 발생한 호출 비용은 계속 집계한다. 재시작하면서 실행 디렉터리를 바꿀 수는 있어도 앞선 시도를 지울 수는 없다. 지우면 최종 “사용 가능한 결과당 비용”에는 마지막 성공 구간만 남는다.

배치 크기는 이 총비용으로 골라야 한다. 큰 배치는 공통 입력 비용을 분산하지만 전체 재시도는 한 항목의 오류 영향을 키운다. 프로젝트는 후속 설계에서 재시도를 소진한 지정 배치에만 결정적 분할을 허용했고 단일 항목 실패도 실행을 끝낼 수 있게 했다. 분할은 범위를 제한한 복구 수단이지 무한 재실행의 이유가 아니다.

회귀 시험은 첫 반환의 항목 식별 정보를 일부러 망가뜨리고 세 가지를 확인한다. 그 시도는 실패 수신 기록을 쓰고, 성공 체크포인트 경로는 비어 있으며, 그다음 올바른 반환에서야 성공을 쓴다. 이번 장애가 통과한 틈을 직접 검사한다.

배치 완료 수는 여기서부터 늘어야 한다. 반환이 요청과 맞고 전체 검수가 끝난 뒤 성공 확정이 일어나는 지점이다.