طراحی فریبندهٔ ابزارهای هوش مصنوعی؛ اولویت نمایش بر بهره‌وری

تصور کنید حسابداری هستید که از ابزاری استفاده می‌کند که در متنی ریز و خاکستری می‌گوید «ممکن است اشتباه کنم»، اما هیچ راهی برای بازبینی یا حسابرسی (Audit) محاسباتش به شما نمی‌دهد. این دقیقاً وضعیت فعلی بازار مدل‌های زبانی بزرگ (LLM) است؛ جایی که ظاهرِ حرفه‌ای و رابط‌های صیقل‌خورده، نقص‌های ساختاری عمیقی را می‌پوشاند.

به نقل از نقد مفصلی که در ۲۸ سپتامبر ۲۰۲۶ در وب‌سایت blog.glyph.im منتشر شد، محصولات فعلی هوش مصنوعی بیشتر شبیه به «کلاهبرداری» (Grifts) هستند تا ابزار بهره‌وری. نویسنده استدلال می‌کند که این محصولات به‌گونه‌ای طراحی شده‌اند که کاربر را در وضعیت امنیتی کاذب قرار دهند و او را به‌طور فعال از بازبینی خطاهای مکرر بازدارند. در واقع، این ابزارها توهمی از قابلیت‌هایی را ایجاد می‌کنند که در واقعیت وجود ندارند.

این نقد در زمانی مطرح می‌شود که صنعت به سمت گردش‌کارهای عامل‌محور (Agentic) — یعنی هوش مصنوعی که می‌تواند به‌جای شما اقدام کند و تسک‌ها را پیش ببرد — حرکت کرده است. در حالی که آزمایشگاه‌های بزرگی مثل OpenAI، Anthropic و گوگل این قابلیت‌ها را پیش می‌برند، رابط کاربری (UI) همچنان همان کادر ساده و تختِ چت است. این طراحی، شکافی خطرناک بین «اعتبار ادعایی» هوش مصنوعی و «قابلیت اطمینان واقعی» آن ایجاد می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، فقدان لایه‌های نظارتی در رابط کاربری، ریسک خطاهای سیستمی را افزایش می‌دهد. این مشکل حتی در ابزارهایی مثل Ollama هم دیده می‌شود؛ ابزاری که شاید حتی بیشتر از مدل‌های ابری به ویژگی‌های تایید نیاز داشته باشد، زیرا کیفیت مدل‌های محلی در دسترس معمولاً پایین‌تر است.

یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — نباید در نقش یک «چت‌بات چاپلوس» (Obsequious Chatbot) ظاهر شود، بلکه برای تبدیل شدن به یک ابزار جدی، باید به یک فضای کاری ساختاریافته، قابل تایید و قابل حسابرسی تبدیل شود.

چارچوب «بازبینی خطا»

بزرگ‌ترین شکست محصولات فعلی این است که بازبینی خطا را به‌جای یک ویژگی اصلی و هسته‌ای، به یک سلب مسئولیت حقوقی (Legal Disclaimer) تبدیل کرده‌اند. تمام چت‌بات‌های بزرگ در متون ریز و با زبان حقوقی هشدار می‌دهند که مدل ممکن است اشتباه کند: Gemini هشدار می‌دهد که «هوش مصنوعی می‌تواند اشتباه کند، پس پاسخ‌ها را دوباره چک کنید»؛ Claude می‌گوید «کلود یک هوش مصنوعی است و ممکن است اشتباه کند»؛ و ChatGPT یادآور می‌شود که «چت‌جی‌پی‌تی می‌تواند اشتباه کند. اطلاعات مهم را بررسی کنید». نویسنده این سوال اساسی را مطرح می‌کند که کاربر دقیقاً چگونه باید تشخیص دهد کدام بخش از اطلاعات «مهم» است و نیاز به بررسی دارد؟

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

