GraphRAG و Agentic RAG؛ کدام پیچیدگی واقعاً لازم است؟

نام‌های تازه در معماری RAG زیادند، اما پرسش اجرایی ساده‌تر است: کدام خطای فعلی را می‌خواهیم برطرف کنیم؟ اگر یک بند مشخص از یک سند پیدا نمی‌شود، ساخت گراف دانش احتمالاً نخستین پاسخ نیست. اگر سؤال دربارهٔ ارتباط چند پروژه و علت‌های مشترک در صدها گزارش است، بازیابی چند قطعهٔ شبیه به سؤال هم شاید کافی نباشد.

GraphRAG، روش‌های عامل‌محور و بازیابی اصلاحی، هر کدام بخشی از این فاصله را هدف می‌گیرند. در این مقاله، آن‌ها را بر اساس نوع سؤال، مسیر اجرا و هزینهٔ نگهداری مقایسه می‌کنیم. هدف، انتخاب ابزار پیچیده‌تر نیست؛ پیدا کردن کمترین معماری‌ای است که مسئلهٔ واقعی را با کیفیت قابل سنجش حل کند.

ابتدا سؤال محلی و سؤال سراسری را جدا کنید

یک سؤال محلی مانند «محدودیت این بند قرارداد چیست؟» معمولاً شاهدی محدود و نسبتاً مشخص دارد. سؤال سراسری مانند «چه موضوع‌هایی در گزارش‌های این فصل بیشتر تکرار شده‌اند؟» به پوشش گسترده‌تر نیاز دارد. در حالت دوم، نزدیک‌ترین قطعه‌ها ممکن است فقط چند نمونهٔ مشابه را پیدا کنند و تصویر مجموعه را نشان ندهند.

پژوهش GraphRAG مایکروسافت، از گراف موجودیت‌ها و خلاصه‌های اجتماع‌ها برای پاسخ‌گوییِ مبتنی بر خلاصه‌سازی سراسری استفاده می‌کند. این روش، مسئله‌ای فراتر از یافتن نزدیک‌ترین متن را هدف می‌گیرد. ۱ نتیجهٔ اجرایی این نیست که گراف همیشه بهتر است؛ باید ببینیم سؤال‌های پروژه واقعاً به روابط و ساختار کل مجموعه نیاز دارند یا نه.

ساخت گراف فقط اضافه کردن یک پایگاه داده نیست

گراف به تعریف موجودیت، رابطه و روش اتصال اشاره‌های مختلف نیاز دارد. «شرکت آلفا» و نام کوتاه همان شرکت ممکن است در سندها متفاوت نوشته شوند. اگر یک موجودیت چندبار ساخته شود یا دو موجودیت متفاوت ادغام شوند، مسیر استدلال نیز تحت تأثیر قرار می‌گیرد. بنابراین کیفیت استخراج و رفع ابهام، بخشی از مسئله است.

همچنین رابطه باید به شاهد اصلی برگردد. نمایش یک اتصال میان دو گره، بدون سند پشتیبان، برای بررسی یک پاسخ کافی نیست. در سناریوی تحلیل پروژه، کاربر باید بداند ارتباط «پروژهٔ الف به تأمین‌کنندهٔ ب وابسته است» از کدام گزارش و کدام نسخه آمده است. گراف نباید زنجیره‌ای از ادعاهای بی‌منبع بسازد.

یک سناریوی طراحی: تحلیل ریسک میان چند پروژه

فرض کنید سازمان، گزارش‌های وضعیت پروژه، صورت‌جلسه و یادداشت‌های ریسک دارد. سؤال این است: «کدام پروژه‌ها از یک وابستگی مشترک تأثیر می‌گیرند؟» پیدا کردن یک گزارش مرتبط کافی نیست؛ باید اشاره‌های مربوط به پروژه‌ها، وابستگی و وضعیت زمانی آن‌ها کنار هم قرار بگیرند.

یک طراحی قابل آزمایش می‌تواند دو مسیر داشته باشد: بازیابی اسنادی برای یافتن شاهدهای دقیق و ساختار رابطه‌ای برای پیمودن ارتباط‌ها. نتیجه به‌جای جمله‌ای کلی، فهرست پروژه‌ها، نوع وابستگی و سند پشتیبان را نشان می‌دهد. اگر رابطه فقط در یک گزارش قدیمی آمده و در گزارش جدید حذف شده باشد، وضعیت زمانی باید در پاسخ دیده شود.

