پرش به محتوای اصلی
پرش به محتوای مقاله

۵ خطای امنیتی در RAG که اسناد محرمانه را به چت‌بات‌ها لو می‌دهد

·۱۹ مهر ۱۴۰۵۴ دقیقه مطالعه
راهنما
پنج اشتباه RAG که اسناد خصوصی را در پاسخ‌های چت فاش می‌کند
پنج اشتباه RAG که اسناد خصوصی را در پاسخ‌های چت فاش می‌کند
اشتراک‌گذاری
واقعاً چه چیز جدید است؟

ارائه یک چارچوب عملیاتی برای انتقال فیلترهای دسترسی از لایه نرم‌افزاری به لایه کوئری در پایگاه‌داده‌های برداری برای جلوگیری از نشت داده در RAG.

تصور کنید یک کارمند عادی از چت‌بات سازمانی می‌پرسد «حقوق مدیران ارشد چقدر است؟» و مدل با استناد به یک سند محرمانه منابع انسانی، پاسخ دقیق را می‌دهد. این یک حمله هکری نیست، بلکه شکست کامل در معماری سیستم است. یک بررسی عمیق فنی نشان داد که چگونه پیاده‌سازی‌های رایج 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 مراجعه کنید.

چرا این موضوع مهم است؟

این معماری از نشت داده‌های حساس در سازمان‌ها جلوگیری می‌کند و اعتماد مدیران را برای استقرار واقعی هوش مصنوعی جلب می‌کند. تخصص در پیاده‌سازی لایه‌های حفاظتی (Guardrails) اکنون به اندازه انتخاب خودِ مدل اهمیت یافته است.

تأثیر برای ایران

برای توسعه‌دهندگان ایرانی که در حال ساخت چت‌بات‌های سازمانی هستند، پیاده‌سازی این لایه‌ها برای جلوگیری از نشت اطلاعات داخلی حیاتی است. این متدها با هر زبان برنامه‌نویسی و پایگاه‌داده برداری سازگار هستند.

·نگاه ما
تحریریه دات‌هوش

جدا کردن مفهوم «شباهت ریاضی» از «مجوز دسترسی» کلیدی‌ترین درس این گزارش است. بسیاری از تیم‌های مهندسی به اشتباه تصور می‌کنند که اگر خروجی مدل را فیلتر کنند، امنیت برقرار است، در حالی که نشت داده در همان لایه بازیابی رخ می‌دهد. این رویکرد نشان می‌دهد که RAG در مقیاس سازمانی، بیش از آنکه یک چالش مدل‌سازی باشد، یک چالش مدیریت دسترسی (IAM) است.

منابع

این گزارش با خط‌لولهٔ خودکار دات‌هوش از منابع معتبر جهانی تدوین و زیر نظر تحریریه منتشر شده است. روش کار ما

گفتگو

پنج‌شنبه‌های هوش‌محور

بسته‌ی هفتگی دات‌هوش

۵ خبر، ۲ ابزار، ۱ پرامپت در هر شماره. به‌زودی راه‌اندازی می‌شود — هر پنج‌شنبه صبح.

خبر کلیدی
ابزار کاربردی
پرامپت حرفه‌ای
تحلیل پژوهش
به‌زودی
زاویه‌ی ایرانی
به‌زودی
تمرین این هفته
به‌زودی

راهنماهای دات‌هوش

راهنماهای کاربردیِ دات‌هوش برای کار با هوش مصنوعی — از همین‌جا شروع کنید:

دات‌هوش

راهنمای فارسی هوش مصنوعی — با نگاه به ایران

اخبار روزانه، معرفی ابزارها و مدل‌ها، و آموزشِ کار با هوش مصنوعی؛ همیشه با این پرسش که از ایران چه چیزی کار می‌کند و چه چیزی نه.