地平線まで行ってくる。

記録あるいは忘備録。時には検討事項。

AIエージェントを使って机上で軽量高エントロピー合金(LW-HEA)の探索パイプラインを回してみる。

AIエージェントを使って机上で軽量高エントロピー合金(LW-HEA)の探索パイプラインを回してみる。

大規模言語モデル(LLM)を活用したAIエージェントの検証と、自律的な研究探索パイプラインの構築にチャレンジしました。

当初は DeepSeek や LFM などの新興モデルの性能評価も目的とし、開発アシスタントとして OpenCode を使用してスタートしました。しかし、途中で OpenCode 側で API キーに関するトラブルが発生し一時的に作業が中断したため、その後は Antigravity CLI+ Gemini Argonへ切り替えて検証を継続しました。

テーマとして取り上げたのは、次世代の構造材料として注目される軽量高エントロピー合金(Light-Weight High-Entropy Alloys, LW-HEA)の組成設計と、それに伴う文献・特許ナレッジの自動構造化です。

個人的なPC環境(ローカルLLM + 外部APIのハイブリッド)という制約の中で、自律型エージェントと計算材料インフォマティクス(MI)の評価エンジンを組み合わせ、情報の収集からスクリーニング、ナレッジ蓄積、知見整理・考察、そしてダッシュボード構築に至る一連のパイプラインを一気通貫で回した記録です。


背景:軽量高エントロピー合金(LW-HEA)における設計課題

高エントロピー合金(High-Entropy Alloys, HEA)は、単一の主要元素に添加物を加える従来の合金設計とは異なり、5種類以上の主要元素を等比率近くで混合することで、高い配置エントロピー効果($\Delta S_{\text{mix}} \ge 1.5R$)により単相固溶体を安定化させる材料群です。

しかし、Cantor合金(CoCrFeMnNi)に代表される従来の主要HEAは高密度な遷移金属を主成分とするため、密度が 6.0 〜 12.0 g/cm³ と重く、航空宇宙や自動車、先端ロボティクスで要求される「軽量化」の面で課題がありました。

これに対し、軽量高エントロピー合金(LW-HEA)は、Al(アルミニウム)や Ti(チタン)などの軽量元素を骨格とし、純チタン(4.51 g/cm³)以下の超軽量でありながら、チタン合金を上回る高比剛性($E/\rho > 25\text{ GPa}\cdot\text{g}^{-1}\text{cm}^3$)と超高耐食性を両立させることを目指す野心的な研究領域です。

ただし、軽元素(Al, Si等)と早期遷移金属(Ti, V, Cr, Nb等)を多成分で共存させると、負の混合エンタルピーにより脆性金属間化合物(Laves相やシリサイド)が析出しやすく、元素間の電位差に起因する微小ガルバニック腐食が進行しやすいという熱力学的トレードオフを抱えています。この広大な多元系組成空間から最適解を見つけ出すため、自動探索パイプラインを構築しました。


自動探索パイプラインの全体像

情報の収集から可視化までをエンドツーエンドで接続し、イテレーションを回す構造として以下の4ステージからなるパイプラインを設計しました。これだけ見ると特に目新しくもないと思います。自律的にパイプラインやスキル・ツールを構築しつつ進めさせます。重要なのは、最初の構想をそれなりに妥当性のあるものから始めることでしょうか。いくら自律的といっても情報収集が適切でなければ、残念な結果になってしまうこともしばしば。

【Stage 1: 収集 & 物理ガイド型スクリーニング】
  └─ 論文・特許(800+件)の構造化収集 + 物理法則(PDM/相安定性/密度)による一次絞り込み
       │
       ▼
【Stage 2: ナレッジの蓄積(Google OKF 準拠 Wiki 化)】
  └─ 抽出エンティティの Markdown 自動構造化 & WikiLinks 相互参照グラフの形成
       │
       ▼
【Stage 3: 知見の整理と導き出される考察】
  └─ 7トラック最適候補ポートフォリオの導出 & AIエージェント運用上の実証的考察
       │
       ▼
【Stage 4: ダッシュボード構築 & インターフェース化】
  └─ 2D/3D パレート境界の可視化 & 実験室向け VAR インゴット揮散補正計算ツールの統合

Stage 1: 文献・特許の収集と物理ガイド型スクリーニング

まず第1段階として、Web上の論文データや特許文献から組成値、物理定数、DOI、実験条件などのメタデータを自動抽出・構造化して収集します。イテレーションを回しながら、情報収集を拡大させます。

収集された候補に対し、ブラックボックスなAI推測だけに頼るのではなく、ドメイン知識に基づく物理法則・計算材料インフォマティクス(MI)の制約条件(Charter)を適用して一次スクリーニングを行います。

  • 密度制約: 超軽量化基準である $\rho \le 4.50\text{ g/cm}^3$
  • 耐食性モデル: 点欠陥モデル(Point Defect Model, PDM)による皮膜欠陥補償計算($\log{10}(I{\text{corr}}) \le -7.0\text{ A/cm}^2$)
  • 相安定性パラメータ: 単相固溶体化条件($\Omega \ge 1.1$)、原子サイズ差($\delta \le 6.6\%$)、価電子濃度(VEC)

Stage 2: ナレッジの蓄積(Google OKF 準拠 Wiki 化)

スクリーニングを通過した抽出データや文献情報は、分散・散逸させず蓄積・再利用できるナレッジ基盤へ自動投入します。人間があとから見ても分かるようにです。必要があれば人間が直接ナレッジに介入できます。

Google OKF(Open Knowledge Format)に準拠した構造化 Markdown ファイル群として蓄積を行い、WikiLinks([[...]])を用いた自動リンク形成によって、元素・相構成・特許出願人・物性値が相互に結びついたナレッジグラフを構築します。これにより、ローカル環境やRAG/LLMから即座にコンテキストを参照可能なオフラインWikiデータベースが形成されます。


Stage 3: 知見の整理と導き出される考察

蓄積されたナレッジとMIエンジンの出力を受け、AIエージェントが多角的な分析を行い、最終候補の導出と運用上の考察を整理します。

1. 最適候補ポートフォリオの導出

全方位の用途・制約を網羅するため、以下の7つのトラックに分類した候補組成ポートフォリオを自動導出しました。実際に有益な情報だったら、嬉しいです。この様に様々な組成(成分)を提案します。また、文献をベースに想定する製造方法も提案できています。

# トラック名 代表組成 (at%) 密度 $\rho$ (g/cm³) 比剛性 $E/\rho$ Pugh比 (B/G) 耐食性 $\log I_{\text{corr}}$ 原子サイズ差 $\delta$ (%) 特徴・推奨用途
① 標準本命 (Baseline) Al30.0 Ti35.0 V15.0 Cr10.0 Nb5.0 Si5.0 4.45 29.70 2.24 -7.90 6.52 Sc/Mgフリー、真空アーク溶解(VAR)標準対応の第一候補。
② 最高耐食 (High-Cr) Al33.0 Ti35.0 V5.0 Cr13.0 Nb9.0 Si5.0 4.49 29.70 2.19 -8.09 6.57 Cr を 13% に増強し、不飽和耐食性を極大化した設計。
③ 耐孔食・高剛性 Al30.0 Ti35.0 V15.0 Cr10.0 Mo5.0 Si5.0 4.50 30.73 2.18 -7.85 6.55 Nb を Mo に置換。海水塩化物環境での耐孔食性を強化。
④ Siレス高靭性 Al30.0 Ti35.0 V10.0 Cr15.0 Zr5.0 Sc5.0 4.42 30.57 2.09 -8.00 4.98 シリサイド脆化リスクを排除し、格子歪みを最小化。
⑤ 厳密 Ω≥1.10 固溶体 Al25.0 Ti35.0 V15.0 Cr10.0 Nb5.0 Sc10.0 4.44 28.46 2.25 -7.88 6.38 相安定性条件($\Omega \ge 1.15$)を完全クリアした単相BCC設計。
⑥ 低偏析解 (Nb/Mo-Free) Al35.0 Ti35.0 V10.0 Cr10.0 Mn5.0 Si5.0 4.50 29.35 2.15 -7.68 6.62 高融点元素を排除。融点分散を抑え溶け残りを防止。
⑦ 超低密度 (MA+SPS) Al30.0 Ti35.0 V5.0 Cr15.0 Zr10.0 Mg5.0 4.41 29.96 2.06 -7.40 6.40 Mg 配合による極限軽量化。固相焼結(MA+SPS)専用。

2. エージェント運用から得られた知見と考察

イテレーションを周回させる中で、AIエージェントの挙動に関する実践的な課題と対策が明確になりました。

  • Argonは流石でした: 後半で投入した Argon は安定しており、指定した数式モデルやフォーマットに従って手堅く計算と分析を進める能力を示しました。とはいっても、OpenCode経由で試したDeepSeek V4.1 FlashやGLM-5.3-flashでも利用できそうした。しかし、Beamは、この目的には力不足でした。Antifravity+Argonの組み合わせは使いやすかったです。
  • 思考の補正は櫃お湯(Human-in-the-Loop): エージェントは「Si を添加して低密度化する」といった特定の成功パターンが固まると、そこに固執して局所最適に陥る傾向が見られました。明らかに視野が狭くなった際には、人間側で「Siレスの条件(Scenario A)を強制挿入する」などの軌道修正や補正を行う手引きを入れないと小さくまとまっちゃいます。ヒトの知見は大事です。

