اگر امروز برای استخراج داده‌های پیچیده از اسنادتان به RAG ساده تکیه می‌کنید، احتمالاً با نرخ خطای بالایی دست‌وپنجه نرم می‌کنید. طبق گزارش منتشرشده در ۴ اکتبر ۲۰۲۶، معماری‌های عامل‌محور (Agentic) توانسته‌اند صحت پاسخ‌ها را در محک Public-100 از ۴۱٪ به ۷۲٪ برسانند. این شکاف عمیق ثابت می‌کند که بازیابی ساده تنها می‌تواند شواهد را «پیدا» کند، اما برای «بررسی» و «محاسبه» واقعی داده‌ها، به یک رویکرد عامل‌محور نیاز است.
زمینه و بستر بازیابی
بسیاری از سامانه‌های فعلی از یک خط لوله‌ی خطی استفاده می‌کنند: کاربر می‌پرسد، سیستم سند را می‌یابد و مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — متن را خلاصه می‌کند. این روش برای جست‌وجوهای ساده عالی است، اما وقتی پاسخ نیاز به زنجیره‌ای از عملیات دارد، شکست می‌خورد. در واقع، بسیاری از نقص‌های سیستم‌های فعلی پیش از آنکه داده‌ها به مدل زبانی برسند، در ساختار خط لوله‌ی بازیابی رخ می‌دهند.
بازیابی (Retrieval) شواهد را می‌یابد، اما تحقیق (Investigation) تصمیم می‌گیرد که با آن شواهد چه کند. وقتی یک پرس‌وجو در ظاهر ساده به نظر می‌رسد اما برای پاسخ به آن بیش از بازیابی چند سند نیاز است، یک خط لوله‌ی استاندارد ناکافی خواهد بود. این چالش‌ها اغلب ریشه در لایه ورود داده‌ها دارند که به عنوان یک گلوگاه پنهان، کیفیت خروجی نهایی را تحت تأثیر قرار می‌دهد.
برای مثال، تصور کنید می‌خواهید بفهمید در المپیک زمستانی ۲۰۱۸، چند رویداد بیاتلون بیش از ۷۳ شرکت‌کننده داشتند. یک سیستم RAG معمولی ممکن است اسناد درست را پیدا کند اما در شمارش دقیق آن‌ها دچار مشکل شود. چنین سیستمی باید ابتدا اسناد رویدادهای المپیک را بیابد، سپس رویدادهای بیاتلون را شناسایی کند، تعداد شرکت‌کنندگان هر یک را استخراج نماید و در نهایت رویدادهای واجد شرایط را بشمارد.
بر اساس مستندات این پروژه، در تست‌های انجام‌شده، سیستم‌های بازیابی ترکیبی (Hybrid) اسناد مرتبط را یافتند اما پاسخ نهایی متناقض بود؛ در یک اجرا، مدل زبانی عدد ۴ را برگرداند و در اجرای دیگر، با وجود شناسایی درست ۵ رویداد، نتیجه را ۶ اعلام کرد. در حالی که پاسخ درست ۵ بود. این موضوع ثابت کرد که مشکل از بازیابی نبود، بلکه در محاسبه و تفسیر شواهد رخ داد. این نوع خطاها دقیقاً همان نقاطی هستند که استفاده از جریان‌های داده‌ای پنج‌مرحله‌ای می‌تواند با کاهش توهمات، دقت سیستم را افزایش دهد.
جزئیات فنی Agentic GraphRAG
برای حل این چالش، پیاده‌سازی Agentic GraphRAG یک لایه‌ی مسیریابی و اجرا اضافه کرده است که طبق سلسله‌مراتب زیر عمل می‌کند:
- مسیریاب پرس‌وجو (Question Router): دسته‌بندی سوالات به گروه‌هایی مثل جست‌وجوی ساده (Lookup)، تجمیعی (Aggregation)، زمانی (Temporal)، برترین‌ها (Superlative) یا چندگامی (Multi-hop).
- عامل عامل‌محور (Agentic Agent): مدیریت عملیات در حالت‌های مختلف. در پیکربندی فعلی، حالت «Auto» به حالت «Planned» تبدیل می‌شود.
- برنامه‌ریز و اعتبارسنج (Planner & Validator): برنامه‌ریز یک نقشه اجرایی ساختاریافته ایجاد می‌کند و اعتبارسنج بررسی می‌کند که آیا این نقشه معتبر است یا خیر. اگر نقشه نامعتبر باشد، سیستم به حالت «Reactive» (واکنشی) بازمی‌گردد.
- مجری (Executor): اجرای برنامه از طریق یک رجیستری ابزار (Tool Registry) که لایه‌ی واسط بین منطق اجرا و ابزارهای واقعی است.
قابلیت‌های رجیستری ابزار
این رجیستری ابزار به جای اجازه دادن به عامل برای اجرای عملیات دلخواه و تصادفی، قابلیت‌های مشخص و اعتبارسنج‌شده‌ای را مدیریت و توزیع می‌کند:
- جست‌وجوی معنایی (Similarity search) و جست‌وجوی ترکیبی (Hybrid search).
- بازیابی ساختاری از گراف و تجمیع ساختاری (Structural aggregation).
- بازیابی مستندات و متون زمینه‌ای (Contextual retrieval).
- تجمیع قطعی (Deterministic aggregation) و سایر ابزارهای ثبت‌شده در گراف.
این معماری به‌ویژه زمانی اهمیت می‌یابد که سیستم در حال انجام یک تحقیق چندمرحله‌ای است.
توازن بین عملکرد و هزینه
اما این جهش عملکردی، بهای سنگینی دارد. طبق ارزیابی‌های Hidden-50، در حالی که صحت Agentic GraphRAG به ۷۲٪ رسید (در مقابل ۵۵٪ برای GraphRAG و ۴۱٪ برای RAG معمولی)، هزینه‌ها به‌صورت تکان‌دهنده‌ای تغییر کرد:
- RAG معمولی: ۱۳,۴۹۶.۴۴ توکن و ۲۲.۹۶ ثانیه برای هر پرس‌وجو.
- GraphRAG: ۱,۲۱۸.۷۷ توکن و ۸.۳۸ ثانیه برای هر پرس‌وجو.
- Agentic GraphRAG: ۶۰,۷۳۷.۵۴ توکن و ۱۰۰.۵۳ ثانیه برای هر پرس‌وجو.
این یعنی سیستم در واقع دقت منطقی را با مصرف شدید توکن (Token) — تکه‌های کوچکی از متن، شبیه برش‌های یک کیک که مدل تکه‌تکه می‌خورد — و زمان استنتاج معاوضه کرده است. رویکرد عامل‌محور به طور قابل توجهی توکن‌های بیشتری مصرف می‌کند و زمان پاسخ‌دهی آن بسیار طولانی‌تر است.
برای توسعه‌دهندگان، این داده‌ها فرض «پیشرفته‌تر همیشه بهتر است» را به چالش می‌کشد. داده‌ها نشان می‌دهند که یک استراتژی لایه‌بندی‌شده (Tiered) پایدارتر است: از ساده‌ترین روش بازیابی ممکن استفاده کنید و تنها زمانی که پیچیدگی پرس‌وجو ایجاب می‌کند، به بررسی‌های عامل‌محور روی آورید.
این رویکرد از «خون‌ریزی توکن‌ها» که در اثر استفاده از عامل‌های سنگین برای کارهای ساده‌ی جست‌وجو رخ می‌دهد، جلوگیری می‌کند و در عین حال دقت بالا را برای تحلیل‌های پیچیده داده‌ها حفظ می‌نماید.
توسعه‌دهندگان اکنون باید لاگ‌های پرس‌وجوی کاربران خود را ارزیابی کنند تا تشخیص دهند چه درصدی از سوالات واقعاً نیاز به بررسی چندگامی دارند و چه درصدی با بازیابی ساده پاسخ داده می‌شوند تا نسبت هزینه به دقت (Cost-to-Accuracy) را بهینه کنند.
گام بعدی شما
- لاگ‌های پرس‌وجوی کاربران خود را تحلیل کنید تا بفهمید چند درصد سوالات واقعاً نیاز به بررسی چندگامی دارند.
- یک سیستم لایه‌بندی‌شده (Tiered) طراحی کنید که ابتدا RAG ساده و در صورت عدم اطمینان، Agentic GraphRAG را فراخوانی کند.
- تأخیر ۱۰۰ ثانیه‌ای را در تجربه کاربری (UX) مدل کنید تا کاربر از انتظار طولانی غافلگیر نشود.
اما داستان سخت‌افزاری این تحول و فشار روی حافظه VRAM حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو