OKF × RAG Synergy

OKF(Open Knowledge Format)と RAG は競合ではなく、バンドルが RAG の精度を左右する知識基盤になるシナジー関係にある

OKF × RAG Synergy

“OKF と RAG はどっちを使えばいいのか?”

この質問はもっともらしく見えて、実は前提が間違っています。OKF(Open Knowledge Format)と RAG(Retrieval-Augmented Generation)は対立する選択肢ではなく、役割が違う相棒です。

  • RAG … 必要な断片を検索して LLM に読ませ、回答を生成する 仕組み(アーキテクチャ/実行フロー)
  • OKF … 知識をどういう形で持ち・公開・相互運用するかを定義する 規格(データ表現)

本ページではこの関係を、このリポジトリが実際に生成する okf/ バンドルを例に分解し、OKF が RAG の精度を左右する入力(=RAG-ready な知識基盤)になることを示します。

まず RAG の強みと弱み

RAG の流れはおおまかに次の通りです。

  1. 質問を受け取る
  2. ベクトル/ハイブリッド検索で関連文書の断片を取得する
  3. 断片をコンテキストに投入する
  4. LLM が根拠つきで生成する

強み: - 最新の社内ドキュメント等、動的に変わる情報を参照しやすい - 参照元を提示しやすく、根拠運用に向く(設計次第)

弱み: - 検索ミスがそのまま回答ミスになる(“検索品質が性能を支配しがち”) - 断片数が増えるとコンテキスト費用が増える - 曖昧な質問・複雑な推論は、断片が不十分だと限界が出る

RAG の精度を分解すると、こう整理できます。

  • 検索(retrieval)の成否: 必要な断片が引けるか
  • 生成(generation)の成否: 引けたものを根拠に整合的に書けるか
  • コンテキスト設計: 何を・どれだけ・どの順で渡すか

ここで注目すべきは、検索・コンテキスト設計を決めているのは「データがどう整理されているか」だということです。断片がバラバラなら RAG は苦労し、断片に粒度・メタデータ・関係があるなら RAG は一気に設計しやすくなります。

OKF が提供するもの

