Tudásalapú rendszerek

Az előadások a következő témára: "Tudásalapú rendszerek"— Előadás másolata:

1 Tudásalapú rendszerek
Előadó: Kovács Zita 2016/2017. I. félév Ismeretalapú rendszerek építését támogató eszközök Ismeretalapú rendszerek készítésének fázisai

2 A tudásalapú rendszerek építése
feladat elemzése feladat szerkezetének meghatározása tudásszerzés A modellalkotás minden esetben a terminológia rögzítésével, ontológia szinten kezdődik. A tervezést követő rendszerépítés során javasolható technikai fogásokból nézünk meg néhányat (Harmon, 1990 alapján).

3 Tudásalapú rendszerek építése
Az előadás tartalma Tudásalapú rendszerek építése Célvezérelt rendszerek építése (példával) Adatvezérelt rendszerek építése (vázlat) Strukturált szabályalapú rendszerek építése (vázlat) Hibrid rendszerek építése (vázlat) Tudásalapú rendszerek verifikálása és validálása

4 Célvezérelt szabályalapú rendszerek építése
a kisméretű szabályalapú rendszerek többsége célvezérelt alkalmazási típusuk jellemzően diagnosztizáló - ezen belül osztályozó vagy kiválasztó példa: egy képmagnó vételénél tanácsot adó rendszer prototípusának inkrementális megépítése

5 A célvezérelt rendszerek építésének első lépései
a probléma elemzése és definiálása a probléma szerkezetének meghatározása az induló szabálykészlet kidolgozása a szabályok továbbfejlesztése, finomítása a következtetés és vezérlés „testreszabása”

6 1. A feladat elemzése és megadása A megoldandó feladat átfogó jellemzéséhez néhány szempont:
A rendszer célja: képmagnó kiválasztásában tanácsadás. Felhasználói kör: képmagnó eladással foglalkozó üzlet eladói (későbbiekben esetleg a vevők is) Szakértői kör: üzlet eladói A rendszer felhasználásának módja: eladók munkájának támogatása – intelligens feladatmegoldó segédletként Felhasználó (a vevő) jellemző igényei: pl. villogó fény, digitális kijelző, színes gombok, minél alacsonyabb ár, stb

7 1. A feladat elemzése és megadása A feladatmegoldás jelenlegi módja (Felhasználó, Bemenet -> Elemzés -> Kimenet, Javaslat): Bemenet: a vevők vételi szempontjai, preferenciái. A feladat elemzése: (azaz egy konkrét eladásnál a kiválasztás) segíti a vevők kikérdezése, a lehetőségek bemutatása, alternatívák felvetése, stb. Kimenet: az eladó által javasolható készülék(ek), a vevő kérésére megfelelő indoklással ellátva.

8 1. A feladat elemzése és megadása A feladatmegoldás jelenlegi módja (Felhasználó, Bemenet -> Elemzés -> Kimenet, Javaslat): Feladat elemzés (Szabályok, következtetések) Felhasználó Javaslat Bemenet Kimenet A vevő képmagnót szeretne vásárolni, és tanácsot kér. Az eladó kérdéseket tesz fel a vevőnek, hogy megtudja a vevő igényeit. Az eladó javaslatként megnevez egy v. több képmagnót, indoklással.

9 1. A feladat elemzése és megadása A feladatmegoldás módja a szakértő rendszer segítségével:
Elképzelhető, hogy egy későbbi rendszerváltozat az eladókat részlegesen/teljesen kiváltja a tanácsadásban. Emberi szakértő Probléma Javaslat Szakértő rendszer

10 1. A feladat elemzése és megadása A feladatmegoldás módja a szakértő rendszer segítségével:
Kulcs-kritériumok: Tárgyköri szakértő rendelkezésre áll: igen (kijelölt eladó) Tesztesetek rendelkezésre állnak: igen (az üzletben kapható képmagnók leíró adatai) Szűk, jól definiált a feladat: igen Verbális ismeretek jellemzőek: igen

