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 لـ
# الترميز الدقيق لمعلمة "الخيارات" اعتمادًا على برنامج التشغيل المستخدم).
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 وسلاسل الجلب، مع تكامل ناضج بنفس القدر في نظام LangGraph البيئي. لا يتعلق الاختلاف بالقدرة بقدر ما يتعلق بالمكان الذي يعيش فيه منطق الأعمال: مدمج في المؤشر على جانب LlamaIndex، ويتم تجميعه بشكل واضح في سلسلة على جانب LangChain.

كلاهما يعرف كيفية استخدام pgvector كقاعدة متجهة: llama-index-vector-stores-postgres على جانب LlamaIndex، وفئة PGVector من الحزمة langchain-postgres على جانب LangChain. في مشروع Aurabase، يكون pgvector 0.8.6 موجودًا بالفعل في صورة مستأجر Postgres: تتصل كلا الحزمتين به بنفس سلسلة الاتصال، بدون خطوة تنشيط منفصلة.

احفر بشكل أعمق: بناء خط أنابيب Postgres/pgvector RAG

يقوم 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 وواجهات برمجة التطبيقات الخارجية وبحث الويب) مع التحكم الدقيق في التدفق عبر LangGraph، وإذا كان الفريق يقدر النظام البيئي التكاملي الأوسع في السوق.
• LlamaIndex: إذا كان قلب المشروع هو RAG أو الاستعلام عن البيانات المفهرسة بالفعل، مع وجود حاجة قوية لموصلات المصدر ونموذج فهرس/استعلام يتناسب مباشرة مع حالة الاستخدام.
• CrewAI أو AutoGen بالإضافة إلى: بمجرد أن لا يعد وكيل واحد كافيًا ويجب توزيع العمل بين عدة أدوار متخصصة، فوق واحد أو آخر من إطاري البيانات.

يمكن أن يتواجد الاثنان أيضًا في نفس المشروع: يعد محرك استعلام LlamaIndex الذي يتم عرضه كأداة في وكيل LangGraph نمطًا شائعًا. إن الحفاظ على إطارين ينطوي على تكلفة تعقيد حقيقية، ويجب مقارنتها بالمكاسب قبل اعتمادها افتراضيًا.