برای سنجش، سؤال‌هایی بسازید که پاسخشان در یک سند است، سؤال‌هایی با دو شاهد و سؤال‌های نیازمند پوشش گسترده. اگر گراف فقط در گروه سوم کمک می‌کند، شاید همان گروه را به مسیر گرافی بفرستیم و بقیه را با روش ساده‌تر پاسخ دهیم. این تفکیک می‌تواند پیچیدگی و هزینه را محدود کند.

LightRAG و RAPTOR را با GraphRAG یکی ندانید

LightRAG، در پژوهش معرفی‌کنندهٔ خود، استفاده از ساختار گراف و بازیابی در دو سطح را بررسی می‌کند. تفاوت جزئیات استخراج، به‌روزرسانی و مسیر پرسش‌وجو مهم است؛ صرف مشترک بودن واژهٔ گراف، به معنی یکسان بودن رفتار دو روش نیست. ۲ پیش از انتخاب، واحد بازیابی و نحوهٔ بازگشت به شواهد را بررسی کنید.

RAPTOR مسیر دیگری دارد: خوشه‌بندی و خلاصه‌سازی بازگشتی برای ساخت یک ساختار درختی از متن‌ها. این ساختار، نمایی در چند سطح انتزاع فراهم می‌کند. ۳ در ارزیابی چنین روشی، باید پرسید خلاصهٔ بالاتر کدام جزئیات را حذف کرده و آیا پاسخ نهایی هنوز به شواهد اصلی قابل اتصال است یا نه.

DRIFT چگونه جست‌وجوی محلی و سراسری را نزدیک می‌کند؟

در مستندات GraphRAG، مسیر DRIFT با ترکیب ویژگی‌های جست‌وجوی محلی و سراسری معرفی می‌شود. ایده این است که زمینهٔ گسترده‌تر بتواند به گسترش پرسش و دنبال کردن جزئیات مرتبط کمک کند. ۶ این یک مسیر مشخص در خانوادهٔ GraphRAG است و باید رفتار، تنظیمات و هزینهٔ آن را از توضیح کلی «جست‌وجو در گراف» جدا کرد.

برای تصمیم اجرایی، سؤال‌هایی را انتخاب کنید که نه با یک قطعه جواب می‌گیرند و نه فقط خلاصهٔ کلی مجموعه را می‌خواهند. سپس پوشش شواهد، تعداد گام و هزینه را با مسیرهای محلی و سراسریِ خط مبنا مقایسه کنید. وجود یک نام تازه، معیارِ کافی برای جایگزین کردن مسیر فعلی نیست.

Agentic RAG چه چیزی به مسیر اضافه می‌کند؟

در یک مسیر ثابت، ترتیب گام‌ها از پیش مشخص است: بازیابی، انتخاب و پاسخ. در روش عامل‌محور، سامانه ممکن است براساس سؤال تصمیم بگیرد کدام ابزار را به کار ببرد، به منبع دیگری برود یا یک پرسش فرعی بسازد. این انعطاف برای سؤال‌های چندمرحله‌ای و منابع متفاوت جذاب است، اما قابلیت انتخاب باید دامنه و هزینهٔ مشخص داشته باشد.

برای مثال، پاسخ به «وضعیت خدمت این مشتری و آخرین شرط قراردادش چیست؟» ممکن است به یک پرس‌وجوی ساختاریافته و یک سند متنی نیاز داشته باشد. عامل می‌تواند این دو مسیر را هماهنگ کند. اما باید روشن باشد ابزار به دادهٔ کدام مشتری دسترسی دارد، چند بار فراخوانی می‌شود و چه زمانی باید اعلام کند شواهد کافی نیستند.

به‌جای اعتماد به یک حلقهٔ باز، سقف تعداد گام، زمان، هزینه و دامنهٔ ابزار را بنویسید. برای عملیات دارای اثر بیرونی، مسیر تأیید مناسب تعریف کنید. تولید یک پیش‌نویس پاسخ با تغییر یک رکورد یا ارسال پیام به مشتری، از نظر اختیار یکسان نیست.

Self-RAG و Corrective RAG چه تفاوتی دارند؟

Self-RAG در پژوهش خود، یادگیری برای بازیابی، تولید و نقد را با سازوکار بازاندیشی بررسی می‌کند. ۴ Corrective RAG نیز کیفیت نتیجهٔ بازیابی را ارزیابی می‌کند و برای بازیابی ناکافی، مسیر اصلاح در نظر می‌گیرد. ۵ این دو را نباید صرفاً نام دیگری برای افزودن یک دستور «پاسخ را بررسی کن» دانست؛ روش پژوهشی، آموزش و اجزای مشخص خود را دارد.

