생성하지 않고 '고르는' 모델: Decision Model 100여 개를 뜯어보니

Lucy.·2026년 10월 10일 (토)

고객 문의를 어느 팀으로 보낼지, 문서가 검토 기준을 통과하는지, 지금 작업을 계속할지 사람에게 넘길지. 이런 업무에는 긴 설명보다 정해진 선택지 중 하나와 그 판단을 얼마나 믿을 수 있는지가 먼저 필요합니다.

이 틈을 겨냥한 AI가 Decision Model, 판단형 AI입니다. Jev를 비롯해 AWS·Microsoft·Perplexity·Cloudflare·Liquid AI까지 서로 다른 방식의 모델을 선보였습니다. 공개 자료에서 베이스를 확인할 수 있는 구현 105개를 뜯어보면, 새로운 이름 아래에서 같은 출발점을 공유하는 모델이 많고, 큰 모델의 높은 판단 점수가 곧 저렴한 운영으로 이어지지도 않습니다.

앞선 Jev는 어떤 업무에서 GPT급일까? 판단형 AI 성능·비용 직접 비교에서는 Jev가 답변 검수 등 일부 과제에서 범용 AI에 근접한 결과를 내면서 처리 시간과 기록 비용을 줄인 사례를 살펴봤습니다. 판단형 AI의 강점은 미리 정한 선택지 안에서 답해 코드의 조건 분기에 연결하기 쉽고, 긴 답변 생성을 줄여 지연·비용을 낮출 여지가 있다는 것입니다. 선택지별 확률은 실제 정답률과의 차이를 검증한 뒤 사람에게 넘길 기준으로 쓸 수 있습니다. 어떤 모델·업무에서 이 이점이 살아나는지는 직접 비교해야 합니다.

이 글에서는 모델의 계보와 만드는 방식, 성능표를 읽는 기준, 한국어 업무에서 직접 확인할 실험을 연결해 봅니다. 처음부터 모델을 학습할 필요는 없습니다. 반복되는 업무 하나를 고르고, 실제 입력과 선택지·판정 기준을 적어 보는 것이 가장 쉬운 시작입니다.

판단형 AI의 입력과 세 출력

판단형 AI에는 보통 상황(state), 질문, 제한된 답변 범위를 넣습니다. 고객의 “연동 오류가 계속 납니다”라는 문의를 상황으로, “어느 팀이 처리할까?”를 질문으로, “결제·기술 지원·영업”을 선택지로 넣는 식입니다. 출력은 정해진 타입의 결과와 확률입니다.

TypeSafe가 문서화한 대표적인 세 형식을 보면 역할이 분명해집니다.

Choice — 묻는 내용: 여러 후보 중 무엇을 고를까? 반환하는 결과: 선택지별 확률과 선택 결과. 업무 예시: 고객 문의 담당 팀 배정
Noul — 묻는 내용: 이 조건이 성립할까? 반환하는 결과: 예일 확률, 0~1. 업무 예시: 문서에 필수 항목이 있는지 확인
Score — 묻는 내용: 어느 수준에 해당할까? 반환하는 결과: 순서가 있는 평가 단계의 확률과 기대 점수. 업무 예시: 답변이 기준을 얼마나 충족하는지 평가

이름이 같은 형식이라도 업체별 입력 규격과 반환 필드는 확인해야 합니다. 특히 Score의 4점과 Choice의 0.8, Noul의 예 확률은 서로 다른 값입니다.

일반 LLM도 A·B·C 같은 답변 기호의 logits, 즉 정규화 전 점수를 읽어 선택지 확률을 만들 수 있습니다. 판단형 AI의 특징은 이 절차를 제품의 중심에 놓고, 선택·평가 결과가 바로 프로그램의 다음 행동으로 이어지도록 구성했다는 데 있습니다. 긴 답변을 생성하고 그 문장을 다시 해석하는 과정이 줄어들면 반복 분류나 라우팅에 유리할 수 있습니다.

다만 새 문장을 만들지 않는다는 사실이 정확한 판단을 보장하지는 않습니다. 잘못된 기준을 넣거나 실제 업무와 다른 자료로 학습했다면, 형식이 정확한 오답을 빠르게 반환할 수도 있습니다.

베이스·출력부·학습법의 차이

새 판단 모델을 볼 때는 무엇에서 출발했고, 결과를 어떻게 읽으며, 무엇을 학습했는지를 나누어 보세요.