OKF はその「断片の質」を規格で保証します。このリポジトリでは、concepts/*.qmd が 1 概念 = 1 ファイルの情報源(ソース・オブ・トゥルース)で、そこから okf/ バンドル(index.md / log.md / concepts/*.md)を生成します。

1 ファイルの frontmatter は機械にとっての「辞書」です。実例(Get User):

---
type: APIEndpoint
title: "Get User"
description: ユーザー情報を取得する。
resource: https://example.com/api/v1/users/{userId}
method: GET
path: /v1/users/{userId}
tags: [read, users]
status: stable
generated: { by: human:okf-seedling, at: 2026-08-11T00:00:00Z }
verified: { by: human:okf-seedling, at: 2026-08-11T00:00:00Z }
stale_after: 2026-12-31
---
  • type(必須)… 概念の種別。レジストリ(tools/okf-types.json)で拡張可能
  • status / generated / verified / stale_after … 鮮度・信頼・検証履歴
  • resource / tags … 対象と分類
  • 型固有フィールド … API なら method / path、計算なら runtime / parameters / executor / attester

ポイントは、これらが「ただの yaml」ではなく、後述の RAG 設計の条件(フィルタ・ランキング・コンテキスト優先度)にそのまま使えるフィールド群だということです。

なぜ競合ではなくシナジーか

OKF と RAG は、データ層と推論層という別レイヤーにいます。

レイヤー 役割 ツール
データ層 知識の持ち方・交換・更新 OKF(okf/ バンドル)
推論層 質問への根拠つき回答 RAG(検索 → コンテキスト → 生成)

シナジーは「RAG が OKF データを検索・取得してコンテキスト化する」接点で発生します。OKF が強いほど RAG は設計しやすくなり、RAG が強く使われれば OKF の知識が活きます。OKF=データ側の基盤、RAG=利用側の推論基盤です。

OKF データを RAG で使う 2 つのモード

モード A: ドキュメント RAG(テキスト断片を引く)

OKF の各レコードを「検索用テキスト(+埋め込み)」として扱う使い方です。断片化(chunk)ルールは OKF の粒度と整合させます。

例: Playbook(インシデント対応)は Trigger / Steps という見出し規約で構造化されています。ここから Steps 節だけを断片にすれば、チャンク戦略が自明になります。

モード B: 構造 RAG(プロパティと関係で引く)

OKF レコードのプロパティやリンク(参照/包含)を「絞り込み + 辿り」に使う使い方です。LLM には、辿って得た根拠セットを渡します。

例: Metric(Revenue)は、Attested Computation への参照を持つ type: Metric レコードです。ここから「定義 → 計算式 → 実行器/検証器」と参照を辿れます。

シナジー実演: 質問「この資格、合格するには?」が辿る経路

OKF の frontmatter が RAG のフィルタ・ランキング・コンテキスト組み立てに直結する流れを、資格取得・受験勉強の事例で示します。

flowchart TB
    Q["質問: この資格、合格するには?"] --> F1["type で絞り込み: Metric + Playbook + AttestedComputation"]
    F1 --> F2["stale_after で鮮度フィルタ<br>(旧シラバス・旧試験範囲を除外)"]
    F2 --> F3["status: stable を優先<br>(公式ガイド・対策本を上位に)"]
    F3 --> R["参照を辿る: Metric 合格ライン<br>→ Playbook 学習計画 → 計算演習"]
    R --> C["コンテキスト: 合格基準 + 学習計画 + 復習手順"]
    C --> LLM["LLM が根拠つきで生成"]

  1. 型で絞り込み: type: Playbook(学習計画・復習手順)・type: Metric(合格ライン)・type: AttestedComputation(計算演習)を持つレコードだけを候補にする。関係ない概念は最初から探索範囲に入らない(≈ 検索空間の縮小)
  2. 鮮度フィルタ: stale_after を基準に、改訂前シラバス・旧試験範囲のレコードを除外。RAG が「古い試験対策」を回答に混ぜるリスクを、検索段階で防げる
  3. 信頼ランキング: status: stable、verified を持つ公式ガイド・対策本のレコードを優先
  4. 参照を辿る(モード B): Metric の「合格ライン」→ Playbook の「学習計画」→ 苦手分野の Attested Computation「計算演習」という関係を辿り、根拠セットを完成
  5. コンテキスト組み立て: 辿って得た「合格基準 + 学習計画 + 復習手順」だけを LLM に渡す

つまり RAG の「どこを、どう絞り、何を渡すか」という設計判断の大半が、OKF の frontmatter から決まります。 これが本題のシナジーです。

OKF ならではの付加価値

  • 検証可能性: Attested Computation の executor / attester が、回答の根拠が「実行・検証可能」であることを示す。RAG 単体では作りにくい属性
  • 機械可読なメタデータ: concept-meta ブロックとして HTML にも出力されるため、DOM から安定セレクタで抽出できる(このリポジトリの Playwright 知識パイプラインがその前提を利用)
  • 差分追跡: okf/ は sha 差分を機械が検知できる。知識更新のトレーサビリティが RAG の再インデックス運用と整合する

RAG 単独で起きがちな問題と、OKF での解消

問題 1: 検索したのに前提が違う

  • 例: 「A の手順」だけ引いたが、実は B 環境限定だった
  • OKF での解消: tags / resource / 型固有フィールド(method / path 等)を持たせ、フィルタやコンテキスト組み立てで防ぐ

問題 2: 根拠が混ざって、回答が矛盾する

  • 例: 同じ質問に対して古い仕様と新しい仕様が混入
  • OKF での解消: status / generated / verified / stale_after で検索・ランキング段階の優先順位を決める

問題 3: 粒度がバラバラで、結局チャンク運ゲーになる

  • OKF での解消: 型ごとの見出し規約(tools/okf-types.json の headings)と「1 概念 = 1 ファイル」で粒度を揃え、チャンク戦略を安定させる

設計チェックリスト

OKF 側で決めるべき設計項目と、RAG に効く観点です。

  • 粒度: 1 レコードは何か(概念 / 手順 / 指標 / 計算定義)
  • 本文フィールド: 検索・生成で読ませる文章をどのフィールドに持つか
  • メタデータ: 対象、適用条件、期限(stale_after)、バージョン、信頼度(verified)
  • 関係: 参照先、上位概念、前提条件、依存関係(例: Metric → AttestedComputation)
  • 正規化: 用語の ID 体系(例: urn:metric:acme:revenue)、同義語、表記揺れ対策
  • 根拠: 根拠 URL / 出所(sources) / 原典
  • 更新戦略: 改訂時にレコードを置換するか、履歴を残すか

次の一歩

“RAG を強くしたい”なら、まず知識を RAG-ready な形式にしておくのが近道です。このリポジトリはその土台を一発で生成します。

quarto use template watanabe3tipapa/okf-seedling
quarto render
node tools/validate-okf.mjs

テンプレートをフォークした場合は、watanabe3tipapa を自分の GitHub 組織名に置き換えます。

生成された okf/ バンドルは、そのまま RAG のインデックス・フィルタ設計に使い始められます。仕組みの詳細はクイックスタート、型の設計はConcept Typesを参照してください。