【要約】Intel N100で回せるローカルLLMを試行錯誤したら、Claudeの生成コードに穴があった件 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
筆者は、家計明細の集計結果をローカルLLMに説明させる仕組みを構築している。しかし、モデルの性能を評価するための検証機能が、期待通りに動作しない問題に直面した。具体的には以下の課題が挙げられる。
- ・検証コードの正規表現が「6千円」等の表記ゆれに対応できず、検知をすり抜ける。
- ・データ照合用のホワイトリストが広すぎて、無関係な数字まで正解と見なす。
- ・「削減額が現状額を超える」といった、数字同士の論理的な矛盾を判定できない。
// Approach
筆者は、Intel N100搭載のミニPCを用い、3種類の異なるモデルで比較実験を行った。モデルごとの特性を多角的に把握するため、以下の手順で検証を実施した。
- ・llm-jp-3.7b、qwen2.5:7b、gemma4:e4bの3モデルを、同一の入力データで実行。
- ・処理時間、日本語、形式、数値、データ参照の5軸で評価。
- ・モデルサイズと処理時間の相関を測定し、CPU推論の見積もり精度を確認。
- ・検証コードの挙動を分析し、検知漏れが発生するメカニズムを特定。
// Result
検証の結果、モデルの性能と検証ツールの信頼性に関する重要な知見が得られた。単一の指標ではモデルの真の価値を判断できないことが明確になった。得られた成果は以下の通りである。
- ・CPU推論において、モデルサイズ1GBあたり約70秒という見積もり基準を確立。
- ・「警告ゼロ」が必ずしも高品質を意味しないリスクを特定。
- ・検証機能の欠陥（表記ゆれ、広すぎる許容リスト、論理チェック不足）を発見。
Senior Engineer Insight
> 低リソース環境でのLLM運用において、本件は極めて示唆に富む。まず、計算ロジックをLLMから切り離し、決定論的なコードで完結させる設計は、信頼性確保の鉄則である。また、自動検証ツールの設計では、単なる「存在チェック」ではなく、論理的な整合性まで踏み込む必要がある。「検知できないエラー」こそが、システムにおける最大の脆弱性となる。リソース見積もりの定量的基準を得た点も、実運用への導入判断において高く評価できる。