شباهت معنایی به‌تنهایی برای RAG کافی نیست؛ روتینگ راهکار جایگزین است

تصور کنید یک مهندس در حال رفع خطای یک سرور است و سیستم هوش مصنوعی به‌جای دستورالعمل فعلی، یک پست قدیمی از سه سال پیش را به دلیل شباهت کلمات پیشنهاد می‌دهد. این دقیقاً همان نقطه‌ای است که سیستم‌های تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — در محیط‌های عملیاتی شکست می‌خورند. در حالی که یک سیستم RAG ممکن است دقیقاً سند مرتبط را بازیابی کند، اما همچنان می‌تواند پاسخی کاملاً غلط را با اعتمادبه‌نفس بالا ارائه دهد. این تنش زمانی رخ می‌دهد که سیستم یک تکه متن (Chunk) از یک پاسخ در انجمن‌های کاربران، یک یادداشت طراحی داخلی، نسخه‌ای از محیط Staging یا یک راهنمای API منسوخ شده را که از نظر معنایی شبیه است، به عنوان حقیقت مطلق در نظر بگیرد. اگرچه آن سند ممکن است در بافتار خاص خودش درست باشد، اما برای پرس‌وجوی فعلی غلط است. در نهایت، این تنها یک مشکل بازیابی نیست؛ بلکه یک مشکل مسیریابی (Routing) است.

به نقل از تحلیل فنی منتشر شده در dev.to در ۹ سپتامبر ۲۰۲۶، مشکل اصلی هوش مصنوعی در مقیاس سازمانی، نه در بازیابی (Retrieval)، بلکه در مسیریابی (Routing) است. اکثر توسعه‌دهندگان خط لوله‌های خود را با این فرض می‌سازند که تمام منابع در یک ذخیره‌ساز برداری (Vector Store) به یک اندازه معتبر هستند، اما در داده‌های واقعی سازمانی، شباهت به معنای اعتماد نیست. یک تکه متن مرتبط از یک منبع با اعتبار پایین یا قدیمی همچنان می‌تواند غلط باشد. در سیستم‌های RAG چندمنبعی، سؤال سخت این نیست که «کدام تکه‌ها شبیه پرسش هستند؟»، بلکه این است که «این پرس‌وجو در این لحظه، برای این کاربر و در این محیط، باید به کدام منبع دانش اعتماد کند؟»

برای درک بهتر، یک کارشناس پشتیبانی را تصور کنید که به مشتری پاسخ می‌دهد. او باید به یک سیاست رسمی صورت‌حساب اعتماد کند تا یک تیکت حل‌شده از سه سال پیش. یا مهندسی که در حال رفع خطای سرور است، باید به یک Runbook جاری اعتماد کند تا یک FAQ عمومی. توسعه‌دهنده‌ای که درباره یک API می‌پرسد، باید مرجع فعلی API را به یک پست وبلاگی از دو سال پیش ترجیح دهد. وقتی سیستمی فاقد لایه مسیریابی باشد، به یک «ماشین اعتمادبه‌نفس» تبدیل می‌شود که بر روی یک مشکل اثبات (Evidence Problem) بنا شده است.

تلهٔ تک-اندکس (One-Index Trap)

بسیاری از تیم‌ها در «تله تک-اندکس» می‌افتند؛ آن‌ها مستندات محصول، صفحات قدیمی ویکی، تیکت‌های جیرا، پیشنهادهای طراحی و پست‌های انجمن را در یک فضای برداری واحد می‌ریزند. چون جست‌وجوی برداری فقط بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که می‌گوید این کلمه همسایه‌ی چه کلمات دیگری است — را می‌بیند، نمی‌تواند تشخیص دهد که به چه نوع منبعی نگاه می‌کند. نتیجه این است که یک سند طراحی منسوخ ممکن است از نظر معنایی شبیه‌تر به پرسش باشد تا مستندات رسمی فعلی، و این باعث می‌شود مدل پاسخی روان، دقیق اما غلط ارائه دهد. برای مثال، اگر کاربر بپرسد «چرا وب‌هوک بعد از ۳۰ ثانیه تلاش مجدد می‌کند؟»، ممکن است اولین نتیجه یک سند طراحی رها شده باشد که از نظر معنایی عالی است اما از نظر واقعیت منسوخ شده است.

