평가에 의사결정 모델을 활용하는 방법

최근 의사결정 모델(decision model)이 잇따라 등장했습니다. TypeSafe의 Jev를 시작으로 Perplexity의 Decider, Liquid의 d1, Cloudflare의 Clef, OpenAI의 Decisions API¹까지 나왔습니다. 모두 빠르고 저렴한 분류를 내세웁니다.

의사결정 모델은 자동화된 평가(eval)에서 LLM 심사자(LLM judge)²를 대체할 수 있는 저비용 대안으로 주목받습니다. 하지만 실제로 적합한 선택인지는 사용 사례의 비용, 성능, 지연 시간 요구 사항에 따라 달라집니다.

또 많은 사람이 기본 결정 임계값 0.50이 자신의 작업에 잘 맞는지 확인하지 않고 그대로 쓰는 모습도 보았습니다. 이렇게 하면 낼 수 있는 성능을 상당 부분 놓치게 됩니다.

이 글에서는 먼저 임계값을 조정해 의사결정 모델에서 최상의 결과를 얻는 방법을 보여드립니다. 임계값을 조정한 뒤에는 비용과 성능을 비교해 어떤 모델이 여러분의 사용 사례에 맞는지 판단합니다. 마지막으로 조치 여부를 결정할 때 모델 점수를 어떻게 해석해야 하는지, 보정(calibration)으로 점수를 신뢰도 추정치로 더 유용하게 만드는 방법은 무엇인지 살펴봅니다.

테스트 방법

아파트 임대 에이전트의 트레이스(대화와 동작을 기록한 로그) 100건을 사용했습니다. 작업은 예약 실패나 사람 상담원으로의 인계 누락처럼 오류가 있는 트레이스를 찾아내는 것입니다.³ 같은 데이터셋과 같은 포괄적 실패 탐지 작업을 자동화된 평가를 다룬 이전 글에서도 사용했습니다. 여기서는 각 의사결정 모델이 트레이스마다 실패 확률을 반환합니다.

테스트한 모델은 Jev 1.13, Perplexity Decider 1.1 27B, Liquid d1과 d1-ultra, Cloudflare Clef Flash, OpenAI Decisions(GPT-6 Luna)¹입니다. 모든 모델에 같은 평가 기준을 제공했습니다. Jev에 사용한 프롬프트와 구조화 버전은 부록에서 확인할 수 있습니다.

모델은 두 가지 기준으로 비교합니다.

• 성능: 각 모델의 예측을 사람이 검토해 통과 또는 실패로 라벨링한 트레이스와 비교합니다. 모델이 실패를 얼마나 잘 잡아내면서 오탐은 얼마나 피하는지 측정하는 방식입니다.
• 비용: 토큰 사용량과 제공업체의 가격으로 API 비용을 계산합니다.⁴

지연 시간은 이번 실험에서 통제할 수 없는 요인에 좌우되므로, 간결함을 위해 다루지 않았습니다.⁵

결정 임계값 이해하기

각 트레이스에는 통과(pass)와 실패(fail) 중 하나의 라벨을 붙입니다. 이를 이진 통과/실패 평가라고 하며, 기준을 명확히 세우게 하고 사람의 판단과 맞추기도 쉬워서 이 방식을 권장합니다.

의사결정 모델은 트레이스에 실패가 있을 가능성을 0에서 1 사이의 점수로 반환합니다. API는 이 점수를 기본 결정 임계값 0.50에 따라 판정으로 바꿉니다. 점수가 임계값 이상인 트레이스는 실패로 표시됩니다. 이 기본값을 자기 데이터로 검증하지 않고 쓰면 결과가 기대에 못 미칠 수 있습니다.

예를 들어 어떤 모델이 모든 실패에 0.40, 모든 통과 트레이스에 0.10을 부여한다고 해 보겠습니다. 임계값을 0.30으로 잡으면 이 모델은 트레이스를 완벽하게 분류하지만, 기본 임계값 0.50에서는 실패를 하나도 잡지 못합니다.

