OpenAI는 Jev를 빠르게 따라잡을 유리한 위치에 있습니다

AI 요약

TypeSafe가 만든 Jev는 자연어로 분류 질문을 지정하고 결과와 확률을 돌려주는 모델입니다. Vercel은 Jev가 AI Gateway 역사상 가장 빠르게 채택된 모델이라고 소개했습니다. 글쓴이는 Jev가 약속한 정확도와 범용성을 갖췄다면 유용한 제품이지만, OpenAI 같은 대형 연구소가 기능을 복제하거나 기존 모델에 넣을 수 있다고 봅니다. 글의 중심에는 Jev의 기술적 해자가 어디에 있는지, 그리고 OpenAI가 분류 능력을 생성형 모델 안에 통합할 수 있는지에 관한 주장이 놓여 있습니다.

LLM은 이미 작은 분류기로 동작합니다

글쓴이는 Jev가 기존 대형 언어 모델(LLM)과 가까운 구조라고 가정합니다. 모델은 다음 토큰을 고를 때 어휘 전체에 대한 확률 분포를 계산합니다. Jev는 이 분포에서 필요한 선택지에 해당하는 확률을 가져와 결과로 가공한다는 설명입니다. 참·거짓 질문에서는 두 토큰의 확률을 비교하고, 여러 선택지가 있는 질문에서는 각 선택지 토큰의 확률을 비교합니다. 점수 기능도 비슷한 방식일 수 있다고 추측하지만, 글쓴이는 이를 자세히 검토하지 않았다고 덧붙입니다.

이 방식은 새롭기만 한 발상은 아닙니다. 글쓴이는 OpenAI가 도구 호출을 도입한 뒤부터 LLM을 암묵적인 분류기로 활용했다고 설명합니다. ChatML에서 assistant 응답의 첫 토큰이 일반 답변을 시작하는 줄바꿈인지, to=function.인지에 따라 도구 호출 여부가 갈립니다. 이어지는 토큰은 사용할 도구를 고르고, 뒤의 토큰은 인수와 값을 생성합니다. 응답을 끝내는 <|im_end|> 토큰도 모델이 발화를 마칠지 고르는 판단으로 볼 수 있습니다. 다만 이런 판단은 각각 정해진 작업만 수행하는 전문 분류기입니다. 글쓴이는 Jev의 차이를 여러 분야에 쓸 수 있는 일반 분류 능력에서 찾습니다.

모델 안에서 바로 판단하는 방식

글쓴이는 OpenAI가 분류기를 외부 도구로 부르는 대신 모델 내부 기능으로 만들 수 있다고 제안합니다. 예시에서는 모델이 생각을 이어가다 <prediction> 태그를 넣고, 주장과 확률을 계산해 결과를 문맥에 기록합니다. 일반적인 도구 호출은 모델 생성이 멈춘 뒤 외부 실행기가 동작하고 결과를 새 입력으로 돌려줍니다. 반면 이 제안에서는 GPU를 벗어나지 않고 모델이 판단을 이어갑니다.

구현 아이디어는 일반적인 토큰 디코딩과 다릅니다. 모델이 probability: 위치에 도달하면 가장 높은 확률의 토큰을 그대로 고르지 않고, 참·거짓 토큰의 로짓(logits)만 읽어 확률을 정규화합니다. 계산한 값을 텍스트로 문맥에 넣은 뒤 생성을 재개합니다. 글쓴이는 이를 문법에 맞는 출력을 유도하는 제약 디코딩(constrained decoding)과 비슷한 방식으로 설명합니다. 다만 이 위치에서는 다음 단어를 예측하는 능력뿐 아니라, 질문의 참된 답을 판단하고 확률을 보정하는 능력이 필요합니다. 글쓴이는 미세 조정으로 이런 판단을 맡는 전문가를 만들 수 있다고 제안하면서도, 혼합 전문가(MoE) 구조에 관한 설명은 단순화했다고 밝힙니다.

이런 내부 분류기가 신뢰할 만하다면 모델은 긴 추론 중 다음에 할 일을 고르거나, 도구 호출이 안전한지 확인하거나, 도구 응답에 프롬프트 인젝션이 있는지 검사할 수 있습니다. 작업에 더 크거나 작은 모델이 필요한지 골라 비용을 조정하는 용도도 제시합니다. 이미지와 음성 분류로 확장할 가능성도 언급합니다. 특히 음성 에이전트라면 실시간으로 말을 끊을지, 담당자에게 넘길지, 계속 들을지 판단하는 데 쓸 수 있다는 구상입니다. 다만 이는 구현 사례가 아니라 글쓴이가 제안한 활용 방식입니다.

