ローカルJEV互換 + Qwen3 + Flask + PostgreSQL/RAG 構想

ローカルJEV互換 + Qwen3 + Flask + PostgreSQL/RAG 構想

ローカルJEV互換 + Qwen3 + Flask + PostgreSQL/RAG

Ubuntu / Mac の両方で動かす、ローカル判断AI基盤の構想。Jevの「文章を生成するAI」ではなく「ソフトウェアが使える判断を返すAI」という考え方を、Qwen3とRAGで実装する。

Ubuntu / macOSQwen3Flask API PostgreSQL + pgvectorRAGChoice / Noul / Score 原則ローカル処理

1. そもそもJEV(Jev)とは何か

Jev はTypeSafe AIが2026年9月に公開した「System One Model」の最初のモデルです。通常のLLMが文章を生成することを主目的にするのに対し、Jevは入力された状態を見て、型付きの判断と確率を返すことを主目的にしています。

通常のLLM

文章・データLLM自然言語

説明、要約、会話、文章作成などに強い一方、ソフトウェアから見ると返答文を再解釈する必要があります。

Jev型

状態判断モデル選択肢+確率

「分類」「Yes/No判断」「段階評価」を、アプリがそのまま処理できる構造化データとして返します。

Jevの3種類の判断

種類意味想定出力
Choice候補の中から分類・選択問い合わせ内容は「故障 / 契約 / 苦情 / その他」のどれか故障 0.82 / 契約 0.08 / 苦情 0.07 / その他 0.03
Noul命題が成立する可能性この報告は緊急対応が必要か0.91
Score定義した尺度上で評価損傷の重要度を「軽微 / 中 / 大 / 緊急」で評価「大」中心の分布
大事な違い:Jevは「もっともらしい説明文」を作るためのモデルではなく、アプリケーション内部の分岐や自動処理に利用しやすい判断器として設計されています。

2. 今回作るものは「Jevそのもの」ではなく「Jev互換ローカル実装」

TypeSafe公式はPython SDKに加え、LLM APIを使ってJev互換の評価インターフェースを実現する system-one-adapter-python を公開しています。この考え方をローカルQwen3に適用します。

注意:公開されているTypeSafeのJev本体の重みをローカルで実行する、という意味ではありません。Qwen3で Choice / Noul / Score と互換性のある判断APIを作ります。したがって公式Jevと同一の確率校正・速度・精度を保証するものではありません。

アプリ側ではJev風の共通APIだけを見るようにし、将来は次のように差し替えられる構造にします。

ローカル Qwen3公式 Jev別のローカルモデル

3. 提案する全体構成

Web / App ブラウザ・iOS・業務アプリREST / JSON Flask API 認証 / セッションJEV互換API業務ルール / Python Decision Engine Qwen3 Local InferenceChoice / Noul / Score 確率正規化・閾値判定llama.cpp / MLX等 RAG Engine 文書分割 / Embedding類似検索 / メタデータ 根拠文書を状態へ追加 PostgreSQL + pgvector 文書・チャンク・Embedding判断履歴・確率・監査ログ ユーザー / 業務データ Python Modules 計算・通知・CSV・外部機器制御など

基本方針:LLMに全部を任せない。RAGは根拠検索、JEV互換層は判断、Pythonは確定処理を担当する。

4. Ubuntu / Mac を同一設計にする方法

レイヤーUbuntuMac共通化
Web APIFlask + gunicornFlask(開発)/ gunicorn同一Pythonコード
DB / RAGPostgreSQL + pgvectorPostgreSQL + pgvector同一スキーマ
LLMQwen3 GGUF + llama.cpp(CUDA/CPU)Qwen3 GGUF + llama.cpp Metal、またはMLXOpenAI互換ローカルHTTP APIを境界にする
JEV互換Flask内の共通Decision Engine。Choice / Noul / ScoreをJSONで定義完全共通
Embedding日本語対応の多言語Embeddingモデルをローカル実行完全共通
最初の実装では llama.cpp を共通バックエンドにするのが安全です。 UbuntuではCUDA、MacではMetalを利用でき、Flask側を変更せずに同じHTTPインターフェースを維持できます。Macで性能を詰める段階になったらMLXバックエンドを追加します。

5. 処理の流れ

① 入力② RAG検索③ State生成 ④ JEV互換判断⑤ 閾値判定⑥ Python実行

例:設備点検

{
  "state": {
    "report": "擁壁に新しい斜めクラックを確認。雨天後に湧水あり。",
    "rag_context": [
      "維持管理基準 4.2: 新規クラックと湧水の併発時は詳細確認...",
      "過去点検: 前回はクラックなし..."
    ]
  },
  "questions": {
    "category": {
      "type": "choice",
      "criteria": ["経過観察", "再点検", "専門家確認", "緊急対応"]
    },
    "urgent": {
      "type": "noul",
      "instruction": "早急な対応が必要か"
    },
    "severity": {
      "type": "score",
      "scale": ["軽微", "中", "大", "緊急"]
    }
  }
}

結果が urgent = 0.92 なら、「0.85以上は担当者へ通知」のようにPython側で明示的なルールを実行できます。判断と処理を分離するため、業務システムとして監査しやすくなります。

6. この構成で何ができるか

文書の自動振り分け

メール、報告書、問い合わせ、点検記録を複数カテゴリへ分類。確信度が低いものだけ人に回す。

RAG根拠付き判定

