خب، بیاید بی‌تعارف بریم سراغ معایب واقعی فریمورک‌های RAG و Agent. این روزا همه دنبال راه حل سریعن، ولی این ابزارها عصای موسی نیستن و هرکدوم کلی دردسر و مشکلات فنی با خودشون میارن. اینجا یه کالبدشکافی از مشکلاتشون رو می‌بینید که از تجربه و بازخورد دولوپرها درومده.


اصل داستان توی ساخت سیستم‌های مبتنی بر LLM، ارکستریشن (orchestration) هست. یعنی مدیریت جریان کار، فراخوانی ابزارها، و نگهداری وضعیت (state). هر فریمورکی یه راهی برای این ارکستریشن پیشنهاد می‌ده و انتخاب اشتباه می‌تونه منجر به مشکلات معماری جدی بشه.

استفاده مستقیم از OpenAI SDK یعنی شما مسئولیت کامل لایه ارکستریشن رو به عهده می‌گیرید. این به معنی کنترل صددرصدی روی پرامپت‌ها، مدیریت state و منطق فراخوانی ابزارهاست. از نظر فنی، این روش کمترین overhead و dependency رو داره ولی تمام پیچیدگی‌های state management و control flow رو به کدبیس اپلیکیشن شما منتقل می‌کنه. برای سیستم‌های پیچیده، این یعنی باید یک مینی-فریمورک داخلی برای خودتون بنویسید.

فریمورک LangChain مشکل اصلیش سطح بالای انتزاع (high level of abstraction) هست. این فریمورک منطق اصلی رو پشت کلاس‌ها و متدهای خودش مخفی می‌کنه و این باعث می‌شه introspection یا همون بازبینی عملکرد داخلی سیستم، به شدت سخت بشه. مثلا فهمیدن اینکه پرامپت نهایی که به مدل ارسال شده دقیقاً چی بوده، کار ساده‌ای نیست. این "جادو" هزینه داره: سربار محاسباتی و حافظه بیشتر، و سختی در دیباگ کردن. LangGraph تلاشی برای حل این مشکله؛ با تبدیل کردن جریان کار به یک گراف صریح (explicit graph)، کنترل بیشتری روی control flow به دولوپر می‌ده. در واقع شما یک state machine تعریف می‌کنید. چالش فنی LangGraph اینه که هنوز جدیده، ابزارهای جانبی و مستندات کاملی نداره و پیچیدگی مدیریت گراف به عهده خود شماست.

ابزار LlamaIndex معماریش کاملاً داده-محور (data-centric) هست و برای پایپ‌لاین‌های ingestion و retrieval در RAG بهینه‌سازی شده. انتزاع‌های اصلیش مثل Index و QueryEngine برای این کار طراحی شدن. نقطه ضعف فنیش اینه که قابلیت‌های agentic اون به اندازه بخش retrieval توسعه پیدا نکرده. اگه بخواید یک ایجنت با منطق پیچیده و ابزارهای متنوع بسازید، ممکنه معماری LlamaIndex محدودتون کنه.

در مورد Haystack باید گفت که یک فریمورک پایپ‌لاین-محور (pipeline-centric) هست. شما یک Pipeline از Node های مختلف می‌سازید که هرکدوم یک وظیفه مشخص دارن. این معماری ماژولار و شفاف، دیباگ کردن رو ساده می‌کنه. اما برای ساخت ایجنت‌های پیچیده که نیاز به حلقه‌های منطقی (reasoning loops) و مدیریت حافظه مکالمه دارن، Haystack ابزارهای آماده کمتری ارائه می‌ده و باید منطق رو به صورت سفارشی در Node های خودتون پیاده‌سازی کنید.

فریمورک‌هایی مثل CrewAI و AutoGen یک پارادایم سطح بالاتر برای سیستم‌های چند-ایجتی (multi-agent systems) ارائه می‌دن. مشکل فنی این رویکرد، نبود observability و کنترل دقیق روی تعاملات بین ایجنت‌هاست. وقتی چندین ایجنت با هم شروع به کار می‌کنن، فضای حالت (state space) سیستم به شدت پیچیده می‌شه و دیباگ کردن اینکه چرا یک ایجنت تصمیم اشتباهی گرفته، تقریباً غیرممکنه. این‌ها بیشتر برای کارهای تحقیقاتی و اتوماسیون‌های خاص مناسبن تا اپلیکیشن‌های پروداکشن که نیاز به پایداری و رفتار قابل پیش‌بینی دارن.

پلتفرم‌های low-code مثل Langflow و Dify.ai برای پروتوتایپینگ سریع عالین، ولی از نظر مهندسی نرم‌افزار مشکلات جدی دارن. بزرگترین مشکل، عدم سازگاری با فرآیندهای استاندارد CI/CD و version control هست. مدیریت تغییرات، تست‌نویسی و همکاری تیمی روی یک فلو-چارت گرافیکی بسیار سخت‌تر از کد هست. این ابزارها برای رسیدن به پیچیدگی‌های دنیای واقعی، مقیاس‌پذیر نیستن.

در نهایت، ابزارهای تخصصی و مینیمال هم جایگاه خودشون رو دارن. Vanna فقط برای Text-to-SQL طراحی شده و معماریش برای همین کار بهینه شده. txtai و smol-agents هم فلسفه مینیمالیسم دارن. چالش فنی smol-agents عدم پشتیبانی نیتیو از async هست که برای ساخت اپلیکیشن‌های I/O-bound مقیاس‌پذیر یک محدودیت جدیه.

به نظر من تنها راه معقول برای ساختن یه اپلیکیشن جدی و قابل نگهداری، استفاده مستقیم از OpenAI SDK و ساختن منطق کار روی پایه‌های مهندسی نرم‌افزار واقعیه. بقیه‌ی این فریمورک‌ها یا اسباب‌بازی هستن، یا تله‌های بهره‌وری که فقط technical debt تولید می‌کنن. گول "سادگی پیاده سازی" رو نخورید. هیچ میانبری وجود نداره. یا کار رو درست و اصولی انجام میدی، یا چند ماه دیگه در حال بازنویسی کامل پروژه‌ای هستی که تو باتلاق یه فریمورک پر از هایپ گیر کرده.

🛠 Join @LLMEngers Community