Ollama에서 Jev 실행하기: 문장 대신 분류와 확률 받기

환불 문의와 결제 오류가 한 큐에 들어오면 담당자는 본문을 읽고 팀을 골라야 합니다. 이때 일반 채팅 모델에 “어느 팀이 맡아야 하는지 설명해 줘”라고 요청하면 자연스러운 문장은 얻지만, 뒤의 자동화가 그 문장을 다시 해석해야 합니다. 설명을 작성하는 일과 정해진 후보에서 하나를 고르는 일은 다른 작업입니다.

System One은 두 번째 작업에 맞춘 요청 방식입니다. 문의를 공통 state로 보내고, 질문마다 후보와 판단 지침을 정합니다. Ollama의 `/v1/systemone`은 2026년 9월 28일 공개된 0.35.0에서 추가됐습니다. 따라서 0.34.x 이하 설치본에서는 같은 주소가 동작한다고 기대하지 말고 먼저 버전을 확인하세요. 이 글의 예시는 결제 큐에 들어온 한 문의를 `billing` 또는 `technical`로 분류합니다.

시작 전에는 Ollama가 설치되어 있고 실행 중인지, 모델을 받을 디스크 공간과 모델 실행 메모리가 있는지 확인합니다. Bespoke Labs는 Nimble 9B의 원본 BF16¹ 가중치를 약 18GB로 안내합니다. 하지만 Ollama가 받는 `nimble` 태그의 파일은 포맷과 양자화²가 다를 수 있습니다. `ollama list`의 SIZE 열에서 받은 파일 크기를 확인하고, 그 수치를 실제 실행 메모리와 같다고 보지 마세요. Ollama 0.35.0 릴리스 자체는 특정 Mac이나 GPU³의 최소 메모리, 이 endpoint의 지연 시간을 보장하지 않습니다.

먼저 입력과 질문을 고정하면 실패를 구분하기 쉽습니다. 아래 요청은 “오늘 아침부터 결제 단계에서 500 오류가 난다”는 상황을 서버 오류 담당팀과 결제 담당팀 중 하나로 분류합니다. 후보 설명은 모델이 무엇을 구별해야 하는지 말해 주고, `instructions`는 현재 문의에서 판단할 질문을 지정합니다. 설명을 바꾸면 분류 경계도 달라질 수 있으니 실제 운영 기준과 같은 말을 넣으세요.

`choice` 질문에는 2개에서 26개까지 후보를 둘 수 있습니다. 결과에는 가장 높은 확률을 받은 후보 키와 모든 후보의 확률이 들어옵니다. `curl`은 서버에 한 번 요청한 뒤 완성된 JSON을 출력합니다. 이 API⁴는 스트리밍 응답을 제공하지 않으므로, 채팅 응답처럼 토큰⁵이 차례로 화면에 나타날 것으로 기대하지 마세요.

응답에서 `model`, `answers.route.choice`, `answers.route.probabilities`, `answers.route.confidence`, `usage`를 찾아봅니다. `choice`는 확률이 가장 높은 키입니다. 후보 확률은 입력에 적은 후보들 사이에서 정규화되어 합이 1이 되며, 후보가 빠져 있으면 그 누락은 확률 계산으로 복구되지 않습니다. 예를 들어 `billing`과 `technical`만 제시했다면 인사말이나 계정 탈취 신고도 그 둘 중 하나로 분류됩니다. 운영 큐에 예외 경로가 필요하다면 별도 규칙이나 후보를 설계해야 합니다.

담당 팀 하나를 고르는 상황에서는 `choice`를 씁니다. “긴급 장애인가?”처럼 예/아니오에 가까운 판단은 `noul`로 보낼 수 있고, 기본 후보는 false와 true입니다. 필요하면 두 후보의 뜻을 `criteria`에 문자열로 적습니다. 답은 불리언 값이 아니라 true일 확률인 숫자이므로, 애플리케이션에서 기준을 정해 참/거짓으로 바꿔야 합니다.

우선순위처럼 여러 단계 중 하나를 고르고 싶다면 `score`를 씁니다. 기준 배열은 낮은 단계부터 높은 단계 순으로 둡니다. 응답의 `score`는 0부터 시작하는 후보 인덱스에 확률을 곱해 더한 값이라 정수가 아닐 수 있습니다. 예를 들어 0, 1, 2단계 확률이 각각 0.2, 0.3, 0.5라면 점수는 `0×0.2 + 1×0.3 + 2×0.5 = 1.3`입니다. 1.3은 네 번째 범주가 아니며, 등급을 결정하려면 서비스가 별도의 경계 규칙을 정해야 합니다.

