تصور کنید یک عامل هوش مصنوعی نمی‌تواند یک کد خطای نادر یا نام دقیق یک محصول را پیدا کند؛ مشکل در اینجا مدل نیست، بلکه شکست در سیستم بازیابی است. چون مدل نمی‌تواند پاساژی را بازیابی کند که خط لوله بازیابی هرگز آن را فراهم نکرده است، جست‌وجوی برداری خالص همچنان بیشتر شبیه یک نمونهٔ اولیه است تا یک معماری آماده برای تولید. طبق یک راهنمای فنی که در ۲۸ اوت ۲۰۲۶ منتشر شد، یک خط لوله بازیابی ترکیبی (Hybrid Retrieval) متمرکز می‌تواند این شکاف‌ها را پر کند. این رویکرد، بازیابی را به‌جای یک جست‌وجوی ساده بر اساس شباهت، به عنوان یک برنامه پرس‌وجوی ساختاریافته مدیریت می‌کند.
بسیاری از توسعه‌دهندگان در حال حاضر سیستم‌های تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — را با رویکرد «چندزبانه» (Polyglot) می‌سازند. آن‌ها ممکن است از Postgres برای داده‌های کاربر، یک ذخیره‌ساز برداری اختصاصی برای بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که می‌گوید این کلمه همسایه‌ی چه کلمات دیگری است — و Elasticsearch برای جست‌وجوی کلمات کلیدی استفاده کنند. این روش در محیط دمو جواب می‌دهد، اما در مقیاس واقعی، «مالیاتی» سنگین از نظر تأخیر شبکه و ریسک‌های امنیتی ایجاد می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی اتوماسیون زیرساخت‌های دیتاسنتر متا اشاره کردیم، چرخش به سمت پایگاه‌داده‌های متمرکز هوش مصنوعی اجازه می‌دهد این عملیات پیچیده در یک نقطه رخ دهد. این رویکرد متمرکز در واقع تکامل یافته‌ی استراتژی‌های مدیریت حافظه است، مشابه آنچه در بهینه‌سازی حافظه دو لایه برای کاهش تأخیر عامل‌ها مشاهده کردیم.
برای درک این موضوع، سناریوی «جین» را در نظر بگیرید؛ دستیار پژوهشی در شرکت Acme که می‌پرسد: «مقاله Letta درباره تخلیه حافظه چه گفته و چه تفاوتی با توصیه‌های AgentCore دارد؟». این پرسش تمام نقاط ضعف سیستم‌های بازیابی را به چالش می‌کشد. جست‌وجوی برداری ممکن است موضوع کلی «مدیریت حافظه» را پیدا کند اما نام خاص «Letta» را به‌دلیل اینکه مدل‌های برداری به اسامی خاص نادر وزن کمی می‌دهند، نادیده بگیرد. در مقابل، جست‌وجوی کلمات کلیدی «Letta» را می‌یابد اما پاراگرافی درباره «هرس کردن زمینه» (Context Pruning) را پیدا نمی‌کند چون نمی‌داند این عبارت مترادف «تخلیه حافظه» است.
سه حالت بازیابی و نقاط شکست آن‌ها
برای درک خط لوله، باید سه حالت بازیابی و نقاط ضعف هر کدام را بشناسیم:
- بازیابی برداری (Vector Retrieval): بر اساس شباهت معنایی رتبه‌بندی می‌کند. این حالت با بازنویسی‌ها، مترادف‌ها و تطابق‌های مفهومی (مثلاً پیوند دادن «تخلیه حافظه» به «هرس پیام‌های قدیمی») عالی عمل می‌کند. نقطه شکست آن «دقت در جزئیات» (Specificity) است؛ توکن‌های نادر، شماره نسخه‌ها و نام محصولات در بردار کلی موضوع گم می‌شوند. اگر از یک ایندکس برداری درباره «Letta» بپرسید، او می‌شنود «مقاله‌ای درباره حافظه عامل»، که نیمی از کل مجموعه داده را توصیف می‌کند. در این راستا، استفاده از مدل‌های Multi-Vector می‌تواند به جایگزینی برای متدهای سنتی فشرده‌سازی در RAG باشد تا جزئیات بیشتری حفظ شوند.
- بازیابی لغت‌نامه‌ای (Lexical Retrieval): با استفاده از امتیازات مرتبط Oracle Text، تطابق دقیق کلمات را بررسی می‌کند. این حالت برای شناسه‌های دقیق، قطعات کد و پیام‌های خطای عیناً نقل‌شده (مثل ORA-51805) بی‌نقص است. نقطه شکست آن «تغییر واژگان» (Vocabulary Drift) است؛ اگر کاربر بگوید «تخلیه» اما در سند عبارت «هرس کردن» آمده باشد، چیزی پیدا نمی‌شود.
- بازیابی متادیتا (Metadata Retrieval): رتبه‌بندی نمی‌کند، بلکه فیلتر می‌کند. این حالت جست‌وجو را بر اساس محدوده، چرخه حیات، زمان، منبع و نوع محدود می‌کند. این تنها حالتی است که می‌تواند مرزهای امنیتی را از طریق امنیت سطح ردیف (RLS) اجرا کند. یک امتیاز مرتبط (Relevance Score) در واقع یک «نظر» است، اما یک شرط محدوده که توسط دیتابیس اجرا شده، یک «مرز» است.
خط لوله بازیابی شش‌مرحله‌ای
معماری پیشنهادی برای حل این مشکلات، یک قیف شش‌مرحله‌ای سخت‌گیرانه را اجرا می‌کند. هدف این است که فیلترها زودتر و رتبه‌بندی‌ها دیرتر انجام شوند تا عملیات گران‌قیمت فقط روی کوچک‌ترین مجموعه کاندیداها اجرا شود. این رویکرد از یک اصل بهینه‌سازی پرس‌وجو پیروی می‌کند: عملیات ارزان با قدرت تفکیک بالا باید اول اجرا شوند تا مجموعه کاندیداها کوچک شود.
۱. درک پرس‌وجو (Query Understanding): سؤال خام تجزیه می‌شود. سیستم موجودیت‌ها (مثل Letta و AgentCore) را استخراج کرده، واژگان مفهومی را گسترش می‌دهد (تخلیه $ \rightarrow $ هرس، خلاصه‌سازی) و قصد کاربر را طبقه‌بندی می‌کند. در یک پیاده‌سازی تجاری، می‌توان از یک فراخوانی مدل سریع استفاده کرد که یک شیء JSON شامل موجودیت‌ها، عبارات گسترش‌یافته، قصد و محدوده‌های زمانی برگرداند. در دفترچه راهنمای همراه، از قوانین ثابت و یک لغت‌نامه کوچک برای حذف نوسانات پاسخ مدل استفاده شده است.
۲. فیلتر متادیتا (Metadata Filtering): ابتدا فیلترهای محدوده و سیاست‌های امنیتی اعمال می‌شوند. در شمای ارائه شده در مقاله «از پرامپت تا پایداری»، شرط مستأجر (Tenant Predicate) توسط RLS اضافه می‌شود. سایر شروط شامل user_id/agent_id/thread_id با ارث‌بری NULL، شرط deleted_at IS NULL و وضعیت valid_until است. این تنها مرحله اجباری برای صحت سیستم است؛ نبود فیلتر در اینجا یک باگ امنیتی است، نه یک مشکل کیفی.
۳. تولید کاندیداهای ترکیبی (Hybrid Candidate Generation): جست‌وجوهای برداری و لغت‌نامه‌ای به‌طور موازی روی مجموعه فیلترشده اجرا می‌شوند. هر کدام یک لیست رتبه‌بندی شده top-k (به‌طور پیش‌فرض ۵۰ مورد) تولید می‌کنند. استخر برداری، بازنویسی‌ها را می‌گیرد و استخر لغت‌نامه‌ای، شناسه‌ها را. پاسخ سؤال جین در اجتماع این دو استخر قرار دارد.
۴. تلفیق امتیازات (Score Fusion): چون مقیاس فواصل برداری و امتیازات لغت‌نامه‌ای متفاوت است، سیستم از Reciprocal Rank Fusion (RRF) استفاده می‌کند. این روش به هر کاندیدا امتیازی برابر با $1/(60 + rank)$ از هر لیست اختصاص داده و آن‌ها را جمع می‌کند. این کار از نیاز به کالیبراسیون امتیازات جلوگیری کرده و RRF را به عنوان یک خط پایه قوی قرار می‌دهد. تکه‌ای که توسط هر دو مولد پیدا شود بالا می‌رود و تکه‌ای که فقط توسط یکی پیدا شود همچنان شانس رقابت دارد.
۵. بازرتبه‌بندی (Reranking): یک Cross-encoder (مانند BAAI/bge-reranker-base) پرس‌وجو و کاندیداها را با هم امتیازدهی می‌کند. برخلاف Bi-encoders، در Cross-encoder توجه (Attention) بین توکن‌های پرس‌وجو و کاندیدا جریان می‌یابد. این گران‌ترین مرحله است اما بیشترین افزایش دقت را فراهم می‌کند. این مرحله روی مجموعه کوچکی (مثلاً ۴۰ کاندیدا) اجرا می‌شود، نه روی کل مجموعه داده.
۶. بودجه‌بندی زمینه (Context Budgeting): لیست نهایی برای گنجاندن در یک بودجه توکن ثابت برش می‌خورد. به‌جای برش ساده، سیستم از یک گذر حریصانه (Greedy Pass) استفاده می‌کند تا تنوع در اسناد منبع را ترجیح دهد و تکه‌های تقریباً تکراری را حذف کند تا از افت عملکرد «گم‌شدن در میانه» جلوگیری شود. توکن‌های بیشتر از زمینه بد، فقط به معنای زمینه بد گران‌تر است.
ادغام زیرساخت در SQL
قلب این رویکرد، تبدیل مراحل ۲ تا ۵ به یک دستور واحد SQL است. با استفاده از Oracle AI Database 26ai، خط لوله از رفت‌وبرگشت‌های متوالی بین سه سیستم مختلف خلاص می‌شود.
در مدل‌های قدیمی «چندزبانه»، برنامه باید ابتدا شناسه‌های مجاز را از دیتابیس بگیرد، آن‌ها را به ذخیره‌ساز برداری بفرستد، سپس به موتور جست‌وجو ارسال کند و در نهایت نتایج را در کد پایتون ادغام نماید. این کار مستلزم اجرای مرز مستأجر سه بار در سه گویش فیلتر مختلف است. همچنین فیلتر $in ممکن است هزاران شناسه سند را روی شبکه جابه‌جا کند چون سیستم‌ها نمی‌توانند Join کنند.
در مدل متمرکز، یک پرس‌وجوی واحد، VECTOR_DISTANCE (با استفاده از ایندکس‌های HNSW)، امتیاز لغت‌نامه‌ای CONTAINS در Oracle Text و تلفیق RRF را از طریق FULL OUTER JOIN و محاسبات COALESCE مدیریت می‌کند. برای فعال‌سازی این قابلیت، یک ایندکس CTXSYS.CONTEXT روی ستون محتوا با پارامترهای SYNC (ON COMMIT) ایجاد می‌شود. پرس‌وجو از آکولادها (مثلاً {Letta}) استفاده می‌کند تا محتوا را به صورت Literal درآورد و از خطاهای نحوی با کلمات رزرو شده‌ای مثل WITHIN یا ABOUT جلوگیری کند.
این ادغام یک مزیت حیاتی ایجاد می‌کند: سازگاری تراکنشی (Transactional Consistency). چون کل خط لوله در یک دستور اجرا می‌شود، عامل هوش مصنوعی یک نمای تراکنشی واحد از دیتابیس می‌بیند. هیچ ریسکی وجود ندارد که در حین اجرای پرس‌وجو، نسخه قدیمی یک سند در استخر برداری و نسخه جدید آن در استخر لغت‌نامه‌ای بازیابی شود. این پاداشِ بخش خواندن در الگوی دو لایه «کانونیکال/مشتق» است.
هزینهٔ دقت
دقت بالا، بهای خود را در تأخیر (Latency) می‌پردازد. در تستی روی یک مجموعه داده پژوهشی شامل ۲۳ سند (۱۳۷ تکه)، جست‌وجوی برداری خالص تنها ۸ میلی‌ثانیه زمان برد. اما افزودن مرحله بازرتبه‌بندی ترکیبی، تأخیر p50 را به حدود ۲,۱۲۱ میلی‌ثانیه رساند؛ یعنی بیش از ۲ ثانیه هزینه اضافی. اجراهای اخیر روی ۴۰ کاندیدا پس از گرم شدن مدل، حدود ۲.۹ تا ۳.۱ ثانیه زمان بردند. اولین فراخوانی امتیازدهی معمولاً به دلیل بارگذاری مدل، ۰.۹ تا ۱.۱ ثانیه طول می‌کشد.
با این حال، بهبود کیفیت ملموس است. آزمایش‌ها نشان داد در حالی که تلفیق ترکیبی با وزن برابر گاهی در مجموعه‌های کوچک ضعیف‌تر از جست‌وجوی برداری خالص بود (NDCG@10 برابر ۰.۵۶ در مقابل ۰.۶۱)، افزودن بازرتبه‌کننده، معیار NDCG@10 را به ۰.۷۱ و Recall@20 را به ۰.۷۸ رساند.
یک نکته فنی حیاتی: بازرتبه‌کننده باید تکه متن را به همراه عنوان سند در ابتدا امتیازدهی کند (d.title || '. ' || c.content). بدون عنوان، Cross-encoder زمینه لازم برای رتبه‌بندی درست تکه‌های چند-مستأجری را از دست می‌دهد. در یک تست، افزودن عنوان باعث شد بهترین تکه‌ها از رتبه ۱۱ به سه رتبه اول منتقل شوند. در پیاده‌سازی مرجع، مدل BAAI/bge-reranker-base به عنوان یک عبارت PREDICTION در دیتابیس اجرا می‌شود تا متن کاندیداها در مرز دیتابیس باقی بماند.
ارکستراسیون با LangGraph
برای تبدیل این سیستم به یک محصول تجاری، خط لوله با LangChain و LangGraph یکپارچه شده است. یک OracleHybridRetriever سفارشی، خط لوله SQL را در بر می‌گیرد و فقط از طریق Memory Manager تعامل می‌کند تا یکپارچگی شمای داده‌ها حفظ شود. مدیر حافظه تنها بخشی از کد است که اجازه دسترسی به شما (Schema) را دارد.
به‌جای نوشتن کدهای پیچیده ارکستراسیون، فرآیند بازیابی به یک گراف با سه گره اصلی تبدیل می‌شود: understand (درک)، retrieve (بازیابی) و budget (بودجه‌بندی).
این ساختار اجازه می‌دهد توسعه‌دهندگان وضعیت (State) را چک‌پوینت کنند و هر مرحله را ابزارگذاری نمایند. همچنین امکان انتقال به «بازیابی عامل‌محور» (Agentic Retrieval) را فراهم می‌کند، جایی که مدل می‌تواند در یک حلقه، چندین پرس‌وجو صادر کند. برای مثال، یک عامل می‌تواند ابتدا درباره بحث تخلیه حافظه در Letta بپرسد، بفهمد که این موضوع «خلاصه‌سازی بازگشتی» نامیده می‌شود و سپس پرس‌وجوی دوم و دقیق‌تری برای نسخه AgentCore از آن مکانیسم صادر کند. این رویکرد چند-گامی (Multi-hop) یک سیاست ارتقا است: جست‌وجوهای ساده یک بار اجرا می‌شوند، در حالی که سوالات پیچیده تحت یک بودجه مشخص از تعداد دورها و توکن‌ها، حلقه را فعال می‌کنند.
تحلیل: پایان عصر «فقط برداری»
این تغییر سیگنالی است برای فاصله گرفتن از هایپ «فقط برداری» که بر پیاده‌سازی‌های اولیه RAG حاکم بود. برای توسعه‌دهنده عملیاتی، این بدان معناست که مشکل «گم‌شدن در میانه» — جایی که LLMها داده‌های مرتبط دفن شده در زمینه‌های طولانی را نادیده می‌گیرند — یک مشکل معماری بازیابی است، نه یک محدودیت مدل.
با انتقال تلفیق و بازرتبه‌بندی به داخل دیتابیس، «مرز امنیتی» توسط موتور دیتابیس از طریق RLS اجرا می‌شود، نه توسط کد برنامه. این کار رایج‌ترین حالت شکست در SaaSهای چند-مستأجری را حذف می‌کند: جایی که توسعه‌دهنده فراموش می‌کند فیلتر tenant_id را به یکی از سه سرویس جست‌وجوی مختلف اضافه کند.
ارزیابی کیفیت بازیابی
بازیابی بدون اندازه‌گیری، بازیابی بدون مدیریت است. برای عبور از روایت‌های پراکنده، تیم‌ها باید از یک «مجموعه طلایی» (Golden Set) از سوالات برچسب‌گذاری شده استفاده کنند. جدول conversation_memory به عنوان یک جعبه سیاه (Flight Recorder) عمل کرده و شناسه‌های کاندیداها را به عنوان رویدادهای retrieval_result در کنار فراخوانی‌های ابزار ثبت می‌کند.
معیارهای کلیدی عبارتند از:
- Recall@k: اندازه‌گیری می‌کند که آیا پاسخ در مجموعه کاندیداها هست یا خیر. اگر Recall@50 ضعیف باشد، بازرتبه‌بندی پایین‌دستی نمی‌تواند آن را اصلاح کند.
- NDCG@10: به قرار دادن مرتبط‌ترین موارد در بالاترین رتبه‌ها پاداش می‌دهد. این معیار اصلی برای حافظه عامل است زیرا نشان می‌دهد مرحله بودجه‌بندی چه چیزی را مصرف می‌کند.
- MRR: برای جست‌وجوی حقایق دقیق که در آن یک مورد موفق کافی است، مفید است.
- Precision@k: در مرز مجموعه کاری بیشترین اهمیت را دارد، جایی که هر مورد نامرتبط، بودجه زمینه را مصرف می‌کند.
ارزیابی باید در هر تغییر مدل برداری اجباری باشد، زیرا برداری‌های جدید کل فضای برداری را تغییر می‌دهند و می‌توانند عملکرد را روی یک مجموعه داده خاص کاهش دهند، حتی اگر در بنچمارک‌های کلی بهبود یابند. استفاده از LLM-as-judge یک سیگنال جهت‌دار برای اولویت‌بندی است، اما برای ادعاهای دقیق، مجموعه طلایی برچسب‌گذاری شده الزامی است.
گام بعدی شما
توسعه‌دهندگان اکنون باید یک مطالعه حذف (Ablation Study) روی داده‌های برچسب‌گذاری شده خود اجرا کنند تا ببینند آیا تأخیر ۲ ثانیه‌ای بازرتبه‌بندی در برابر افزایش دقت روی مجموعه داده خاص آن‌ها، یک معامله منصفانه است یا خیر. می‌توانید با استخراج جفت‌های «پرسش-تکه متن» واقعی از لاگ‌های گفتگوهای موجود، یک «مجموعه طلایی» برای اندازه‌گیری بسازید. مقاله بعدی مرحله نهایی را پوشش خواهد داد: چگونه مجموعه کاری را در یک پنجره متنی سازماندهی کنیم تا توجه مدل به حداکثر برسد.
گفتگو