Jev와 LLM

같은 판단, 두 가지 방식

지원 티켓 하나를 네 개의 큐 중 하나로 보냅니다. 각 방식이 코드로서 실제로 무엇을 요구하는지 보세요.

const res = await llm.chat({
  messages: [{ role: "user", content:
    `Route this ticket. Reply with JSON: {"queue": "Billing"|"Technical"|"Account"|"Sales"}
     Ticket: ${ticket}` }],
  response_format: { type: "json_object" }
});

let queue;
try {
  queue = JSON.parse(res.content).queue;        // may not be JSON
} catch {
  return retry();                               // ...so there is a retry
}
if (!QUEUES.includes(queue)) return retry();    // may be a queue you never had
// and no idea how close the call was

const { answers } = await jev.systemOne({
  state: ticket,
  model: "jev-latest",
  questions: { queue: { type: "choice", instructions:
    "Which team should own this ticket?", criteria: QUEUES } }
});

const { choice, probabilities, confidence } = answers.queue;
// choice is one of QUEUES. It cannot be anything else.
if (confidence < 0.7) return humanReview(ticket, probabilities);
route(choice);

재시도 루프가 결정적인 단서입니다. 첫 번째 버전에 그것이 있는 이유는 답이 텍스트로 도착해 파싱되지 않을 수도 있고, 파싱되더라도 목록에 없던 큐가 나올 수 있기 때문입니다. 두 번째 버전에는 그것이 있을 자리가 없습니다. 구성상 답은 반드시 QUEUES 중 하나입니다. 대신 들어서는 것은 전혀 다른 분기 — 출력이 망가졌을 때가 아니라 모델이 확신하지 못할 때 작동하는 분기입니다.

두 번째 버전이 볼 수 있는 것

그 티켓을 실제로 Jev에 돌린 결과입니다. 승자는 놀랍지 않습니다. 맨 라벨이었다면 버렸을 부분은 차점자 쪽입니다.

기술이 87%로 이기지만 계정이 13%를 쥐고 있습니다 — 그리고 이것은 있어야 마땅한 이견입니다. SSO 장애는 실제로 둘의 경계에 걸쳐 있으니까요. 맨 라벨만 있었다면 이를 감췄을 것입니다. 잘못 보내는 데 비용이 따른다면, 13%가 바로 임계값을 둘 숫자입니다.

나란히 보기

보내는 것

Jev

하나의 state와 타입 있는 질문들의 맵.

LLM

프롬프트. 대개 스키마와 규칙을 산문으로 싣고 있습니다.

돌아오는 것

Jev

질문마다 타입 있는 답 하나, 선택지마다 확률.

LLM

텍스트. 정중히 요청했고 그 모드를 지원한다면 JSON.

다음 한 줄

Jev

여러분의 값 중 하나일 수밖에 없는 값에 대한 switch.

LLM

파싱하고, 검증하고, 둘 중 하나가 실패했을 때의 분기.

실패하는 방식

Jev

텍스트를 잘못 읽을 수는 있습니다. 정의하지 않은 모양을 돌려줄 수는 없습니다.

LLM

모양에서도 틀릴 수 있습니다 — 빠진 필드, 나열한 적 없는 라벨, JSON을 감싼 산문.

열 가지를 물을 때

Jev

열 개 질문을 한 번의 요청으로, state에 대해 병렬 평가.

LLM

빽빽한 프롬프트 하나, 아니면 열 번의 호출.

불확실성

Jev

모든 Choice와 Score에 분포와 확신도.

LLM

텍스트가 자기 확신에 대해 주장하는 것, 그뿐.

숫자

TypeSafe가 공개한 것으로, 벤더 자신의 수치이지 우리의 측정값이 아닙니다.

우리가 측정할 수 있는 것: 이 사이트를 통해 이뤄진 14회의 실행에서 왕복 시간의 중앙값은 329ms입니다 — 게다가 그 대부분은 한 문항이 아니라 아홉 문항을 실은 요청이었습니다.

LLM이 맞는 도구일 때

필요한 것이 언어라면 대개 그렇습니다. Jev에는 설명할 의견도, 할 말도 없습니다.

• 산문이 필요할 때 — 답장, 요약, 커밋 메시지, 판단 자체가 아니라 판단에 대한 설명.
• 코드나 계획을 써야 할 때, 또는 호출 전에는 답의 집합을 알 수 없는 열린 작업 전반.
• 가능한 답의 집합이 정말로 무한할 때. 임의의 이름을 뽑아내는 것은 255개 선택지에 대한 Choice가 아닙니다.
• 따져 볼 수 있는 추론의 사슬이 필요할 때. Jev가 돌려주는 것은 판단이지 그 뒤의 단계가 아닙니다.
• 양이 적고 형태가 느슨할 때. 하루 두 번 도는 재시도 루프는 설계로 없앨 만한 것이 아닙니다.

이 둘은 다투기보다 맞물릴 때 더 좋습니다. TypeSafe 자신의 정리도, 빠른 구조화된 판단은 시스템 1이 맡고 그 뒤에 보통의 모델을 시스템 2로 두라는 것입니다 — Noul로 입력을 거르고, Choice로 보내고, 살아남은 것을 정말 쓸 줄 아는 모델에 넘기세요.

이어서 읽기