11 1. A feladat elemzése és megadása A feladatmegoldás módja a szakértő rendszer segítségével:
Kizáró kritériumok: egyikkel sem kell számolni A feladat típusa: Diagnosztizáló: igen, ezen belül egyszerű kiválasztó jellegű A következtetés jellege: Célvezérelt: igen (kevés a javasolható készülék, azok kiválasztásához célzott kérdésekkel célszerű az adatokat – a felhasználói igényeket - bekérni)

12 1. A feladat elemzése és megadása A feladatmegoldás módja a szakértő rendszer segítségével:
Feladat megadása: A feladat egy képmagnókat árusító üzlet kínálatából a vevők igényeit kielégítő készülékre javaslatot tevő – ilyen értelemben az eladók munkáját segítő – tanácsadó rendszer megépítése. A rendszer a javaslat összeállítása során a szükséges információkat a vevő számára érthetően feltett kérdések révén szerzi be. A javaslatban szereplő készülékeket a rendszer megfelelően súlyozza, igény szerint megindokolva azok választását. A rendszer a későbbiekben kibővíthető egy, a kínálat változását követő szolgáltatással. Célszerű ez esetben egy olyan integrált tanácsadó rendszert létrehozni, amely az alapadatokat ebből a (kínálat változását követő) karbantartó rendszerből veszi át.

13 2. A feladat szerkezetének meghatározása
az eladás tárgyát képező, konkrét képmagnókkal foglalkozik (ami készleten van, más objektumokat nem kezel) egy képmagnó a következő öt attribútummal jellemezhető: videó-rendszer típus fejek száma állókép (egy kép kimerevítésének) lehetősége felvétel-keresési lehetőség ár (az ár helyett a tájékoztató jellegű – alacsony, közepes, illetve magas értékű – árfekvéssel dolgozunk majd)

14 2. A feladat szerkezetének meghatározása
Négyféle készülék kapható, név szerint: VCX-1000, Record-Mate99, Xmovie-Beta, Super-Viewer -2.0 Ezek a konkrét példányai az alábbi általános objektumnak: típus VHS BETA objektum: képmagnó fejek száma (szám) állókép igen/nem keresés ár igen/nem (szám)

15 2. A feladat szerkezetének meghatározása
Szempontok attribútum nevének megválasztásához: rövid nevek használata (20-30 karakter) összetett szavaknál elválasztójelek: „-”, „ _ ” (eszköz-függő) találó nevek használata (a fejlesztés résztvevői számára félreértés nélkül érthetőek) Ábrázoljuk az objektumok nevét is attribútumként, neve legyen: „javaslat”, lehetséges értékei pedig a konkrét képmagnó nevek. Mivel tárgyterületünk így összesen hat, szerkezet nélküli elemmel leírható, ezért logika alapú (például szabályalapú) reprezentáció alkalmazható. A rendszer kis mérete miatt bármelyik PC-s célvezérelt eszköz alkalmas a megvalósításra (M.1).

16 3. Az induló szabálykészlet kidolgozása
kétféle módon indíthatjuk egy kicsi szabályalapú rendszer építését: rögtön szabályokat írunk (3.a) előbb döntési táblába foglaljuk a szakértő példáit (3.b) Ezután a cél megadásával egészítjük ki a az induló szabálykészletet (3.c).

17 3.a Kezdjük a szabályok megírásával
A képmagnó-objektum ábráját szemlélve a szakértő elmond egy szabályt. („szab1”), majd még további hármat, jelezve, hogy az „ár”-nál az eladó, majd a vevőtől fogja megkérdezni, hogy milyen árfekvésű készülékre gondol. A szabálybázisunk mélysége egy: minden szabály direkt módon következtet egy-egy javaslatra, így végrehajtáskor a következtetési lánc hossza 1.

18 A képmagnó tanácsadó rendszer első szabályai:
if típus= ‘VHS’ and fejek-száma = 4 and állókép = igen and keresés = igen and ár = alacsony then javaslat = ‘VCX-1000’. szab-2: keresés = igen and ár = közepes then javaslat = ‘Record-Mate99’. szab-3: if típus = ‘BETA’ and fejek-száma = 3 and állókép = nem and keresés = igen and ár = alacsony then javaslat = ‘Xmovie-Beta’. szab-4 if típus = ‘VHS’ and fejek-száma = 5 and állókép = igen and ár = magas then javaslat = ‘Super-Viewer-2.0’.

