خطای بارگذاری مدل را با خاموش‌کردن حفاظت رفع نکنید

توسعه‌دهنده فایل یک مدل دسته‌بندی را دانلود کرده است. برنامه هنگام بازکردن فایل به یک شیء ناشناخته می‌رسد و متوقف می‌شود. دستیار کدنویسی پیشنهاد می‌دهد یکی از گزینه‌های بارگذاری تغییر کند. خطا ناپدید می‌شود؛ ولی هم‌زمان، برنامه اجازه تازه‌ای برای اجرای دستورهای داخل فایل گرفته است. تغییر دوم را چه کسی بررسی کرده؟

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

خطر ممکن است پیش از نخستین پاسخ شروع شود

وزن‌های مدل عددند؛ اما فایلی که آن‌ها را نگه می‌دارد الزاماً فقط عدد ندارد. سازنده ممکن است همراه وزن‌ها، وضعیت آموزش، اشیای پایتون یا اطلاعات لازم برای بازسازی برنامه را ذخیره کرده باشد. پس پیش از بازکردن فایل باید قالب واقعی و برنامه خواننده را شناخت. پسوندهایی مانند .pt یا .bin این شناخت را فراهم نمی‌کنند.

مستندات pickle در پایتون هشدار می‌دهد که بازسازی محتوای نامطمئن ممکن است کد دلخواه را اجرا کند. این خطر با پاسخ نامناسب مدل فرق دارد: هنوز استنتاجی انجام نشده است. نوشتن دستور «ایمن رفتار کن» برای مدل، از رایانه‌ای که پیش از پاسخ‌گویی کد اجرا کرده محافظت نمی‌کند.

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

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

قالب وزن و اجازه اجرای کد دو تصمیم جدا هستند

عبارت «به این مدل اعتماد داریم» چند پرسش متفاوت را پنهان می‌کند. به کدام فایل، با کدام خواننده و برای چه کاری اعتماد داریم؟ بهتر است پاسخ‌ها در تنظیمات و سابقه بررسی هم جدا بمانند.

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

سیاست امنیتی Transformers همین جدایی را نشان می‌دهد. گزینه use_safetensors=True آن قالب را الزام می‌کند و نبودنش خطا می‌دهد. گزینه trust_remote_code=True موضوع دیگری است: اجرای کد مخزن که باید بررسی و به نسخه مشخص مقید شود. روشن‌بودن اولی، دلیل روشن‌کردن دومی نیست.

پیشنهاد ژرف این است که هر دو تصمیم صریحاً در پرونده استقرار ثبت شوند. نیاز یک معماری به کد سفارشی لزوماً آن را نامناسب نمی‌کند، ولی پذیرش آن کد، پذیرش نرم‌افزار است. نباید آن را تغییر بی‌اهمیت یک گزینه خواندن فایل دانست. در راهنمای پذیرش ابزار عامل همین تفاوت را برای ابزارهای اجرایی شرح داده‌ایم.

خطای بارگذار را بخوانید؛ مجوز نسازید

طبق یادداشت سریال‌سازی PyTorch، از نسخه ۲.۶، اگر pickle_module داده نشود، پیش‌فرض weights_only=True است. این مسیر بازسازی را محدود می‌کند و واردکردن پویای ماژول را نمی‌پذیرد. بررسی ایستای نوع‌ها کامل نیست و بعضی نوع‌های ساخته‌شده هنگام اجرا را نمی‌بیند؛ این محدودیت بارگذاری، مانع همه حملات مصرف منابع هم نیست.

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

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

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

فایل‌های جانبی عددی را فراموش نکنید

