Jev가 등장하고 나서야 다들 “우리 제품군에도 있어야 할 유용한 기능”이라고 깨달았다는 게 조금 놀라움.
지나고 보니 당연해 보이는 종류의 일일 수도 있겠음. 몇 년 전에도 간단한 JSON 구조만 출력하도록 하는 문법 제약 출력으로 비슷한 시도를 했겠지만, 그 방식으로는 모델의 확률을 얻을 수 없음. 그렇다면 이 모델들은 확률을 어떻게 계산하는 걸까?
AI 분야에는 실제로 이런 일이 많음. GPT-2와 GPT-3는 기술 뉴스에 소개되는 신기한 기술 정도였고 대중의 관심은 크지 않았지만, RLHF로 사용자 경험이 크게 개선되면서 ChatGPT가 대중화됨. 머신러닝 엔지니어 상당수가 사용자 경험의 중요성을 과소평가하며, Jev도 마찬가지임.
확률 계산에 대한 짧은 답은 더 많고 더 좋은 데이터임. 길게 답하면 다른 분류기와 비슷할 것으로 봄. 정답 확률과 예측 확률을 비교하고, 그 차이를 교차 엔트로피로 계산해 올바른 확률에 가까워지도록 모델을 학습시키는 방식임.
OpenAI는 이미 Decisions API를 개발 중이었음. Jev가 빠르게 출시해 일주일 정도 주목받았고, 그 뒤 OpenAI가 베타를 공개함. 참고로 꽤 잘 작동함.
LLM에서도 yes, Yes, YES 등의 로그 확률(logprobs) 을 no 계열과 비교하면 가능함. 불리언 값, Jev에서 아마 nool이라고 부르는 것에 쓸 수 있음.
직접 구현하거나 기존 라이브러리를 써도 됨. Python에서 vLLM 위에 구축된 라이브러리 중 이런 기능을 지원하는 것이 있는 것으로 알고 있음.
LLM 자체가 모두를 놀라게 했던 일에 더 가까워 보임. 이렇게 단순한 시스템이 이 정도로 효과적일 것이라고는 합리적으로 예상하기 어려웠지만, 실제로 그렇게 됨. 이를 의사결정 모델로 더 작게 증류하는 것도 안 될 것 같지만 작동하는 듯함.
이 시스템 전체가 우리에게 낯설며, 지능이란 무엇인지 다시 생각하게 만듦.
LLM이 문장 하나도 안정적으로 완성하지 못하던 시절부터 제로샷·퓨샷 분류를 해왔음. 일관된 글을 생성하는 것보다 쉬운 작업임. 생성이 아닌 분류와 해당 분야에 맞춰 모델을 조정해야 했지만, 간단한 설명만으로 새로운 분류 작업에 성공하는 경우도 많았음.
이후 LLM이 크게 발전했으니, 지금은 다양한 분야에서 훨씬 적은 노력으로 높은 정확도를 얻을 수 있어 제품으로서 매력적일 것임. 사실 몇 년 전에도 모델 성능은 충분했을 수 있음. 지금은 제품을 빠르게 출시하기 쉬워졌고, 업계에 토큰 비용을 줄이려는 수요도 있음.
아직 의사결정 모델을 써보지 못했는데, 현재 어떻게들 활용하고 있는지 궁금함. Pi 같은 코딩 에이전트 실행 환경에서 쓰는 분도 있는지?
모델 개발용 학습 데이터 라벨링에 사용 중임. Jev로 여러 레코드에 라벨을 붙여 모델을 학습시키고, Opus와 따로 떼어둔 평가용 데이터로 결과를 검증하는 식으로 활용할 수 있음.
마침 오늘 Jev를 써서 Pi용으로 Claude/Codex의 /goal 기능을 직접 구현함. 에이전트가 도중에 멈추길래 매 턴 Jev를 호출해 작업이 끝났는지 확인하도록 했음. Claude의 설명에 따르면 Claude에서도 비슷하게 작동한다고 함.
로컬에서 비공개로 더 빠르게 실행하고 CPU에서도 실행·학습할 수 있는 도구를 찾는다면 http://jeffyclassify.com/을 살펴보길 권함.
사전 학습된 분류기가 여러 개 포함되어 있고, 제공되는 도구로 직접 분류기를 학습시킬 수도 있음. n8n 같은 워크플로 도구와의 연동도 지원함.
Jev 자체를 제외하고 써본 의사결정 모델 중 가장 좋았던 것은 respan/span-02임. Gemma4 26A4 기반이며, 아마 미세 조정한 모델인 듯함. 덕분에 이번 출시도 높은 비용에도 불구하고 기대하게 됨.
같은 범주의 다른 의사결정 모델보다 가격이 조금 높음. 하지만 오디오와 비디오 입력도 받을 수 있어, 그런 용도에는 매우 유용할 수 있음.
파일 정리·색인 도구에서 1년 넘게 Claude가 작성해 준 자체 Jev 유사 구현을 계속 쓰는 주된 이유가 이미지 입력임. 이미지를 1K로 축소하고 태그를 붙이기 위한 질문 몇 개를 던짐. Qwen 3 VL 기반으로 1K 이미지와 최대 2,048토큰 입력에 맞춰 증류·최적화했고, 초당 이미지 약 3장을 처리함. 시스템 프롬프트 뒤에 질문을 하나씩 보내면서 캐시를 재사용함.
더 긴 문서는 다른 GPU에서 실행하는 요약 모델로 보내는데, 아마 Qwen 3.6일 것임. 결과는 모두 벡터 검색 엔진에 넣어 나중에 쉽게 찾도록 함.
새로운 기능이 나올 때마다 Claude에게 추가하라고 맡기고 완료 통보만 받다 보니, 이제 내부에서 정확히 무엇이 돌아가는지도 잘 모르겠음. 새로 추가하는 입력 기능은 기존 파일 전체에 다시 적용할 수 있음.
Jev 출시 시점에 개발을 시작한 것이라면, Google치고는 상당히 빠르게 출시한 셈임.
벤치마크에서 모델 간 성능이 상당히 비슷해서 놀라움.
그저 더 나은 벤치마크가 필요하다는 신호일 수도 있음.
Google이 탁월하지는 않아도 무난한 “우리도 지원한다” 제품으로 기존 고객의 지출을 더 확보하려는 것임. 위험과 변화를 꺼리는 성향을 활용한 가격 책정으로 보이며, Google의 전형적인 방식임.
내가 Claude Code를 쓰게 된 계기는 Google Antigravity였음. Antigravity는 출시 초기에는 훌륭했지만 어느 순간부터 내리막을 걷기 시작함. 정점을 찍은 뒤 개발 활력이 떨어지는, 다른 Google 제품에서 느꼈던 불길한 흐름이 나타나기 시작함.