의사결정 모델에게 AI 작업 검토를 맡겼습니다. 생각하라고 요구하지 않자 성능이 좋아졌습니다.

Microsoft가 이번 달에 OpenRouter에 작고 특이한 모델을 올렸습니다. 이 모델은 상황과 명시된 답안이 있는 질문을 받으면, 각 답안에 대한 확률을 돌려줍니다. Microsoft-Decision-1이 바로 그 기능을 합니다.

저희는 대부분의 요청을 저렴한 모델로 보내고 외부로 나가기 전에 작업 내용을 검사하는 게이트웨이를 운영합니다. 숫자와 함께 '예' 또는 '아니오'로만 답하는 모델은 몇 달 동안 구축하려고 노력해 온 검사기처럼 들렸습니다. 저희는 토요일을 투자하여 알아봤습니다.

실패했던 부분들을 포함하여, 다음과 같은 일이 벌어졌습니다.

1. At a glance: four versions took wrong approvals from 9 to 0

저희에게 가르쳐준 첫 번째 교훈

저희는 신중한 동료에게 할 법한 질문들로 시작했습니다. '이 메모가 에이전트가 하려는 작업과 관련성이 있습니까?', '이 도구 호출이 사용자가 요청한 것과 일치합니까?'와 같은 질문들이었습니다.

모델은 불안정하게 반응했습니다. 동일한 요청을 두 번 보냈더니 다른 확률이 돌아왔고, 때로는 그 차이가 컸습니다. 관련성 질문의 경우, 동일한 입력에 대해 호출마다 최대 0.17만큼 변동했습니다. 동일한 입력에 대해 마음을 바꾸는 검사기는 쓸모가 없습니다.

그러다가 저희는 모델이 안정적으로 유지되는 지점을 발견했습니다. 질문이 사실(fact)에 관한 것이었을 때, 모델은 꾸준했습니다. '사용자의 메시지에 이 정확한 도시 이름이 포함되어 있습니까?'라는 질문은 매번 동일하게 돌아왔고, 그것도 정확했습니다.

그것이 나머지 하루 동안의 규칙으로 자리 잡았습니다. 코드가 사실을 찾게 하세요: 사용자의 단어에 값이 있는지, 올바른 유형인지, 목록에 적절한 개수의 항목이 있는지를요. 그런 다음 모델에게 이미 코드에 제시된 사실에 대해 명확하게 질문하세요. 실질적인 판단(judgement)이 필요한 경우에는 답변을 강요하지 마십시오. '불확실함(UNSURE)'이라고 말하고 더 강력한 시스템으로 전달하십시오.

판단이 아닌, 사실을 제공하세요.

2. Asked for a judgement, it wobbled. Asked about a fact, it held still.

검사기 (The checker)

우리가 만든 것은 의도적으로 지루합니다. 코드가 호출을 점검합니다. Decision-1은 몇 가지 사실 질문에 답합니다. 만약 뭔가 잘못되었고 수정 가능하다면, 저렴한 모델이 호출을 복구하기 위해 한 번 시도하고, 복구된 호출은 동일한 검사를 거칩니다. 결과는 APPROVE(승인), REJECT(거부) 또는 UNSURE(불확실)이며, 실행된 모든 검사 내역서가 첨부됩니다.

3. Code finds the facts; the model only answers about them

우리는 세 가지를 측정했습니다. 왜냐하면 검사기는 세 가지 방식으로 실패할 수 있기 때문입니다:

• 잘못된 호출을 승인하는 빈도. 우리는 이것을 “덜 틀림(less wrong)”이라고 부르며, 5% 이하를 목표로 했습니다.
• 잘못된 호출을 받아 수정하고 그 수정을 승인하는 빈도.

각 단계는 이전 버전이 잘못 처리한 호출(calls)을 읽는 것에서 비롯되었습니다.

Version 2.2는 '예'에 대한 기준을 높였고, 누수(leaks)는 줄었습니다. 수정 사항들 또한 그와 함께 줄어들었습니다. 이는 좋은 것을 얻기 위해 또 다른 좋은 것을 포기하는 것이었으므로, 우리는 수정 사항의 최소치를 설정하고 계속 진행했습니다.

Version 2.3은 2.1과 2.2가 승인했던 열세 개의 잘못된 호출을 검토했고, 이들이 네 가지 형태로 나타났으며, 모두 코드가 감지할 수 있는 것이었습니다. 목록이 목록 안에 텍스트로 전송되는 형태. 사용자가 언급하지 않은 선택적 값. 사용자가 'Washington D.C.'라고 말했을 때의 'Washington'. 사용자가 '5 미만'이라고 말했을 때의 5라는 제한치 등입니다. 검사기(checker)를 위한 네 가지 새로운 사실을 추가하자, 누수는 2개로 줄어들었고 수정 사항은 다시 증가했습니다.

