مقالات آموزشی

کتابخانه ساختگی در کد هوش مصنوعی؛ بررسی نام‌ها پیش از نصب

با یک تمرین بدون نصب بسته، نام نصب و import را در کد پیشنهادی هوش مصنوعی جدا کنید، شاهد مستند بیابید و نتیجه را در فایل CSV ثبت کنید.

تصویرسازی مفهومی: کتابخانه ساختگی در کد هوش مصنوعی؛ بررسی نام‌ها پیش از نصب
در این مقاله می‌خوانید ۶ بخش

این بررسی چه چیزی را روشن می‌کند؟

برای بررسی کتابخانه ساختگی در کد هوش مصنوعی، نام وابستگی را مستقیماً به فرمان نصب تبدیل نکنید. ابتدا نام مورد استفاده برای نصب را از نامی که در import آمده جدا کنید و ارتباطشان را در مستندات رسمی همان پروژه بیابید. خروجی این تمرین یک فایل dependency-review.csv است؛ نه نصب بسته و نه تأیید امنیت آن.

پژوهش ارائه‌شده در USENIX Security 2025 در اوت ۲۰۲۵، پیشنهاد وابستگی‌های ناموجود توسط مدل‌های تولید کد را بررسی کرده است. پژوهشگران ۱۶ مدل را با دو مجموعه پرامپت آزمودند و ۵۷۶ هزار نمونه کد در دو زبان تولید کردند. این یافته‌ها ضرورت بررسی نام‌ها را نشان می‌دهند، اما نرخ خطای هر مدل امروزی یا هر پاسخ برنامه‌نویسی را تعیین نمی‌کنند.

۱. محیط تمرین و پاسخ اولیه را آماده کنید

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

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

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

۲. نام نصب را از نام import جدا کنید

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

طبق راهنمای رسمی PyPA، بسته توزیعی نامی است که برای نصب یا تعریف وابستگی به کار می‌رود؛ بسته قابل import نامی است که کد وارد می‌کند. یکسان‌بودن این دو رایج است، اما الزامی نیست. نمونه مستند آن Pillow برای نصب و PIL برای استفاده در کد است. همچنین یک بسته توزیعی می‌تواند چند نام قابل import فراهم کند.

پرامپت پیشنهادی تألیفی و آزمایش‌نشده: «وابستگی‌های این کد پایتون را فهرست کن. نام نصب را از نام import جدا بنویس، مستند رسمی پیشنهاد بده و موارد نامطمئن را نیازمند بررسی علامت بزن. هیچ فرمانی اجرا نکن و نام نامعلوم را حدس نزن.»

پاسخ تازه مدل فقط فهرست پیشنهادی برای بررسی است، نه تأیید پاسخ قبلی.

۳. برای ارتباط دو نام، شاهد رسمی پیدا کنید

برای هر ردیف، مستندات رسمی پروژه را باز کنید و بخش نصب و نمونه استفاده را کنار هم بخوانید. پرسش مشخص این است: آیا همین پروژه نام نصب پیشنهادی و نام import موجود در کد را به هم مرتبط می‌کند؟ نام صفحه و بخش حاوی شاهد را یادداشت کنید.

وجود یک نام در فهرست بسته‌ها، به‌تنهایی ارتباط آن با import را ثابت نمی‌کند. راهنمای PyPA صریحاً هشدار می‌دهد که دیدن import foo دلیل کافی برای نصب بسته هم‌نام نیست؛ این کار ممکن است به نصب بسته ناخواسته یا مخرب منتهی شود.

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

۴. نتیجه را در dependency-review.csv ذخیره کنید

در یک فایل متنی، ستون‌های tool، model، response_date، install_name، import_name، evidence، status و notes را با ویرگول از هم جدا کنید و برای هر وابستگی یک ردیف بسازید. فایل را با نام dependency-review.csv و کدگذاری UTF-8 ذخیره کنید. برای خانه‌ای که شامل ویرگول است، مقدار را داخل علامت نقل‌قول دوتایی قرار دهید.

نمونه آموزشی برگرفته از سند PyPA، نه نتیجه آزمایش این مقاله: install_name برابر Pillow، import_name برابر PIL و evidence برابر «راهنمای PyPA، بخش تفاوت بسته توزیعی و قابل import» است. وضعیت این ردیف می‌تواند «شاهد یافت شد» باشد؛ در notes بنویسید «فقط ارتباط نام‌ها مستند است؛ سلامت امنیتی بررسی نشده».

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

اگر بررسی به نتیجه نرسید، چه کنید؟

اگر نام نصب با import فرق داشت، آن را فوراً خطای مدل ندانید؛ نمونه Pillow و PIL نشان می‌دهد این اختلاف می‌تواند معتبر باشد. اگر مستندات ارتباط را روشن نکرد، ردیف را تأییدنشده نگه دارید و فرمان نصب پیشنهادی را مبنای ادامه کار قرار ندهید.

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

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

منابع این مطلب
مطالب بیشتر در مقالات آموزشی
دیدگاه‌ها۰ دیدگاه تأییدشده

هنوز دیدگاهی منتشر نشده است. اولین نفر باشید.

دیدگاه خود را بنویسید

دیدگاه پس از بررسی مدیر منتشر می‌شود. نام و متن شما عمومی خواهد بود.