Jev vs Agents: 소프트웨어에 결정 원시 통합하기

지난 일주일 동안 동굴 속에 숨어 지낸 게 아니라면, @typesafeai의 Jev를 봤을 것이다.

https://x.com/CompleteSkeptic/status/2099925682726002904

이들은 자신의 모델을 다음과 같이 설명한다:

소프트웨어가 직접 사용할 수 있는 빠르고 구조화된 의사결정을 내리도록 설계된 AI 모델 클래스입니다. System One 모델은
state를 평가하고
타입이 지정된 답변과 확률을 반환합니다.

TypeSafe의 벤치마크에 따르면, Jev는 LLM보다 20-200배 빠르고 40-400배 저렴하다.

하지만 왜 이것이 중요할까? 우리는 이전에 분류기(classifier)를 훈련해 본 적이 있다(스마트폰의 자동 수정, Gmail 필터링 등). 하지만 트위터에서 Jev는 특별한 무언가로 여겨진다.

이 글에서는 Jev가 무엇인지, 왜 존재하는지, 그리고 프로덕션 시스템에 어떻게 도입할 수 있는지 알려주고자 한다.

Jev는 정확히 무엇인가?

"Jev를 프론티어 인텔리전스 함수 호출로 생각하세요. 비구조화된 상태가 입력되면 타입이 지정된 확률적 의사결정이 출력됩니다." - TypeSafe

Jev는 3가지 기본 요소(primitives)를 제공한다: Choice, Score, 그리고 Noul.

Choice는 정의된 집합(최대 255개) 중 하나의 옵션을 선택하는 질문 유형으로, 답변에는 선택된 옵션, 각 옵션의 확률 및 신뢰도가 포함된다.
Score는 콘텐츠 순서가 지정된 서술적 수준을 기준으로 평가하며, 답변에는 점수, 각 수준의 확률 및 신뢰도가 포함된다.
Noul은 모델에게 예/아니오 질문에 대한 평가를 요청하고, 답변이 '예'일 확률을 반환하도록 한다.

고객 지원 사용 사례에 대한 샘플 입력 및 출력은 다음과 같다:

json

1// Input
2{
3  "model": "jev-latest",
4  "state": "Hi, I was charged twice for my monthly subscription. Could you refund the extra charge? My account is working fine.",
5  "questions": {
6    "department": {
7      "type": "choice",
8      "instructions": "Which team should handle this message?",
9      "criteria": {
10        "billing": "Charges, payments, subscriptions, and refunds",
11        "technical": "Bugs, errors, and broken features",
12        "account": "Login, passwords, and account access"
13      }
14    },
15    "requests_refund": {
16      "type": "noul",
17      "instructions": "Is the customer explicitly requesting a refund?"
18    },
19    "frustration": {
20      "type": "score",
21      "instructions": "How frustrated does the customer sound?",
22      "criteria": [
23        "Calm: politely describes the issue without expressing frustration",
24        "Frustrated: expresses annoyance or dissatisfaction",
25        "Very frustrated: expresses strong anger or threatens to leave"
26      ]
27    }
28  }
29}
30// Output
31{
32  "model": "jev-1.13.0",
33  "answers": {
34    "department": {
35      "type": "choice",
36      "choice": "billing",
37      "confidence": 1,
38      "probabilities": {
39        "technical": 0,
40        "account": 0,
41        "billing": 1
42      }
43    },
44    "requests_refund": {
45      "type": "noul",
46      "noul": 0.99
47    },
48    "frustration": {
49      "type": "score",
50      "score": 0,
51      "legend": {
52        "0": "Calm: politely describes the issue without expressing frustration",
53        "1": "Frustrated: expresses annoyance or dissatisfaction",
54        "2": "Very frustrated: expresses strong anger or threatens to leave"
55      },
56      "confidence": 1,
57      "probabilities": {
58        "0": 1,
59        "1": 0,
60        "2": 0
61      }
62    }
63  },
64  "usage": {
65    "input_tokens": 442,
66    "output_tokens": 72
67  },
68  "request_id": "playground_12bbfa4198be5ca4de9818a45c0906a2055",
69  "evaluation_time_ms": 163.01120699790772
70}

상태(state)와 질문(questions)이 출력값을 위해 어떻게 함께 작동하는지 더 잘 이해하려면 그들의 대시보드 온보딩을 살펴보는 것을 추천한다.

이건 그냥 분류기가 아닌가?

글쎄, 맞기도 하고 틀리기도 하다. 마치 LLM과 분류기가 아이를 낳은 것과 비슷하다.

전통적인 분류기는 대량 처리 및 고정된 분류 체계(taxonomy) 작업에 적합하다. 예를 들어 LeNet-5가 이미지 속 숫자를 식별하는 경우를 생각해 보라. 그러나 분류기는 보통 초특화되어 있고 도메인 종속적이다. LLM은 시퀀스 생성에 능숙하다. 유연하고 런타임에 정의되는 개방형(open-ended) 작업에 훌륭하지만, 분류기보다 느리고(분류기 대비), 비용이 더 많이 들며 예측 가능성이 낮다.

