InfoForge：私のローカルAIエージェント用のRAGソースとしてのオフライン版ウィキペディア

私はローカルの8Bモデルに、小説家の夏目漱石がいつ生まれたか尋ねてみました。すると「1867年2月9日」と答えた上で、実際に私が知りたかったこともやってのけました。つまり、その情報の出典となった記事の名前を挙げたのです。このモデル自体はその事実を知りません。しかし、私の家にあるマシンに保存されている52.69GB分のウィキペディアデータからその情報を調べたのです。この処理においてインターネットは全く不要でした。

モデルがすでに「物事を知っている」のに、わざわざする必要があるのでしょうか

なぜなら、そうはならないからです。そしてその失敗の仕方も非常に厄介なものです。小規模なモデルに日付や化学的性質、地名などを尋ねてみると、流暢で自信に満ち、一見もっともらしい答えが返ってきますが、それが正しいかどうかの手がかりは全くありません。モデルは嘘をついているわけではありません。ただ、記憶から引き出した情報と自ら生成した情報を見分ける手段がないだけです。文章作成には問題ありませんが、事実に関しては大問題となります。

検索機能であれば問題は解決しますが、通常の検索の仕組みではクラウド上の検索APIが前提となります。つまり、質問がある企業に送られ、その企業がそれを記録するわけです。そうなると、私のアシスタントは他社の稼働状況や利用規約に依存することになってしまいます。私の子供たちからの質問に答えるためのAIシステムがある我が家では、この両方の点が気になります。

ウィキペディアは、これら二つの問題を同時に解決してくれます。これは最も情報密度の高い一般知識の集積体であり、合法的にその全内容をダウンロードすることも可能です。そして、一晩の飲食代よりも安いディスク1枚に収まってしまうほどです。Kiwixプロジェクトが数年前に大変な作業を行い、全てのウィキペディアの内容を圧縮・インデックス処理されたZIM形式にパッケージ化してくれました。これは学校や船内、インターネット接続がない場所でも利用できるようにするためです。私は単にブラウザの代わりにAIにこのデータを読ませているだけなのです。

最終的に得られるもの

質問が入力され、答えが出力される。さらに、その答えの根拠となったウィキペディアの記事を番号付きで列挙したリストも表示される。これは2026年9月16日に実際に実行された処理例である（サーバーアドレスはループバックです）。

$ infoforge ask "夏目漱石はいつ生まれましたか？"
infoforge: 警告: 曖昧さを解消するためのページである「夏目」をスキップします
infoforge: 警告: 曖昧さを解消するためのページである「漱石」をスキップします
infoforge: 合計5件の記事を基に回答します
提供された情報源によると、夏目漱石は1867年2月9日に生まれました。...

引用文献：
[1] 夏目漱石 — http://127.0.0.1:8080/content/wikipedia_en_all_nopic/Natsume_Soseki
[2] 夏目漱石 — http://127.0.0.1:8080/content/wikipedia_en_all_nopic/Natsume_S%C5%8Dseki
[3] 柳秉天 — ...

4.4秒かかりました。そして、基準となるものが何もない場合には、このようになります。

$ infoforge search "qzxvbnm plorkwidget fnargle"
infoforge: エラー: ‘qzxvbnm plorkwidget fnargle’に対応する情報源が見つかりませんでした
$ echo $?
3

段落は不要ですし、推測も不要です。また、呼び出し側のスクリプトが確認できる終了コードも必要です。askコマンドを実行すると、同じく終了コード3が返されますが、より単純なキーワードを試すか、infoforge doctorを実行するようヒントも示されます。終了コードの一覧は以下の通りです：0は正常、2は設定または使用方法に問題あり、3は参照となる情報が何もない場合、4は出典が引用されていない場合（ただし--strictオプションを指定した時のみ）、5はすべてのモデルエンドポイントに接続できない場合です。終了コード5の場合でも、ツールは見つけた記事内容を出力するため、検索結果が無駄になることはありません。

仕組みについて

5つの段階がありますが、どれも巧妙なものではありません。そのままでいてほしいと願っています。

キーワード抽出。 問題となるのはクエリそのものではありません。Kiwixではすべての検索用語をANDで結合するため、「『こころ』は誰が書いたか、いつ出版されたか？」というようなクエリではほとんど何もヒットしません。一方で「こころ」という単語そのものが適切なクエリとなります。この抽出機能の核心となるのは、元の単語の順序を保持しつつ不要な単語を除外するストップワードフィルターです。

def keyword_query(question: str) -> str:
    tokens = _TOKEN_RE.findall(question)
    keywords = [
        t for t in tokens
        if t.lower() not in _STOPWORDS and t.lower() not in _WEAK_VERBS
    ]
    return " ".join(keywords) if keywords else question.strip()

バージョン2では、二つの機能が追加されました。まず、質問文中の大文字で書かれたフレーズをまず記事タイトルとして試みます。そして、得られた検索結果を再ランク付けすることで、曖昧さを解消するためのページや単なる年表、さらには「～の一覧」といったページが下位に移動するようになっています。

検索機能。 Kiwixの全文検索機能は、単なるgrep処理ではなく、実際の検索インデックスを利用しています。これがこのシステムが機能する理由です。私がこの機能を実装した際、1,919万件ものエントリの中から順位付けされたタイトルを3ミリ秒から30ミリ秒で返していました。2026年9月16日には、同じマシン上でより負荷の高い日に同様のクエリを実行したところ、90ミリ秒から730ミリ秒かかりました。おそらくインデックスがページキャッシュから外れてしまったのだと思いますが、いずれにせよモデルの処理時間と比べれば気にならない程度です。このシステム内にはエンベディングも、ベクトルデータベースも、ダンプ更新時に再構築するためのチャンクストアも存在しません。ウィキペディアの編集者たちがすでにチャンク分けを行っており、彼らはそのチャンクを「記事」と呼んでいます。

取得と切り出し。 kiwix-serveはループバック経由で記事を約1ミリ秒で返します。私が直近で読んだ3つの記事についてcurlで測定したところ、ウォーム状態では0.7～1.1ミリ秒、初回実行時には6～9ミリ秒かかりました。最初の草稿では「0.5ミリ秒」と記述しましたが、それがウォーム状態での数値であることは記していませんでした。切り出し処理のみが判断を要するステップです。冒頭から切り取ると、必要な文が長大な記事の奥深くにあることが多いため、答えが失われることが頻繁にありました。そのため、各記事では先頭部分の短いテキスト（全量の4分の1程度）に加えて、質問文中で最も稀な単語と最もよく一致する箇所周辺を切り出しています。

基本となるプロンプトです。 これが全てのコツであり、4文から成ります。まずルールがあり、次に番号付きの情報源、そして最後に質問が続きます。

あなたは、以下に記載されている情報源のみを根拠として質問に答えるアシスタントです。
ユーザーの質問に対して、これらの情報源に記載されている内容のみを使って回答してください。もし情報源に答えがない場合は、はっきりとそう伝えてください。
情報源の内容を引用する際には、記事のタイトルを明記してください（例：「