한동안 중요한 Codex 작업에 대한 저의 기본 대응 방식은 간단했습니다. 가장 강력한 모델을 선택하고, 추론 노력 (reasoning effort)을 높여서 모든 것을 처리하게 만드는 것이었습니다.

이것은 보수적으로 들릴 수 있습니다. 하지만 종종 비효율적입니다.

가장 강력한 모델은 이미 승인된 결정을 재검토할 수도 있습니다. 기계적인 편집 (Mechanical edits)은 과도하게 큰 컨텍스트 패킷 (context packet)을 상속받습니다. 아주 작은 결정론적 (deterministic) 변화가 작업 자체보다 더 많은 비용이 드는 오케스트레이션 (orchestration) 단계 뒤에서 대기하게 됩니다. 최종 차이 (diff)가 단순하더라도, 그 경로는 토큰 측면에서는 비싸지고 경과 시간 측면에서는 느려집니다.

그에 대한 당연한 반응인 '모든 것을 가장 저렴한 모델로 보내는 것'은 정반대의 이유로 실패합니다. 모호한 작업은 재시도 (retries)를 요구할 가능성이 더 높습니다. 검토 비용이 비싸집니다. 결국 강력한 상위 모델이 컨텍스트를 재구성하고 결정을 다시 내려야 합니다.

진정한 최적화 목표는 가장 저렴한 호출이 아닙니다. 그것은 가장 저렴한 '완료되어 수락된 경로 (complete accepted route)'입니다.

중요했던 경계선

처음에 저는 작업을 "쉬운 것"과 "어려운 것"으로 나누었습니다. 그것은 유용하기에는 너무 주관적이었습니다. 더 나은 질문은 결정과 정확성 메커니즘 (correctness mechanism)이 고정되어 있는지 여부입니다.

모두 "몇몇 파일을 생성한다"라고 설명할 수 있는 네 가지 작업을 고려해 보십시오:

1. 승인된 9개의 상태 매핑 (state mappings)을 구현하고 모든 값을 검증합니다.
2. 14개의 문서에 흩어져 있는 상충하는 제품 규칙을 조정합니다.
3. 예상 동작이 승인되었지만 패치 메커니즘이 열려 있는 상태에서 비동기 레이스 (asynchronous race)를 수정합니다.
4. 승인된 권한 규칙을 정확한 세트 검사기 (exact-set checker)가 있는 진리표 (truth table)로 컴파일합니다.

출력 형식은 어떤 모델이 충분한지를 알려주지 않습니다. 불확실성이 알려줍니다.

첫 번째와 네 번째 작업은 닫힌 집합 (closed sets), 고정된 규칙, 그리고 결정론적 검증을 가집니다. 이들은 저렴한 실행을 위한 좋은 후보입니다. 두 번째 작업은 교차 소스 조정 (cross-source reconciliation)을 필요로 합니다. 세 번째 작업은 여전히 디버깅 결정 (debugging decision)을 포함하고 있습니다. 네 가지 작업을 모두 동일한 등급에 맡기는 것은 크레딧(credits)이나 재시도(retries) 중 하나를 낭비하게 됩니다.

품질 우선 라우팅 정책

결국 저는 네 가지 광범위한 경로를 도출했습니다:

• Direct parent or tools: 하나 또는 두 개의 알려진 결정론적(deterministic) 작업용.
• Luna: 고정된 규칙(frozen rules), 제한된 컨텍스트(bounded context), 기계적 실행(mechanical execution) 및 철저한 검증(exhaustive checks)용.
• Terra: 교차 소스 합성(cross-source synthesis), 일반적인 통합(ordinary integration), 더 넓은 컨텍스트 및 개방형 디버깅(open debugging)용.
• Sol 또는 현재의 부모(parent): 모호한 계획(ambiguous planning) 및 권한, 개인정보 보호, 자금, 컴플라이언스(compliance), 과학 또는 운영(production)과 관련된 중대한 결정용.

이것은 의도적으로 모델 리더보드(leaderboard)를 지향하는 것이 아닙니다. 저비용 모델은 전체 작업의 적절한 소유자가 아닐지라도, 특정 단계에서는 올바른 선택이 될 수 있습니다.

