분류·추출·요약 작업에서 Claude Haiku 5.5와 4.5 비교

Claude Haiku 5.5는 반복적인 애플리케이션 작업에 평가해 볼 만하지만, Haiku 4.5를 대체하기 전에 업그레이드한 모델이 출력 계약을 만족하는지 확인해야 합니다. Ofox에서 진행한 소규모 테스트에서는 두 버전 모두 예상한 분류 및 추출 값을 반환했습니다. 요약 결과의 구조는 달랐고, JSON을 요청했는데도 두 버전 모두 응답을 Markdown 펜스로 감쌌습니다. 답변이 얼핏 맞아 보인다고 해서 엄격한 JSON 파서의 입력으로 유효한 것은 아닙니다.

이 글에서는 실제 API에 보낸 합성 입력 기반의 세 가지 작업을 비교하고, 기록된 결과를 보여 주며, 배치 처리나 애플리케이션 백엔드를 관리하는 개발자를 위한 마이그레이션 절차를 안내합니다. 이 테스트로 전반적인 정확도, 지연 시간 또는 비용의 우열을 입증하지는 않습니다. 구조화된 출력 스키마 없이 모델별로 작업당 요청을 한 번씩, 총 여섯 번 보냈습니다.

Anthropic은 10월 7일 Haiku 5.5를 발표하면서 분류와 요약을 포함한 대량 처리 작업에 적합하다고 소개했습니다. 이러한 제품 관련 주장은 아래의 제한적인 관찰 결과와는 별개입니다.

10월 12일에 캡처한 실제 Ofox 인터페이스입니다. 모델 식별자와 Anthropic SDK 예시를 보여 줍니다. 아래 비교에서는 별도로 지정한 Chat Completions 경로를 사용했습니다. 이 스크린샷은 설정 참고 자료이며, 평가가 성공했다는 근거는 아닙니다.

테스트 계약

https://api.ofox.io/v1/chat/completions와 max_tokens: 1800을 사용했으며, Ofox ID는 다음과 같습니다.

anthropic/claude-haiku-4.5
anthropic/claude-haiku-5.5

temperature나 추론 제어 설정은 명시적으로 지정하지 않았습니다. 제공업체의 기본값, 라우팅, 토큰 집계 방식은 다를 수 있습니다. 따라서 사용자 텍스트가 같아도 실제 연산 예산까지 같다고 보장할 수는 없습니다. 입력에는 고객 데이터, 실제 주문 또는 개인 정보가 포함되지 않았습니다.

다운로드 가능한 테스트 키트에는 프롬프트, 비식별 처리한 응답 증거, 스크립트가 들어 있습니다. API 스크립트를 실행하면 실제 요청이 전송되어 사용량 요금이 발생할 수 있습니다. 먼저 내용을 확인하고 직접 제한된 테스트 예산을 설정하세요. 원본 관찰 결과의 날짜는 해당 테스트 배치를 기준으로 하며, 페이지를 읽을 때마다 새로 생성되는 값이 아닙니다.

요약 프롬프트는 지정된 필드를 요청했지만 정식 스키마를 제공하지는 않았습니다. 따라서 이 테스트는 통합 위험을 발견하는 데 유용하지만, 모델이 강제된 스키마를 따르지 못한다는 주장의 근거는 아닙니다.

결과: 값과 응답 구조는 별도로 확인해야 합니다

분류와 추출의 경우, 응답을 감싼 코드 펜스 하나를 제거하면 값이 예상과 일치했습니다. 소비자 코드에서 json.loads(response_text)를 직접 호출한다면 같은 응답도 파싱 오류가 됩니다. 소비자가 단일 펜스를 허용하는지 정하고 문서화하세요. 예상한 답변처럼 보일 때까지 임의의 잘못된 출력을 조용히 ‘수정’해서는 안 됩니다.

Haiku 5.5의 요약은 평탄한 객체였습니다.

{
  "owner": "Maya",
  "deadline": "2026-10-14",
  "decision": "English-only pilot approved",
  "unresolved": "Price undecided"
}

반면 Haiku 4.5는 이메일 초안, 파일럿 승인, 미정인 가격을 각각 별도의 작업 항목으로 묶었습니다. 이 표현에는 유용한 정보가 담겼지만, 최상위 owner와 deadline을 기대하는 소비자는 해당 필드를 찾지 못합니다. 표본이 하나뿐이고 스키마도 구체적이지 않았으므로, 책임 있는 결론은 통합 계약을 테스트하고 강제해야 한다는 것입니다. 어느 한 버전이 항상 더 잘 요약한다고 결론지을 수는 없습니다.

평탄한 객체에서는 이메일 작성 작업이 명시적으로 드러나지 않기도 합니다. 업무상 작업과 결정을 모두 필요로 한다면 별도의 필드를 요구하세요. ‘스키마와 일치한다’와 ‘운영에 필요한 사실을 모두 담고 있다’는 서로 다른 합격 기준입니다.

관찰된 지연 시간과 토큰

아래는 클라이언트에서 관찰한 요청 소요 시간과 API가 보고한 토큰 수입니다. 선택한 게이트웨이 경로가 포함되며, 모델 추론만 측정한 값은 아닙니다.

이번 실행에서는 5.5에 보낸 요약 요청의 소요 시간이 더 길었습니다. 이 단일 관찰만으로 제공업체의 더 광범위한 포지셔닝을 반박할 수도, 프로덕션 지연 시간을 예측할 수도 없습니다. 서비스 수준 기대치를 바꾸기 전에 대표 사례를 반복해 테스트하고, 실패 사례도 포함하며, 지연 시간 분포를 수집하세요.

