家庭で構築するローカルLLM統合システム設計
ChatGPTに匹敵する体験を自作する技術同人誌

家庭用途における現実的な選択肢は以下です．

• 12GBクラス（例：RTX 3060）
  
• 16GB〜24GBクラス（将来拡張向け）
  

12GBあれば7Bモデルが安定します．
24GBあれば14Bモデルや長コンテキストが現実的になります．

VRAMを消費する主因は以下です．

• モデル本体
  
• KVキャッシュ（コンテキスト長依存）
  
• 推論バッファ
  

重要なのは，ベクトルDBは通常VRAMを消費しないという点です．
ベクトルDBは主にRAMまたはSSDを使用します．

• GPU: 12GB以上
  
• RAM: 32GB
  
• SSD: NVMe 1TB
  
• CPU: 6コア以上
  

この構成で実用的な環境が構築可能です．

軽量モデル（常用）:

• 7Bクラス
  

高品質モデル（用途限定）:

• 14Bクラス
  

用途別に切り替える設計が合理的です．

長コンテキストはVRAMを消費します．

• 8k: 安定
  
• 16k: やや重い
  
• 32k: 上位GPU向け
  

長文対応はRAGで補う方が効率的です．

RAGは以下で構成されます．

1. 文書保存
   
2. チャンク分割
   
3. Embedding生成
   
4. ベクトルDB登録
   
5. 類似検索
   
6. LLMへ注入
   

ローカル文書が頻繁に更新される場合：

• 変更ファイルのみ再インデックス
  
• ハッシュ管理による差分検出
  

全再構築は不要です．

標準UIにはファイル監視機能がありません．
そのため以下を実装します．

• ファイル監視
  
• 差分検出
  
• 再Embedding
  
• DB更新
  

これにより常に最新状態を維持できます．

Web取得 → 本文抽出 → チャンク化 → Embedding → DB登録

推奨：

• RSS駆動型
  
• 特定ドメイン限定
  
• 定期バッチ処理
  

無差別クロールは非推奨です．

• robots.txt遵守
  
• 著作権確認
  
• 利用規約確認
  

個人利用でも注意が必要です．

OpenAI互換APIはステートレスです．
毎回以下を送信します．

• system
  
• user
  
• assistant履歴
  

systemプロンプトはリクエストごとに送信します．
Elisp側で可変変数として管理します．

ロール変更時は履歴をクリアする設計が望ましいです．

• バッファローカルsystem変数
  
• 履歴管理
  
• ストリーミング対応
  

これにより柔軟な人格切替が可能になります．