RAG on KnightLiブログ

PageIndexとは？ベクトルDBを使わない推論型RAG文書インデックスを解説

Wed, 20 May 2026 23:51:37 +0800

VectifyAI/PageIndex は興味深いRAGプロジェクトです。「また別のベクトルDBを作る」ことから始めるのではなく、長文書をまず目次のようなツリー構造に整理し、そのツリーに沿ってLLMに推論型検索を行わせます。

この記事の整理時点で、GitHubページでは約31.8k stars、2.7k forksが表示されており、ライセンスはMITです。READMEでの位置づけは Vectorless, Reasoning-based RAG、つまりベクトルDBを使わない、推論ベースのRAGです。

何を解決しようとしているのか

従来のRAGでよくある流れは、文書をチャンク化し、ベクトル化し、ベクトルDBに格納し、類似度検索で断片を取得するというものです。この方法はシンプルで汎用的、かつ成熟していますが、長い専門文書ではいくつかの問題が起きやすくなります。

類似度は本当の関連性と同じではない。
チャンク化によって文書構造が分断され、章や節の関係が失われる。
検索結果の説明性が弱く、なぜその箇所がヒットしたのか説明しにくい。
財務報告、規制文書、法律文書、技術マニュアルのような資料では、章をまたいだ推論が必要になることが多い。

PageIndexの考え方は逆です。まず文書を意味的なツリーとして構成し、モデルが人間のように目次を読み、章を開き、階層的に関連内容を探します。

PageIndexの基本ワークフロー

READMEでは、PageIndexの検索は二つのステップに分けられています。

文書に対して Table-of-Contents のようなツリー構造インデックスを生成する。
ツリー検索によって reasoning-based retrieval を行う。

このツリーは単なるファイルディレクトリではなく、LLMが使うための文書構造です。ノードにはタイトル、ページ範囲、要約、子ノードなどの情報が含まれます。これにより、モデルは質問に答えるときに大量のバラバラなchunkへいきなり向き合う必要がありません。まずどの章に入るべきか判断し、その後さらに下へ検索できます。

この方式は、構造が明確で内容が長い文書に向いています。たとえば次のような文書です。

財務報告やSEC filings。
規制資料やコンプライアンス文書。
学術教材や論文。
法律文書。
技術マニュアルや製品ドキュメント。
モデルのコンテキストウィンドウを超える大型PDF。

従来のベクトルRAGとの違い

PageIndexの主な特徴は五つにまとめられます。

第一に、Vector DBを必要としません。ベクトル類似度検索だけに頼るのではなく、文書構造とLLMの推論によって内容を特定します。

第二に、従来型のchunkingを行いません。文書は固定長の断片ではなく、自然な章や節に沿って整理されます。

第三に、説明性が高くなります。検索経路をページ、章、ツリーノードに対応させられるため、「ベクトル類似度でこの段落に当たった」より追跡しやすくなります。

第四に、検索はコンテキスト認識型です。質問、会話履歴、ドメイン背景がツリー検索の経路に影響します。

第五に、人間の専門家が文書を読む方法に近いことです。人は普通、文書全体を小さく切って類似度を計算するのではなく、まず目次を見て、章を特定し、最後に詳細を読みます。

これはベクトルDBに価値がないという意味ではありません。より正確には、PageIndexは「意味的な類似だけでは足りず、構造と推論が必要になる」長文書検索に向いた方式です。

ローカルでの実行方法

READMEにはローカルでのセルフホスト方法が示されています。まず依存関係をインストールします。

`1`	`pip3 install --upgrade -r requirements.txt`

次に、プロジェクトのルートディレクトリに .env を作成し、LLM API keyを書き込みます。プロジェクトは LiteLLM によって複数モデルをサポートします。

`1`	`OPENAI_API_KEY=your_openai_key_here`

PDFからPageIndex構造を生成します。

`1`	`python3 run_pageindex.py --pdf_path /path/to/your/document.pdf`

Markdownも処理できます。

`1`	`python3 run_pageindex.py --md_path /path/to/your/document.md`

主なオプション引数は次の通りです。

--model
--toc-check-pages
--max-pages-per-node
--max-tokens-per-node
--if-add-node-id
--if-add-node-summary
--if-add-doc-description

READMEでは、ローカルのオープンソース版は標準的なPDF解析を使うとも説明されています。複雑なPDFでは、プロジェクト側のクラウドサービスが拡張OCR、ツリー構築、検索パイプラインを提供します。

Agentic Vectorless RAGの例

このプロジェクトには、セルフホストしたPageIndexとOpenAI Agents SDKを使う agentic vectorless RAG の例もあります。オプション依存関係を入れて実行します。

1
2

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

この例の価値は、PageIndexを「文書ツリーを生成する」段階から「Agentが文書ツリーを使って検索する」段階へ進めていることです。企業ナレッジベース、財務報告Q&A、規制文書Q&A、技術文書Agentを作っているなら、READMEだけを読むより、この例を一度動かす価値があります。

クラウドサービス、MCP、API

PageIndexは単なるGitHub repoではありません。プロジェクトページにはいくつかの入口も示されています。

セルフホスト：オープンソースコードをローカルで実行し、実験や制御された展開に向く。
Chat Platform：ChatGPT風の文書分析プラットフォーム。
MCP / API：既存のAgentや自動化フローへ組み込みやすい。
Enterprise：プライベートまたはオンプレミス展開向け。

これは単なるdemoではなく、「推論型文書検索」を統合可能な文書インテリジェンス基盤にしようとしていることを示しています。

向いている場面

PageIndexは次のようなタスクに向いています。

長いPDFのQ&A。
財務報告、年次報告、目論見書、規制文書の分析。
法律・コンプライアンス文書検索。
技術マニュアルQ&A。
複数章にまたがる教材や論文の検索。
説明可能な検索経路が必要な企業ナレッジベース。
Agentに構造化された文書コンテキストを提供すること。

