Postgres エージェントの LangChain と LlamaIndex の比較

LangChain と LlamaIndex は、2022 年末の ChatGPT のリリースを受けて、同じ時期に登場しました。それらの出発点は著しく異なります。 LangChain は、プロンプト、モデル呼び出し、ツール、メモリなど、すべて LCEL または LangGraphグラフを介して組み立てられる、構成可能なステップのチェーンとして LLM アプリケーションをモデル化します。

LlamaIndex は、まずデータ (ドキュメント、ノード、インデックス、クエリ エンジン) をモデル化します。 VectorStoreIndex または SQLDatabase は第一級市民であり、汎用エージェントに追加されるツールではありません。どちらもオープン ソース (MIT ライセンス) で、Python と TypeScript で利用でき、現在、エージェント、RAG、ツール呼び出し、SQL 接続など、ほぼ重複する範囲をカバーしています。

この収束により、比較は機能のリストよりもアーキテクチャ上でより有用になります。どちらも、ほぼ同じことを実行できます。何が変わるかは、どのように変わるかです。

LangChain 側では、langchain_community.utilities.SQLDatabase モジュールが SQLAlchemy エンジンをカプセル化します。 create_sql_agent エージェントは、テーブルの一覧表示、スキーマの記述、クエリの実行、実行前のクエリのチェックなどのツール セットとしてそれを公開します。

from langchain_community.utilities import SQLDatabase
from langchain_community.agent_toolkits import create_sql_agent
from langchain_openai import ChatOpenAI

# Studio → 設定 → 接続から取得したチャンネル。
# search_path プロジェクト スキーマへのルート (詳細については SQLAlchemy/psycopg ドキュメントを参照)
# 「options」パラメータの正確なエンコードは、使用されるドライバに応じて異なります)。
db = SQLDatabase.from_uri(
    "postgresql+psycopg2://aura:***@<host>:5432/aura_db_master?options=-csearch_path%3Dproject_<id>"
)

llm = ChatOpenAI(model="gpt-4o-mini")
agent = create_sql_agent(llm=llm, db=db, agent_type="tool-calling")

agent.invoke({"input": "Combien de commandes la semaine dernière ?"})

LlamaIndex 側では、同等の抽象化は llama_index.core.SQLDatabaseであり、これも SQLAlchemy エンジン上に構築されています。 NLSQLTableQueryEngine クエリ エンジンは、自然言語の質問を SQL クエリに変換して実行し、結果を応答として再定式化します。

from sqlalchemy import create_engine
from llama_index.core import SQLDatabase
from llama_index.core.query_engine import NLSQLTableQueryEngine
from llama_index.llms.openai import OpenAI

engine = create_engine(
    "postgresql+psycopg2://aura:***@<host>:5432/aura_db_master?options=-csearch_path%3Dproject_<id>"
)
sql_database = SQLDatabase(engine, include_tables=["orders", "customers"])

query_engine = NLSQLTableQueryEngine(
    sql_database=sql_database, llm=OpenAI(model="gpt-4o-mini"),
)
response = query_engine.query("Combien de commandes la semaine dernière ?")

どちらの抽出も Aurabase に依存しません。 Supabase、RDS、または自己ホスト型インスタンスの場合と同様、SQLAlchemy ドライバーと標準の Postgres 接続文字列で十分です。

LangChain は最初に古典的なエージェント ループ (AgentExecutor、ReAct パターン) を提案しました。それ以来、プロジェクトはエージェントを LangGraphに向けて収束させました。エージェントはノードとエッジの明示的なグラフとして表現されており、チェックポイント設定と 2 つのステージ間の人間の介入の可能性があります。

LlamaIndex は、イベント駆動型のオーケストレーションである Workflowsで応答します。各ステップは、型指定されたイベントを発行および消費します。 SQL またはベクトル クエリ エンジンは、すでにフレームワークのネイティブ プリミティブであるため、追加のアダプテーション レイヤーを必要とせずに、ステップとして直接プラグインされます。

Postgres にクエリを実行するエージェントの場合、実質的な違いは次のとおりです。LangGraph では、SQL 呼び出しの前後で分岐と再試行をきめ細かく制御できます。 LlamaIndex は、フレームワークによってすでにインデックス付けされているデータに関する質問の場合、必要なリンク コードが少なくなります。

さらに詳しく: Postgres エージェントの関数呼び出しチュートリアル

LlamaIndex は、コネクタのカタログ (LlamaHub) とコンテンツの種類に応じた特殊なインデックスを使用して、LLM をデータ ソースに接続するために最初から設計されました。 RAG は、フレームワークの最も直接的な使用例であり、後から追加される機能ではありません。

LangChain は、retrievers およびフェッチ チェーンを通じて同じニーズを満たし、LangGraph エコシステムへの同様に成熟した統合を実現します。違いは容量に関するものではなく、ビジネス ロジックが存在する場所です。LlamaIndex 側ではインデックスに統合され、LangChain 側ではチェーンに明示的に組み立てられます。