베이스 모델은 출발점이 된 사전학습 모델입니다. 체크포인트는 특정 시점의 가중치 파일입니다. 같은 Qwen 계열이어도 크기·버전·학습·실행 설정이 달라지면 다른 결과가 나옵니다.

출력부, 즉 readout head는 내부 표현을 선택지 점수로 바꾸는 부분입니다. 선택지 위치의 표현을 비교하는 pointer 방식, A·B·C 같은 기호의 점수를 읽는 방식, 여러 질문과 필드를 함께 처리하는 별도 head 등이 있습니다. LoRA는 원래 가중치에 작은 학습 가능한 행렬을 추가하는 학습법이며, 출력부의 이름은 아닙니다.

AWS Strands Decider 2B는 구체적인 사례입니다. Qwen3.5-2B의 본체에서 언어 생성 head를 떼고, 약 100만 파라미터의 pointer head와 rank 16 LoRA를 학습했습니다. 개발사의 출시 글은 RTX 3090에서 중앙 지연 시간 약 115ms를 제시합니다. 이는 해당 글의 v18 측정이며, 공개된 v19 체크포인트나 다른 장치·입력 길이의 속도를 자동으로 뜻하지 않습니다.

이런 “작은 LLM + 새 출력부 + LoRA”는 유력한 경로지만 전체 분야의 공통 제조법은 아닙니다. 베이스를 그대로 두고 logits만 읽는 구현도 있고, 전체 미세조정이나 여러 학습 결과의 병합을 쓰는 구현도 있습니다.

Cloudflare Clef는 작은 Transformer 출력부로 스키마의 여러 질문을 함께 처리합니다. Fastino GLiNER2.5-Decide는 encoder 기반으로 점수를 계산하고 제약을 반영해 구조화된 결과를 고릅니다. Liquid의 d1은 모델별로 미세조정과 병합 과정을 사용합니다. 업체 이름이 같아도 구조를 한 줄의 “LoRA 모델”로 통일하면 중요한 차이를 놓칩니다.

주요 기업 모델의 베이스

공식 출시문과 모델 카드에서 확인한 출발점을 정리하면 다음과 같습니다. 베이스의 공개 여부와 완성된 제품의 제공 방식은 별개입니다.

모델·제품	확인된 베이스·구조	제공 방식과 확인할 지점
Microsoft-Decision-1	Qwen3.5-9B를 후학습한 모델	Foundry·OpenRouter API. 현재 베이스와 향후 다른 베이스로 확장하려는 계획을 구분
AWS Strands Decider 2B	Qwen3.5-2B-Base + pointer head + LoRA	v19 코드·가중치 Apache 2.0. 출시 글의 속도 측정은 v18 조건
Perplexity Decider v1.1 27B	Qwen3.8-27B + 별도 decision readout	v1을 개선한 체크포인트. 비인과 attention·저장된 보정 온도 등 전용 추론 설정 확인
Cloudflare Clef / Clef-Flash	Qwen3.8-27B / Qwen3.5-9B	스키마 기반 다중 질문 출력부. 모델 카드 Apache 2.0
Liquid d1-3B	LFM2.5-VL-3B 계열 decoder	text backbone 조합과 미세조정·병합. 한 번의 순전파로 선택 결과 산출
Liquid d1-omni-600M	LFM2.5-Encoder-350M + 시각·음성 encoder	텍스트+이미지 또는 텍스트+음성 입력. 실험적 모델
Fastino GLiNER2.5-Decide	DeBERTa-v3-large 계보의 GLiNER2 encoder, 340M	구조화된 판단과 제약 처리. 전체 또는 LoRA 미세조정 가능
TypeSafe Jev	베이스·세부 내부 구조 비공개	타입이 있는 판단 API. 공개된 입출력 규격과 측정 결과로 평가

Microsoft의 공식 출시문은 현재 모델이 Qwen3.5-9B에서 출발했다고 설명합니다. 앞으로 MAI나 OpenAI 계열 등 다른 베이스를 검토한다는 계획을 현재 구조와 혼동하지 않아야 합니다.

Perplexity v1.1은 별도 readout을 사용하며 일부 attention의 인과 마스크를 해제합니다. 일반적인 causal 추론으로 실행하면 모델 카드가 설명한 평가 설정을 재현하지 못합니다. 공개 카드의 사용 안내에는 인증 접근과 약 49GiB의 가중치 메모리 등 조건도 적혀 있으므로, 모델 이름만 보고 곧바로 가볍게 실행할 수 있다고 가정해서는 안 됩니다.