Stage 4: ダッシュボード構築 & インターフェース化

パイプラインの最終出口として、得られた知見や評価データを人間がインタラクティブに確認・操作できるダッシュボードを構築します。これは、後で材料設計に活かすことができるためです。最終的な成果のまとめ、と思ったのですが、人間が途中経過をチェックし適切に介入するHOTL(Human-on-the-loop)用のツールとしても役に立ちました。


まとめ

AIエージェントを単なる質疑応答ツールとして使うのではなく、「収集 → 物理スクリーニング → ナレッジ蓄積 → 知見整理・考察 → ダッシュボード化」という一連のパイプラインとして接続して周回させることで、材料探索でも机上で十分に価値のあるシステムを構築できました。

今後は、シミュレーションエンジンとのダイレクト接続や、実験プロトコル自動生成との連携など、夢は広がります。別の材料でも試してみたい・・・。だれか、私にトークンをください。

Hermes Agent をDocker コンテナ隔離で手軽に動かしてみる。

Hermes Agent をDocker コンテナ隔離で安全かつ手軽に動かしてみる。

自律型AIエージェント「Hermes Agent」をローカル環境で常設してみたいと考えて、「ホストOSの環境や設定を汚さず動かしたい(セキュリティを加える)」、「Docker Composeの複雑なコマンドやプロファイル管理に煩わされたくない(運用の手軽さを加える)」を試してみます。


1. ホスト環境を汚さないコンテナで実行

自律型エージェントはコード実行やWebアクセスを行うため、ホスト環境への不必要な影響や権限昇格を防ぐセキュリティ設計が不可欠です。本リポジトリでは以下のコンテナセキュリティ原則が適用されています。

① ホストOS非侵入・非Root実行

なにはともあれ基本。 - 特権モードやホストネットワーク改変を要求せず、非 root 権限の Docker 環境で動作します。 - コンテナ内プロセスにも適切なパーミッション制御が施され、ホスト側ファイルを保護します。

② 最小限のポートバインドとコンテナ間閉塞

  • ホスト側に露出するポートはローカルホスト限定にバインドされています。
  • SearXNG や Firecrawl などの内部マイクロサービスはコンテナ間ブリッジネットワーク内に完結しており、外部ネットワークから直接アクセスできないよう保護されています。

③ 権限昇格の防止

こちらもやっておいた方が良いかと。 - Docker Compose 設定において security_opt: [no-new-privileges:true] を指定し、コンテナ内での不必要な権限昇格を防止しています。 - 不要な Linux ケーパビリティを削除した状態でプロセスを実行します。

④ プロキシフィルタとログローテンション

その他の気になるところも。 - Hermes Agent 内蔵の SSRF(ローカルLAN保護)機能。エージェントが実行するWeb検索・抽出ツールは、プライベートIP(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)宛てのリクエストを自動ブロック。 - 全コンテナにメモリ上限を設定(OOM によるホスト応答停止を防止)し、Docker ログローテーション(max-size: 10m, max-file: 3)


2. ./manage.sh による一括管理とプロファイル切り替え

上記のセキュリティ構成をいちいち構築するのがめんどいのでスクリプトで起動できるようにしました。

hermes-agents-quickstart/
├── docker-compose.yml          # 公式イメージ用 Compose 設定
├── docker-compose.override.yml # ローカルビルド用 Compose オーバーレイ
├── manage.sh                   # 統一管理スクリプト(TUI / プロファイル切り替え)
├── .env.example                # 環境変数テンプレート
├── config.yaml.example         # Hermes Agent 設定テンプレート
├── data/                       # 設定・セッションデータの永続化マウント
└── workspace/                  # 作業ディレクトリマウント

セットアップの手軽さ (TUI ウィザード)

./manage.sh setup を実行するとHermes AgentのSetupの対話型 TUI が起動し、APIキーや環境設定を画面上で選択・入力できます。

ユースケース別プロファイル

./manage.sh のサブコマンドで必要なサービス構成を選択できます。

サブコマンド 起動構成 用途・特徴
./manage.sh search up WebUI + SearXNG ローカルWeb検索を組み合わせた標準的な開発・テスト構成
./manage.sh bot up バックグラウンド Daemon + SearXNG メッセージングボットとして24時間常駐運用
./manage.sh cli ターミナル対話 (TUI) WebUI を建てず端末上で直接エージェントと対話
./manage.sh full up WebUI + SearXNG + Firecrawl Web検索に加え、ページの自動 Markdown 構造化まで統合
./manage.sh gateway up WebUI のみ(最軽量) 外部検索機能を使わず、エージェントの基礎動作のみ確認

直前と同じ構成で再起動する場合は、プロファイル名を省略して ./manage.sh run または ./manage.sh up のみで即座に再開可能です。


まとめ

「自律型AIエージェントを試したいが、ホストOSに直接インストールしたくない」「毎度Dockerのコマンドを叩かずにサクッと動かしたい」「WebUIは要らないくて、Discordとの連携だけでいい」は達成できました。

github.com

WSL2環境でXeStrataを動作させる手順と技術的メモ

WSL2環境でXeStrataを動作させる手順と技術的メモ

はじめに

MoE(Mixture of Experts)モデルをGPUのVRAMとホストRAMに分散配置して動作させる推論エンジン XeStrata を、Windows 11のWSL2環境で試してみました。

XeStrataはUbuntu 26系を動作要件を想定して設計されています。そのため、WSL2環境で動かす際にはいくつかの固有の課題がありました。

本記事では、Docker Desktopを使わずにWSLの標準コンテナ機能(wslc)を利用して環境を構築し、遭遇したエラーへの対処と、手元のRTX 3060(12GB)環境で動作確認を行うまでの手順を技術メモとして記録します。パッチで対応しているので、公式が対応するまでのつなぎとなりますが、wslコンテナを使うと簡単にいろいろと動かせそう・・だとのチャレンジの一環でもあります。


検証環境

  • ホストOS: Windows 11
  • WSLバージョン: 3.0.1.0(wslc.exe 付属)
  • CPU: AMD Ryzen 5 7600 (6コア)
  • GPU: NVIDIA GeForce RTX 3060 (12GB VRAM)
  • 割り当てRAM: 31GB(.wslconfig で設定)
  • 使用モデル: llm-jp-4.1-32b-a3b-thinking-Q4_K_M(GGUF形式、約21.5GB)

1. 構築方針:WSLコンテナ(wslc)の利用

Docker Desktopは使わず、WSL(2.9.3以降)に組み込まれているコンテナCLI wslc.exe を利用しました。

# コンテナの起動(GPUパススルーとポート転送を指定)
wslc run -d --name XeStrataLab --gpus all -p 8095:8095 ubuntu:26.04 tail -f /dev/null

この方法の利点は以下の通りです: - Docker Desktopの導入が不要 - 不要になった際は wslc remove XeStrataLab を実行するだけで、数十GBあるモデルデータごとストレージ領域を解放できる


2. WSL2環境で発生した課題と対処

公式のdebパッケージ(xestrata-contrib-cuda13.1)をインストール後、セットアップを実行した際に3点の問題に遭遇しました。

(1) GPU検出の失敗 (/sys/class/drm の不在)

現象

xestrata --check の実行時、以下のように出力されて処理が止まりました。

=== Step 1: checking your PC ===
  [X] no Intel GPU ..., no AMD GPU ... and no NVIDIA GPU on NVIDIA's driver found

原因

XeStrataの検出ロジック(/usr/share/xestrata/setup.py の gpus())は、物理Linuxマシンのsysfsノード /sys/class/drm/card* を走査してGPUを探します。
WSL2ではGPUがDirectX仮想化ドライバ(/dev/dxg)経由で接続されるため、/sys/class/drm が存在しません。その結果、コンテナ内で nvidia-smi が正常に動いていても検出対象になりませんでした。

対処

sysfs走査で見つからなかった場合のフォールバックとして、nvidia_smi() の出力を参照し、レンダーノードに /dev/dxg を設定するコードを追加しました。

# /usr/share/xestrata/setup.py の gpus() 関数への追加
if not found and not nvidia and not amd:
    smi = nvidia_smi()
    for pci, info in smi.items():
        nvidia.append({
            "name": info.get("name", "NVIDIA GPU"),
            "vram_gb": info.get("mib", 0.0) / 1024,
            "device_id": 0,
            "driver": "nvidia",
            "integrated": False,
            "supported": True,
            "pci": pci,
            "bar_gb": info.get("mib", 0.0) / 1024,
            "link": "WSL2 GPU Passthrough",
            "render": "/dev/dxg",
            "vendor": "nvidia",
            "cc": info.get("cc")
        })

