LLM が一度に「参照」できるテキスト量には限りがあります（コンテキストウィンドウ）。小規模なタスクには対応できますが、ナレッジベースが数千ページに及ぶと機能しなくなります。コンテキストウィンドウが十分でも、「干し草の山から針を探す」問題により、パフォーマンスが低下することがあります。
RAG（「検索拡張生成」）は非常に一般的な手法です。ドキュメント、Wiki、ポリシー、文字起こしなどのナレッジベースを維持し、ユーザーのクエリに対してセマンティック検索を実行して、埋め込みにより関連性の高い箇所を取得し、質問とともにそれらのチャンクを LLM に渡します。これによりモデルのコンテキストが絞られ、適切に実施すれば、回答品質を高めてハルシネーションを減らせます。
pgai は、信頼性の高いオープンソースデータベース PostgreSQL 上で「AI 検索」ワークフローを構築できる、オープンソースの Postgres 拡張機能（および関連ツール）です。
主な考え方は、DB を埋め込みの「単なる保管場所」として扱うのではなく、標準的な RAG パイプラインの大部分（取り込み → チャンク化 → 埋め込み → 埋め込みの同期維持）をデータベース層に移すことです。
第一印象では有望ですが、RAG パイプラインが少しでも複雑になると、特にチャンク化の手法によっては適さなくなります。とはいえ、今後もこのプロジェクトを注視していきます。
RAG の構築方法は多数あります。各種アプローチの詳しい解説は、カスタマイズされた RAG ソリューションの実践例をご覧ください。 品質を追求すると設計の選択肢は驚くほど奥深くなりますが、一般的な「デフォルト」のアプローチは次のとおりです。
ドキュメントをまとめて用意する
ドキュメントをチャンクに分割する方法はさまざまです（段落単位、意味的なグループ単位など）
各チャンクを埋め込みに変換する
埋め込みをベクトルデータベース（Pinecone、Milvus など）、または pgvector を使用した Postgres に保存する
クエリ実行時に最も近いチャンクを検索し、`LLM に渡す（これにもさまざまな方法があります）
多くの技術スタックでは、手順（1）～（3）はデータベース外のアプリケーションコードやデータパイプラインで行われ、データベースは主に次の目的で使用されます。
埋め込みの保存
埋め込みの検索
pgai は、その境界を曖昧にしようとする Postgres 拡張機能です（オープンソースで、Timescale が開発）。
pgai は、埋め込みをアプリで手動管理するものではなく、データベースの機能として扱います。
埋め込み対象のテーブルやドキュメントを定義する
埋め込みモデルとチャンク化戦略を指定する
ソースデータの変更に合わせた埋め込みの更新など、残りは pgai が管理する
この構想には次のような魅力があります。
保守が必要な専用の連携コードを削減
元のドキュメントが変わっても、埋め込みを「最新」に保ちやすい
再試行、レート制限、失敗したジョブなどを Postgres/pgai が管理
読者への注記：pgai には、もう一つの非常に人気の高い RAG 用 Postgres 拡張機能である pgvector が同梱されています。pgvector は Postgres にベクトルストレージと類似度検索を追加します。pgai はそれを基盤として、チャンク化、埋め込み、埋め込みの更新維持といった RAG パイプラインの工程を自動化します。
1）簡単に稼働できる
標準的な手順は比較的シンプルです。
Timescale の Docker イメージ（データベースとワーカー）を取得する
埋め込みプロバイダーの API キーを設定する
少量の SQL を実行してベクトライザーを宣言する（基本的には、埋め込み対象、チャンク化方法、使用するモデルを指定）
その後、pgai はベクトライザーワーカーを別プロセスとして実行し、非同期で埋め込みを生成します（5 分ごとなど、任意の間隔を指定できます）。
2）パイプライン全体をデータベースの「近く」で実行できる
pgai はテーブルからコンテンツを取り込めるほか、S3 などからドキュメントを読み込み、解析、チャンク化、埋め込みまで実行できます。PDF や Markdown など、さまざまなテキストドキュメント形式にも対応できます。
1）制御の多くを失う（RAG では制御が必要な場合がある）
回答品質で評価した場合、高性能な RAG システムには、次のような独自のパイプラインが必要になることがよくあります。
独自のチャンク化ルール（見出し、ページ、話者の発言単位など）
メタデータを考慮したチャンク化（セクション名、タイムスタンプ、作成者、ドキュメント形式を保持）
ドキュメント形式ごとに異なる埋め込み戦略
上記の点では、pgai の柔軟性は限られています。
現時点で主なチャンク化戦略は、文字テキスト分割と再帰的文字テキスト分割の 2 つで、チャンク化しないオプションもあります。用途によっては十分かもしれませんが、多くの本番 RAG システムでは、さらなるカスタマイズが必要です。
Timescale が Chonkie などのライブラリに見られる高度なチャンク化戦略を取り入れ、同様に Anthropic のコンテキスト検索のような高度な設計にも対応すれば、素晴らしいでしょう。
2）マルチモーダルではなく、テキスト優先
興味深い RAG の課題の多くは、もはやテキストだけでは完結しません。
図を含む PDF
スクリーンショットや画像
音声録音
動画クリップ
これらのソースから「テキストを抽出」できても、真のマルチモーダル埋め込みパイプラインと同じではありません。
将来的に pgai がマルチモーダルモデルにエンドツーエンドで対応し、S3 に保存された大容量の画像、音声、動画を堅牢に同期しながら、読み込み → チャンク化 → 埋め込みまで行えるようになれば魅力的です。しかし現時点では、テキスト埋め込みのワークフローです。
3）埋め込みだけが必要なら、pgai は不要かもしれない
取り込みパイプラインがすでに独自仕様である、または独自仕様にする必要がある場合、「テキストチャンクの埋め込み」は RAG で最も難しい部分ではありません。そのような環境では、pgai が解決するのは課題の最も簡単な部分です。
また、ナレッジベースの更新頻度が低ければ、埋め込みを自動同期する価値もそれほど高くありません。
pgai の特に優れた活用法の一つは、データベース上に Text-to-SQL インターフェースを導入することです。これは、pgai が提供する semantic_catalog モジュールで簡単に実現できます。次のように設定するだけです。
Bash
続いて pgai semantic-catalog create を実行し、セマンティックカタログにデータディクショナリを収集させます。これにより、データストアから次のようなコンテキストが生成されます。
Plain Text
このコンテキストは、さまざまな方法で pgai から利用できるようになります。
セマンティック検索：
このクエリは、自然言語クエリに関連する可能性があるテーブル、関数、その他のオブジェクトを返します。
Bash
生のコンテキストを取得：
自然言語クエリに関連する生の YAML コンテキストを表示します。
Bash
SQL を生成：
または、クエリへの回答に必要な生の SQL を直接生成できます。前の手順で得たコンテキストが LLM に送信され、回答が生成されます。
Bash
比較的シンプルな RAG システムを構築しており、次の要件がある場合は、pgai を試す価値があります。
Postgres を信頼できる唯一の情報源として使用
最小限の連携コード
自動的に同期される埋め込み
データベースに Text-to-SQL をすばやく適用
新しい RAG ツールや Postgres 拡張機能を試用
RAG パイプラインに次のいずれかが必要な場合、pgai の採用は待った方がよいでしょう。
高度にカスタマイズされた取り込みまたはチャンク化ロジック
解析要件が異なる多数のドキュメント形式
マルチモーダル埋め込み
最後に、pgvector が広く採用されていることは明らかですが、登場から約 18 か月しか経っていないとはいえ、pgai が同程度の関心を集め、それに伴うサポートを得られるかは不透明です。
pgai は、日常的な運用作業の多くをデータベースに任せ、アプリケーションコードを簡素化するという、RAG への興味深いアプローチです。
現時点での評価は次のとおりです。
シンプルな RAG 構成では実用的で、非常に使いやすい
独自性の高いパイプライン、特にマルチモーダル用途には柔軟性が不足
将来性があり、今後の進展を追う価値は十分にあります。