ローカルLLMとオフラインWikipediaの比較

• 最近のMIT Technology Reviewの記事で、ローカルLLMをオフラインのバックアップWikipediaと比較するというアイデアが紹介された
• Ollamaライブラリの主要LLMモデルのファイルサイズと、Kiwixが提供するオフラインWikipediaバンドルの容量を直接比較している
• LLMファイルとWikipediaデータは目的・強み・弱みが異なるため単純比較は難しいが、容量ベースでは興味深い差がある
• 一部の**LLM（1〜4GBモデル）**はSimple English Wikipedia（約1GB）より大きく、完全版Wikipedia（57GB）は大規模LLM（20〜32GB）より大きい
• ファイルサイズ以外にもメモリやCPU要件など現実的な考慮が必要で、実際の利用目的によって選択は変わりうる

---

ローカルLLMとオフラインWikipediaの比較

導入と比較のきっかけ

• MIT Technology Reviewで最近「How to run an LLM on your laptop」という記事が紹介された
• その記事では、ローカルでLLMを動かしてオフライン環境でも知識を活用できる点が強調されている
• Simon Willisonの**「オフラインLLMはWikipediaの要約された不完全版のようなもので、終末的状況でもUSBさえあれば社会の再起動に役立つ」という比喩**が印象的だった

モデルとデータ容量の比較

• Ollamaライブラリの複数のLLMモデルと、Kiwixが提供するオフラインWikipediaバンドルのファイルサイズを比較している
• 比較のため、一般的なコンシューマー向けハードウェアで実行可能なモデルと、画像なしのWikipediaデータに限定している
• 主な比較結果は以下の通り:
  • 最小の要約版
    • Best of Wikipedia（上位5万件、要約版）: 356.9MB
    • Simple English Wikipedia（要約版）: 417.5MB
  • 代表的なLLMモデル（小型）
    • Qwen 3 0.6B: 523MB
    • Deepseek-R1 1.5B: 1.1GB
    • Llama 3.2 1B: 1.3GB
  • 代表的なLLMモデル（中〜大型）
    • Deepseek-R1 8B / Qwen 3 8B: 5.2GB
    • Gemma3n e4B: 7.5GB
    • Deepseek-R1 14B: 9GB
    • Qwen 3 14B: 9.3GB
  • Wikipedia全体
    • Wikipedia（全体）: 57.18GB
• Wikipediaの上位5万件の記事は356.9MBと非常に小さい
• **最小のLLM（0.6B、Qwen）**は523MBで、単純なWikipedia要約版より大きい
• **Wikipedia全体（57.18GB）は最大級のLLM（20GB）**よりはるかに大きい

比較の限界と考慮点

• 直接比較は難しい: 百科事典（データ）とLLM（生成モデル）は本質的に目的も構造も異なる
• 重要なのはファイルサイズだけではない: LLMはファイルサイズに加え、実行時のメモリとCPUリソースも多く必要とする。オフラインWikipediaは低スペック機器でも動かしやすい
• 実際の用途ごとの有用性: たとえば化学分野だけをダウンロードすることもできるし、特定ハードウェアに最適化されたLLMを使うこともできる
• 選定基準の主観性: 比較に使った項目の選び方には主観がある

結論と示唆

• Wikipediaの上位5万件の記事とLlama 3.2 3Bモデルは、ファイルサイズの面では近い水準にある
• 最小のWikipediaバンドルは最小のLLMよりも小さく、Wikipedia全体のファイルは最大のLLMより大きい
• 十分なストレージがある環境なら、LLMとWikipediaデータの両方をダウンロードして活用することも検討に値する

[GN⁺]

Hacker Newsのコメント