資料が短い、構造がほとんどない、または普通のFAQに近い場合は、従来のembedding + vector DBで十分かもしれません。PageIndexの利点は、長文書、強い構造、専門領域、推論が必要な質問でより出やすくなります。

注意点

第一に、PageIndexは依然としてLLMに依存します。ツリー構築、要約、検索品質は、モデル能力、プロンプト、文書解析品質の影響を受けます。

第二に、ローカル版は標準的なPDF解析を使います。複雑なスキャン文書、図表が多いPDF、レイアウトが乱れた資料では、OCRやより強い前処理が必要になる場合があります。

第三に、ベクトルDBなしはゼロコストを意味しません。ツリー構築自体もモデル呼び出しと時間を消費します。大規模文書コレクションでは特にそうです。

第四に、PageIndexは文書構造インデックスと推論検索のフレームワークに近く、すべてのRAG技術スタックを直接置き換えるものではありません。実際の本番環境では、ベクトル検索、キーワード検索、権限制御、キャッシュ、監査システムと組み合わせて使うこともあります。

まとめ

PageIndexの面白さは、RAGの重点を「テキスト類似度による取得」から「文書構造 + LLM推論」へ移していることです。長文書や専門文書では、この方向は注目に値します。

企業文書Q&A、財務報告分析、規制文書検索、技術マニュアルAgentを作っているなら、PageIndexは新しいRAGアーキテクチャの参考になります。最初からすべてを細かく切ってベクトルDBに入れるのではなく、まず文書に構造を与え、その構造に沿ってモデルに推論させるという考え方です。

参考：

GitHub：VectifyAI/PageIndex

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 を働かせることができます。

参考リンク：

コンピューター用語を平易に言うと：TTS、STT、API、RAG、Agent は何を指すのか

Tue, 12 May 2026 22:15:34 +0800

コンピューター分野には、初めて聞くと難しそうに感じる用語がたくさんあります。しかし平易な言葉に置き換えると、日常のとても単純な動作を指していることが多いです。

たとえば AI が話せることは TTS、AI が人の話を聞けることは STT と呼ばれます。複雑なシステムに見えますが、分解すると「文字を読み上げる」と「音声を書き起こす」です。

参考リンク：https://www.zhihu.com/question/267978646/answer/2035405228460201515

この記事では、その視点からよくある用語をつなげて説明します。用語自体は残しつつ、意味を平易に言い換えます。

TTS と STT：文字と音声の相互変換

TTS は Text-to-Speech、つまりテキストを音声に変換することです。文字を入力すると、システムがそれを音として再生できる形にします。ナビの音声案内、電子書籍の読み上げ、AI カスタマーサポートの音声、音声アシスタントなどで使われます。

STT は Speech-to-Text、つまり音声をテキストに変換することです。スマートフォンに話しかけると、まず音声が文字に変換され、その後のプログラムに渡されます。音声入力、会議の文字起こし、自動字幕、スマートスピーカーには欠かせません。

多くの音声 AI 製品は、実際には次の流れです。

STT：あなたの発話を文字に変換する。
LLM：その文字から回答を生成する。
TTS：回答を音声として読み上げる。

自然に会話しているように見えても、内部では複数のモジュールが順番に処理しています。

OCR：画像から文字を写し取る

OCR は Optical Character Recognition、日本語では光学文字認識です。

平易に言えば、画像の中の文字を抜き出すことです。請求書を撮影する、本のページをスキャンする、身分証の名前や番号を読む、といった処理はすべて OCR です。

昔の OCR は「文字の形から推測する」ものに近かったですが、現在は深層学習を組み合わせ、複雑な背景、傾いた文字、手書き文字、低解像度画像にも強くなっています。それでも本質的な問いはシンプルです。画像の中にどんな文字があるのか、です。

NLP と LLM：機械に人間の言葉を扱わせる

NLP は Natural Language Processing、自然言語処理です。分かち書き、翻訳、要約、感情分析、質問応答、分類など、人間の言葉を扱います。

LLM は Large Language Model、大規模言語モデルです。テキストを理解し生成できるため、現在では多くの NLP タスクが LLM によって処理されています。

平易に言うと：

NLP：人が話したり書いたりする言葉を機械に処理させる。
LLM：多くの言語タスクを受け止められる大きなテキストモデル。

AI に記事を要約させる、メールを書かせる、タイトルを直させる、コードを説明させる、といったことはすべてこの方向に含まれます。

API と SDK：一方は窓口、一方は道具箱

API は Application Programming Interface です。

平易に言えば、相手が機能を呼び出すための入口を用意してくれている、ということです。天気 API は都市を渡すと天気を返し、決済 API は注文情報を渡すと決済結果を返します。

SDK は Software Development Kit です。

平易に言えば、API を呼び出しやすくするために、公式がよく使うコード、型、サンプル、ツールをまとめたものです。API がレストランの窓口なら、SDK は注文アプリのようなものです。窓口に直接伝えることもできますし、アプリを使えばより楽に注文できます。

CRUD：作成、読み取り、更新、削除

CRUD は Create、Read、Update、Delete の略です。

平易に言えば、追加、表示、編集、削除です。

多くの管理画面、業務システム、データベース操作は CRUD を中心に回っています。ユーザー管理、記事管理、注文管理、在庫管理は業務としては違って見えますが、内部ではフォームと CRUD の組み合わせであることがよくあります。

プログラマーが「また CRUD を書いた」と言うのは、それが本当に頻出するからです。

Cache：よく使うものを手元に置く

Cache はキャッシュです。

平易に言えば、よく使うものを手元に置いておき、次回は探し直したり計算し直したり問い合わせ直したりしない、ということです。

Web ページでは画像やスクリプトをキャッシュできます。遅いデータベースクエリでは人気の結果を Redis に置けます。モデル推論が高価な場合は、同じ質問への回答をキャッシュできます。