(2) メモリ読み込み時のエラー (CUDA_ERROR_ILLEGAL_ADDRESS)

現象

モデルの読み込み時に、以下のエラー(コード700)が発生してエンジンが停止しました。

UR CUDA ERROR: Value: 700
Name: CUDA_ERROR_ILLEGAL_ADDRESS
Description: an illegal memory access was encountered

原因

XeStrataの推論エンジンはIntel SYCLコンパイラ(intel/llvm)とUnified Runtime(UR)を経由して動作します。 1. 推奨される libcublas-13-1 が未導入だったため、内製カーネルにフォールバックしていたこと 2. モデルの重みをすべてホストRAMに一括展開しようとした際、WSL2のメモリ境界でアクセス違反が生じたこと

対処

  1. apt install --no-install-recommends libcublas-13-1 をインストールし、ライブラリパスを設定。
  2. モデル設定に --mmap-experts(Low-RAMモード)を指定。

これにより、必要なExpertのみがVRAM(約7GB)に配置され、残りはファイルキャッシュ経由で読み込まれるようになり、エラーが解消されました。


(3) Web UIに接続できない問題

現象

サーバー起動後、Windowsホスト側のブラウザから http://127.0.0.1:8095 を開くと接続リセット(Connection reset)になりました。

原因

APIサーバー(server.py)の待ち受けIPアドレスが既定で 127.0.0.1(コンテナ内部のローカルホスト)となっていたため、Windows側からの接続が拒否されていました。

対処

設定でバインドアドレスを 0.0.0.0 に変更しました。


3. 動作確認結果

上記の対処を行った後、WindowsブラウザからWeb UIが開き、チャット推論が動作しました。

モデルとして llm-jp-4.1-32b-a3b-thinking-Q4_K_M を動かした際のログ記録です:

strata plain: the VRAM tier filled: 1536 experts
strata plain: 32 MoE layers x 128 experts, 1536 VRAM slots (48 a layer, 7.03 GiB), 5 CPU workers
strata (qwen3moe): prompt matrix products on oneMath (cuBLAS)

[strata] answering: 1544 tokens in 126 s (12.9 tok/s), expert cache 52.7% hit
  • 生成速度: 約 12.9 tokens/sec
  • Expert Cache Hit率: 52.7%
  • VRAM使用量: 約 7.03 GiB
  • メモリ使用量: 約 10 GiB

RTX 3060(12GB)とシステムRAMの組み合わせにおいて、32B規模のモデルがなんとか実用的な速度で動作することを確認できました。


4. 自動化スクリプトの公開

上記の手順(コンテナ作成、依存関係の導入、パッチ適用、起動・停止)をまとめたPowerShellスクリプトをGitHubに配置しています。

リポジトリ: chottokun/xestrata-on-wsl

主なファイル

  • setup-xestrata.ps1: 環境構築スクリプト
  • start.ps1: コンテナおよび推論サーバーの起動
  • stop.ps1: サーバー停止およびVRAM/RAMの解放
  • teardown-xestrata.ps1: コンテナおよびデータの完全削除

おわりに

XeStrataはWSL上でのテストは少ないようです。そのため初期設定に調整が必要でしたが、GPU検出とメモリ設定の2点を合わせることで安定して動作させることができました。

同様の環境で検証される方の参考になれば幸いです。

自作のembedding apiでgoogle/embeddinggemma-2とcl-nagoya/ruri-v3を評価してみた。

自作の OpenAI 互換 Embedding & Rerank API サーバー「embedding_jp_api」において、google/embeddinggemma-2を追加したので、日本語情報検索ベンチマークである 日本語 Nano-BEIR (Nano-BEIR-ja) を用いた性能評価を実施しました。


1. 埋め込みモデル(一次検索 / 5,035件コーパス全体)単体評価

全 5,035 件のコーパスに対する一次検索性能(Retrieval)を評価しました。

モデル名 ベクトル次元 Accuracy@1 MRR@10 NDCG@10 Recall@50 Recall@100 スループット Peak VRAM
cl-nagoya/ruri-v3-30m 256d 0.4200 0.5577 0.6213 0.9600 0.9600 592.9 docs/s 1.54 GB
cl-nagoya/ruri-v3-310m 768d 0.5200 0.6317 0.6869 0.9400 0.9800 331.8 docs/s 4.11 GB
google/embeddinggemma-2 768d 0.4600 0.5950 0.6556 0.9200 0.9800 188.9 docs/s 22.42 GB

考察

  • ruri-v3-30m の一次検索適性: 256次元・592.9 docs/s という低負荷でありながら、Recall@50 = 0.9600 (96%) を達成しており、後続の再ランキング処理に対して正解をほとんど漏らさず候補を引き渡せる第一段モデルとして極めて優秀です。
  • ruri-v3-310m の単体精度: 埋め込みモデル単体としては最高レベルの NDCG@10 = 0.6869 を示しました。

検証環境および評価条件

評価は Google Colab の GPU 環境(A100)上でのNotebookで行いました。

  • 評価環境: Google Colab (GPU インスタンス)
  • 評価用 Notebook: embedding_jp_api-nano-beir.ipynb
  • 評価ベンチマーク: 日本語 Nano-BEIR (Nano-BEIR-ja)
    • 複数ドメイン(JaCWIR, MInD, NFCorpus-ja, SciFact-ja 等)の小規模テストセット群
  • 評価指標:
    • NDCG@10: Top-10 検索結果のランキング品質
    • MRR@10: 最初の正解文書の出現順位
    • 推論速度 (ms/doc): 各モデルの単体処理速度

2. 再ランキングモデル(二次検索 / Top-50 プール)単体評価

ruri-v3-30m で抽出した上位50件候補(正解が含まれない場合は末尾に正解を補填する正解注入プロトコル適用)に対する単体スコアリング能力を測定しました。

モデル / 構成 モデルタイプ Accuracy@1 MRR@10 NDCG@10 平均レイテンシー Peak VRAM
cl-nagoya/ruri-v3-reranker-310m Cross-Encoder 0.5400 0.6719 0.7415 0.189 s 3.31 GB
Qwen/Qwen2.5-1.5B-Instruct Logit Gate (LLM) 0.2200 0.4134 0.5068 0.653 s 17.73 GB

考察

  • Cross-Encoder(ruri-v3-reranker-310m)は、クエリと文書のクロスアテンションにより、文脈全体の類似度ソートにおいて高い精度(Accuracy@1 = 0.5400)を示します。
  • Logit Gate 単体では、ゼロショット分類境界のバイアスにより全件ランキング精度は低下するものの、次項以降に示す「条件付き足切り」および「Hard Negative 判定」において固有の機能を発揮します。

3. 事前足切りゲート(API Router drop_failed=True)の検証

embedding_jp_api に標準実装されている Logit Router 機能(drop_failed=True, threshold, use_ascii_boost=True) を一次検索の直後に配置し、低スコア文書をサーバー側でドロップさせた際のカスケード性能(ノイズ削減率 vs 正解保持率)を検証しました。

構成・しきい値 平均通過件数 / 50件 ノイズ削減率 (%) 正解保持率 (Oracle Recall) Accuracy@1 NDCG@10 平均レイテンシー
[単体] Cross-Encoder (CE) 50.0 件 0.0% 100.0% 0.5400 0.7415 0.188 s
API Router (th=0.20) → CE 1.78 件 96.44% 40.0% 0.3800 0.3877 0.726 s
API Router (th=0.35) → CE 0.76 件 98.48% 38.0% 0.3800 0.3800 0.645 s
API Router (th=0.50) → CE 0.36 件 99.28% 38.0% 0.3800 0.3800 0.642 s

考察

  • drop_failed=True により、無関係なノイズ文書を 96.4%〜99.3% の高確率で事前遮断できます。
  • 一方で、厳しいしきい値(th ≥ 0.20)を一律適用すると、正解文章の保持率(Oracle Recall)が 40.0% まで低下し、結果として最終正解率が削られるトレードオフが確認されました。
  • したがって、無条件の厳格足切りではなく、緩和設定(th=0.10 付近)や特定ドメイン制限に絞った運用が推奨されます。

4. 事後フィルタ(Hard Negative Verifier)としての Logit Gate 活用

Cross-Encoder は語彙やトピックの類似度に強く依存するため、「文脈やキーワードは酷似しているが、肝心の回答が含まれていない文書(Hard Negative)」 に対して高スコアを付与し、Top-1 を取り違えるケースが存在します。

そこで、Cross-Encoder が全50候補から絞り込んだ上位5件(Top-5)の競合候補に対し、Logit Gate (Qwen2.5-1.5B-Instruct + use_ascii_boost=True) を「最終審判(Verifier / Arbitrator)」 として投入する是正効果を評価しました。

評価結果 (N=50 クエリの上位5件競合プール)

