에이전트의 모든 단계를 가장 강한 모델에 맡기기에는 비쌉니다. 과제별 모델 라우팅과 fallback은 어떻게 설계하나요?

단계의 난이도·오류 비용·필요한 기능·지연·데이터 정책을 기준으로 모델을 선택하겠습니다. 간단한 형식 변환과 복잡한 코드 수정, 민감한 행동 결정은 같은 기준으로 라우팅할 필요가 없습니다. 다만 모델 크기나 공개 순위만으로 적합성을 확정하지 않고 실제 과제에서 성공률·안전성·총비용을 비교해야 합니다.

라우팅 기준과 검증기

입력 길이·작업 종류·필요 도구·코드 언어 같은 관찰 가능한 특징으로 초기 경로를 정할 수 있습니다. 작은 모델이 정해진 스키마를 만들고 코드 검증기가 확인하는 단계는 저렴하게 처리할 수 있지만, 검증할 수 없는 복잡한 의미 판단은 별도 평가가 필요합니다. 모델이 말하는 confidence만으로 상향 전환을 결정하지 않고 검증 실패·근거 부족·도구 인자 오류·예산 소진 같은 신호를 사용합니다.

강한 모델로 fallback할 때는 실패한 시도의 실제 관찰과 미완료 조건을 전달하되 잘못된 잠정 결론을 사실로 고정하지 않습니다. 원래 사용자 권한·데이터 공개 범위·논리 요청 ID를 유지해야 합니다. 다른 제공자에게 문맥을 보내는 것은 데이터 전송 목적지가 바뀌는 것이므로 단순한 품질 fallback으로 자동 허용하지 않습니다.

교체가 실행 계약을 바꾸지 않게 합니다

모델별로 도구 호출 형식·구조화 출력·이미지 입력·문맥 한도·거절 동작이 다를 수 있습니다. 어댑터가 차이를 숨기더라도 실제 실패·잘림·호출 순서를 시험합니다. 변경 도구가 이미 실행된 뒤 다른 모델로 재시도하면 새 계획이 같은 행동을 반복할 수 있어 내구 상태와 멱등 키가 필요합니다. fallback은 새로운 사용자 요청이 아니라 같은 작업의 다른 추론 경로일 수 있습니다.

평가에서는 전체 평균뿐 아니라 과제 유형별 오분류, 불필요한 상향 호출, 잘못된 하향 선택, fallback 후 성공과 누적 지연을 봅니다. 제공자 장애·rate limit·정책 거절을 같은 재시도 오류로 취급하지 않습니다. 안전 정책 때문에 거절한 행동을 다른 모델이 수행하게 만드는 우회는 허용하지 않습니다. 모델 업데이트 후 라우터와 검증 기준을 다시 평가하고 작은 트래픽에서 점진 적용합니다. 최적 라우팅은 가장 약한 모델을 최대한 쓰는 것이 아니라 허용된 조건에서 전체 작업의 비용·신뢰도를 맞추는 선택입니다.

실행 사례로 확인합니다

라우터 자체가 모델 호출이면 그 비용과 오분류도 포함합니다. 단순한 과제 구분은 코드 규칙으로 시작하고 복잡한 분류가 실제 이득을 주는지 비교할 수 있습니다. 새 모델을 추가할 때는 필요한 도구·구조화 출력·이미지 지원이 실제로 활성화되어 있는지 확인합니다. 동일한 모델 이름 아래 버전이나 제공 방식이 바뀔 수 있으므로 평가한 식별자와 설정을 기록합니다. 운영 중 rate limit 때문에 fallback할 때도 이미 사용한 예산을 초기화하지 않고 남은 전체 budget 안에서 진행합니다. 정책 거절·자료 부족·인프라 실패를 구분하면 강한 모델로 보내도 해결되지 않는 상황에서 낭비를 줄일 수 있습니다.