Fastino의 GLiDE는 또 다른 예외입니다. 불확실한 경우 추가 추론을 사용하는 API 제품으로, 모든 판단 모델이 항상 “한 번의 순전파·출력 토큰 0”으로 끝난다고 일반화할 수 없음을 보여 줍니다. GLiNER2.5-Decide와 같은 회사 제품이라고 해서 GLiDE의 비공개 베이스까지 같은 것으로 추정할 수도 없습니다.

이 비교에서 중요한 것은 업체의 크기보다 우리 입력을 받아 필요한 결과를 어떤 조건과 비용으로 돌려주는가입니다.

105개 계보와 상위권의 차이

조사 목록의 105개는 공개 자료로 베이스를 분류한 decoder 기반 구현과 diffusion 기반 구현입니다. 현재 보드의 측정값이 있는 102개와 발표·공개 자료로 추가한 3개를 합쳤습니다. AWS Strands Decider 2B, Microsoft-Decision-1, Liquid d1-3B는 이 목록에서 같은 Capability 측정값이 없는 항목입니다.

베이스가 공개되지 않은 Jev와 GLiDE, encoder·reranker 및 학습 없는 베이스 대조군은 이 계보 집계에서 제외했습니다. 따라서 105개가 전부 같은 시험을 치른 모델이거나, 서로 독립적으로 개발된 105개 베이스라는 뜻은 아닙니다.

Qwen — 조사 수: 74. 비중: 약 70%. 점수 확인 수: 72. Capability 평균: 58.9. 최고: 82.8.
Gemma — 조사 수: 23. 비중: 약 22%. 점수 확인 수: 23. Capability 평균: 67.9. 최고: 81.7.
기타 — 조사 수: 8. 비중: 약 8%. 점수 확인 수: 7. Capability 평균: 48.2. 최고: 58.4.
합계 — 조사 수: 105. 비중: 100%. 점수 확인 수: 102. Capability 평균: —. 최고: —.

평균은 측정값이 있는 구현만 계산했습니다. 기타 48.2는 점수가 있는 7개 구현의 평균입니다. 기타의 개별 베이스 계열 평균은 43.3~58.4로, 구현 전체의 평균과 구분됩니다. 위 목록의 최고값은 비용·지연 제한 밖의 모델까지 포함한 Capability이며, 제한 안의 공식 상위 순위와 구분해야 합니다.

Qwen3.5-4B에서 출발한 구현은 29개입니다. 같은 크기의 베이스에서 출력 방식·데이터·추론 코드를 바꾸는 실험이 활발하다는 뜻입니다. Plumb나 deck 계열의 구현을 이어받은 경우에도 최종 이름만 보지 않고 상위 베이스까지 거슬러 올라가 Qwen 계보로 분류했습니다.

반면 Benchmark Heaven의 v1.6.1·board v1.7.30 공식 Composite 상위 20개 중 19개는 Gemma 계보이고, 나머지 하나는 Qwen3.5-4B 기반 H2O-Lightning-4B v1.1입니다. 여기에는 Gemma 계보의 Diffusion Jev도 포함되며, 순위가 없는 Jev 기준 행은 세지 않았습니다.

두 결과는 서로 다른 질문에 답합니다. Qwen은 이 조사 목록에서 가장 많이 선택된 출발점입니다. Gemma는 이 버전의 종합 점수 상위권에서 큰 비중을 차지합니다. 제출·구현의 수, 판단 능력, 운영 효율의 순위는 같지 않습니다.

또한 버전·크기·학습법·출력부·실행 장치가 섞인 계열 평균만으로 “Gemma라는 베이스 자체가 원인”이라고 결론 내릴 수는 없습니다. 실무 후보를 좁히는 신호로 삼고, 비슷한 조건의 개별 모델을 비교하는 편이 유용합니다.

27B의 비용, 5.1~22.2배

Qwen3.8-27B 계열 구현은 이 목록에 15개 있습니다. 직접 베이스가 파생 모델인 경우에는 상위 계보를 확인했고, torchcast의 일부 역사적 베이스 버전은 공개 보드의 추정 표기를 함께 고려했습니다. Flash-Next나 2B로 증류한 모델까지 27B에 넣지는 않았습니다.