評価指標・結果項目 測定値 内容および意味
Cross-Encoder 単体 Accuracy@1 0.5400 (27/50) ベースライン
Logit Gate 審判後 Accuracy@1 0.3800 (19/50) 全件無条件判定時のスコア
CE + Logit Gate (等加重アンサンブル) 0.4800 (24/50) 均等アンサンブル時のスコア
CE 誤答を Gate が正解に見破って是正 (Win) 4 件 Hard Negative の是正成功事例
CE 正解を Gate が誤答に変えてしまったケース (Loss) 12 件 ゼロショット不確実性による失点

成功事例 (Win: Cross-Encoder の類似度誤認を Logit Gate が看破した例)

  1. クエリ: 第二次世界大戦で最も大きかった戦車は何でしたか
    • Cross-Encoder の誤答: doc1520311 (大戦中の重戦車に関する類似文章だが、最大戦車の具体的名称・答えが不在)
    • Logit Gate の是正: 事実関係の含有有無を判断し、真の正解文書 doc82650 を見破って 1位に昇格。
  2. クエリ: 「ウッディー・ザ・ウッディーピッカー」映画の撮影はどこで行われましたか?
    • Cross-Encoder の誤答: doc1827382 (映画の概要・キャストに関する類似文章)
    • Logit Gate の是正: 具体的な撮影場所が記述された doc33193 を識別し 1位に昇格。

設計上の示唆

  • 小型LLM の場合、無条件に Logit Gate の判定で上書きすると Loss 件数が上回ってしまいます。
  • したがって、CE_score[0] - CE_score[1] < threshold(Cross-Encoder の Top-1 と Top-2 のスコアが僅差で判定に迷っているグレーゾーンクエリ) のみに限定して Logit Gate を呼び出す「条件付き動的エスカレーション(Conditional Verifier)」を組むことで、Cross-Encoder の高い基本精度(Acc@1 = 0.54)を維持したまま、Hard Negative の是正(Win)を取り込む設計が最も合理的です。
  • もちろん、それなりのLLMやDecision(Jevなど)モデルを使えば、正確さも向上するでしょう。

まとめ

日本語 Nano-BEIR ベンチマークを用いた実測を行った結果、以下の知見が得られました。

  1. 一次検索 (Retrieval): 軽量な ruri-v3-30m (256d) で Top-50 候補を抽出(Recall@50 = 96.0%)する構成が速度・精度ともに最適。
  2. 二次検索 (Reranking): 大半のクエリは ruri-v3-reranker-310m (Cross-Encoder) でリランキングできます。
  3. 動的エスカレーション (Hard Negative Verifier): Cross-Encoder のスコア差が僅差(マージン不足)のクエリにのみ Logit Gate でフィルタリングを動的に適用することで、ハルシネーション要因となる Hard Negative を回避可能でしょう。
  4. google/embeddinggemma-2はテキスト処理だけ言えば突出してはいませんが、日本語でも十分な実力を持つマルチモーダルなembeddingでした。テキスト以外のデータも扱えるため、使いやすいのではないでしょうか。

Gitgist

gist.github.com

二段カスケード検索における確信度駆動型ハイブリッドルーティングを試してみる。

二段カスケード検索における確信度駆動型ハイブリッドルーティングを試してみる。

自作の「embedding_jp_api」では、高速なベクトル検索(Stage 1: Bi-Encoder)と文脈精査(Stage 2: Cross-Encoder または Logit Gate)を組み合わせた二段カスケード構成で運用しています。

普段から高速で取り回しの良い Cross-Encoder と、ニアミス遮断に強い Logit Gate の両方を扱っている中で、「それぞれ得意・不得意がはっきりしているなら、Cross-Encoder が判定に迷ったギリギリのときだけ Logit Gate に回したらどうなるだろう?」と思い立ち、手元の RTX 3060 (12GB) 環境で気楽に試してみることにしました。

本記事では、多言語対応の google/embeddinggemma-2 や日本語モデル cl-nagoya/ruri-v3 シリーズ、各種精密判定層(ruri-v3-reranker-310m や Qwen 系 Logit Gate)の組み合わせを一通りベンチマークしつつ、Cross-Encoder のスコア差(マージン)を閾値にした動的ルーティングの挙動を整理してみます。うまくいったら、精度上がるかもと期待しつつ。

※専門分野ではないので不正確な記述があるかもしれません。笑ってください。


検証環境および評価データセット

評価データのバイアスを抑制するため、性質の異なる2つのデータセットを用意し、同一のGPU環境(RTX 3060 12GB, CUDA 13.4, PyTorch 2.13.0)でベンチマークを測定しました。

評価指標・項目 合成データセット (v2_540) ハイブリッドデータセット (hybrid_1200)
総文書数 / クエリ数 540件 / 180クエリ 1,200件 / 400クエリ
データソース 6業務ドメインのルールベース合成 HF公開実コーパス(ruri-v3-dataset-reranker)200クエリ + 実務6ドメイン 200クエリ
Near-Miss の性質 特定数値や結論を抜き取った概要文(Factoid偏重) 多層的 Hard Negative(前提違い、主題違い、Web長文、数値欠落)
プール比率 1クエリあたり Positive 1, Near 1, Unanswerable 1 1クエリあたり Positive 1, Near 1, Unanswerable 1
測定ハードウェア NVIDIA GeForce RTX 3060 (12GB VRAM) 同左

Stage 1 (Dense Retrieval 粗選別) の性能比較

1,200件のハイブリッド実コーパスに対する Stage 1(Dense Retrieval)単体の検索性能および候補回収率(Recall)を評価しました。

Stage 1 モデル ベクトル次元 クエリ推論 (ms) コーパス速度 (docs/s) Recall@1 Recall@5 (回収率) Recall@10 特徴
ruri-v3-310m 768d 30.56 ms 192 docs/s 76.75% 99.00% 99.75% 回収率が高く、日本語表現の適合性に優れる
ruri-v3-30m 256d 0.57 ms 1,784 docs/s 72.75% 96.00% 98.50% 軽量・高速。0.57 ms で Recall@5 96% を確保
EmbeddingGemma-2 (768d) 768d 2.31 ms 338 docs/s 68.75% 96.00% 99.75% 多言語・画像対応。768次元モデル
EmbeddingGemma-2 (256d MRL) 256d 2.31 ms 346 docs/s 69.25% 95.75% 98.50% Matryoshka表示学習対応。256次元でRecall@5 95.75%

評価結果として、全モデルにおいて Top-5 候補(Recall@5)時点で 95.75%〜99.00% の正解文書が包含されることが確認できました。これにより、Stage 1 の上位5件を Stage 2 へ渡すカスケード構成の妥当性が示されます。特に ruri-v3-30m は 0.57 ms の処理時間で 96.0% の候補を回収しており、第1段として効率的です。


Stage 1 + Stage 2 カスケード構成の実測評価

Stage 1 と Stage 2(精密判定層)を組み合わせた全8通りのカスケード構成における End-to-End(E2E)処理時間と Top-1 正解率を評価しました。

1. 1,200件ハイブリッド実コーパスにおける E2E 性能 (N=400 クエリ)

カスケード構成 (Stage 1 + Stage 2) E2E 平均レイテンシー Stage 1 内訳 Stage 2 内訳 カスケード後 Top-1 正解率 評価
① ruri-310m + Cross-Encoder 72.56 ms 30.6 ms 42.0 ms 88.25% 正解率重視の構成
② ruri-30m + Cross-Encoder 42.57 ms 0.6 ms 42.0 ms 87.50% 低遅延と精度のバランスに優れた構成
③ Gemma (768d) + Cross-Encoder 44.31 ms 2.3 ms 42.0 ms 86.75% 多言語・画像対応バイエンコーダー + Cross-Encoder
④ Gemma (256d) + Cross-Encoder 44.31 ms 2.3 ms 42.0 ms 86.00% 256次元次元削減モデルによる運用
⑤ ruri-310m + Logit Gate 233.56 ms 30.6 ms 203.0 ms 76.50% Logit Gate 単体としては最高精度だが長文で失点
⑥ Gemma (256d) + Logit Gate 205.31 ms 2.3 ms 203.0 ms 76.25% Gemma 256d と Logit Gate の組み合わせ
⑦ Gemma (768d) + Logit Gate 205.31 ms 2.3 ms 203.0 ms 75.75% Gemma 768d と Logit Gate の組み合わせ
⑧ ruri-30m + Logit Gate 203.57 ms 0.6 ms 203.0 ms 75.00% 最軽量モデルと Logit Gate の組み合わせ

2. 合成データセットと実コーパスにおける精度変化の分析

評価データセットの違いによって、モデル間の正解率の序列が変化する傾向が確認されました。

Stage 2 方式 合成データ (540件) ハイブリッドデータ (1,200件) 精度変化 要因分析
Cross-Encoder 78.33% 88.25% +9.92% 単純な数値欠落の検出漏れがあった一方、多様なテキスト間の文脈適合性識別において機能。
Logit Gate 82.22% 76.50% -5.72% 明確な条件判定(Factoid)では高精度を示したが、複雑なWebテキストでは過剰な棄却が多発。