실제로는 실패와 통과 트레이스의 점수 분포가 겹칩니다. 임계값을 낮추면 더 많은 실패를 잡아내지만 오탐도 늘어날 수 있습니다. 임계값을 정한다는 것은 다음 두 지표 사이에서 균형을 잡는 일입니다.

• 정밀도(precision): 실패로 표시된 트레이스 중 실제로 알려진 실패가 있는 트레이스의 비율입니다.
• 재현율(recall): 알려진 실패 중 모델이 잡아낸 실패의 비율입니다.

적절한 균형점은 비즈니스 목표에 따라 다릅니다. 형사 재판은 무고한 사람에게 유죄를 선고하지 않도록 유죄 판단의 기준을 높게 두므로 정밀도를 중시합니다. 반면 암 검진은 오탐이 늘더라도 놓치는 사례를 줄이는 쪽, 즉 재현율을 중시할 수 있습니다.⁶ 이번 비교에서는 정밀도와 재현율의 조화평균인 F1 점수로 두 지표에 같은 비중을 둡니다. F1은 0에서 1 사이의 값이며 높을수록 좋습니다.

아래 곡선은 각 모델이 실패(주황)와 통과 트레이스(파랑)에 점수를 어떻게 매기는지 보여줍니다. 곡선이 높은 구간일수록 해당 클래스의 점수가 그 범위에 많이 몰려 있다는 뜻입니다. 점선으로 표시한 임계값 이상의 점수는 실패로 판정됩니다. 토글을 사용해 0.50과 모델별로 임계값을 정하는 F1 최적화를 비교해 보세요.⁷

이 작업에서는 OpenAI가 두 클래스를 가장 잘 구분했고, 이는 더 높은 F1 점수로도 나타납니다.

분류기가 쓸모 있으려면 충족해야 할 최소 요건을 먼저 생각해야 하며, F1을 무작정 최대화해서는 안 됩니다. 예를 들어 이 분류기를 자동 알림 시스템에 쓴다면, 오탐은 최소화하면서 충분한 수의 실패를 잡아내도록 정밀도와 재현율 모두 최소 80%는 되어야 한다고 생각합니다.

아래 차트는 임계값에 따라 정밀도와 재현율이 어떻게 달라지는지 보여줍니다.⁸ 음영 영역은 두 지표가 모두 80% 이상인 구간입니다.

Perplexity, Liquid d1-ultra, OpenAI Decisions는 요구 사항을 충족합니다. 다만 모델마다 음영 영역 안에서 결정 임계값을 골라야 합니다. 다음 절에서 임계값을 조정하는 방법을 설명합니다.

결정 임계값 조정하기

이 예시에서는 F1을 최적화합니다. 후보 모델은 가능하면 학습 데이터에서 두 가지 80% 최소 요건을 모두 충족하는 임계값 안에서만 조정하도록 제한합니다. 나머지 모델은 조정 효과를 보여주기 위해 제한 없이 조정합니다.⁹

라벨링된 트레이스와 저장해 둔 모델 점수가 있다면, 코딩 에이전트에게 임계값 조정을 맡길 수 있습니다. 다음은 사용 사례에 맞게 수정해 쓸 수 있는 프롬프트 예시입니다.

Using my saved model scores and binary labels (1 means failure), tune a decision threshold to maximize F1 while requiring at least 80% precision and 80% recall. Use stratified five-fold cross-validation, choosing thresholds on the training examples and measuring performance on the remaining examples. If comparing models, use the same splits for each. Only select thresholds that meet both minimums on the training examples. If none qualifies, report that rather than relaxing either requirement. Report validation precision, recall, and F1, along with any splits where no threshold qualified or validation performance fell below my minimums. Compare with the default threshold of 0.50. Reuse the saved scores without making new model calls.

F1 기준으로 조정하자 각 모델의 성능이 어떻게 달라졌는지 살펴보겠습니다. 정밀도-재현율 차트에서 고른 후보 세 개는 묶어서 보여주고, 나머지 모델은 회색으로 표시해 조정의 효과가 얼마나 큰지 드러냈습니다.