Jev는 "분류를 위한 파운데이션 모델"로, LLM의 자연어 유연성과 분류기의 제약된 확률적 출력을 결합한다. 새로운 모델을 훈련하지 않고도 다양한 작업을 수행할 수 있으며, 동시에 여러 다른 도메인(코드, 텍스트, 로그, UI 상태, 이벤트 등)에서의 전문성을 유지할 수 있다. 또한 Jev는 병렬로 출력을 생성할 수 있어 순차적 생성에만 제한된 LLM보다 훨씬 빠르다.

요약하자면, 정말 똑똑하고 일반화 가능한 분류기이다.

Jev는 왜 존재하는가?

TypeSafe의 CEO이자 공동 창업자인 Diogo Almeida는 OpenAI에서 RLHF(human feedback 기반 강화 학습) 및 ChatGPT 제품 개발을 돕는 데 시간을 보냈다. RLHF는 LLM이 지시문과 프롬프트를 따르는 데 매우 뛰어나도록 훈련할 수 있게 해주었으며, 이는 그들의 자기회귀적(autoregressive) 특성과 일치한다.

그 후 그는 OpenAI를 떠나 TypeSafe를 설립하고 에이전트가 아닌 AI 기반 소프트웨어를 가능하게 하는 다른 종류의 모델을 훈련했다. Jev는 RLCD(calibrated decisions 기반 강화 학습)로 훈련되는데, 이는 연구 용어로 모델이 답변보다는 신뢰도와 확률을 출력하는 데 매우 뛰어나도록 훈련한다는 의미이다.

TypeSafe는 소프트웨어가 지능적이어야 한다고 믿는다. 에이전트는 소프트웨어가 역사적으로 작동했던 방식에 자연스럽게 확산되지 않으며, human-in-the-loop 방식은 지능적이고 자율적인 소프트웨어를 어렵게 만든다. Jev는 소프트웨어 시스템 내에서 조합 가능하고 신뢰할 수 있는 기본 요소로서 지능을 향한 한 걸음이다.

이는 완전히 새로운 아이디어는 아니다. 2017년 연구자들은 강한 예측 정확도가 신뢰할 수 있는 추정치를 의미하지는 않는다(따라서 LLM은 여기서 완벽한 해결책이 아니다)는 사실을 발견했다.

RLHF 대신 RLCD를 사용하는 이유는?

RLHF의 문제는 인간이 원하는 것이 항상 객관적으로 옳지는 않다는 점이다. 우리가 특정 형식의 특정 답변을 선호한다고 해서 모델이 더 지능적이 되는 것은 아니며, 단지 다루기 더 쉬워질 뿐이다.

또한 모드 붕괴(mode collapse)를 유발한다. RLHF는 LLM이 때로는 여러 경로가 모두 '정답'일 수 있음에도 불구하고 단일 답변으로 수렴하도록 만든다.

"출력값이 사람에게 매력적이라고 해서无人值守(unattended) 자동화에 충분히 신뢰할 수 있는 것은 아닙니다. 인간의 선호와 기계의 신뢰성은 서로 다른 최적화 목표입니다."

Jev 문서의 모드 붕괴

Jev는 에이전트를 구축하기 위한 것이 아니었다

타임라인에서 보이는 것들과 달리, Jev는 독립형 에이전트로서는 그리 좋지 않다. 우리는 Jev 단독 버전과 LLM + Jev 버전을 모두 만들어 보려고 시도했다.

https://x.com/kylejeong/status/2100622054945095934

솔직히 말해서, Jev 에이전트는 멋진 데모를 만들기는 한다. Jev를 사용하여 번개처럼 빠르게 에이전트 작업을 수행하는 데모들이 쏟아지고 있다. 하지만 최고의 데모조차도 프로덕션에 배포할 준비가 되지는 않았다.

Jev 같은 모델은 AI 기반 소프트웨어를 위한 것이며, 결정론적 코드(deterministic code)로 구성된 의사결정을 내리는 데 도움을 줄 수 있다. 추론이나 생성 기능이 없으므로 이를 독립형 에이전트로 사용하는 것은 순수한 무지일 뿐이다.

AI 기반 소프트웨어

Jev를 독립형 컴퓨터 사용(computer use) 에이전트로 두는 대신, 고객 지원 라우팅, 인보이스 처리, 보안 알림 및 트리아지(triaging), 또는 에이전트 모니터링 도구로 사용해야 한다.

숫자들

첫 번째 모델인 Jev 1.13.0의 비용은 입력 토큰당 $42/btok(또는 $0.042/mtok)이며 출력 토큰은 무료이다. 참고로 Fable 5.1은 입력 토큰당 $10/mtok인데, 이는 $10,000 / Btok에 해당한다. 일반적인 엔터프라이즈 워크로드의 입력-출력 토큰 비율은 3:1 또는 4:1이므로, Fable의 비용은 약 $20,000/Btok(출력 $50/mtok 기준)으로 올라간다.

컨텍스트 윈도우는 요청당 64k 토큰이며, 상태(state)와 가장 긴 질문은 32k 토큰 내에 들어가야 한다.