این اتفاق به این دلیل می‌افتد که رویکرد تک-اندکس، چندین دامنه اعتماد متفاوت را در یک سطح بازیابی واحد ادغام می‌کند. اگرچه این روش به دلیل سادگی — یک خط لوله ورود داده، یک ذخیره‌ساز برداری و یک مسیر پرس‌وجو — جذاب است، اما در محیط تولید شکست می‌خورد زیرا نمی‌تواند بین یک حقیقت معیار (Canonical Truth) و یک پیشنهاد رها شده تفاوت قائل شود.

برای رفع این مشکل، توسعه‌دهندگان باید پیش از تکیه بر شباهت، منابع را بر اساس کلاس (Class) جدا کنند. این کار آلودگی بین‌دامنه‌ای را کاهش می‌دهد، زیرا پیش از پرسیدن «چه چیزی شبیه است؟»، می‌پرسد «این چه نوع پاسخی است؟». این هدف را می‌توان با روش‌های زیر اجرا کرد:

• استفاده از مجموعه‌ها (Collections) یا فضای نام‌ها (Namespaces)
• فیلترهای متاداده (Metadata Filters)
• نام‌های مستعار اندکس (Index Aliases)

با تفکیک کلاس‌های منبع در زمان پرس‌وجو — مانند جداسازی PRODUCT_DOCS ،API_REFERENCE ،BILLING_POLICY ،INTERNAL_RUNBOOKS ،SUPPORT_TICKETS ،COMMUNITY_POSTS و DESIGN_DOCS — سیستم می‌تواند تصمیم بگیرد که یک سؤال صورت‌حساب مشتری هرگز نباید در مجموعه design_archive جست‌وجو شود. برای مثال، نگاشتی مانند SourceClass.INTERNAL_RUNBOOKS به ops_runbooks تضمین می‌کند که سیستم دقیقاً می‌داند به کدام سطل دانش دسترسی دارد. البته به توسعه‌دهندگان هشدار داده می‌شود که بیش از حد زود دست به جداسازی نیندازند؛ ده مجموعه بد تعریف شده بدتر از سه مجموعه خوب تعریف شده است.

مسیریابی بر اساس قصد و قابلیت

قصد کاربر (Intent) تعیین می‌کند که منبع کجا باشد. یک سؤال درباره «لغو اشتراک» می‌تواند معانی مختلفی داشته باشد: مکان دکمه در رابط کاربری، سیاست‌های بازگشت وجه، پشتیبانی API از این قابلیت، یا اینکه آیا کاربر واجد شرایط استثنا است یا خیر. اگر مسیریاب همه این‌ها را یک «جست‌وجوی سند» ساده ببیند، پاسخ عملیاتی غلط خواهد بود.

سیستم‌های پیشرفته یک لایه مسیریابی (Router) پیاده می‌کنند — که می‌تواند مبتنی بر قانون، یک طبقه‌بندی‌کننده (Classifier) یا مبتنی بر LLM باشد — که پرسش را پیش از بازیابی طبقه‌بندی می‌کند. این تصمیم باید صریح، ثبت‌شده (Logged) و قابل تست باشد. در محیط تولید، این مسیریاب ممکن است الگوهای کلیدواژه‌ای را ترکیب کند (مثلاً «فاکتور»، «شارژ»، «بازگشت وجه»، «اشتراک»، «لغو»، «قیمت‌گذاری» برای صورت‌حساب؛ «اندپوینت»، «api»، «sdk»، «محدودیت نرخ»، «وب‌هوک»، «توکن» برای API؛ «قطعی»، «رول‌بک»، «runbook»، «on-call»، «حادثه» برای عملیات)، در کنار طبقه‌بندی‌کننده‌های سبک، نقش‌های کاربر و وضعیت گفتگو تا یک RoutingDecision ایجاد کند که مشخص می‌کند از کدام کلاس‌های منبع استفاده شود و آیا سیستم به داده‌های require_current (حتماً جاری) نیاز دارد یا خیر.

این لایه تصمیم می‌گیرد که آیا پرس‌وجو به موارد زیر نیاز دارد:

• دانش ایستا (Static Knowledge): مستندات عمومی و مراجع رسمی.
• جست‌وجوی حساب (Account Lookup): داده‌های زنده API برای وضعیت خاص کاربر (مثلاً «آیا بازگشت وجه من پردازش شده است؟» یا «سفارش من»).
• متریک‌های زنده (Live Metrics): تله‌متری سیستم در لحظه، نرخ خطاها یا وضعیت تأخیر (مثلاً «تأخیر فعلی چقدر است؟»).
• پشتیبانی انسانی (Human Support): ارجاع مستقیم به اپراتور زمانی که کاربر صراحتاً می‌خواهد با «یک شخص» یا «کارشناس» صحبت کند.

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

