کاربر از دستیار سازمان میپرسد «علت تغییر بودجهٔ این پروژه چه بود؟» و پاسخی دقیق، مستند و قانعکننده میگیرد. مشکل این است که یکی از منابع پاسخ، صورتجلسهای بوده که این کاربر اجازهٔ خواندنش را نداشته است. این مثال فرضی نشان میدهد چرا در ارزیابی سامانهٔ RAG، درستی پاسخ و درستی دسترسی باید دو معیار جدا باشند.
بهبود embedding ممکن است سند مرتبطتری پیدا کند، اما مرتبطبودن به معنای مجازبودن نیست. سامانه باید هم پرسش «چه چیزی به این سؤال مربوط است؟» و هم پرسش «این کاربر در این لحظه حق دیدن کدام بخش از آن را دارد؟» را پاسخ دهد. خبر تازهٔ Compass Cloud در اطلاعیهٔ ۲۵ سپتامبر ۲۰۲۶ Cohere بهانهای برای بررسی همین مرز است؛ نه شاهدی بر اینکه یک محصول همهٔ مسائل امنیتی RAG را حل کرده است.
مجوز باید قبل از ورود محتوا به مسیر پاسخ اثر کند
در الگوی ساده، برنامه ابتدا چند نتیجهٔ نزدیک را میگیرد و بعد موارد غیرمجاز را از فهرست حذف میکند. این فیلتر میتواند بخشی از دفاع سامانه باشد، اما اگر متن پیش از حذف به reranker، لاگ، cache مشترک یا مدل مولد رسیده باشد، حذف آن از پاسخ نهایی اتفاق قبلی را جبران نمیکند. همچنین ممکن است سهم نتایج مجاز در میان چند نتیجهٔ اول آنقدر کم باشد که پاسخ، بیدلیل ناقص شود.
منظور از اجرای مجوز در بازیابی، محدودکردن دامنهٔ جستوجو و عبور محتوا با هویت معتبر کاربر، tenant و سیاست دسترسی جاری است. در طراحی چنین سامانهای، شناسهٔ نقش نباید صرفاً رشتهای باشد که کاربر در prompt مینویسد؛ برنامه باید آن را از مرجع احراز هویت و مجوز قابل اعتماد بگیرد. جزئیات اجرا به موتور جستوجو و ساختار داده بستگی دارد و صرف وجود یک گزینهٔ «فیلتر» اثبات نمیکند که این مرز درست برقرار شده است.
برای بازیابی چندمرحلهای نیز مجوز مرحلهٔ اول کافی نیست. هر جستوجوی بعدی و هر سندی که از پیوندهای سند قبلی پیدا میشود، باید در همان دامنهٔ مجاز باقی بماند؛ زمینهای که به مدل میرسد هم باید از همین کنترل عبور کرده باشد. اینها ملاحظات معماری و آزموناند، نه ادعای تأیید همهٔ این جزئیات در Compass.
cache نمونهٔ مهم دیگری است. کلید و اعتبار پاسخ ذخیرهشده باید نسبت به tenant، دامنهٔ دسترسی و تغییر مجوز حساس باشد؛ پس از لغو مجوز یا حذف سند، پاسخ قدیمی نباید راه فرعی افشای محتوا شود. همین پرسش دربارهٔ reranking و ثبت رخداد هم مطرح است: کدام سرویس متن خام را میبیند، با چه مجوزی، و تا چه زمانی آن را نگه میدارد؟
Compass Cloud چه چیزی را معرفی کرده است؟
Cohere در معرفی Compass Cloud از یک پلتفرم بازیابی مدیریتشده سخن میگوید که اتصال منابع، پردازش اسناد، embedding، نمایهسازی، بازیابی و reranking را در یک مسیر قرار میدهد. طبق همان اطلاعیه، محدودیتهای tenant و سند هنگام بازیابی اعمال میشوند و دسترسی از طریق API، SDK پایتون و MCP ارائه میشود. این توصیفِ قابلیت اعلامشدهٔ ناشر است؛ در این یادداشت آزمون مستقل امنیتی یا عملیاتی آن انجام نشده است.
وضعیت اعلامشدهٔ Cloud، private beta برای شمار محدودی از شرکای سازمانی است. اطلاعیه در کنار آن، عرضهٔ self-hosted را برای نیازهای مقرراتی و حریم خصوصی مطرح میکند؛ بنابراین نباید ویژگیها، شرایط دسترسی و مسئولیتهای نسخهٔ مدیریتشده را خودکار به استقرار داخلی تعمیم داد. self-hosted بودن هم بهخودیخود به معنای متنباز بودن، رایگان بودن یا نداشتن وابستگی پشتیبانی نیست.
MCP در این بحث رابط اتصال ابزارهاست. اتصال از این مسیر بهتنهایی تضمین محرمانگی ایجاد نمیکند؛ محل اجرای ابزار، احراز هویت، دامنهٔ مجوز، ثبت رخداد و مقصد ارسال داده همچنان تعیینکنندهاند. به همان ترتیب، اینکه یک کاربر فقط سند مجاز خود را میبیند، پاسخ پرسش دیگری نیست: آیا سازمان اجازه داده است آن سند برای پردازش به ارائهدهندهٔ ابری ارسال شود؟
عدد بازیابی را با شرایطش بخوانیم
در ارزیابی داخلی HighFinance که Cohere در همین معرفی گزارش کرده، مقدار نمایشدادهشدهٔ nDCG@10 از ۶۴٫۸ به ۸۱٫۱ رسیده است؛ یعنی ۱۶٫۳ واحد افزایش در همان مقیاس نمایشدادهشده. مجموعه از اسناد حوزهٔ مالی و پرسشهای برچسبخوردهٔ داخلی تشکیل شده و مسیر ورود اسناد نیز یکسان نبوده است: در مقایسهٔ Azure Search، parsing با GPT-4.1 Mini انجام شده، در حالی که مسیر Embed 4 فایلهای PDF را مستقیماً بهصورت تصویر دریافت کرده است. در نتیجه، عدد حاصل را نمیتوان فقط به تفاوت embedding نسبت داد.
این گزارش میتواند فرضیهای برای آزمون بسازد: شاید حفظ اطلاعات بصری و ساختار سند، در برخی پروندهها بازیابی را بهتر کند. اما از آن نه برتری عمومی در همهٔ سازمانها نتیجه میشود، نه کیفیت فارسی و نه درستی کنترل دسترسی. برای تفکیک اثر موتور بازیابی از اثر پردازش سند، یک مقایسه باید ورودی پردازششدهٔ یکسان داشته باشد و مقایسهٔ کامل دو پشته، با parsing متفاوت، جدا گزارش شود.
برای تصمیم سازمانی چه چیزی هنوز باید روشن شود؟
اطلاعیهٔ بررسیشده مبنای کافی برای قطعیدانستن قیمت، SLA، منطقهٔ میزبانی، اقامت داده یا امکان ارائهٔ خدمت به ایران نیست. این محدودیت را نباید به «نبود این اطلاعات در همهٔ اسناد و قراردادهای شرکت» تبدیل کرد؛ باید مستند مربوط به همان طرح و همان مشتری را دریافت کرد. تا دسترسی واقعی و شرایط خدمت روشن نشده، Compass Cloud در این یادداشت توصیهٔ عملی پیشفرض برای سازمان ایرانی نیست.
پیش از انتخاب هر پشته، تیم خریدار میتواند یک آزمون پذیرش کوچک اما مشخص بخواهد: دو کاربر با مجوز متفاوت یک سؤال یکسان بپرسند، سپس دسترسی یکی لغو و سندی حذف شود. سامانه باید در بازیابی تازه، پاسخ ذخیرهشده و پرسش چندمرحلهای این تغییر را رعایت کند؛ آزمون باید هم قطعهٔ سند بازیابیشده و هم پاسخ نهایی را بررسی کند. مشاهدهٔ یک پاسخ بیخطر کافی نیست، چون ممکن است محتوای غیرمجاز پیشتر وارد زمینهٔ مدل یا سرویس دیگری شده باشد.
معیار انتخاب، کنار هم قرارگرفتن کیفیت بازیابی، زمان پاسخ، هزینه و حفظ مرز دسترسی است. اگر متن درست از سند نامجاز آمده باشد، امتیاز بالای بازیابی مشکل را حل نمیکند؛ همانطور که حذف همهٔ نتایج و ندادن پاسخ هم موفقیت کاربردی نیست. این تعادل باید با اسناد مجازِ آزمون، نقشهای مشخص و معیار پذیرش از پیش تعیینشده سنجیده شود.