LangChain против LlamaIndex для агентов Postgres

LangChain и LlamaIndex появились в один и тот же период, после выпуска ChatGPT в конце 2022 года. Их отправная точка заметно различается. LangChain моделирует приложение LLM как цепочку составных шагов: подсказка, вызов модели, инструмент, память — все это собирается с помощью LCEL или графа LangGraph.

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

# Канал получен из Студии → Настройки → Подключение.
# 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. Драйвера SQLAlchemy и стандартной строки подключения Postgres достаточно, как и для Supabase, RDS или локального экземпляра.

LangChain впервые предложил классический цикл агента (AgentExecutor, шаблон ReAct). С тех пор проект свел своих агентов к LangGraph: там агент представлен в виде явного графа узлов и ребер с контрольными точками и возможным вмешательством человека между двумя этапами.

LlamaIndex отвечает своим Workflows: оркестровкой, управляемой событиями, где каждый шаг генерирует и потребляет типизированные события. Механизм SQL или векторных запросов подключается непосредственно в качестве шага, без дополнительного уровня адаптации, поскольку эти механизмы уже являются собственными примитивами платформы.

Для агента, запрашивающего Postgres, практическая разница заключается в следующем: LangGraph обеспечивает детальный контроль над ветвями и повторными попытками выполнения SQL-вызова. LlamaIndex требует меньше связывающего кода, когда вопрос в первую очередь касается данных, уже проиндексированных платформой.

Идем глубже: руководство по вызову функций для агента Postgres

LlamaIndex изначально разрабатывался для подключения LLM к источникам данных с каталогом коннекторов (LlamaHub) и специализированными индексами в зависимости от типа контента. RAG остается наиболее прямым вариантом использования платформы, а не функцией, добавленной постфактум.

LangChain удовлетворяет те же потребности через свои цепочки retrievers и fetch с такой же зрелой интеграцией в экосистему LangGraph. Разница не столько в емкости, сколько в том, где живет бизнес-логика: она интегрирована в индекс на стороне LlamaIndex, явно собрана в цепочку на стороне LangChain.

Оба знают, как использовать pgvector в качестве векторной базы: llama-index-vector-stores-postgres на стороне LlamaIndex, класс PGVector пакета langchain-postgres на стороне LangChain. В проекте Aurabase pgvector 0.8.6 уже присутствует в образе клиента Postgres: оба пакета подключаются к нему с помощью одной и той же строки подключения без отдельного этапа активации.

Копните глубже: построение RAG-конвейера Postgres/pgvector

CrewAI управляет несколькими агентами на каждую роль: каждый агент получает цель, контекст (backstory) и инструменты, сгруппированные в Crew, где Task выполняется последовательно или в соответствии с иерархией. Это полноценная среда оркестрации, а не расширение LangChain.

AutoGen, исследовательский проект Microsoft, использует другой подход: агенты, которые общаются друг с другом (AssistantAgent, UserProxyAgent, GroupChat), с возможностью выполнять код в изолированной среде. Координация выглядит как диалог, а не как явный граф состояний, такой как LangGraph.

Ни один из них не заменяет уровень подключения к данным. Агент CrewAI или AutoGen, которому необходимо читать Postgres, на практике вызывает инструмент SQL, созданный с помощью LangChain или LlamaIndex, или простую функцию Python на основе psycopg2. CrewAI и AutoGen отвечают «кто, что и в каком порядке делает», а не «как читать базу данных».

create_sql_agent и NLSQLTableQueryEngine выполняют запрос, сгенерированный моделью, к предоставленному соединению. Не ограничивает количество строк, возвращаемых по умолчанию, и не блокирует запрос на запись: фактическое ограждение — это роль Postgres, используемая в строке подключения, а не опция платформы.

Это структурное отличие от собственного NL2SQL Aurabase, который преобразует вопрос в SQL на стороне сервера, проверяет сгенерированный запрос (анализ SQL, отклонение поддельных полей сервера) и ограничивает LIMIT перед выполнением. Это не тот же самый кирпич: конечная точка NL2SQL отвечает за один ход, при этом платформа устанавливает защитные ограждения; Агент LangChain или LlamaIndex рассуждает в несколько этапов, с возможностью собраться самостоятельно.

На практике эти два подхода скорее дополняют, чем исключают друг друга: ограниченная конечная точка NL2SQL для простого вопроса, заданного конечному пользователю, агент для многоэтапного рассуждения, который сочетает в себе несколько инструментов, помимо SQL.

См. также: Учебное пособие по NL2SQL по Postgres с Aurabase

Трех шагов достаточно, независимо от выбранной платформы, и они не зависят от какого-либо коннектора, специфичного для платформы.

# 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;

Третий шаг имеет большее значение, чем выбор структуры. Роль Postgres, ограниченная действительно необходимыми правами, остается единственной надежной защитой от сгенерированного запроса, выходящего за рамки его объема, независимо от того, какой агент его выполняет. См. документацию AI для настройки собственных поставщиков LLM Aurabase (OpenAI, Anthropic, Gemini), которые можно использовать на стороне агента.

Ни одна из инфраструктур не является абсолютно лучшей для агента, подключенного к Postgres. Стартовый контекст проекта имеет большее значение, чем список функциональных возможностей.

• LangChain: если агент должен объединить несколько разнородных инструментов (SQL, внешние API, веб-поиск) с точным контролем потока через LangGraph, и если команда ценит самую широкую экосистему интеграции на рынке.
• LlamaIndex: если сердцем проекта является RAG или запрос уже проиндексированных данных, с острой потребностью в коннекторах источника и модели индекса/запроса, которая напрямую соответствует варианту использования.
• CrewAI или AutoGen дополнительно: как только одного агента уже недостаточно и работу приходится распределять между несколькими специализированными ролями, над одной или другой из двух платформ данных.

Они также могут сосуществовать в одном проекте: механизм запросов LlamaIndex, представленный как инструмент в агенте LangGraph, является распространенным шаблоном. Поддержание двух платформ сопряжено с реальными сложностями, которые необходимо сопоставить с выгодой, прежде чем принимать их по умолчанию.