19 Mélyebb működési szintek:
absztrahálással, közbülső következtetési szabályok beiktatásával részcélok segéd-hipotézisek absztrakt attribútumok bevezetése Példa: ha a vevő nem tudja a fejek számát, csak azt, hogy jó minőségű készüléket szeretne szab-5: if minőségi-keresés = fontos then fejek-száma = 4 and fejek-száma = 5. Új attribútum, ill. szabály beiktatásával működési-szint növelés érhető el. A szabályok összevonása megengedett, ha a feltételük megegyezik és következményükben ugyanaz az attribútum szerepel.

20 3.b Döntési tábla készítése

21 Döntési tábla készítése (kétféle szemlélet)
Leíró közelítés: összes javaslat beírása, majd táblázat kitöltése soronként Empirikus közelítés: ugyanarra a javaslatra akár több alternatív sort (példát) is megadhatunk Pl. egy termék követéséhez szükséges hibajegyzék esetén: külön tárolunk minden reklamációt hiba-jelenségenként gyűjtjük a reklamációkat Ezután szabályok generálása indukcióval (eszközzel, kézzel). A kézi szabálygeneráláshoz egyszerűsítő javaslatok: azonos sorokból (példákból) csak egyet tartsunk meg a megegyező javaslattal (utolsó oszlopbeli elemmel) rendelkező sorokat a feltételben „or”-al fogjuk össze (ha eszközünk támogatja ezt)

22 3.c Végül meg kell adni a célt
goal = <javasolt attribútum>; jelen esetben: „goal = javaslat” Indulhat a konkrét feladat megoldása (go, nem definiált értékekre rákérdez az M.1 rendszer) A nem definiált attribútum-értékekre alapértelmezés szerint angol kérdő-mondattal kérdez rá: „ What is the value of <attribútum> ? ” Példa: What is the value of típus? VHS What is the value of minőségi-keresés? fontos What is the value of állókép? igen What is the value of keresés? igen What is the value of ár? magas javaslat = Super-Viewer-2.0.

23 4. Szabályok továbbfejlesztése, finomítása
4.a Minden esetben adjon tanácsot (legalább: „Forduljon igazi szakértőhöz!”). 4.b Felhasználóbarát párbeszéd biztosítása. 4.c Szituációk kidolgozása, melyekhez több javaslat tartozhat. 4.d Bizonytalanságkezelés (bizonyossági tényezőket rendelünk a szabályokhoz, attribútumokhoz; felhasználó is adhat bizonytalan válaszokat). 4.e Szabályok „finomítása” absztrakció útján, vagy kiegészítés további szabályokkal. 4.f Egyesítjük az ismétlődő szabályokat (ha az eszköz ezt megengedi). 4.g Újabb szabályok bevitelével bővítjük a tárolt ismeretanyagot.

24 4.a Minden esetben adjon tanácsot a rendszer
akkor is adjon tanácsot, ha ismereteinek határához ért (ismerje fel saját korlátait) helyezzünk el lezáró szabályt szab-6: if javaslat is unknown and display (‘Nem tudok javaslatot adni!’) then javaslat = nem-adható.

25 4.b Felhasználóbarát párbeszéd biztosítása
Felhasználói párbeszédet támogató meta-szabályok alkalmazása kérdő mondat deklarálása: question(<attribútum-név>) = ‘Milyen…’. pl.: question(típus) = ‘Milyen típusú képmagnót kíván venni?’. Válasz-menü deklarálása: legalvals(<attribútum-név>) = [<érték>, …]. pl.: legalvals(típus) = [‘VHS’,’BETA’]. válasz-ellenőrzés: legalvals(<attribútum-név>) = <ellenőrző eljárás>. pl.: legalvals(fejek-száma) = number.

26 A felhasználói párbeszédet támogató meta-deklarációk
question(típus) = ‘Milyen típusú képmagnót kíván venni?’. legalvals(típus) = [‘VHS’, ’BETA’]. question(minőségi-keresés) = ‘Fontos-e a keresés minősége?’. legalvals(minőségi-keresés) = [fontos, nem-fontos]. question(állókép) = ‘Igényt tart-e állókép üzemmódra?’. legalvals(állókép) = [igen, nem]. question(keresés) = ‘Igényt tart-e felvétel keresésére?’. legalvals(keresés) = [igen, nem]. question(ár) = ‘Milyen árfekvésű készülék érdekli?’. legalvals(ár) = [alacsony, közepes, magas].