같은 보드의 1,000회 판단 비용 열을 Jev의 고정 v1.5 기준 비용 약 0.0323달러와 비교하면, 이 15개는 약 5.1~22.2배 범위입니다.

예시	보드의 1,000회 판단 비용	고정 Jev 기준 대비
JADE	약 $0.164	약 5.1배
Perplexity Decider v1.1 27B	약 $0.217	약 6.7배
Clef	약 $0.249	약 7.7배
Kev 27B	약 $0.529	약 16.4배
Open-Jev 27B v1.1	약 $0.716	약 22.2배

따라서 “27B 계열은 Jev보다 6~7배 비싸다”는 요약은 Perplexity 같은 일부 사례에는 맞지만 계열 전체를 설명하지 못합니다.

이 열에는 자체 호스팅 모델의 토큰 사용량과 기준 가격으로 계산한 추정 비용이 포함되어 있습니다. API 서비스의 실제 청구 가격, 직접 빌린 GPU의 시간당 비용, 배치 처리로 절약한 비용은 따로 계산해야 합니다. 표의 비용 비율을 그대로 계약 견적처럼 쓰면 안 됩니다.

Perplexity v1.1의 Capability는 82.8로, Intelligence 75.7과 Calibration 89.9의 평균입니다. v1과 v1.1은 서로 다른 체크포인트이며, 모델 카드의 Decision Index 점수도 이 JevBench 값과 다른 평가입니다.

높은 Capability에도 비용이 Jev-class 한도를 넘으면 해당 헤드라인 순위에서는 제외됩니다. 비용까지 반영하는 Composite 순위도 달라집니다. 어느 순위표에서 1위인지보다, 우리 업무의 예산과 응답 시간 안에서 어떤 모델이 남는지가 더 중요합니다.

JevBench 능력과 종합 효율

Benchmark Heaven의 JevBench는 Intelligence·Calibration·Speed·Cost 네 축을 평가합니다. 화면에서 비슷하게 보이는 Capability와 Composite는 계산 방식도, 답하는 질문도 다릅니다.

지표	계산·조건	읽는 방법
Intelligence	판단 과제의 성능을 보드의 방식으로 산출	우리 업무와 어떤 과제가 겹치는지 확인
Calibration	반환한 확률과 결과의 부합 정도 평가	높은 확률의 오답이 얼마나 생기는지 확인
Capability	(Intelligence + Calibration) ÷ 2	능력과 확률 보정을 함께 본 값
Jev-class	고정 Jev 기준의 비용·중앙 지연 시간 모두 2배 이하	헤드라인 Capability 순위의 자격 조건
Composite	네 축의 동일 가중 조화평균에 낮은 축의 감점 적용	능력·속도·비용을 함께 고려한 종합 점수

현재 기준의 Jev-class 한도는 1,000회 판단 비용 약 $0.0646, 조정된 중앙 지연 시간 약 1.23초입니다. 비용 또는 지연 한도를 넘으면 Capability가 높아도 헤드라인 자격을 얻지 못합니다.

Composite의 “동일 가중”은 네 점수를 단순히 더해 4로 나눈다는 뜻이 아닙니다. 조화평균은 낮은 축의 영향을 크게 받고, Intelligence·Speed·Cost가 설정된 기준 아래면 추가 감점도 적용합니다. 그래서 큰 모델이 판단은 잘해도 높은 비용 때문에 종합 점수가 낮아질 수 있습니다.

역사적인 순위도 구분해야 합니다. BenchLM에 남은 v1.5.4에서는 Cygnet 73.70, Winnow 73.23이 통계적으로 비슷한 상위권이었습니다. 이 글에서 보는 현재 v1.6.1의 Composite 1위는 H2O-Lightning-4B v1.1입니다. 시험 구성·방법과 후보가 달라질 수 있으므로, 버전이 다른 숫자의 변화를 전부 모델 개선 효과로 읽어서는 안 됩니다.

또 하나의 JevBench인 “JevBench: coherence tests for typed decision models”는 타입이 있는 판단의 일관성을 검사하는 별도 프로젝트입니다. 이름이 같아도 정확도·비용·속도를 종합하는 Benchmark Heaven의 순위표와 바꾸어 인용하면 안 됩니다. Decision Index 역시 별도 평가이며 그 점수를 Capability와 같은 척도로 섞지 않습니다.

확률 0.8과 confidence 0.8의 차이

