コードベースのナレッジ化なら、LLM Wikiで十分かもしれない - Qiita

前書き コーディングエージェントに改修を依頼するたびに、「この修正はどこまで影響するんだろう」と、同じ調査を何度もやり直させた経験はないでしょうか 社内の仕様書や設計ドキュメントをベクトルDBに入れて、エージェントに検索させる構成を組んでいる方も多いと思います。 ドキュメントの中身自体は正しく引けるものの、同じ質問をするたびにベクトル検索の結果から答えを組み立て直すため、聞くたびに微妙に言い回しが変わったり、検索コストがじわじわ積み上がったりする——そんな感覚に心当たりはないでしょうか。 この課題を解決する考え方として、「 LLM Wiki 」というアプローチがあります。 本記事では、まず従来の検索型ツールが抱える限界を振り返り、次に「LLM Wiki」という考え方を整理し、最後に、OpenWikiという「LLM Wiki」に似た仕組みを持つライブラリーを動かすところまでを紹介します。 エ

[yarumato]

“LLM Wikiと似た仕組みを持つツールが立て続けに出てきた。質問のたびに生データから答えを組み立て直すRAGと違い、データを取り込むタイミングで一度だけコストを払う。Wikiのメンテもエージェントなら面倒がらない”

[simplememofast]

RAGが毎クエリで答えを組み直すのに対し、取り込み時に一度書くのはDBのマテビュー化と同型。クエリ費と鮮度管理コストのトレードオフを移し替えた整理だと読んだ

[nguyen-oi]

毎回ベクトル検索回してトークン溶かすより事前にMarkdown化しておく方が理にかなってる

[pmint]

低品質。読みもせず投稿。タイトルくらいは見直さないと。