LangChain vs LlamaIndex dla agentów Postgres

LangChain i LlamaIndex pojawiły się w tym samym okresie, po wydaniu ChatGPT pod koniec 2022 roku. Ich punkt wyjścia znacznie się różni. LangChain modeluje aplikację LLM jako łańcuch dających się złożyć kroków: podpowiedź, wywołanie modelu, narzędzie, pamięć, a wszystko to składa się za pomocą wykresu LCEL lub LangGraph.

LlamaIndex pierwsze modele danych: dokumenty, węzły, indeksy, silnik zapytań. VectorStoreIndex lub SQLDatabase to obywatele pierwszej klasy, a nie narzędzia dodane do ogólnego agenta. Obydwa są open source (licencja MIT), dostępne w Pythonie i TypeScript, a dziś obejmują w dużej mierze pokrywający się zakres: agenci, RAG, wywoływanie narzędzi, połączenie SQL.

Ta zbieżność sprawia, że ​​porównanie jest bardziej przydatne w przypadku architektury niż na liście funkcji: oba mogą prawie zrobić to samo. Co się zmienia, to jak.

Po stronie LangChain moduł langchain_community.utilities.SQLDatabase zawiera silnik SQLAlchemy. Następnie agent create_sql_agent udostępnia go jako zestaw narzędzi: wyświetla listę tabel, opisuje schemat, wykonuje zapytanie, sprawdza zapytanie przed wykonaniem.

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

# Kanał uzyskany ze Studio → Ustawienia → Połączenie.
# search_path trasa do schematu projektu (patrz dokumentacja SQLAlchemy/psycopg dla
# dokładne kodowanie parametru „opcje” w zależności od użytego sterownika).
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 ?"})

Po stronie LlamaIndex równoważną abstrakcją jest llama_index.core.SQLDatabase, również zbudowana na silniku SQLAlchemy. Mechanizm zapytań NLSQLTableQueryEngine tłumaczy pytanie w języku naturalnym na zapytanie SQL, wykonuje je, a następnie ponownie formułuje wynik jako odpowiedź.

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 ?")

Żaden z ekstraktów nie zależy od Aurabase. Wystarczający jest sterownik SQLAlchemy i standardowy ciąg połączenia Postgres, podobnie jak w przypadku Supabase, RDS lub instancji hostowanej samodzielnie.

LangChain jako pierwszy zaproponował klasyczną pętlę agenta (AgentExecutor, wzorzec ReAct). Od tego czasu projekt skupił swoich agentów w kierunku LangGraph: agent jest tam reprezentowany jako wyraźny wykres węzłów i krawędzi, z punktami kontrolnymi i możliwą interwencją człowieka pomiędzy dwoma etapami.

LlamaIndex odpowiada swoim Workflows: orkiestracją sterowaną zdarzeniami, w której każdy krok emituje i zużywa wpisane zdarzenia. Silnik zapytań SQL lub wektorowych podłącza się bezpośrednio jako krok, bez dodatkowej warstwy adaptacyjnej, ponieważ te silniki są już natywnymi prymitywami frameworka.

W przypadku agenta wysyłającego zapytania do Postgres praktyczna różnica jest następująca: LangGraph zapewnia precyzyjną kontrolę nad gałęziami i ponownymi próbami wywołania SQL. LlamaIndex wymaga mniej kodu łączącego, gdy pytanie dotyczy najpierw danych już zaindeksowanych przez platformę.

Wejdź głębiej: poradnik wywoływania funkcji dla agenta Postgres

LlamaIndex został od początku zaprojektowany, aby połączyć LLM ze źródłami danych, z katalogiem łączników (LlamaHub) i specjalistycznymi indeksami w zależności od rodzaju treści. RAG pozostaje najbardziej bezpośrednim przypadkiem użycia frameworka, a nie funkcją dodaną po fakcie.

LangChain zaspokaja tę samą potrzebę poprzez swoje retrievers i łańcuchy pobierania, z równie dojrzałą integracją z ekosystemem LangGraph. Różnica polega mniej na pojemności, niż na tym, gdzie leży logika biznesowa: zintegrowana z indeksem po stronie LlamaIndex, jawnie połączona w łańcuch po stronie LangChain.

Obaj wiedzą, jak używać pgvector jako bazy wektora: llama-index-vector-stores-postgres po stronie LlamaIndex, klasa PGVector pakietu langchain-postgres po stronie LangChain. W projekcie Aurabase pgvector 0.8.6 jest już obecny w obrazie dzierżawy Postgres: oba pakiety łączą się z nim za pomocą tych samych parametrów połączenia, bez osobnego etapu aktywacji.

Kop głębiej: budowanie rurociągu RAG Postgres/pgvector

CrewAI organizuje kilku agentów na rolę: każdy agent otrzymuje cel, kontekst (backstory) i narzędzia pogrupowane w Crew z Task wykonywanym sekwencyjnie lub według hierarchii. Jest to pełnoprawna platforma orkiestracji, a nie rozszerzenie LangChain.

