ナレッジベース on KnightLiブログ

OpenKB：ドキュメントを継続更新される LLM ナレッジベースへコンパイルする

Sun, 17 May 2026 17:15:08 +0800

OpenKB は、VectifyAI が公開しているオープンソースの LLM ナレッジベースツールです。

これは、ドキュメントをチャンク化し、ベクトル化し、問い合わせ時にコンテキストを組み直すだけの従来型 RAG システムではありません。OpenKB はまず生のドキュメントを構造化された wiki にコンパイルします。そこには文書要約、概念ページ、相互参照、後続の問い合わせ、lint チェックが含まれます。言い換えると、資料を継続的に整理していくナレッジベース CLI に近い存在です。

プロジェクト：https://github.com/VectifyAI/OpenKB

先に結論

OpenKB で注目したい点は 3 つあります。

ナレッジベースを専用データベースに閉じ込めず、通常の Markdown ファイルとして出力する。
PageIndex で長い PDF を処理し、ベクトル DB なしの長文ドキュメント検索を重視している。
「知識のコンパイル」を重視し、毎回ゼロから検索するのではなく、LLM が要約、概念ページ、相互リンクを生成する。

そのため OpenKB は、論文読解、プロジェクト文書、社内資料、技術仕様、製品調査、個人ナレッジベースのように、資料を長期的に蓄積する場面に向いています。

一方で万能の代替ではありません。高並行のオンライン Q&A、複雑な権限管理、Web 管理画面、企業向け監査、大規模なマルチテナント機能が必要なら、現時点の OpenKB は完全な企業ナレッジプラットフォームというより、開発者向けツール兼ナレッジベースのプロトタイプに近いです。

OpenKB とは

OpenKB は Open Knowledge Base の略です。

CLI として動作し、知識庫に入れた原始ドキュメントを変換、整理、要約し、一連の wiki ファイルを生成します。公式 README の説明は明快です。OpenKB は LLM を使って原始ドキュメントを構造化された相互リンク付き wiki スタイルのナレッジベースへコンパイルし、PageIndex によってベクトルレスな長文ドキュメント検索を支援します。

対応する入力形式は次の通りです。

PDF
Word
Markdown
PowerPoint
HTML
Excel
プレーンテキスト
markitdown で変換できるその他の形式

生成されたナレッジベースは wiki/ に置かれ、主に次の内容を含みます。

index.md：ナレッジベースの概要
log.md：操作タイムライン
AGENTS.md：ナレッジベース構造とメンテナンス方針
sources/：変換後の原文
summaries/：各ドキュメントの要約
concepts/：ドキュメント横断の概念ページ
explorations/：保存された問い合わせ結果
reports/：lint レポート

この設計の最大の利点は透明性です。ブラックボックスの検索インターフェイスから答えを受け取るだけでなく、Markdown ファイルを直接開いて知識庫を確認できます。

従来型 RAG との違い

従来型 RAG の典型的な流れは次のようなものです。

ドキュメントをチャンクに分割する。
embedding を生成する。
ベクトルデータベースに保存する。
問い合わせ時に関連チャンクを取得する。
それらを LLM に渡して回答を生成する。

この流れは成熟しており、Q&A システムにも向いています。ただし、知識そのものは本当の意味では蓄積されません。質問のたびに、関連片を探し、コンテキストを組み立て、回答を生成し直すことになります。

OpenKB の考え方は「先に整理し、それから問う」に近いです。

ドキュメントを raw/ に入れる。
短いドキュメントは markitdown で Markdown に変換する。
長い PDF は PageIndex でツリーインデックスと要約を生成する。
LLM が文書要約を生成する。
LLM が既存の概念ページを読み、ドキュメント横断の概念を作成または更新する。
ナレッジベースの索引、ログ、相互リンクを更新する。

その結果、新しいドキュメントを 1 つ追加することは、単に検索可能なファイルを 1 つ増やすことではありません。十数個の wiki ページが更新されることもあります。知識は概念ページに書き込まれ、既存資料と接続されます。