실무 자동화에서는 “무엇을 골랐나” 다음에 “어느 때 사람에게 넘길까”가 필요합니다. 이때 서비스가 주는 확률과 confidence의 정의를 먼저 확인해야 합니다.

Choice의 최고 선택지 확률이 0.8이라는 것은 그 모델이 해당 선택지에 배분한 값입니다. TypeSafe의 Choice confidence는 선택지 수에 따른 균등 분포 기준을 제거한 값입니다.

confidence = (최고 확률 - 1/선택지 수) ÷ (1 - 1/선택지 수)

가령 선택지가 4개이고 최고 확률이 0.8이면 confidence는 약 0.733입니다. Noul은 별도 confidence 없이 예일 확률을 돌려줍니다. 서로 다른 서비스의 0.8에 같은 업무 임계값을 붙이기 전에 이 차이를 확인하세요.

보정(calibration)은 비슷한 확률을 받은 여러 사례에서 실제 결과가 그 확률과 얼마나 맞는지를 보는 성질입니다. 0.8을 준 사례 묶음의 정답률이 크게 낮다면 모델은 과도하게 확신한 셈입니다. ECE는 확률 구간별 확신도와 정답률의 차이를, Brier score는 예측 확률과 실제 결과의 차이를 측정합니다.

AWS v19 카드의 공개 항목 정답률 167/231과 그 카드의 보정 지표는 해당 평가 조건의 자체 측정입니다. 그 비율을 전체 JevBench Capability로 부르거나 실제 한국어 고객 문의의 성공률로 옮길 수는 없습니다.

업무 자료로 임계값을 정할 때는 자동 처리의 정답률과 자동 처리한 비중, 사람에게 넘긴 비중을 함께 보세요. 사람에게 거의 전부 넘겨 얻은 높은 정확도와 대부분을 처리하며 얻은 정확도는 운영 가치가 다릅니다. 선택지 순서와 같은 입력의 반복 실행도 확인해야 합니다. 출력 토큰이 없다는 이유만으로 모든 모델의 재현성이 같아지는 것은 아닙니다.

한국산 베이스와 한국어 성능

105개 목록에서 EXAONE 계열은 한 개입니다. 이것은 한국에서 만든 베이스의 포함 수이며, 한국어 판단형 AI 전체가 한 개뿐이라는 뜻은 아닙니다. Qwen·Gemma 계열도 한국어를 대상으로 평가할 수 있고, 베이스의 국적만으로 한국어 성능을 알 수 없습니다.

EXAONE-4.0-1.2B-JEV는 LG의 공식 판단 모델이 아니라 개인 개발자의 파생 모델입니다. v0.3 카드에는 영어 자료를 이용한 전체 미세조정, 선택지 순서를 두 번 바꾸어 읽고 평균 내는 방식이 설명되어 있습니다. 영어 전용이라는 범위와 익숙하지 않은 영역에서 과도하게 확신할 수 있다는 한계도 명시되어 있습니다.

베이스 EXAONE-4.0-1.2B가 한국어를 지원한다는 사실을 이 파생 모델의 검증된 한국어 판단 성능으로 확대해서는 안 됩니다. 또한 베이스와 파생 모델 카드의 비상업 라이선스 조건이 있어, 사업용 후보로 삼기 전 이용 조건을 확인해야 합니다.

AIB DecisionBench-KJ에서 직접 확인할 수 있는 것

한국어 평가도 이미 출발점이 있습니다. 에이아이비가 운영하는 AIB DecisionBench-KJ는 공개 데이터 8종의 한국어 1,250문항·일본어 750문항, 총 2,000문항으로 판단형 AI를 비교합니다. 2026년 10월 10일 공개 화면의 0.2 버전에는 판단형 모델 12개와 범용 대조군 GPT-6.1 Sol·Claude Sonnet 5.5가 있습니다. 앞선 Jev 글의 10월 4일 결과에서 비교 모델이 늘어난 현재 결과입니다.

과제는 긴 답변 작성이 아니라 예·아니오, 보기 선택, 단계 점수로 답할 수 있는 판단에 맞췄습니다. 원본 데이터셋의 사람 라벨을 정답으로 쓰고, 모델이 각 선택지에 부여한 확률 중 가장 높은 것을 답으로 채점합니다.