社内規程・マニュアル・過去記録を検索し、それを根拠状態として判断モデルへ渡す。

異常・緊急度判定

設備報告、災害情報、監視イベントを「通常 / 注意 / 警告 / 緊急」などに評価。

ワークフロー自動分岐

確率と閾値を使い、承認、再確認、通知、保留などの処理を自動分岐。

LLM回答の検査役

別のLLMが作った回答について、根拠不足、要修正、カテゴリ適合などを第二段階で判定。

検索結果の再ランキング

RAGで取得した複数資料を、質問への適合度で再評価し、上位だけを生成LLMへ送る。

センサー+文章の判断

数値計算はPython、ログや状態説明の意味判断はQwen3に担当させ、最終分岐を統合。

CSV / JSON自動処理

分類結果をJSON化し、CSV出力、DB更新、帳票生成、別システムへの連携に利用。

オフライン業務支援

モデル・DB・RAGを端末またはLAN内サーバに置き、機密情報を外部クラウドへ送らない構成が可能。

7. 特に相性が良い使い方

用途RAGJEV互換Python
点検・診断支援基準書・過去履歴状態分類・危険度閾値、計算式、通知
問い合わせ処理FAQ・契約・製品情報種別・緊急性担当振分け
防災支援地域資料・行動基準状況・優先度ルール判定、警告
設計・施工記録設計書・写真メタ情報不足情報・確認要否検査項目生成
AIエージェント業務知識次に行う行動の選択実際のAPI・機器操作

8. 通常の「ローカルLLM + RAG」より何が増えるのか

従来

RAGで資料を探してQwen3へ渡し、最終的に文章で回答させる。

RAG → Qwen3 → 「確認が必要と思われます」

JEV互換レイヤー追加後

文章回答とは別に、アプリが利用できる判断を返す。

RAG → Qwen3 Decision
→ {
  "action": "expert_review",
  "probability": 0.91
}
→ Pythonで処理
つまり「AIに答えてもらう」から「AIの判断をソフトウェア部品として使う」へ進めます。

9. 実装予定のAPI

Endpoint役割
POST /api/systemoneJEV互換のChoice / Noul / Score判断
POST /api/rag/searchpgvector類似検索
POST /api/rag/ingest文書登録、チャンク化、Embedding生成
POST /api/ask通常のRAG + Qwen3文章回答
POST /api/decideRAG検索を含む業務判断の一括実行
GET /api/decisions/<id>判断履歴、確率、使用根拠の確認
GET /healthzFlask / DB / LLM / RAGの死活確認

10. 判断履歴を保存する理由

JEV型の仕組みでは、単に最終回答を保存するだけでなく、何を見て、どの選択肢を何%と評価し、どの閾値によって処理したかを記録できます。

decision_log
├─ id
├─ created_at
├─ model
├─ state_hash
├─ retrieved_document_ids
├─ question_type
├─ choices / score
├─ probabilities
├─ selected_action
├─ threshold
└─ execution_result

これにより、後日「なぜこの処理になったのか」を追跡しやすくなり、精度改善用の評価データにもできます。

11. 初期構成案

項目初期採用理由
LLMQwen3 4B〜8B級 GGUFローカル運用と日本語性能のバランスを取りやすい
Inferencellama.cpp serverUbuntu CUDA / CPU、Mac Metalで共通化しやすい
Mac高速化候補MLXApple Silicon向けに後から追加可能
APIFlask既存Python資産・業務モジュールと統合しやすい
DBPostgreSQL 16+ / pgvectorRAG・業務DB・監査ログを一本化
Embedding日本語対応多言語モデル完全ローカルRAG
JEV互換型Choice / Noul / Score公式Jevの考え方に合わせる

12. 精度を上げるための二段階構成

初期版はQwen3に確率分布を構造化出力させます。その後、よりJev型に近づけるために候補トークンのlogits / logprobsを直接利用する方式を追加できます。

段階方式長所注意
Phase 1Qwen3 + JSON確率出力早く実装でき、機種差が少ない自己申告確率なので校正が必要
Phase 2候補logitsから確率算出生成文に依存せず高速化しやすいトークナイズや候補設計の検証が必要
Phase 3検証データによるCalibration0.8なら実際にも約80%正しい、に近づける用途別の正解データが必要

13. 実装上の重要原則

01

AIに計算させない

確定的な数式、日付計算、閾値比較はPythonで処理。

02

AIに勝手な候補を作らせない

Choiceはアプリ側で候補を定義し、その中だけから選択。

03

低確信度は人へ戻す

「不明」を無理に自動化せず、閾値以下は確認待ちへ。

14. 最終的に目指す形

                      ┌──────── 通常の回答 ────────┐
ユーザー / センサー → RAG → Qwen3               │
                      │                           ↓
                      └→ JEV互換 Decision → Python → 実行
                              │
                              ├→ 自動処理
                              ├→ 再検索
                              ├→ 別LLMへ依頼
                              ├→ 人へ確認
                              └→ 保留

「話すAI」と「判断するAI」を分け、その判断結果をPythonが安全に実行する。 これが今回のローカルJEV互換基盤の中心です。

15. 参考情報(2026-09-21確認)

Jevは公開直後の技術であり、SDK、モデル、ローカル互換実装は今後変化する可能性があります。本資料では「公式Jev」と「Qwen3等によるJev互換実装」を明確に区別しています。

ローカルJEV互換基盤 構想資料 — 2026-09-21

No responses yet

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA


トップへ戻る