キャッシュの難しさは「コピーを置くこと」ではなく、「いつ更新するか」です。データが変わってもキャッシュが変わらなければ、古い情報が表示されます。多くのキャッシュ問題はそこから生まれます。

Queue：タスクを並べて順番に処理する

Queue はキューです。

平易に言えば、やることが多すぎるので、いったん並べて一つずつ処理することです。

たとえばユーザーが動画をアップロードしても、変換がすぐ終わるとは限りません。システムはタスクをキューに入れ、バックグラウンドサービスで後から処理できます。SMS 送信、メール送信、レポート生成、注文コールバック処理にもよく使われます。

キューが解決するのは、すべての重い処理を現在のリクエスト内で待たせないことです。ユーザーには先に応答し、時間のかかる処理は後ろで行います。

Index：データベースに目次を作る

Index はインデックスです。

データベースのインデックスは、本の目次のようなものです。目次がなければ最初のページから最後まで探す必要がありますが、目次があれば目的の場所に早くたどり着けます。

ただしインデックスは多ければよいわけではありません。検索は速くなりますが、書き込みや更新は遅くなることがあります。データが変わるとインデックスもメンテナンスする必要があるからです。

そのためデータベース最適化では「遅いクエリはまずインデックスを見る」と言われます。ただし実際に作るときは、検索条件、ソート項目、データ量、書き込み頻度も見る必要があります。

RPC、REST、Webhook：システム同士の話し方

RPC は Remote Procedure Call、リモート手続き呼び出しです。

平易に言えば、ローカル関数を呼ぶように、別のマシン上の関数を呼ぶことです。

REST は Web API でよく使われます。URL と HTTP メソッドでリソース操作を表します。たとえば GET /users はユーザー取得、POST /orders は注文作成です。

Webhook は逆方向の通知です。こちらが「終わった？」と何度も聞くのではなく、相手が処理完了後にこちらの URL へ通知します。

簡単に覚えるなら：

RPC：遠隔の関数を呼ぶ。
REST：HTTP でリソースを管理する。
Webhook：出来事が起きたら相手から知らせてもらう。

CDN と Load Balancing：近くに置く、負荷を分ける

CDN は Content Delivery Network、コンテンツ配信ネットワークです。

平易に言えば、静的リソースをユーザーに近いノードへ置くことです。画像、動画、CSS、JS にアクセスするとき、毎回オリジンサーバーまで行く必要がなくなります。

Load Balancing は負荷分散です。

平易に言えば、アクセスが多すぎるときに一台のサーバーだけに背負わせず、複数のマシンへリクエストを分けることです。

一方は「ユーザーに近づける」、もう一方は「一台を疲れさせない」ための仕組みです。大規模サイトでは通常どちらも使われます。

Docker、Container、Kubernetes：パッケージ化、実行、配置

Docker は代表的なコンテナツールで、Container はコンテナです。

平易に言えば、プログラムと依存環境をまとめてパッケージ化し、別のマシンでもできるだけ同じように動かす仕組みです。「自分の PC では動くのにサーバーでは動かない」問題を減らします。

Kubernetes はよく K8s と書かれる、コンテナオーケストレーションシステムです。

平易に言えば、コンテナがたくさんあるときに、どこで動かすか、落ちたらどう再起動するか、トラフィックをどう分けるか、バージョンをどう更新するかを管理します。

小さなサービスが一つだけなら Docker で十分なこともあります。多くのサービス、マシン、レプリカがある場合に K8s の価値が出ます。

CI/CD：自動ビルド、自動リリース

CI は Continuous Integration、継続的インテグレーションです。

平易に言えば、コードがコミットされると、システムが自動でコードを取得し、テストし、ビルドして、早めに問題を見つけることです。

CD は Continuous Delivery または Continuous Deployment を指します。

平易に言えば、ビルドが通った後、コードをより安定して自動的にテスト環境や本番環境へ届けることです。

これは「コードを書く」問題ではなく、「書いた後にどう少ないミスでリリースするか」の問題を解決します。

Serialization：オブジェクトを送れる形式に詰める

Serialization はシリアライズです。

平易に言えば、プログラム内のオブジェクトを保存・送信できる形式に変えることです。JSON、XML、Protobuf などが例です。

逆に Deserialization は、それらの形式をプログラムで使えるオブジェクトに戻すことです。

フロントエンドとバックエンドが JSON をやり取りするとき、サービス同士が Protobuf を使うとき、どちらもシリアライズが関わっています。

Token、Embedding、Vector DB：文字をモデルが扱える形にする

大規模モデルにおける Token は、テキストを分割した基本単位を指します。必ずしも漢字一文字や英単語一つではなく、モデル内部でテキストを処理する粒度のようなものです。

Embedding は埋め込みベクトルです。

平易に言えば、文字、画像、その他の内容を数字の列に変換し、モデルが類似度を比較できるようにすることです。

Vector DB はベクトルデータベースです。

平易に言えば、それらのベクトルを保存し、「意味が近い」内容を素早く探せるデータベースです。

たとえば「ルーターをリセットする方法」と聞くと、システムはベクトルデータベースから「工場出荷状態に戻す」「Wi-Fi パスワードを忘れた」「管理画面にログインできない」といった近い内容を探し、モデルに参考資料として渡します。

RAG：先に資料を調べてから答える

RAG は Retrieval-Augmented Generation、検索拡張生成です。

平易に言えば、モデルが答える前に、まず資料庫から関連内容を探し、その資料を持って回答することです。

これは大規模モデルが記憶だけで適当に答えてしまう問題を和らげます。企業文書、ナレッジベース、製品マニュアル、コード片をつなぐことで、モデルは学習時の記憶だけでなく、あなたが与えた最新資料を参照できます。

典型的な流れは：

ユーザーが質問する。
システムが質問を Embedding に変換する。
Vector DB から関連文書を探す。
文書片と質問を一緒に LLM へ渡す。
モデルが回答を生成する。

