문제점

비용 효율적인 AI 시스템은 쉬운 작업은 저렴한 모델(cheap model)로 보내고, 어려운 작업만 비싼 프런티어 모델(frontier model)로 에스컬레이션(escalate)합니다. 문제는 무엇이 무엇인지 아는 것입니다. 유닛 테스트(unit tests)가 있는 코드와 같이 작업에 테스트가 있는 경우, 단순히 테스트를 실행하면 됩니다. 저렴한 답변이 통과하면 그대로 서빙하고, 그렇지 않으면 에스컬레이션합니다. 하지만 대부분의 실제 프롬프트(prompt)에는 테스트가 없습니다. "유지보수 시간대가 언제인가요?"와 같은 질문은 코드를 실행하여 확인할 수 없습니다. 테스트가 없으면 신중한 시스템은 거의 모든 것을 에스컬레이션하며, 저렴한 모델이 처리할 수 있었던 작업에 대해 프런티어 가격을 지불하게 됩니다.

우리는 자체 게이트웨이(gateway)를 측정하여 정확히 그 사실을 발견했습니다. 자동 모드에서 테스트가 없는 프롬프트의 경우, 시스템은 모든 컨텍스트 길이(context length)에서 100%의 확률로 프런티어로 에스컬레이션했습니다. 저렴한 티어(cheap tier)는 능력이 있었지만, 시스템은 테스트 없이는 이를 신뢰하지 않았고, 따라서 해당 답변들을 서빙하지 않았습니다.

아이디어: 테스트를 대신하는 동의(agreement)

테스트 대신, 두 번째의 독립적인 저렴한 모델에게 동일한 질문을 던집니다. 만약 두 저렴한 모델이 동의한다면, 그 답변은 매우 정확할 가능성이 높으므로 저렴하게 서빙합니다. 만약 두 모델이 동의하지 않는다면, 그것은 진정으로 어려운 사례이므로 프런티어로 에스컬레이션합니다. 불일치(disagreement)는 이전보다 더 나쁜 답변을 서빙하는 일이 결코 없는데, 왜냐하면 불일치 경로는 어차피 발생했을 기존의 에스컬레이션 경로와 동일하기 때문입니다. 동의(agreement)는 불필요한 프런티어 호출을 건너뛸 기회만을 추가합니다. 이 게이트(gate)는 구조적으로 보수적(conservative)이므로, 유일한 실패 모드는 피할 수 있었던 에스컬레이션에 비용을 지불하는 것이며, 두 저렴한 모델이 우연히 동일한 틀린 답변에 동의하지 않는 한 잘못된 답변을 서빙하는 일은 결코 없습니다. 그 단 하나의 리스크가 핵심이기에, 우리는 이를 직접 측정했습니다.

시스템을 망가뜨릴 수 있는 단 하나의 숫자

이 게이트가 잘못된 답변을 서빙하는 유일한 방법은 두 저렴한 모델이 동일한 틀린 답변에 동의하는 경우뿐입니다. 우리는 이를 P(wrong given agree)라고 부릅니다. 만약 이 값이 0이라면, 동의는 테스트를 대신할 안전한 수단이 됩니다. 그래서 우리는 이를 스트레스 테스트(stress test)했습니다.

우리는 아키텍처가 서로 다른 두 개의 저렴한 모델을 네 가지 작업군(task families)에 대해 실행했습니다. 여기에는 모델이 학습 데이터로부터 암기할 수 없도록 우리가 직접 작성한 완전히 새로운 고난도 함정(hard traps) 세트(역비율 함정(reverse-percentage trap), 상승 후 하락 가격 함정(rise-then-fall price trap), 2+1 구매 함정(buy-two-get-one trap), 시계 종소리 간격 함정(clock-chime interval trap), 우물 안 달팽이 함정(snail-in-a-well trap) 등)이 포함되었습니다. n=160일 때의 결과는 다음과 같습니다: P(wrong given agree, 동의했을 때 틀릴 확률)는 네 가지 작업군(검색(retrieval), 추론(reasoning), 다중 사실(multi-fact), 그리고 새로운 적대적 함정(adversarial traps)) 모두에서 0.00이었으며, 총 160건 중 '동의했으나 틀린' 사례는 단 한 건도 없었습니다.

두 저렴한 모델이 동의했을 때, 모델을 속이기 위해 설계된 함정들을 포함하여 모든 카테고리에서 100%의 정확도를 보였습니다. 모델들은 약 76%의 확률로 동의했으며, 각 저렴한 체크(cheap check)는 중앙값 기준으로 약 0.9초가 소요되었습니다. 엄밀성에 대한 솔직한 언급을 하자면: 초기 실행에서 몇 가지 명백한 실패 사례가 나타났으나, 이는 실제 오류가 아니라 우리의 채점 과정에서 발생한 포맷팅 버그(formatting bug)로 밝혀졌습니다. 우리는 이를 발견하여 수정하였고, 깨끗한 상태로 재실행했습니다. 지루한 재확인 과정이 바로 실질적인 작업입니다.

비용에 미치는 영향

우리는 이 게이트(gate)를 프로덕션(production) 환경에 배포하고, 테스트를 거치지 않은 프롬프트에 대한 에스컬레이션(escalation, 상위 모델로의 전환)을 다시 측정했습니다:

경계 모델(frontier) 호출 비용이 가장 많이 발생하는 긴 컨텍스트(long context) 구간에서, 정확도의 손실 없이 에스컬레이션은 전체에서 0%로 감소했습니다. 실제 트래픽 전체를 기준으로, 이제 시스템은 요청의 약 91%를 저렴한 티어(cheap tier)에서 처리합니다. 우리의 혼합 측정 비용(blended measured cost)은 요청당 약 0.002달러이며, 반복되는 질문은 캐시(cache)에서 거의 제로에 가까운 비용으로 처리됩니다.

*이것이 중요한 이유
*
테스트 코드가 포함된 코드와 같이 검증 가능한 작업에서 얻는 비용 절감은 이미 실질적이었습니다. 이 방식은 추측을 배제하고 정확도를 포기하지 않으면서도, 테스트가 없는 대다수의 실제 질문이라는 광범위한 작업 영역에 동일한 경제적 효과를 확장합니다. 어려운 사례들은 여전히 프론티어 (frontier) 모델이 처리하며, 이러한 사례들이 바로 고품질 답변을 캐시 (cache)해둘 가치가 있는 사례들입니다. 그래야만 다음에 동일한 질문이 들어왔을 때도 저렴하게 서비스될 수 있기 때문입니다.

정직함과 한계

우리가 증명한 모든 사례는 단일 최종 답변에 관한 것입니다. 우리는 아직 다단계 추론 (multi-step reasoning) 단계에서의 게이트 (gate)를 증명하지 못했습니다. 즉, 끊어진 추론 과정 속에서 운 좋게 최종 답변이 맞을 수 있는 경우나, 두 모델이 동일하게 틀린 추론 과정을 공유하며 동의할 수 있는 경우에 대해서는 아직 검증되지 않았습니다. 그것이 다음 단계의 과제이며, 우리는 여기서 그것을 주장하지 않습니다. 위의 결과는 두 개의 특정 저렴한 모델을 대상으로 한 것입니다. 다른 모델 쌍은 다르게 동작할 수 있으며, 모델의 다양성을 넓히는 것은 우리가 예비로 보유하고 있는 알려진 레버 (lever)입니다. 우리는 게이팅 엔지니어링 (gating engineering)이 아니라, 결과와 정직함을 공개하는 것입니다.