한 요청에 질문을 여러 개 넣으면 각각 같은 state를 기준으로 따로 평가됩니다. 첫 질문의 답이 다음 질문의 입력으로 자동 전달되지는 않습니다. 질문을 묶으면 네트워크 호출 하나로 여러 필드를 받을 수 있지만, 이를 여러 질문 사이의 대화나 의존 관계로 생각해서는 안 됩니다. 명령 전송 전에 질문 이름은 빈 문자열이 아닌 고유한 키로 정하고, 후보 수는 2~26개 범위인지 살펴보세요.

확률이 한 후보에 몰리면 confidence도 높아질 수 있습니다. 이 값은 후보 분포의 엔트로피를 기준으로 계산한 집중도이며, 정답을 맞힐 확률로 보정된 값이 아닙니다. 모델이 모르는 유형의 문의를 자신 있게 잘못 분류해도 confidence가 높게 나올 수 있습니다. 따라서 “confidence가 0.9보다 높으면 정답” 같은 규칙은 검증 자료 없이 두지 마세요.

운영에 넣기 전에는 과거 문의 중 대표 유형과 예외를 포함한 검증 묶음을 만듭니다. 각 문의의 실제 담당팀을 사람이 확인하고, 같은 state와 같은 후보 설명을 사용해 반복 실행합니다. 전체 정확도 하나만 보지 말고 결제팀 문의가 기술팀으로 넘어가는 비율과, 기술 장애가 결제 큐에 묻히는 비율을 따로 셉니다. 어느 오류가 더 큰 비용을 만드는지에 따라 자동 배정, 사람이 확인할 구간, 재질문 경로가 달라집니다.

예를 들어 검증용 문의가 100건이라면, 100건 중 몇 건을 맞혔는지와 함께 실제 결제 문의 40건 중 잘못 보낸 건수처럼 분모를 나눠 기록합니다. 이 숫자는 설명을 위한 계산 예시이지 모델의 측정 결과가 아닙니다. 실제 정확도나 지연값을 본문에 쓰려면 데이터셋, 모델 태그와 revision, 실행 장비, Ollama 버전, 반복 수를 직접 기록해야 합니다. Ollama 0.35.0 릴리스는 Nimble의 `/v1/systemone` 처리 성능 비교를 제공하지 않습니다.

출력이 이상하면 먼저 endpoint 주소와 Ollama 버전을 확인하고, 다음으로 모델 태그가 System One 호환 Nimble 또는 Tev인지 확인합니다. 요청의 `type`은 choice, noul, score 중 하나여야 하며 질문별 후보는 지원 범위 안에 있어야 합니다. 이 구현은 간단한 문자열 후보와 기준 배열을 사용하세요. TypeSafe의 참조 API가 허용하는 모든 복합 후보 설명 형식이 Ollama 0.35.0에서도 그대로 지원된다고 가정하지 말고, Ollama 요청에서 실제로 받아들이는 JSON을 기준으로 시작합니다.

System One은 선택과 점수화에 맞고, 사용자에게 이유를 설명하거나 환불 안내 문장을 작성하는 도구는 아닙니다. 한 문의에서 팀을 고른 뒤 고객에게 보낼 답변이 필요하다면 분류 결과를 애플리케이션 로직으로 넘긴 다음 별도의 채팅 요청을 사용할 수 있습니다. 두 요청이 다른 역할을 한다는 점을 코드에서 분리하면 자동 분류의 후보 오류와 답변 생성의 문체 문제를 따로 점검할 수 있습니다.

반대로 문의를 담당자가 읽을 필요가 없고 모든 유형이 이미 규칙으로 구별된다면 모델을 추가할 이유가 없을 수도 있습니다. 규칙으로 처리할 수 없는 표현 변형이 실제 검증 묶음에서 반복되고, 그때 모델 분류가 사람의 업무를 줄이는지 확인한 뒤 도입하세요. 처음에는 자동 전달 대신 결과만 저장하고 사람이 판단과 비교하는 shadow mode가 안전한 시작점입니다.

마지막으로 속도를 재려면 같은 요청을 고정하고 모델을 이미 메모리에 올린 warm 실행과 처음 로드하는 cold 실행을 나누세요. 요청 한 건의 벽시계 지연은 분류 작업에서 직접 의미가 있지만, 일반 채팅의 출력 tokens/second만으로 이 endpoint와 비교할 수 없습니다. 준비 실행 후 같은 표본을 세 번 이상 보내 중앙값과 오류 건수를 함께 기록하면, 모델 교체나 후보 설명 수정이 실제 업무에 어떤 차이를 만들었는지 확인할 수 있습니다.

이 글의 API 경로와 필드 의미는 Ollama의 0.35.0 릴리스, Ollama Python 클라이언트의 System One 설명, 현재 Ollama OpenAPI 정의를 기준으로 정리했습니다. 실행 가능 모델과 후보 타입은 버전이 바뀌면 달라질 수 있으므로 적용 전에 설치한 버전의 공식 문서를 확인하세요.