つまり RAG は難しそうに聞こえますが、本質は「先に資料を調べてから、言葉を組み立てる」です。

Agent：タスクを分解できる自動化フロー

AI 文脈での Agent は、しばしばエージェントや智能体と呼ばれます。

平易に言えば、単に一文を返すだけでなく、目標をステップに分け、ツールを呼び出し、結果を観察し、次の行動を決められるものです。

たとえば「このリポジトリのテストが失敗する理由を分析して」と頼むと、通常のチャットモデルは助言だけを返すかもしれません。Agent なら、ファイルを読み、テストを実行し、エラーを確認し、コードを修正し、再度テストを走らせる可能性があります。

もちろん Agent は必ず信頼できるという意味ではありません。実態は「モデル + ツール呼び出し + 状態ループ」です。使いやすさは、ツール権限、タスク境界、エラー処理、人間の確認設計に左右されます。

まとめ

多くのコンピューター用語が難しそうに見えるのは、英語の略語、アーキテクチャ図、製品文言に包まれているからです。分解すると、多くは素朴な動作を表しています。

TTS：文字を読み上げる。
STT：音声を書き起こす。
OCR：画像から文字を写す。
API：呼び出し口を公開する。
SDK：呼び出し用の道具をまとめる。
CRUD：作成、読み取り、更新、削除。
Cache：よく使う結果を保存する。
Queue：タスクを並べて後で処理する。
Index：データに目次を作る。
CDN：コンテンツをユーザーに近づける。
Load Balancing：リクエストを分散する。
Docker：実行環境をパッケージ化する。
CI/CD：テストとリリースを自動化する。
Embedding：内容を数値ベクトルにする。
RAG：先に資料を調べてから答える。
Agent：モデルにツールを使わせて段階的に作業させる。

用語は検索、コミュニケーション、ドキュメント参照に便利なので残すべきです。ただし理解するときに怖がる必要はありません。まず平易な言葉に訳し、それから技術的な細部へ戻ると、多くの概念はずっと分かりやすくなります。

参考

Zhihu 回答：https://www.zhihu.com/question/267978646/answer/2035405228460201515

Gemini Embedding 2：テキスト、画像、動画、音声を同じベクトル空間に入れる

Mon, 04 May 2026 06:01:10 +0800

Google Developers Blog が Gemini Embedding 2 の開発方法を紹介した。このモデルは Gemini API と Gemini Enterprise Agent Platform を通じて GA になっている。重要なのは、単なる新しい embedding モデルではなく、テキスト、画像、動画、音声、ドキュメントを同じ意味空間にマッピングできる点だ。

これにより、検索システムが扱える範囲は広がる。従来の多くの RAG パイプラインでは、画像、動画、音声を先にテキストやメタデータへ変換し、それぞれ別にインデックスする必要があった。Gemini Embedding 2 はマルチモーダル入力を直接処理できるため、エージェント、検索、分類システムが実際の業務資料を扱いやすくなる。

原文リンク：Building with Gemini Embedding 2: Agentic multimodal RAG and beyond

モデルの機能

Gemini Embedding 2 は 100 以上の言語をサポートする。1 回のリクエストで処理できる内容は次の通り。

最大 8,192 text tokens
最大 6 枚の画像
最大 120 秒の動画
最大 180 秒の音声
最大 6 ページの PDF

中心にある考え方は「統一された意味空間」だ。開発者は異なるモダリティの内容を同じベクトル表現に入れ、同じ検索、クラスタリング、再ランキングのロジックで処理できる。

たとえば、テキスト説明と画像を同じ embedding リクエストに入れられる。

from google import genai
from google.genai import types

client = genai.Client()

with open('dog.png', 'rb') as f:
    image_bytes = f.read()
result = client.models.embed_content(
    model='gemini-embedding-2',
    contents=[
        "An image of a dog",
        types.Part.from_bytes(
            data=image_bytes,
            mime_type='image/png',
        ),
    ]
)

print(result.embeddings)

入力ごとに個別の embedding が必要で、集約された 1 つのベクトルでは困る場合は Batch API を使える。原文では、この種のバッチ対応について Agent Platform 側はまだ対応中だとも説明している。

RAG にとっての意味

マルチモーダル embedding はエージェント型 RAG に向いている。AI agent は、コードリポジトリ、PDF、スクリーンショット、図表、音声会議録、商品画像を同時に確認する必要があるかもしれない。すべての資料を同じ意味空間に入れられれば、形式ごとに別々の検索入口を作る必要がなくなる。

Google は、タスクの目的に応じて task prefix を使うことを勧めている。これにより、embedding が検索目的に合いやすくなる。たとえば、質問応答、ファクトチェック、コード検索、検索結果には異なる prefix を使える。

# Generate embedding for your task's query:
def prepare_query(query):
    return f"task: question answering | query: {content}"
    # return f"task: fact checking | query: {content}"
    # return f"task: code retrieval | query: {content}"
    # return f"task: search result | query: {content}"
# Generate embedding for document of an asymmetric retrieval task:
def prepare_document(content, title=None):
    if title is None:
        title = "none"
    return f"title: {title} | text: {content}"

この prefix は非対称検索に適している。ユーザーのクエリは短く、ドキュメントは長いことが多い。query と document をタスクに合わせて別々に整形すると、短い検索語と長い文書のマッチングを改善できる。

原文では 2 つの導入例が紹介されている。

Harvey は法律検索ベンチマークで、以前の embedding と比べて Recall@20 precision が 3% 向上した。
Supermemory は Recall@1 の検索精度が 40% 向上し、記憶、インデックス、検索、Q&A パイプラインに利用している。

これらの数字はすべての場面で同じ改善を保証するものではない。ただし、マルチモーダル embedding がデモだけでなく、実際の検索プロダクトで効果を出していることはわかる。

ビジュアル検索

