Local LLM
Thank you for reading this post, don't forget to subscribe! 生成AIは便利だが、時に平然と“嘘”をつく。
だからこそ私は、クラウド依存を避けるために Local LLM を導入し、自分の手元でモデルを動かすことに挑戦した。
しかし、PDFのページ数が増えた瞬間に精度が落ち、前の文書の内容が混ざり、モデルを eject して再読み込みするという作業を繰り返すことになった。
この章では、私が実際に行ったモデル選定、PDF解析の試行錯誤、そして「Local LLM の限界」をどう乗り越えたかをまとめる。
そこで第2章では、私が実際に行った検証の記録をまとめる。
複数のモデルを試し、PDFを読み込ませ、精度の落ちるポイントを見極め、そして最終的に「AIとの共生」に必要な運用方法にたどり着くまでのプロセスだ。Local LLM の“理想”と“現実”の間で揺れながら、私は何を感じ、どう判断したのか。
その実体験を、詳しく紹介したい。
なぜ Local LLM に挑んだのか
クラウド型の生成AIは便利だが、時に“もっともらしい嘘”を返してくる。
私はこの問題に長く悩まされてきた。
そこで考えたのが、
「ならば自分のPCで動く Local LLM ならどうだろう？」
という発想だった。
- データを外部に送らない
- モデルを自由に選べる
- 量子化も変えられる
- そして“嘘”が減る可能性がある
こうした期待から、私は LM Studio を使って Local LLM の検証を始めた。
第1章では、生成AIが抱える「嘘」や「幻覚」という根本的な問題、そしてそれを避けるために私が Local LLM に目を向けた理由を書いた。
クラウドAIの便利さと危うさ、その両方を理解したうえで、私は“自分の手元で動くAI”に可能性を感じた。
しかし、Local LLM を導入したからといって、すべてが魔法のように解決するわけではない。
むしろ、実際に使い始めて初めて見えてくる“壁”があった。
モデルの選定、量子化の違い、PDF解析の精度、ページ数による解像度の低下、そしてモデル内部に残る“前の文書の記憶”。
Local LLM は強力だが、万能ではない。
その限界と向き合いながら、どう使いこなしていくか──ここからが本当の勝負だった。
そこで第2章では、私が実際に行った検証の記録をまとめる。
複数のモデルを試し、PDFを読み込ませ、精度の落ちるポイントを見極め、そして最終的に「AIとの共生」に必要な運用方法にたどり着くまでのプロセスだ。
Local LLM の“理想”と“現実”の間で揺れながら、私は何を感じ、どう判断したのか。
その実体験を、次の章で詳しく紹介したい。
モデル選定：14B クラスの限界と可能性
・・・色々試してみて（Gemma 2 9B Instruct SPPO Iter3 Q5_K_S 9B では、ある程度うまく行った。しかし長文のpdfとなると限界があった）
ここで、最後に選んだのは、
DeepSeek-R1-Distill-Qwen-14B-GGUF（mmnga）Q5_K_M。
選んだ理由は明確だった。
- 日本語最適化が強い
- 事実抽出に強い
- R1系の推論強化で論理性が高い
- 32GB RAM でも動く
- Q5_K_M 量子化で精度が高い
Copilot と Gemini の両方が推奨してきたこともあり、
「これならいける」と思った。
実際、ページ数の少ないPDFでは驚くほど正確だった。
実際の取り組み：PDF解析で起きたこと
私が扱ったPDFは、単なる文章ではない。
- Discord DMログ
- メール
- 時系列資料
- 前提条件
- 英日混在
- 固有名詞・ID・ハンドル名
- 引用文
- 会話の流れ
これらが複雑に絡み合った“高密度文書”ばかり。
ファイルサイズは小さくても、1ページあたりの情報量が異常に多い。
最初は順調だったが、
ページ数が増えると突然、解像度が落ち始めた。
直面した“解像度の壁”と原因
20ページのPDFを読み込ませたとき、
明らかに精度が30％程度まで落ちた。
- 文脈が飛ぶ
- 重要な記述が抜ける
- 前のPDFの内容が混ざる
- 時系列が崩れる
原因は明確だった。
✔ 14Bモデルの context window の限界
高密度PDFは、20ページでも実質40〜60ページ分の負荷になる。
✔ attention の限界
英日混在・DMログ・引用文は attention を大量に消費する。
✔ モデル内部のキャッシュ残留
前のPDFの内容が混ざるのは、まさにこれ。
私は仕方なく、(直感的に)
モデルを eject → 新スレッド → 再読み込み
という作業を繰り返した。
正しい対処だが、正直かなり面倒だった。・・・これは、後からCopiltに聞いてみたが、Copilotも「モデルを eject → 新スレッド → 再読み込み」を正しい対処方法だと認めた。
64GB RAM を検討した理由と現実的な結論
「メモリを増やせば解決するのでは？」
そう思って調べたが、現実は違った。
❌ 14Bモデルの読解精度は RAM を増やしても変わらない
理由は、
モデル構造そのものが限界を決めているから。
ただし、64GBにすれば
- 32Bモデルが動く
- スワップが消える
- 安定性が上がる
というメリットはある。
しかし、
DDR5-5600 64GB が12万円
という現実(去年の今頃の３～４倍の価格)を見て、私は冷静になった。
Local LLM と共生するための運用戦略
最終的にたどり着いた結論はこれ。
✔ 1〜3ページ単位で分割
✔ 各チャンクを独立スレッドで処理
✔ system prompt で強制リセット
✔ 最後に人間（私）が統合・補完する
これが最も安定し、コストもかからない。
そして気づいた事：AIは“補助”、判断は人間がする
Local LLM は強力だが万能ではない。
特に、私のように“高密度PDF”を扱う場合、
AIだけに任せるのは無理がある。
しかし、
AIが抽出した情報を人間が補完する
この組み合わせは非常に強い。
私は今回の経験を通じて、
「AIとの共生」とは、
AIに任せすぎず、AIを道具として正しく扱うこと
だと実感した。