• برگه‌های تایید (Verification Worksheets): یک رابط کاربری دو ستونی که در ستون اول خروجی هوش مصنوعی قرار دارد و در ستون دوم، ستونی برای یادداشت‌های انسانی. کاربران باید مستند کنند که چه بررسی‌هایی برای تایید یک ادعا انجام داده‌اند و تنها پس از تایید کامل، تیک تیک تایید را به‌صورت دستی بزنند.
• امکانات بررسی کد (Coding Harness Affordances): دستیارهای کدنویسی فعلاً بررسی را به مرحلهٔ Code Review می‌اندازند. این یک «الگوی تاریک» (Dark Pattern) است که نویسندگان را تشویق می‌کند کار را به بازبین‌ها واگذار کنند. یک ابزار جدی باید اجازه دهد کاربر تفاوت‌ها (Diffs) را قبل از مصرف منابع گران‌قیمت کلاسترهای تست، بررسی کند.
• ارجاعات درجه‌یک (First-Class Citations): به‌جای لینک‌های ریز و ناخوانا (که اغلب ابعادشان کمتر از ۱۶ پیکسل است) و فقط نام دامنه را نشان می‌دهند، ارجاعات باید به صورت اشیایی بزرگ باشند. این ارجاعات باید شامل تاریخ انتشار، نام نویسنده و نقل‌قول مستقیم و دست‌نخورده‌ای باشد که توسط یک برنامه معمولی (نه توسط LLM) استخراج شده است.
• کاهش تاکید بر متن هوش مصنوعی: خلاصه‌های تولید شده توسط هوش مصنوعی باید با فونتی کوچک‌تر و کم‌رنگ‌تر زیر ارجاع قرار بگیرند و تا زمانی که کاربر صحت خلاصه را تایید نکند، در حاشیه باقی بمانند (مشابه وضعیت فعلی سلب مسئولیت‌های حقوقی).
• ردیاب مطالعه (Reading Trackers): برای پروژه‌های پژوهشی، یک چک‌باکس با عنوان «آیا منبع را خواندید؟» قرار گیرد تا اطمینان حاصل شود کاربر به نتایج احتمالا به‌هم‌ریخته‌ی تولید بازیابی‌افزا (RAG) — که شبیه دانش‌آموزی است که قبل از جواب دادن، اول کتاب را باز می‌کند — اعتماد کورکورانه نکرده است.

حذف اتلافات «شخصیت هوش مصنوعی»

نویسنده استدلال می‌کند که استفاده از زبان اول شخص و عذرخواهی‌های مدل، اتلاف محض محاسبات (Compute) و زمان انسان است. یک ابزار حرفه‌ای پژوهشی یا کدنویسی هیچ دلیلی ندارد که بگوید «متاسفم» یا «من به عنوان یک مدل زبانی...». این عذرخواهی‌ها توسط بات تولید می‌شوند، توسط کاربر خوانده می‌شوند و کاربر به آن‌ها پاسخ می‌دهد؛ فرآیندی که در هر سه مرحله زمان را تلف می‌کند.

علاوه بر این، «حفاظ‌ها» (Guardrails) یا همان نرده‌های ایمنی — که شبیه حصارهای دور یک باغ هستند تا مدل از مسیر خارج نشود — حتی در سال ۲۰۲۶ به‌راحتی دور زده می‌شوند و عملاً «غیرکاربردی» هستند. محصولی که واقعاً به دنبال بهره‌وری است باید وراجی‌های بیهوده را متوقف کند و روی تسک تمرکز کند. نویسنده اشاره می‌کند که چون آزمایشگاه‌ها می‌توانند خروجی مدل را برای بنچ‌مارک‌ها به‌شدت کنترل کنند، پس قادرند مدل‌هایی بسازند که به‌طور قابل توجهی کمتر وراج (Less Verbose) باشند.

فراتر از رابط‌های زبان طبیعی

