تیپ #۳۴
بازیابی پویا: ایجنت خودش تصمیم می‌گیرد چه زمانی جست‌وجو کند
در روش کلاسیک، هر پرسش کاربر یک جست‌وجوی اجباری در پایگاه دانش را فعال می‌کند، حتی وقتی مدل خودش پاسخ را می‌داند. در رویکرد ایجنتی، بازیابی به یک ابزار در اختیار ایجنت تبدیل می‌شود و خودش تشخیص می‌دهد چه زمانی جست‌وجو لازم است، چه عبارتی بنویسد و آیا نتایج برگشته کافی هستند یا نه 🧭. نتیجه‌اش این است که توکن و زمان کمتری هدر می‌رود و در عوض ایجنت می‌تواند چند مرحله جست‌وجو را زنجیره کند و پرس‌وجوی ناموفق را اصلاح کند.
توضیح کامل‌تر
در معماری کلاسیک بازیابی افزوده (RAG) یک خط لوله ثابت داریم: پرسش کاربر همیشه به یک جست‌وجوی برداری می‌رود و چند سند بازیابی‌شده به مدل تزریق می‌شود. مشکل اینجاست که برای پرسش‌هایی مثل «سلام، می‌تونی کمکم کنی؟» یا سؤال‌هایی که پاسخشان از قبل در حافظه گفتگو هست، این جست‌وجو فقط تأخیر و هزینه اضافه می‌سازد و حتی می‌تواند با آوردن اسناد بی‌ربط، کیفیت پاسخ را پایین بیاورد. در بازیابی ایجنتی، عمل بازیابی به‌صورت یک ابزار با ورودی مشخص، مثلاً پرس‌وجو و فیلتر، به مدل معرفی می‌شود و مدل با فراخوانی تابع تصمیم می‌گیرد چه زمانی آن را صدا بزند. ایجنت می‌تواند پرس‌وجو را بازنویسی کند، نتایج را ارزیابی کند و اگر اسناد کافی نبودند دور دیگری جست‌وجو کند یا سراغ منبع دیگری مثل وب برود. برای اینکه این حلقه از کنترل خارج نشود، سقف تعداد دورها، بودجه توکن و شرط توقف را از قبل تعیین کنید. یک مثال ساده: برای پرسش «قیمت پلن حرفه‌ای چنده؟» ایجنت اول مستندات قیمت‌گذاری را می‌خواند و اگر چیزی پیدا نشد پرس‌وجو را به «تعرفه پلن حرفه‌ای» تغییر می‌دهد، اما برای «ممنون، فهمیدم» هیچ جست‌وجویی انجام نمی‌دهد.
← بازگشت به همهٔ نکته‌های روز