Jev가 구조화된 출력(structured output)을 다시 흥미롭게 만든 이유

User: 샌드위치를 발명한 사람은 누구인가?
LLM: 샌드위치는 샌드위치 백작이 발명했습니다.

User: { state: 

Jev의 속도가 가장 흥미로운 예시는 **모델이 Doom을 플레이할 수 있다**는 점입니다. 현재 게임 상태를 텍스트 기반으로 모델에 입력하고, “트리거를 누르고 있어야 하는가”, “현재 목표는 무엇이어야 하는가”, “현재 목표가 X라는 것을 감안할 때 어떤 키보드 입력을 눌러야 하는가”와 같은 일련의 선택지들을 결합하여 넣으면 작동합니다. 지연 시간(latency)이 충분히 낮고 시스템이 충분히 똑똑해서 모델이 실시간으로 잘 플레이합니다.

물론 Doom을 플레이하도록 신경망(neural net)을 훈련시킬 수도 있습니다. 하지만 Jev는 *범용적인* 지능입니다. LLM이 세금 신고를 하거나, 수학 연구를 수행하거나, Python 환경을 수정하고, 시를 써줄 수 있는 것처럼, Jev는 단일 비디오 게임을 플레이하는 것 외에도 다른 많은 작업을 할 수 있습니다. 현재의 LLM도 Doom을 플레이할 수는 있지만 (비록 느리더라도) 말입니다. 하지만 넬슨 엘헤지(Nelson Elhage)가 유명하게 말했듯이, 빠르다는 것은 단순히 같은 작업을 더 빠르게 수행한다는 의미를 넘어, 완전히 새로운 종류의 작업을 할 수 있다는 것을 의미합니다. 다양한 결정 지점에 100ms 정도의 저렴한 지능을 주입함으로써 어떤 새로운 프로그램을 작성할 수 있을까요?

제게는 이것이 Jev에 관한 가장 흥미로운 부분입니다. *빠른* 구조화된 출력(structured output)은 지능을 위한 진정으로 새로운 계산 원시 요소(computational primitive)가 될 수 있습니다. 지금까지 우리는 자기회귀 토큰 생성(autoregressive token generation) 위에 많은 프로그램을 구축해 왔고, 그들은 모두 멋진 챗봇처럼 보입니다. 구조화된 출력에 깊이 집중하는 것은 AI를 위한 챗봇 외의 다양한 사용 사례들을 상상할 수 있게 해줄 수도 있습니다.

Jev에 대한 저의 가장 큰 문제는 **빠른 구조화된 출력이 이미 존재한다**고 생각한다는 것입니다. LLM의 구조화된 출력은 단지 (a) 아무도 그것에 신경 쓰지 않거나4, 그리고 (b) 관심을 갖는 사람들은 큰 JSON 덩어리를 원하기 때문에 느릴 뿐입니다. 따라서 이는 일반적으로 “문법 제약 디코딩(grammar-constrained decoding)”으로 구현됩니다. 즉, LLM은 평소처럼 자기회귀적으로 출력을 하지만, 로짓 샘플러(logit sampler)가 구조화된 출력에 맞지 않는 토큰을 폐기하는 방식입니다 (예: ”[”가 없었다면, ”]”를 출력할 수 없습니다).

만약 제한된 선택지(limited choices)에 대해 빠르고 병렬화된 구조적 출력(structured output)을 원한다면, 아예 자기회귀 생성(autoregressive generation)을 할 필요가 없습니다. 단순히 응답을 `"choice": "`로 사전 채우고 사용자 제공 선택지에 국한하여 토큰 5개를 생성하면 됩니다. LLM은 모든 입력 토큰을 병렬로 처리하기 때문에, 이는 전체 구조적 출력을 생성하는 것보다 훨씬 빠릅니다. 여러 선택지는 일반적인 추론 배치(inference batching)를 통해 하나의 순방향 패스(forward pass)에 배치할 수 있습니다. 이것이 장문 구조적 출력(long-form structured output)을 가능하게 하지는 않지만, 그 대가로 Jev의 “비밀 병기” 중 대부분인 속도, 일관성, 그리고 시스템 원 모델(System One model)의 병렬성을 얻게 됩니다.

사람들은 이미 오늘 Jev의 발표 이후 이를 시도하기 시작했으며, 괜찮게 작동하는 것 같습니다. 즉, 저는 Jev가 실질적인 기술적 해자(technical moat)를 가지고 있지 않다고 의심하며, 그들이 주장하는 “보정된 결정을 위한 강화학습(Reinforcement Learning for Calibrated Decisions)”은 새롭고 혁신적인 확장 축(scaling axis)이 아닐 것이라고 생각합니다. 다른 어떤 연구소나 개별 프로그래머가 기존 오픈소스 LLM에 이를 적용하여 빠른 Jev 유사 모델을 만드는 것은 상당히 쉬울 것입니다.

하지만 저는 Jev가 여전히 “Qwen-32B-System-One”의 대부분 버전보다 나을 것이라고 생각합니다. 구조적 출력만으로 모델을 미세 조정(fine-tune)하거나 최적화할 수 있다는 점은 아마도 의미 있는 이점일 것입니다.

저는 Jev가 초거대 LLM(frontier LLMs)만큼 똑똑해질 수 있을지 의심합니다. 테스트 시간 컴퓨팅(test-time compute)을 전혀 사용할 수 없다는 것은 큰 단점이며, 이러한 종류의 모델 성능을 추론 능력이 없는 LLM 수준으로 제한할 가능성이 높습니다. 실제로는 저지연 애플리케이션(low-latency applications)에 있어서는 크게 중요하지 않을 수 있지만, 이를 새로운 확장 축이나 더 지능적인 모델을 생성하는 방법으로 보아서는 안 됩니다.

Jev 개발자들은 이것이 환각(hallucination)으로부터 면역이라고 주장합니다. 저에게는 이는 일종의 의미론적 회피처럼 보입니다. 왜냐하면 Jev가 여전히 잘못된 선택을 할 수 있기 때문입니다 (예: 하늘을 “빨간색”이라고 부르는 경우). 모델이 완전히 새로운 것을 지어내는 대신 사용자 제공 선택지를 고르고 있는 것이므로, 기술적으로는 단지 *실수*일 뿐이라고 생각합니다. 하지만 이 모든 것은 구조화된 출력을 가진 일반적인 LLM에도 해당되는 이야기이며, Jev를 실제 사용에서 더 신뢰할 수 있게 만들지는 않습니다.

Jev의 가치 중 모델 자체에 얼마나 많은 부분이 있는지, 아니면 질문당 단 하나의 토큰만 생성하는 추론 전략(inference strategy)에 얼마나 많은 부분이 있는지가 불분명합니다. 발표 자료와 데모는 어떤 Terra 크기의 모델이든 단일 토큰 추론 스택에 연결하여 생성할 수 있었던 것처럼 보입니다. 하지만 관련된 사람들은 신뢰할 만하며, 저는 이 모델이 좋을 것이라고 확신합니다. 다만, LLM에게 JSON 덩어리를 토큰별로 불필요하게 생산하도록 강요하지 않는 비교 자료가 제공되었으면 좋겠습니다.

전반적으로, Jev의 존재에 만족하며 성공하기를 바랍니다. 빠르고 구조화된 출력(fast-structured-output) 영역에서 실제 경쟁이 일어나고, 이것이 대형 연구소들이 자신들의 모델을 이 분야에 맞춰 파인튜닝(fine-tuned)하여 공식 버전을 출시하도록 동기를 부여하기를 바랍니다. GPT-5.6-Terra-System-One은 AI 제품을 구축하는 데 매우 흥미로운 모델일 것입니다.

-
저는 Thinking Machines의 “상호작용 모델(interaction models)”에 대해서도 글을 썼는데, 이것 역시 의미 있게 다를 수 있는 AI 추론 패러다임입니다.

↩ -
그들은 Jev를 Daniel Kahneman이 부분적으로 신뢰를 잃은 *Thinking Fast and Slow*의 내용을 따라 ‘시스템 원(System One)’ LLM이라고 부릅니다. 이 책에서 그는 인간의 인지 과정을 번개처럼 빠른 시스템 원과 느리고 사색적인 시스템 투로 나눕니다.

↩-
만약 “잠깐, 일반 LLM을 공격적으로 프리필(prefill)하고 단 하나의 제약된 토큰만 생성할 수 있지 않을까?”라고 생각한다면 계속 읽어보세요.

↩ -
구조화된 출력이 아닌 방식으로 내장된 툴 호출(tool calls)은 제외합니다.

↩ - 사용자의 선택지가 단일 토큰보다 길다면 어떻게 해야 할까요? 저 자신은 시도해 보지 않았지만, 이를 단일 토큰으로 번역하거나 모델을 훈련시켜 선택 내용 대신 내부적으로 “1/2/3”과 같은 형식으로 출력하도록 하거나, 선택지의 첫 번째 토큰만 다를 경우에 생성하는 등 제가 생각하지 못한 다른 기발한 방법이 있을 것이라고 확신합니다.

↩ - Jev는 그들이 생성한 확률이 “보정(calibrated)”되었다고 주장하지만, 저는 이것들이 단순히 일반적인 로짓(logit) 확률이 아님을 시사하는 것을 본 적이 없습니다. 아마도 불확실한 상황에서 정확한 로그 확률(logprobs)을 유도하기 위해 어떤 기발한 훈련을 하는 것일 수도 있습니다 (예: 동전 던지기를 예측할 때 모델이 `heads: 50, tails: 50`과 같이 출력하도록 만드는 등)? 만약 그렇다면, 발표에서 이 부분에 대해 더 많이 작성해 주었으면 좋았을 텐데요. - 저는 직접 `Qwen2.5-1.5B-Instruct`로 시도해 보았고, 접두사(prefixed)가 없는 구조화된 출력 방식과 비교하여 2배~3배의 속도 향상을 얻었습니다. - 그들은 고정된 횟수만큼 반복하는 루프드 트랜스포머(looped-transformer) 같은 것을 할 수는 있겠지만, 추론처럼 보이는 어떤 것도 모델의 지연 시간(latency)을 느리고 예측 불가능하게 만들어 전체 목적에 역행할 것입니다.

↩

이 게시물이 마음에 드셨다면, 제 새 글에 대한 이메일 업데이트를 구독하거나 Hacker News에 공유해 주세요.

여기에 이와 태그가 같은 관련 게시물의 미리보기가 있습니다.

**요원(agents)에게 '어떻게(how)'만이 아니라 '왜(why)'를 알려주세요**

초기 AI 요원들은 기본적으로 열정적인 바보들이었습니다. 이들과 작업하려면 그들에게 무엇을 원하는지 정확하게 말해줘야 했습니다 (예: “클래스 B에 메서드 A가 존재하니, 클래스 C부터 F까지 동등한 메서드를 추가해 주세요”). 그렇지 않으면 완전히 잘못된 것을 실행하고 엉뚱한 곳으로 새어 나갔습니다. 하지만 AI 요원들이 발전함에 따라 이 점이 바뀌었습니다.

최첨단 모델(frontier models)이 오늘 잘못된 행동을 할 때, 그것은 혼란스러워서가 아니라 사용자의 목표나 우선순위에 대해 잘못된 가정을 하기 때문에 발생합니다. 예를 들어, GPT-6-Astra가 자신을 위한 코드를 작성한다고 생각하면, 축소된 코드(minified code)를 생성할 것입니다. 이 모델은 인간이 읽을 수 있는 코드를 작성하는 데 완벽하게 능숙합니다 — 적어도 제가 그 모델로 수천 줄의 허용 가능한 코드를 생산한 Golang에서는 그렇습니다 — 하지만 사용자에게 사람이 코드를 읽게 될 것이라고 알려줘야 합니다.