dengan “Ya” atau “Tidak”. Ketika diminta untuk memberika penjelasan, penjelasan yang diberikan sangat jarang dan singkat. knowledge engineers ragu apakah Mr
Kelly mau untuk bekerja sama untuk mejelaskan lebih dalam tentang ilmu dan keahlian yang dipunyainya.
Setelah itu semua Knowledge Engineers berusaha untuk membuah prototype tetapi dengan hasil yang sangat jauh dari sempurna. Akhirnya Knowledge Engineers
memutuskan untuk melakukan survei ke bendungan. Setelah satu tahun knowledge base sistem pakar yang ada terdiri dari 20 aturankaidah yang memberikan solusi
yang tidak bagus. Karena terbatasnya waktu dan dana yang ada maka Texas Instrument memutuskan bahwa sistem pakar yang dibuat hanya digunakan untuk
Bendungan Vermillion dan aturan yang dibuat mencapai 80 aturan. Sistem pakar yang dihasilkan tidak bisa bekerja dengan baik dan pegawai Southern California
Edition harus bekerja lebih keras agas sistem pakar tersebut berguna dengan baik. Dari kegagalan tersebut dapat diperoleh beberapa faktor yang mempengaruhinya
yaitu : 1. Penugasan Knowledge Engineers yang kurang berpengalaman.
2. Pertemuan pertama yang melelahkan selama 7 jam. 3. Keterlambatan survai lokasi survai idealnya dilakukan sedini mungkin atau
sebelum tahap knowledge acquisiton 4. Ketidakbisaan Knowledge Engineers untuk mengatasai keengganan domain
expert untuk memberikan penjelasan yang detail. 5. Ketidakbisaan knowledge engineer untuk membangun hubungan yang saling
menghormati antara domain expert dan Knowledge Engineers.
2.14 Knowledge Engineers sebagai Domain Expert
Seperti pada permasahalan yang dijelaskan sebelumnya, pemilihan seorang pakar mungkin akan menjadi masalah pada tahap knowledge acquisition.
Permasalahan yang timbul mungkin pakar meninggal dunia ataupun keluar dari perusahaan. Untuk permasalahan seperti ini kita mempunyai paling tidak 2 pilihan
yaitu : 1. Menggunakan data historis untuk mengembangkan rule-based sistem pakar.
2. Menjadi domain expert sendiri. Dalam literatur sistem pakar tidak ada larangan untuk menjadi domain expert sendiri,
apabila pendekatan ini lebih baik maka ini akan menghasilkan hasil yang baik.
Kenyataannya R1 dan XCON dikembangkan dengan domain expertnya adalah Knowledge Engineers.
2.15 Domain Expert sebagai Knowledge Engineers
Kalau Knowledge Engineers bisa bertindak sebagai domain expert maka begitu pula sebaliknya, domain expert bisa bertindak sebagai Knowledge Engineers,
karena kenyataannya tujuan utama dari sistem pakar adalah menyediakan paket pengembangan yang berinteraksi langsung dengan domain expert, ini dimaksudkan
untuk menghilangkan kebutuhan akan Knowledge Engineers. Walaupun begitu tujuan ini belum sepenuhnya terealisasi, meskipun demikian ada klaim yang
menyatakan bahwa ini dapat diduga pada bebrapa tahun yang akan datang. Ada beberapa kesuksesan dalam pelatihan domain expert untuk
mengembangkan rule based dan mengimplementasikan rule based ini pada beberapa paket pengembangan. Beberapa perusahaan melaporkan ada
perkembangan yang cukup berarti pada keseluruhan produktifitas dari pengembangan beberapa sistem pakar dengan rule based kecil yang dikerjakan
oleh domain expertnya. Ada beberapa hal yang harus dijauhkan dari pendekatan ini, yaitu :
1. Butuh waktu dan dana yang digunakan untuk melatih domain expert. 2. Setelah domain expert dilatih kemungkinan beberapa domain expert cenderung
untuk menyelesaikan sebagian dan seluruh permasalahan dalam sistem pakar, bahkan lebih efektif, efisien dan sesuai dengan kebutuhan.
Dengan pendekatan ini knowledge engineer mungkin tinggal mengadakan training dan bimbingan dalam pengembangan rule based, pendekatan ini pada dasarnya
digunakan oleh beberapa perusahaan. Dengan pendekatan ini perusahan bisa memberikan catatan bahwa memberikan training kepada domain expert lebih murah
dibandingkan harus membentuk sebuah divisi Knowledge Engineers, kelebihan yang lainnya adalah bahwa lebih praktis melatih domain expert tentang sistem pakar
membutuhkan waktu yang lebih sedikit dari pada melatih knowledge engineer untuk mempelajari permasalahan pada domain tertentu, walaupun pendapar ini belum
tentu benar, karena masih tergantung dengan situasi dan kondisi yang ada. Ada pendapat lain yang menyatakan bahwa seorang knowledge engineer hanya butuh
untuk menjadi familiar dengan permasalahan yang ada, Knowledge Engineers tidak perlu menjadi seorang pakar untuk mengembangkan sebuah sistem pakar.
Menurut pendapat kami, cara yang lebih bagus adalah dengan menyediakan beberapa tingkat pelatihan tentang sistem pakar yang cukup sehingga domain
expert dapat mengerti dengan tujuan, scope, dan batasan-batasan dalam sistem pakar, juga menjadi lebih mengeti untuk mengidentifikasi permasalahan yang ada
sehingga sistem pakar yang dikembangkan akan lebih sesuai dengan kebutuhan.
2.16 Knowledge Acquisition dengan Rule Induction