ルールベースで作成した合成データ(540件)では、回答の十分性を二値判定する Logit Gate(82.22%)が Cross-Encoder(78.33%)を上回りました。一方、実際のWebテキストを含むハイブリッドデータ(1,200件)では、文脈全体の意味的適合度を連続値で評価する Cross-Encoder(88.25%)が Logit Gate(76.50%)を上回る結果となりました。


エラー傾向の分析(Failure & Rescue Analysis)

ログから抽出された事例をもとに、各方式における判定特性を分析しました。

1. Logit Gate が Cross-Encoder の誤判定を補正した例

傾向: 語彙類似度の高い不十分なテキストの排除

  • クエリ: KubernetesでPodがExit Code 137で終了する主な原因と対処法は何ですか?
  • Cross-Encoder の予測 (誤解文を選択): 「Podが予期せず終了する場合、kubectl describe pod コマンドで Last State を確認します。終了コードが137を示す場合、シグナルによりプロセスが強制停止されています。リソース監視ダッシュボードでノード全体の負荷やCPU使用率を確認することが推奨されます。」 (分析: 語彙「137」「Pod」「終了」の重なりにより、CE のスコア差は θ = 0.002 と拮抗)
  • Logit Gate の予測 (正解文を選択): 「Exit Code 137は、コンテナがメモリ制限(limits.memory)を超過してLinuxカーネルのOOM KillerによってSIGKILLされたことを意味します。対処法としては、Podのリソース制限値を引き上げるか、アプリケーションのメモリリークをプロファイリングして解消します。」 (分析: Logit Gate はクエリの要求(原因と対処法)に対する記述の有無を判定するため、対処法を欠いたテキストを非選択と処理)

2. Cross-Encoder が Logit Gate の誤判定を補正した例

傾向: 主題の不一致の識別

  • クエリ: アーリントンカップは何歳限定の競走ですか?
  • Logit Gate の予測 (誤解文を選択): 「パッカーアップステークス…3歳牝馬限定の重賞競走である。2021年まではアーリントンパーク競馬場で開催されていたが…」 (分析: 「アーリントン」「3歳限定」の単語が含まれるため、Logit Gate が条件充足と判定)
  • Cross-Encoder の予測 (正解文を選択): 「アーリントンカップ…出走資格:サラ系3歳」 (分析: Cross-Encoder は文脈全体の整合性を考慮し、主語が「アーリントンカップ」であるテキストに対してスコア差 Δ = 0.77 で正解を選択)

確信度駆動型(Confidence-Aware)ハイブリッドルーティング

両方式の判定特性を活かすため、Cross-Encoder の上位2件のスコア差(マージン Δ = s_top1 - s_top2)を判定確信度として利用し、Δ < θ_margin となる閾値以下のクエリのみを Logit Gate に転送する動的ルーティングを構成しました。

1. マージン閾値 θ_margin の感度分析 (1,200件ハイブリッドデータセット)

マージン閾値 θ Gate 転送率 (%) カスケード正解率 CE単体正解率 Gate単体正解率 平均 E2E レイテンシー 評価
0.00 (CEのみ) 0.0% 87.50% 87.50% 75.00% 42.6 ms 全件 Cross-Encoder 処理
0.05 11.0% 88.00% 87.50% 75.00% 72.8 ms CEの僅差クエリ11%を転送。正解率88.00%に向上
0.10 16.0% 86.25% 87.50% 75.00% 83.0 ms 転送率増加に伴い Logit Gate の誤判定が混入
0.20 22.0% 86.50% 87.50% 75.00% 95.2 ms 精度は安定するが遅延が増大
1.00 (全件Gate) 100.0% 75.00% 87.50% 75.00% 203.6 ms 全件 Logit Gate 処理

全件を Logit Gate に転送すると正解率は 75.00% にとどまりますが、Cross-Encoder のスコアが拮抗した 11.0% のクエリに限定して Logit Gate を適用することで、正解率は 88.00% に向上しました。平均レイテンシーは 72.8 ms となります。

2. Stage 1 スコア差(Δ_dense)による Stage 2 バイパスの検証

Dense Retrieval のコサイン類似度マージン(Δ_dense = s_1 - s_2)が大きい場合、Stage 2 の再ランキング処理をバイパスする手法の可否を検証しました。

閾値 θ_dense Stage 2 バイパス率 (%) カスケード正解率 平均 E2E レイテンシー 評価
0.00 100.0% (全バイパス) 72.75% 8.5 ms Stage 1 単独精度
0.02 74.8% 80.50% 19.1 ms レイテンシー 19.1 ms で正解率 80.50%
0.05 38.3% 86.25% 34.4 ms 約38%をスキップし正解率 86.25%
0.08 11.8% 87.50% 45.6 ms 正解率(87.50%)を維持しながらレイテンシーを短縮
0.10以上 4.5%以下 87.50% 48.6 ms スキップの寄与が減少

用途別の構成パターン

実測データに基づき、システムの要求要件に応じた構成を整理しました。

ユースケース パイプライン構成 E2E レイテンシー 正解率 選定理由
精度重視 ruri-v3-30m → Cross-Encoder → 動的 Logit Gate (θ = 0.05) ~72.8 ms 88.00% 単一モデル構成と比較して高い正解率を示す
速度重視 ruri-v3-30m → Cross-Encoder (Stage 1 バイパス θ_dense = 0.08) ~42.6 ms 87.50% 50ms 未満のレイテンシーで 87.50% の精度を維持
多言語・省容量 EmbeddingGemma-2 (256d) → Cross-Encoder ~44.3 ms 86.00% 256次元ベクトルによるメモリ削減と多言語対応

まとめ

評価データセットの選定によってモデルの評価結果が異なる点、ならびにスコア差に基づく動的ルーティングの有効性が確認できました。評価データセットにはHF公開実コーパス(ruri-v3-dataset-reranker)が含まれるため、もしかしたら、ruri-v3が有利かもしれないという点は指摘しておきます。

Cross-Encoder で大半の処理(約89%)を高速に行い、スコアが拮抗した境界値のクエリのみを Logit Gate にルーティングする設計は、単一のGPU環境(RTX 3060 12GB)において精度と計算効率のバランスをとる上で有効なアプローチとなります。正確にはJevではないため、仮にLogit Gateと呼んでいますが、SLMのモデルと共有できるため、ローカルで十分可能性のある構成でもあるだろうと考えています。

他のモデルでは、状況が変わるかもしれませんが、セマンティック検索の弱点をカバーする方法の一つではないでしょうか。

今後の予定としては、実際に機能として実装してみたいと思います。

github.com

材料開発をテーマに統合設計プラットフォームをハーネス・オントロジーを使って構築してみる。

材料開発をテーマに統合設計プラットフォームをハーネス・オントロジーを使って構築してみる。

硬さと靭性の両立に代表されるように、相反する物性のトレードオフをいかに打破するかは材料開発の命題です。局所的なパラメーターの微調整だけではこの壁の突破は難しく、材料組織、製造プロセス、要求物性間の因果関係を一気通貫で俯瞰できる統合的な設計アプローチが常です。

この課題に対して、特許や論文といった公知情報に散在する実験データ、物性相関、プロセス設計を一貫した意味論で結び直す「知識の構造化」が欠かせません。文献を広く探索し、特許を精査してレビューにまとめる作業自体も研究者にとって刺激的な時間ですが、これを単なるまとめにとどめず、思索・共有・対話を加速させる「コントロールパネル」のようなプラットフォームへと昇華できれば、材料開発の探求はさらに楽しいものになるはずです。

そこで、AIエージェントの振る舞いや推論パイプラインを制御・束ねる実行枠組み(=ハーネス)と、オントロジーを使って構築すれば、そこそこ汎用的なものできそうなので、チャレンジしてみました。スキル・ルールも自己改善できるようにしつつ組み入れていきます。


1. 直面した課題:電池正極材における特許の「泥臭いレシピ」と論文の「理想化された物理」

全固体電池や次世代リチウムイオン電池の正極材開発(超高Ni単結晶NCM、界面コーティング層、硫化物固体電解質複合正極など)では、特許と学術論文の双方が欠かせない情報源です。しかし、この2つには大きな性質の違い(情報の非対称性)があります。

情報源 得意な領域(光) 抱える構造的課題(影)
特許明細書 現場の焼成温度プロファイル、水洗・脱水プロセス、被覆コーティング手法、リアルな失敗例(比較例) 権利化のために範囲が広くぼかされ、「なぜそのコーティングで界面抵抗が下がるのか」という微視的メカニズムや物理的根拠が意図的に省略されている
査読付き論文 単粒子レベルの充放電挙動、固相内Li拡散係数、DSC熱暴走の開始温度、微細組織(TEM/STEM)による理論的解明 理想化された清浄環境(平滑な薄膜、過剰電解液)が前提で、量産工程における残留アルカリ、微量水分失陥、粒子割れといった泥臭い製造制約が捨象されやすい

現場の技術者は、「特許にあるこの奇妙な添加・被覆条件は、あの論文が指摘していた格子ひずみ緩和や空間電荷層の抑制で説明がつくのではないか?」と、両者を脳内で往復しながら結びつけています。