27 4.c Több javaslatot adó szituációk kidolgozása
ne csak egy, hanem több érték keresése az adott célhoz pl.: Prolog: nem csak az első megoldásra vagyunk kíváncsiak, hanem mindegyikre multivalued(javaslat). pl.: multivalued(fejek-száma).

28 4.d Bizonytalanságkezelés bevezetése
a szakértő azonos igényeket kielégítő készülékek közül egyeseket gyakrabban szokott ajánlani, mint másokat (szerviz, használhatóság, haszonkulcs, akció) bizonyossági tényező alkalmazása: cf if …. then javaslat = ‘Super-Viewer-2.0’ cf 40 válaszoknál is használható: ‘Igényt tart-e állókép üzemmódra?’ igen, nem igen cf 80 Javaslat = Super-Viewer-2.0 cf 32

29 4.e A tudásbázis finomítása absztrakcióval; újabb szabályok felvétele
felhasználó által nem érthető helyzetekben használunk attribútum-absztrakciót (pl.: fej-attribútum) ismétlődő feltétel-csoportokat ki lehet emelni egy új szabály (segédhipotézis) feltételébe csökken a tudásbázis mérete, rövidebb lesz a kiértékelési idő szab-7: if állókép = igen and keresés = igen then jó-minőség = igen.

30 4.e A tudásbázis finomítása absztrakcióval; újabb szabályok felvétele
transzformáció szabályok – felhasználó számára kézenfekvőbb az értékcsoportok közti átváltás szab-8: if legfeljebb < then ár = alacsony. question(legfeljebb) = ‘Legfeljebb mennyit szán a készülékre?’ legalvals(legfeljebb) = number.

31 4.e A tudásbázis finomítása absztrakcióval; újabb szabályok felvétele
szab-9: if legfeljebb >= then ár = magas. szab-10: if legfeljebb >= and legfeljebb < then ár = közepes. Ne azt kérdezze a rendszer, hogy közepes árfekvésű terméket akar-e vásárolni, hanem azt, hogy legfeljebb mennyi pénzt szán rá.

32 4.f Ismétlődő szabályok egyesítése
azonos attribútum-struktúrájú (ismétlődő) szabályok általánosítása kézenfekvő. Ezek összevonás után helyettesíthetőek (eszköztől függő módon): változókat tartalmazó egyetlen szabállyal és a változók konkrét (attribútum)érték n-eseivel, mint tényállításokkal (Prolog szerű megoldás) egyetlen adatbázis szabállyal („szabály-osztállyal”) és attribútum-értékek n-eseit rögzítő adatbázis táblával pl.: szab-db: if típus = [ ] and fejek-száma = [ ] and állókép = [ ] and keresés = [ ] and ár = [ ] then javaslat = [ ].

33 4.g Új szabályok bevitelével bővítjük a rendszerben tárolt ismereteket
konzisztencia ellenőrzés: Nagyon törékeny egy ilyen rendszer, ha nem készítjük elő gondosan a rendszer bővítését, az új szabályok könnyen vezethetnek az eddigiekkel ellentmondó következtetésekre. tudásalapú végtelen ciklus kiküszöbölése

34 5. A következtetés és a vezérlés testre szabása
A célvezérelt szabályalapú keretrendszerek következtető gépe erőteljes beépített stratégia szerint működik. Indirekt módon módosíthatjuk a célvezérelt végrehajtást, például: 5.a szabályok vagy részeik sorrendjének megváltoztatása 5.b bizonytalanságkezelésnél lokális küszöbszám megadása 5.c többértékű (többszörös) cél megadása

35 5.a Szabályok vagy részeik sorrendjének megváltoztatása
ha nem lehet szabály prioritást megadni, szabályok sorrendjét is átrendezhetjük előrevetett szabállyal időben elvágjuk a meghiúsuló szabályok előtt a végrehajtást (sebesség növelése) szabály-relatív küszöbszám (a bizonytalansági súly mellett) megadása szabályokban elemi feltételek átrendezése; ha valami gyakran meghiúsul, azt előrevéve megspórolhatjuk az előtte lévő feltételek kiértékelését