Gemini Embedding 2 は、画像検索、画像とテキストを組み合わせた検索、商品識別にも使いやすい。原文では、URBN の衣料レンタル会社 Nuuly が、倉庫で撮影したタグ未付与の衣類写真をカタログと照合するために使っている例が紹介されている。この導入により、Match@20 は 60% から約 87% に向上し、全体の識別成功率は 74% から 90% 超に上がった。

この種の場面で重要なのは生成ではなく、「この画像はどの在庫、文書、商品レコードに最も近いか」を理解することだ。業務に大量の画像、動画クリップ、スキャン資料があるなら、マルチモーダル embedding はテキストだけのインデックスより自然に使える。

検索結果の再ランキング

Embedding は rerank にも使える。一般的には、まず基本検索で候補を取得し、その候補とユーザーのクエリとの類似度を計算して、より関連性の高い内容を上位に並べる。

# 1. Define a function to calculate the dot product (cosine similarity)
def dot_product(a: np.ndarray, b: np.ndarray):
  return (np.array(a) @ np.array(b).T)
# 2. Retrieve your embeddings
# (Assuming 'summaries' is your list of search results)
search_res = get_embeddings(summaries)
embedded_query = get_embeddings([query])

# 3. Calculate similarity scores
sim_value = dot_product(search_res, embedded_query)

# 4. Select the most relevant result
best_match_index = np.argmax(sim_value)

原文では別の考え方も紹介されている。まずモデルに内部知識から仮の基準回答を生成させ、その回答を embedding し、候補コンテンツとの類似度を比較して、意味的に最も近い結果を選ぶ方法だ。これは質問応答型 RAG で特に役立つ。

クラスタリング、分類、異常検知

検索以外にも、embedding はクラスタリング、分類、異常検知に使える。前述の質問応答検索とは異なり、これらは対称的なタスクなので、query と document に同じ task prefix を使える。

# Generate embedding for query & document of your task.
def prepare_query_and_document(content):
    # return f'task: clustering | query: {content}'
    # return f'task: sentence similarity | query: {content}'
    # return f'task: classification | query: {content}'

この種のタスクは、評判分析、コンテンツ審査、類似アセットの分類、異常サンプルの発見に使える。また、agent が大量のコンテキスト資料を先に整理してから、後続の推論に入る用途にも向いている。

保存とコスト

Gemini Embedding 2 はデフォルトで 3,072 次元のベクトルを出力する。Matryoshka Representation Learning を使っているため、output_dimensionality でより小さい次元に切り詰められる。Google は効率を優先する場合、1,536 または 768 次元を推奨している。

result = client.models.embed_content(
    model="gemini-embedding-2",
    contents="What is the meaning of life?",
    config={"output_dimensionality": 768}
)

ベクトルは Agent Platform Vector Search、Pinecone、Weaviate、Qdrant、ChromaDB などに保存できる。コスト面では、原文は Batch API がより高いスループットを提供し、デフォルト embedding 価格の 50% で利用できると説明している。

開発者はどう使うか

すでにテキスト RAG がある場合は、まず次の 2 種類の改善から始めるとよい。

PDF、スクリーンショット、画像説明、テキスト文書を同じインデックスに入れ、検索の再現率が安定するか確認する。
質問応答、ファクトチェック、コード検索、商品検索など、タスクごとに task prefix を付ける。すべての内容を同じ embedding 形式で処理しない。

新しいプロダクトを作るなら、次の方向を優先して検討できる。

企業ナレッジベース：文書、図表、プレゼン資料のスクリーンショット、会議資料をまとめて検索する。
ビジュアル検索：画像、テキスト、混合入力で商品、アセット、デザイン案、アーカイブを探す。
Agent ツールチェーン：coding agent、research agent、customer support agent が複数形式の業務資料を検索できるようにする。
コンテンツガバナンス：テキスト、画像、動画クリップを統一的に分類、クラスタリング、異常検知する。

Gemini Embedding 2 の価値は、マルチモーダル資料を同じ検索可能な資産に変えることにある。開発者にとっては、「先にテキストへ変換してから検索する」中間層を減らし、RAG システムを実世界のデータ形態に近づけられる。

代表的な埋め込みモデルはどう選ぶべきか: OpenAI・BGE・E5・GTE・Jina の比較

Thu, 23 Apr 2026 15:23:47 +0800

RAG、セマンティック検索、ナレッジベース検索を始めると、多くの人が最初に同じ疑問にぶつかります。埋め込みモデルはたくさんあるけれど、結局どれを選べばいいのか、ということです。

代表的なモデルは大きく二つに分けられます。一つは中国語・英語・多言語タスクを広くカバーする汎用テキスト埋め込みです。もう一つは中国語向けの用途により適していて、中国語検索、中国語 QA、中国語ナレッジベースでの性能を重視したものです。

まず短い結論だけ言うなら、次のように考えると分かりやすいです。

手間を減らして API をそのまま使いたいなら: text-embedding-3-small または text-embedding-3-large
中国語検索をやりたくて、かつオープンソースを自前で運用したいなら: bge-base-zh-v1.5、bge-m3、gte-large-zh
多言語にも対応したいなら: multilingual-e5-base、multilingual-e5-large、jina-embeddings-v3
中国語用途でコストを抑えたいなら: bge-small-zh-v1.5、gte-base-zh

1. まずは種類ごとに見る

1. OpenAI 系

text-embedding-3-small
text-embedding-3-large

この系統の特徴は、呼び出しが簡単で安定していることです。API を直接使って検索、RAG、分類、類似度マッチングを行うのに向いています。強みは「特定の中国語ベンチマークで飛び抜けて高得点」という点ではなく、全体としての使いやすさにあります。導入ハードルが低く、品質が安定していて、エンジニアリングコストも低いです。

チームとしてモデルを自前でホストしたくない、推論サービスの運用もしたくないなら、OpenAI 系はたいてい最も時間を節約しやすい選択です。

2. BGE 系

