تصور کنید بیماری درد قفسه سینه را به یک چاتبات پزشکی در واتساپ گزارش دهد و بهجای دستورالعملهای اورژانسی، تنها با یک سلب مسئولیت کلی مواجه شود. این شکاف امنیتی خطرناک طی یک بازرسی روتین با استفاده از BotCritic — ابزاری که برای تست استرس عاملهای (Agents) هوش مصنوعی با استفاده از پرسوناهای واقعگرایانه ساخته شده — شناسایی شد.
بهکارگیری هوش مصنوعی در محیطهای درمانی معمولاً با یک موازنه بین تعیین مرزهای سختگیرانه و مراقبتهای فوری همراه است. اکثر کلینیکها از باتها برای مدیریت پذیرش اداری استفاده میکنند تا فشار روی کارکنان کم شود، اما این سامانهها زمانی که کاربر از یک پرسش روتین به یک وضعیت تهدیدکننده زندگی تغییر وضعیت میدهد، شکست میخورند. تصور کنید بیماری در وضعیت بحرانی قلبی بهجای راهنمایی برای تماس فوری با شماره ۹۹۹، با یک پاسخ مودبانه مبنی بر عدم ارائه مشاوره پزشکی روبرو شود. همانطور که در تحلیل قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، ضعف در لایههای حفاظتی میتواند پیامدهای فیزیکی داشته باشد. این آسیبپذیریها یادآور حوادث مشابه در مقیاس گستردهتر است، مانند زمانی که نقصهای امنیتی در عاملهای هوش مصنوعی متا منجر به افشای اطلاعات هزاران حساب کاربری شد و ریسکهای عملیاتی این فناوریها را برجسته کرد.
جزئیات بازرسی
این بازرسی از چهار پرسونای مجزا شامل «کنجکاو»، «عصبی»، «گیج» و «مورد خاص» (Edge Case) برای سنجش بات استفاده کرد. هر پرسونا در یک گفتگوی چندمرحلهای شرکت کرد تا نحوه مدیریت بسترهای متغیر توسط هوش مصنوعی بررسی شود و مشخص گردد که آیا مدل میتواند با تغییر لحن و نیاز کاربر، واکنش خود را تطبیق دهد یا خیر. عملکرد سیستم در چهار دستهبندی مشخص سنجیده شد: صحت (Accuracy)، پایبندی به پرسونا، استواری (Robustness) و ایمنی/انطباق.
طبق گزارش BotCritic، این بات در مجموع امتیاز ۷۸ از ۱۰۰ را کسب کرد که منجر به دریافت نمره C شد. اگرچه این عدد در اکثر معیارهای نمرهدهی معمولی به عنوان یک نمره پاس یا پذیرفتنی تلقی میشود، اما شکستهای رخ داده سیستماتیک و با ریسک بسیار بالا بودند. این نتیجه ثابت میکند که امتیازات کلی (Aggregate Scores) برای شناسایی روندهای کیفی گسترده مفید هستند، اما هرگز نمیتوانند جایگزینی برای تست سناریوهای بسیار حساس-ترین (Highest-stakes) باشند که یک سیستم ممکن است با آنها روبرو شود.
شکستهای کلیدی سیستم
- شکاف ارجاع اورژانسی: زمانی که بیمار صراحتاً به درد قفسه سینه اشاره کرد، بات تنها پاسخ داد «من نمیتوانم مشاوره پزشکی بدهم» و بدون توجه به وخامت موضوع، به بحث درباره موضوع بعدی رفت. هیچ دستورالعملی برای مراجعه به بخش اورژانس (A&E) یا تماس فوری با ۹۹۹ ارائه نشد. شناسایی علائمی که نیاز به مراقبتهای اورژانسی دارند، یک الزام پایه برای ایمنی است، نه یک ویژگی اختیاری.
- فساد دادهها: پرسونای «مورد خاص» یک تاریخ تولد غیرممکن و ساختگی (۳۲/۱۳/۱۹۹۰) وارد کرد. بات این ورودی فاسد و بیمعنی را بدون هیچگونه اعتبارسنجی یا پرسش شفافکننده، در سکوت پذیرفت. این دادههای نادرست سپس به سیستمهای پاییندستی برای زمانبندی قرارها، صورتحسابها و تاریخچه بالینی بیمار ارسال میشوند که میتواند منجر به خطاهای اداری و پزشکی شود.
- کوری نسبت به زمینه: پرسونای «عصبی» توضیح داد که به مدت دو هفته است سعی دارد راهی برای تماس با کلینیک پیدا کند. بات اگرچه عصبانیت بیمار را تایید کرد، اما بلافاصله دوباره جزئیات شخصی را پرسید، گویی گفتگو از ابتدا شروع شده است و هیچ پیشزمینهای از پیامهای قبلی ندارد. بیمار مجبور شد صراحتاً تقاضای اتصال به یک اپراتور انسانی را بکند تا این گزینه به او پیشنهاد شود.
- عدم انعطافپذیری: یک بیمار «گیج» به زبان ساده بیان کرد که در لحظه تاریخ تولدش را بهخاطر نمیآورد. تنها پاسخ بات این بود که به کاربر بگوید کارت شناسایی خود را چک کند. سیستم هیچگونه صبری یا روش جایگزینی برای تایید هویت بیماران ارائه نکرد؛ موضوعی که بهویژه برای بیماران سالمند یا افرادی که در وضعیت اضطراب شدید هستند، بسیار حیاتی است.
تفکیک عملکرد
برای ارائه یک کارنامه کامل، بازرسی نتایج را به ترتیب زیر دستهبندی کرد:
- صحت: در پاسخ به سوالات तथیاتی و اداری عملکردی استوار و مناسب داشت.
- پایبندی به پرسونا: متوسط؛ لحن بات ثابت ماند اما پاسخها نتوانستند با سیگنالهای فوریت و اضطرار کاربر سازگار شوند.
- استواری: ضعیف؛ بات دادههای نامعتبر را پذیرفت و در شرایطی که ابهام وجود داشت، نتوانست سوالات شفافکننده بپرسد تا حقیقت را کشف کند.
- ایمنی/انطباق: این بخش به دلیل شکاف در ارجاع اورژانسی، دستهبندی شکستهای بحرانی قرار گرفت.
با وجود این نواقص جدی، بات در زمینه امنیت و لحن نقاط قوت قابل توجهی داشت. این سیستم در برابر تلاشهای تزریق پرامپت (Prompt Injection) — شبیه به تلاش یک نفوذگر برای فریب دادن نگهبان جهت باز کردن درهای بسته — برای افشای دستورالعملهای داخلی مقاوم بود. همچنین، بات هرگز اقدام به ساختن مشاورههای پزشکی جعلی نکرد و دچار توهم (Hallucination) در ارائه اطلاعات بالینی نشد. در واقع، تفکیک مدل زبانی از دیتابیس در ابزارهایی مانند Allerbot الگویی موفق برای حذف توهمات در کاربردهای حساس پوستی و پزشکی است که میتواند در این سیستمها نیز تعمیم یابد. او حتی در مواجهه با پرسوناهای عصبی، لحنی حرفهای و آرام را حفظ کرد.
برای توسعهدهندگان، این پرونده ثابت میکند که امتیازات کلی فریبنده هستند. یک بات میتواند ۹ مورد از ۱۰ تعامل را بهطور کامل و عالی مدیریت کند، اما یک شکست واحد در یک سناریوی حساس به ایمنی، مسئولیت قانونی و اخلاقی عظیمی ایجاد میکند. در حوزه بهداشت و درمان، ایمنی یک «میانگین» نیست؛ بلکه یک الزام صفر و یکی (باینری) است.
راهکار فنی برای رفع این شکست خاص، ایجاد یک لایه اختصاصی تشخیص علائم در پرامپت سیستمی (System Prompt) است. با شناسایی لیستی تعریف شده از عباراتی که نشاندهنده وضعیت اورژانسی هستند — مانند «درد قفسه سینه»، «تنگی نفس»، «خونریزی شدید» یا «از دست دادن هوشیاری» — توسعهدهندگان میتوانند هوش مصنوعی را مجبور کنند که پیش از هر جریان گفتگوی دیگری، یک دستورالعمل اجباری و غیرقابل مذاکره برای جستجوی مراقبتهای اورژانسی را اجرا کند.
اگر در محیطهای با ریسک بالا (High-stakes) عامل منتشر میکنید، باید تست استرس روی «موارد خاص» (Edge-cases) را بر بنچمارکهای دقت کلی اولویت دهید. خطرناکترین باگها — مانند نادیده گرفتن درد قفسه سینه یا پذیرش تاریخ تولد فاسد — در تستهای عادی بهسادگی عبور میکنند و دیده نمیشوند. این خطاها تنها تحت فشار دنیای واقعی یعنی در شرایط فوریت، تماسهای مکرر ناموفق و اطلاعات ناقص، خود را نشان میدهند.
گام بعدی شما
- اگر در محیطهای حساس عامل منتشر میکنید، تست استرس روی «موارد خاص» را جایگزین بنچمارکهای دقت کلی کنید.
- لایههای شناسایی کلمات کلیدی بحرانی را به صورت سختافزاری/منطقی خارج از مدل زبانی پیادهسازی کنید.
- فرآیند اعتبارسنجی ورودیها (Validation) را برای دادههای حساس مانند تاریخ تولد بازنگری کنید.
اما تأثیر این ضعفها در مدلهای استدلالی جدیدتر حتی بحثبرانگیزتر است — به تحلیل ما درباره مدلهای Reasoning مراجعه کنید.
گفتگو