اگر امروز از Copilot برای حل مشکلات کامپیوترتان استفاده می‌کنید، احتمالاً با پاسخ‌هایی مواجه شده‌اید که با اعتمادبه‌نفس کامل، راهکاری کاملاً غلط را به شما تحمیل کرده‌اند. باید بدانید که این «اعتمادبه‌نفس کاذب» نه یک نقص ساده، بلکه نتیجه‌ی اولویت دادن مدل به قاطعیت در برابر دقت است. در واقع، هوش مصنوعی در بسیاری از موارد ترجیح می‌دهد قاطع به نظر برسد تا اینکه دقیق باشد.
به گزارش وب‌سایت zdnet.com در ۲۲ ژوئن ۲۰۲۶، استراتژی اصلی برای مقابله با این مشکل در Microsoft Copilot (که از مدل GPT-5 بهره می‌برد)، انتقال مدل از «حالت پاسخ‌دهی» یا همان Solution Mode به «حالت تحلیل» یا Analysis Mode است. در بسیاری از موارد، این مدل حتی وقتی داده‌های لازم در اختیار ندارد، یک حدس احتمالی را به عنوان یک حقیقت مطلق ارائه می‌دهد و کاربر را به اشتباه می‌اندازد.
عیب‌یابی با مدل‌های زبانی بزرگ (LLM) — شبیه کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — می‌تواند بسیار متناقض و نامنظم باشد. گاهی یک چت‌بات با یک پاسخ منطقی و هوشمندانه مشکل را حل می‌کند و گاهی با اطمینانی کامل، پاسخ‌های کاملاً اشتباه را پیشنهاد می‌دهد. این وضعیت یک شکاف ارتباطی ایجاد می‌کند که گویی هوش مصنوعی از مریخ و انسان از ونوس آمده است. راه حل این نیست که امیدوار باشیم مدل حدس بهتری بزند، بلکه باید دقیقاً از چت‌بات بپرسیم که چگونه پرامپت‌ها را برای دریافت نتایج مفید بهینه کنیم.
بسیاری از کاربران با مدل‌ها مثل یک «جعبه جادویی» رفتار می‌کنند و درخواست‌های مبهمی مثل «کامپیوترم کند است» می‌فرستند. این رویکرد فاقد مبنی‌سازی (Grounding) — یا همان اتصال پاسخ مدل به واقعیات عینی — است و داده‌های لازم برای دقت یک LLM را فراهم نمی‌کند. این چالش دقیقاً همان نقطه‌ای است که برخی ابزارهای تخصصی برای متوقف کردن حدس‌های اشتباه در محیط‌های کدنویسی از آن برای کاهش خطاها استفاده می‌کنند. برای دریافت نتایج حرفه‌ای، شما باید یک مجموعه داده مشخص را ارائه دهید: شرح دقیق مشکل، کدهای خطا، تغییرات اخیر سیستم و مشخصات دستگاه. این روش دقیقاً مشابه فرآیند پذیرش و دریافت اطلاعات در مراکز پشتیبانی فنی انسانی است که تعامل را از یک «حدس ساده» به یک «گردش کار هدایت‌شده» تبدیل می‌کند.
طبق اعلام مایکروسافت، برای به حداکثر رساندن احتمال تشخیص درست، Copilot ساختار زیر را برای هر درخواست عیب‌یابی پیشنهاد می‌کند:
- مشکل: شرحی شفاف از آنچه در حال رخ دادن است در برابر آنچه انتظار داشتید اتفاق بیفتد (مثلاً: «کامپیوتر هنگام باز کردن File Explorer برای ۱۰ تا ۲۰ ثانیه هنگ می‌کند»).
- پیام‌های خطا: متن دقیق یا کدهای خطای خاصی که روی صفحه نمایش داده شده است.
- تغییرات اخیر: هرگونه سخت‌افزار جدید، نصب درایورها یا به‌روزرسانی‌های ویندوز و اپلیکیشن‌ها.
- جزئیات سیستم: نسخه دقیق سیستم‌عامل (OS) و نوع دستگاه.
- تاریخچه اقدامات: لیستی از تمام گام‌هایی که پیش از این برای رفع مشکل امتحان کرده‌اید تا مدل موارد تکراری را پیشنهاد نکند.
برای حذف اعتمادبه‌نفس کاذب، شما باید صریحاً قطعیت مدل را به چالش بکشید و اجازه ندهید مدل به راحتی به یک نتیجه واحد برسد. مؤثرترین ساختارهای مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن، شبیه کسی که می‌داند چطور از یک مشاور باتجربه بهترین جواب را بگیرد — عبارت‌اند از:
- درخواست جایگزین‌ها: به‌جای پذیرش یک تشخیص واحد، از مدل بخواهید محتمل‌ترین علت‌ها را در کنار احتمالات کم‌رنگ‌تر ارائه دهد و برای هر کدام درصد اطمینان (Confidence Percentage) ذکر کند. این کار مدل را مجبور می‌کند پاسخ‌های خود را مشروط و توجیه کند.
- اجبار به استدلال: از مدل فرمان دهید که «قبل از ارائه توصیه نهایی، مراحل استدلال خود را گام‌به‌گام توضیح دهد». این کار باعث می‌شود زنجیره تفکر (Chain-of-Thought) — شبیه وقتی شاگرد ریاضی پای تخته بلند بلند فکر می‌کند تا به جواب برسد — مدل آشکار شود و فرضیات ضعیف پیش از آنکه شما یک تغییر ریسکی را روی سیستم اعمال کنید، شناسایی شوند.
- شناسایی شکاف‌ها: پرامپت خود را با پرسش‌های انتقادی به پایان برسانید، مانند: «در چه موردی ممکن است اشتباه کرده باشی؟» یا «چه اطلاعاتی در اینجا کم است که اگر بود، پاسخ تو را تغییر می‌داد؟»
در ادامه پوشش‌های پیشین ما درباره استقرار ChatGPT Enterprise توسط سامسونگ برای کارکنانش در کره جنوبی، واضح است که با ورود هوش مصنوعی به محیط‌های حرفه‌ای، تمرکز از چت‌های ساده به «دقت در مسائل حساس» تغییر یافته است. در یک محیط شرکتی یا فنی، یک پاسخ «متقاعدکننده» اما غلط می‌تواند منجر به شکست‌های بحرانی در سیستم یا از دست رفتن دائمی داده‌ها شود.
به‌جای اینکه با هوش مصنوعی مثل یک تکنسین سطح ۳ (Tier 3) صحبت کنید، تعامل را به شکل دو همتا (Peer) که هر دو متخصص هستند تعریف کنید. با دستور «سریع به نتیجه نرس و به conclusions نپر — اگر برای تشخیص نهایی به جزئیات بیشتری نیاز داری، پیش از ارائه جواب نهایی از من بپرس»، شما به مدل اجازه می‌دهید که درنگ کند. برای مدیریت بهتر این تعاملات طولانی و جلوگیری از فراموشی جزئیات، می‌توان از متدهای سازماندهی داده‌ها برای حذف اتلاف وقت در جلسات چت بهره برد. این کار از بیش‌برازش (Overfitting) — یا همان تکرار الگوهای محدود داده‌های اولیه بدون تحلیل عمیق و عجله برای تطبیق با داده‌های کم — جلوگیری می‌کند.
این تغییر در استراتژی پرامپت‌نویسی، رفتار مدل را از «صدور حکم» به «ارائه طیفی از احتمالات» تغییر می‌دهد. با مشخص کردن اینکه شما به دنبال احتمالات و سطوح اطمینان هستید، LLM را از یک جایگزین برای قضاوت انسانی، به یک دستیار دانشمند تبدیل می‌کنید که به شما در تصمیم‌گیری کمک می‌کند.
در نهایت، هنگام دسترسی به بخش‌های حساس سیستم باید بسیار محتاط بود. به‌دلیل احتمال توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد، شبیه دوتی که خاطره‌ای را اشتباه تعریف می‌کند — این قوانین ایمنی را به شدت رعایت کنید:
- هیچ دستوری را در ترمینال یا Command Prompt که معنای آن را به‌طور کامل درک نمی‌کنید، اجرا نکنید.
- در ویرایش‌های رجیستری (Registry) بسیار محتاط باشید، زیرا کوچکترین خطا در این بخش می‌تواند پایداری کل سیستم‌عامل را به‌هم بزند و منجر به کرش شود.
- هر گامی که پتانسیل اثرگذاری بر یکپارچگی داده‌ها یا پایداری سیستم را دارد، دوباره و با دقت بررسی کنید.
گام بعدی شما
- این «پرامپت‌های عدم قطعیت» را روی یک باگ پیچیده نرم‌افزاری امتحان کنید تا ببینید آیا مدل علت‌های غیرمنتظره و ضدشهودی را افشا می‌کند که قبلاً نادیده گرفته بود یا خیر.
- بررسی کنید که آیا دستور «توضیح استدلال پیش از جواب» روی مدل‌های پیشرو دیگر مثل Claude یا Gemini نیز اثر مشابهی در کاهش خطای فنی و افزایش شفافیت دارد یا خیر.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو