クラウドを使わないMCP

筆者は、MCPはエージェント専用ではなく、大規模なローカルドキュメントコレクションからの検索を実装するなど、他の目的にも使用できると主張しています。従来のRAGも検討されましたが、エンベディングモデルやベクトルデータベース、定期的な再インデックス付けなどの重要なインフラストラクチャが必要であり、モデルが特定の断片を選択した理由を監査するための透明性が提供されません。代わりに、目次の役割を果たすインデックスファイル（llms.txtのアイデア）を使用することを提案しています。モデルはまずインデックスを読み、次にサブインデックスを読み、その後でドキュメントの特定のセクションを取得します。筆者は、PDFをMarkdownに変換し、クリーンアップし、セクションに分割し、index.mdとsubindex.mdを作成し、すべてをGitに保存し、モデルに接続するMCPサーバーであるDocShelfツールを作成しました。パイプラインは次のとおりです。PDFからMarkdownへ、次にセクションへの分割、次にインデックスの構築、次にGitへの保存、次にMCPサーバーを介してLLMへ。モデルはアーカイブ全体のほんの一部だけを消費します。85 MBのシェルフを使用した例では、約16.5 KBのコンテキストが使用されました。記事では、PDF解析の問題、キリル文字の破損、貧弱なMarkdown構造など、よくある落とし穴も強調し、トラブルシューティングのテーブルを提供しています。2つのコンバータが利用可能です。pymupdf4llm（高速、GPU不要）とmarker-pdf（複雑なケース向けですが、重い）。DocShelfはGitをストレージ、バージョン管理、レビューとしてサポートし、閉域ネットワークでも動作できます。筆者は、このアプローチは、監査が必要でコーパスがローカルであるシナリオにおいて、従来のRAGの実行可能な代替手段であると結論付けています。