36 5.b Bizonytalanságkezelésnél lokális küszöbszám megadása
bizonyossági szint csökken a bizonytalan szabályoknál. Ha egy küszöbszám alá kerül, akkor meghiúsul. Átírhatjuk a küszöbszámot az egyes rendszereknél.

37 5.c Többértékű (többszörös) cél megadása
ha a megoldáshoz a rendszer fokozatosan közelít , a célt részcélokra lehet bontani (pl. TV ajánlattal bővíteni a képmagnó ajánlatot) sok eszköz deklarációval támogatja a sorrend előállítását.

38 Adatvezérelt rendszerek építése
adatokból megkonstruálnak egy vagy több elfogadható megoldást sok megoldás – nem mindegy, milyen úton történik a keresés  tudásmérnöknek több beleszólás biztosítása a vezérlés menetébe a végrehajtás vezérlésével is foglalkozni kell (kiinduló adatok megadása, konzultáció menetének előírása, megállási feltétel)

39 Rendszerépítés két vonala
Deklaratív és heurisztikus ismeretek Vezérlési ismeretek Objektumok kidolgozása Vezérlési elemek kidolgozása Szabályok megírása Vezérlési utasítások beírása a szabályokba

40 Adatvezérelt rendszerek építésének első lépései
a probléma elemzése és definiálása induló adatok megadása induló szabálykészlet megadása a rendszer megállásának beállítása szabályvégrehajtása vezérlése a rendszer továbbfejlesztése

41 Strukturált szabályalapú rendszerek építése
a probléma elemzése és definiálása kontextus-hierarchia meghatározása induló kontextusfa megtervezése a kontextusfa implementálása a kontextusfa és a szabályok kibővítése, felülbírálata

42 Kontextus-hierarchia meghatározása
A feladat részfeladatokra bontása: Procedurális elemzéssel Egymás után elvégzendő részfeladatok sorozatára lehet bontani. Strukturális elemzéssel A feladat dekomponálása a feladat belső szerkezetének olyan kibontását jelenti, amelynél a részfeladatok egymáshoz kapcsolódnak, de ezek nem a feladatmegoldás során egymás után megteendő lépések. Pl.: ASEA robotegységek hibafelderítését és karbantartását támogató tanácsadó rendszer.

43 Induló kontextus-fa megtervezése
Átfogó/áttekintő közelítés: Az egész feladatot elnagyolva fogja meg. Felszínes lesz a modell, prototípus általában nem is készül. Leszűkítő, részletező közelítés: Egy kiragadott kontextust részleteiben kidolgozunk, majd megépítünk egy prototípust is. Kevert közelítés: Az előző két eset kombinációja. Ily módon meg lehet vizsgálni a rendszer átfogó struktúráját, megmutatva egy részletesebben kidolgozott részletét is. Az egyes kontextusok által átfogott feladat terjedelme legyen közel azonos. Több változatot is érdemes kidolgozni és elemezni azokat. Találó neveket adjunk a kontextusoknak.

44 Hibrid keretalapú rendszerek építése
A feladat leírására kombinálják a keret- és a szabályalapú technikákat, a felhasználói felületet pedig objektum-orientált technikával kezelik. Előnyei: Szabályokat csak a heurisztikák leírására használjuk Egyetlen helyen, a kereten belül vannak az adott keretekről szóló összes információk. Az általános célú tudásalapú eszközök piacán a hibrid eszközök dominálnak.

45 Hibrid rendszerek építésének javasolt lépései
probléma meghatározása keretek és rések megadása példányok megadása felhasználói felület megadása szabályok megadása démonok megadása üzenetküldés kidolgozása

46 Tudásalapú rendszerek verifikálása és validálása
DAISY (Dependability os Artifical Intelligence Systems) követelményrendszer A hiteles (dependant) szakértői rendszerekkel szembeni minőségi követelmények: Megbízhatóság (reliability); Védelem (security) az illetéktelen felhasználókkal szemben; Biztonságosság (safety) vagyis a felhasználó védelme a rendszerrel, ill. annak külső (hardver/szoftver) környezetével szemben; Karbantarthatóság (maintainability); Hordozhatóság (portability).

