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

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

مدیریت پروژه

انتظار می رود مدیریت پروژه، موارد ذیل را تأمین نماید. در حقیقت مدیریت پروژه، خود یکی از موضوعات مورد نظر طراحات سیستمها خبره بوده است.

مدیریت منابع

تخمین منابع مورد نیاز

منابع در دسترس

تعیین مسئولیتها برای استفاده بهینه از منابع

تهیه و تدارک منابع بحرانی برای به حداقل رساندن گلوگاه ها

فعالیتهای لازم برای ایجاد یک سیستم خبره، آن دسته از وظایفند که برای ساخت سیستم لازمند. شکل ۲-۶ یک نگرش سطح بالا از فعالیتهای لازم برای ساخت سیستم را نشان می دهد که شامل مراحلی است که سیستم باید از آنها عبور کند.

مسئله تحویل

سیستم چگونه تحویل داده خواهد شد؟

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

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

حالت ایده آل آن است که سیستم خبره تحویل شده را بتوان روی سخت افزار استاندارد اجرا نمود. ولی بعضی ابزارهای سیستم خبره به یک ریزپردازنده LISP خاص نیاز دارند که هزینه را تا حد زیادی افزایش می دهد.

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

نگهداری و تکامل

چگونه سیستم تکامل یافته و از آن نگهداری می شود؟

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

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

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

خطاها در مراحل ایجاد

همان طور که شکل ۳-۶ نشان می دهد، خطاهای عمده ای که احتمالا در ایجاد سیستم خبره رخ می دهد. با تشخیص مرحله ای که احتمال بروز آن خطا بیشتر است دسته بندی می شود. این خطاها شامل موارد زیر هستند.

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

در پروژه هایی که ماموریت حساسی به عهده دارند و زندگی یا اموال افراد در خطر است، ممکن است لازم باشد از یک رویه رسمی برای تصدیق دانش فرد خبره استفاده شود. یکی از روشهای موفقیت آمیزی که ناسا برای پروازهای فضایی بکار برد استفاده از کمیته فنی پرواز بود که به طور منظم، راه حل مسائل و روشهای تحلیلی بکار رفته در ایجاد راه حلها را مورد بازنگری قرار می داد (Culbert 87). کمیته های فنی از کاربران سیستم، افراد خبره در زمینه های مستقل از هم، سازندگان سیستم و مدیران تشکیل می شود تا همه زمینه های ایجاد سیستم به طور موثر پوشش داده شود.

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

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

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

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

خطاهای موتور استنتاج. مانند هر قسمتی از یک نرم افزار، موتور استنتاج نیز ممکن است دچار خطا شود. اولین باری که یک ابزار سیستم خبره جهت استفاده عمومی آماده می شود باید کلیه خطاهای عمومی آن برطرف شده باشد. ولی گاه خطاهایی وجود دارند که فقط در شرایطی بسیار نادر بروز می کنند که به عنوان مثال قرار گرفتن ۱۵۹ قاعده در دستور کار از آن جمله است. ممکن است بعضی خطاها بسیار ظریف باشند و فقط در تطبیق خاصی از قواعد با واقعیات بروز کنند. به طور کلی خطاهای موتور استنتاج ممکن است در تطبیق قواعد با واقعیات، رفع تناقض و اجرای فعالیتها روی دهند. اگر این خطاها به طور پیوسته رخ ندهند تشخیص آنها بسیار دشوار است. وقتی از ابزار سیستم خبره برای مأموریتهای حساس استفاده می کنید باید مشخص کنید که ابزار چگونه معتبر می شود.

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

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

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

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

مهندسی نرم افزار و سیستمهای خبره

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

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

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

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

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

تشریح کلمه کیفیت به صورت کلی دشوار است زیرا این کلمه برای افراد معانی گوناگونی دارد. یکی از تعاریف کیفیت این است که آن را به صورت مشخصه های لازم یا مطلوبیک شی تعریف کنیم که در مقیاسهای خاصی تعیین شده است. کلمه شی در اینجا به معنای هر نوع سخت افزار یا نرم افزار یا محصولات نرم افزاری است. مشخصه ها و مقادیر آنها شاخص نامیده می شوند زیرا از آنها برای اندازه گیری اشیاء استفاده می شود. به عنوان مثال، قابلیت اطمینان اندازه گیری شده یک دیسک درایو، شاخصی برای کیفیت آن است. یکی از معیارهای این مشخصه، متوسط زمان بین خرابی (MTBF) درایوهاست. MTBF یک درایو قابل اطمینان، حدود ۱۰۰۰ ساعت است، در حالی که برای یک درایو غیر قابل اطمینان ممکن است حدود ۱۰۰ ساعت باشد.