これは人間がナレッジベースを維持する方法に近いです。新しい資料が入ったら、保管するだけではなく、トピックページを更新し、差分を要約し、参照を追加します。

PageIndex が解決する問題

長文ドキュメントは、RAG と LLM ナレッジベースにとって常に難所です。

長い PDF を単純に多数の chunk に分けると、次の問題が起きやすくなります。

章や節の関係が失われる。
表、画像、脚注を扱いにくい。
検索される断片が細かすぎて、回答に全体構造が欠ける。
コンテキストウィンドウが大きくても、文書全体を詰め込むのは適切ではない。
要約の連鎖が長いと、細部が圧縮されて失われやすい。

OpenKB は長い PDF の処理に PageIndex を使います。プロジェクト説明によると、PageIndex は長文ドキュメントに対してツリーインデックスと要約を作成し、LLM が全文を直接読むのではなく、文書ツリー上で推論できるようにします。

この路線の要点は「ベクトル類似度が最も高い数段落」を探すことではありません。モデルが文書の階層構造を利用して関連内容を見つけられるようにすることです。研究レポート、論文、マニュアル、目論見書、コンプライアンス文書のような長い資料では、この考え方はかなり有効です。

OpenKB はデフォルトでオープンソース版 PageIndex をローカル実行できます。OCR、複雑な PDF 処理、より高速な構造生成が必要な場合は、PAGEINDEX_API_KEY を設定して PageIndex Cloud を使うこともできます。

インストールとクイックスタート

OpenKB は pip で直接インストールできます。

`1`	`pip install openkb`

GitHub の最新バージョンを入れることもできます。

`1`	`pip install git+https://github.com/VectifyAI/OpenKB.git`

ソースから開発用にインストールする場合：

1
2
3

git clone https://github.com/VectifyAI/OpenKB.git
cd OpenKB
pip install -e .

ナレッジベース用ディレクトリを作成します。

1
2

mkdir my-kb && cd my-kb
openkb init

ドキュメントを追加します。

1
2

openkb add paper.pdf
openkb add ~/papers/

質問します。

`1`	`openkb query "What are the main findings?"`

対話モードに入ります。

`1`	`openkb chat`

新しいファイルを自動処理したい場合は watch モードを使います。

`1`	`openkb watch`

その後 raw/ にファイルを置くと、OpenKB が自動的に wiki を更新します。

LLM 設定

OpenKB は LiteLLM を通じて、OpenAI、Claude、Gemini など複数のモデルプロバイダーに対応します。

モデルは初期化時に設定できますし、.openkb/config.yaml に書くこともできます。

1
2
3

model: gpt-5.4
language: en
pageindex_threshold: 20

モデル名は LiteLLM の provider/model 形式に従います。OpenAI モデルでは provider 接頭辞を省略できます。

`1`	`model: gpt-5.4`

Anthropic や Gemini のモデルは通常、次のように書きます。

`1`	`model: anthropic/claude-sonnet-4-6`

`1`	`model: gemini/gemini-3.1-pro-preview`

API key は .env に入れます。

`1`	`LLM_API_KEY=your_llm_api_key`

PageIndex Cloud を有効にする場合は、さらに追加します。

`1`	`PAGEINDEX_API_KEY=your_pageindex_api_key`

よく使うコマンド

OpenKB のコマンドは開発者にとって扱いやすいです。

openkb init：新しいナレッジベースを初期化する。
openkb add <file_or_dir>：ファイルまたはディレクトリを追加する。
openkb remove <doc>：ドキュメントを削除し、関連する wiki ページ、画像、レジストリ、PageIndex 状態を整理する。
openkb query "question"：ナレッジベースに対して単発の質問を行う。
openkb chat：複数ターンの対話に入る。
openkb watch：raw/ を監視し、自動更新する。
openkb lint：構造と知識の健全性を確認する。
openkb list：索引済みドキュメントと概念を一覧する。
openkb status：ナレッジベースの統計を表示する。

openkb chat は、連続した探索には openkb query より向いています。セッションの再開、一覧、削除に対応し、チャット内では /status、/list、/add <path>、/save、/lint のような slash commands も使えます。

Markdown wiki が重要な理由