이 두 개의 누수 중 하나는 `['[

Version 2.4에서는 두 검사 순서를 수정하고, 복구 모델이 숫자를 재조정하는 것을 막았으며, 하나의 조용한 규칙을 추가했습니다. 즉, 검사자가 승인한 경우에만 복구가 유지됩니다. 그렇지 않으면 원래의 호출은 아무것도 건드리지 않은 채 그대로 나갑니다. 이 규칙 덕분에 아무것도 고장나지 않았습니다. 누구도 보증할 수 없는 복구는 어떤 것도 대체할 수 없게 된 것입니다.

8. A repair nobody could vouch for never replaces anything

'제로(zero)'가 의미하는 것

우리가 규칙을 작성하는 검토자에게 2.4 버전이 잘못된 호출을 승인한 적이 없다고 말했을 때, 그 검토자는 강하게 반발했습니다. 검토 과정의 일부는 받아들여졌습니다. 모든 버전은 다른 호출 샘플과 다른 레이블러를 기반으로 실행되었기 때문에, 버전 전반에 걸친 추세에는 노이즈가 포함되어 있습니다. 그리고 96개 중 20개의 수정 비율은 간신히 20%의 기준을 충족합니다.

하지만 일부는 받아들여지지 않았습니다. 그들은 '제로'라는 수치가 더 큰 분모에 의해 부풀려졌다고 제안했습니다. 우리는 그 아래의 순수한 숫자를 계산했습니다. 네 가지 버전을 통틀어 검사자가 예라고 말한 횟수는 각각 164, 150, 120, 110회였으며, 잘못된 경우는 각각 9, 4, 2, 0회였습니다. 2.4 버전이 '예'라고 말했을 때는 지금까지 매번 정확했습니다. 이 수치는 그 자체로 의미가 있습니다.

9. When 2.4 says yes it has been right every time; it says yes less often

진짜 비용은 같은 숫자에서 확인할 수 있습니다. '예'라고 말하는 횟수가 적습니다.

청구서(The bill)

Decision-1은 사라지기에 충분히 저렴합니다. 전체 300개 호출 테스트는 1센트 미만이었고, 기록된 1,417개 추가 호출에 대해서도 중앙값 기준으로 초당 약 2분의 1센트에 불과했습니다.

흥미로운 비용은 다른 곳에 있습니다. 검사기(checker)가 구매하는 것을 바꿉니다. 검사기가 없다면 토큰당 비용을 지불하고 답변이 맞기를 기대해야 합니다. 하지만 검사기가 있다면, 단위는 '검증된 답변'이 되며, 그 가격에는 검사기가 승인하지 못해 더 비싼 곳으로 보내야 했던 모든 호출의 비용이 포함됩니다.

이것은 저희로 하여금 토큰당 가격 대신 작업(task)당 가격으로 생각하게 만들었습니다. 자체 기록한 실행 결과에 따르면, 저렴한 모델에 검사기와 에스컬레이션(escalation)을 더했을 때의 비용은 동일한 작업을 프리미엄 모델이 직접 수행하는 데 드는 비용보다 훨씬 적습니다. 얼마나 작은 비율인지는 거의 전적으로 하나의 수치, 즉 검사기가 '예'라고 말할 수 있는 빈도에 달려 있습니다.

10. A checker turns price per token into price per checked task

우리가 아직 해결하지 못한 문제

10건 중 4건의 호출이 UNSURE(불확실)로 돌아옵니다. 대부분은 검사기가 사용자의 말에서 사실로 확정할 수 없는 주장에 달려 있습니다. 코드는 그러한 값의 의미를 알 수 없으며, 이를 판단하도록 요청받은 의사결정 모델(decision model)은 흔들립니다.

11. Four in ten calls come back UNSURE

다음 주에 우리가 가져갈 질문은 이것입니다. 검사기가 해서는 안 되는 것에 '예'라고 말하도록 가르치지 않으면서, 의미에 대한 판단을 순수 코드가 확인할 수 있는 사실로 어떻게 바꿀 수 있을까요?

이것을 구현한 것이 있다면, 저희가 듣고 싶습니다.

Tom Jones, Spanda Works. 검사기와 테스트 하네스(test harness)는 저희 소유이며; Microsoft-Decision-1은 마이크로소프트의 모델이고, OpenRouter를 통해 사용됩니다.