라우터(router)는 사용자가 선택한 부모 모델과 노력을 보존합니다. 라우터는 작업을 유형화된 단계—증거 수집, 결정, 고정된 계약(frozen contract) 실행, 또는 메커니즘이 열려 있는 동안의 실행—로 분리하고, 해결되지 않은 단계만을 할당합니다.

위임(Delegation)에도 비용이 따릅니다

저렴한 작업자(worker)가 공짜인 것은 아닙니다. 유용한 추정치에는 다음이 포함됩니다:

작업 패킷(task packet)
+ 작업자 실행(worker execution)
+ 검증(verification)
...

이것이 한 줄의 CSS 변경 사항이 보통 직접(direct) 처리되어야 하는 이유입니다. 또한, 대규모의 고정된 매핑(frozen mapping)이 여러 파일에 걸쳐 있더라도 위임할 가치가 있는 이유이기도 합니다. 작업 패킷의 비용이 분할 amortized 되고, 검사기(checker)가 전체 세트를 검증할 수 있기 때문입니다.

첫 번째 회귀 테스트(regression)가 말해주는 것과 말해주지 않는 것

저는 이 정책을 Adaptive Model Router라는 이름의 오픈 소스 Codex 스킬로 패키징하고, 14가지 사례로 구성된 라우팅 회귀 테스트(routing regression)를 만들었습니다. 여기에는 미세한 편집, 유한한 매핑(finite mappings), 교차 소스 증거, 비동기 경합(async races), 긴 컨텍스트 합성(long-context synthesis) 및 중대한 결정 사례가 포함됩니다.

스킬 가이드 방식의 두 차례 실행은 라우팅 오라클(routing oracle)을 상대로 14/14점을 기록했습니다. 가이드가 없는 두 차례의 비교 실행은 5/14 및 6/14점을 기록했습니다.

이 수치에는 강력한 주의 사항이 필요합니다: 이것은 개발용 회귀 테스트(development regression)입니다. 사례들이 라우터에 정보를 제공했습니다. 이것은 독립적인 홀드아웃(holdout)이 아니며, 엔드 투 엔드(end-to-end) 품질, 크레딧, 토큰 또는 지연 시간(latency)의 보편적인 개선을 증명하는 것도 아닙니다. 다만, 작성된 정책이 테스트에 나타난 경계 조건에서 경로 선택을 더 일관되게 만들었음을 보여줍니다.

이 저장소(repository)에는 프롬프트(prompts), 스키마(schema), 오라클(oracle), 스코어러(scorer), 그리고 가공되지 않은 결과물(raw outcomes)이 포함되어 있어, 해당 주장이 마케팅 수단으로 반복되는 대신 직접 검증될 수 있습니다.

시도해보기

이 프로젝트는 MIT 라이선스를 따르며 Codex 플러그인 마켓플레이스(marketplace)를 통해 배포됩니다:

codex plugin marketplace add cyc981565058-cpu/adaptive-model-router
codex plugin add adaptive-model-router@adaptive-model-router

소스 및 벤치마크(benchmark):

https://github.com/cyc981565058-cpu/adaptive-model-router

다음으로 유용한 단계는 동일한 사례에 맞춰 조정된 또 다른 정교한 벤치마크가 아닙니다. 그것은 독립적인 작업 증거(independent task evidence)입니다: 즉, 수락 품질(acceptance quality), 재시도(retries), 원시 토큰(raw tokens), 크레딧 또는 API 비용, 그리고 다양한 부모 모델(parent models) 및 추론 노력(reasoning efforts)에 따른 경과 시간(elapsed time)입니다.

만약 검증(verification) 횟수를 산정했을 때, 라우터(router)가 지속적으로 너무 약하거나, 너무 강력하거나, 혹은 더 느린 모델을 선택하는 작업이 있다면, 그러한 반례(counterexample)가 일반적인 성공 사례보다 더 가치 있습니다.

공개 사항: 저는 링크된 프로젝트를 유지 관리합니다. 이 글은 AI의 도움을 받아 초안을 작성한 후, 공개 저장소, 가공되지 않은 벤치마크 출력물 및 플랫폼 가이드라인을 바탕으로 검토되었습니다.