Ingegneria della conoscenza

Sistemi esperti e ingegneria della conoscenza
Parte I .  Struttura di un sistema esperto
Premessa
Nell’ambito dell’intelligenza artificiale, l’idea di sistema esperto rappresenta una modifica prospettica:

• limitazione delle aspettative: non la “comprensione”, ma risultati pratici
• riduzione del raggio di azione: non in qualsiasi campo, cfr. test di Turing, ma su una classe di problemi specifici
• adozione di una metodologia precisa: affrontare il problem solving attraverso strumenti logici
• nuove distinzioni operative: la conoscenza, l’inferenza, l’acquisizione di conoscenze, l’uso delle stesse

Elementi di un sistema esperto
Un modello semplificato :

• Base di conoscenza
• Motore inferenziale
• Interfaccia per l’acquisizione delle conoscenze
• Interfaccia di consultazione

Lo shell (guscio).  In realtà ciascuno shell stabilisce una interpretazione ed una relazione reciproca tra base di conoscenze, motore e interfaccia.  Per esempio, la struttura della base di conoscenza è spesso del tipo “a regole di produzione”, già predisposta cioè per l’azione del motore inferenziale: la conoscenza è soprattutto conoscenza delle condizioni di ciascun fatto rilevante e delle sue conseguenze (conoscenza delle relazioni logiche tra i fatti/proposizioni).
La regola di produzione.  Se… allora…
Discussione sull’inferenza logica (distinta dal concetto di causa ecc.)
La regola di produzione può non coincidere con l’inferenza logica (nel modello semplificato di S.E., assumiamo che coincida)
Relazione col modus ponens e modus tollens: esempi
Cenni a differenti algoritmi nel caso di logica modale.  Interpretazione della logica modale in termini di probabilità.  Inferenze “probabilistiche”; diverso comportamento delle regole in “OR” e in “AND”
Schema del motore inferenziale. Operare forward oppure backward attraverso la base di conoscenze
Motore inferenziale orientato ad uno scopo.  Goal del sistema esperto
Effetto dell’introduzione del goal su una base di conoscenze: grafo virtuale dei rapporti logici
Operatività del motore in backward a partire dal goal
Individuazione delle “foglie” dell’albero logico: “fatti” (proposizioni) considerati non derivabili da altri eventi
Strategie da adottare per riconoscere le “foglie”
Uno shell è in pratica un insieme di programmi e di base dati in grado di ospitare delle conoscenze espresse come relazioni tra eventi.
Un S.E. è in questo caso uno shell “riempito” da una specifica base di conoscenza, in grado di applicarla per la soluzione di problemi (attraverso l’interfaccia di consultazione)
Parte II .  Operatività di un sistema esperto
La conoscenza e i “fatti”
Applicazione del S.E. ad un caso da trattare: distinzione tra base di conoscenza (con eventuali “fatti” sempre veri) e fatti specifici, appartenenti ad singolo caso
Accumulo di fatti “noti” (N.B. Nel caso della logica modale, i fatti possono non essere accertati o negati, ma avere un loro grado di verità, o di probabilità)
In alcuni sistemi, i fatti ammessi in un primo momento possono successivamente essere scartati (sistemi a lavagna: inserimento e cancellazione di fatti)
Interfaccia di consultazione: come stabilire il goal; come accumulare i “fatti” noti; come agire di fronte alle “foglie” di cui non si conosce il valore di verità
S.E. semplificato: i fatti accertati non sono più rimessi in discussione
Due modalità di conversazione: guidata dai fatti oppure guidata dal fine
La modalità più sorprendente del S.E. è quella guidata dal fine: il S.E. assume uno scopo preciso ed “agisce” in modo da conseguirlo
Strategie di utilizzo della base di conoscenze per raggiungere lo scopo (= verificare l’asserto goal)
Ricorsione: ogni altro nodo del grafo logico è suscettibile di divenire goal temporaneo
Modalità di esplorazione dell’albero logico: in profondità, oppure in estensione (come nelle strategie di problem solving)
Nella fase di verifica logica, la sequenza è indifferente; nell’adozione di tattiche ricorsive (assunzione di goal temporanei) la scelta determina il comportamento “esteriore” del sistema, la successione di risposte e comunicazioni nell’interfaccia di consultazione.  A differenza che in una procedura informatica tradizionale, il sistema deve essere in grado in ogni momento di “giustificare” la via che ha intrapreso e di mostrare la sequenza dimostrativa ipotizzata. (il motore si comporta come un interprete in modalità “debugging”, in grado di mostrare il punto del codice che sta eseguendo)
Nella pratica: necessità di pilotare la sequenza di esplorazione per simulare in ogni punto significativo il comportamento dell’esperto umano
Acquisizione delle conoscenze
Dato uno shell di S.E., la fase di definizione della base di conoscenze determina l’esperienza del sistema e il suo comportamento di fronte ai problemi da risolvere.
Relativa indipendenza della fase: raccogliere tutte le conoscenze pertinenti, senza preoccuparsi dell’ordine e dell’importanza di ciascuna
Necessità di coerenza logica: per il principio di identità, è opportuno non introdurre varianti legate per esempio al tempo (relazioni vere in un primo momento, false successivamente) o al contesto implicito (relazioni ora affidabili ora incerte a seconda di condizioni non citate o non logicamente comprese nelle premesse)
Completezza dell’informazione: adottare un metodo per non tralasciare aspetti rilevanti del problema
Ingegneria della conoscenza: come affrontare con successo e in tempi ragionevoli questo compito pratico ma condizionato da istanze divergenti
La relazione con l’esperto umano
Il S.E. in prima battuta si propone di riprodurre le capacità dell’esperto umano, ricavando dall’esperto stesso le regole di comportamento.
Antico problema: esistono regole dietro un comportamento efficace?  La regola è una condizione implicita in ogni comportamento ragionevole, o è invece soltanto una forzatura a posteriori, una giustificazione illusoria, una approssimazione suggestiva ma in realtà inefficace?
Sul terreno dell’I.A., la polemica è stata condotta p.es. da Hubert Dreyfus
Comunque sia: la scienza si fonda sulla convinzione che una conoscenza teorica sia possibile, che la soluzione di problemi sia raggiungibile in base a leggi e a regole di applicazione esplicite.
L’ingegnere della conoscenza assume che sia possibile “elicitare” la conoscenza dell’esperto umano, tradurla in regole di comportamento, in regole di deduzione, in particolare in “regole di produzione”.
Rapporto con l’esperto umano: molto più stretto di quello col committente di una procedura informatica tradizionale.  L’esperto in una professione o in una attività specialistica spesso non adotta procedure standardizzate e non appartiene a strutture burocraticamente definite.
Occorre rendere esplicito il suo comportamento fondato sull’intuito, sull’occhio clinico, sull’esperienza di casi analoghi.  Non basta un’intervista di tipo tradizionale, ma occorre un’opera di sintesi e di invenzione comune, per arrivare a scoprire insieme le ragioni di ogni passo che l’esperto umano compie.  (Dreyfus richiama l’arte maieutica di Socrate, cioè la capacità di favorire il “parto”, la nascita di una nuova creazione da parte dell’esperto umano).
La conoscenza ricavata va quindi scritta in termini di regole di produzione, possibilmente in modo che sia interpretabile sia dall’esperto umano (per validarla) che dal S.E. (per applicarla in via prototipale)
Necessità di arrivare quanto prima al prototyping: trattandosi di conoscenza pratica e non squisitamente teorica, non può essere ben interpretata e compresa se non attraverso le sue conseguenze sul comportamento stesso del S.E.
L’esperto umano deve collaborare nel verificare e correggere l’interpretazione operativa che il S.E. dà delle regole elicitate
Alcuni schemi e procedure per affrontare le prime fasi di istruzione tramite esperto umano
Caratteristiche dell’interfaccia di acquisizione delle conoscenze.  Il problema della ambiguità di ogni espressione verbale.  Distinzione tra comprensione delle proposizioni e individuazione delle relazioni logiche tra proposizioni.
Rappresentazione della conoscenza
Il S.E. semplificato non si propone di interpretare le parole e i simboli che rappresentano fatti del mondo esterno, quanto piuttosto di riprodurre i rapporti logici tra le diverse preposizioni.  In linea di massima, il significato operativo di una condizione o di un “fatto” è lasciato all’interfaccia di acquisizione o di consultazione.  Il motore inferenziale si limita a derivare conseguenze (applicando le leggi logiche all’insieme di fatti e base di conoscenza) o a individuare le proposizioni da accertare per poter derivare l’asserto-goal.
Per il sistema, ciascuna frase (o predicato verbale) può essere codificata con un qualsiasi simbolo funzionale, dotato o meno di variabili.  Per semplicità, si escludono anche rappresentazioni metalinguistiche (funzioni che si applicano a funzioni).  Tutto l’apparato linguistico-formale è demandato allo shell, mentre la base di conoscenza si riferisce a fatti e relazioni del mondo esterno.
In questa versione estremizzata, il problema del significato delle frasi elementari (proposizioni atomiche o funzioni) è affidato dall’interfaccia a procedure di verifica ad hoc.  Per esempio, la fonte di informazione può essere la tastiera (immissione di un “fatto”), l’introduzione di un valore binario (“sì” oppure “no” in risposta ad una domanda del sistema), la restituzione di un valore (binario e/o discreto) da parte di una procedura di validazione (p.es., la lettura di uno strumento, la ricerca di un dato in un archivio gestionale, la segnalazione di esecuzione avvenuta da parte di una routine di computer (eventualmente collegata ad operazioni robotizzate ecc.).
Per poter essere compresa dall’operatore umano, ciascuna proposizione elementare deve avere possibilmente un equivalente linguistico significativo, in modo da trovare una rappresentazione concisa ma evocativa in ogni regola di produzione e in ogni contesto esplicativo in cui la proposizione compaia.
Nello shell di S.E. portato ad esempio, la base di conoscenza ha due “rappresentazioni” biunivocamente correlate: il codice di funzione, usato per velocizzare l’interprete, e la sua decodifica in frasi in linguaggio naturale.  Unica abilità linguistica dell’interfaccia: volgere la frase in negativo, in forma interrogativa, in forma parametrica (nel caso di funzioni con variabili),
Questa separazione tra uso funzionale e rappresentazione linguistica permette di mostrare che il S.E. funziona senza nessuna pretesa di rappresentare concetti, intenzionalità espressive ecc.
Vantaggio conseguente: si controlla esplicitamente (mediante una decodifica linguistica del tutto indipendente) la semantica della base di conoscenza, che non dipende dalle parole impiegate né dalla capacità di coniugare le radici verbali o interpretare una sintassi sia pure semplificata del linguaggio naturale.  L’effetto di “naturalezza” di conversazione può ugualmente essere raggiunto con un raffinamento dell’interfaccia di decodifica (che nello shell di riferimento è veramente elementare ma tuttavia abbastanza efficace)
Finalità del Sistema Esperto e tipo di  shell
Tipicamente, un S.E. può avere un impiego di carattere:

• diagnostico
• tutoriale
• euristico

Nell’impiego euristico, di solito interfaccia con altri sistemi automatici e robotizzati. Per esempio, attraverso modelli del mondo esterno il S.E. suggerisce strategie di soluzione a programmi specializzati di calcolo numerico che non sono in grado di eseguire in modo esaustivo e in tempo reale una esplorazione completa dell’arco delle soluzioni possibili; oppure fornisce interpretazioni plausibili a dati informativi incompleti o non corrispondenti agli scenari memorizzati in un sistema robotico.
Nell’impiego tutoriale, il S.E. interfaccia con un operatore umano, di cui deve avere modelli interpretativi sufficientemente ampi e flessibili
Nell’impiego diagnostico, che qui approfondiamo, siamo forse più vicini alla modalità d’azione del tipico esperto umano, che fornisce informazioni e comandi sia ad operatori di minore esperienza, sia a procedure eventualmente automatizzate.
La diagnostica spesso si avvale di logiche modali; qui esemplifichiamo in prima battuta l’impiego della logica binaria classica, per quanto lo shell di riferimento disponga anche di rappresentazioni e capacità inferenziali di tipo probabilistico.
Vari tipi di diagnostica
Nell’esempio affrontato: una situazione in cui vi è una normativa di riferimento, in linea di principio in grado di definire senza ambiguità i casi “patologici” (mancato rispetto della normativa stessa)
Vantaggi e svantaggi di riferirsi ad una normativa
Necessità comunque di avvalersi dell’esperto umano per interpretare l’apparente sistematicità delle norme e suggerire una modalità istruttoria ragionevole
Riferimento alle norme: in fase esplicativa, il sistema esperto deve non solo indicare le regole di produzione che sta utilizzando, ma anche rimandare per ciascuna all’apparato normativo da cui è stata tratta.

Parte III . Illustrazione di shell di S.E. applicato ad un problema reale
Componenti, tecniche realizzative e modalità d’uso dello shell “Ergo”

• Base di conoscenza rappresentata in un data base relazionale
• Motore inferenziale realizzato attraverso procedure ricorsive in linguaggio C
• Interfaccia di sviluppo: maschere, stampe e query sul data base; schemi grafici, relazioni,  funzioni esplicative, backtracking automatico sul motore inferenziale
• Interfaccia di consultazione: procedura interattiva cablata sul motore inferenziale, con diverse modalità operative

Asserto atomico e negazione
Asserto parametrico (solo con operatore =, >, <, e un parametro numerico)
Regola di produzione in AND o in OR
Suddivisione della conoscenza in “argomenti” e definizione, per ciascuno, di un goal standard
Motore inferenziale.  Opera in forward ad ogni nuova acquisizione: esplora tutte le regole per verificare se qualcuna può scattare (e così via, ricorsivamente), applicando sia modus ponens che modus tollens. Vi è un controllo sulla ricorsione (cut al secondo passaggio da uno stesso nodo)
A richiesta, opera in backward a partire dal goal dell’argomento principale.  Sono esaminate le regole che hanno il goal come conseguenza, e ricorsivamente tutte le premesse di ciascuna. Se non viene trovato nessun percorso verificato, si sottopongono a verifica le foglie dell’albero logico. Ciascuna foglia può comportare un valore di default (vero, falso, ignoto), oppure una routine automatizzata (che restituisce un valore di verità); in assenza o mancata restituzione del valore, si può avere una richiesta diretta a video, a cui rispondere affermativamente o negativamente.
In pratica, la sequenza delle domande riguarda ogni volta percorsi che comportino il conseguimento o il fallimento del goal (sono cioè strettamente pertinenti al caso in esame); se un ramo è escluso da una fase del dialogo, il percorso è abbandonato e ne viene ricercato un altro eventualmente ancora possibile .
In ogni fase, si può chieder conto della regola che ha innescato l’ultima azione, e via via risalire fino al goal lungo il percorso in esame (in forma dialogica: una catena di “perché” giustificativi).

Fasi e metodi per l'acquisizione delle conoscenze

• raccogliere informazione sul problema. In presenza di una normativa di riferimento, occorre esaminarne la struttura logica
• documentare la sequenza di operazioni svolte dall’esperto umano durante la soluzione di un caso (istruzione del problema)
• individuare le possibili conclusioni dell’istruttoria
• indicare il goal principale. Generalmente, il goal è lo stato di soluzione del problema (diagnosi formulata, oppure impossibilità di pervenire ad una risposta conclusiva; in caso di logica modale, la diagnosi è accompagnata da una valutazione di attendibilità)
• definire il rapporto logico delle possibili diagnosi col goal.  In situazioni complesse, il goal può essere un asserto pleonastico o fittizio, a cui le diagnosi sono collegate in senso positivo o negativo
• formulare le condizioni di macrolivello che indirizzano in prima battuta verso l’una o l’altra indagine diagnostica.  Si tenta cioè di suddividere il problema in sottoproblemi, eventualmente indipendenti ma collegati al goal prescelto
• costruire su questo una bozza di prototipo (20-30 regole)
• validare il prototipo con l’esperto umano, curando la comprensibilità degli asserti e l’accettabilità del modo di procedere (meglio se vicino all’istruttoria indicata dall’esperto)

La rapidità con cui si arriva ad un prototipo convincente permette di assumere che il processo sia autodocumentato: è il prototipo stesso che documenta l’analisi del problema e rappresenta lo stato del lavoro di elicitazione della conoscenza.  Iterando i punti 6-7-8, è possibile individuare vicoli ciechi o procedimenti non soddisfacenti, dovuti ad una errata definizione di regole o asserti. In questo caso occorre salvare e documentare lo stato del prototipo, giustificare il cambio di strategia e solo allora procedere a modificare anche in modo drastico la struttura logica della base di conoscenze.  Non è necessario definire i contorni dell’”errore” (ricerca del colpevole), ma è essenziale documentare il processo di accrescimento della base di conoscenze, poiché non procede in modo lineare ed i tempi di sviluppo comprendono necessariamente le fasi di ripensamento e approfondimento delle strategie solutive.  Inoltre, se il rimedio risulta peggiore del male deve essere possibile tornare al punto di svolta e scegliere una via alternativa.
Un’osservazione sulla scelta del goal: si può scegliere un asserto generico, del tipo “l’analisi del problema è stata completata”, in modo che sia sempre possibile aggiungere al secondo livello ulteriori diagnosi.  Nel SE in esame, il goal è “il piano regolatore è stato rispettato” (in negativo: “il piano regolatore non è stato rispettato”), che nella sua generalità corrisponde in effetti alla risposa finale che ci si attende dall’istruttoria su un progetto edilizio da approvare o respingere.
Lo shell fornisce l’elenco delle conclusioni intermedie più rilevanti, che in pratica sono in grado di giustificare l’accoglimento o il rigetto del caso proposto, indicando implicitamente i punti in cui, in caso di diagnosi negativa, la proposta deve essere modificata.
L’arricchimento del frasario e delle regole richiede attenzione, per non duplicare asserti o relazioni già trattate o non complicare in modo incontrollato il processo di soluzione. Il DB consente una ricerca rapida di tutte le frasi che contengono certe parole, o di tutte le regole in cui la frase è richiamata. L’interfaccia di consultazione permette inoltre una conversazione libera, in cui l’utente immette delle frasi a piacere e il sistema cerca di interpretarle sulla base delle proposizioni presenti nella base di conoscenza (con un semplice algoritmo di frequenza di parole o parti di parola); questo può essere usato per richiamare, in ordine di numero di corrispondenze, tutti gli asserti più o meno attinenti ad un certo argomento.
La base di conoscenza di P.R.O.F. (Piano Regolatore Online - Forlì)
PROF utilizza circa 700 frasi (asserti codificati) combinate in 850 regole (oltre a qualche dozzina di “conoscenze condensate”: liste di frasi equivalenti oppure mutuamente esclusive)
Le regole sono tutte collegate, direttamente o attraverso ulteriori clausole deduttive, al goal principale, rappresentato dalla frase “il Piano Regolatore è rispettato”; tendono cioè a derivare, data una certa situazione istruttoria, la trasgressione (goal fallito) o viceversa il rispetto della normativa del PRG del Comune di Forlì.
Nel caso specifico, si è scelto di cercare di dimostrare che l’intervento contrasta col piano regolatore: questo equivale ad un comportamento puntiglioso, che tende a verificare tutte le possibilità di trasgressione previste dalle norme.  Qualora tutti i ragionevoli controlli falliscano, il sistema assume che il piano sia stato rispettato (ignotum pro reo): l’asserto goal ha come default il valore “vero”.
In buona parte, vengono richiamati esplicitamente gli articoli della normativa, sotto condizione che siano applicabili al caso in esame.  Poiché le clausole in AND vengono controllate in ordine di presentazione, una formulazione del tipo (regola 978):
“SE l'intervento comprende opere edilizie E  l'intervento non riguarda la zona F (a prevalente destinazione agricola) E  hai indicato tutte le destinazioni d'uso del caso in questione E  la destinazione d'uso non e': carburanti , servizi per viabilita' (Tab. 6.6) E  non e' soddisfatto l' Art. 77 ( salvaguardia e potenziamento del verde e alberatura)
ALLORA  le norme del PRG non sono rispettate “
comporta che le norme dell’articolo 77 siano richiamate solo nel caso in cui le quattro clausole precedenti siano verificate. L’ordine delle condizioni di una regola in AND determina la sequenza di analisi del S.E.
Ugualmente, le sottoregole che riguardano l’articolo 77 (come molti altri articoli trattati) tendono a dimostrarne il mancato rispetto, hanno cioè come conseguente la negazione dell’asserto “è soddisfatto l’Art. 77”.
In questo modo si è sfruttata la ragionevole suddivisione del PRG in articoli per sezionare il problema in parti più facilmente controllabili.  Naturalmente vi sono norme che, indipendentemente dal numero di capoverso in cui compaiono, hanno una applicabilità trasversale, e quindi sono tradotte in regole con una puntuale specifica delle condizioni a cui si riferiscono.
Applicazione di P.R.O.F. a casi reali: tuning dell'istruttoria
Man mano che l’esperto umano interpreta le norme e l’ingegnere della conoscenza le traduce nel castello deduttivo, il sistema è in grado di affrontare sempre meglio i casi reali. In sostanza, si tratta di sottoporre a controllo progetti di interventi edilizi che ricadono sotto la giurisdizione del PRG. Ma anche quando la logica del S.E. è soddisfacente, non sempre l’ordine delle domande che il sistema pone appare appropriato.  In particolare, l’esperienza suggerisce che alcune verifiche magari più semplici hanno buona probabilità di scovare i difetti del progetto, mentre altre indagini più approfondite hanno senso quando si siano esclusi gli errori più grossolani.  Per banalizzare: è inutile cavillare sugli indici edilizi quando si stia cercando di costruire un condominio in un’area riservata a verde pubblico.  Questo portato di buon senso non è ovviamente incluso nelle capacità logico-deduttive del S.E. e deve essere simulato ordinando le regole e le clausole secondo una priorità di istruttoria: l’ordine dei controlli eseguiti dall’esperto umano di solito ha motivazioni valide. Una opportuna assegnazione dell’indice di priorità di ciascuna regola permette un primo ordinamento; il prototyping consente di variare tali indici di priorità fino ad arrivare ad un comportamento ragionevole. Evitare comunque, se non nell’ultima fase di tuning, di introdurre regole ad hoc per forzare il sistema: si rischia di inserire regole contraddittorie che portano a risultati differenti a seconda dell’ordine in cui sono valutate.
Il motore inferenziale, attraverso le catene Why? e What if?, documenta le linee di ragionamento in uso; il comando backtrack inverte di segno l’ultima risposta e intraprende una strada alternativa; la modalità di esplorazione in backtracking percorre tutte le vie possibili, scegliendo per ogni foglia prima la risposta positiva, poi la risposta negativa, segnalando eventuali contraddizioni annidate nei punti più nascosti dell’albero logico (nel caso di PROF, le vie percorribili risultano qualche decina di migliaia).
È possibile stampare l’intero albero logico, riferito al goal attivo; nella stampa, si sceglie la strada deep first, evitando la ristampa di regole già stampate (e gli eventuali loop sul grafo delle relazioni).
Combinando questi metodi di verifica durante le sedute di prova, si individuano i punti di svolta dell’anamnesi condotta dal sistema ed eventualmente si interviene, per esempio modificando la priorità delle regole che convergono sullo stesso asserto conclusivo.  Si possono memorizzare conversazioni parziali (ovvero, elenco di valori o asserti pertinenti al caso in esame), in modo da ricaricarle a fronte di modifiche della base di conoscenza, per verificare che non abbiano conseguenze indesiderate su parti già testate (equivale al testing strutturato di procedure tradizionali).

Parte IV . Dimostrazione. Confronto con altre applicazioni
Illustrazione del progetto. Documentazione e dimostrazioni a computer
Uso del DB Access per la costruzione della base di conoscenza. Sedute di consultazione del S.E.
L'immissione a sintassi libera per la definizione del caso o la modifica del goal. La modalità guidata (goal driven) per l'istruttoria. Esplorazione del path attivo. Backtracking.  Catalogazione e riesame di casi standard. Report diagnostico.
Completamento di un progetto di S.E.  e confronto con l'esperto umano
Con l'appiattimento della curva costi/benefici, occorre concordare la chiusura del lavoro di ingegneria della conoscenza.
Il progetto può ritenersi completato se soddisfa i requisiti di applicabilità ai casi reali (cfr. Test di Turing: se fornisce le stesse diagnosi di un esperto umano).
Applicazione del S.E.: consulenza, pre-istruttoria
Impiego del S.E. sul piano regolatore:

• in fase di stesura del piano regolatore, per chiarire ambiguità interpretative e simulare l'impatto di una norma sui progetti di intervento edilizio
• da parte dell'addetto all'istruttoria tecnica delle pratiche edilizie (o di un operatore apprendista) per ottenere uniformità di giudizio e di documentazione nei pareri da trasmettere alla commissione edilizia
• come consulenza offerta agli uffici tecnici privati
• come documentazione e supporto informativo alla cittadinanza

Cenni su altri progetti (sistema diagnostico di pneumologia neonatale - con logica modale)
Un esempio di applicazione di logica modale: il sistema I.RE.NE. (Insufficienza Respiratoria Neonatale) fornisce consigli di pronto intervento all'ostetrico in mancanza o in attesa dello specialista delle disfunzioni respiratorie
S.E. e intelligenza artificiale: discussione
È vera gloria?
Il sistema esperto offre risultati paragonabili alle prestazioni di un professionista intelligente?
È applicabile con risultati non banali?
È affidabile? (necessità di definire limiti e criteri di affidabilità)
Un sistema diagnostico consente quantomeno lo screening su grandi insiemi di casi: può individuare una percentuale di situazioni su cui richiamare l'attenzione dello specialista umano.
Rappresenta un valido supporto di conoscenze, più interattivo e più semplice da usare rispetto al manuale tradizionale; ha un ovvio impiego in fasi di addestramento e di istruzione dello specialista umano.  La costruzione di una base di conoscenze rappresenta per il consulente "esperto umano" un valido momento di approfondimento professionale.
Impatto di un S.E. in ambienti di lavoro professionale
Sospetti e timori suscitati dall'esperto artificiale
La “trasparenza” del S.E.
Democratizzazione della conoscenza e perdita di potere burocratico-professionale
Sfruttamento diretto di sapere condiviso

Luciano Bazzocchi     Appunti per il seminario "Sistemi Esperti e ingegneria della conoscenza"