Bab 9 Multiple Classification Ripple Down Rules
9.6 Mendapatkan Kondisi Rule – Validasi Rule
Verifikasi dan validasi kita perhatikan dengan pemastian bahwa sebuah sistem SBP berjalan seperti yang diinginkan.
95
Pendekatan normal dalam verifikasi mencoba untuk mengurangi KB ke jalur-jalur path dari data ke konklusi dan lalu melihat hubungan diantara jalur-jalur path, data yang digunakan, konklusi level menengah yang ada, dan lain-lain.
Validasi dalam istilah perawatan dan akuisisi bertingkat, berkaitan dengan pengetesan apakah case-case yang lain yang telah dikoreksi dengan benar sebelumya akan salah diklasifikasi dengan rule yang baru, seperti halnya pemastian rule baru melingkupi case baru.
Disini kita akan lebih membahas mengenai validasi, khususnya dalam memvalidasi SBP dengan mengetesnya pada case-case yang ada.
Teknik standar yang digunakan adalah sebuah database dari case-case standar. Dalam situasi ini kita tergantung pada case-case yang direpresentasikan oleh case yang sistem maksudkan untuk dicakup. Dengan RDR, suatu case diasosiasikan dengan sebuah rule sebab rule ditambahkan untuk berhubungan dengan case tertentu itu. Sebuah rule baru harus dibedakan diantara case yang menyebabkan dibuatnya rule baru tersebut dan case yang diasosiasikan dengan rule yang memberikan klasifikasi salah sebelumnya.
Dengan MCRDR, sejumlah case (cornerstone cases) dapat mencapai sebuah rule baru dan yang lebih tinggi dalam tree maka lebih banyak case dapat mencapai rule. Rule baru seharusnya dapat dibedakan antara case baru dan semua cornerstone cases. Maka dari itu, MCRDR mempunyai banyak cornerstone cases (multiple cornerstone cases) untuk sebuah rule, dibandingkan dengan RDR (Single Multiplication RDR) yang hanya mempunyai satu cornerstone case untuk setiap rule.
Sebuah rule pada suatu level dapat diproses dengan semua case yang diasosiasikan dengan saudara-saudaranya pada level yang sama dan level anak-anaknya yang lebih rendah dalam sistem. Sehingga, rule harus dibuat layak secara spesifik sehingga tak satu pun dari case-case yang lain memenuhi rule. Namun demikian, tak jadi masalah jika case-case yang lain yang memiliki klasifikasi yang sama mencapai rule tertentu ini. Jika sebuah rule ditambahkan pada level di bawah level puncak, hanya case-case yang memenuhi syarat rule orang tua di atasnya yang perlu untuk dipertimbangkan sebagai cornerstone case. Sebagai catatan disaat sistem dikembangkan, case-case yang lain mungkin muncul yang memenuhi rule dengan benar, tetapi mungkin ditambahkan ke sistem disebabkan sebuah rule diperlukan di tempat lain untuk menambahkan klasifikasi lebih lanjut. Case seperti ini akan menjadi sebuah cornerstone case untuk rule baru di bawah rule yang memenuhi dan untuk mana klasifikasi adalah benar. Saat tree dikembangkan, rule-rule di bagian bawah akan secara alami memiliki lebih sedikit cornerstone case yang diasosiasikan dengan mereka.
96
hanya case yang akan ditambahkan dan tak ada case lain yang sudah disimpan, kecuali bahwa adalah tidak penting jika ini terjadi untuk memenuhi case-case yang termasuk pada klasisfikasi yang sama. Algoritma untuk pemilihan kondisi untuk membuat rule layak dan tepat adalah sangat sederhana.
Dimisalkan case baru A dan dua cornerstone case B dan C. Dalam pembuatan rule baru, kita dapat membayangkan bahwa pakar harus memilih paling tidak satu diantara
kondisi-kondisi dari
(Case A – (Case B ∪ Case C))
atau
negasikan kondisi-kondisi dari ((Case B ∩ Case C) - Case A)
Namun demikian, seperti terlihat pada gambar 9.4, ini bisa saja kosong – mengarah pada situasi dimana tak ada satu pun kondisi rule dapat ditemukan. Alternatifnya daftar
perbedaan mengandung hanya kondisi yang sepele yang tak relevan. Dengan kata lain tak ada kondisi yang sama yang membedakan case baru yang disediakan dari semua
cornerstone case, tetapi sejumlah kondisi yang berbeda membedakan case-case yang berbeda dan kondisi-kondisi ini harus dilibatkan dalam rule-rule baru.
Dalam gambar 9.4 terlihat dua case yang mirip dimana daftar perbedaan akan ditemukan untuk membedakan case yang disediakan (case A) dari dua cornerstone case B dan C. Perlu dicatat dalam bagian (a) perbedaan diantara case yang disediakan dan irisan dari case-case lain memperlihatkan kondisi yang pantas. Untuk bagian (b) rule baru harus melibatkan kondisi dari kedua daftar perbedaan diantara A dan B dan dari daftar perbedaan diantara B dan C.
97
Gambar 9.4 Diagram case A dan cornerstone case B dan C
Algoritma yang digunakan adalah sebagai berikut ini. Pertama, sistem dapat membentuk daftar cornerstone case yang dapat mencapai rule baru dan harus dibedakan dari case yang disediakan. Pakar ditanyai untuk memilih dari daftar perbedaan diantara case yang tersedia dan satu dari cornerstone cases dalam daftar cornerstone cases yang telah ada.
Sistem lalu mengetes semua cornerstone case dalam daftar dibandingkan dengan kondisi-kondisi yang terpilih dan menghapus cornerstone case dari daftar yang tak memenuhi kondisi yang terpilih.
Selanjutnya pakar ditanyai untuk memilih kondisi-kondisi dari daftar perbedaan diantara case yang ada saat ini dan satu dari cornerstone case yang tersisa dalam daftar.
Kondisi-kondisi yang terpilih ditambahkan sebagai penghubung ke rule. Sistem mengulangi proses ini sampai tak ada lagi cornerstone case dalam daftar yang memenuhi rule.
Pertanyaan krusial untuk evaluasi berikut ini adalah apakah proses ini membutuhkan terlalu banyak langkah dari penambahan kondisi-kondisi ke rule-rule.
Setelah sistem menambahkan sebuah rule dengan kondisi-kondisi terpilih, ia mengetes cornerstone case yang tersisa yang diasosiasikan dengan parent rule dan sembarang case yang dapat memenuhi rule baru lalu disimpan sebagai cornerstone case dari rule baru. Perlu dicatat lagi bahwa dibolehkan untuk case-case yang melibatkan klasifikasi yang diberikan oleh rule untuk memenuhi rule, dan cornerstone case yang telah disimpan melibatkan case-case ini.
98
Akhirnya case baru ditambahkan ke data base cornerstone case. Daftar dari cornerstone case untuk rule-rule yang lain yang secara benar dipenuhi oleh case (yaitu yang
memberikan klasifikasi yang benar untuk case ini) juga diupdate untuk melibatkan case baru ini. Sistem sekarang siap untuk menjalankan case yang lain dan, jika
klasifikasi-klasifikasi yang ada adalah tidak benar/salah, untuk akuisisi pengetahuan lebih banyak lagi.
Sistem MCRDR dikembangkan untuk seluruh domain atau secara bertahap, sub-domain pada waktu tertentu untuk mencegah tuntutan-tuntutan pada sang pakar. Sehingga case yang memiliki lebih dari satu klasifikasi mungkin hanya memberikan satu klasifikasi awal. Dalam hal penanganan dengan sub-domain secara bertahap, algoritmanya adalah sama kecuali untuk kebutuhan konsultasi ekstra sang pakar yaitu apakah klasifikasi baru
diaplikasikan untuk setiap cornerstone case yang dapat memenuhi rule. Namun demikian, fitur yang tertinggal adalah rule menjadi lebih tepat untuk mengeluarkan case yang spesifik, case-case lain yang juga dikeluarkan tak akan lagi dipertimbangkan lebih lanjut.
99