مدیریت شکست در Agentic RAG؛ اصلاح جستجو برای پرسش‌های پیچیده

مدیریت شکست در Agentic RAG وقتی اهمیت پیدا می‌کند که پرسش‌ها پیچیده می‌شوند. بعضی پرسش‌ها با یک جستجو جواب نمی‌گیرند. کاربر ممکن است هم پیش‌نیاز یک دوره را بخواهد و هم بداند آیا با برنامه‌ی زمانی‌اش سازگار است. ایجنت می‌تواند این پرسش را به چند جستجوی کوچک‌تر تقسیم کند؛ اما همین آزادی دو خطر تازه هم می‌آورد.

در قسمت پانزدهم با Agentic RAG در smolagents آشنا شدیم. در این قسمت از مجموعه‌ی آموزش هوش مصنوعی تخته سبز، روی روی دیگر سکه تمرکز می‌کنیم: وقتی جستجو شکست می‌خورد چه باید کرد؟ ایجنت کی باید دوباره تلاش کند، کی باید متوقف شود و کی باید کار را به انسان بسپارد؟

Agentic RAG؛ مالکیت فرایند استدلال

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

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

مثالی از استدلال مستقل

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

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

حلقه‌ی Agentic RAG

Agentic RAG بر یک الگوی حلقه‌ای تکیه دارد. هدف کاربر به مدل داده می‌شود. اگر مدل کمبود اطلاعات یا دستور مبهم تشخیص دهد، ابزاری را صدا می‌زند؛ مثلاً جستجوی ترکیبی در پایگاه برداری یا پرس‌وجو از پایگاه داده. بعد داده‌ی برگشتی را ارزیابی می‌کند.

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

حلقه‌ی سازنده و بازرس

این سبک را گاهی الگوی «سازنده و بازرس» می‌نامند. یک مرحله پاسخ یا پرس‌وجو می‌سازد و مرحله‌ی دیگر آن را بررسی می‌کند. این رفت‌وبرگشت دقت را بالا می‌برد؛ به‌خصوص در پرس‌وجو از پایگاه داده‌ی ساختاریافته، جایی که یک پرس‌وجوی SQL نادرست ممکن است نتیجه‌ی خالی یا اشتباه بدهد.

نمودار زیر حلقه‌ای را نشان می‌دهد که در این مقاله می‌سازیم؛ با دو نقطه‌ی کنترل برای مدیریت شکست.

مدیریت شکست در Agentic RAG

خودمختاری Agentic RAG با سازوکارهای اصلاح خودکار همراه است. وقتی سیستم به بن‌بست می‌رسد، مثلاً اسناد نامرتبط بازیابی می‌کند یا با پرسش بدشکل روبه‌رو می‌شود، سه راه دارد.

سه راه برای برخورد با بن‌بست

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

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

دو شکست که باید کنترل شوند

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

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

پیاده‌سازی حلقه با کنترل شکست

کد زیر یک حلقه‌ی ساده‌ی Agentic RAG برای مقایسه‌ی دو دوره است. به دو نقطه‌ی کنترل دقت کنید: سقف جستجو و بررسی شواهد. تابع‌های search، rewrite و is_relevant را ایجنت یا کد شما پیاده می‌کند:

MAX_SEARCHES = 4

def answer_comparison(question, parts, search, rewrite, is_relevant):
    evidence, searches = {}, 0
    for part in parts:  # مثلاً «پیش‌نیاز دوره‌ی الف»، «مدت دوره‌ی ب»
        query = part
        while searches < MAX_SEARCHES:
            searches += 1
            docs = [d for d in search(query) if is_relevant(part, d)]
            if docs:
                evidence[part] = docs
                break
            query = rewrite(part, query)  # بازنویسی و تلاش دوباره
    missing = [p for p in parts if p not in evidence]
    if missing:
        return {"status": "needs_human", "missing": missing, "found": evidence}
    return {"status": "ok", "evidence": evidence}

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

سنجش ارتباط سند

is_relevant را می‌توان به چند شکل پیاده کرد. ساده‌ترین راه، حداقل شباهت برداری است؛ همان کاری که در قسمت RAG کردیم. راه دقیق‌تر، پرسیدن از یک مدل کوچک است: «آیا این سند به این پرسش مشخص پاسخ می‌دهد؟ فقط بله یا خیر».