Jev의 해자는 정확도와 학습 과정입니다

글쓴이는 구조 자체에는 큰 해자가 없다고 봅니다. 전통적인 LLM도 범용 분류에 적합하고, OpenAI는 이를 구현할 기술 인력과 컴퓨팅 자원, 자금을 갖췄다는 주장입니다. 더 어려운 부분은 정확한 확률을 내도록 학습하는 데이터와 과정일 수 있습니다. 글쓴이는 정답이 이미 확인된 고객 지원 티켓의 분류 결과, 실제 채용 여부가 알려진 이력서, 실제 평점이 있는 상품 후기 같은 사례를 폭넓게 모으는 방식을 예로 듭니다. 서로 다른 분야의 사례를 학습시켜 특정 작업에 한정되지 않는 분류 능력을 만드는 구상입니다. 강화학습이 어떤 역할을 하는지는 글쓴이도 알지 못하며, 그 과정에 비공개 노하우가 있을 수 있다고 추측합니다.

무엇보다 이 데이터와 학습 과정도 Jev가 충분히 정확해야 의미가 있습니다. 글쓴이는 일부 분야에서 Jev의 확률이 기대에 못 미치는 사례를 봤다고 말합니다. Jev가 다양한 작업에서 정확한지 검증되지 않은 상태라면 속도와 비용만으로 지속적인 경쟁력을 판단하기 어렵습니다. 정확도가 높고 복제하기 어려운 학습 과정이 있다면 TypeSafe가 살아남거나 인수될 수 있고, 해자가 얕다면 대형 연구소가 자체 구현해 빠르게 따라올 수 있다는 것이 글의 전망입니다.

Hacker News 반응

• @HarHarVeryFunny — Jev에는 세 가지 장점이 있어 보입니다. 빠르고 저렴하며, 입력 하나를 여러 분류에 재사용해 계산을 공유합니다. 구조화된 출력을 기본으로 내고, 확률이 실제 의미를 갖도록 보정됐습니다. OpenAI나 다른 회사가 복제할 수는 있겠지만, AI 회사가 지능과 토큰을 파는지 고객과 경쟁하는 애플리케이션 회사인지 먼저 정해야 합니다.
• @alex_sf — 구조화된 출력이 특정 형식으로 나온다는 뜻이지, 내용까지 정답이라는 뜻은 아닙니다. 문법 제약은 어떤 LLM에서도 쓸 수 있습니다. 문법 기능이 있다는 사실을 놓치고 이야기하는 경우가 많습니다.
  • @time0ut — 제약 디코딩은 Jev가 겪지 않는다고 주장하는 방식으로 모델을 학습 분포 밖으로 밀어낼 위험이 있습니다. 또 Jev가 여러 질문에 독립적으로 답하는 점도 흥미롭습니다. TypeSafe의 주장이 어디까지 맞는지는 더 지켜봐야 하지만, 제가 시험한 결과는 괜찮았습니다.
• @hbrn — 마케팅 문구를 너무 쉽게 믿지 마세요. 선택지 순서만 바꿔도 Jev의 확률이 크게 달라질 수 있습니다. ‘confidence’ 값도 확률에 공식을 적용한 결과라 추가 정보를 주지 않습니다. 백엔드에서 선택지 순서를 정렬해 이 문제를 고친 척할 것 같습니다.
  • @HarHarVeryFunny — 실제 업무 분류의 확률이 특정 기준보다 높은지가 중요하다면, 그 작업에 맞는 모델을 직접 학습하거나 미세 조정하는 편이 낫습니다. TypeSafe가 그런 서비스도 내놓으려는지는 모르겠습니다.
• @EagnaIonat — 일반 LLM은 생성한 텍스트를 바탕으로 분류합니다. Jev는 분류 결과와 확률을 바로 반환하므로 빠르고, 확률을 지어내지 않는다는 장점이 있습니다. 하지만 분류 항목이 늘수록 LLM은 원하는 분류보다 패턴을 일반화하기 시작하고 성능이 무너집니다. Jev의 기반이 된 Laya 논문도 분류가 20개를 넘으면 급격히 실패한다고 언급합니다.
• @amluto — 자기회귀 LLM이 확률을 만든다는 설명에는 큰 단서가 있습니다. 다음 토큰 확률은 학습 분포에서 그 문장 뒤에 어떤 토큰이 나올지 나타내지, 우리가 원하는 분포에서 주장의 참일 확률을 뜻하지는 않습니다. 모델이 추론을 거치면 최종 답의 로짓은 선택한 추론 경로에 조건부로 매겨집니다. Jev 사용자가 원하는 확률 분포와 다를 수 있습니다.
  • @dgellow — 자기회귀 LLM은 확률보다 ‘그럴듯함’을 출력한다고 말하는 편이 더 이해하기 쉽습니다.
