شهریور
آموزش هوش مصنوعی
RAG کاملاً آفلاین روی اسناد محرمانه
وقتی میخواهید یک سیستم RAG (Retrieval-Augmented Generation) روی اسناد محرمانه بسازید—قراردادهای حقوقی، پروندهٔ کارکنان، اسناد مالی داخلی—اولین چیزی که به ذهن میرسد این است: «مدل زبانی را محلی اجرا میکنم تا اطلاعات به بیرون نرود.» این جمله درست است، اما ناقص. یک پایپلاین RAG از چند مرحلهٔ متوالی تشکیل شده، و اگر فقط مرحلهٔ آخر (تولید پاسخ) محلی باشد ولی مراحل قبلی هنوز به سرویسهای ابری متصل باشند، محتوای محرمانهٔ شما همچنان از در پشتی بیرون میرود. برای آشنایی با معماری کلی این نوع سیستمها میتوانید نقشهٔ راه ساخت چتبات تخصصی را ببینید؛ و برای نگاه امنیتی گستردهتر به اینگونه پروژهها، نقشهٔ راه امنیت هوش مصنوعی منبع خوبی است. در این مقاله دقیقاً همین نقطهٔ کور را باز میکنیم: چرا برای اسناد محرمانه، آفلاینبودن باید کل زنجیره را در بر بگیرد، نه فقط مدل نهایی.
لیست مطالب
چرا «فقط مدل محلی» کافی نیست
یک پایپلاین RAG معمولی این مراحل را طی میکند: اسناد شما parse و به قطعات کوچکتر (chunk) تقسیم میشوند، هر قطعه با یک مدل embedding به بردار عددی تبدیل میشود، این بردارها در یک پایگاهدادهٔ برداری ذخیره میشوند، و در زمان پرسش، پرسش کاربر هم embed شده و نزدیکترین قطعات بازیابی میشوند تا در نهایت به مدل زبانی برای تولید پاسخ داده شوند. اگر مرحلهٔ تولید پاسخ محلی باشد اما مدل embedding از طریق یک API ابری فراخوانی شود، عملاً محتوای واقعی اسناد محرمانهٔ شما—همان متنی که قرار بود هیچوقت از سازمان خارج نشود—به سرور آن سرویس ابری فرستاده میشود. از نظر امنیتی، این دقیقاً همان نشتی است که سعی داشتید با اجرای محلی مدل جلویش را بگیرید؛ فقط جای آن جابهجا شده است.
اجزای زنجیرهای که باید محلی باشند
برای اینکه واقعاً بتوانید بگویید یک پایپلاین RAG «کاملاً آفلاین» است، باید هر یک از این اجزا را جداگانه بررسی کنید:
- مدل embedding: باید روی همان دستگاه یا شبکهٔ داخلی اجرا شود، نه از طریق API ابری فراخوانی شود. اغلب ابزارهای اجرای مدل محلی (از جمله همانهایی که برای چت استفاده میکنید) از مدلهای embedding محلی هم پشتیبانی میکنند.
- پایگاهدادهٔ برداری (vector database): باید نسخهٔ self-hosted یا در حافظهٔ محلی باشد، نه سرویس ابری managed. بسیاری از این پایگاهدادهها هم نسخهٔ ابری و هم نسخهٔ کاملاً محلی (self-hosted) دارند؛ انتخاب نسخهٔ درست همینجا تعیین میشود.
- مدل زبانی نهایی (LLM): همان مدل محلی که در مقالههای قبلی دربارهٔ آن صحبت کردیم.
- مرحلهٔ parsing و OCR: اگر اسناد شما اسکنشده یا PDF هستند و از یک سرویس ابری OCR برای استخراج متن استفاده میکنید، این هم یک نقطهٔ نشتی است که باید محلی شود.
خطر پنهان: telemetry و فراخوانیهای پسزمینه
حتی وقتی همهٔ اجزای بالا را بهدرستی محلی راهاندازی کردهاید، بسیاری از فریمورکها و کتابخانههای متنباز بهطور پیشفرض telemetry یا بررسی بهروزرسانی به سرورهای خودشان میفرستند؛ این ترافیک معمولاً حاوی محتوای سند نیست، اما نشان میدهد سیستم شما همچنان یک اتصال بیرونی باز دارد که برای یک سیستم واقعاً air-gapped قابلقبول نیست. بهترین کار این است که در محیط حساس، ترافیک شبکهٔ خروجی را با یک فایروال یا حداقل با ابزار مانیتورینگ شبکه بررسی کنید و ببینید سرویس واقعاً هیچ درخواستی به بیرون نمیفرستد، نه اینکه فقط به مستندات ابزار اعتماد کنید.
| مرحلهٔ زنجیره | خطر رایج | راهحل آفلاین |
|---|---|---|
| Parsing / OCR سند | استفاده از API ابری برای استخراج متن از PDF یا تصویر | ابزار OCR محلی یا کتابخانهٔ parsing که کاملاً روی دستگاه اجرا میشود |
| Embedding | فراخوانی مدل embedding ابری برای برداریکردن قطعات متن | مدل embedding محلی که همراه سرور مدل زبانی اجرا میشود |
| پایگاهدادهٔ برداری | استفاده از نسخهٔ managed / ابری پایگاهدادهٔ برداری | نسخهٔ self-hosted روی همان سرور یا شبکهٔ داخلی |
| تولید پاسخ نهایی | این مرحله معمولاً محلی است، اما نباید تنها مرحلهٔ محلی باشد | مدل زبانی محلی طبق مقالهٔ سختافزار و اتصال |
| Telemetry ابزارها | فراخوانیهای پسزمینه به سرورهای سازندهٔ کتابخانه | غیرفعالسازی صریح telemetry و بررسی ترافیک خروجی با فایروال |
چطور واقعاً مطمئن شویم سیستم آفلاین است
اعتماد به مستندات یک ابزار برای اثبات آفلاینبودن کافی نیست؛ باید خودتان آن را تأیید کنید. سادهترین روش این است که کل پایپلاین را در یک محیط بدون دسترسی به اینترنت اجرا کنید—مثلاً با قطع موقت اتصال شبکه یا با یک قانون فایروال که هر ترافیک خروجی بهجز بازهٔ IP داخلی را مسدود میکند—و ببینید آیا سیستم همچنان بهدرستی کار میکند یا در جایی با خطای اتصال متوقف میشود. اگر جایی خطا گرفتید، همانجا نقطهٔ نشتی واقعی شما پیدا شده؛ این روش بسیار قابلاعتمادتر از خواندن مستندات یا حدسزدن است. برای محیطهای حساستر، بعضی تیمها حتی یک نسخهٔ کاملاً air-gapped (بدون هیچ کارت شبکهٔ فعال) نگه میدارند و فقط از طریق رسانهٔ فیزیکی اسناد و بهروزرسانیها را وارد میکنند.
نکتهٔ دیگر اینکه، آفلاینبودن باید در طول زمان هم پایدار بماند، نه فقط در روز راهاندازی. یک بهروزرسانی نرمافزاری میتواند بیسروصدا یک وابستگی جدید یا یک فراخوانی telemetry اضافه کند. به همین دلیل، بررسی ترافیک شبکه باید به یک روال دورهای تبدیل شود، نه یک تست یکباره؛ مخصوصاً بعد از هر بهروزرسانی کتابخانهها یا سرور مدل.
نکتهٔ آخر اینکه، آفلاینبودن فقط یک تصمیم فنی نیست؛ باید بخشی از سیاست امنیتی مستند سازمان شما باشد. اگر میخواهید این موضوع را در چارچوب گستردهتری از ارزیابی ریسک هوش مصنوعی ببینید، دوباره تأکید میکنم که نقشهٔ راه امنیت هوش مصنوعی نقطهٔ شروع خوبی است.
جمعبندی
- محلیبودن فقط مدل زبانی نهایی کافی نیست؛ کل زنجیرهٔ RAG باید آفلاین باشد.
- مدل embedding و پایگاهدادهٔ برداری دو نقطهٔ نشتی رایج و کمدیدهشده هستند.
- اگر از OCR یا parsing ابری برای اسناد اسکنشده استفاده میکنید، همانجا هم یک نشتی بالقوه است.
- telemetry پیشفرض بسیاری از کتابخانههای متنباز باید صراحتاً غیرفعال و ترافیک خروجی بررسی شود.
- آفلاینبودن کامل باید بهعنوان یک الزام مستند در سیاست امنیتی پروژه ثبت شود، نه صرفاً یک انتخاب پیکربندی.