47 Egy tudásalapú/szakértő rendszer hibáinak forrásai
1. Hiányzik a követelmény-specifikáció, ha pedig van, akkor nem tartják be. 2. A tudásbázisba beépítenek szintaktikai és szemantikai hibákat. 3. Nincs megfelelően reprezentálva a tárgyterületi ismeretanyag és/vagy az alkalmazott következtetések nem illeszkednek a problémához.

48 Verifikálás és validálás
A rendszer hibátlan működésének – illetve általában, a minőségbiztosításnak – fontos módszerei az egyes fejlesztési fázisokat lezáró verifikálás, valamint a végtermék érvényesítésével foglalkozó validálás.

49 Verifikálás és validálás
Más néven összehasonlító ellenőrzés Egy adott fejlesztési fázis eredményének értékelési eljárása. Célja: igazolni, hogy az eredmény megfelel-e a fázis kezdeti állapotát jellemző termékeknek, követelményeknek, valamint a fázisra vonatkozó szabályoknak A hibaforrások 1. és 2. eseteivel, valamint a tudásbázis konzisztenciájának és teljességének szintaktikai és szemantikai hibákra vezető hiányosságaival foglalkozik.

50 Verifikálás és validálás
vagy más néven bevizsgálás, érvényesítés Az elkészült rendszer kiértékelési eljárása. Célja: annak vizsgálata, hogy a szoftver – működésében és eredményében - és a szoftver dokumentációja megfelel-e az előre definiált követelményeknek és minőségi jellemzőknek. Főként a hibaforrások 3. esetével foglalkozik.

51 Rendszertesztelés Hagyományos szoftverek Tudásalapú szoftverek
Előre meghatározható tesztesetek A rendszer videlkedésének megfigyelése révén szerezhetőek be a tesztesetek Adott bemenethez meghatározható kimenet Adott bemenethez szakértő függő (elfogadható) kimenet, bizonytalanságkezelés Objektív és teljes körű ellenőrzés A tesztsorozat lefuttatása után a rendszer érvényesnek mondható Szubjektív és nem teljes körű ellenőrzés, az esetek sikeres lefuttatása még nem jelenti a rendszer érvényességét Laboratóriumi környezetben tesztelhető Laboratóriumi környezetben nem tesztelhető

52 Rendszertesztelés Nem lehet objektív Nem lehet teljeskörű
különböző szakemberek eltérő véleménye Nem lehet teljeskörű

53 Verifikálás A specifikáció teljesítése
Programozási hibák a szabálybázisban Amikor egy szemantikai hiba nem hiba Számítógéppel támogatott verifikálás

54 1. A specifikáció teljesítése
Eleget tesz-e a rendszer a specifikációnak? Nincsenek-e hibák a rendszerben? A verifikálás hasonló a hagyományos rendszerekéhez Fejlesztés verifikált eszközzel → elegendő a tudásbázist ellenőrizni

55 1. Specifikáció teljesítése
megfelelő a tudásreprezentációs módszer? megfelelő a következtetési módszer? megfelelő felhasználói felület? megfelelő magyarázatadás? …

56 2. Programozási hibák a szabálybázisban a. Redundáns szabályok
Szintaktikailag redundáns Szab-a1 if páratartalom = magas and hőmérséklet = forró then zivatar = lehetséges. Szab-a2 if hőmérséklet = forró and páratartalom = magas Különösen veszélyes, ha bizonyossági tényezőt kapcsolunk hozzájuk, és pl.: különböző forrásokból származó következményekként indokolatlanul megerősítik egymás (önmaguk) bizonyossági mértékét.

57 2. Programozási hibák a szabálybázisban a. Redundáns szabályok
Szemantikailag redundáns: Szab-a3: if páratartalom = magas and hőmérséklet = forró then zivatar = várható. Szab-a4: then

58 2. Programozási hibák a szabálybázisban b. Ellentmondó szabályok
A feltétel azonos A következmény egymásnak ellentmondó Pl.: then napsütés = várható. then not napsütés = várható.

