社内の知見をAIが漏らさず拾う唯一の設計思想 ― Karpathy氏のLLM Wikiを実践して分かったこと

健適文化という会社をやっています。社内ドキュメントが散らかって検索できない、AIに聞いてもまともな答えが返ってこない、そういう課題に対して、会社のナレッジベースをゼロから構築するお手伝いをしています。この記事はその過程で得た知見をまとめたものです。 先に結論 社内ドキュメントをベクトルDBに突っ込んでRAGを組んだのに精度が出ない、という問題の原因は「入れ方」にあります。生のドキュメントをそのまま渡すのではなく、LLMが消化できる粒度まで段階的に加工してから渡す。Anthropicがコンテキストエンジニアリングの文脈でprogressive disclosureと呼んでいる設計思想で、Karpathy氏の提唱するLLM WikiもPineconeのNexusも、突き詰めるとここに収束します。 実際に自分のクラウドストレージ（約20万ファイル）で試したところ、体感レベルでは検索精度が大きく向

[misshiki]

RAGの精度問題は「入れ方」にあるとして、Karpathy氏のLLM WikiとPinecone Nexusを紹介。20万ファイルで試し、知識を取り込み時に構造化・コンパイルする設計が効いたと述べる。

[vcc]

生のドキュメントをそのまま検索対象にするのではなく、一度LLMに読ませて「コンパイル」し、整理されたWikiページ群として保持するという構造

[hasiduki]

へーへーへー！！！！！

[bouzuya]

"ドキュメントが多いほど良いという思い込みもあります。むしろ古い情報、重複、矛盾が精度を下げます。整理して不要なものを削ることこそが精度向上の本丸です。"

[hirrrose]

社内Wiki

[simplememofast]

Karpathy の LLM Wiki は、Allen の GTD で言う「次の物理動作」の知識版。粒度を再呼び出し可能な単位に揃える発想で、ナレッジ管理は格納より取り出しが先

[mkusaka]

RAG精度が出ない原因と、KarpathyのLLM Wiki（三層raw→Wiki→schema）で構造化コンパイルする設計を解説。約20万ファイルで精度向上も報告。