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

تصور کنید برنامه‌نویسی در ۶ ژوئیه ۲۰۲۶ است و با اطمینان کامل، تابعی را فراخوانی می‌کند که در کتابخانه مورد‌نظرش اصلاً وجود ندارد. این اتفاق که به آن توهم (Hallucination) می‌گویند، طبق گزارش dev.to، یک ویژگی ساختاری در نحوه عملکرد مدل‌های زبانی بزرگ است. هر کسی که بیش از یک هفته با دستیارهای کدنویسی کار کرده باشد، احتمالاً این لحظه را تجربه کرده است: کد تمیز است، نام‌گذاری‌ها درست به نظر می‌رسند، قابلیت تکمیل خودکار (Autocomplete) با آن موافق است، اما تابع در هیچ‌کجای کتابخانه یافت نمی‌شود.

مکانیسم‌های توهم

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

اگر از مدل بخواهید با استفاده از یک کتابخانه محبوب چیزی بنویسد، او از هزاران نمونه‌ای که دیده است استفاده می‌کند. مدل یاد گرفته است که توابع آن کتابخانه معمولاً چه «شکلی» دارند و چگونه نام‌گذاری شده و فراخوانی می‌شوند. از آنجا که مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — متن را توکن به توکن تولید می‌کند، نامی می‌سازد که با «شکل» آماری کنوانسیون‌های نام‌گذاری آن کتابخانه همخوانی داشته باشد.

وقتی یک AI تابعی را پیشنهاد می‌دهد، در حال تأیید کد منبع (Source Code) فعلی آن کتابخانه نیست. هیچ مرحله داخلی وجود ندارد که خروجی را با کد منبع واقعی و جاری تطبیق دهد. همین موضوع باعث می‌شود کدهای توهم‌زده به‌شدت متقاعدکننده باشند؛ زیرا استایل درست، الگوهای آرگومان صحیح و نام‌گذاری‌های متناسب را رعایت کرده‌اند و تا لحظه اجرا، کاملاً درست به نظر می‌رسند. این موضوع دقیقاً همان جایی است که خطرات پنهان آغاز می‌شوند، مشابه آنچه در پروژه Loupe برای شناسایی باگ‌های خاموش در کدهای تولیدشده توسط AI بررسی شد.

الگوهای رایج توهم

برای شناسایی سریع‌تر این خطاها، چهار الگوی خاص وجود دارد که دانستن آن‌ها ضروری است:

• متدهای ساختگی (Fabricated Methods): این رایج‌ترین مورد است. AI نام تابعی را پیشنهاد می‌کند که دقیقاً شبیه چیزی است که «باید» وجود داشته باشد و استایل نام‌گذاری را به‌طور کامل رعایت کرده است، اما این تابع در نسخه نصب‌شده کتابخانه به‌طور کامل غایب است.
• پارامترهای API قدیمی (Outdated API Parameters): مدل‌ها با اطمینان فیلدهایی را پیشنهاد می‌دهند که چندین نسخه پیش حذف شده‌اند، تغییر نام داده‌اند یا هرگز وجود نداشته‌اند. این مورد به‌ویژه در فریم‌ورک‌هایی که سرعت تغییر بالایی دارند و در SDKهای ارائه‌دهندگان خدمات ابری که مدام به‌روز می‌شوند، دیده می‌شود.
• مستندات خیالی (Phantom Documentation): دستیار کدنویسی ارجاعات ساختگی به مستندات ارائه می‌دهد. مثلاً به شما می‌گوید بخش یا صفحه خاصی از مستندات رسمی را چک کنید و حتی عنوانی برای آن صفحه می‌سازد که منطقی به نظر می‌رسد، در حالی که آن صفحه اصلاً وجود خارجی ندارد.
• تضاد نسخه‌ها (Version Mismatch): این یک خطای ظریف و کلافه‌کننده است. کد پیشنهادی ممکن است برای یک نسخه قدیمی از فریم‌ورک کاملاً درست باشد، اما در نسخه‌ای که شما در حال حاضر اجرا می‌کنید، بدون اینکه خطای واضحی برای توضیح دلیل آن صادر شود، باعث شکست برنامه می‌شود.

مثالی کاربردی

تصور کنید درخواست دریافت نتایج صفحه‌بندی شده (Paginated) از یک API را دارید. AI ممکن است با اطمینان کامل خروجی زیر را تولید کند: results = client.fetch_all(cursor=None, page_size=50). اگرچه این کد منطقی به نظر می‌رسد و با نحوه عملکرد معمول صفحه‌بندی‌ها سازگار است، اما متد واقعی در آن کتابخانه خاص ممکن است list_items باشد و ساختار پارامترهای کاملاً متفاوتی داشته باشد.

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

کاهش اثرات و ابزارها

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

برای توسعه‌دهندگانی که ابزارهای مبتنی بر AI می‌سازند، پیاده‌سازی تولید بازیابی‌افزا (Retrieval Augmented Generation یا RAG) راهکار اصلی است. با متصل کردن مدل به مستندات واقعی و به‌روز در لحظه درخواست، توسعه‌دهندگان می‌توانند خطاهای مبتنی بر حافظه را به‌شدت کاهش دهند. این کار مانع از آن می‌شود که مدل صرفاً به آنچه در زمان آموزش (Training) به خاطر سپرده — و احتمالاً اکنون قدیمی شده — تکیه کند.

این تغییر رویکرد به این معناست که با خروجی AI مانند یک «برنامه‌نویس جونیور سریع اما بیش‌ازحد مطمئن» رفتار کنید. خروجی‌ها اغلب درست و واقعاً مفید هستند، اما قبل از ادغام (Merge) در پروژه، نیاز به تأیید در برابر کد منبع و وابستگی‌های واقعی دارند.

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

گام بعدی شما

• هر متد پیشنهادی توسط AI را با دستور dir() یا help() در کنسول پایتون یا ابزارهای مشابه اعتبارسنجی کنید.
• در صورت تکرار توهمات در یک کتابخانه خاص، از ابزارهای مبتنی بر RAG یا افزونه‌هایی که مستندات محلی را می‌خوانند استفاده کنید.
• عادت کنید پیش از پذیرش کد، نام تابع را در مستندات رسمی نسخه مورد استفاده خود جست‌وجو کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است؛ برای درک اینکه چرا استنتاج این مدل‌ها هزینه‌بر است، تحلیل ما درباره تراشه‌های Blackwell را بخوانید.