후보 모델은 F1 조정으로 얻은 이득이 Liquid d1과 Clef Flash보다 작았습니다. 두 모델은 조정 후에도 최소 요건에 미치지 못했습니다. 그래도 정밀도와 재현율이 조금만 달라져도 비즈니스 비용이나 사용자 경험에 영향을 줄 수 있으므로, 균형점은 신중하게 선택해야 합니다. 실제로는 (이 글에서 F1으로 가정한 것처럼) 정밀도와 재현율이 똑같이 중요한 경우는 드뭅니다. 예를 들어 F-beta 점수는 beta를 1보다 작게 하면 정밀도에, 1보다 크게 하면 재현율에 더 큰 가중치를 줄 수 있습니다. 다른 지표를 최적화하면 임계값과 결과도 달라질 수 있습니다.

성능과 비용

아래 차트는 남은 후보를 중심으로 각 모델의 (조정 후) F1을 비용과 비교합니다.

점선은 남은 후보 사이의 파레토 프런티어(Pareto frontier)입니다. 특정 F1 점수가 주어졌을 때, 그 점수 이상을 달성하는 후보 중 가장 저렴한 모델을 이어 놓은 선입니다. 선택지가 세 개뿐이라 이 차트는 다소 싱겁지만, 비용과 성능을 함께 따져 보는 방법을 이해하는 데는 도움이 됩니다.

이 후보 중 가장 저렴한 모델은 Perplexity로, 평가 100회당 0.82센트이고 F1은 0.79였습니다. OpenAI Decisions는 평가 100회당 3.72센트로 약 4.5배 비싸지만 F1 0.87을 기록했습니다.

확률을 믿어도 될까?

통과/실패 평가를 넘어, 의사결정 모델의 점수를 신뢰도 추정치로 쓰고 싶을 수도 있습니다. 그런데 그 숫자를 그대로 받아들여도 될까요? 점수 0.80이 실패 확률 80%를 의미하려면, 비슷한 점수를 받은 트레이스 중 약 80%에 실제로 실패가 있어야 합니다.

아래 차트는 각 모델의 확률 보정(probability calibration) 상태, 즉 예측 확률이 실제 결과와 얼마나 일치하는지를 보여줍니다.¹⁰ 각 점은 점수가 비슷한 트레이스 약 20건을 나타냅니다. 대각선 위의 점은 예측 확률이 해당 그룹의 실제 실패율과 일치한다는 뜻입니다. 선보다 위에 있으면 모델이 실패 위험을 과소평가한 것이고, 아래에 있으면 과대평가한 것입니다.

예측 확률이 실제 결과와 맞지 않으면 또 다른 모델로 확률을 조정할 수 있습니다. 두 번째 패널은 간단한 곡선을 맞춰 이 조정을 수행하는 방법 중 하나인 Platt scaling을 보여줍니다.¹¹

Perplexity, Liquid d1, Clef Flash는 보정 후 대각선에 더 가까워집니다. 예를 들어 Clef Flash의 한 트레이스 그룹은 평균 예측 실패 확률이 약 8%였지만, 실제로는 60%에서 실패가 발견됐습니다.

Jev와 Liquid d1-ultra는 이 데이터셋에서 이미 보정이 잘 되어 있어 조정이 거의 필요하지 않았습니다.

Platt scaling이 항상 가장 잘 맞는 것은 아닙니다. 예를 들어 OpenAI의 확률은 우리가 사용한 방식의 Platt scaling을 적용하자 오히려 소폭 나빠졌습니다.¹² 코딩 에이전트에게는 다음 프롬프트로 보정을 맡길 수 있습니다.

Using my saved failure probabilities and binary labels (1 means failure), test whether Platt scaling improves each model’s probabilities. Use stratified five-fold cross-validation with the same splits for every model. Fit the calibration mapping on each training split and apply it to the remaining traces. Fit on log-odds, clipping probabilities away from 0 and 1 first. Plot predicted probabilities against observed failure rates before and after calibration. Report Brier scores (lower is better), and explain which models improved or got worse. Reuse the saved scores without making new model calls.

