Posted:
| Tags:
ai,
benchmark,
bfcl,
local-llm,
terminal-bench,
tool-calling
先に私の評価結果
- 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-native | parser、tool routing、warning filter、output relay、suppression |
| proxy / CLI | OpenAI-compatible proxy、Responses 変換、Codex CLI JSONL |
| terminal task | terminal agent としての最終タスク達成 |
BFCLとTerminal-Benchの位置づけ
BFCL は function calling の評価に近い。adapter の tool schema 変換、arguments、tool name、malformed recovery を見るには相性がよい。
Read more...Posted:
| Tags:
ai,
codex,
local-llm,
tool-calling,
troubleshooting
ローカル 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...Posted:
| Tags:
ai,
codex,
hermes,
local-llm,
tool-calling
なぜこのアプローチを試しているのか
- ローカルLLM、日本語は結構返してくれるようになった
- tool searchの段階で結構あやしい
- ローカルLLMの性能に期待せずに、途中でインターセプトしてcodexなどから使えないか?と考えた
- 2026年時点ではまだうまくできてない(かなりのユースケースに対応するコードが必要そう)
小型のローカル 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...