رابط‌های مبتنی بر زبان طبیعی، نادقیق، تکراری و پر از «خرافاتی هستند که در لباس بهترین شیوه‌ها (Best Practices) ظاهر شده‌اند». اگرچه برخی محصولات از سرورهای پروتکل زمینهٔ مدل (MCP) برای دادن «ابزار» به هوش مصنوعی جهت انجام اقدامات استفاده می‌کنند، اما نویسنده معتقد است این رویکرد معکوس است؛ اگر ما نمی‌توانیم قصد خود را به‌طور شفاف بیان کنیم، نباید به سیستم اجازه دهیم اقداماتی انجام دهد که پتانسیل تخریب دارند.

به‌جای آن، رابط کاربری باید به سمت عناصر غیرزبانی حرکت کند:

• دکمه‌های تخصصی تسک: اگر ابزاری قرار است اسکنر امنیتی برای باگ‌های OWASP Top 10 باشد، باید یک دکمه اختصاصی برای این تسک داشته باشد.
• مدل‌های تخصصی: به‌جای تکیه بر یک «مغز سیاره‌ای» عظیم مثل Fable، آزمایشگاه‌ها باید از مدل‌های کوچک‌تر و موثرتری استفاده کنند که مستقیماً برای عملکردهای خاص آموزش دیده‌اند. این رویکرد با برتری مدل‌های زبانی کوچک در محیط‌های عملیاتی همسو است که نشان می‌دهد تخصص بر ابعاد مدل اولویت دارد.
• یکپارچگی ساختاری (Integrated Harnesses): به‌جای اینکه هوش مصنوعی از طریق استارتاپ‌ها به APIها وصل شود، این توابع باید در هسته محصول یکپارچه شوند تا نتایجی تکرارپذیر ارائه دهند.

منشأ داده‌ها و بازتولیدپذیری

در حال حاضر، محصولات هوش مصنوعی داده‌های API، خط لوله‌های RAG و توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — را در یک جریان واحد و یکپارچه ترکیب می‌کنند. یک ابزار جدی باید از نشانگرهای منشأ (Provenance) قوی استفاده کند تا بین یک فراخوانی معتبر API و یک خلاصه تولید شده، تمایز قائل شود. نویسنده یک مرحله «تایید برنامه‌نویسی‌شده داده‌ها» را پیشنهاد می‌کند که در آن بخش‌هایی از خروجی مانند یک صفحه گسترده (Spreadsheet) تلقی شوند تا محاسبات استاندارد کامپیوتری بتوانند نتایج را تایید کنند.

همچنین کنترل دقیق روی دمای مدل (Temperature) — که میزان تصادفی بودن جواب را تعیین می‌کند — ضروری است. اکثر کاربران از این متغیر بی‌خبرند و همین باعث ایجاد این تصور غلط می‌شود که هوش مصنوعی در حال ارائه یک «پاسخ قطعی و معتبر» است. برای حل این مشکل پیشنهاد شده:

• بازپخش فرآیند (Process Replay): وجود عناصری در UI که فرآیند تولید پاسخ را بازپخش کند تا کاربر ببیند طبیعت تصادفی (Stochastic) مدل چگونه روی قابلیت اطمینان یک تسک خاص اثر گذاشته است.
• انجماد قطعی (Deterministic Freezing): قابلیت منجمد کردن بخش‌های غیرقطعی یک گفتگو در حالی که فریم‌های داده با اطلاعات به‌روز شده پر می‌شوند، تا از تصادفی بودن بیهوده جلوگیری شود.
• طراحی ضد-درگیرسازی (Anti-Engagement Design): فاصله گرفتن از «کادر چت تخت» — که نویسنده آن را شبیه به بهینه‌سازی‌های شبکه‌های اجتماعی برای «افزایش زمان حضور در سایت» و شکارچی‌گونه می‌بیند — و حرکت به سمت سیستمی که به کاربر اجازه دهد مشکلش را حل کند و سریعاً از برنامه خارج شود.