프롬프트 튜닝과 평가자의 범위

이 글에서는 모델 간 차이가 더 잘 드러나도록 평가 작업의 범위를 넓게 잡았습니다. 하지만 실무에서는 실패 유형마다 별도의 심사자를 만들기를 권장합니다. 작업 범위를 좁히고 더 구체적인 지침을 주면 모델 간 성능 격차도 줄어들 것으로 예상합니다.

저는 해당 작업에서 성능이 충분히 나오는 큰 모델로 시작한 다음, 더 작은 모델이 더 낮은 비용으로 같은 성능을 내는지 시험해 보는 방식을 선호합니다. 고품질 라벨이 있다면 프롬프트 튜닝도 도움이 됩니다.¹³ 좋은 심사자 프롬프트를 작성하는 방법은 이 글에서 다뤘습니다.

실전에 적용하기

이 데이터셋에서는 OpenAI가 더 높은 비용으로 두드러진 성능을 보였습니다. Perplexity와 Liquid d1-ultra는 성능은 낮지만 비용이 더 저렴한 선택지입니다. 모델 성능은 작업과 데이터셋에 따라 크게 달라지는 것을 확인했습니다. 그러니 직접 측정해 보는 것이 중요합니다.

정리하면 다음과 같습니다.

• 심사자 프롬프트가 만족스러워졌다면, 사용 사례에 맞는 정밀도와 재현율의 최소 요건을 정합니다. 이를 충족하지 못하는 모델은 후보에서 제외합니다.
• 성능을 비교하기 전에 모델별로 결정 임계값을 조정합니다. 비즈니스 목표에 맞는 정밀도-재현율 균형을 선택하세요. 이 글에서 썼다고 해서 F1 점수를 그대로 따라 쓰지 말고, 의도를 갖고 선택하세요!
• 점수를 신뢰도 추정치로 쓰려면 확률이 실제 결과와 일치하는지 확인합니다. 보정이 도움이 될 수 있지만, 실제로 개선되는지는 직접 측정해야 합니다.
• 워크로드에 맞춰 성능을 비용, 지연 시간과 함께 따져 봅니다.

이 과정은 반복적입니다. 프롬프트를 개선한 뒤 임계값을 다시 조정하거나 보정을 다시 살펴봐야 할 수도 있습니다. 이 글에서 임계값 조정과 보정에 집중한 이유는 많은 사람이 이런 요소를 고려하지 않고 의사결정 모델을 기본 설정 그대로 쓰는 모습을 봤기 때문입니다.

의사결정 모델이 LLM과 비교해 어떤지도 궁금하실 겁니다. OpenAI Decisions는 GPT-6 Luna를 사용하며, 이번 실험에서 가장 높은 비용으로 가장 높은 F1을 기록했습니다. 어려운 평가 작업일수록 LLM에 더 많은 비용을 들일 만할 수 있다는 뜻입니다. 더 폭넓은 비교에서 Randy Olson은 분류와 라우팅에서는 의사결정 모델이 더 낮은 비용으로 LLM에 필적할 수 있지만, 지식과 추론이 필요한 작업에서는 LLM이 앞선다는 결과를 얻었습니다.

이 글에서 다룬 내용 중 새로운 것은 없습니다. 정밀도-재현율 균형 선택, 임계값 조정, 성능과 비용 비교는 어떤 분류기를 평가할 때든 거치는 과정입니다. 이런 기초를 더 배우고 싶다면 Kyle Gallatin과 Chris Albon의 Machine Learning with Python Cookbook, 2nd Edition을 추천합니다.

마지막으로, AI 시대에 데이터 사이언티스트나 ML 엔지니어로서 자신의 자리가 어디인지 고민하는 분들께 말씀드립니다. 이런 역량은 이미 여러분이 갖고 있습니다. 이제 되갚아 줄 때입니다 🙂.

