저희 AI 파이프라인은 세 가지 종류의 단계(ai.generate, ai.extract, ai.classify)로 구성되어 있으며, 각 단계는 실행 시점에 자체적인 제공업체(provider), 모델, 프롬프트 개정판을 독립적으로 해결합니다. 기본 모델은 Opus가 아니라 Sonnet입니다. 처음에는 이것이 타협처럼 느껴졌는데, 왜냐하면 Opus가 비싸지만 신뢰할 수 있는 옵션이었고, Sonnet은 같은 통과율에 도달하기 위해 세심한 관리가 필요했기 때문입니다.

격차를 해소한 해결책은 더 똑똑해진 프롬프트가 아니었습니다. 그것은 tool_choice와 강화된 출력 스키마(output schema)였으며, 모델이 토큰을 사용하여 추측하는 대신 답변 형태에 전념하도록 강제했습니다. 이것만으로도 저희 평가에서 Sonnet이 Opus의 이전 출력과 비슷한 통과율을 약 4분의 1 비용으로 달성하게 했습니다. 두 번째 독립적인 레버는 Anthropic 자체적으로 에이전트 작업(agentic tasks)에 권장하는 `effort:

이 세 가지 방법 중 그 어느 것도 프롬프트(prompt) 내용이나 제공자(provider)를 건드리지 않았습니다. 세 가지 모두 단계별 토큰 사용량(per-step token usage)을 분석한 결과였으며, 이는 모든 단계가 완료 시점에 프롬프트 수정(prompt revision), 제공자(provider), 모델(model), 토큰 사용량(token usage)과 같은 불변의 출처 기록(immutable provenance record)을 작성하기 때문에 가능했습니다. 이는 도메인 쓰기(domain writes) 대신 LLM 호출에 적용된 이벤트 소싱(event sourcing)과 같은 개념입니다. "아마도 파이프라인이 어떤 모델로 설정되었든 프롬프트 v3를 사용했을 것이다"라고 추측하는 대신, 이를 명시하는 행(row)을 갖게 되는 것입니다. 이를 통해 실제 LLM 페이로드(payload)를 로드하지 않고도