کنترل از طریق مانیفست منبع

نام‌گذاری‌های دستی مانند docs_final_v2 ،wiki_old ،support_macros_2024 یا internal_stuff بیشتر شبیه باستان‌شناسی است تا مدیریت مهندسی. وقتی هیچ‌کس به یاد نمی‌آورد کدام مجموعه معیار (Canonical) است، خط لوله اغلب برای جلوگیری از خرابی، در همه آن‌ها جست‌وجو می‌کند. راهکار درست، ایجاد یک مانیفست منبع (Source Manifest) است؛ یک رکورد متاداده که هدف، مالک، سطح اعتبار و چرخه حیات هر منبع را توصیف می‌کند.

جزئیات مانیفست شامل موارد زیر است:

• شناسه و کلاس منبع: شناسه یکتا و دسته‌بندی (مثلاً billing-policy-v5 به عنوان کلاس BILLING_POLICY).
• مالک (Owner): تیمی که مسئول محتوا است (مثلاً finance-ops).
• سطح اعتبار (Authority Tier): رتبه‌بندی عددی اعتماد (مثلاً سطح ۱ برای سیاست‌های معیار).
• چرخه حیات (Lifecycle): نشانگرهای وضعیت مانند active (فعال)، deprecated (منسوخ)، archived (آرشیو شده) یا draft (پیش‌نویس).
• محیط‌ها و مخاطبان: کجا منبع معتبر است (مثلاً production) و چه کسی می‌تواند آن را ببیند (مثلاً support یا customers).
• SLA تازگی: حداکثر سن مجاز سند به روز بر حسب روز (مثلاً ۳۰ روز برای سیاست‌های صورت‌حساب).
• گروه‌های ACL: لیست‌های کنترل دسترسی برای امنیت (مثلاً finance یا customers-public).

با مانیفست‌ها، مسیریابی سیاست‌محور می‌شود. یک مسیریاب می‌تواند به‌طور خودکار منابعی را که برای محیط فعلی نیستند حذف کند، برای سؤالات سیاستی authority_tier == 1 را ترجیح دهد، یا اگر منبعی SLA تازگی خود را از دست داده است، هشدار دهد. این کار سیستم را از تکیه بر «دانش شفاهی» به تکیه بر یک صفحه کنترل صریح تغییر می‌دهد. با این حال، مانیفست‌ها نیاز به نگهداری دارند؛ یک مانیفست قدیمی می‌تواند به اندازه یک سند قدیمی گمراه‌کننده باشد.

اعتبار در برابر شباهت

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

1. سیاست معیار (Canonical Policy): بالاترین سطح اعتماد.
2. مستندات رسمی (Official Docs): اعتماد بالا.
3. یادداشت‌های داخلی (Internal Notes): اعتماد متوسط.
4. محتوای جامعه (Community Content): اعتماد پایین.
5. آرشیو شده/تولید شده (Archived/Generated): پایین‌ترین سطح اعتماد.

با اضافه کردن یک «پاداش اعتبار» (Authority Bonus) به امتیاز مرتبط بودن، سیستم تضمین می‌کند که یک سند با شباهت کمی کمتر اما اعتبار بسیار بالا، رتبه‌ای بالاتر از یک سند بسیار شبیه اما غیرقابل اعتماد داشته باشد. برای مثال، یک منبع سطح ۱ ممکن است پاداش +۰.۲۰، سطح ۲ پاداش +۰.۱۲ و سطح ۳ پاداش +۰.۰۵ دریافت کند، در حالی که منبع سطح ۵ جریمه -۰.۱۰ می‌گیرد.

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

اعتماد زمانی و دسترسی‌ها

تازگی داده یک سیگنال حیاتی است. برخی دانش‌ها پایدار هستند، اما قیمت‌ها، محدودیت‌های API و قوانین انطباق (Compliance) زمانی هستند. اگر یک خط لوله بازیابی با تمام اسناد به عنوان داده‌های جاری برخورد کند، پاسخ‌های قدیمی تولید خواهد کرد. مدل‌سازی زمان به عنوان بخشی از بازیابی — با استفاده از برچسب‌های زمانی effective_at (موثر از)، valid_until (معتبر تا)، last_reviewed_at (آخرین بازبینی) و review_interval_days (بازه بازبینی) — مانع از رقابت منابع قدیمی با داده‌های جاری می‌شود.

