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

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).

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

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

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”

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

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.

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.

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

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

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)

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.

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)

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)

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).

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).

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.

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’.

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.

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

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)

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.

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.

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ó.

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.

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].

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).

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

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.

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 < 30000 then ár = alacsony. question(legfeljebb) = ‘Legfeljebb mennyit szán a készülékre?’ legalvals(legfeljebb) = number.

4.e A tudásbázis finomítása absztrakcióval; újabb szabályok felvétele szab-9: if legfeljebb >= 60.000 then ár = magas. szab-10: if legfeljebb >= 30.000 and legfeljebb < 60.000 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á.

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 = [ ].

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

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

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

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.

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.

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)

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

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

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

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.

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.

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.

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

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).

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.

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.

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.

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.

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ő

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

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

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

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? …

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.

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

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ó.

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)

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).

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

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.

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

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

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.

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.

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

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ő

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

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

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

É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.

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)

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.