Tag: Local-Llm

Coding Agent向けにソースコード構造解析を試す：Call Graph、CFG/DFG/PDG、Ansible、Provenanceの使い分け

Posted: 2026-10-04 | Categories: ai | Tags: ai, ansible, codex, coding-agent, graph, local-llm, python, sre, static-analysis

Coding Agent向けにソースコード構造解析を試す：Call Graph、CFG/DFG/PDG、Ansible、Provenanceの使い分け

Coding Agentに大きなrepositoryを読ませるとき、単純にsource fileを大量にcontextへ投入する方法には限界がある。

大きなmodelならかなり読めるが、それでも「どのfileから読むべきか」「どのfunctionが中心なのか」「値がどこから来ているのか」「複数repositoryをまたぐ処理は何なのか」を毎回sourceから探索するのは高コストである。特に小型のlocal LLMでは、repository全体をcontextへ入れる方法は現実的ではない。

そこで、sourceから決定論的に構造情報を抽出し、

Coding Agentが読むべきsourceを絞る
人間がarchitectureを理解する材料にする
refactoring前後の構造差を確認する
小型LLMにはboundedなcontextだけを渡す

という用途に使えないか、homeclusterのPython / Ansible中心のcodebaseでいくつかの解析方法を試した。

今回試したものは次の通りである。

Symbol Index
Call Graph
module / type / provenance
receiver method resolution
Control Flow Graph（CFG）
Data Flow Graph（DFG）
Program Dependence Graph（PDG）
Ansible domain graph
inventory provenance graph
cross-repository contract graph
bounded structural slice

結論から言うと、どれか1つが勝者というより、それぞれ違う層で有用だった。

さらに実際に作ってみると、すべてを同じ頻度で更新するより、

普段は軽量なstructural indexを継続的に最新化し、難しい調査やarchitecture reviewのときだけDeep解析を実行する

という二層構成が良さそうだと分かった。

この記事では、解析手法の一般論から入り、実際に試して分かったメリット・デメリット、Coding Agentへ任せる場合の設計、自動化で気を付ける点、他言語へ広げるときの考え方まで整理する。

ソースコード解析にはいくつかの「深さ」がある

「source codeを解析する」と言っても、何を知りたいかによって必要な解析は違う。

最も単純なのは、fileやsymbolを探すindexである。

repository
  |
  +-- module A
  |     +-- function foo
  |     +-- class Bar
  |
  +-- module B
        +-- function baz

ここから一段進むと、function同士の呼び出し関係を調べるCall Graphになる。

Gemma 4 E4B QAT Q4_0をCodex CLIローカルモデルとして評価したメモ

Posted: 2026-06-14 | Tags: ai, codex, gemma, llama-server, local-llm, mcp

Gemma 4 E4B QAT Q4_0 GGUF を、Codex CLI の text-only local model backend 候補として試した。

比較対象は、先に評価していた Gemma 4 12B Q4_K_M である。見たかったのは、単なる短文応答ではなく次の 4 点だった。

12B より GPU memory が下がるか
Codex CLI の agent prompt を現実的な context に収められるか
JSON final answer と read-only shell tool use が成立するか
広い文書検索や MCP tool selection で破綻しないか

先に結論を書くと、E4B は memory / speed 面では 12B よりかなり扱いやすい。一方で、Codex CLI の tool routing まで含めると、12B の単純な置き換えではない。特に MCP tool を model に直接選ばせる構成は不安定で、検索 intent は adapter / router 側でルールベースに拾う方が堅い。

Gemma 4 12B Q4_K_MをCodex CLIローカルモデルとして評価したメモ

Posted: 2026-06-13 | Tags: ai, codex, gemma, llama-server, local-llm, tool-calling

Gemma 4 12B Q4_K_M の GGUF を llama-server で起動し、OpenAI-compatible proxy を挟んで Codex CLI の local model として使えるかを試した。

後続では、同じ環境で Gemma 4 E4B QAT Q4_0 の軽量 backend 評価も行った。

見たかったのは、単なる短文応答ではなく次の 3 点だった。

Codex CLI の大きめの agent prompt を context に収められるか
JSON-only final answer が壊れないか
shell tool call と tool result の読み取りが成立するか

先に結論を書くと、12GB class GPU でも ctx=16384, ngl=28, --reasoning off なら短時間の JSON/tool smoke は通った。ただし、長文、温度、tool schema の増加、別の chat template ではまだ崩れる余地がある。

構成

抽象化すると構成はこうなる。

flowchart LR
    Codex[Codex CLI] --> Proxy[OpenAI-compatible proxy]
    Proxy --> Llama[llama-server]
    Llama --> Model[Gemma 4 12B Q4_K_M GGUF]
    Codex --> Tools[Codex tool executor]

今回の評価では adapter を挟まず、proxy の Responses API 変換から llama-server の Chat Completions へ流した。

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

Posted: 2026-05-20 | Tags: ai, benchmark, bfcl, local-llm, terminal-bench, tool-calling

先に私の評価結果

2026年時点でNvidia 3060 12GBメモリモデルで検証
現状のローカル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 を見るには相性がよい。

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

Posted: 2026-05-20 | Tags: ai, codex, local-llm, tool-calling, troubleshooting

ローカル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 。

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

Posted: 2026-05-20 | Tags: ai, codex, hermes, local-llm, tool-calling

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

ローカル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]

役割を分けると、