多くのナレッジベースツールで厄介なのは移行コストです。

資料が専用データベース、専用インデックス、専用フォーマットに入ると、直接確認、編集、バックアップ、移行するのが難しくなります。OpenKB は結果を通常の Markdown として書き出すため、既存ツールと自然に組み合わせられます。

最も直接的な使い方は、Obsidian で wiki/ を開くことです。

要約ページをそのまま読める。
概念ページを [[wikilinks]] で相互接続できる。
グラフビューで知識間の関係を確認できる。
問い合わせ結果を explorations/ に保存できる。
AGENTS.md でナレッジベースの維持方法を定義できる。

これにより OpenKB は単なる Q&A ツールではなく、個人やチームの知識整理パイプラインにもなります。

向いている場面

OpenKB は特に次の場面に向いています。

論文や技術レポートの読解。
プロジェクト文書の整理。
製品調査資料庫。
オープンソースプロジェクト周辺の文書ナレッジベース。
社内規程、会議メモ、説明資料の整理。
個人 Obsidian ナレッジベースの自動メンテナンス。
長い PDF、PPT、Word、Web 資料の構造化。

大量のドキュメントに向き合うとき、単に「一問一答」したいだけでなく、資料を徐々に閲覧可能、再利用可能、追跡可能な知識庫にしたいなら、OpenKB の方向性は合っています。

使うときの注意点

第一に、OpenKB は LLM の品質に依存します。

要約、概念ページ、相互リンクはモデルによって生成されます。モデルが強いほど知識コンパイルの品質は安定します。モデル能力が不足していると、概念抽出、矛盾検出、ドキュメント横断の統合は弱くなります。

第二に、コストは先に見積もるべきです。

大量の長文ドキュメントを一度に投入すると、LLM 呼び出しコストは低くありません。まず小規模な資料セットで試し、出力構造と品質を確認してから範囲を広げるのがよいです。

第三に、生成された wiki には人間の確認が必要です。

OpenKB は資料を整理できますが、事実の完全な正確性を自動保証するものではありません。重要な知識庫では、要約、概念ページ、引用関係を人間が確認する必要があります。

第四に、機密資料には慎重に扱う必要があります。

クラウド LLM や PageIndex Cloud を使う場合、文書内のプライバシー、営業秘密、コンプライアンス要件に注意してください。社内資料では、モデルプロバイダー、データ保持方針、アクセス境界を先に確認するのが安全です。

第五に、現時点では CLI ツール寄りです。

ロードマップでは Web UI、データベースストレージ、大規模コレクション対応、階層型概念インデックスが挙げられています。ただし現在の段階では、チームメンバーがコマンドラインに慣れていない場合、導入のハードルはまだあります。

Obsidian、NotebookLM、企業 RAG との関係

OpenKB と Obsidian の関係は、「自動整理レイヤー」と「閲覧・編集レイヤー」と考えると分かりやすいです。

Obsidian は人間が書き、直し、閲覧し、リンクを作るのに向いています。OpenKB は原始ドキュメントを Obsidian に入れられる wiki へまとめるのに向いています。

OpenKB と NotebookLM の違いは、「ローカルで制御しやすいこと」と「開かれたファイル形式」にあります。

NotebookLM は資料を入れてすぐ質問や要約を行う体験に優れています。OpenKB は、整理結果をローカルディレクトリに残し、Markdown として継続的に管理したい開発者に向いています。

OpenKB と企業 RAG の関係は、置き換えではなく補完です。

企業 RAG は権限、監査、サービス化、アクセス分離、監視、安定したスループットを重視します。OpenKB は、読みやすく編集しやすく長期的に蓄積できる知識レイヤーを作るのに向いています。将来的にオンライン Q&A を作る場合でも、OpenKB が生成した wiki は高品質なコーパスとして使えます。

まとめ

OpenKB の価値は、LLM ナレッジベースを「問い合わせ時に一時的にコンテキストを組む」段階から一歩前に進めることです。まず資料を wiki として整理し、その wiki 上で質問、チャット、検査、継続的なメンテナンスを行います。