BAAI/bge-small-zh-v1.5
BAAI/bge-base-zh-v1.5
bge-m3

BGE は中国語検索で非常によく見かける系統です。bge-small-zh-v1.5 と bge-base-zh-v1.5 は中国語単一言語タスク寄りで、中国語セマンティック検索、ナレッジベース検索、FAQ マッチングに向いています。bge-m3 はより汎用的で、多言語、多粒度、より複雑な検索シナリオもカバーできます。

データの大半が中国語テキストなら、BGE は候補に入れやすいモデル群です。

3. E5 系

intfloat/multilingual-e5-base
multilingual-e5-large

E5 系の特徴は、多言語性能のバランスがよいことです。中国語と英語が混在する環境、クロスリンガル検索、国際向けコンテンツ基盤に向いています。中国語だけを見るモデルではなく、「異なる言語を一つの検索基盤にまとめる」ことを重視した設計です。

コーパスが中国語だけでなく、英語、日本語、あるいはさらに多くの言語を含むなら、中国語専用モデルより E5 の方が安定しやすいです。

4. GTE 系

Alibaba-NLP/gte-base-zh
gte-large-zh

GTE も中国語タスクでよく使われます。位置づけは BGE に近く、どちらも中国語検索の実用派です。比較的バランスが良く、導入のハードルも高くありません。中国語ナレッジベース、サイト内検索、社内ドキュメント検索に向いています。

中国語オープンソースモデルを複数比較したいなら、GTE は一緒に評価する価値があります。

5. Jina Embeddings

jina-embeddings-v3

Jina はより汎用的で、現代的な実装シナリオに寄った選択肢です。多言語検索、長文、Web コンテンツ処理などでよく使われます。「一つのモデルでより多くのタスク形態をカバーしたい」という文脈でよく名前が挙がり、embedding 層を統一したいチームに向いています。

Web ページ、文書、多言語テキストなど、データソースが混在しているなら、Jina は試す価値のある候補です。

2. 中国語シナリオでよく使われるモデル

対象を中国語シナリオに絞ると、代表的な候補はほぼ次の通りです。

bge-small-zh-v1.5
bge-base-zh-v1.5
bge-m3
gte-base-zh
gte-large-zh
multilingual-e5-base
multilingual-e5-large

ここで大事なのは、「どれが絶対に一番強いか」ではなく、次の三つです。

データの中心は中国語か
多言語対応が必要か
品質、コスト、導入しやすさのどれを優先するか

3. これらのモデルを並べて考える

1. 中国語性能だけを見る場合

中国語ナレッジベース、中国語 QA、中国語文書検索であれば、まず BGE と GTE を見るのが一般的です。

bge-small-zh-v1.5: 軽量で、コスト重視の場面に向く
bge-base-zh-v1.5: 中国語用途でバランスが良い定番
gte-base-zh: 軽量 BGE に近く、まずベースラインを作るのに向く
gte-large-zh: 検索品質をより重視する場面に向く
bge-m3: 中国語検索に加えて、より複雑な要件も視野に入れたいときに向く

コーパスがほぼ中国語だけなら、E5 も使えますが、最優先になることは多くありません。

2. 多言語が必要な場合

この場合は優先順位がかなり変わります。

multilingual-e5-base と multilingual-e5-large は多言語を統一的に検索するのに向いています
jina-embeddings-v3 も多言語と汎用テキスト処理に向いています
bge-m3 は従来の中国語専用モデルより、多言語へ拡張しやすいです
text-embedding-3-small と text-embedding-3-large は API ベースで素早く進めたい場合に向いています

中国語、英語、製品ドキュメント、Web コピー、ユーザー問い合わせが同じ基盤に入るなら、多言語モデルの方が後からの改修コストをかなり減らせます。

3. 推論コストと保存コストを抑えたい場合

ここでは軽量モデルが有利です。

bge-small-zh-v1.5
gte-base-zh
multilingual-e5-base
text-embedding-3-small

これらは次のようなケースに向いています。

文書量が多い
更新頻度が高い
大量のベクトル化が必要
レイテンシとコストに敏感

データ規模が大きい場合、embedding の次元数、推論速度、インデックスサイズは総コストに直結します。そのため、まず小さいモデルでベースラインを作るのは堅実なやり方です。

4. まず性能上限を優先したい場合

より大きいモデルは、複雑な検索や高品質な再現率を求める場面に向いています。たとえば次のようなモデルです。

text-embedding-3-large
multilingual-e5-large
gte-large-zh
bge-base-zh-v1.5
bge-m3

ただし、モデルが大きいほど本番体験が必ず良くなるわけではありません。多くのプロジェクトでは、本当のボトルネックはモデルそのものではなく、チャンク分割、取得件数、再ランキング、データクリーニング、評価方法にあります。

4. 各モデルはどんなタスクに向くか

モデル	向いている場面	ざっくりした判断
`text-embedding-3-small`	汎用検索、RAG、素早い導入	API 利用が簡単でコストにも優しい
`text-embedding-3-large`	品質重視の汎用検索	品質優先で実装負担も小さい
`bge-small-zh-v1.5`	中国語の軽量検索	中国語用途の定番入門モデル
`bge-base-zh-v1.5`	中国語ナレッジベース、FAQ、セマンティック検索	中国語シナリオでバランスが良い
`bge-m3`	中国語中心だが、より複雑な検索にも広げたい場合	拡張性が高い
`multilingual-e5-base`	多言語の基本検索	国際化プロジェクトでよく使われる
`multilingual-e5-large`	多言語で高品質な再現率が欲しい場合	より品質重視
`gte-base-zh`	中国語の軽量検索	まずベースラインを作るのに向く
`gte-large-zh`	中国語で品質重視の場面	BGE との比較対象として使いやすい
`jina-embeddings-v3`	多言語、Web、汎用テキストタスク	embedding 層を統一したいときに試す価値がある