این امر اجازه می‌دهد مسیریابی زمانی پیچیده‌ای را با استفاده از یک برچسب زمانی as_of اجرا کنیم:

• وضعیت جاری: استفاده از now برای پرسشی مثل «سیاست فعلی بازگشت وجه چیست؟»
• وضعیت تاریخی: استفاده از یک بازه زمانی خاص برای «چه سیاست بازگشت وجهی برای سفارشات سال ۲۰۲۴ اعمال می‌شد؟»
• وضعیت مقایسه‌ای: بازیابی هر دو نسخه برای پاسخ به «چه تغییراتی بین محدودیت‌های قدیمی و جدید API رخ داده است؟»

علاوه بر این، دسترسی‌ها باید پیش از بازیابی اعمال شوند. تکیه بر مدل زبانی (LLM) برای سانسور محتوای محدود شده یک ریسک امنیتی است. سیستم باید پیش از اینکه هر تکه متنی وارد Prompt شود، مانیفست‌های مجاز را بر اساس نقش کاربر، مستاجر (Tenant) و محیط فیلتر کند. این فرآیند باید ترتیب دقیقی داشته باشد: تعیین بافتار درخواست، فیلتر مانیفست‌های مجاز، مسیریابی بر اساس قصد، بازیابی از منابع مجاز و در نهایت تولید پاسخ. نقطه اجرا باید پیش از تولید باشد تا از رسیدن دانش غیرمجاز به مدل جلوگیری شود.

حل تعارضات و ارزیابی مسیریابی

وقتی دو منبع با هم اختلاف دارند — برای مثال، یکی می‌گوید بازه بازگشت وجه ۳۰ روز است و دیگری می‌گوید ۴۵ روز — مدل اغلب تعارض را بر اساس «حس» (Vibes) یا اینکه کدام عبارت متقاعدکننده‌تر به نظر می‌رسد حل می‌کند. سیستم‌های عملیاتی به قوانین صریح منشأ (Provenance) و اولویت نیاز دارند:

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

اگر تعارضی حل‌نشده باقی ماند، سیستم باید عدم قطعیت را فاش کند (مثلاً: «منبع سیاست فعلی ۳۰ روز را می‌گوید، اما منبع فعال دیگری ۴۵ روز را ذکر کرده است. لطفاً با مالک سیاست تأیید کنید») به‌جای اینکه در سکوت یک برنده انتخاب کند. حل تعارض یک تصمیم محصولی و حاکمیتی است، نه یک ترفند در Prompt.

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

• Recall کلاس منبع: آیا مسیریاب انواع منابع درست را شامل شده است؟
• Precision کلاس منبع: آیا انواع منابع نامرتبط زیادی را وارد کرده است؟
• نرخ منبع ممنوعه: آیا برای کاربران خارجی در مناطق محدود یا اسناد داخلی جست‌وجو کرده است؟
• نرخ نقض تازگی: آیا برای سؤالات جاری، منابع منسوخ را بازیابی کرده است؟
• نرخ نقض اعتبار: آیا برای پرس‌وجوهای حساس، منابع با اعتبار پایین را ترجیح داده است؟
• نرخ مسیریابی اشتباه قابلیت: آیا زمانی که باید از داده‌های زنده یا پشتیبانی انسانی استفاده می‌کرد، از مستندات استفاده کرده است؟

این تغییر در رویکرد، RAG را از یک موتور جست‌وجو به یک دستیار قابل اعتماد تبدیل می‌کند که قصد، اعتبار و قابلیت را درک می‌کند. با تبدیل مسیریابی به یک شهروند درجه یک در معماری، توسعه‌دهندگان می‌توانند تضمین کنند که مدل بافتار درست را از منبع درست و در شرایط درست دریافت می‌کند.

گام بعدی شما

• ساختار پایگاه‌داده برداری خود را از تک-اندکس به مدل چند-مجموعه‌ای (Multi-collection) تغییر دهید.
• برای هر منبع داده، یک فایل مانیفست شامل سطح اعتبار (Authority Tier) و تاریخ انقضا تعریف کنید.
• یک لایه طبقه‌بندی ساده (Classifier) قبل از مرحله Retrieval اضافه کنید تا قصد کاربر را تشخیص دهد.

اما مدیریت این لایه‌های مسیریابی در مقیاس هزاران منبع، چالش‌های جدیدی در زمینه تأخیر ایجاد می‌کند — به تحلیل ما درباره بهینه‌سازی استنتاج در مدل‌های RAG مراجعه کنید.