فقط فایل اصلی مدل اهمیت ندارد. آرایه کالیبراسیون یا بسته پیش‌پردازش کنار آن هم می‌تواند مسیر دیگری برای بازسازی اشیا باشد. مرجع numpy.load توضیح می‌دهد که پیش‌فرض allow_pickle=False است و خواندن آرایه‌های شیء با این محدودیت رد می‌شود؛ چون آن آرایه‌ها از pickle استفاده می‌کنند. نام یک آرایه، عددی‌بودن صرف محتوایش را تضمین نمی‌کند.

وقتی نیاز برنامه اجازه می‌دهد، از تولیدکننده آرایه‌های عددی با نوع مشخص بخواهید و توضیحات را در سندی جدا با ساختار معلوم بگیرید. مثلاً نام ویژگی‌های کالیبراسیون می‌تواند در فراداده‌ای محدود ثبت شود، نه در مجموعه‌ای از اشیای دلخواه پایتون. دو طرف باید بر سر شکل داده توافق کنند؛ تغییر گزینه اعتماد در خواننده، جای این توافق را نمی‌گیرد.

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

تبدیل فایل، مواجهه با ورودی قدیمی را حذف نمی‌کند

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

نمونه مشخص این تمایز در مستندات ایمنی مدل TGI آمده است: از نسخه ۲.۰، تبدیل خودکار pickle به پرچم صریح اعتماد به کد وابسته شده است. این رفتار مستند همان سامانه است؛ نباید آن را به همه چارچوب‌ها و برنامه‌های واسط تعمیم داد.

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

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

سیاست امنیتی PyTorch اجرای مدل نامطمئن در محیط جدا، تفکیک وزن از کد و اعتبارسنجی ورودی را حتی با قالب امن‌تر توصیه می‌کند. همان سیاست درباره احتمال اجرای کد توسط ابزارهای بررسی TorchScript هم هشدار می‌دهد. نام «بررسی» روی یک فرمان، به‌تنهایی منفعل‌بودن آن را ثابت نمی‌کند.

خروجی تبدیل هنوز اجازه انتشار ندارد

کارگری که ورودی بالقوه اجرایی را خوانده نباید خودش خروجی را برای محیط اصلی تأیید یا امضا کند. پیام «تبدیل موفق بود» فقط نتیجه اعلام‌شده همان اجراست، نه رأی مستقل امنیتی. فرایندی جدا باید فایل‌های خروجی مجاز را تحویل بگیرد و اجازه ندهد کارگر تبدیل، اختیار انتشار پیدا کند.

این فرایند، هش ورودی و خروجی، کد و محیط تبدیل، قالب انتخاب‌شده و تصمیم بررسی‌کننده را به هم وصل می‌کند. خروجی مورد انتظار وزن و فراداده محدود است؛ نه اسکریپت تازه، بسته ناشناخته یا فرمان راه‌اندازی عوض‌شده. نام، ابعاد و نوع تنسورها باید پیش از تخصیص منابع نامحدود با معماری بررسی‌شده تطبیق داده شود.

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

سابقه تبدیل را به شناسنامه انتشار سامانه هوش مصنوعی وصل کنید. در غیر این صورت شاید استقرار بعدی دوباره فایل اصلی را از مخزن بیرونی بگیرد و همه بررسی‌ها کنار بروند. محیط اصلی باید مجموعه داخلیِ تأییدشده را بخواند؛ حالت بارگذار و کد مجاز نیز بخشی از هویت همان مجموعه‌اند.

نمونه تصمیم برای یک مدل دسته‌بندی قدیمی

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

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

سازنده وزن‌ها را جدا می‌کند، اما فایل پیش‌پردازش هنوز آرایه شیء دارد. تیم نمایش داده‌ای با نوع مشخص می‌خواهد و پیاده‌سازی کوچک پیش‌پردازش را مستقل بررسی می‌کند. اگر سازنده نتواند آن را بدهد، انتخاب میان تبدیلِ جداگانه و کنارگذاشتن گزینه است. نزدیک‌شدن مهلت تحویل، آرایه شیء را به ماتریس ساده تبدیل نمی‌کند.