• LLMの強みは、単なる知識の保存や検索ではなく理解力にある。Wikipediaのような単純なデータではなく、曖昧だったり不正確だったりする質問も把握して、ユーザーのレベルに合わせて説明し、複数の分野を結び付けられる。社会を再起動するような状況では、こうした相互作用的な理解のほうがより価値を持つかもしれない。単なる知識のスナップショットではなく、人々がそれを活用し学べる道具になると思う
  • 信頼できないコンピューターが情報化以前の社会で神のように崇拝される、そんなスタートレックのエピソードを思い出す
  • LLMが「より」価値があるかは分からないが、確かに有用ではある。今のAIの使われ方はあまり好きではなく、根本的には強化されたオートコンプリートのようなものだと思う。それでも検索エンジンとしては非常によく機能する。Copilotに短い質問をすると、しばしばまずまずの答えが返ってくる。しかし、かなり深い技術的な質問をすると、でたらめをたくさん言う。常に警戒が必要だ。CentOSのリポジトリファイルの生成を頼んだところ、全体としては完璧だったのに、gpgkey を http で指定していてセキュリティに穴が開いた経験がある
  • 理想を言えば、他人の要約よりも一次資料を批判的に読むべきだ。学校では誰もがそう学び同意するが、実際にやる人は少ない。卒業後は三次資料だけを信頼する傾向がある。LLMを活用して、その主題における最新の史学の潮流や参考にすべき資料を見つけられたことがある。一方で、Wikipediaの編集者がWikipediaは不正確だと言われると敵対的に振る舞う例も多く、実際に参考文献を確認しないと誤解を招く内容も多いと感じた
  • コンピューターやスマートフォンが残っていることが前提だ。Wikipediaや何冊かの本を印刷して保管しておくほうが、安全なバックアップになるかもしれない。しかし、本当に社会が再起動するなら、いっそまったく違う形で始めてみるのも意味があるかもしれない
  • オフラインWikipediaと他の情報源、そしてローカルLLMの組み合わせが最善だと思う。LLMが簡潔で関連リンクを提供してくれるなら、なお良い。検索機能付きのLLMは説明が長すぎることが多く、もっと多くのリンクを提示して、必要な情報へ移動できるようにしてくれたほうがいい
• 「USBスティック1本で社会を再起動する」というのは、インタビュー中に何気なく口にしただけで、これが記事に書かれるとは思っていなかった 記事リンク。多くの人がWikipediaをUSBに入れるのが合理的だと言っていて、それには同意する。WikipediaのダンプはMySQLなので、SQLiteに変換してFTSを使うほうが便利そうだ。1TB以上のUSBも簡単に手に入るので、保存容量の心配はほとんどない
  • こうした知識をあらかじめ搭載したUSBスティックを作って販売する会社を、誰かが始めそうだ。電磁パルス保護用の箱まで付ければ、実際の災害時に大きな助けになるだろう。保存価値が最も高いのは、大規模災害リスクに関する情報だと思う。著作権の問題で『Global Catastrophic Risks』のような本は入れられないが、関連ウェブページ などはクロールできそうだ
  • 10年以上、携帯電話やPDAにローカルのWikipediaダンプを入れて持ち歩いていた（ここ5年ほどは画像付き）。災害対策だけでなく、オフライン用途でもよく役に立つ。最近はLLMなどのモデルが本当に有用になってきたので、RAG形式でローカルモデルとWikipediaを組み合わせれば相乗効果があると期待している
  • 昔のコメントを再引用すると、デジタル化されたすべての本は約30TB、圧縮すれば約5.5TBで、2TBのmicroSDカード3枚に収まる。およそ750ドルで全体を持ち運べる
  • わざわざSQLを使わなくてもKiwixを使えばいい
  • 記事の導入があまりにも大げさなのが少し気に障る。記者はいつも道具を過剰に壮大なものとしてフレーミングしている気がして、妙な感じがする