그러나 내부 벤치마크에서는 OpenAI, Anthropic, Deepseek(Fireworks를 통한 추론)의 모든 모델보다 정확도/비용 및 정확도/속도 측면에서 우수한 성능을 보인다.

정확도/비용

말은 충분하다, 어떻게 사용하는가?

지금쯤이면 Jev에 대한 충분한 이해를 바탕으로 현재 진행 중인 작업에 대해 몇 가지 사용 사례를 떠올렸을 것이다. (아니라면 TypeSafe가 권장하는 사용 사례 목록을 확인하라).

사용 방법에 대한 창의성을 제한하기보다는, 우리가 프레임워크 Stagehand에 Jev를 어떻게 재구성(retrofitting)했는지 보여 주겠다.

지난 2년간 Stagehand는 AI와 에이전트가 원격 브라우저를 제어하기 위한 프레임워크로 진화해 왔다. 에이전트가 충분히 좋아지기 전에, 우리는 개발자가 웹을 자동화하기 위한 자가 치유(self-healing) 스크립트를 작성할 수 있도록 Act(작업 완료), Extract(구조화된 데이터 추출), Observe(페이지 내 잠재적 작업 발견)라는 AI 기본 요소를 만들었다.

Playwright(또는 기타 레거시 프레임워크)를 사용하여 액션용 셀렉터를 제공하기 위해 DOM을 수동으로 파싱하는 대신, Stagehand의 A/E/O를 사용하면 자연어를 사용하여 자동화를 구축할 수 있다.

typescript

1// Playwright
2await page.click('button[type="submit"]');
3
4// Stagehand
5stagehand.act("click the submit button")

이는 처음 스크립트를 작성할 때 유용하다(개발 속도가 훨씬 빨라짐). 특히 스크립트 유지보수에 도움이 된다. 웹사이트 변경으로 인해 DOM 셀렉터가 업데이트되면 Playwright 스크립트는 새 페이지에 맞게 다시 작성되어야 한다. Stagehand는 런타임에 셀렉터와 액션을 선택하므로 "자가 치유" 기능을 제공한다.

우리가 어디로 향하고 있는지 대략 알 수 있을 것이다. Jev는 이러한 기본 요소에 매우 잘 맞는다. 원래는 LLM을 사용하여(페이지 모양과 목표에 대한 컨텍스트를 주어) 무엇을 할지 결정했다. Jev를 사용하면 Choice를 사용하여 상호작용할 셀렉터를 결정할 수 있다.

Act를 구체적으로 사용하여 흐름을 설명해 보자. 일반적으로 하이브리드 a11y-tree를 사용하여 페이지의 간결한 표현을 LLM에 제공했다. Jev를 사용하면 먼저 a11y tree의 노드를 상호작용 가능(rich-text editor 포함)하거나 불가능한 것으로 표시(mark nodes)한다.

stagehand.act가 호출될 때:

Jev는 지시문을 액션(클릭, 채우기, 스크롤 등)으로 분류한다.
Stagehand는 인수를 파싱하고 해당 액션에 대한 후보 리스트(근처의 페이지 컨텍스트 포함)를 빌드한다.
Jev는 "어떤 후보가 최선인가"와 "후보 중 매칭되는 것이 있는가"에 대해 0.7의 허용 임계값(acceptance threshold)으로 답변한다.
후보 액션이 허용되면 Stagehand가 실행을 처리한다.
액션이 허용되지 않으면 Stagehand는 LLM으로 폴백(fallback)한다.

Act 흐름

초기 테스트에서 Act의 중앙값 지연 시간은 1.97초에서 0.46초로 감소하여 약 4.3배 더 빠르다(시간이 77% 단축됨). 전체 PR 스택을 참조하라.

컴퓨터 사용(computer use) 분야에서 Jev는 퍼즐의 한 조각이지만 독립적인 솔루션은 아니다. 이제 에이전트가 사용할 수 있는 더 결정론적인 소프트웨어 도구를 구축할 수 있게 되었다.

Jev를 언제 사용할 것인가

현실 세계에 AI 확산시키기

Jev가 프로덕션급 컴퓨터 사용 에이전트를 구축할 수 있을까? 아니다. 그것이 퍼즐의 유용한 조각일까? 나는 그럴 것이라고 생각한다.

Jev 이전에는 말이 안 됐던 아이디어들이 넘쳐나는 것처럼 느껴진다. 즉각적인 검색, 스마트 복사 붙여넣기 등 단순하지만 매우 유용한 도구들을 만드는 사람들을 보았다.

AI는 동기식 또는 비동기식 채팅 인터페이스의 어떤 버전으로만 국한되어서는 안 된다. Jev 같은 모델을 통해 우리는 채팅 입력 상자 없이 예측 모델을 통합하는 소프트웨어를 구축할 수 있다. 분류기가 오랫동안 존재해 왔지만, 그 어느 때보다 유용하게 느껴진 적은 없었다. 어쩌면 우리가 필요로 했던 것은 영감뿐이었을지도 모른다.

-> Kyle