59 2. Programozási hibák a szabálybázisban c. Magában foglaló szabályok
Ha a feltétel bővebb, a következmény pedig ugyanaz. Pl.: 2 feltétel => a következmény 2+1 feltétel => b következmény (a not = b)

60 2. Programozási hibák a szabálybázisban d. Körkörös szabályok
Körbefutó következtetések if testvérek(X,Y) then szülők-azonosak(X,Y). if szülők-azonosak(X,Y) then testvérek(X,Y).

61 2. Programozási hibák a szabálybázisban e
2. Programozási hibák a szabálybázisban e. Szükségtelen feltétel alkalmazása Szintaktikailag redundáns lenne, de az egyik feltételük ellentmond egymásnak lázas = igen lázas = nem

62 2. Programozási hibák a szabálybázisban f. Zsákutca szabályok
A következményének egyetlen akciója sem jelent megoldást, de nem is eredményezi más szabály tüzelőképessé válását. if üzemanyagszint-mutató = piros then tank = üres.

63 2. Programozási hibák a szabálybázisban További hibák
g. Hiányos, vagy hiányzó szabályok h. Elérhetetlen szabályok

64 3. Amikor egy szemantikai hiba nem hiba
A bizonytalanságkezelés bevezetésével a programozói hibák más szinezetet kapnak. A magában foglaló szabályoknál például a különböző forrásokból származó bizonyosság megfelelő beállítása miatt építik be. Bizonyossági értékek esetén változik a helyzet: Szab-c1 if páratartalom = magas and hőmérséklet = forró then zivatar = várható cf 80 Szab-c2 if páratartalom = magas and hőmérséklet = forró and légnyomás = alacsony then zivatar = várható cf 90

65 4. Számítógéppel támogatott verifikálás
CHECK verifikáló, a LES (Lockhead Expert System) eszközhöz fejlesztették ki Az inkonzisztencia vizsgálatánál felderíti a redundáns-, az ellentmondó-, a magában foglaló-, a körkörös szabályokat, valamint a szükségtelen feltételeket. A tudásbázis teljességének vizsgálatát a nem-hivatkozott vagy illegális attribútum-értékek, elérhetetlen célok, hiányzó- és zsákutca-szabályok felderítésével támogatja.

66 4. Számítógéppel támogatott verifikálás
Először a MYCIN verifikálásának automatizálásával foglalkoztak, ez a TEIRESIAS rendszer volt. Újabban eredményes kutatások folynak a tudásbázis inkrementális fejlesztésének, aktualizálásának, módszeres finomításának, valamint hangolásának verifikálási funkciókkal való támogatására.

67 Validálás módszerei informális validálás validálás teszt-esetekkel
helyszíni, élő esetekkel történő validálás modulonkénti validálás érzékenység-elemzés

68 Informális validálás szakértők és felhasználók bevonása
rendszer futtatása javaslatok megvitatása modul fejlesztéséhez megfelelő rendszer validálásához nem kielégítő

69 Validálás teszteléssel
előkészített tesztesetek futtatása szakértők megkérdezése javaslatok összevetése a szakértők minősítik a rendszer javaslatait fekete doboz Turing teszt

70 Helyszíni teszt validálás
valós esetek futtatása a helyszínen nem várt hibák léphetnek fel

71 Validálás modulonként
független modulokra bontható rendszer kisebb, kevésbé bonyolult rendszerszintű validálás is kell

72 Érzékenység elemzés A bemenetek kismértékű módosításakor milyen érzékenyen változtatja meg a kimeneteit. Bizonytalanságot kezelő rendszereknél hatékony technika.

73 Tudásalapú rendszerek validálásának kritériumai
Összehasonlítás ismert korábbi eredményekkel Ún. történeti esetekkel való összehasonlítás Összehasonlítás szakértői problémamegoldással Tolerálja a validáló szakértő esetleges megoldási hibáit Összehasonlítás elméleti lehetőségekkel Fizikai rendszerek modellezésénél ez kézenfekvő kritérium Pontosság (accuracy) Teljeskörűség (adequacy)

74 Validálás során hibák:
legális bemenet, téves következtetés A rendszer nem pontos, nem szabatos. Van olyan bemenet, amit a rendszer nem tud feldolgozni. A rendszer nem teljes körűen fogja át a problémát.