وقتی پروژه هوش مصنوعی از کار می افتد، کدام فرض پنهان مانده بود؟

وقتی دستیار پاسخ نادرست می دهد، معمولا اولین سوال این است: «چه چیزی خراب شد؟» سوال لازم دیگری هم هست: «سامانه به چه چیزی تکیه داشت که کسی بررسی اش نکرد؟»

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

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

از رخداد به زنجیره برسید

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

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

هر پاسخ یک فرض یا کنترل را آشکار می کند. فهرست کوتاهی از فرض ها برای چنین دستیاری می تواند این ها را در بر بگیرد:

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

این فهرست نسخه همگانی نیست. کاربرد و پیامد خطا تعیین می کند کدام فرض ها اهمیت بیشتری دارند.

نمونه اولیه سوال آسان تری می پرسد

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

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

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

این تصویر یادآوری می کند که پروژه فقط مدل نیست. هر جزء تازه یک وابستگی و یک فرض تازه می آورد. هرچه سامانه پیچیده تر شود، پاسخ نهایی به تنهایی برای فهمیدن علت خرابی کافی نیست.

باور را به آزمون تبدیل کنید

اگر تیم فکر می کند بازیابی خوب است، چند پرسش نماینده و سند های مورد انتظار را ثبت کند. اگر می گوید تغییر دستور پاسخ ها را بهتر کرده، پیش و پس از تغییر مورد های قبلی را اجرا کند. اگر مدل ارزان تری را جایگزین می کند، کیفیت، هزینه و زمان پاسخ را روی همان وظیفه بسنجد. هدف ساختن نمره کامل نیست؛ باید فرض های اثرگذار را قابل بررسی کرد.

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

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

مسئولیت را هم مانند داده ثبت کنید

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

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

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

رخداد را به اصلاح سامانه تبدیل کنید

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

برای یک پروژه کوچک هم می توانید از این پرسش ها شروع کنید: درباره داده چه فرض کرده ایم؟ درباره رفتار مدل و کاربران چطور؟ چه چیزی هزینه یا زمان پاسخ را تغییر می دهد؟ پس از راه اندازی مالک سامانه کیست؟ کدام نشانه باعث توقف یا بازبینی می شود؟

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

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