KoBEST — 한국어 250문항: 지문 기반 예·아니오 100, 원인·결과 90, 감정 분류 60
KLUE — 한국어 250문항: 근거와 문장의 일치 150, 문장 유사도 100
JGLUE — 일본어 250문항: 상식 75, 근거 일치 100, 문장 유사도 75
KMMLU·JMMLU — 한국어·일본어 각 125문항: 한국 자격시험·일본 교과 수준 지식
M-RewardBench — 한국어·일본어 각 125문항: 두 AI 답변 중 더 나은 쪽 선택
PolyGuardPrompts — 한국어·일본어 각 125문항: 유해한 요청 판별
K-MHaS — 한국어 250문항: 혐오 표현 판별
RTP-LX — 한국어·일본어 각 125문항: 유해성의 정도를 단계로 판단

종합 정확도는 8개 데이터셋의 정답률을 같은 비중으로 평균합니다. 한국어·일본어 점수도 각 언어가 있는 데이터셋끼리 같은 비중으로 평균하므로, 종합 점수는 두 언어 점수의 단순 평균이 아닙니다. 문장 유사도 0~5, 유해성 1~5 같은 단계 점수는 정답 단계를 정확히 맞혀야 정답으로 셉니다.

정확도 옆에서는 두 가지를 더 봐야 합니다. 확률 보정(ECE)은 “90% 확신”이라고 한 답들이 실제로 그만큼 맞는지, 보기 순서 흔들림은 같은 문제의 보기 순서를 뒤집었을 때 답이 바뀌는 비율을 봅니다. 두 지표 모두 낮을수록 좋습니다. 순서 비교는 최대 1,340쌍을 추가로 물어, 판단형 모델마다 기본 2,000문항을 포함한 3,340요청으로 측정했습니다.

현재 측정한 네 모델을 종합 정확도 / 확률 보정 오차 / 보기 순서 흔들림 순서로 읽으면 다음과 같습니다.

Perplexity Decider v1.1 27B: 81.7점 / 3.4%p / 6.9%
Jev 1.13: 78.6점 / 3.7%p / 6.5%
Microsoft-Decision-1: 77.5점 / 8.6%p / 5.6%
Perplexity Decider v1 27B: 77.2점 / 2.3%p / 14.9%

이 결과에서는 정확도 1위와 확률 보정 1위가 다릅니다. Perplexity v1.1은 종합 정확도가 가장 높지만, v1은 보정 오차가 더 작습니다. 또 Clef Flash의 보기 순서 흔들림은 4.0%로 낮아도 종합 정확도는 69.4점입니다. 정답·확률·순서 안정성을 따로 읽어야 하는 이유입니다.

속도와 비용도 현재 표에서 함께 비교할 수 있습니다. Perplexity v1.1은 1천 건 환산 6분 52초·$0.0046, Jev는 3분 45초·$0.022입니다. 대조군 GPT-6.1 Sol은 정확도 83.9점, 34분 25초·$0.826입니다. 이 측정에서는 Perplexity v1.1이 정확도 2.2점 차이로 약 5배 짧은 환산 시간과 약 180분의 1 기록 비용을 보였습니다. 이 배율은 해당 버전·문항·호출 조건의 비교 결과입니다.

측정 기록은 10월 3~10일에 걸쳐 있으며, 응답 버전과 호출 경로도 공개합니다. 예를 들어 Jev는 OpenRouter의 typesafe/jev-1.13-20260917, Perplexity v1.1은 Perplexity의 pplx-decider-v1.1-27b로 측정했습니다. 응답 시간에는 경유 시간이 포함되고, 비용은 실제 청구 기록을 기준으로 하며 일시 무료판은 유료 비용 비교에서 뺍니다. 공급사 판정 거부는 오답으로 처리합니다.

문항은 시드 20261003으로 층화 추출해 버전 안에서 고정하고, 세트별 문항 지문(SHA-256)과 기록된 원본 revision을 공개합니다. 모델을 추가해도 문항 판은 유지합니다. 따라서 이 평가를 출발점으로 삼아 한국어 업무·선호·라우팅 과제를 확장하는 실험이 자연스럽습니다.

공개 평가로 후보를 좁힌 뒤 우리 팀의 표현, 업무 기준, 문서 길이, 예외 사례를 넣어 다시 보아야 합니다. 고객의 “취소”가 결제 취소인지 예약 취소인지, “문제가 없다”가 확인 완료인지 불만의 완곡한 표현인지 같은 차이는 전체 평균 점수 하나로 드러나지 않습니다.