そこで、「特許の泥臭い製造ノウハウ」と「学術論文の基礎物理」をオントロジーで結びつけ、電池正極材の実測値で検証されたシミュレータまで一気通貫で組み上げるハーネスを設計しました。

ここでは、電池正極材に関する技術を取り上げて例とします。


2. アーキテクチャの骨格:「縦糸(電池正極ドメイン)」×「横糸(機能横断)」の設計

電池正極材には、特有の支配方程式(Butler-Volmerの電気化学反応、固相内Li拡散方程式、空間電荷層のトンネル抵抗、DSC熱暴走キネティクスなど)が存在します。

そこで、システム全体を「電池正極材の深い物理を担う縦糸」と、「文献処理や検証を自動化する横糸」に切り分けて整理しました。

              【ドメイン特化スキル(縦糸: 全固体・LIB電池正極材の物理)】
              ┌──────────────────────────────────────────────────────┐
              │  battery-cathode-knowhow-miner                       │
              │  ・正極オントロジー(単結晶NCM, LiNbO3被覆, 残留Li等) │
              │  ・材料物理モデル(界面移動抵抗R_int, Li拡散, 熱暴走DSC)│
              │  ・正極探索クエリ / 正極TRIZ矛盾対立データ             │
              └─────────────────────────┬────────────────────────────┘
                                        │
── ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─┼─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
【機能横断スキル】                      │
 (横糸: 共通基盤)                       │
 ・academic-evidence-retriever ───────── 特許の被覆・組成条件から査読論文(Acta Mater, J. Power Sources等)を自動照合
 ・material-triz-matrix ──────────────── 高容量化(高Ni)と熱安定性・寿命のトレードオフをTRIZ原理へマッピング
 ・battery-cathode-critical-auditor ──── 特許・論文の実験実測値(Ground Truth)に基づき計算モデルを自動監査
  • 縦糸(正極材特化): 電池正極材の概念辞書(domain_ontology.yaml)や、界面電荷移動抵抗・Li拡散を計算する物理モデル(Python/JS)。
  • 横糸(共通基盤): 特許の記述から背景論文(DOI)を自動探索するエンジン、相反する物性トレードオフを整理するTRIZマトリクス、そしてモデルの妥当性を監視する批判的監査エンジン。

3. データ処理の5ステージ・パイプライン:正極公知情報から対話型シミュレータへ

文献情報がどのようにして「動く対話型シミュレータ」へ昇華されるのか、パイプラインは以下の5段階で構成されています。

[Raw Input] ──> [Validation] ──> [Extraction & Ingestion] ──> [Matrix Integration] ──> [Portal Build]

これらのパイプラインはハーネスに含まれるスキル・ルールなどを汎用部分+ドメイン(対象とするテーマ)部分に分けて構築させていきます。そうなると、ドメイン(テーマ)が変わってもノウハウの横展開をすることができます。

① Raw Input(特許・論文の入力)

インプットは「基本情報」「公開技術(建前・公報記載)」「隠蔽・省略された真のノウハウ(焼成雰囲気・コーティング厚・微視構造)」「失敗モード(比較例・割れ・ガス発生・熱暴走)」の4セクションに構造化して投入します。

② Validation(バリデーションゲート)

「適宜調整する」「数%程度」といった曖昧な定性表現しか含まないテキストは機械的に弾かれます。被覆層の膜厚(nm)、焼成温度(℃)、比容量(mAh/g)、界面抵抗(Ω·cm²)などの具体的単位を持った工学数値が必須です。また、比較例における劣化データが含まれていることも必須条件としています。

③ Extraction & Ingestion(オントロジー構造化と論文照合)

正極オントロジーに沿って専門用語を正規化。特許で主張されている効果に対し、背景にある学術論文のDOIや理論的根拠を自動で紐付けた構造化Markdownを生成します。

④ Matrix Integration(横断比較マトリクス)

文献をまたいだパラメータ(Ni比率、被覆材料、熱処理条件、サイクル維持率、界面抵抗など)をCSVへ自動集約。「どの論文のどのメカニズムに基づき、どの特許でその最適値が実証されているか」を俯瞰できる知識マップが形成されます。

⑤ Portal Build(対話型ダッシュボード生成)

ブラウザ単体で完全にオフライン動作するスタンドアロンHTMLを自動生成。JavaScriptで実装された正極物理シミュレータが内蔵されており、スライダーでNi組成比やコーティング膜厚を動かすと、容量・界面抵抗・熱暴走開始温度のトレードオフ曲線がリアルタイムに再描画されます。


4. 「AIの夢見がち」を叩き落とす:正極実測アンカー点による批判的監査(Critical Audit)

LLMと材料シミュレータを組み合わせる際、最も恐ろしいのは「教科書的な理想モデルを過信し、現場の実測とかけ離れた過大評価(オーバープロミス)を平気で出力すること」です。

本システムでは、特許の実施例や論文のグラフに記載された「実際の実験測定値」を実測アンカー点(Ground Truth)として登録し、モデルの予測値と常時突き合わせる監査エンジンを回しています。

# 正極実測アンカー点との自動突合(概念コード)
# 例: LiNbO3被覆による界面電荷移動抵抗(R_int)の突合
relative_error = abs(sim_val - meas_val) / meas_val * 100

if relative_error <= tolerance_pct:
    status = "PASSED"            # 実測値と許容誤差内で整合
elif relative_error <= 1.3 * tolerance_pct:
    status = "WARNING"           # 軽微なモデル乖離
else:
    status = "FAILED"            # パラメータや数式構造の再校正が必要

# 物理限界(負の拡散係数、理論容量を超える比容量など)の破綻検知
if violates_physical_bounds(sim_val):
    status = "OVERPROMISED / OUT_OF_BOUNDS"

これをCI(pytest)で自動テストとして常時監視することで、「AIが生成した都合のいい楽観予測」を機械的に排除しています。


5. 画面紹介

対話型シミュレーター

クリックやスライダーでグラフが動的に変化します。

横断マトリクス

特許の実施例番号と論文DOIがマッピングされたマトリクスです。

TRIZ

TRIZっぽく分類しつつ技術を眺める一覧です。

ナレッジドキュメント類

ドキュメントをそれぞれまとめたマークダウンファイルを参照できます。

スキルやルールやダッシュボードには利用した特許や論文の情報が混入している可能性があり、非公開。

6. おわりに:自己改善する材料知識ハーネスへ

文献を探索して斜め読みし、技術の勘所を見つけ出すプロセスは研究者・エンジニアにとって知的好奇心を刺激する楽しい時間です。しかし、全固体・LIB正極材のように「高エネルギー密度」「低界面抵抗」「熱的安全性」「長寿命」という多重のトレードオフが絡み合う領域では、特許の行間に潜むノウハウと論文の基礎物理を結びつける作業が手軽に実施できるのは、考察がさらに進みます。

特許と論文という2つの公知情報を、正極オントロジーと物理モデルで架橋する。そして新しい文献に出会うたびに、辞書が育ち、TRIZマトリクスが拡充され、エージェントの振る舞い自体も自己改善を行います。思考の整理をしている気分でした。

今回は、PDFやワードファイル程度をテキストで雑にざっとパースして利用しました。しかし、精度を上げるには、特許や論文などから、情報を抽出する部分を磨く必要があります。組織写真といった画像データも重要でしょう。これは、今までチャレンジしてきたことなので、十分なレベルでローカルで完結できるものもあります。

また、オントロジーでマテリアルインフォマティクスへと繋げていくと、机上検討がさらに進みます。CALPHADを利用した計算を入れ込んだり、NiMSなどで公開されているマテリアルデータベースを参照したり、と連携へと夢が広がります。

Descriptor‐Based Zero‐Shot Learning for Predicting Catalytic Constituent Elements - Maki - 2026 - ChemistrySelect - Wiley Online Library

「記述子ベースのゼロショット学習」についての論文です。オントロジーとの相性もよいのではないでしょうか。論文の趣旨とは異なりますが、材料開発におけるドメインナレッジの蓄積方法としての可能性を感じました。

例えば、OKF v0.2 フォーマットのようなオントロジーとmarkdown要素をソース(RAW)を担保しつつ,中間ナレッジをヒトとの親和性の高い情報の構築する。オントロジーの逆伝播による自己改善と、緩さと再構築で担保する。

情報と異なり材料分野の論文は、個人では読み込むには大き目のコストがかかります。個人で遊ぶのにも限界はありますが、考えていきたいと思います。

日本語特化小規模LLM「Qwen3.5-0.8B-Japanese-SFT-v2」をJevっぽく使ってみる

日本語特化小規模LLM「Qwen3.5-0.8B-Japanese-SFT-v2」をJevっぽく使ってみる。

JevっぽくLLMを使うLogit Router としてQwen3.5-0.8B-Japanese-SFT-v2を使っています。Logit Router とは、プロンプトの次の1トークン予測における候補ラベル(A, B, C...)の ロジット(未正規化対数確率)を1回のForward Passで直接抽出・比較 して判定します。テキスト生成ループを回さないため、低レイテンシで判定が完了します。

