تصور کنید یک کارمند عادی از چتبات سازمانی میپرسد «حقوق مدیران ارشد چقدر است؟» و مدل با استناد به یک سند محرمانه منابع انسانی، پاسخ دقیق را میدهد. این یک حمله هکری نیست، بلکه شکست کامل در معماری سیستم است. یک بررسی عمیق فنی نشان داد که چگونه پیادهسازیهای رایج RAG بهطور تصادفی جستوجوی شباهت را به یک مسیر دسترسی غیرمجاز به دادهها تبدیل میکنند.
بر اساس بررسیهای فنی، بسیاری از پیادهسازیهای تولید بازیابیافزا (RAG) — که شبیه دانشآموزی است که قبل از جواب دادن، اول کتاب درسی را باز میکند و از آن نقل میآورد — بهطور تصادفی جستوجوی معنایی را به مسیری برای دسترسی غیرمجاز به دادهها تبدیل میکنند. مشکل اینجاست که اکثر توسعهدهندگان با پایگاهداده برداری (Vector Database) مثل یک موتور جستوجوی ساده برخورد میکنند و فراموش میکنند که شباهت کسینوسی (Cosine Similarity) — یعنی معیاری برای سنجش نزدیکی دو بردار معنایی — هیچ درکی از نقشهای سازمانی یا سطوح حریم خصوصی ندارد. وقتی یک سیاست سفر و یک جدول حقوقها در یک ایندکس مشترک قرار میگیرند، هوش مصنوعی هر آنچه را که از نظر ریاضی شبیهتر باشد بازیابی میکند، فارغ از اینکه چه کسی سؤال را پرسیده است.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای زبانی اشاره کردیم، تکیه بر لایههای بیرونی برای کنترل دسترسی کافی نیست. در واقع، اگر سیستم نتواند بین «حق دسترسی برای بازسازی ایندکس» و «حق خواندن دادههای حقوق و دستمزد» تفاوت قائل شود، امنیت سازمان به خطر میافتد.

