Tag: Local-Llm

ローカルLLM AdapterをBFCLとTerminal-Benchで評価する計画

先に私の評価結果

  • 2026年時点でNvidia 3060 10GBメモリモデルで検証
  • 現状のローカルLLMは日本語はかなりのものを返すようになった( 1bit LLMでも割と正しいものを返す )
    • ただし tool search , tool use の機能の正確さはまだ良くない( 結構な頻度で失敗する )
  • ローカルLLMへの期待としては 1bit LLM かつ tool search 機能を最初から学習したモデルが待たれる

ローカルLLM AdapterをBFCLとTerminal-Benchで評価する計画

ローカル LLM の評価では、model 単体の一般能力と、adapter を含む tool calling 経路の品質を混ぜない方がよい。

今回測りたいのは、Hermes 3 Llama 3.1 8B の総合知能ではなく、Hermes adapter が Codex CLI 互換の tool call をどれだけ安定して成立させるかである。

そのため、評価対象を次の 3 層に分ける。

評価したいもの
adapter-nativeparser、tool routing、warning filter、output relay、suppression
proxy / CLIOpenAI-compatible proxy、Responses 変換、Codex CLI JSONL
terminal taskterminal agent としての最終タスク達成

BFCLとTerminal-Benchの位置づけ

BFCL は function calling の評価に近い。adapter の tool schema 変換、arguments、tool name、malformed recovery を見るには相性がよい。

Read more...

ローカルLLM Tool Adapterのトラブルシューティング分類

ローカルLLM Tool Adapterのトラブルシューティング分類

ローカル LLM と tool calling adapter を組み合わせると、失敗原因が複数の層に分かれる。

最終応答だけを見ると「model が間違えた」に見えるが、実際には次のような層のどこかで起きていることが多い。

  • model context / VRAM
  • Hermes prompt / parser
  • tool pruning / router
  • OpenAI-compatible proxy
  • CLI の tool execution
  • shell sandbox
  • internal web tool
  • external research helper
  • benchmark harness

このメモでは、公開してもよい抽象度でトラブルの傾向を整理する。実 port、実 path、token 名、host 名、生ログは private runbook 側に残す。

全体の切り分け

flowchart TD
    Final[final answer] --> A{tool call eventは出たか}
    A -->|no| Router[adapter router / model tool selection]
    A -->|yes| B{tool executorは動いたか}
    B -->|no| Proxy[proxy / schema / unknown tool]
    B -->|yes| C{tool outputは正しいか}
    C -->|no| Sandbox[sandbox / command / environment warning]
    C -->|yes| D{finalが正しいか}
    D -->|no| Relay[output relay / model summarization]
    D -->|yes| Done[pass]

まず見るべきなのは final answer ではなく、tool call event と tool result 。

Read more...

ローカルLLMでTool Callを安定させるHermes Adapter設計メモ

なぜこのアプローチを試しているのか

  • ローカルLLM、日本語は結構返してくれるようになった
  • tool searchの段階で結構あやしい
  • ローカルLLMの性能に期待せずに、途中でインターセプトしてcodexなどから使えないか?と考えた
  • 2026年時点ではまだうまくできてない(かなりのユースケースに対応するコードが必要そう)

ローカルLLMでTool Callを安定させるHermes Adapter設計メモ

小型のローカル LLM を coding agent や terminal helper に使う場合、通常の chat 品質よりも tool call の安定性が先に問題になる。

特に 8B 級の model では、次のような失敗が起きやすい。

  • tool call すべき場面で自然文のコマンド例を返す
  • tool name や arguments の JSON が崩れる
  • tool 数が多すぎて選択を誤る
  • tool output に混じった環境 warning を実行結果と誤解する
  • 「実行しないで」と言われたのに実行系 tool を選びかける

このメモは、Hermes 3 Llama 3.1 8B Q5_K_M を例に、ローカル LLM と Codex CLI の間に小さい adapter を置いて tool call を安定させる設計をまとめる。

基本構成

想定した流れは次のようになる。

flowchart LR
    CLI[Codex CLI] --> Proxy[OpenAI-compatible proxy]
    Proxy --> Adapter[Hermes tool adapter]
    Adapter --> Llama[llama-server]
    Llama --> Model[Hermes 3 Llama 3.1 8B GGUF]
    Adapter --> InternalTools[adapter internal read-only tools]
    InternalTools --> Fetch[fetch_url]
    InternalTools --> Search[search_web]
    InternalTools --> Research[optional research helper]
    CLI --> ToolExecutor[Codex tool executor]
    ToolExecutor --> Shell[exec_command / write_stdin]

役割を分けると、

Read more...