• @andy12_ — OpenAI는 강화학습을 통한 추론 모델에 집중하고 있습니다. Jev처럼 빠른 판단을 위해 추론하지 않는 모델과는 방향이 다릅니다. 추론을 추가하면 자동회귀 토큰 생성으로 비용과 속도 이점을 잃으니, OpenAI가 굳이 신경 쓰지 않을 수도 있습니다. 글에서 Jev가 기존 LLM과 비슷하다고 가정하지만, 그렇다는 증거는 아닙니다.
• @NeutralCrane — Jev는 기존 분류기와 LLM 사이의 간격을 메우려는 제품으로 보입니다. 전통적인 분류기는 주석 데이터와 학습이 필요하지만 빠르고 저렴하며 확률을 얻을 수 있습니다. LLM은 데이터와 학습 없이 제로샷 분류를 하지만 느리고 비쌉니다. Jev는 LLM의 제로샷 사용성을 유지하면서 전통적인 분류기에 가까운 비용과 속도를 제공하려는 것으로 보입니다.
• @oblio — TypeSafe와 Jev가 2~3년치 운영 자금을 갖고 있다면 이 문제는 저절로 해결될지도 모릅니다.
  • @cmrdporcupine — 더 그럴듯한 시나리오는 OpenAI나 Anthropic이 높은 가격을 주고 Jev를 인수하는 것입니다. 기술보다 인재와 홍보 효과를 노릴 수 있습니다. 기술은 쉽게 복제하지만 이름과 화제성은 그렇지 않습니다.
• @yogthos — OpenAI가 무엇을 하든 크게 상관없습니다. DeepSeek, Qwen, GLM 같은 모델이 분류기를 통합한 오픈 모델을 내놓는 일이 더 기대됩니다.
• @enraged_camel — 왜 OpenAI인가요? 글에 나온 내용은 OpenAI만의 특징이 아닌 것 같습니다.
  • @docheinestages — OpenAI만이 아닙니다. Jev보다 자금이 많은 최첨단 AI 연구소라면 어디든 가능합니다.
• @pushpendraw — Jev의 진짜 장점은 학습된 분류기를 정확도로 이기는 데 있지 않습니다. 학습과 배포를 반복하는 대신 프롬프트를 고쳐 분류 대상을 바꿀 수 있다는 점입니다.
• @orbital-decay — 주요 AI 회사는 추론 파이프라인, 안전장치, 데이터 준비, 학습 등 다양한 곳에서 이미 분류기를 씁니다. 새삼스러운 점은 분류기가 생성형 모델보다 효율적이라는 사실을 사람들이 알아가기 시작했다는 것입니다.
  • @JohnBerryman — 제게는 범용적으로 적용할 수 있고 품질도 높다는 약속이 새롭고 특별해 보입니다. 실제 주장이 맞는지는 기다려 봐야 합니다.
• @jrochkind1 — Jev는 처음 들었습니다. 정말 큰일인지, 글쓴이가 Jev를 홍보하는 건지, LLM이 쓴 듯한 글이 아닌 다른 자료에서 더 알아볼 수 있는지 확인하고 싶습니다. 참 별난 세상입니다.
• @skyde — 적은 데이터로도 표본 효율을 높일 수 있다는 점 때문일 수 있습니다. 데이터가 많지 않아도 LoRA로 자기 Jev를 미세 조정할 수 있습니다.
• @jcims — Claude와 Jev를 조합해 댓글과 게시물을 ‘슬롭’인지 분류하는 브라우저 확장 기능을 만들었습니다. TypeSafe API 키와 문서 링크를 Claude에 주고 약 10분 만에 HN 댓글마다 점수를 붙였습니다. LLM 지연에 익숙해진 뒤 써 보니 매우 빨랐고, 주관적인 평가치고는 잘 작동했습니다.
• @gcr — TypeSafe가 살아남기를 바란다면서 OpenAI에 이들을 이길 구체적인 방법을 자세히 알려주는군요.
  • @JohnBerryman — 혼돈 중립입니다.

원문: Arcturus Labs / 번역·요약: Trawling