今回は、日本語SFTモデルとして公開されている Takenoko12345678/Qwen3.5-0.8B-Japanese-SFT-v2 およびその GGUF量子化版(Q4_K_M / Q8_0) を取り上げ、「日本語環境でのLogit Routerとして実用可能か?」を 2,500問の実践的テストケース を用いて検証しました。


結論サマリー

  • 利用可否: 実用的 0.8Bという超軽量サイズでありながら、ベースライン(Qwen2.5-1.5B-Instruct)を超える 正解率 89.2% / Macro-F1 0.88 を達成。
  • 低レイテンシ 1.5Bモデルが約75msかかる処理を、40〜55ms で判定完了。
  • GGUF量子化(Q4_K_M)の有用性 4-bit量子化を施しても精度低下はわずか 1.1%(89.2% → 88.1%)。最小限のVRAM環境やエッジ・ローカル端末での運用にベストバランス。
  • 日本語ノイズへの対応 方言・口語・誤字・長文・否定表現などが混在する過酷な条件下でも高い精度を維持。

評価環境とベンチマーク設計

2,500件の自作日本語テストセット

ルーターモデルの実用性を検証するため、実運用で発生する多様な入力を網羅した 計2,500件 のテストスイートを構築しました。

  • 総ケース数: 2,500件(Hard: 1,351件 / Medium: 971件 / Easy: 178件)
  • 網羅されたドメイン:
    • ツール選択(Web検索 / 計算機 / Python実行 / DBクエリ / ドキュメント管理など): 1,196件
    • 意図・感情分類(質問 / クレーム / 購買意欲 / 称賛 / 要求): 443件
    • 曖昧性解消(意図明確 / 要確認 / 複数意図 / 曖昧 / 対象外): 377件
    • 最適モデル選択(小型高速 / 推論特化 / VLM / コード特化 / 多言語): 251件
    • その他(緊急度判定、セキュリティガードレール、PII検知、多言語振り分け): 233件
  • 日本語特有のノイズ耐性タグ: 方言(360件)、絵文字混在(331件)、長文コンテキスト(330件)、口語・スラング(327件)、二重否定・否定表現(327件)、敬語(323件)、Prompt Injection等の敵対的ケース(318件)、誤字・脱字(313件)、曖昧指示(312件)、全角半角混在(309件)

測定環境と実行速度に関する注意事項

[!NOTE] 実行速度(レイテンシ)はハードウェア環境や実行バックエンドに大きく依存します。 掲載している数値は同一測定環境における相対比較の目安としてご参照ください。

今回の測定ハードウェア環境

  • GPU: NVIDIA GeForce RTX 3060 12GB
  • CPU / Host: Linux x86_64, PyTorch 2.x + CUDA 12.x / llama.cpp (GGUF実行)
  • バッチサイズ: 1(リアルタイムAPIリクエストを想定した逐次推論)

ベンチマーク結果

1. 精度とレイテンシの比較

モデル 形式 / 量子化 正解率 (Accuracy) Macro-F1 誤字ノイズ耐性 長文耐性 p50 レイテンシ p95 レイテンシ
Qwen3.5-0.8B-JP-SFT-v2 HF (bfloat16) 89.2% 0.88 85.0% 88.0% 55.2 ms 60.1 ms
Qwen3.5-0.8B-JP-SFT-v2 GGUF (Q8_0) 89.0% 0.87 84.8% 87.9% 48.0 ms 52.1 ms
Qwen3.5-0.8B-JP-SFT-v2 GGUF (Q4_K_M) 88.1% 0.86 84.1% 87.2% 40.5 ms 45.2 ms
Qwen2.5-1.5B-Instruct HF (bfloat16) 87.5% 0.85 81.0% 84.5% 75.3 ms 80.4 ms

2. 結果の考察

① パラメータ数は半分以下、精度はベースライン超え

ベースラインとして比較した Qwen2.5-1.5B-Instruct(1.5Bパラメータ)に対し、Qwen3.5-0.8B-Japanese-SFT-v2(0.8Bパラメータ)はモデルサイズが約半分にもかかわらず、日本語ルーティング精度で +1.7%、Macro-F1で +0.03 上回る結果となりました。 日本語SFTによって「〜というわけではない」「どないしたらええの?」といった文脈表現を正確に捉えられることが要因と考えられます。

② レイテンシは最大 46% 短縮

推論処理において生成を行わないLogit抽出の強みと、0.8Bの軽量性が相まって、GGUF Q4_K_M では p50: 40.5ms / p95: 45.2ms を記録しました。1.5Bベースライン(75.3ms)と比較して大幅に高速化されています。

③ GGUF(Q4_K_M)が良好なコストパフォーマンス

GGUFの4-bit量子化版(Q4_K_M)は、メモリ消費を1GB未満に抑えながら、未量子化版と比較してわずか 1.1% の精度差に収まっています。低リソースなサーバやローカル環境での配備には、Q4_K_M がもっとも推奨される構成です。


実装・運用のポイント

トークナイザ仕様への対応

LLaMA系などのトークナイザでは選択肢文字の直前にスペース(" A")が必要な場合がありますが、Qwen系トークナイザではダイレクトに "A", "B", "C" を指定することで正しいToken IDが割り当てられます。実装側で is_qwen に応じたトークンID抽出を行うことで対応しています。


まとめと推奨構成

  • 本番API環境(精度最優先):
    • モデル: Takenoko12345678/Qwen3.5-0.8B-Japanese-SFT-v2 (HF / bfloat16)
    • 89.2% の精度と 55ms 前後の早いレスポンス。
  • オンデバイス / エッジ / コスト最優先環境:
    • モデル: Takenoko12345678/Qwen3.5-0.8B-Japanese-SFT-v2-GGUF (Q4_K_M)
    • メモリ消費 1GB 未満、40ms台の超高速レスポンスで 88% 超の精度を両立。

日本語に特化した軽量SFTモデルは、テキスト生成タスクだけでなく、「高速・高精度なLogit Router」としても良い選択肢 であることが実証されました。セマンティック検索やキーワード検索と組み合わせると、RAG用検索の強化できます。素敵なモデルをありがとうございます。

WSL3.0とContainerDesktopを使ってみる。

WSL3.0とContainerDesktopを試してみました。

Docker Desktopなどの追加ツールなしに、Linuxコンテナの作成・実行が可能になります。開発含めて便利にできそうです。docker composeへの対応も楽しみです。

 

インストール

wslを3にします。

> wsl --update
更新プログラムを確認しています。
Linux 用 Windows サブシステムをバージョン 3.0.1 に更新しています。

 

WSLContainerDesktopも入れます。

Releases · mhackermsft/wslcontainerdesktop · GitHub

から以下の3つのファイルをダウンロードします。

Install.ps1

WSLContainerDesktop-Signing.cer

WSLContainerDesktop_1.9.1_x64.msix

 

Install 管理者ターミナルから
> powershell -ExecutionPolicy Bypass -File .\Install.ps1
> WSLContainerDesktop

これで完了

 

お試し

nginxで試してみます。

> wslc run -d --rm -p 8080:80 --name web nginx
イメージ 'nginx' が見つかりません。プルしています
latest: Pulling from library/nginx
6b37362b3da7: Pull complete

....


無事動作しました。


先ほどインストールしたWSLデスクトップにも表示されます。AI機能も。今のところ、複雑なことはしないので不要ですが、どういった利用が想定されているのか。


保存先を気軽に変更できるようにしてほしいです。

RerankにおけるLogit Gate導入とニアミス遮断を試してみる。

RerankにおけるLogit Gate導入とニアミス遮断を試してみる。

RAG(検索拡張生成)システムにおいて、ベクトル検索や初期リトリーバルで取得した候補文書の順位を整える「再ランキング(Rerank)」は、LLMへ渡すコンテキストの質の向上の手段です。

従来は cl-nagoya/ruri-v3-reranker-310m などのクロスエンコーダー(Cross-Encoder)モデルが一般的に利用されてきました。しかし、クロスエンコーダーには「テキスト全体のトピックや意味的類似度」に過剰に反応してしまい、「文脈やトピックは一致しているが、肝心の回答やエラーコード・コマンドなどの決定的な情報が欠落しているニアミス文書」に対して高スコアを付与してしまうという根本的な課題がありました。かと言ってBERTモデルを再チューニングしようにも、教師データの確保や学習に用いる各種パラメータ類のチューニングといった壁があります。

そこで今回、LLM(Qwen/Qwen2.5-1.5B-Instruct)の指示追従能力とロジット出力を用いて「回答十分性(Sufficient to answer)」のみを単一フォワードパスで直接判定する Logit Gate 機構(およびASCII Matcher)を導入し、従来のクロスエンコーダーとの直接対決ベンチマーク評価を実施してみました。Jevもどきを入れ込むとニアミス=ノイズを減らせるだろうという発想です。

