예/아니오, 선택, 등급이 하나의 언어로 충분한가?
Noul, Choice, Score는 코드를 위한 언어입니다. 이 글은 경비 보고서로 세 질문이 어떻게 갈라지는지, 그리고 이 언어가 언제 충분하지 않은지를 보여 줍니다.
공동 작성자: folkbench.com (Folkbench는 AI API, 모델 서비스, 관련 사이트를 위한 검증 가능한 평가·선택 플랫폼입니다. 공개된 서비스 정보, 가격, 가용성, 지연, 증거 구간을 바탕으로 사용자가 경로를 비교하고 고를 수 있게 합니다.)
이 시리즈는 열 편입니다:
- JEV - 관절에는 뇌가 필요 없습니다
- JEV - 채팅하지 못하는 Jev가 Agent에 맞는 이유
- JEV - “환각할 수 없다”는 말이 어디까지인가
- JEV - 예/아니오, 선택, 등급이 하나의 언어로 충분한가?
- JEV - 연구소는 만들 수 있습니다. 그래도 만들지 않을 수 있습니다.
- JEV - 내가 돌려 본 두 demo
- JEV - 사람은 루프의 가운데에서 가장자리로 물러납니다
- JEV - 그 선을 넘으면, 나는 누가 더 똑똑한지 더 이상 가리지 못합니다
- JEV - 어떤 질문은 여기에 속하지 않습니다
- JEV - 덜어 낸 모델, 스위트, 그리고 말하지 않는 하나
이 언어가 충분한지는, 그것이 무엇을 말하기를 바라는지에 달렸습니다. 닫힌 질문 세 가지는 속도를 사고, 조합할 수 있음도 삽니다. 대가는, 펼쳐야 하는 것을 말할 수 없다는 점입니다. 이것은 코드를 위한 언어입니다. 사람이 읽으라고 있는 것이 아닙니다.
문서와 평가 사이트는 같은 방식으로 나눕니다. Noul, Choice, Score입니다. 페이지에 네 번째 종류는 없습니다.
문서 안의 세 종류
Noul은 예 또는 아니오만 묻습니다. 확률을 돌려줍니다. 문서에서 그 수는 0에서 1까지입니다. 1에 가까우면 확신 있는 예입니다. 0에 가까우면 확신 있는 아니오입니다. 0.5 근처에서 멈추면, 양쪽이 똑같이 가능하다는 뜻일 뿐입니다. “중간 정도”가 아닙니다. 문서는 이 함정에 이름을 붙입니다. 누군가 Python을 잘하는지 물으면, 0.5는 중간 수준이 아닙니다. 정말로 수준을 재려면 Score로 바꾸고, 각 등급이 어떻게 보이는지 적습니다. Noul은 별도의 확신도도 붙이지 않습니다. 확률이 신호입니다.
Choice는 미리 고정한 집합에서 항목 하나를 고릅니다. 돌아오는 것은 고른 항목과, 분포 전체와 확신도입니다. 확신도는 분포가 뾰족한지를 봅니다. 확률이 퍼져 있으면 확신도는 낮고, 코드는 이 질문이 불안정하다는 것을 압니다. Jev에서 이 질문의 기수 상한은 255입니다. 그것을 넘으면 Jev는 두 단계로 갑니다. 두 단계는 먼저 따로 점수를 매기고, 그다음 명시적인 선택을 한다는 뜻입니다. 가끔 조금 느립니다. 느린 것은 단계가 하나 더 있기 때문이지, 같은 좁은 질문이 갑자기 비싸진 것이 아닙니다.
Score는 눈금 위의 등급입니다. 쓸 때는 2에서 10등급의 순서가 있는 눈금입니다. 문서는 최소 두 등급이라고 하고, 인터페이스는 최대 열을 받습니다. 등급은 맞춰 볼 수 있는 상황으로 적어야 합니다. “조금 높다”나 “괜찮다”만 적으면, 모델에는 맞출 것이 없습니다. 점수는 두 등급 사이에 떨어질 수 있습니다. 그 수는 각 등급의 위치에 그 확률을 곱한 것의 합입니다. 두 등급 사이의 소수는 정상입니다. 계산이 깨진 것이 아닙니다. 점수와 함께, 등급 위의 분포와 확신도를 돌려줍니다. 같은 점수가 가운데 등급에 전부 눌린 것일 수도 있고, 양쪽 끝으로 갈라진 것일 수도 있습니다. 점수만 보면 그것을 같은 것으로 취급하게 됩니다. 분포와 확신도를 같이 읽습니다.
세 답 모두, 미리 준 칸을 벗어날 수 없습니다. 같은 자료 위의 질문은 서로 독립입니다. 하나를 더하거나 빼도 다른 질문은 바뀌지 않습니다. 판단이 여러 가지에 함께 달려 있으면, 따로 묻고 가중치는 코드에 남깁니다. 나중에 정책을 조정할 때는 이 숫자를 바꿉니다. prompt 전체를 다시 쓰지 않습니다.
경비 보고서를 쪼개 보면
공식 평가 페이지는 경비 보고서를 장난감으로 씁니다. 왼쪽은 사람이 쓴 문단이고, 팀이 적어 둘 법한 정책입니다. 모든 보고서에는 영수증이 있어야 합니다. 영수증을 읽을 수 없으면 직원에게 다른 것을 요청합니다. 그다음 지출이 식사인지, 출장인지, 장비인지를 봅니다. 식사가 $75를 넘고 설명이 영수증과 맞지 않으면, 관리자가 서명해야 합니다. 나머지 보고서는 승인된 것으로 처리합니다.
오른쪽에서 같은 문단은 흐름으로 쪼개집니다. 정책의 각 문장은 질문 하나이거나, 코드 규칙 하나입니다. 영수증을 읽을 수 있는지는 예/아니오입니다. 읽을 수 없으면 코드가 새 것을 요청하고, 그 단계는 모델에게 다시 묻지 않습니다. 범주는 단일 선택을 쓰고, 선택지는 식사, 출장, 또는 장비입니다. 금액이 $75를 넘는지는 코드가 스스로 비교합니다. 설명이 영수증과 맞지 않는다는 반 문장만, 모델에게 한 번 더 물어야 합니다. 금액과 함께 그것이 관리자의 서명을 정합니다. 관리자 서명이 필요 없는 보고서는 코드가 승인으로 처리합니다. 모델은 여기서 코멘트를 쓰지 않습니다.
평가 페이지의 방향은 한 문장입니다. 구조는 언제나 큰 prompt 하나보다 낫습니다. 예시 흐름 네 개를 평균하면, 워크플로 위의 모든 모델이 정책 전체를 prompt 하나로 둔 것보다 정확도가 더 높고, 비용과 시간은 더 낮습니다. prompt 쪽은 정책 전체를 넘기고, 모델이 답 하나 안에서 논리를 걷게 합니다. 워크플로 쪽은 규칙으로 적을 수 있는 것은 코드에 주고, 좁은 판단만 질문으로 남깁니다.
가장 안정적인 실제 흐름은 보통 큰 질문 하나가 아닙니다. 서로 독립인 좁은 질문이 많습니다. 행동은 확률에 달리고, 이산 라벨 하나에만 달리지 않습니다. 범주는 정해진 것처럼 보여도, 다른 선택지가 아직 확률의 몫을 쥐고 있을 수 있습니다. 코드는 적어 둔 임계값에서 한 걸음 더 갈 수 있고, 분포를 버릴 필요가 없습니다. 흐름 밖에서는 여전히 분기 하나입니다. 가운데 층은 도메인 공학입니다. 이번에 어느 질문이 쓰이지 않는지, 어느 숫자가 선을 넘는지는 이 업무를 위해 적어 두고, 매번 같은 방식으로 돌려야 합니다. 좁은 질문의 답이 코드에 들어오면, 가중치와 임계값은 이 층에서 정해집니다.
문자열 생성을 포기한 뒤
Jev는 문자열 생성을 포기하고, 그 대신 병렬 샘플링을 받습니다. 한 요청 안의 질문은 함께 계산됩니다. 모든 출력이 한 번에 나옵니다. 토큰마다 나오지 않습니다. 채팅 모델은 토큰을 하나하나 이어 자라야 하고, 각각이 앞의 것을 봅니다. 여기에는 글자마다의 단계가 없습니다. 평범한 좁은 질문을 몇 개 더해도, 시간은 거의 함께 오르지 않습니다. 추가 비용은 주로 질문 자신의 토큰입니다.
공식 가격은 채팅 인터페이스의 가격이 아닙니다. 입력은 100만 토큰당 $0.042입니다. 출력은 FREE입니다. 토큰으로 과금되는, 길게 생성된 단어의 흐름이 없으면 출력은 과금되지 않습니다. 지연은 70–500밀리초에 떨어집니다. 그 범위는 호출 사슬을 위한 것이지, 채팅 상자 안에서 기다리는 것을 위한 것이 아닙니다.
반환값은 곧장 코드로 갑니다. Noul의 확률은 if에 들어갈 수 있습니다. 라우팅은 Choice의 라벨을 씁니다. 채점 임계값은 Score의 위치를 씁니다. 먼저 파싱하지 않습니다. 채팅 모델이 Markdown 한 편을 돌려주면, 단어를 먼저 쪼개야 하고, 문장 하나가 더 있으면 형식이 휘어서 나머지가 이어지지 않을 수 있습니다. 세 질문은 그 텍스트를 돌려주지 않습니다. Jev가 그것을 생성하지 않기 때문입니다.
이 보고서를 왜 거절했는지 설명하는 것은 세 질문에 담기지 않고, 사과와 협상도 마찬가지입니다. 사람이 읽도록 쓴 이유도 반환값에 없습니다. 그것들은 말할 수 있는 모델로 갑니다. Jev는 판단에서 멈춥니다.
충분하지 않을 때의 경우는 구체적입니다. 선택지가 열린 세계의 이름이면, 회사 이름과 제품 이름이 계속 나타나고 집합을 미리 고정할 수 없습니다. 255는 기수 상한이지, 무한한 목록이 아닙니다. 이유가 출처의 문장을 인용해야 할 때, 넘길 그런 문장은 없습니다. 사용자가 사람의 문장을 기다릴 때, 인터페이스가 원하는 것은 읽을 수 있는 말입니다. 그때 Jev를 억지로 쓰는 것은 관절을 입으로 취급하는 일입니다.
정책을 예/아니오, 단일 선택, 등급으로 닫을 수 있으면, 뒤따르는 것은 분기이고 판단은 같은 코드로 다시 조립됩니다. 원하는 것이 속도와 이런 종류의 조합 가능성이면, 충분합니다. 펼쳐야 하는 것은 말할 수 없습니다. 속도와 조합 가능성은 그 교환이 사는 것입니다.
출처
- https://typesafe.ai/blog/introducing-system-one-models-and-jev
- https://evals.typesafe.ai/
- https://docs.typesafe.ai/primitives