結局、LLM Wikiはどうなのか | メンバー限定記事
Andrej KarpathyのLLM Wikiは、一つのソリューションではあります。
自分が保有しているデータを単にベクトル化して自然言語で検索できるようにするだけでなく、段階的な抽出と構造化によって、より網羅的に探せるようにすること。
ポイントは以下でしょう。
Most people’s experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There’s no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.
「This works, but the LLM is rediscovering knowledge from scratch on every question. There’s no accumulation. 」
LLMに質問するたびに毎回ググっているようなものであって、それはそれで見つかるが、そこには 蓄積（accumulation）がない。言い換えれば、LLM Wikiはその蓄積を目指す手法ということです。
全rawデータを段階的に抽出し、階層的な構造で整理させることよって、LLMはそこに保存されているデータを「理解」できるようになります。人間にたとえれば、ベクトル単体ならば「連想で思い出せたものを並べる」だったものが、「情報の構造に合わせて適切に処理できる」に変わるわけです。
もちろん、良い結果を引き出すでしょう。これを維持するためのトークンが割に合うかどうかは別として、維持できているなら大量の情報を適切に扱えるようになることは疑いありません。
だってそれは「司書」がやっていることですから。
司書さんは、何か質問されたときに、適当に思いついた本のタイトルを教えているわけではありません。職業的なプロとして、日本十進分類法エトセトラが頭に入っており、どこを探せばいいのかを把握しています。高度なレファレンスには、情報の構造的理解が欠かせないのです。
単なるベクトル連想だったLLMが、構造的司書に変身するのですから、ありがたいことは間違いないでしょう。
イメージしてみましょう。あなたが住んでいる町にはじめて図書館ができて、そこに優秀な司書さんがやってきます。あなたが何かしらの研究を行っているなら大いに助かるはずです。
もちろんそれは、あなたが自分で研究する限りにおいて、という保留がつきますが。