5. 実際の選定をどう進めるか

論文を書くのではなく、実際にシステムを作るなら、選定手順はもっとシンプルで大丈夫です。

シナリオ 1: 中国語ナレッジベース

まずは次の組み合わせを試します。

bge-base-zh-v1.5
gte-large-zh
bge-small-zh-v1.5

予算が厳しいなら小さいモデルから始めて、検索品質をより重視するなら大きいモデルへ広げます。

シナリオ 2: 中国語と英語が混在するナレッジベース

まずは次を試します。

multilingual-e5-base
multilingual-e5-large
text-embedding-3-small
text-embedding-3-large

自前運用を避けたいなら OpenAI がより直接的です。自前でホストしたいなら、E5 の方が一般的です。

シナリオ 3: 今は中国語中心だが、将来的に多言語へ広げる可能性がある

まずは次を試します。

bge-m3
multilingual-e5-base
jina-embeddings-v3

このタイプの場面で一番怖いのは、最初は中国語だけを前提に設計し、後からベクトル基盤を丸ごと作り直すことです。

6. 最後に大事なのは「ランキング1位」ではない

埋め込みモデル選定で最も陥りやすい失敗は、公開ベンチマークの点数だけを見て、そのまま本番投入してしまうことです。

より確実なのは、だいたい次の手順です。

まず 2 から 4 個の候補モデルを選ぶ
自分たちの実データで embedding を作る
一度検索評価を回す
そのうえでコスト、遅延、導入方法を合わせて最終判断する

実際に結果を決めるのは、モデル名そのものよりも、そのモデルが自分のコーパス、チャンク戦略、クエリ形式に合っているかどうかだからです。

まとめ

実用的な結論だけ覚えるなら、次のように整理できます。

中国語優先: bge-base-zh-v1.5、gte-large-zh
コスト優先: bge-small-zh-v1.5、gte-base-zh、text-embedding-3-small
多言語優先: multilingual-e5-base、multilingual-e5-large、jina-embeddings-v3
API をそのまま使いたい: text-embedding-3-small、text-embedding-3-large
中国語と将来の拡張性を両立したい: bge-m3

すべてのプロジェクトに合う単一のモデルはありませんが、多くのプロジェクトでは、まずこの数グループから第一候補をかなり素早く絞り込めます。

AI用語解説: Agent、MCP、RAG、Token をわかりやすく整理する

Thu, 23 Apr 2026 13:13:40 +0800

AI に触れ始めたばかりのとき、人を遠ざけやすいのはモデルそのものより、会話の中に次々出てくる用語です。Agent、MCP、RAG、AIGC、Token はどれも見覚えはあっても、やさしく説明されないと本当の意味まではつかみにくいものです。

この記事では、よくある入門向けの説明の流れに沿って、AI で頻出する 10 個の用語を覚えやすい形にまとめます。学術的に厳密に説明することよりも、日常的な AI の話題についていける基本イメージを作ることを目的にしています。

10 個の代表的な AI 用語は何を意味するのか

1. Agent: 会話だけでなく実行もする AI

Agent は、実際に作業を進めてくれる AI アシスタントだと考えると分かりやすいです。

普通のチャットボットは、質問すると答えるという形にとどまりがちです。Agent はそこから一歩進み、タスクを分解し、手順を組み立て、ツールを呼び出し、最後に結果を返します。資料整理、調査、文書生成のような依頼でも、助言だけで終わらず、一連の動作をつないで実行することがあります。

だから Agent の本質は、話せるかどうかではなく、動けるかどうかにあります。

2. OpenClaw: PC に常駐する AI アシスタント

ここでの OpenClaw は、PC の中に住む AI アシスタントのようなものとして説明されています。

この種のツールは、デスクトップ操作に近い AI 支援だと考えると分かりやすいです。文字入力を受け取るだけでなく、画面を見たり、ローカルツールを呼び出したり、手順に沿って作業したりすることがあります。一般的な Web チャットと比べると、実際の操作能力がより重視されます。

Agent が実行型 AI という抽象的な概念だとすれば、こうしたデスクトップ型アシスタントは、その考え方の PC 上での具体例だと言えます。

3. Skills: Agent に追加する能力パック

Skills は、Agent の機能モジュールや操作ルールだと捉えられます。

同じ Agent でも、どの Skills を持つかによって得意分野が変わります。文章作成寄りのものもあれば、データ整理向けのものもあり、コード処理に向いたものもあります。スマートフォンのアプリに少し似ていますし、再利用できるワークフロー集にも近いです。

つまり、モデルそのものが急に賢くなったというより、背後にあるルール、ツール、手順が明確になった結果だと言えます。

4. MCP: AI が外部ツールにつながるための共通方式

MCP は Model Context Protocol の略です。

身近な比喩で言えば、AI の世界における Type-C 端子のようなものです。以前はモデルを別々のツールにつなぐたびに個別実装が必要になりがちでしたが、共通プロトコルがあると接続方法を標準化しやすくなります。

多くの人にとって大事なのは、MCP が「モデルが答えられるかどうか」の話ではなく、「モデルが外部ツールや外部リソースに安全かつ安定して接続するにはどうするか」の話だという点です。

5. ガチャ: AI 生成にはランダムさがある

「ガチャ」という表現は、AI 画像生成、動画生成、クリエイティブ用途でよく使われます。

意味はシンプルです。同じプロンプトで、同じ方向性を指定しても、毎回まったく同じ結果になるとは限りません。すごく良い結果が出ることもあれば、明らかに崩れることもあります。そのため、何度も生成して当たりを引く感覚がゲームのガチャにたとえられます。

ここで押さえておきたいのは、AI 生成は固定的な公式ではなく、確率的な揺らぎを含んだプロセスだということです。

6. API: アプリとモデルをつなぐ入口

API は Application Programming Interface の略です。