مدیریت و دیده‌شدن زمینه (Context)

مدیریت «زمینه» یا Context در LLMها یکی از دشوارترین چالش‌های مهندسی است. کاربران پیشرفته در حال حاضر از «مهارت‌ها»، «ابزارها» و «زیر-عامل‌ها» برای مدیریت مسائل بزرگ استفاده می‌کنند، اما اغلب «کورکورانه» پیش می‌روند چون محصولات به‌صورت پیش‌فرض زمینه را به کاربر نشان نمی‌دهند.

یک محصول جدی باید زمینه را به یک ویژگی درجه‌یک تبدیل کند از طریق:

• نمایش «زمینه در دسترس» در رابط کاربری.
• توضیح اثرات فشرده‌سازی زمینه (Context Compaction).
• مرئی کردن پرامپت‌هایی که توسط لایه‌های نظارتی (Harness) تولید شده‌اند برای کاربر.
• اجازه دادن به کاربران برای انجام آزمایش‌های واقعی جهت درک نحوه بهینه‌سازی پنجره زمینه.

خطرات کدنویسی عامل‌محور

عامل‌های کدنویس در حال حاضر «به‌صورت پیش‌فرض ناامن» هستند. نویسنده این وضعیت را به «بستن یک تفنگ فنری به گردن یک سگ» تشبیه می‌کند. محیط‌های ایزوله مثل Docker جلوی پاک شدن کل سیستم‌عامل را می‌گیرند، اما نمی‌توانند جلوی تخریب کدبیس محلی یا ویرایش کدهای تست به‌جای سیستم اصلی (برای «تقلب» در تست‌ها) را بگیرند. این آسیب‌پذیری‌ها دقیقاً با ریسک امنیتی «دادنِ قدرتِ بیش از حد به عامل‌ها» که به یکی از بزرگ‌ترین تهدیدات سال ۲۰۲۶ تبدیل شده، همخوانی دارد.

برای اصلاح این وضعیت، یک لایه نظارتی (Harness) جدا از LLM باید این موارد را اجباری کند:

• ایزوله‌سازی سخت‌گیرانه فایل‌ها: محدود کردن حذف‌ها به دامنه‌های مشخص، فارغ از دستور پرامپت و مستقل از سیستم‌عامل.
• اسنپ‌شات خودکار: اجبار به ثبت وضعیت کل مخزن کد (Repo) در هر عملیات برای امکان بازگشت (Rollback) فوری.
• حذف حالت Auto: حذف کامل ویژگی‌های خطرناکی مثل --dangerously-skip-permissions.
• تایید دسته‌ای (Batch Approval): جایگزینی هشدارهای مکرر (که منجر به خستگی کاربر می‌شود) با برنامه‌های ساختاریافته‌ای که کاربر آن‌ها را به‌صورت گروهی بررسی و تایید کند.
• تایید سرویس‌های شبیه‌ساز (Mock Service Verification): اجرای تسک‌های عامل در برابر APIهای شبیه‌ساز برای تایید هم برنامه (Front-end) و هم فراخوانی‌های واقعی صادر شده (Back-end).

ریسک‌های سازمانی و «کاهش هوشیاری»

فراتر از نرم‌افزار، نویسنده هشدار می‌دهد که شرکت‌هایی که هوش مصنوعی را مستقر می‌کنند، ریسک‌های روان‌شناختی انسانی را نادیده می‌گیرند. پدیده «کاهش هوشیاری» (Vigilance Decrement) زمانی رخ می‌دهد که کاربر چون مدل ۹۵٪ مواقع درست می‌گوید، دیگر دقت نمی‌کند و همین منجر به شکست‌های فاجعه‌بار می‌شود. نویسنده به «میلیون‌ها سفارش گم‌شده در آمازون» به عنوان نمونه‌ای از زوال فرآیندهای مهندسی به دلیل استفاده از LLM اشاره می‌کند.