AIB의 네 가지 실험 후보

이 계보 조사에서 AIB가 검토해 볼 활용은 네 가지입니다. 아래는 활용·평가 제안이며, 이미 서비스에 적용했거나 학습을 마쳤다는 설명은 아닙니다.

1. 한국어 답변 선호 학습. 같은 질문에 대한 두 답변 중 사용자가 무엇을 골랐는지 활용하면 선호 판단을 학습할 가능성을 시험할 수 있습니다. 다만 선호는 객관적 정답이나 안전성 판정과 다릅니다. 동의·이용 조건을 확인한 자료에서 반복 투표, 질문·모델 편향, 노이즈를 점검한 뒤 학습 가능성을 검토해야 합니다.

2. 모델 라우터. 작업의 종류·길이·요구 품질과 예산·대기 시간 조건을 넣고 어느 모델에 보낼지 선택합니다. 싼 모델에 우선 보내고 어려운 경우 다른 모델이나 사람에게 넘기는 정책을 비교할 수 있습니다. 라우터 자체의 비용과 잘못 보낸 작업의 재처리 비용도 총비용에 넣어야 합니다.

3. 투표 품질 검토. 질문과 답변의 관련성, 비교 자료의 부족, 검토가 필요한 패턴을 Noul이나 Choice로 표시하는 실험입니다. 예외를 검토자에게 보내는 보조 신호로 먼저 평가해야 하며, 모델의 한 점수만으로 사용자의 신뢰도나 부정 참여를 단정하는 기능으로 확대해서는 안 됩니다.

4. 한국어 판단 벤치마크 확장. 기존 DecisionBench-KJ에 실제 업무 분류, 선택지 순서 변화, 선호·품질 판단과 모델 라우팅 과제를 더하는 실험입니다. 객관적인 정답이 있는 과제와 사람마다 선호가 다른 과제를 구분하면 어떤 판단을 잘하는지 더 분명히 볼 수 있습니다.

출발은 평가 가능한 작은 문제 하나입니다. 예를 들어 익명화하고 이용 범위를 확인한 과거 문의에서 담당자가 확정한 분류를 모아, 모델이 같은 기준으로 팀을 배정하는지 확인할 수 있습니다. 이 글의 제안은 비공개 투표를 추출하거나 학습에 쓰는 승인으로 이어지지 않습니다.

세 베이스의 한국어 학습 실험

직접 모델을 만드는 실험을 한다면 Qwen3.5-4B, Gemma-4-12B, EXAONE-4.0-1.2B를 후보로 비교해 볼 수 있습니다. 목적은 한국어 자료에 학습 가능한 판단 신호가 있는지 확인하는 것입니다.

세 모델은 크기가 다릅니다. 따라서 이 실험은 같은 크기의 베이스를 겨루는 순수한 우열 시험보다 서로 다른 배포 후보의 품질·자원 요구를 비교하는 실험으로 해석해야 합니다. EXAONE의 이용 조건처럼 실제 채택을 제한하는 요소도 결과와 함께 기록합니다.

비교 항목	맞추거나 기록할 조건	확인하려는 질문
과제·자료	같은 한국어 입력, 선택지, 판정 기준	동일한 업무에서 판단이 달라지는가?
자료 분할	학습·보정·검증·최종 테스트 분리	익숙한 질문을 외운 결과인가?
출력부	가능한 공통 원리, 모델별 구조 차이 기록	head 차이가 결과에 영향을 주는가?
학습 예산	데이터량·학습 횟수·seed·학습 파라미터 수	같은 이름의 LoRA가 실제로 같은 실험인가?
실행	체크포인트·정밀도·장치·배치·입력 길이	품질을 얻기 위해 어느 자원이 필요한가?
평가	정답률·선호 합치도·ECE·Brier·지연·비용	실제 자동 처리 정책에 쓸 수 있는가?

같은 원문이나 같은 질문의 변형이 학습과 테스트에 동시에 들어가지 않도록 묶어서 나눕니다. 선택지 순서를 바꾼 평가와 오류·기권 사례도 기록합니다. 모델별 구조가 다르면 같은 LoRA rank만 맞춰도 학습 파라미터 수가 달라질 수 있습니다.

head와 LoRA를 추가한 결과는 원래 모델의 logits를 그대로 읽은 결과와 비교해야 합니다. 그래야 복잡한 학습 절차가 실제로 도움이 되었는지 알 수 있습니다. 대표 업무에서 통하는 신호가 확인된 뒤에 자료와 모델 규모를 넓히는 순서가 현실적입니다.

