سیستمهای عاملی (Agentic Systems) معمولاً دو وظیفه اصلی دارند: ایجاد زمینه (Context) و سپس استفاده از آن زمینه برای تولید پاسخ یا اقدام. اما بسیاری از شکستهایی که شبیه مشکلات مدلهای زبانی بزرگ (LLM) به نظر میرسند، در واقع از مرحله ایجاد زمینه شروع میشوند. به عبارت دیگر، پاسخی که LLM میدهد محدود به زمینهای است که دریافت کرده یا از طریق فراخوانی ابزار پیدا میکند. اگر مدل عامل نتواند منابع درست را بازیابی کند، بهبود خود مدل تولید، تأثیر چندانی بر عملکرد کلی سیستم نخواهد داشت.
اهمیت کیفیت بازیابی در معماری عاملها
برای درک این موضوع، مثالی از یک مشتری به نام Specstory را در نظر بگیرید. این پلتفرم میخواست به کاربران امکان پرسش از تاریخچه عامل را بدهد؛ مثلاً چرا تیم توسعه، کتابخانه Authlib را برای احراز هویت انتخاب کرده و چه جایگزینهایی را در نظر گرفته است. برای پاسخ به این سؤال، ربات گفتگو باید مکالمات، تصمیمات و مصالحههای قبلی را از میان مجموعه بزرگی از جلسات کدنویسی استخراج کند. مدل و پرامپت سیستم فقط پس از آن که آن نوبتهای گفتگو بازیابی و در زمینه قرار گرفتند، میتوانند کمک کنند.
«بسیاری از شکستهایی که شبیه مشکلات LLM به نظر میرسند، از مرحله ایجاد زمینه شروع میشوند.»
اگر سیستم بازیابی، قطعات پیادهسازی را بالاتر از بحثهایی که تیم در آن جایگزینها را سنجیده رتبهبندی کند، عامل همچنان میتواند پاسخی مطمئن اما نادرست تولید کند. مثلاً ممکن است کدی پیدا کند که Authlib را وارد کرده و چند نظر داخلی داشته باشد، سپس تصمیم را بر اساس شواهد پیادهسازی توضیح دهد، در حالی که بحث اصلی در مورد مصالحهها نادیده گرفته شده است.
شکستهای بازیابی؛ تقلید از اشکالات تولید
همین الگو در یک بررسی اپراتور AnkiHub در انجمن خصوصی مشاهده شد. درخواست کمک برای مطالعه بر اساس اسلایدهای سخنرانی فقط زمانی کار میکند که فراخوانیهای ابزار عامل، فلشکارتهای درست را بازیابی کنند. بخش سخت، پیدا کردن کارتهای مرتبط نیست؛ یک سخنرانی در مورد عملکرد قلب ممکن است با صدها کارت مطابقت داشته باشد. رتبهبندی تعیین میکند که آیا کارتهای اصلی وارد زمینه میشوند یا سیستم مجبور است top_k را افزایش داده و پرامپت را با دادههای بیربط پر کند.
| علامت | علت بازیابی |
|---|---|
| توهم (Hallucination) | منبع پاسخ هرگز وارد زمینه نشده است. |
| پوسیدگی زمینه (Context Rot) | فراخوانی کم باعث میشود top_k بالا برود و نتایج پر سر و صدا پنجره زمینه را پر کنند. |
| تأخیر (Latency) | بازیابی ضعیف منجر به فراخوانی ابزار بیشتر، مجموعههای کاندید بزرگتر و پنجرههای زمینه بزرگتر میشود. |
یک مدل بهتر به استدلال و نوشتن کمک میکند، اما نمیتواند بدون زمینه درست پاسخ بهتری بدهد. این اصل در ارزیابی Mixedbread OfficeQA-Pro نیز تأیید شده است. OfficeQA-Pro از ۸۹۰۰۰ صفحه اسناد مالی، جداول متراکم، پیدیافهای اسکن شده و سوالاتی که نیاز به استدلال بین اسناد دارند استفاده میکند. دادن ابزارهای جستجوی بهتر به Codex باعث کاهش فراخوانی ابزار و بهبود کیفیت پاسخ شد.
ابزارهای جستجوی سنتی کافی نیستند
ابزارهای متن ساده مانند grep و rg روی فایلهای کد مسطح تا حدی کار میکنند. اما زمانی که زمینه در پیدیافها، جداول، تاریخچههای گفتگو، ورودیهای چندوجهی، نتایج وب و دادههای مجاز قرار دارد، این ابزارها کارایی ندارند. در چنین مواردی، عامل به یک سیستم بازیابی نیاز دارد که بتواند اصطلاحات دقیق، معنا، فراداده، مجوزها و کیفیت رتبهبندی را ترکیب کند. برای مطالعه بیشتر درباره معماری عاملها، میتوانید به ویکیپدیای عامل هوشمند مراجعه کنید.
بازیابی نیاز به ردیابی و ارزیابی دارد
هنگامی که بازیابی وارد معماری میشود، سوال بعدی این است که آیا اطلاعات درست را پیدا میکند. برای این کار به ردیابی (Traces) و ارزیابی (Evals) نیاز دارید. برای هر مرحله بازیابی، حداقل ردیابی شامل ورودی، خروجی، و راهی برای برچسبگذاری اینکه آیا هر خروجی مرتبط بوده است یا خیر. برای یک عامل کدنویسی که از rg استفاده میکند، ورودی دستور است، خروجی قطعات برگشتی است، و برچسب نشان میدهد کدام قطعات مفید بودند، کدام نویز بودند، و کدام فایلهای مرتبط گم شده بودند.
برای اطلاعات بیشتر در مورد تکنیکهای بازیابی اطلاعات، مقاله بازیابی اطلاعات در ویکیپدیا را مطالعه کنید.
جمعبندی
کیفیت بازیابی به یکی از چالشهای تعیینکننده در معماری عاملهای هوش مصنوعی تبدیل شده است. شکست در این مرحله میتواند به اشکالاتی مانند توهم، تأخیر و پوسیدگی زمینه منجر شود که اغلب به اشتباه به مدل زبانی نسبت داده میشوند. سرمایهگذاری بر روی ابزارهای بازیابی پیشرفته، رتبهبندی هوشمند و ردیابی مداوم، کلید دستیابی به عاملهای قابل اعتماد و کارآمد است.