부록: 평가 프롬프트

Perplexity, Liquid d1과 d1-ultra, Clef Flash, OpenAI Decisions에는 아래 프롬프트를 제공했습니다. Jev에는 아래 예시와 같이 구조화한 프롬프트로 동등한 기준을 제공했습니다. 차트에 사용한 점수와 라벨은 JSON으로 받을 수 있습니다.

Decide whether `messages` contains at least one substantive failure, risk, or quality problem in the AI assistant's behavior or tool use. This is one complete production trace from an AI that handles apartment-leasing customer support over phone or messaging. The trace includes the conversation plus any tool calls and tool outputs.

Evaluate the AI assistant and its tool use, not the customer. Treat system messages inside `messages` as the instructions governing the assistant's behavior and allowed capabilities. Inspect the full trace, including final turns and all tool calls and outputs. Base the judgment only on evidence visible in this trace. Do not assume external policies, channel behavior, or business requirements that are not present. Do not assume every trace failed. A short, ambiguous, or inconclusive trace is not an issue unless visible evidence establishes a substantive failure.

Return the probability that at least one substantive issue is present; the issue does not need to be named or clustered.

Count as an issue when supported by the trace: the assistant contradicts an applicable system instruction or tool result; makes an unsupported factual or operational claim; misses, misuses, repeats, or falsely claims completion of a required tool action, transfer, booking, cancellation, follow-up, or confirmation; materially misunderstands or leaves an explicit user request unresolved; or exposes internal actions, placeholders, or broken content to the customer in a way that materially harms the interaction.

Do not count as an issue: a minor stylistic preference with no meaningful effect; a failure caused only by the customer's behavior; internal tool metadata that was not exposed to the customer and did not cause an incorrect response; a hypothetical concern requiring information outside the trace; or insufficient evidence and inconclusive conversations.

{
  "version": "nurtureboss-any-issue-v1",
  "question_id": "has_substantive_issue",
  "type": "noul",
  "instructions": {
    "task": "Does `messages` contain at least one substantive failure, risk, or quality problem in the AI assistant's behavior or tool use?",
    "context": "This is one production trace from an AI that handles apartment-leasing customer support over phone or messaging. The trace contains the complete conversation plus any tool calls and tool outputs.",
    "evaluation_rules": [
      "Evaluate the AI assistant and its tool use, not the customer.",
      "Treat system messages inside `messages` as the instructions governing the assistant's behavior and allowed capabilities.",
      "Inspect the full trace, including the final turns and all tool calls and outputs.",
      "Base the judgment only on evidence visible in this trace. Do not assume external policies, channel behavior, or business requirements that are not present.",
      "Do not assume every trace failed. A short, ambiguous, or inconclusive trace is not an issue unless the visible evidence establishes a substantive failure.",
      "Return the probability that at least one substantive issue is present. The issue does not need to be named or clustered."
    ]
  },
  "criteria": {
    "true": {
      "definition": "At least one substantive problem is supported by evidence in the trace.",
      "examples_of_qualifying_evidence": [
        "The assistant contradicts an applicable system instruction or a tool result.",
        "The assistant makes an unsupported factual or operational claim.",
        "A required tool action, transfer, booking, cancellation, follow-up, or confirmation is missing, incorrect, repeated, or falsely claimed as complete.",
        "The assistant materially misunderstands or leaves an explicit user request unresolved.",
        "Customer-facing text exposes internal actions, placeholders, or broken content that materially harms the interaction."
      ]
    },
    "false": {
      "definition": "No substantive assistant problem can be established from the visible trace.",
      "do_not_count_as_an_issue": [
        "A minor stylistic preference with no meaningful effect.",
        "A failure caused only by the customer's behavior.",
        "Internal tool metadata that was not exposed to the customer and did not cause an incorrect response.",
        "A hypothetical concern that requires information outside the trace.",
        "Insufficient evidence or an inconclusive conversation."
      ]
    }
  }
}