AutoGen, projekt badawczy firmy Microsoft, przyjmuje inne podejście: agenci, którzy komunikują się ze sobą (AssistantAgent, UserProxyAgent, GroupChat), z możliwością wykonywania kodu w izolowanym środowisku. Koordynacja wygląda jak rozmowa, a nie wyraźny wykres stanu, taki jak LangGraph.

Żadna z nich nie zastępuje warstwy połączenia danych. Agent CrewAI lub AutoGen, który musi czytać wywołania Postgres, w praktyce narzędzie SQL zbudowane z LangChain lub LlamaIndex lub prosta funkcja Pythona wokół psycopg2. CrewAI i AutoGen odpowiadają na pytanie „kto co i w jakiej kolejności robi”, a nie „jak czytać bazę danych”.

create_sql_agent i NLSQLTableQueryEngine wykonują zapytanie wygenerowane przez model na podstawie dostarczonego połączenia. Ani nie ogranicza domyślnie liczby zwracanych wierszy, ani nie blokuje żądania zapisu: rzeczywistą poręczą jest rola Postgres używana w ciągu połączenia, a nie opcja struktury.

Jest to strukturalna różnica w stosunku do natywnego języka NL2SQL Aurabase, który tłumaczy pytanie na SQL po stronie serwera, sprawdza wygenerowane zapytanie (parsowanie SQL, odrzucanie sfałszowanych pól serwera) i ogranicza LIMIT przed wykonaniem. To nie ta sama cegła: punkt końcowy NL2SQL odpowiada w jednej turze, z barierkami zainstalowanymi na platformie; a agent LangChain lub LlamaIndex uzasadnia w kilku etapach, z zabezpieczeniem samodzielnego montażu.

W praktyce te dwa podejścia raczej się uzupełniają niż wykluczają: ograniczony punkt końcowy NL2SQL dla prostego pytania kierowanego do użytkownika końcowego, agent do wieloetapowego wnioskowania, który łączy w sobie kilka narzędzi wykraczających poza SQL.

Zobacz też: Samouczek NL2SQL na temat Postgres z Aurabase

Wystarczą trzy kroki, niezależnie od wybranego frameworka i nie są one zależne od żadnego konektora specyficznego dla platformy.

# 1. Pobierz parametry połączenia Postgres projektu
#    (Studio → Ustawienia → Połączenie lub dowolny zarządzany Postgres)
export AURA_DB_URL="postgresql+psycopg2://aura:***@<host>:5432/aura_db_master?options=-csearch_path%3Dproject_<id>"

# 2. Zainstaluj sterownik SQL i wybrany framework
pip install langchain langchain-community langchain-openai psycopg2-binary
# lub po stronie LlamaIndex:
pip install llama-index llama-index-llms-openai psycopg2-binary

# 3. Utwórz dedykowaną rolę Postgres, tylko do odczytu, jeśli agent powinien tylko odpytywać
CREATE ROLE agent_readonly LOGIN PASSWORD '***';
GRANT SELECT ON ALL TABLES IN SCHEMA project_<id> TO agent_readonly;

Trzeci krok ma większe znaczenie niż wybór ram. Rola Postgres ograniczona do naprawdę niezbędnych praw pozostaje jedynym niezawodnym zabezpieczeniem przed wygenerowanym żądaniem przekraczającym jego zakres, niezależnie od agenta go wykonującego. Zobacz dokumentację AI, aby zapoznać się z konfiguracją natywnych dostawców LLM Aurabase (OpenAI, Anthropic, Gemini), których można używać po stronie agenta.

Żadna struktura nie jest ściśle lepsza dla agenta połączonego z Postgres. Kontekst początkowy projektu jest bardziej decydujący niż lista funkcjonalności.

• LangChain: jeśli agent musi połączyć kilka heterogenicznych narzędzi (SQL, zewnętrzne API, wyszukiwarka internetowa) z precyzyjną kontrolą przepływu za pośrednictwem LangGraph i jeśli zespół ceni najszerszy ekosystem integracyjny na rynku.
• LlamaIndex: jeśli sercem projektu jest RAG lub wykonywanie zapytań dotyczących już zindeksowanych danych, przy silnym zapotrzebowaniu na łączniki źródłowe i model indeksu/zapytania, który pasuje bezpośrednio do przypadku użycia.
• CrewAI lub AutoGen dodatkowo: gdy pojedynczy agent już nie wystarczy i praca musi zostać rozdzielona pomiędzy kilka wyspecjalizowanych ról, powyżej jednego lub drugiego z dwóch frameworków danych.

Obydwa mogą również współistnieć w tym samym projekcie: silnik zapytań LlamaIndex udostępniony jako narzędzie w agencie LangGraph jest powszechnym wzorcem. Utrzymanie dwóch frameworków wiąże się z prawdziwym kosztem złożoności, który należy porównać z korzyściami przed domyślnym przyjęciem.