プログラム同士がやり取りするための標準的な入口だと考えると分かりやすいです。自分のアプリ、スクリプト、エディタからモデルサービスを呼び出すときは、実質的に API を通じてリクエストを送り、結果を受け取っています。

モデルサービスをレストランにたとえるなら:

メニューは API ドキュメント
注文は API リクエスト
厨房から料理が返ってくるのはモデルの応答

そのため、見た目は違うツールでも、裏側では何らかの API を呼んでいることが多いです。

7. マルチモーダル: AI は文字だけを扱うわけではない

マルチモーダル とは、AI が文字の読み書きだけに限られず、複数の種類の情報を扱えることを指します。

たとえば画像を見たり、音声を理解したり、動画を解釈したり、画像を生成したり、リアルタイムの音声や映像のやり取りを支えたりできます。文字しか扱えなかった初期のモデルと比べると、「見る・聞く・話す・書く」に近い能力を併せ持つ方向へ進んでいます。

だからこそ、今の AI 製品は単なるテキスト入力欄だけでは語れなくなっています。

8. RAG: 先に資料を探し、そのうえで答えを作る

RAG は Retrieval-Augmented Generation の略です。

これはとても実務的な課題に向いています。モデルの学習データには時点の限界があり、社内の最新資料、サポート記録、業務ルールを自動では知りません。RAG は、まず指定した資料群から関連情報を探し、その内容を踏まえて回答を生成する考え方です。

価値が出やすい点は主に 3 つあります。

回答が実際の資料に寄りやすくなる
どの資料を根拠にしたか追いやすい
新しい資料を追加すれば知識を更新しやすい

そのため、企業向けナレッジベース、AI カスタマーサポート、社内 Q&A では RAG がよく使われます。

9. AIGC: AI が作るコンテンツ全体を指す言葉

AIGC は AI Generated Content の略です。

これは単独のツール名ではなく、AI が生成したコンテンツ全般を指す総称です。文章、画像、音声、動画などが含まれます。AI ライティング、AI イラスト、AI による短尺動画制作、AI 音声生成などはすべて AIGC の枠で理解できます。

大事なのは、この言葉が特定のモデルではなく、コンテンツの作り方そのものを指していることです。

10. Token: モデルが内容を処理するときの計量単位

Token は、モデルがテキストを処理するときの基本的な計量単位だと考えられます。

これは 1 文字や 1 単語と完全に一致するわけではありませんが、実用上は計算量や課金の共通単位として捉えて問題ありません。入力でも Token を消費し、出力でも Token を消費し、保持しているコンテキストも同じように Token を使います。

だから多くのモデルサービスがコンテキスト長、コスト管理、プロンプト圧縮を強調するのは、結局どれも Token と深く関係しているからです。

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 フレームワークのほうが扱いやすいかもしれません。

RAG on KnightLiブログ

PageIndexとは？ベクトルDBを使わない推論型RAG文書インデックスを解説

何を解決しようとしているのか

PageIndexの基本ワークフロー

従来のベクトルRAGとの違い

ローカルでの実行方法

Agentic Vectorless RAGの例

クラウドサービス、MCP、API

向いている場面

注意点

まとめ

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

先に結論

OpenKB とは

従来型 RAG との違い

PageIndex が解決する問題

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

LLM 設定

よく使うコマンド

Markdown wiki が重要な理由

向いている場面

使うときの注意点

Obsidian、NotebookLM、企業 RAG との関係

おすすめのワークフロー

まとめ

コンピューター用語を平易に言うと：TTS、STT、API、RAG、Agent は何を指すのか

TTS と STT：文字と音声の相互変換

OCR：画像から文字を写し取る

NLP と LLM：機械に人間の言葉を扱わせる

API と SDK：一方は窓口、一方は道具箱

CRUD：作成、読み取り、更新、削除

Cache：よく使うものを手元に置く

Queue：タスクを並べて順番に処理する

Index：データベースに目次を作る

RPC、REST、Webhook：システム同士の話し方

CDN と Load Balancing：近くに置く、負荷を分ける

Docker、Container、Kubernetes：パッケージ化、実行、配置

CI/CD：自動ビルド、自動リリース

Serialization：オブジェクトを送れる形式に詰める

Token、Embedding、Vector DB：文字をモデルが扱える形にする

RAG：先に資料を調べてから答える

Agent：タスクを分解できる自動化フロー

まとめ

参考

Gemini Embedding 2：テキスト、画像、動画、音声を同じベクトル空間に入れる

モデルの機能

RAG にとっての意味

ビジュアル検索

検索結果の再ランキング

クラスタリング、分類、異常検知

保存とコスト

開発者はどう使うか

代表的な埋め込みモデルはどう選ぶべきか: OpenAI・BGE・E5・GTE・Jina の比較

1. まずは種類ごとに見る

1. OpenAI 系

2. BGE 系

3. E5 系

4. GTE 系

5. Jina Embeddings

2. 中国語シナリオでよく使われるモデル

3. これらのモデルを並べて考える

1. 中国語性能だけを見る場合

2. 多言語が必要な場合

3. 推論コストと保存コストを抑えたい場合

4. まず性能上限を優先したい場合

4. 各モデルはどんなタスクに向くか

5. 実際の選定をどう進めるか

シナリオ 1: 中国語ナレッジベース

シナリオ 2: 中国語と英語が混在するナレッジベース

シナリオ 3: 今は中国語中心だが、将来的に多言語へ広げる可能性がある

6. 最後に大事なのは「ランキング1位」ではない

まとめ

AI用語解説: Agent、MCP、RAG、Token をわかりやすく整理する

10 個の代表的な AI 用語は何を意味するのか

1. Agent: 会話だけでなく実行もする AI

2. OpenClaw: PC に常駐する AI アシスタント

3. Skills: Agent に追加する能力パック

4. MCP: AI が外部ツールにつながるための共通方式

5. ガチャ: AI 生成にはランダムさがある

6. API: アプリとモデルをつなぐ入口

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