در مقاله قبل گفتیم که آمادگی برای هوش مصنوعی را نمیتوان فقط در سطح کل سازمان سنجید. سؤال بهتر این است که آیا سازمان برای یک مسئله مشخص آماده است یا نه.
حالا فرض کنیم در یک شرکت مهندسی یا EPC، تیم مهندسی با حجم زیادی از مشخصات فنی، دیتاشیتها، مدارک سازندگان و اسناد پروژههای قبلی سروکار دارد.
پیدا کردن یک الزام مشخص یا سابقه یک تصمیم فنی گاهی مستلزم جستوجو در چندین فایل و پوشه است.
پیشنهاد مطرح میشود:
یک دستیار هوش مصنوعی داشته باشیم که مهندس سؤالش را بپرسد و پاسخ را از میان اسناد فنی سازمان پیدا کند.
ایده جذاب است. اما آیا پروژه آماده شروع است؟
بیایید همانجا، قبل از انتخاب ابزار، موضوع را بررسی کنیم.
مسئله را کوچکتر کنیم
«دسترسی به اطلاعات مهندسی سخت است» برای شروع هنوز خیلی کلی است.
ممکن است مشکل اصلی پیدا کردن سند باشد. ممکن است تشخیص آخرین نسخه دشوار باشد. شاید اطلاعات پروژههای قبلی بهدرستی دستهبندی نشدهاند. یا مهندسان برای پیدا کردن یک بند مشخص در میان چند سند زمان زیادی صرف میکنند.
هرکدام از این مسائل پاسخ متفاوتی میخواهد.
برای یک شروع محدود میتوان مسئله را اینطور تعریف کرد:
مهندس بتواند درباره یک موضوع فنی سؤال کند و سامانه، پاسخ مرتبط را همراه با نام سند و محل منبع در اختیار او قرار دهد.
حالا هم دامنه روشنتر شده و هم میتوان نتیجه را ارزیابی کرد.
لازم نیست از کل آرشیو شروع کنیم
فرض کنیم سازمان هزاران سند دارد.
اولین وسوسه این است که همه آنها وارد سامانه شوند تا دستیار به «تمام دانش سازمان» دسترسی داشته باشد.
برای شروع، این کار لزوماً مزیت نیست.
بهتر است ابتدا یک محدوده قابل کنترل انتخاب شود؛ مثلاً اسناد یک پروژه، یک رشته مهندسی یا حتی یک نوع مشخص از مدارک.
حالا میتوان چند سؤال عملی پرسید:
کدام اسناد معتبرند؟ نسخه جاری آنها مشخص است؟ فایلها قابل جستوجو هستند یا تعداد زیادی از آنها اسکن شدهاند؟ سطح دسترسی کاربران متفاوت است؟ آیا اسناد قدیمی وجود دارند که نباید مبنای پاسخ قرار گیرند؟
اگر همین مجموعه محدود قابل اعتماد نباشد، اضافه کردن اسناد بیشتر فقط مسئله را بزرگتر میکند.
نقش دستیار را از ابتدا محدود کنیم
در چنین پروژهای یکی از مهمترین تصمیمها این است که سامانه چه کاری قرار نیست انجام دهد.
در نسخه اولیه، دستیار میتواند اطلاعات را پیدا کند، بخش مرتبط سند را نشان دهد و منبع پاسخ را مشخص کند.
اما قرار نیست به جای مهندس تصمیم نهایی بگیرد.
برای مثال، اگر سؤال درباره یک الزام طراحی است، سامانه میتواند بند مرتبط Specification را پیدا کند؛ اما تفسیر آن در شرایط واقعی پروژه ممکن است همچنان به قضاوت مهندسی نیاز داشته باشد.
این مرزبندی مهم است.
هم ریسک را کمتر میکند و هم انتظار کاربران از سامانه را واقعیتر نگه میدارد.
حالا آن را وارد کار واقعی کنیم
فرض کنیم سامانه از نظر فنی آماده شده است.
به جای یک نمایش کنترلشده، بهتر است چند مهندس آن را با سؤالهایی امتحان کنند که واقعاً در کار روزانه با آن مواجه میشوند.
مثلاً:
«الزام مربوط به جنس این بخش از تجهیز در کدام سند آمده؟»
یا:
«در Specification پروژه درباره این آزمون چه الزاماتی وجود دارد؟»
حالا چند چیز را میتوان بررسی کرد:
آیا سامانه منبع درست را پیدا میکند؟ آیا پاسخ به سند اصلی قابل ردیابی است؟ آیا مهندس میتواند سریع صحت آن را کنترل کند؟ اگر اطلاعات کافی وجود نداشته باشد، سامانه این موضوع را اعلام میکند یا پاسخی ظاهراً مطمئن تولید میکند؟
اینجاست که تفاوت یک نمایش جذاب با یک ابزار قابل استفاده مشخص میشود.
موفقیت را با «کار کردن هوش مصنوعی» نسنجیم
هدف آزمایش این نیست که ثابت کنیم هوش مصنوعی میتواند به سؤال پاسخ دهد.
سؤال مهمتر این است:
آیا این راهکار، کار مهندس را بهتر میکند؟
برای این مثال، میتوان چند شاخص ساده تعریف کرد:
آیا زمان پیدا کردن اطلاعات کمتر شده است؟ آیا دسترسی به منبع معتبر سادهتر شده است؟ آیا پاسخها به سند اصلی قابل ردیابی هستند؟ کاربران در چه نوع سؤالهایی به سامانه اعتماد میکنند و در چه مواردی نه؟ آیا بعد از چند بار استفاده، همچنان ترجیح میدهند از آن استفاده کنند؟
ممکن است نتیجه نشان دهد فناوری مناسب است، اما اسناد سازمان نیاز به ساماندهی بیشتری دارند.
یا مشخص شود مشکل اصلی اصلاً پیدا کردن محتوا نیست و ضعف اصلی در مدیریت اسناد یا کنترل نسخههاست.
این نتیجه شکست پروژه نیست. برعکس، قبل از سرمایهگذاری بزرگتر یک واقعیت مهم را روشن کرده است.
در این مثال، چه زمانی شروع منطقی است؟
برای چنین دستیار مهندسی، لازم نیست کل سازمان به سطح بالایی از بلوغ هوش مصنوعی رسیده باشد.
برای شروع یک آزمایش محدود کافی است چند شرط برقرار باشد:
مسئله مشخص باشد. مجموعهای محدود از اسناد معتبر در دسترس باشد. چند کاربر واقعی در آزمایش حضور داشته باشند. مرز مسئولیت دستیار و مهندس روشن باشد. و از ابتدا بدانیم چه نتیجهای را موفقیت میدانیم.
اگر این شرایط وجود داشته باشد، میتوان با دامنه کوچک شروع کرد و از نتیجه برای تصمیم بعدی استفاده کرد.
اما اگر هنوز نمیدانیم دقیقاً چه مشکلی را حل میکنیم، اسناد معتبر کداماند یا چه کسی قرار است از نتیجه استفاده کند، اضافه کردن فناوری مسئله را حل نخواهد کرد.
ارزیابی آمادگی قرار نیست مانع شروع شود؛ قرار است کمک کند درست شروع کنیم.
و اگر این آزمایش موفق باشد، تازه سؤال بعدی مطرح میشود:
چطور یک نمونه آزمایشی را به راهکاری تبدیل کنیم که واقعاً در سازمان استفاده شود؟
این موضوع مقاله بعدی است: چرا بسیاری از پروژههای هوش مصنوعی در صنعت از مرحله نمونه آزمایشی عبور نمیکنند؟