この方向性はすべての Q&A システムに合うわけではありませんが、長期的な蓄積が必要な知識作業には向いています。Markdown ファイル、Obsidian 互換、PageIndex による長文処理、複数モデル対応、CLI ワークフローを組み合わせると、開発者や調査型ユーザーにとって実用的なナレッジベースツールになります。

大量の PDF、レポート、Web ページ、論文、プロジェクト文書を持っているなら、OpenKB は試す価値があります。成熟した企業ナレッジベースをすぐ置き換えるものではないかもしれませんが、資料整理の入口としては実用的です。まずドキュメントを読める、リンクできる、追跡できる知識に変え、その上で LLM を働かせることができます。

参考リンク：

RAGFlowプロジェクト整理：オープンソースRAGエンジンの機能と使い方

Wed, 15 Apr 2026 22:09:25 +0800

RAGFlow は infiniflow によるオープンソースの RAG（Retrieval-Augmented Generation）エンジンです。単なる「ドキュメントをアップロードして質問する」ための薄いナレッジベース外殻ではなく、ドキュメント解析、チャンク分割、検索、リランキング、引用の追跡、モデル設定、Agent 機能、API 統合までを一つのワークフローにまとめることを目指しています。

企業向けナレッジベース、ドキュメント Q&A、サポートアシスタント、社内情報検索、あるいは LLM により信頼できるコンテキスト層を持たせたい場合、RAGFlow は重点的に見る価値のあるオープンソース案の一つです。

01 RAGFlow は何を解決するのか

一般的な RAG システムがぶつかりやすい問題は主に三つあります。

ドキュメント解析の品質が安定しない。特に PDF、スキャン文書、表、画像、複雑なレイアウトで起きやすい。
チャンク分割戦略が見えにくく、検索ヒットはしていても実際の文脈が不完全になりやすい。
回答に信頼できる引用がなく、利用者が出典を確認しにくい。

RAGFlow はまさにこの部分に力を入れています。README では Deep document understanding、テンプレート化されたチャンク分割、チャンクの可視化、引用のグラウンディング、多経路検索とリランキングが強調されています。つまり、単にベクトルデータベースとチャット UI をつなぐのではなく、「高品質な入力が高品質な回答につながる」ことを重視しているということです。

02 主な機能

1. 高度なドキュメント理解

RAGFlow は複雑な非構造化データから知識を抽出できます。README に挙げられている形式には Word、PPT、Excel、TXT、画像、スキャン文書、構造化データ、Web ページなどがあります。

これは企業ナレッジベースにとって非常に重要です。現実の資料はきれいな Markdown ではなく、契約書、レポート、表、スキャン PDF、製品マニュアル、スクリーンショット、Web ページが混在していることが多いからです。解析品質が低いと、その後のベクトル検索も LLM の回答も弱くなります。

2. テンプレート化されたチャンク分割

RAGFlow はテンプレートベースの chunking を提供します。ここでの価値は、チャンク分割がブラックボックスではなく、文書タイプに応じてより適切な戦略を選べることです。

たとえば通常の記事、論文、表、Q&A 文書、画像説明、契約条項では、チャンクの粒度や境界の考え方が異なります。テンプレート化された分割により、「文が途中で切れる」「表の文脈が失われる」「見出しと本文が分かれてしまう」といった問題を減らせます。

3. 追跡可能な引用

RAGFlow は grounded citations を重視しています。つまり、回答がどのソース断片に基づくのかを追えるということです。さらにチャンクの可視化もあり、解析結果やチャンク分割結果を人が確認して調整しやすくなっています。

これは本番環境では特に重要です。企業内 Q&A は、ただ「それっぽい答え」を返せばよいわけではなく、検証可能である必要があります。ポリシー、コンプライアンス、財務、技術文書、サポート情報のような分野では、引用と追跡性はほぼ必須です。

4. 自動化された RAG ワークフロー

RAGFlow は RAG の一連の流れを、より完成度の高いワークフローとしてまとめています。