جدول ۱-۶ فهرستی از چند شاخص ارائه داده است که ممکن است در ارزیابی کیفیت یک سیستم خبره کاربرد داشته باشند. این شاخصها فقط جنبه راهنما دارند زیرا یک سیستم خبره مخصوص ممکن است برخی از این شاخصها یا شاخصهای دیگری داشته باشد. در هر حال بهتر است که فهرستی از شاخصهای لازم تهیه شود تا از آن بتوان در تشریح کیفیت استفاده کرد.

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

چرخه حیات سیستم خبره

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

هزینه های نگهداری

برای نرم افزارهای معمولی، معمولا ۶۰ تا ۸۰ درصد کل هزینه نرم افزار مربوط به هزینه نگهداری است که حدود ۲ تا ۴ برابر هزینه ایجاد سیستم است. اگر چه هنوز به دلیل جدید بودن سیستمهای خبره، اطلاعات کمی درباره نگهداری آنها در دست است ولی احتمالا برای سیستمهای خبره ارقام فوق صادق نیستند. اگر برنامه های معمولی با الگوریتم های شناخته شده نیاز به چنین هزینه زیادی جهت نگهداری دارند احتمالا سیستمهای خبره نیاز به هزینه بیشتری خواهند داشت زیرا این سیستمها مبتنی بر دانش تجربی و هیوریستیکها هستند. سیستمهای خبره ای که حجم بالایی از استنتاجها را در شرایط عدم اطمینان انجام می دهند هزینه نگهداری و ارتقاء بالاتری را می طلبند.

مدل آبشاری

برای نرم افزارهای معمولی، مدلهای چرخه حیات متعددی ایجاد شده است. مدل آبشاری کلاسیک، مدل اصلی چرخه حیات است که در شکل ۵-۶ نمایش داده شده است. این مدل برای برنامه نویسان نرم افزارهای معمولی بسیار آشنا است. در مدل آبشاری هر مرحله با یک فعالیت تصدیق و اعتبارسنجی (V&V) پایان می یابد تا مشکلات آن مرحله به حداقل برسد. همچنین دقت کنید که پیکانها فقط یک مرحله به جلو یا عقب می روند. این موضوع سبب می شود تا ایجاد دوباره سیستم بین دو مرحله مجاور، حداقل هزینه را در برداشته باشد در حالیکه ایجاد دوباره سیستم طی چند مرحله هزینه بالاتری در پی خواهد داشت.

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

۱) بعد از این کار چه کاری باید انجام شود؟

۲) مرحله بعد طی چه مدت زمانی انجام می شود؟

مدل پردازش عملا یک فوق اسلوب یا فرا روش شناسی است زیرا ترتیب و مدت زمان لازم جهت اجرای روشهای نرم افزاری را مشخص می کند. روشهای ایجاد نرم ازار (متدولوژیها) موارد زیر را نشان می دهند.

روشهای خاص برای انجام یک مرحله نظیر

برنامه ریزی

احتیاجات

کسب دانش

آزمونها

نمایش محصول هر مرحله

مستندسازی

کد نویسی

نمودارها

مدل کدنویسی و اصلاح

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

از سال ۱۹۷۰ نقایص روش کدنویسی و اصلاح بخوبی مشهود شده بود و لذا مدل آبشاری برای ارائه یک روش سیستماتیک پدید آمد. این روش به ویژه برای پروژه های بزرگ مفید بود. ولی روش آبشاری نیز با مشکلاتی همراه بود زیرا در این مدل فرض می شود که همه اطلاعات لازم برای یک مرحله وجود دارد. اغلب مواقع در عمل این مکان وجود ندارد که بتوان یک بخش خاص را به طور کامل نوشت مگر اینکه قبلا یک نمونه آزمایشی از سیستم ساخته شده باشد. این موضوع موجب پدیدار شدن مفهوم جدیدی شد: «آن را دوبار انجام دهید.» یعنی در ابتدا با ساخت یک نمونه، احتیاجات را مشخص کرده و سپس سیستم اصلی را بسازید.

مدل افزایشی

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

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

مدل مارپیچی

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

سیستم خبره قسمت 1
سیستم خبره قسمت 2
سیستم خبره قسمت 3
سیستم خبره قسمت 4
سیستم خبره قسمت 5
سیستم خبره قسمت 6