• 今ちょうど wikipedia_en_all_maxi_2024-01.zim をダウンロード中で、libzimでページを抽出してLLMと連携させようとしている。zimファイルはページをHTMLで保存していて、約100GBある。理由は、HDDに大量保存されたゲーム一覧（タイトルだけで、別途カテゴリなし）をWikipediaの記事とマッチングさせて、ジャンルや情報で整理したいからだ。試してみたところ、LLM（Mistral Small 3.2 quantized）が驚くほどこの混沌をうまく整理してくれる。llama.cpp でカスタムスクリプトから高速に動かせる
  • 実際には、こうしたゲームとWikiの連携作業はWikidataクエリのほうがずっと簡単だ。英語版Wikiにまだ存在しないゲームまで含められるかもしれない
  • こういう技術的な体験談こそ、まさに自分がHNを見る本当の理由だ。個人的に悩みながら作った何かを、十分なディテールで共有してくれるのが新鮮に感じる。自分もLLMをいじっているが、こんなに有用な事例を見るのは初めてで、もっと学ばなければと思った。良い情報に感謝している
• Wikipedia、arXivのダンプ、オープンソースコードは、実行可能なコードと信頼性のある情報が大半で、安価で検索しやすい。FOSSアプリはすぐ使えるし、Wikiは主題を紹介したり整理したりしてくれる。一方、LLMは特に小型モデルほど結果を作り話しがちだが、整っていない質問にも答えようとし、（時には）膨大な一次資料を直接読んで整理することもできる。オフライン作業の状況では、既存のライブラリを最大限活用するのが良いと感じるし、コーディング支援としてのLLMにも実用例は思い浮かぶ。ただ、ローカルモデルを使った経験はなく、ベンチマークではQwen3 32Bがコーディング支援になるらしいので、いずれ活用できるかもしれない
• LLMのあまり語られない強みの1つは、言語に縛られず知識を活用できることだ。英語版Wikiにはたいてい内容がそろっているが、他言語ではそうではない。英語版Wikiにもない情報が別言語のWikiにあることもあり、LLMはそれらすべてを1つにまとめて、さまざまな言語でアクセスできる
• AI企業はウェブ全体をLLMに蒸留して賢いコンピューターを作ったのに、なぜ人類は著作権付きの部分まで含めて新しい超一流のWikipediaを作れないのか、不思議に思う。なぜ子どもたちはAI企業より劣っていて、こういうものを作れないのかと考えてしまう
  • それは実際に私たちがずっとやってきたことだ。ただ、今では百科事典があまり売れないだけだ
  • それが図書館だ
• Wikipedia Monthly というWikipediaの月次ダンプに触れておきたい。341言語で合計205GB、英語だけなら24GBだ。MediaWikiマークアップからクリーンテキストに変換されているので、ローカル検索インデックスやさまざまな用途に向いている。Simple English Wikipediaは内容が浅く、正確さにも欠けると感じる。Wikipedia Monthlyのブログリンク
• LLMの有用性を議論する際、状況別の具体的な活用度がいつも抜け落ちているのが残念だ。LLM登場以前は、情報検索や機械学習には厳格な基準や評価セットがあった。しかし現時点では、LLMのほうがより汎用的で多様な課題を解けるようになっているにもかかわらず、実際のLLM対他手法のベンチマーク資料がもっと多くないのが不思議だ。研究界隈の動向をよく知らないので、自分が見落としているだけかもしれない
• LLMは不正確な情報を出すという論争が多いが、理想的な「ドゥームズデイ情報問い合わせデータベース」は、LLM + ファイルアーカイブ構成が最善だと思う。第1段階として、LLMが人間の曖昧な質問を理解して、核心概念と関連するWiki文書などへのリンク一覧を提示する。第2段階として、ユーザーが提示された文書から直接、信頼性の高い情報を確認できる
  • かなり悲観的な自分でさえ、LLMは人間の文章を検索語に翻訳する道具としてはうまく使えそうだと思う。仲介者というより、助言者やチューターとして使うのが理想だろう。結局のところ、重要なのはユーザーが限界を乗り越えることだ
• "$1-distill-$2" のような名前のモデルは（時には -distill が付かないこともあるが）、$2モデルに$1の出力を学習させて作った「知識蒸留（distillation）」モデルなので、名前とは違って$1そのものではない。記事に出てくる「Deepseek-R1 1.5B」のようなモデルは実在せず、この種のものだ