화면에 보이는 답변의 단어 수를 청구되는 출력 토큰으로 계산하지 마세요. 반환된 사용량 필드를 기록하고 제공업체의 요청 기록과 대조하세요. 표에는 API가 반환한 값이 표시되어 있습니다. 내부 집계 방식의 모든 차이를 설명하거나 확정된 달러 청구액을 주장하는 것은 아닙니다.

예산을 세울 때는 입력 및 출력 요금만 보지 말고 승인된 결과당 비용을 비교하세요. 다음과 같은 실용적인 계산표를 사용할 수 있습니다.

cost per accepted result =
  reconciled spend across initial attempts, retries and fallbacks
  / number of results that pass your acceptance rules

분자에서 거부된 출력이나 대체 경로 호출을 빼지 마세요. 승인된 결과가 없다면 비율은 정의되지 않습니다. 0이 아닙니다. 지출을 계산하기 전에 정확한 제공업체의 최신 요금과 적용되는 캐시 또는 컨텍스트 구간을 확인하세요. 이 글에서는 Ofox를 사용하면 일정 금액을 절감할 수 있다는 고정된 주장을 의도적으로 하지 않습니다.

더 엄격한 추출 계약 사용하기

누락 값과 타입 규칙을 명시하는 프롬프트부터 시작하세요. 다음은 개선된 템플릿이며, 위 측정에 사용한 프롬프트가 아닙니다.

Extract only facts explicitly present in the input.
Return a single JSON object, without Markdown or commentary.
Keys must be exactly:
order_id: string
quantity: integer
delivery_date: ISO YYYY-MM-DD string, or null if not stated
currency: three-letter currency code, or null if not stated
Do not infer a delivery date from today's date.
Do not convert an unknown value to an empty string.
Input:
Order BX-71 contains 12 notebooks. Delivery is not scheduled.
Total: 48 EUR.

결과 객체는 코드에서 검증하세요. 사용 중인 경로가 스키마 제약 출력 기능을 지원한다면, 이를 도입하기 전에 정확히 사용할 모델과 엔드포인트에서 해당 기능을 검증하세요. 프롬프트만 사용한 이번 테스트로는 이 기능을 검증하지 않았습니다.

import json

def validate_order(text):
    value = json.loads(text)  # Strict: intentionally rejects code fences.
    expected = {"order_id", "quantity", "delivery_date", "currency"}
    if not isinstance(value, dict) or set(value) != expected:
        raise ValueError("Unexpected object shape")
    if not isinstance(value["order_id"], str):
        raise ValueError("order_id must be a string")
    if type(value["quantity"]) is not int:
        raise ValueError("quantity must be an integer")
    # Fixture-specific assertions; replace with production business rules.
    if value != {"order_id": "BX-71", "quantity": 12,
                 "delivery_date": None, "currency": "EUR"}:
        raise ValueError("Fixture facts do not match")
    return value

합성 테스트 입력에 대해서는 이 정확한 값 검증이 적절합니다. 프로덕션 검증기에는 허용되는 통화 값, 유효한 날짜, 레코드 식별자에 대한 도메인 규칙도 필요합니다. 모든 고객 레코드를 BX-71과 비교할 수는 없습니다.

실패한 레코드를 잃지 않고 마이그레이션하기

모델 ID를 명시적인 설정값으로 관리하고, 대체 모델이 대표성 있는 평가를 통과할 때까지 기존 모델을 유지하세요. 각 입력에 대해 안정적인 레코드 ID, 프롬프트 버전, 모델 ID, 시도 횟수, 반환된 사용량, 검증 상태, 출력을 기록하세요. 오류가 난 레코드는 배치에서 버리지 말고 레코드로 저장하세요.

일반적인 사례와 경계 사례를 포함하는 소규모의 라벨링된 데이터 세트부터 시작하세요. 날짜 누락, 정보 간 모순, 알 수 없는 카테고리, 빈 입력, 유난히 긴 텍스트, 입력에 삽입된 지시문 등을 포함하면 됩니다. 입력 문서는 데이터로 취급하세요. 문서가 추출 지시를 대체하거나 임의의 도구를 선택할 수 있어서는 안 됩니다.

의미상 승인 여부는 JSON 구문과 구조의 적합성 여부와 분리해 비교하세요. 출시 범위를 넓히기 전에 결과가 다른 사례를 검토하세요. 제한된 범위로 출시하는 동안에는 기존 경로를 통제된 대체 경로로 유지하고, 재시도 횟수를 제한하며, 중복 처리를 추적하세요. 요청 시간이 초과되더라도 제공업체에 요청이 도달했을 수 있습니다. 사용량이 발생하지 않았다고 단정하지 마세요.

분류에서는 허용된 라벨에 맞는 항목이 없을 때 어떻게 처리할지 정하세요. 요약에서는 어떤 사실을 생략할 수 있는지 정의하세요. 추출에서는 모호한 필드를 null로 처리할지, 사람의 검토로 넘길지 정하세요. 이러한 결정은 보통 모델 문자열만 바꾸는 것보다 애플리케이션의 정확성에 더 큰 영향을 줍니다.

Claude Code도 사용한다면 curl과 클라이언트의 연결 문제를 진단하는 가이드를 참고해 연결을 별도로 검증하세요. 텍스트 API가 성공했다는 사실만으로 코딩 클라이언트의 도구나 설정을 검증할 수는 없습니다.