#ローカル実行

大きなLLMに文章を書かせるのではなく、与えた選択肢のどれが適切かを素早く選ばせる。そんな用途に絞って作られたのが、GitHubで公開されている「Jeff」というプロジェクトだ。元記事は、Qwen3.5とGemma 4をゼロショット分類向けにファインチューニングしたモデル群の中身と、実際の速度や精度をかなり具体的に示している。派手な生成AIではなく、現場の分岐判断をどれだけ軽く、安定してさばけるかを見せる内容になっている。 元記事の主題は、firelex/jeff というGitHubリポジトリにあるモデル群の説明だ。Jeff は Qwen3.5 と Gemma 4 をゼロショット分類向けに調整したもので、文脈を文章で与え、選択肢を平易な言葉で並べると、その中からどれが合うかを確率つきで返す。生成文を出すのではなく、1回の forward pass で「どの विकल्पが正しそうか」を出す設計で、著者はこれを「小さくて速い decision model」と位置づけている。 対応する入力形式は、たとえば「荷物が壊れて届いたので返金したい」という状況文に対して、「Refunds and p

ChatGPTのように文章を長く生成するのではなく、入力に対して「invoice か refund か」「危険か安全か」といった判断を素早く返すモデルがある。Ollayaは、その種の decision model を自分のPCやサーバー上で動かすための仕組みを前面に出してきた。クラウドAPIに投げるのではなく、ローカルで、しかも数ミリ秒単位の応答を狙うのが売りだ。特に、個人情報や社内データを外に出しづらい用途では、かなり現実的な選択肢に見える。 Ollayaは、open decision models を自分のマシンでダウンロードして提供するサイト兼ツールだ。トップページでは「typed questions about any text or JSON」に答え、しかも calibrated answers を milliseconds で返すと説明している。ここでいう decision model は、長文を生成するLLMとは少し違う。選択肢の中から答えを一つ返したり、yes/no を出したり、スコアを付けたりする用途に向いたモデルで、文章を1トークンずつ出すのではなく、1回の for

いま話題になっている「Jev」を、25行のPythonで再現してみせる──そんな短いデモを軸にした記事が出ています。元記事は、派手な紹介文というより、わざと肩の力を抜いたパロディとして書かれていて、流行のAI手法に対する距離感がよく見えます。面白いのは、そこで示される中身が難しい理論ではなく、「入力された選択肢に確率を付けるだけ」のかなり素朴な仕組みだという点です。これがどういう軽さで、何を皮肉っているのかを、元記事を読んでいない人向けに整理しつつ、こちらの見方も含めて読んでいきます。 元記事は、「Everyone and their mom is talking about Jev」と始めて、JevがAI界隈で大げさに語られていることをからかいます。そのうえで、「25 lines of Python」で実装したと称する短いコードを見せますが、やっていることはかなり単純です。Python 3.12 を前提にして、`huggingface-hub`、`llama-cpp-python`、`numpy` を使い、`Qwen/Qwen3-0.6B-GGUF` の `Qwen3-0.6B-Q8

アプリを「インストールして使うもの」から、「ファイルとして渡して、そのまま開くもの」に変えようとしているサービスがあります。Capsuleは、その考え方をかなり正面から押し出したツールです。元記事では、アプリの見た目やデータ、実行に必要な要素を1つの `.capsule` ファイルにまとめ、メールやWhatsApp、AirDropで送れると説明しています。単なるデモではなく、AIでアプリを作り、あとから中身を直接更新できる点まで含めて、かなり野心的です。 いまこの記事を取り上げるのは、ローカル実行やプライバシー重視の流れに、AIによるアプリ生成が重なってきたからです。クラウドに預ける前提のSaaSとは違う、新しい「配布」の形を模索しているとも読めます。 Capsuleのサイトは、冒頭からかなり挑発的です。見出しは「Documents that run like apps」。説明文には「One file, entire app. Share like a document, open like an app.」とあり、1つのファイルでアプリ全体を持ち運べることを前面に出しています。`.c

読んでまず思ったのは、こういう連携って技術そのものよりも、配布のしかたや制約との綱引きで決まるんだな、ということだった。Claude Desktop からローカルの model を使えるようにする話は一見すると便利機能のニュースに見えるけれど、実際には「前回は数日で止まった」というところが本体に近い。そこが妙に生々しい。 面白いのは、Ollama がやろうとしていることが、単に Qwen や DeepSeek、Kimi を動かせます、で終わらない点だと思う。Model の種類が増えるのはもちろん嬉しい。でも本当に効くのは、Claude Desktop 側の制約をどうかわすか、という実装の工夫のほうだろう。proxy を噛ませていると聞くと、ちょっとした小細工にも見えるけれど、こういう迂回路があるからこそ現実の製品は動く。きれいな正攻法だけでは通らない場面って、やっぱり多い。 それと、この記事を読んで少し引っかかったのは、こうした「つながった、でもまた止まるかもしれない」タイプの機能が、ユーザー体験としてどこまで安心できるのかという点だ。便利さはある。かなりある。でも外部のルールやモデル