AI 워크플로우 비교 시 성공적인 API 호출이 아닌 수락된 작업 수를 계산해야 합니다

HTTP 200 응답, 유효한 JSON, 그리고 유용한 애플리케이션 결과는 세 가지 다른 이벤트입니다. 워크플로우가 두 번 재시도(retries)를 거친 후 하나의 수용 가능한 답변을 생성했다면, 이는 세 번의 성공이 아니라 하나의 '수락된 작업(accepted job)'을 의미합니다.

고지 사항: 저는 다중 모델 API 플랫폼인 Tokatlas에서 근무하고 있습니다. 이 게시물은 제가 지시한 AI 에이전트에 의해 생성되었습니다. 예시는 합성(synthetic)이며, 모델 품질, 가격 또는 생산성 절감에 대한 어떠한 주장도 하지 않습니다.

시도당 한 행 유지하기

재시도 시 안정적인 job_id를 사용하고 각 호출마다 고유한 attempt_id를 사용하세요. 제공업체를 비교하기 전에 설정된 규칙을 사용하여 수락 여부를 기록해야 합니다. 예를 들어, 모든 필수 인보이스 필드는 레이블이 지정된 소스와 일치해야 합니다. HTTP 상태, 파싱 상태(parse status), 그리고 수락 여부(acceptance)는 분리하여 유지하세요.

타임아웃, 오류 응답, 누락된 사용량 필드 또는 취소된 클라이언트 연결로부터 비용을 추론하지 마십시오. 비용은 제공업체의 청구 기록과 같이 의미를 이해하는 출처에서 나와야 합니다. 만약 사용할 수 없다면, 알 수 없는(unknown) 상태로 유지하세요.

이 Python 예시는 알 수 없는 비용을 숨기지 않고 시도 로그를 요약합니다:

from decimal import Decimal

def summarize(attempts):
...

위의 숫자는 Tokatlas의 가격이 아닌, 가상의 고정 값(fixture values)입니다. 그 목적은 회계 경계(accounting boundary)를 보여주는 것입니다: 두 개의 작업, 세 번의 시도, 하나의 수락된 작업, 그리고 하나의 알 수 없는 비용입니다. 총합이 불완전하기 때문에, 수락된 작업당 비용은 여전히 null로 남아 있습니다.

지표 사용 전 확인해야 할 세 가지 유용한 점

1. 단일 코호트(cohort): 동일한 입력 사례, 수락 규칙(acceptance rule), 재시도 제한을 비교합니다. 실패한 시도와 수락된 결과를 생성하지 못한 작업도 포함해야 합니다.
2. 단일 통화 및 범위(scope): 여러 통화를 혼합하거나 호출당 요금과 월별 청구 총액을 혼용하지 마십시오. 이 스니펫은 입력 로그가 이미 해당 규칙을 따르고 있다고 가정합니다.
3. 단일 완료 경계(completion boundary): 아직 실행 중인 코호트는 제외하거나 명시적으로 미완료로 표시해야 합니다. 타임아웃은 나중에 청구 기록을 생성할 수 있으므로, 두 번째 시도를 추가하기보다는 동일한 시도와 상계 처리(reconcile)해야 합니다.

이것은 전체 운영 비용(operational cost)이 아닌 API 비용 지표입니다. 사람의 검토 시간, 대기열 처리(queueing), 호스팅, 작업 지연 시간(task latency) 등은 별도의 필드가 필요합니다. 더 저렴한 호출을 생성하는 모델이라도 여전히 더 많은 검토를 요구할 수 있으며, 더 비싼 호출이라도 귀하의 수락 규칙에 실패할 수 있습니다.

만약 구체적인 워크플로우를 위해 API를 선택하는 경우, 소규모의 마스킹되거나(redacted) 합성된(synthetic) 사례 세트와 서면화된 수락 규칙으로 시작해야 합니다. API 제공업체에게 물어봐야 할 질문은 단순히 "토큰 가격이 얼마입니까?"가 아니라 "각 시도를 상계 처리하기 위해 어떤 응답 및 사용 정보가 필요합니까?"여야 합니다.

현재 어느 실패를 잘못 계산하고 있습니까? 타임아웃(timeout), 구문 분석은 가능하지만 틀린 답변, 아니면 결국 성공하는 재시도(retry)입니까?