ナレッジベースの作成
データのアップロードまたは同期
ドキュメント解析
チャンクの確認と調整
LLM と embedding モデルの設定
多経路検索とリランキングの実行
チャットアシスタントの構築
API 経由で業務システムへ統合

このため、単なるライブラリというより RAG プラットフォームに近い存在です。チームにとっては UI と API の両方が有用で、非エンジニアはナレッジベースを保守しやすく、エンジニアは既存システムへ組み込みやすくなります。

5. Agent、MCP、ワークフロー拡張

最近の RAGFlow には Agentic workflow、MCP、Agent Memory、コード実行コンポーネントなども含まれています。これは、従来型のナレッジベース Q&A にとどまらず、Agent シナリオにも広がっていることを示しています。

典型的には、Agent が信頼できる企業知識レイヤーとして RAGFlow を使い、必要なときにナレッジベースから検索し、引用付きで回答を生成し、必要に応じてツール呼び出しやワークフローと組み合わせる、という形です。

03 基本的な利用フロー

公式のクイックスタートに沿うと、RAGFlow の一般的な使い方は次のようにまとめられます。

1. 実行環境を準備する

README にある基本要件は以下の通りです。

CPU >= 4 cores
RAM >= 16 GB
Disk >= 50 GB
Docker >= 24.0.0
Docker Compose >= v2.26.1

コード実行用のサンドボックスを使う場合は gVisor も必要です。また、公式 Docker イメージは主に x86 向けです。ARM64 を使う場合は、公式ドキュメントに従って自分でイメージをビルドする必要があります。

2. プロジェクトを取得する

1
2

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker

3. `vm.max_map_count` を確認する

RAGFlow のデプロイは Elasticsearch / OpenSearch のようなコンポーネントに依存するため、Linux では通常次を確認します。

`1`	`sysctl vm.max_map_count`

値が 262144 未満なら、一時的に次で設定できます。

`1`	`sudo sysctl -w vm.max_map_count=262144`

再起動後も維持したい場合は /etc/sysctl.conf に追加します。

4. Docker Compose で起動する

CPU モードはそのまま起動できます。

`1`	`docker compose -f docker-compose.yml up -d`

DeepDoc を GPU で高速化したい場合、README では .env に DEVICE=gpu を追加してから起動する方法が示されています。

1
2

sed -i '1i DEVICE=gpu' .env
docker compose -f docker-compose.yml up -d

起動後はログを確認します。

`1`	`docker logs -f docker-ragflow-cpu-1`

サービスが立ち上がったら、ブラウザでサーバーのアドレスを開きます。デフォルト構成では通常次のようになります。

`1`	`http://IP_OF_YOUR_MACHINE`

5. モデル API Key を設定する

RAGFlow では LLM と embedding モデルの設定が必要です。README では service_conf.yaml.template 内でデフォルトの LLM factory を選び、対応する API_KEY を更新する流れが説明されています。

実際には、使うプロバイダーに合わせて次を設定します。

チャットモデル
embedding モデル
rerank モデル
PDF / DOCX 内の画像も理解したい場合はマルチモーダルモデル

6. ナレッジベースを作成して文書を取り込む

サービス起動後の典型的な流れは次の通りです。

Web UI にログインする。
dataset / knowledge base を作成する。
文書をアップロードするか、データソース同期を設定する。
解析完了を待つ。
チャンク結果を確認し、必要なら調整する。
チャットアシスタントを作成し、知識ベースを関連付ける。
回答品質と引用元を確認する。

業務システムに組み込みたい場合は、RAGFlow の API や SDK を使って、検索とチャット機能を自分のアプリに接続できます。

04 向いている場面

RAGFlow は次のような用途に向いています。

企業内ナレッジベース Q&A
製品マニュアル、技術文書、FAQ の検索
カスタマーサポートや営業支援アシスタント
契約書、レポート、規程文書に対する追跡可能な Q&A
複数形式の資料を一元的に扱いたい場合
UI による運用と API 統合の両方が必要なチーム
Agent のコンテキスト層として RAG を使いたいシステム

特に、文書形式が複雑で、引用が重要で、人が解析結果を確認・調整したい場合に向いています。

05 使うときの注意点

