قابلیت اطمینان هوش مصنوعی با اعتماد کور به دست نمی آید

کارشناس پشتیبانی پاسخ دستیار را می خواند و می فهمد یک بند مهم از سیاست جا افتاده است. دکمه ارجاع به انسان هم وجود دارد، اما کسی نگفته کارشناس دقیقا چه چیزی را باید وارسی کند. داشبورد سبز است و سامانه «فعال» به نظر می رسد؛ با این حال پاسخ نادرست راهش را تا مشتری پیدا کرده است.

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

گزارش وضعیت مهندسی عامل های LangChain در ۲۰۲۶ می گوید ۵۷ درصد پاسخ دهندگان عامل هایی در محیط عملیاتی داشتند و کیفیت همچنان مانعی مهم بود. گزارش مهندسی هوش مصنوعی Datadog در ۲۰۲۶ هم از سامانه هایی با مدل ها، ابزار ها، تلاش دوباره، کنترل هزینه و وابستگی های چندسرویسی می گوید. با چنین سامانه ای، اعتماد با یک علامت سبز یا جمله «انسان در چرخه است» ساخته نمی شود.

حفاظ فقط وقتی مفید است که کارش معلوم باشد

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

به جای پرسیدن «حفاظ داریم؟» بپرسید چه چیزی ممکن است با وجود آن خراب شود. چه کسی نخستین نشانه را می بیند؟ اگر پاسخ به سندی نامربوط متکی بود چه می شود؟ چه کسی اجازه دارد ابزار را خاموش کند؟ کاربر در زمان توقف سامانه چطور کارش را ادامه می دهد؟

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

پاسخ روان می تواند خرابی را پنهان کند

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

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

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

هرچه رابط مطمئن تر و طبیعی تر به نظر برسد، بازبینی باید روشن تر طراحی شود.

پروتکل نگرانی را به اقدام وصل می کند

نشانه های ضعیف اغلب پیش از خرابی بزرگ دیده می شوند: کارشناسان پاسخ های بیشتری را اصلاح می کنند، کاربران می گویند «معمولا درست است، ولی دوباره چک می کنم»، یا عامل برای یک کار گام های بیشتری برمی دارد. اگر هیچ قاعده ای برای واکنش نداشته باشیم، فشار تحویل باعث می شود این نشانه ها عادی شوند.

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

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

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

ارزیابی و مشاهده پذیری را وارد کار روزانه کنید

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

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

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

ثبت این اطلاعات باید با حریم خصوصی و دسترسی متناسب باشد: چه چیزی ثبت می شود، چه کسانی می بینند و چه مدتی نگه داشته می شود، خود بخشی از طراحی است.

تایید انسانی را واقعی کنید

«انسان در چرخه» گاهی یعنی کارشناس شواهد را با دقت می بیند؛ گاهی فقط یعنی کسی در صف طولانی روی تایید کلیک می کند. این دو یکی نیستند.

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

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

خرابی را تمرین کنید

سند پاسخ به رخداد ممکن است تا روز رخداد کامل به نظر برسد. بعد معلوم می شود هشدار به کانال اشتباه می رود، مسئول خاموش کردن سامانه در دسترس نیست یا نسخه ای که قرار بوده بازیابی شود دیگر وجود ندارد.

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

هدف نمایش بی نقص نیست؛ پیدا کردن ضعف وقتی هنوز پیامد واقعی ندارد. تیم ها با همین تمرین یاد می گیرند که حفاظ و داشبورد جای آمادگی را نمی گیرند.

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

مهدی لطفی نژاد متخصص داده و هوش مصنوعی، مشاور و مدرس رسمی با نزدیک به ۲۰ سال تجربه صنعتی است. او به صدها متخصص در خاورمیانه و جنوب شرق آسیا آموزش داده و در DATATWEETS می نویسد تا این تجربه عملی را رایگان و خودآموز در اختیار همه بگذارد.