どちらも pgvector をベクトル ベースとして使用する方法を知っています。LlamaIndex 側では llama-index-vector-stores-postgres を、LangChain 側では langchain-postgres パッケージの PGVector クラスを使用します。 Aurabase プロジェクトでは、pgvector 0.8.6 がすでに Postgres テナントイメージに存在しています。両方のパッケージは、別のアクティブ化手順を行わずに、同じ接続文字列を使用してそれに接続します。

さらに詳しく: Postgres/pgvector RAG パイプラインの構築

CrewAI は、ロールごとに複数のエージェントを調整します。各エージェントは、目的、コンテキスト (backstory)、ツールを受け取り、Crew にグループ化され、Task は順番にまたは階層に従って実行されます。これは、LangChain の拡張ではなく、本格的なオーケストレーション フレームワークです。

Microsoft の研究プロジェクトである AutoGen は、別のアプローチを採用しています。つまり、隔離された環境でコードを実行する機能を備えた、相互に通信するエージェント (AssistantAgent、 UserProxyAgent、 GroupChat) です。調整は、LangGraph のような明示的な状態グラフではなく、会話のように見えます。

どちらもデータ接続層を置き換えるものではありません。 Postgres を読み取る必要がある CrewAI または AutoGen エージェントは、実際には、LangChain または LlamaIndex で構築された SQL ツール、または psycopg2周辺の単純な Python 関数を呼び出します。 CrewAI と AutoGen は、「データベースをどのように読み取るか」ではなく、「誰が何をどの順序で行うか」に答えます。

create_sql_agent および NLSQLTableQueryEngine は、提供された接続に対してモデルによって生成されたクエリを実行します。デフォルトで返される行数を制限したり、書き込みリクエストをブロックしたりすることはありません。実際のガードレールは、フレームワーク オプションではなく、接続文字列で使用される Postgres ロールです。

これは、サーバー側で質問を SQL に変換し、生成されたクエリ (SQL 解析、スプーフィングされたサーバーフィールドの拒否) を検証し、実行前に LIMIT を制限する Aurabase のネイティブ NL2SQL との構造的な違いです。これは同じレンガではありません。NL2SQL エンドポイントは、プラットフォームによってインストールされたガードレールを使用して 1 ターンで応答します。 LangChain または LlamaIndex エージェントは、自分で組み立てるための安全策を備えたいくつかの段階で推論します。

実際には、この 2 つのアプローチは、お互いを排除するのではなく、補完し合っています。つまり、エンド ユーザーに公開される単純な質問に対する制限された NL2SQL エンドポイントと、SQL を超えたいくつかのツールを組み合わせたマルチステップ推論のためのエージェントです。

参照: Aurabase を使用した Postgres の NL2SQL チュートリアル

選択したフレームワークに関係なく、3 つの手順で十分です。また、プラットフォーム固有のコネクタに依存しません。

# 1. プロジェクトの Postgres 接続文字列を取得します。
#    (スタジオ → 設定 → 接続、または任意の管理対象 Postgres)
export AURA_DB_URL="postgresql+psycopg2://aura:***@<host>:5432/aura_db_master?options=-csearch_path%3Dproject_<id>"

# 2. SQL ドライバーと選択したフレームワークをインストールします
pip install langchain langchain-community langchain-openai psycopg2-binary
# または、LlamaIndex 側で次のようにします。
pip install llama-index llama-index-llms-openai psycopg2-binary

# 3. 専用の Postgres ロールを作成します。エージェントがポーリングのみを行う場合は読み取り専用です。
CREATE ROLE agent_readonly LOGIN PASSWORD '***';
GRANT SELECT ON ALL TABLES IN SCHEMA project_<id> TO agent_readonly;

3 番目のステップは、フレームワークの選択よりも重要です。本当に必要な権限に制限された Postgres ロールは、実行するエージェントに関係なく、その範囲を超える生成されたリクエストに対する唯一の信頼できる保護手段となります。エージェント側で使用できる Aurabase のネイティブ LLM プロバイダ (OpenAI、Anthropic、Gemini) の設定については、AI ドキュメント を参照してください。

どちらのフレームワークも、Postgres に接続されているエージェントにとって厳密には優れているわけではありません。プロジェクトの開始コンテキストは、機能のリストよりも決定的です。

• LangChain: エージェントが複数の異種ツール (SQL、外部 API、Web 検索) を組み合わせて LangGraph 経由でフローを細かく制御する必要がある場合、およびチームが市場で最も広範な統合エコシステムを重視している場合。
• LlamaIndex: プロジェクトの中心が RAG またはすでにインデックス付けされたデータのクエリであり、ソース コネクタとユース ケースに直接適合するインデックス/クエリ モデルが強く必要な場合。
• CrewAI または AutoGen に加えて: 単一のエージェントでは十分ではなくなり、2 つのデータ フレームワークのいずれかの上にある複数の特殊なロール間で作業を分散する必要がある場合はすぐに実行されます。

この 2 つは同じプロジェクト内で共存することもできます。LangGraph エージェントのツールとして公開される LlamaIndex クエリ エンジンが一般的なパターンです。 2 つのフレームワークを維持するには、実際の複雑さのコストがかかり、デフォルトで採用する前に利点と比較検討する必要があります。