실무 후보와 자동 처리 정책

지금 도입을 검토한다면 105개를 모두 시험할 필요는 없습니다. 입력 언어·길이·이미지나 음성의 필요 여부, 이용 조건, 운영 방식으로 먼저 거르고 조건이 비슷한 후보 두세 개를 비교하세요.

판정 기준을 적습니다. 입력 자료, 선택지, 정답 또는 사람이 검토할 조건을 정합니다. 선택지에 “판단 불가”나 사람 검토 경로가 필요한지도 확인합니다.
대표 사례와 어려운 예외를 모읍니다. 실제 담당자의 기준을 붙이고, 업무에 따라 오류의 손실이 큰 사례를 따로 봅니다.
출력과 비용을 같은 단위로 기록합니다. 정답률뿐 아니라 선택지 확률, 실패·기권, 입력 길이, 1,000건 비용과 응답 시간을 비교합니다.
임계값과 사람 검토 정책을 함께 정합니다. 같은 자동 처리 비중에서 어느 후보가 더 정확한지, 실수와 재처리에 드는 비용은 어느 쪽이 작은지 확인합니다.
운영 중 새 유형을 점검합니다. 문의 내용·문서 양식·선택지가 바뀌면 이전의 확률 보정과 임계값이 유지되는지 다시 봅니다.

우리 업무에서 필요한 것은 가장 높은 공개 순위인가요, 정해진 예산과 시간 안에서 신뢰할 수 있는 다음 행동인가요?

판단형 AI는 업무의 선택 단계를 분리해 평가할 수 있게 합니다. 베이스의 계보를 보면 후보를 좁힐 수 있고, 확률과 비용의 정의를 알면 비교가 쉬워집니다. 마지막 선택은 실제 업무 자료와 처리 정책으로 확인해야 합니다.

출처 및 참고 자료

판단 API와 확률 정의: Introduction - TypeSafe AI · Confidence - TypeSafe AI · Introducing System One Models & Jev - TypeSafe AI Blog

기업 출시와 구현: Microsoft-Decision-1: Our model for fast decision-making · Introducing Strands Decider 2B: a small, open source, decision model | Strands Agents · Open d1: Edge decision models for text, vision, and audio | Blog | Liquid AI

공개 모델 카드: StrandsAgents/strands-decider-2B-hobson-v19 · Hugging Face · perplexity-ai/pplx-decider-v1.1-27b · Hugging Face · Cloudflare/clef · Hugging Face · Cloudflare/clef-flash · Hugging Face

Encoder와 추론 방식: GLiNER2.5-Decide: An Open-Weight Model for Structured Decision Making · fastino/GLiNER2.5-Decide · Hugging Face · Introducing GLiDE: The First Thinking Decision Model

EXAONE와 비교 후보: LGAI-EXAONE/EXAONE-4.0-1.2B · Hugging Face · carrtesy/EXAONE-4.0-1.2B-JEV · Hugging Face · Qwen/Qwen3.5-4B-Base · Hugging Face · google/gemma-4-12B-it · Hugging Face

평가와 데이터: JevBench — AI decision model benchmark & leaderboard | Benchmark Heaven · JevBench dataset card & decision model results | Benchmark Heaven · Best AI Decision Models: Rankings, Cost & Use Cases | BenchLM.ai · JevBench: coherence tests for typed decision models

AIB의 한국어·일본어 평가와 이전 글: AIB DecisionBench-KJ: 한국어·일본어 판단형(Decision) AI 벤치마크 | AIB · Jev는 어떤 업무에서 GPT급일까? 판단형 AI 성능·비용 직접 비교

업무와 예산에 맞는 AI 선택

에이아이비(AIB)는 특정 AI 기업에 치우치지 않고 모델을 비교할 수 있도록 돕는 독립적인 AI 비교 플랫폼을 운영하는 신생 스타트업입니다. 업무에 필요한 품질과 비용을 함께 살펴, 정보와 예산의 차이가 AI 활용의 격차로 이어지지 않도록 돕고자 합니다.

반복 업무를 어디까지 자동화할지, 어떤 AI에 연결할지, 비용과 대기 시간을 어떻게 비교할지 고민이라면 함께 이야기해 주세요.

AIB에 AI 도입·비용·활용 상담 문의하기