結果としては、過去に味見をした時と同様に良好でした。Rerankへの実装だと従来のrerank API互換で受け付けるDifyなどで、そのまま利用しやすいという利点があります。これからセマンティック検索との併用or統合したBERTモデルの公開が進んでいくのではないかと期待しちゃいます。味見的にはうまくいったので、利用しながら調整していきたいと思います。


検証環境および評価モデル

検証にはVRAM 12GBを搭載した単体のGeForce RTX 3060を使用し、実データセットに基づく評価スイートを用いてレイテンシ・スループットおよび精度・ニアミス遮断性能を測定しました。

  • ハードウェア: NVIDIA GeForce RTX 3060 (12GB VRAM, CUDA 13.0)
  • 評価データセット: benchmarks/datasets/sufficiency_eval.json(N = 108:正例 36, ニアミス負例 36, 回答不能 36)
  • 比較モデル:
    1. 従来型 Cross-Encoder: cl-nagoya/ruri-v3-reranker-310m(310Mパラメータ, 双方向BERT分類ヘッド)
    2. Logit Gate ハイブリッド: Qwen/Qwen2.5-1.5B-Instruct(1.5Bパラメータ, 単一フォワードパス ロジット判定 + ASCII Matcher $\beta = 1.2$)

実行時間・スループット比較 (Latency & Throughput)

まず、108件の評価データセット全体に対する実行時間および単一ドキュメントあたりの推論レイテンシを比較しました。

測定項目 Cross-Encoder (ruri-310m) Logit Gate (Qwen2.5-1.5B) 比較・所見
モデルパラメータ数 310M 1,540M (約 5 倍) Cross-Encoder の方が軽量
VRAM 消費量 1,240 MB 2,945 MB いずれも 12GB VRAM に余裕で収容
全108件 処理時間 0.89 秒 4.17 秒 Cross-Encoder が約 4.7 倍高速
1件あたり推論レイテンシ 8.21 ms 38.65 ms いずれも 50ms 以下のリアルタイム基準内
スループット 121.9 docs/sec 25.9 docs/sec 大量候補の粗選別は Cross-Encoder が有利

パラメータ数が約5倍大きくなるため、処理速度面ではCross-Encoderが有利です。ただし、Logit Gateも1件あたり約38msとリアルタイム応答の許容範囲内に収まっています。


精度・ニアミス遮断性能比較 (Accuracy & Discrimination)

次に、正例、ニアミス負例、および無関係な回答不能ドキュメントに対するスコア分布の統計を比較しました。

1. スコア分布統計

カテゴリ Cross-Encoder スコア分布 Logit Gate スコア分布 特性比較
正例 (Positive, N = 36) Mean: 0.9782, Min: 0.2998, Max: 1.0000 Mean: 0.6899, Min: 0.0438, Max: 0.9813 真正な回答にはともに高スコア
ニアミス負例 (Near-Miss, N = 36) Mean: 0.1148, Max: 0.9355, P90: 0.4511 Mean: 0.0294, Max: 0.2018, P90: 0.0538 Cross-Encoder は最大 0.9355 までスコアが誤爆上昇
Logit Gate は最大でも 0.20 に完全抑え込み
回答不能 (Unanswerable, N = 36) Mean: 0.0013, Max: 0.0125 Mean: 0.0036, Max: 0.0251 無関係な文書は両者とも完全遮断

2. 判定閾値($\tau$)別の遮断率と再現率

判定閾値 $\tau$ Cross-Encoder ニアミス遮断率 Cross-Encoder 漏洩件数 Logit Gate ニアミス遮断率 Logit Gate 漏洩件数 正例再現率 (Recall)
$\tau = 0.30$ 83.3% (30/36) 6 件漏洩 (誤爆通過) 100.0% (36/36) 0 件 (完全遮断) CE: 97.2% / LG: 86.1%
$\tau = 0.50$ 91.7% (33/36) 3 件漏洩 (誤爆通過) 100.0% (36/36) 0 件 (完全遮断) CE: 97.2% / LG: 80.6%
$\tau = 0.70$ 91.7% (33/36) 3 件漏洩 (误爆通過) 100.0% (36/36) 0 件 (完全遮断) CE: 97.2% / LG: 58.3%

測定結果において最も顕著だったのは、Cross-Encoderにおける深刻なスコア逆転問題です。Cross-Encoderでは、ニアミス負例の最大スコアが 0.9355 に達する一方で、正例の最小スコアは 0.2998 まで落ち込みました。

これは「ニアミスを遮断しようと閾値を上げると正例が削られ、正例を拾おうと閾値を下げるとニアミスが素通りしてLLMのハルシネーションを引き起こす」という根本的なジレンマが存在することを意味します。一方、Logit Gateではニアミス負例の最大スコアが0.2018に抑え込まれ、閾値 $\tau = 0.30$ 以上でニアミスを100%完全遮断できています。


実際のニアミス漏洩事例

Cross-Encoderが誤爆判定し、Logit Gateが正確に遮断した具体例を比較してみます。

クエリ 候補文書(ニアミス) Cross-Encoder スコア Logit Gate スコア なぜ Cross-Encoder は誤爆したか
Pythonの組み込み関数 len() はどのような役割を持っていますか? 「Pythonには多くの便利な組み込み関数が用意されており、リストや文字列の長さを調べたり...」 0.9355 (ほぼ満点) 0.0210 (完全遮断) 文書全体が Python 組み込み関数や長さ取得について言及しているため類似度が極大化。しかし肝心の len() の具体的説明がない。
太陽系で最も大きい惑星は何ですか? 「太陽系の惑星は地球型と木星型に分類され、外側の巨大惑星群は特異な大気...」 0.7938 (高確率通過) 0.0085 (完全遮断) 太陽系や巨大惑星(木星型)の単語が密集しているが、「最大の惑星は木星」という事実の記述が一切ない。
Gitで直前のコミットメッセージを修正するコマンドは何ですか? 「Gitではコミット履歴を後から変更する機能があり、特定のコマンドやオプションを活用...」 0.7578 (高確率通過) 0.0152 (完全遮断) コミット修正という文脈が完全に一致しているが、具体的なコマンド git commit --amend が記載されていない。

ログ解析と技術的考察

1. Logit Gate はニアミスの排除について

クロスエンコーダーはモデル内部でテキスト同士の語彙・文脈埋め込みのドット積や分類ヘッダーを学習しているため、キーワード密集度や同一トピックに引っ張られます。 これに対し、Logit GateはLLMに対して「クエリに対する回答が文書内に具体的に含まれているか」という二者択一のインストラクションを与え、Yes / No に相当するトークンの生成ロジット確率をダイレクトにスコア化しています。これにより、「トピックは似ているが答えがない」文章を原理的に排除することが可能となっています。とりあえず、Jevの代わり・・・ですね。

2. 二段階カスケード(Two-Stage Cascade)の推奨構成

ベンチマーク結果の速度と精度トレードオフを考慮すると、以下のような二段階構成も合理的である(かも)と考えられます。

  • Stage 1 (高速粗選別): Dense/Sparseベクトル検索で得られた100件程度の候補を、cl-nagoya/ruri-v3-reranker-310m(約8ms/doc)を用いて上位10件に絞り込みます。
  • Stage 2 (厳密十分性ゲート): 絞り込まれた10件に対し、Qwen2.5-1.5B-Instruct(Logit Gate + ASCII Matcher, 約38ms/doc)を適用し、回答十分性が不足している文書(スコア < 0.55)を遮断します。

まとめ

Rerank処理にLLMベースのLogit Gateを導入することで、従来のクロスエンコーダーでは防げなかったニアミス文書によるLLMのハルシネーション・誤回答を劇的に抑制できることが実証されました。

単一モデルでの全件処理が速度面での課題が残るものの、現状のモデルを組み合わせてクロスエンコーダーとの二段階カスケード構成をとることで、レイテンシとニアミス遮断を両立したRAGパイプラインが、実用的なレベルで構築できそうです。


レポジトリ

github.com

Webページにセマンティック検索(modernBERT, Ruri-v3-30m)を設置してみる。

modernBERT, Ruri-v3-*をブラウザ上での利用を試したので、セマンティック検索ができるようにChorme 機能拡張にしてみました。ストアには未登録ですので開発者モードから設定します。

 

機能拡張の動作画面です。

 

セマンティック検索では、新語や製造番号のような言葉に弱い傾向があります。そこでハイブリッド検索(Keyword + Semantic)戦略が一般的です。そこで簡単なキーワードによるスコアブースト戦略をとっています。チューニングは不十分ですが、狙い道理の効果は出ている印象です。

 

最初の利用時にモデルのダウンロードの待ち時間が発生します。以降は、ブラウザ側でキャッシュが効きます。

 

レポジトリ:

github.com

 

まずは速度感が分かれば、使い方は広がります。今回の例では、modernBERTのコンテキスト長を活かせていません。このあたりも、うまく利用するとよいのでしょう。

RAG用のembedding処理への知見が活かせそうなので引き続き実装してみます。