برای مقابله با این موضوع، سازمان‌ها باید این موارد را اجرا کنند:

۱. چرخش شیفت: دوره‌های استراحت اجباری و تخطی‌ناپذیر که مهندسان بدون هیچ کمک هوش مصنوعی کار کنند تا ذهنشان تیز بماند. این مشابه قوانین هوانوردی است که در هواپیماهای بزرگ، حضور کمک‌خلبان برای حفظ ایمنی الزامی است.
۲. حالت بررسی تصادفی (Spot-Check): فرآیندی که در آن یک بازبین دوم به‌طور مستقل لاگ‌های چت‌بات را بررسی کند تا یک حلقه بازخورد ایجاد شود که چه مقدار استراحت برای شناسایی توهمات مدل لازم است.
۳. تمرین مهارت‌ها: اختصاص بودجه برای آموزش‌های «دستی» تا «اثر کارگر بندر» رخ ندهد؛ همان‌طور که جرثقیل‌های مکانیکی باعث شدند کارگران بندر توانایی بلند کردن اجسام سنگین را به‌صورت دستی از دست بدهند، تکیه به هوش مصنوعی منجر به از دست رفتن مهارت‌های ذهنی می‌شود. کارکنان به «زمان باشگاه» برای تمرین‌های آگاهانه و غیراتفاقی نیاز دارند.
۴. منابع سلامت روان: پشتیبانی داخلی برای مقابله با «سوختگی مغزی ناشی از هوش مصنوعی» (AI Brain Fry) و «سایکوز هوش مصنوعی». نویسنده پیشنهاد یک «دوزیمتر شخصی هوش مصنوعی» را می‌دهد تا میزان استفاده تجمعی را ردیابی کند و هشدار دهد اگر چت‌بات شروع به صحبت درباره مفاهیمی مثل «رزونانس» کرد (مگر اینکه کاربر مهندس آکوستیک باشد).

فرضیه صفر بهره‌وری

نویسنده با ادعایی تکان‌دهنده پایان می‌بندد: ابزارهای هوش مصنوعی در مجموع ممکن است «صفر» ارزش ایجاد کنند. استدلال او این است که زمانی که صرف بازبینی خطاها و مدیریت عوارض جانبی می‌شود، تمام سرعت به‌دست‌آمده را می‌بلعد. نویسنده اشاره می‌کند در حالی که برخی ادعا می‌کنند هوش مصنوعی مفید است، او هنوز کسی را ندیده که با یک متدولوژی دقیق، نسبت هزینه/بهره‌وری اندازه‌گیری شده‌ای (مثلاً نسبت ۰.۷۵) ارائه دهد.

اگر این ابزارها واقعاً بهره‌ور بودند، نویسنده معتقد است آزمایشگاه‌ها با اشتیاق ابزارهای اندازه‌گیری و تایید را می‌ساختند، نه اینکه از آن‌ها فرار کنند. نبود این ویژگی‌ها نشان می‌دهد که آشکار کردن نسبت واقعی هزینه/بهره‌وری، تصویری «تیره و تار» را به کاربران و سرمایه‌گذاران نشان می‌داد؛ تصویری که ثابت می‌کند این ابزارها بیش از حد اشتباه می‌کنند و عموماً برای اهداف حرفه‌ای مناسب نیستند.

گام بعدی شما

• در کارهای حساس، به‌جای اعتماد به خلاصه، مستقیماً روی منبع (Citation) کلیک کنید و متن را بخوانید.
• برای کدنویسی، هرگز از حالت Auto-apply استفاده نکنید و تغییرات را در یک Diff-viewer بررسی کنید.
• هر روز یک ساعت را به «کار بدون هوش مصنوعی» اختصاص دهید تا مهارت‌های تحلیلی‌تان تحلیل نرود.

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