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が標準として形式化したものだ。
この2つは並べて比較する対象というより、積み重なる関係にある。OKFで整理された知識ベースは、そのままRAGの検索対象にもできる。frontmatterがきちんと構造化されていれば、チャンク分割の精度も上がりやすい。逆に、RAGだけを入れてもソース側の知識が整理されていなければ、検索の的中率には限界が出てくる。
どちらを検討すべきか
個人や小規模チームが、比較的安定した知識（研究のノウハウ、過去の判断、蓄積されたルール）を長く使い続けたいなら、OKFのような形式でまず知識を整理することが効いてくる。
実装のハードル自体はそれほど高くない。
一方、リアルタイム性の高い情報を大量に扱う、複数のエージェントが同時に検索する、といった場面ではRAGの技術が必要になる。整理の行き届いた知識ベースがあれば、その上に構築するRAGの精度も自然と上がる。
「RAGかOKFか」ではなく「両方をどう組み合わせるか」という発想に切り替えると、検討がぐっと楽になります。整理された知識の上にRAGを載せる、くらいの順番で考えるのがおすすめです。
このクラスタを通じて一貫して書いてきたのは、どちらの技術・標準にも「飛びつかない」という態度だ。GraphRAGとAgentic RAGは検索回数やリンクをたどる範囲を案件ごとに調整するもので、OKFはv0.1からわずか6週間でv0.2に更新されるほどまだ動いている仕様だ。核となる発想には乗りつつ、細部への追従は都度判断する。この距離感は、RAGを検討するときもOKFを検討するときも変わらない。
知識を資産として扱うということ
RAGもOKFも、突き詰めれば「知識をどう蓄積し、どう使い回すか」という一つの問いに対する、異なる角度からの答えだ。知識は個人の頭の中に留めておくだけでは、その人がいなくなれば失われる。整理して蓄積しておけば、チームで共有できる資産になる。
生成AIは、日々の作業を効率化する道具として語られることが多い。しかし、RAGやOKFのような仕組みを組み合わせることで、副次的に知識の蓄積そのものも効率化できる、という側面がある。質問に答えるたびに、その裏側で知識が整理され、次に使いやすい形で残っていく。これは単なる時短ではなく、資産を積み上げる仕組みでもある。
関連記事
- RAGとは？仕組み・チャンク分割・ベクトルDBを初心者向けに解説
- GraphRAGとAgentic RAGとは？RAGの発展形の違いを整理する
- OKF（Open Knowledge Format）とは？LLM-Wikiパターンの標準化を読む
この記事のブログ版（図表・関連記事つき）はこちら: https://lab.nanairo-days.com/ai-tools/rag-okf-hub/75/