디시전 모델은 글을 쓰지 않고 정해진 선택지 가운데 하나를 고르거나 점수·확률만 돌려주는 AI 모델로, 답을 토큰 하나씩 이어 쓰는 대신 허용된 답 전체를 한 번에 채점하기 때문에 결과가 늘 스키마 안의 값으로 나온다. 에이전트가 라우팅, 도구 선택, 분류, 가드레일처럼 빠르고 정형화된 판단을 내려야 할 때 LLM 대신 쓴다.
| 구분 | 일반 LLM | 디시전 모델 |
|---|---|---|
| 출력 | 자유로운 텍스트 | 선택지·점수·확률 |
| 생성 방식 | 토큰을 하나씩 | 한 번에 채점 |
| 잘 맞는 일 | 추론, 코딩, 글쓰기 | 분류, 라우팅, 검증 |
입력으로는 '상태'(텍스트나 JSON)와 코드로 정의한 질문을 받는다. 설명이나 문장은 만들지 않는다.
Jev 기준으로 질문 유형은 세 가지다. 질문과 선택지 설명을 코드로 정의해 API로 보내면, 소프트웨어가 바로 쓸 수 있는 값이 돌아온다.
| 유형 | 돌려주는 값 | 이럴 때 쓴다 |
|---|---|---|
| Choice | 선택지별 확률 + 확신도 | 문의를 담당 팀에 배정 |
| Score | 2~10단계 척도 위 위치 | 티켓 우선순위 매기기 |
| Noul | 0~1 사이 확률 하나 | "이 입력이 스팸인가?" |
보정된 확률이 함께 나오는 게 핵심이다. 확신도가 높으면 자동으로 처리하고, 애매하면 사람에게 검토를 맡기거나 다시 시도하는 제어 장치로 쓸 수 있다. 예를 들어 보험 청구라면 디시전 모델이 복잡도를 분류하고 빠진 정보를 표시한다. 서류 검토는 LLM이 하고, 분쟁 건은 담당자가 맡는다.
응답이 수백 밀리초 안에 오기 때문에 '상태 읽기 → 판단 → 실행 → 다시 판단'을 반복하는 루프 안에서 여러 번 불러도 된다. 입력 분류, 모델 라우팅, 도구 선택, 인자 검사, 출력 채점은 디시전 모델에게 맡긴다. 복잡한 분석·계획·추론만 고성능 LLM에게 넘기면 토큰 비용과 지연이 함께 줄어든다. Jev 같은 상용 API 말고도 가중치를 공개한 Laya와 AWS 스트랜즈 디사이더가 있어 직접 띄워 쓸 수도 있다.
판단의 질은 넘겨준 상태에 달려 있다. 문서를 통째로 넣기보다 질문과 관련된 필드만 골라 보내야 정확해진다. 또 예외 처리를 이미 코드로 다 해 둔 업무라면 LLM을 쓸 때와 차이가 크지 않다는 사용자 평가도 있다. 빠른 판단과 추가 추론 중 무엇이 필요한지 애매한 문제를 위해, 불확실할 때만 더 생각하는 '싱킹 디시전 모델'도 나와 있다.
가장 흔한 건 LLM을 부르기 전후의 짧은 판단을 디시전 모델에 맡기는 방식이다. 들어온 요청을 먼저 분류해 어디로 보낼지 정하고, 나온 결과가 기준을 통과하는지 채점한 뒤, 확신도가 낮은 건만 사람이나 큰 모델로 넘긴다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 고객 문의 처리 | Choice로 담당 팀을 배정하고 Score로 우선순위를 매긴 뒤, 확신도가 낮은 건만 사람에게 |
| 에이전트 루프 | 매 단계 어떤 도구·모델을 쓸지 고르고 인자를 검사, 복잡한 계획만 고성능 LLM에 |
| 입력·출력 가드레일 | Noul로 스팸·위험 입력 확률을 받아 차단 여부를 정하고, LLM 답변을 기준에 맞춰 채점 |
| 서류 심사 흐름 | 복잡도 분류와 누락 정보 표시는 디시전 모델, 서류 검토는 LLM, 분쟁 건은 담당자에게 |