第一に、RAGFlow は軽量スクリプトではありません。ある程度のインフラ要件があります。公式の推奨は最低 4 コア CPU、16GB RAM、50GB ディスクです。少量の Markdown に対して Q&A をしたいだけなら、ここまで大きなプラットフォームは不要かもしれません。

第二に、文書品質は依然として重要です。RAGFlow は解析やチャンク分割を改善できますが、質の低い資料、古い資料、矛盾する資料を自動で信頼できるものに変えることはできません。本番導入前にはナレッジベースの運用設計が必要です。

第三に、モデル設定は結果に直結します。embedding、rerank、チャットモデル、マルチモーダルモデルの選択は、検索品質と回答品質の両方に影響します。RAGFlow はワークフローを提供しますが、最終的な品質はデータ、モデル、パラメータ調整の組み合わせで決まります。

第四に、本番環境では権限とデータセキュリティに注意が必要です。企業ナレッジベースには社内文書が含まれることが多いため、デプロイ方式、アクセス制御、ログ、API Key、モデル提供者側のデータポリシーまで事前に設計するべきです。

06 短い判断

RAGFlow の強みは、RAG で最も面倒な部分をプラットフォーム機能としてまとめていることです。複雑な文書解析、説明可能なチャンク分割、引用のグラウンディング、多経路検索、リランキング、モデル設定、Web UI、API、Agent 拡張までを一式で備えています。

検証可能で保守しやすく、業務システムにも接続できる企業ナレッジベースを作りたいなら、RAGFlow は「ベクトルデータベース + 簡単なチャット UI」より完成度の高い選択肢です。逆に、個人用途の小規模な Q&A や、扱うデータ形式が非常に単純な場合は、より軽量な RAG フレームワークのほうが扱いやすいかもしれません。

ナレッジベース on KnightLiブログ

OpenKB：ドキュメントを継続更新される LLM ナレッジベースへコンパイルする

先に結論

OpenKB とは

従来型 RAG との違い

PageIndex が解決する問題

インストールとクイックスタート

LLM 設定

よく使うコマンド

Markdown wiki が重要な理由

向いている場面

使うときの注意点

Obsidian、NotebookLM、企業 RAG との関係

おすすめのワークフロー

まとめ

RAGFlowプロジェクト整理：オープンソースRAGエンジンの機能と使い方

01 RAGFlow は何を解決するのか

02 主な機能

1. 高度なドキュメント理解

2. テンプレート化されたチャンク分割

3. 追跡可能な引用

4. 自動化された RAG ワークフロー

5. Agent、MCP、ワークフロー拡張

03 基本的な利用フロー

1. 実行環境を準備する

2. プロジェクトを取得する

3. `vm.max_map_count` を確認する

4. Docker Compose で起動する

5. モデル API Key を設定する

6. ナレッジベースを作成して文書を取り込む

04 向いている場面

05 使うときの注意点

06 短い判断

関連リンク

ナレッジベース on KnightLiブログ

OpenKB：ドキュメントを継続更新される LLM ナレッジベースへコンパイルする

先に結論

OpenKB とは

従来型 RAG との違い

PageIndex が解決する問題

インストールとクイックスタート

LLM 設定

よく使うコマンド

Markdown wiki が重要な理由

向いている場面

使うときの注意点

Obsidian、NotebookLM、企業 RAG との関係

おすすめのワークフロー

まとめ

RAGFlowプロジェクト整理：オープンソースRAGエンジンの機能と使い方

01 RAGFlow は何を解決するのか

02 主な機能

1. 高度なドキュメント理解

2. テンプレート化されたチャンク分割

3. 追跡可能な引用

4. 自動化された RAG ワークフロー

5. Agent、MCP、ワークフロー拡張

03 基本的な利用フロー

1. 実行環境を準備する

2. プロジェクトを取得する

3. vm.max_map_count を確認する

4. Docker Compose で起動する

5. モデル API Key を設定する

6. ナレッジベースを作成して文書を取り込む

04 向いている場面

05 使うときの注意点

06 短い判断

関連リンク

3. `vm.max_map_count` を確認する