به نقل از این راهنمای فنی، برای رفع این مشکل باید پنج نقطه شکست کلیدی و راهکارهای فنی آنها را پیاده کرد:
۱. شکاف در ایندکسگذاری
بسیاری از سیستمها از یک ایندکس واحد بدون برچسبهای مخاطب روی تکههای (Chunks) مجزا استفاده میکنند. اگر یک تکه از متن نداند چه کسی حق خواندن آن را دارد، هیچ پرسوجویی نمیتواند این محدودیت را در لحظه اجرا اعمال کند.
- راهکار: افزودن
TenantIdوAudience(مثلاً «همه» یا «منابع انسانی») به هر رکورد و علامتگذاری آنها به عنوان فیلدهای ایندکسشده. - پیادهسازی: استفاده از یک کلاس
KnowledgeChunkکه در آن فیلدهایTenantIdوAudienceو یک متغیر بولی به نامQuarantinedبا ویژگی[VectorStoreData(IsIndexed = true)]تعریف شده باشند. - زمینه: باید به خاطر داشت که دسترسیهای مدیریت برای بازسازی ایندکس دادهها با دسترسیهای خواندن حقوقها متفاوت است و این نقشها باید کاملاً مجزا باقی بمانند.
۲. فیلتر کردن پس از بازیابی
بازیابی نتایج برتر (Top-K) و سپس حذف مواردی که کاربر نباید ببیند، یک خطای استراتژیک و بحرانی است. در این حالت، فرآیند رتبهبندی پیش از این متن محرمانه را دیده است و شما اغلب با بافتارهای خالی مواجه میشوید، زیرا نتایج مناسب حذف شدهاند اما جایگزینی برای آنها در Top-K وجود ندارد.
- راهکار: قرار دادن شرط دسترسی (Permission Predicate) در داخل
VectorSearchOptions.Filterتا پایگاهداده در همان لحظه جستوجو، فیلتر را اعمال کند و نه اینکه اپلیکیشن بعد از دریافت نتایج آنها را فیلتر کند. - مکانیزم: فیلتر باید بررسی کند که
c.TenantId == caller.TenantIdباشد، مخاطب یا «همه» باشد یا باcaller.Roleمطابقت داشته باشد و همچنینc.Quarantined == falseباشد. - هشدار امنیتی: بافتار کاربر (
CallerContext) باید حتماً از طریق موجودیت احراز هویت شده (مانند ادعاهای JWT یا API Key) استخراج شود. اگر کلاینت بتواند شناسهی مستاجر (Tenant ID) را در بدنه JSON ارسال کند، امنیت شما صرفاً یک «نمایش نمایشی» (Security Theater) است و هیچ ارزش واقعی ندارد.
۳. اتکای ضعیف به شواهد
جستوجوی Top-K همیشه تعدادی نتیجه (K نتیجه) برمیگرداند، حتی اگر بهترین تطابق هم صرفاً نویز باشد. این موضوع منجر به توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی میگوید که اصلاً در اسناد وجود ندارد — میشود، زیرا مدل سعی میکند از روی دادههای بیربط پاسخ دهد. برای جلوگیری از این توهمات، میتوان از روشهایی مانند سیستم پینینگ برای تثبیت خروجیهای عاملهای AI استفاده کرد تا پاسخها از تبدیل شدن به افسانه جلوگیری شود.
- راهکار: تعیین یک آستانه امتیاز (
ScoreThreshold) برای شباهت کسینوسی (به گونهای که امتیاز بالاتر به معنای شباهت بیشتر باشد). - نتیجه: اگر هیچ نتیجهای از این آستانه عبور نکرد، سیستم باید وضعیت
NotFoundرا برگرداند و اصلاً سراغ مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — نرود. این کار باعث میشود پاسخ به سؤالات بیربط، رایگان، سریع و بدون احتمال توهم باشد. - کالیبراسیون: آستانهها باید برای هر مدل Embedding بهطور جداگانه کالیبره شوند، زیرا امتیازات یک مدل با مدل دیگر قابل مقایسه نیستند.
۴. توهم دستورات مورد اعتماد
بازیابی صفحهای از ویکی که حاوی جملهی «دستورات قبلی را نادیده بگیر» باشد، میتواند منجر به تزریق پرامپت (Prompt Injection) شود. ایجاد حصارهای متنی به تنهایی یک مرز امنیتی نیست، هرچند جلوی تزریقهای ساده را میگیرد.
- راهکار: شمارهگذاری منابع و کدگذاری HTML محتوا در بلوکهای
<source>با استفاده ازWebUtility.HtmlEncode. - پرامپتنویسی: صراحتاً به مدل بگویید که این بلوکها صرفاً دادههای مرجع هستند و نباید به عنوان دستورالعمل اجرا شوند. مدل را ملزم کنید که از استناداتی مانند [1] استفاده کند و اجازه دهید در صورت عدم یافتن پاسخ، دقیقاً عبارت
NOT_FOUNDرا برگرداند. - دروازه ورود: تکههایی که به وضوح حاوی «یادداشت برای هوش مصنوعی» هستند را در مرحله ورود دادهها (Ingestion) قرنطینه کنید.
۵. استنادات تأییدنشده
مدلها اغلب استنادات جعلی میسازند (مثلاً منبع [۹] را ذکر میکنند در حالی که فقط ۳ منبع ارائه شده است)، زیرا دستور «همیشه به منابع خود استناد کنید» در پرامپت، صرفاً یک درخواست است و نه یک الزام سختافزاری. این چالش مشابه خطاهای منطقی در تستهای خودکار است که در تحلیل ما درباره پیامدهای نوشتن همزمان کد و تست توسط عاملها بررسی شده است.
- راهکار: پیادهسازی یک
CitationValidatorبرای اعتبارسنجی پاسخ پیش از خروج از API. - اعتبارسنجی: استنادات
[n]معتبر را به سند، بخش مربوطه و امتیاز آن در رابط کاربری (UI) متصل کنید. - وضعیتها: API باید وضعیتهای دقیقی مثل
Answered(پاسخ داده شد)،NotFound(یافت نشد) یاUngrounded(بدون سند) را برگرداند. هر پاسخی که بدون سند (Ungrounded) باشد، نباید به کاربر نمایش داده شود.
این تغییر رویکرد، RAG را از یک ابزار در سطح «دمو» به یک سیستم آماده برای محیط تولید تبدیل میکند. با تفکیک «شباهت ریاضی» از «مجوز دسترسی»، توسعهدهندگان میتوانند از رایجترین نشتهای داده در باتهای سازمانی جلوگیری کنند.
برای توسعهدهندگان اکوسیستم .NET، یک پروژه کامل با استفاده از ASP.NET Core، .NET 10 و کتابخانههای Microsoft.Extensions.VectorData و Microsoft.Extensions.AI منتشر شده است تا این لایههای حفاظتی در یک محیط زنده نمایش داده شوند. این پروژه شامل یک کلاینت استخراجی آفلاین و یک مجموعه کامل WebApplicationFactory برای تست است.
توسعهدهندگان باید اکنون خط لولههای RAG خود را با یک «مجموعه طلایی» (Golden-set) از تستها ارزیابی کنند. این تستها باید تأیید کنند که یک کارمند عادی نمیتواند باندهای حقوقی منابع انسانی را ببیند و یک مستاجر (Tenant) به سیاستهای مستاجر دیگر دسترسی ندارد. علاوه بر این، اثر انگشت (Fingerprint) سیستم باید شامل مخاطبان، تنظیمات تکهکننده (Chunker) و شناسه مدل Embedding باشد تا در صورت تغییر مجوزها یا مدلها، بازسازی ایندکس (Re-index) اجباری شود. در این زمینه، درک تفاوت هویت کاری در برابر متن لغوی برای حل رگرسیونها در سیستمهای دادهمحور بسیار حیاتی است.
گام بعدی شما
- خط لوله بازیابی خود را بررسی کنید و فیلترهای دسترسی را از لایه اپلیکیشن به لایه پایگاهداده منتقل کنید.
- برای هر مدل بردار معنایی (Embedding) مورد استفاده، یک آستانه امتیاز (Score Threshold) اختصاصی تعریف کنید تا نرخ توهم کاهش یابد.
- یک اعتبارسنج استناد (Citation Validator) اضافه کنید تا از صحت ارجاعات مدل مطمئن شوید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.




گفتگو