پس از دریافت مجموعه جایگزین، هویت و قالب فایل‌ها بررسی می‌شود؛ ابعاد و برخورد با ورودی آزموده می‌شود و پیش‌بینی‌ها روی مجموعه ثابت و غیرحساس مقایسه می‌شوند. کیفیت دسته‌بندی هم ارزیابی جداگانه دارد. این‌ها پیشنهاد آزمون‌اند، نه نتیجه‌ای که ژرف برای یک مدل واقعی اندازه گرفته باشد.

پشتیبانی از هر فایل قدیمی وظیفه الزامی پروژه نیست. سازگاری هزینه بازبینی، نگهداری، جداسازی و مهاجرت آینده دارد. گاهی درخواست یک خروجی دیگر، از حفظ همیشگی خواننده قدیمی هم ارزان‌تر است و هم توضیح‌پذیرتر.

مسیر ردشدن را هم آزمایش کنید

در راهنمای اسکن pickle در Hugging Face، بررسی واردکردن توابع و بسته‌ها توضیح داده شده، اما خود راهنما تأکید می‌کند که نتیجه کامل و قطعی نیست. اسکن را کنار بررسی کد، هویت فایل و جداسازی نگه دارید. نتیجه بدون هشدار نباید اجازه تلاش خودکار با بارگذار بی‌محدودیت بدهد.

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

تنظیم واقعی را در نقطه ورود و داخل برنامه‌های واسط ثبت و بررسی کنید. پیش‌فرض یک کتابخانه، وضعیت تمام فراخوانی‌های برنامه را توصیف نمی‌کند. نسخه پشتیبانی‌شده بارگذار، گزینه‌های صریح، استثناها و هویت مجموعه بارگذاری‌شده باید معلوم باشند. پس از تغییر وابستگی یا نصب اصلاحات امنیتی، همین آزمون‌ها را تکرار کنید؛ نسخه‌ای که نخستین بار پیش‌فرض بهتری آورده، خط مبنای امنیتی ابدی نیست.

سنجه‌های مفید شامل استثناهای بی‌بررسی، مجوزهای تاریخ‌گذشته، فایل‌های بدون سابقه نگهداری، خروجی‌های غیرمنتظره تبدیل و زمان گرفتن خروجی سازگار است. علت شکست‌ها را تفکیک کنید: افزایش ردشدن شاید از بسته‌بندی نادرست باشد، نه حمله. توقف درست نباید خودکار افت اعتمادپذیری خدمت حساب شود.

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

یادداشت منابع — بازبینی ۱ اکتبر ۲۰۲۶

منابع زیر مستندات اصلی پروژه‌ها هستند، نه گزارش حادثه تازه. صفحات پایتون و NumPy زنده‌اند؛ مرجع سریال‌سازی PyTorch به نسخه ۲.۱۴ اشاره دارد. بقیه سیاست‌ها و مستندات در تاریخ بالا بررسی شدند و تغییر مورد اشاره TGI صریحاً مربوط به نسخه ۲.۰ است. مثال‌ها و کنترل‌های پیشنهادی، تحلیل مهندسی‌اند و گواهی امنیت محسوب نمی‌شوند.

• پایتون — pickle: هشدار بازسازی محتوای نامطمئن.
• PyTorch ۲.۱۴ — سریال‌سازی: بارگذاری محدود، فهرست مجاز و محدودیت بررسی.
• مستندات safetensors: ذخیره‌سازی تنسورها.
• سیاست امنیتی Transformers: الزام قالب و بررسی کد مخزن.
• NumPy — numpy.load: آرایه شیء و مجوز pickle.
• TGI — ایمنی مدل: شرط اعتماد برای تبدیل.
• سیاست امنیتی PyTorch: جداسازی، اعتبارسنجی بعدی و خطر ابزار بررسی.
• Hugging Face — اسکن pickle: دامنه و محدودیت اسکن.