در محصول عملی، می‌توان از ایدهٔ تشخیص شواهد ناکافی الهام گرفت، اما باید ادعای پیاده‌سازی دقیق یک پژوهش را از طراحی سفارشی جدا کرد. اگر سامانه فقط سؤال را بازنویسی و دوباره جست‌وجو می‌کند، بهتر است همین رفتار روشن توصیف شود. نام پژوهش نباید جای مستند کردن مسیر واقعی را بگیرد.

یک جدول تصمیم برای انتخاب مسیر

این جدول دستور خرید ابزار نیست. ابتدا باید خط مبنا و سؤال‌های نماینده داشته باشیم. سپس هر مسیر را در همان گروهی که برایش طراحی شده آزمایش کنیم. مقایسهٔ یک روش پیچیده روی سؤال‌های مناسب خودش با یک روش ساده روی سؤال‌های نامناسب، تصمیم قابل اتکایی نمی‌سازد.

ارزیابی باید مسیر را هم ببیند

در یک سامانهٔ چندمرحله‌ای، فقط متن آخر را ذخیره نکنید. پرسش‌های فرعی، ابزار انتخاب‌شده، شواهد برگشتی و دلیل توقف برای تشخیص خطا مهم‌اند. ممکن است پاسخ آخر درست باشد، اما سامانه برای رسیدن به آن چندین فراخوانی غیرضروری کرده باشد. ممکن است نیز عامل به پاسخ درست از مسیر منبع نامجاز رسیده باشد.

گروهی از آزمون‌ها را برای شکست در نظر بگیرید: منبع قطع است، یک رابطه قدیمی است، ابزار خروجی ناقص دارد یا هیچ شاهدی برای فرض کاربر وجود ندارد. رفتار مناسب در این وضعیت‌ها باید تعریف شود. یک مسیر قابل کنترل که به‌موقع متوقف می‌شود، برای بهره‌برداری از یک مسیر پرادعا و غیرقابل پیش‌بینی مناسب‌تر است.

یک جهت پژوهشی تازه در سال ۲۰۲۶

در A-RAG، منتشرشده در فوریهٔ ۲۰۲۶، عامل از رابط‌های سلسله‌مراتبی برای جست‌وجوی واژگانی، جست‌وجوی معنایی و خواندن قطعه استفاده می‌کند. ایدهٔ اصلی این است که عامل فقط مصرف‌کنندهٔ یک فهرست ثابت نباشد و بتواند نوع و ریزدانگی بازیابی را انتخاب کند. برای تصمیم اجرایی، بپرسید آیا این اختیار تازه، یک خطای مشخص در مجموعهٔ سؤال‌های شما را برطرف می‌کند و آیا هزینهٔ مسیر آن قابل کنترل است. ۷

این مقاله جهت آزمایش را پیشنهاد می‌کند. پیش از ورود به محصول، همان پرسش‌ها را با مسیر ثابت ساده‌تر نیز اجرا کنید، سقف بودجه بگذارید و ثبت کنید کدام تصمیم عامل به شاهد تازه و مفید منجر شده است. اگر یک مسیر ثابت، کیفیت مشابهی با هزینهٔ کمتر دارد، افزودن عامل هنوز توجیه اجرایی پیدا نکرده است.

با مسئله رشد کنید، نه با فهرست اصطلاح‌ها

شروع پیشنهادی، تهیهٔ سؤال‌های واقعی و طبقه‌بندی آن‌هاست: محلی، رابطه‌ای، سراسری و چندابزاری. برای هر گروه، شاهد و معیار پذیرش بنویسید. سپس ساده‌ترین مسیر را بسازید و فقط در جایی که خطا روشن است، پیچیدگی اضافه کنید.

اگر با گراف پیش می‌روید، نگهداری و نسخهٔ رابطه را جدی بگیرید. اگر با عامل پیش می‌روید، اختیار و توقف را محدود کنید. اگر خلاصه‌های چندسطحی می‌سازید، بازگشت به متن اصلی را حفظ کنید. ارزش این خانوادهٔ روش‌ها زمانی روشن می‌شود که بتوان نشان داد کدام سؤال را بهتر و با چه هزینه‌ای پاسخ داده‌اند.