در پرسش‌های مقایسه‌ای، یک بررسی دیگر هم لازم است؛ اینکه سند به همان دوره‌ی مورد نظر مربوط باشد. سندی درباره‌ی پیش‌نیازهای «پایتون مقدماتی» برای پرسش درباره‌ی «پایتون پیشرفته» مرتبط به نظر می‌رسد، اما شاهد درستی نیست.

مرزها، حاکمیت و اعتماد

با وجود همه‌ی این خودمختاری، Agentic RAG معادل هوش مصنوعی عمومی نیست. توانایی‌هایش به ابزارها، منابع داده و سیاست‌هایی محدود است که توسعه‌دهنده در اختیارش گذاشته است. نمی‌تواند خودش ابزار تازه بسازد یا از مرز حوزه‌اش بیرون برود.

کجا Agentic RAG می‌درخشد؟

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

شفافیت و نظارت انسانی

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

نظارت انسانی هم در کارهای حساس ضروری است. Agentic RAG جای قضاوت انسان را در تصمیم‌های مهم نمی‌گیرد؛ گزینه‌های مستند و بررسی‌شده را پیش روی انسان می‌گذارد. جدول زیر نشان می‌دهد هر وضعیت چه خروجی‌ای باید داشته باشد.

سناریوی عملی؛ مقایسه‌ی دو دوره

کاربری می‌خواهد دو دوره را از نظر پیش‌نیاز، سرفصل و زمان لازم مقایسه کند. ورودی آزمون یک پرسش ترکیبی و اسناد جداگانه‌ی هر دوره است. یک نمونه‌ی ناقص هم بگذارید؛ مثلاً دوره‌ای که سندش مدت دوره را ذکر نکرده است.

اقدام و معیار پذیرش

اقدام مورد بررسی سه مرحله دارد: بازیابی مرحله‌ای برای هر بخش پرسش، بررسی کمبود شواهد و ترکیب پاسخ همراه ارجاع. خروجی هر مرحله را جدا ثبت کنید تا مسیر بازیابی قابل بررسی باشد.

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

نمونه‌ی شکست

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

نتیجه‌ی مورد انتظار را پیش از اجرا بنویسید. اگر نسخه‌ی جدیدی ظاهراً بهتر بود، همین دو نمونه را دوباره بسنجید.

تمرین عملی؛ پاسخ مقایسه‌ای با مسیر بازیابی

خروجی این تمرین یک نمونه پاسخ مقایسه‌ای است که مسیر بازیابی‌اش قابل بررسی باشد:

1. حلقه‌ی بالا را با تابع جستجوی قسمت‌های قبل و یک is_relevant ساده پیاده کنید.
2. پرسش مقایسه‌ی دو دوره را اجرا کنید و همه‌ی جستجوها، بازنویسی‌ها و اسناد پذیرفته‌شده را ثبت کنید.
3. دو نمونه‌ی شکست را اجرا کنید و خروجی «نیاز به انسان» را بررسی کنید.

مشخص کنید کدام بخش را واقعاً اجرا کرده‌اید و کدام هنوز فرض است.

سخن پایانی

Agentic RAG مالکیت فرایند استدلال را به مدل می‌دهد؛ جستجو، ارزیابی، اصلاح و تکرار تا رسیدن به شواهد کافی. اما همین آزادی به کنترل نیاز دارد. مدیریت شکست در Agentic RAG با سه ابزار ساده ممکن می‌شود: سقف تعداد جستجو، بررسی صریح ارتباط هر سند با هر ادعا، و ارجاع به انسان وقتی شواهد کافی نیست. ایجنتی که بداند کی متوقف شود، قابل‌اعتمادتر از ایجنتی است که همیشه جواب می‌دهد.

در قسمت بعد طراحی تأیید انسانی را می‌بینیم؛ توقف، بازبینی و ادامه‌ی امن کار.

این آموزش بر پایه‌ی درس Agentic RAG از مجموعه‌ی آزاد AI Agents for Beginners مایکروسافت (مجوز MIT) به فارسی بازنویسی و تکمیل شده است.