本文へ
ハクソク

世界を動かす技術を、日本語で。

25行のPythonで作るJev

元記事: 原文(nobodywho.ai)

概要

  • Jev は話題のAIモデルだが、実態はシンプルな分類器
  • たった 25行のPythonコード でJevの仕組みを再現可能
  • ローカル実行 でデータを外部に送信しない安心設計
  • APIや特別な学習は不要、確率出力も標準機能
  • オープンソース実装や参考リンクも多数紹介

Jevとは何か?実際の仕組み

  • Jev はTwitterなどで「次世代AI」などと話題になっているが、実は非常にシンプルな 選択肢分類モデル

  • 25行程度の Pythonスクリプト で、Jevの基本的な動作を再現可能

  • HuggingFace のGGUF形式モデル(例:Qwen/Qwen3-0.6B-GGUF)を利用

  • モデルロード、プロンプト生成、選択肢定義、確率計算まで一貫した簡単な流れ

    • モデルのロード(Llama.from_pretrained)
    • ラベル・選択肢・メール内容の定義
    • 選択肢を含むプロンプトの作成
    • モデル実行および logits からの確率算出
    • 選択肢ごとの 確率出力 (例:Phishing 88.5%など)

Jevの特徴と誤解

  • APIコール不要、ローカル完結型AI分類
  • System One decision model や RLCD (強化学習による確率校正)は未使用
  • 合成データ生成や追加学習 も不要
  • 単に「プロンプト+選択肢→確率出力」の 高速ローカル分類器
  • データを外部に送信しない ため、プライバシー重視の用途にも最適

Jevの実装例(要点)

  • 必要なパッケージ: huggingface-hub, llama-cpp-python, numpy
  • モデル・プロンプト・選択肢の準備
  • モデルの出力(logits)を softmax 変換し、各選択肢の確率へ
  • 出力例:
    • Logits: {'Legitimate': 26.254, 'Spam': 27.262, 'Phishing': 29.614}
    • 確率: {'Legitimate': 3.1%, 'Spam': 8.4%, 'Phishing': 88.5%}

Jevの本質とオープンソース活動

  • Jevは 「選択肢付き分類」 という単純な枠組み
  • 速い・ローカル・シンプル が強み
  • NobodyWho などによるオープンソース実装が多数存在
    • 例: OpenJev, openjev-sglang, OpenJev on DiffusionGemma
  • 公式Githubでの スター支援 呼びかけも

まとめ

  • Jev は過剰評価されがちだが、実際は「ローカルで選択肢分類するだけ」のシンプルな仕組み
  • プライバシー重視・高速処理・オープンソース が魅力
  • 詳細や実装例は NobodyWho や各種リポジトリを参照

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

技術的な知識を得るためにこういうのを読むのは好きだけど、jevのクリエイターの気持ちもわかるな。今や、100個の小さなことをうまくやった方が、これよりずっと良い製品になる理由を説明するのに、ものすごい労力をかけなきゃいけないんだろうね。

└

「説明する」を「売る」に変えよう。これは金鉱ラッシュだから、企業がパイの一切れを求めて急いでるのに同情する理由はないよ。

└

それは悪名高い「10行のコードでOneDrive(SFTP)」だね。技術的には正しいけど、同じことではないよ。

Heaneyのコメントで言われてた遅延や計算の比較が欠けてるだけじゃなく、エラーレートについても何も言ってないし、アプリが解析できるフォーマットで常に出力されるかどうかもわからない。そこがどう解決されてるのかも不明だし。でも最後に「パロディ」って書いてあるから、HNのタイトルは「ジョーク」って言った方がいいかもね。

└

遅延や計算の比較は、ローカルのセットアップに大きく依存するよ。エラーレートを下げるために、より良いモデルに切り替えることもできる。

└

そう言ってるけど、同じ文の中で他の「OpenJev」実装にも言及してるんだよね。基本的には同じことをちょっと手間をかけてやってるだけだし。それらもパロディだとは暗示してないし(実際、パロディだとは思わない)。なんかHNの連中にはエラー率なんて気にしない「プロ」がたくさんいて、ポテトで動くQwenモデルが最先端の知能だと思ってるみたい。

チャットモデルをベースにしてlogprobsを直接使うのは、ちょっと気持ち悪いよね。出力として文章を書くように訓練されてるからさ。だから「選択肢」トークンの確率が、他の何かを言いたいときに薄まっちゃうかもしれない。もしこの投稿と同じやり方でやるなら、少なくとも明確なシステム指示と、プロンプトのアシスタント出力セクションの最初に慎重に言葉を選んだ始まりを加えて、すぐに逸脱しないようにするべきだよ。構造化された出力を使うと、この問題はずっと良く解決できると思う。モデルに「A」「B」「C」だけを生成させて確率を見るんじゃなくて、「正当」「スパム」「フィッシング」などの事前定義されたオプションから、直接「Legitimate」「Spam」や「Phishing」を生成させる方がいいよ。裏ではかなり似たようなことになるけど、モデルが「フィッシングの試みがありそうだから、答えは(C)が正しい」って言いたかったリスクには直面しないし、その結果「A」が最初のトークンで一番高い確率になることもない。推論の予算を使うこともできるし、残りの出力構造の前に自由形式の部分を設けることもできるよ。確率を言葉や数字で割り当てることもできるけど、トークンのlogprobs以上にはあまり頼らない方がいいかな(でも、かなり良いこともあるけどね)。

└

普通の英単語は全部同じリスクがあるみたいだから、短いランダムな文字列を使う方がいいのかな?実際、こういう効果が存在するかどうかをベンチマークできるかもしれないね。

└

同意する、これは本当に問題だけど、システムプロンプトにスキーマを入れて、モデルに固定値の期待を持たせることで、かなり軽減できると思う。まともな現代のモデルなら、提供された値よりも文章の靭帯を選ぶことはないだろうし。問題を完全に解決するには、いくつかの安価なLoRaのイテレーションで十分だよ。

└

自分の経験から言うと、logprobsを使って不確実性を定量化しようとするのは、LLMにはあまり向いてないね。ニューラルネットは一般的に「キャリブレーション」に苦しむんだ。つまり、予測が本当に50/50の場合、ニューラルネットは過信して予測しがちなんだよね[0]。2年前にGPT-4を使って基本的な分類を試したことがあるんだけど、曖昧な選択肢で人間にエスカレーションしなきゃいけない時、LLMは99.8%の確率みたいな出力をよく出してた。正しい答えは99.99%だったのに。

└

+1、llama.cppには生成を制約するためにBNFスタイルの文法ファイルを渡せる--grammarパラメータがあるよ。Pythonのllama.cppラッパーでも使えるよ。https://til.simonwillison.net/llms/llama-cpp-python-grammars

└

それがdaseinlabs/open-jevのアプローチで、TheoLeeCJ/openjevやekzhang/openjev-sglangとは対照的だね。https://sgnt.ai/p/jev/

Hacker Newsで議論の続きを見る