RAGとOKF、AIに知識を渡す2つの方法

「RAGを入れるべきか、それとも知識をきちんと整理しておくべきか」。この2つ、実は択一の質問ではない。

この記事では、RAGとOKFというレイヤーの異なる2つの視点を整理し、このクラスタで書いた4本の記事への案内をまとめます。

この2つは、AIに知識を渡すという同じ目的に対して、まったく違うレイヤーの問題を解いている。このクラスタでは、RAGとOKFそれぞれの仕組みと自分たちで試した内容を4本の記事で1本ずつ書いてきた。ここでは全体を見渡し、両者の関係と使い分けを整理する。

RAGとOKFは競合しない

RAG（検索拡張生成）は、質問が来るたびに関連情報を検索し、その場で文脈として渡すランタイムの技術だ。

チャンク分割とベクトルDBがその土台になる。情報量が増えると検索精度が頭打ちになるという課題に対し、次の発展形が生まれている。

OKF（Open Knowledge Format）は逆に、知識をどうファイル化し、どう構造化しておくかという表現形式の標準だ。

Markdown＋YAML frontmatterというシンプルな形式で、AI研究者Andrej Karpathy氏が提唱したとされる「LLM-wiki」パターンを、Google Cloudが標準として形式化したものだ。

どちらを検討すべきか

個人や小規模チームが、比較的安定した知識（研究のノウハウ、過去の判断、蓄積されたルール）を長く使い続けたいなら、OKFのような形式でまず知識を整理することが効いてくる。

実装のハードル自体はそれほど高くない。

一方、リアルタイム性の高い情報を大量に扱う、複数のエージェントが同時に検索する、といった場面ではRAGの技術が必要になる。整理の行き届いた知識ベースがあれば、その上に構築するRAGの精度も自然と上がる。

このクラスタを通じて一貫して書いてきたのは、どちらの技術・標準にも「飛びつかない」という態度だ。GraphRAGとAgentic RAGは検索回数やリンクをたどる範囲を案件ごとに調整するもので、OKFはv0.1からわずか6週間でv0.2に更新されるほどまだ動いている仕様だ。核となる発想には乗りつつ、細部への追従は都度判断する。この距離感は、RAGを検討するときもOKFを検討するときも変わらない。

知識を資産として扱うということ

RAGもOKFも、突き詰めれば「知識をどう蓄積し、どう使い回すか」という一つの問いに対する、異なる角度からの答えだ。知識は個人の頭の中に留めておくだけでは、その人がいなくなれば失われる。整理して蓄積しておけば、チームで共有できる資産になる。

生成AIは、日々の作業を効率化する道具として語られることが多い。しかし、RAGやOKFのような仕組みを組み合わせることで、副次的に知識の蓄積そのものも効率化できる、という側面がある。質問に答えるたびに、その裏側で知識が整理され、次に使いやすい形で残っていく。これは単なる時短ではなく、資産を積み上げる仕組みでもある。

関連記事