HASP/SIAP

Nel 1972, mentre Larry Roberts era ancora il Direttore dell’IPTO, egli ha chiesto a Ed Feigenbaum a Stanford di pensare circa l’applicare le idee con successo di AI usate in DENDRAL al problema di identificare e inseguire navi e sottomarini nell’oceano usando dati acustici da schieramenti nascosti di idrofoni (concealed hydrophone arrays).

Alcuni dei dati acustici rilevati dagli schieramenti di idrofoni vengono da assi rotanti (rotating shafts) e eliche (propellors) e macchinari alternativi (reciprocating machinery) a bordo delle navi. Navi differenti emettono suoni con le loro proprie caratteristiche che identificano le frequenze fondamentali e le frequenze armoniche. Gli specialisti umani che analizzano questo tipo di sorveglianza di dati guardano i displays del sonogramma di suoni dell’oceano e il corrispondere degli spettri del suono a riferimenti memorizzati (stored references), tentare di identificare e localizzare navi che potrebbero essere presenti (se ce n’erano). Il prendere queste decisioni spesso richiede l’usare informazione non presenti nei segnali stessi, informazione come reports da altri schieramenti di sensori (sensor arrays), reports dell’intelligence e conoscenza generale circa le caratteristiche di navi e comuni rotte marine.

Il problema dell’analisi è complicato da molti fattori:

Il rumore di sottofondo da navi distanti è mixato con rumori indotti da tempeste e biologici. I percorsi del suono agli schieramenti (arrays) variano con i cicli diurni e stagionali. L’arrivo dell’energia del suono su molti percorsi potrebbe cambiare improvvisamente verso nessun arrivo del tutto, oppure arrivi solo di porzioni di radiazione dell’imbarcazione. Il suono da una sorgente può sembrare arrivare da molte direzioni ad una volta. Le caratteristiche dei ricevitori possono anche causare suono da differenti riferimenti per mixare, il sembrare per venire da una singola posizione. Infine, gli obiettivi del sottomarino di maggior interesse sono molto silenziosi e segreti.

Supportato dalla DARPA, il lavoro su questo problema iniziò nel 1973 alla Systems Control Technology, Inc. (SCI) una company di Palo Alto con esperienza in questa area che potrebbe lavorare su progetti classificati militari. (SCI fu successivamente acquisita dalla British Petroleum.) Feigenbaum e i suoi colleghi alla SCI, avevano presto realizzato che la strategia “generate-and-test” di DENDRAL non avrebbe funzionato per il problema della sorveglianza dell’oceano perché non c’era alcun “legal move generator” che potrebbe produrre posizioni della nave candidata e le loro tracce fornite, i dati (data) della sorveglianza. Tuttavia, notando che il problema dell’analisi complessiva potrebbe essere diviso in livelli simili a quelli usati nell’architettura Blackboard di HEARSAY-II (un sistema mostra di essere capace di trattare segnali nel rumore), il team ha pensato che qualcosa di simile avrebbe funzionato per il loro problema. Il team ha sviluppato un sistema chiamato HASP (un acronimo per Heuristic Adaptive Surveillance Program) basato sul modello Blackboard. Il lavoro derivato che dovrebbe elaborare i dati effettivi dell’oceano iniziò alla SCI con SIAP (un acronimo per Surveillance Integration Automation Program) nel 1976. Darò una breve descrizione del progetto del sistema HASP/SIAP e poi riassumerò come esso ha funzionato.

Il livello top della Blackboard era una “situation board” – un modello simbolico della situazione dell’oceano che si dispiega, costruito e mantenuto dal programma. Esso ha descritto tutte le navi ipotizzate essere fuori di lì con un livello di confidenza (confidence) associato con ciascuna di esse.

Appena sotto il livello dell’imbarco della situazione era un livello che conteneva le imbarcazioni singole ipotizzate. Ciascun elemento dell’imbarcazione aveva informazione riguardo la classe, la posizione, la velocità corrente, la rotta e la destinazione, ciascuno con una confidence weighting. Sotto l’imbarcazione il livello era un livello che conteneva le sorgenti di suono ipotizzate: motori, shafts, propellers e…con le loro posizioni e la ponderazione di fiducia (confidence weighting). Le caratteristiche dello spettro astratte dai dati acustici erano al livello più basso.

I livelli erano collegati alle sorgenti della conoscenza (KSs) che erano capaci di inferire che se certi elementi erano sospettati essere presenti ad un livello poi gli altri elementi potrebbero essere inferiti per essere presenti ad un altro livello (oppure se essi erano già presenti a quel livello, la loro confidenza (confidence) potrebbe essere adattata. Proprio come in HEARSAY-II, i collegamenti potrebbero attraversare livelli multipli e fare inferenza verso l’alto, verso il basso o all’interno di un livello. Un’inferenza causata da una KS potrebbe consentire ad un’altra KS di dedurre ) un’inferenza aggiuntiva, …a cascata, finché tutta l’informazione rilevante è stata usata. In questa maniera, nuova informazione potrebbe essere assimilata e le attese concernenti possibili futuri eventi potrebbero essere formulate.

Un tipo di KS era composto di regole IF-THEN. (Altri tipi erano anch’essi usati.) Per esempio, ecco una regola IF-THEN (tradotta in inglese per leggibilità) che agiva all’interno del livello della sorgente:

IF: una sorgente era perduta dovuta all’affievolirsi nel passato vicino e una sorgente simile è partita in un’altra frequenza e le posizioni delle due sorgenti sono relativamente vicine,

THEN: esse sono le stesse sorgenti con confidenza (confidence) di 3.

HASP/SIAP aveva molti tipi di sorgenti di conoscenza (KSs), ciascuna rappresentata in un modo opportuno ai/al livello/i implicato/i. Alcune KSs erano basate su informazione circa l’ambiente, come comuni rotte di navigazione, posizione degli schieramenti (location of arrays) e aree di manovra note. Altre avevano informazione riguardo le navi e tipi di navi, le loro velocità, le parti componenti, le caratteristiche acustiche, basi,… In aggiunta alle KSs trattare l’appropriata conoscenza per i vari livelli, c’erano “meta” KSs che avevano informazione riguardo come usare altre KSs.

Le azioni delle KSs nel collegare informazione ai vari livelli possono essere rappresentate come una network. Alla fine della sessione di analisi, quando tutte le KSs avevano avuto una chance di partecipare e l’azione finisce, la network risultante è chiamata la “current best hypothesis” (CBH) circa la corrente situazione dell’oceano. Ecco un campione (sample) parziale (tradotto in inglese) di come una CBH per una particolare funzionamento (run) di HASP/SIAP potrebbe essere descritto:

La classe di Vessel-1, localizzata nella vicinanza di Latitudine 37.3 e Longitudine 123.1 al giorno 2, alle ore 4, 55 minuti può essere la classe o Cherry, Iris, Tulip o Poppy. Due distinte sorgenti sonore, supportate dai rispettivi insiemi di armoniche, sono stati identificati per Vessel-1. La Sorgente-1 potrebbe essere dovuta ad un asse (shaft) o ad un’elica (propeller) di una nave di classe Cherry o Poppy. Possibilità di sorgenti simili esistono per Source-5. Queste due sorgenti erano assimilate in Vessel-1 a causa della possibilità di un rapporto (ratio) meccanico noto che esiste tra le due sorgenti.

La MITRE Corporation ha condotto molti esperimenti per confrontare la performance di HASP/SIAP rispetto a quella di due esperti analisti di sonar. In uno di questi esperimenti, MITRE ha concluso che “HASP/SIAP sono stati mostrati eseguire bene sull’oceano i dati derivati…Per questa scena dell’oceano ristretta, il programma non è confuso da dati estranei e dà risultati comparabili con un analista esperto.” In un altro esperimento, esso ha concluso che “HASP/SIAP” hanno capito la scena dell’oceano più scrupolosamente rispetto al secondo analista e così come il primo analista…Il programma può funzionare effettivamente con più di uno schieramento acustico (acoustic array). SIAP ha classificato una scena sull’oceano su un periodo di tempo di tre ore che indica la plausibilità dell’efficacia di SIAP in una situazione in oceano che si evolve.” Il terzo esperimento ha condotto alla conclusione che “con l’eccezione che il programma SIAP ha ottenuto significativamente più contatti che l’analista umano, le descrizioni della scena dell’oceano sono molto simili.” Inoltre, “SIAP può eseguire la classificazione delle navi in scene in oceano di difficoltà crescente senza grandi incrementi nell’uso delle risorse del computer.”

Come menzionato in precedenza, il modello Blackboard è stato applicato in molte altre aree. Esempi, inclusa l’analisi cristallografica delle proteine, la comprensione di immagini, e comprensione di dialoghi. Interessantemente, l’architettura di Blackboard ha impatti oltre la tecnologia. Donald Norman, uno psicologo cognitivista ha detto che HEARSAY-II è stato la sorgente di idee per la psicologia teorica e che esso realizza le sue “intuizioni circa la forma di una generale struttura del processo cognitivo.” Inoltre, come spiegherò in un prossimo post, molti metodi delle neocorteccia implicano l’interagire di livelli somiglianti sia la forma sia i meccanismi dei sistemi Blackboard.

Transportable Natural Language Query Systems

Come l’ho descritto, CHAT-80 era implementato in un sistema per querying un database di dati geografici. Tuttavia, poiché la maggior parte del suo progetto non era specifica per la geografia, esso potrebbe piuttosto facilmente essere modificato per essere capace di trattare altri database. CHAT-80 era solo uno di molti sistemi di query che erano “transportable” nel senso che potrebbero essere adattati a servire come front ends in NL per una varietà di differenti databases. Altri di questi sistemi erano ASK sviluppato alla Caltech, EUFID sviluppato al SDS, IRUS sviluppato alla BBN, LDC-1 sviluppato alla Duke University, NLP-DBAP sviluppato ai Bell Laboratories, e TEAM sviluppato allo SRI.

TEAM (un acronimo per Transportable English Database Access Medium) era stato supportato dalla DARPA ed era stato progettato per acquisire informazione riguardo un database da un amministratore di database e per interpretare e rispondere a questions del database che erano poste in un sottoinsieme di un inglese appropriato per quel database. TEAM, come molti altri sistemi trasportabili, era stato costruito in modo tale che l’informazione necessaria per adattarlo ad un nuovo database e il suo corrispondente oggetto potrebbe essere acquisito da un esperto su quel database anche se egli o ella potrebbero non conoscere niente riguardo alle NL interfacce.

Per illustrare l’operazione di TEAM, i suoi progettisti hanno usato una database consistente di quattro “files” (o “relazioni”) di dati geografici. Io traccerò direttamente alcuni dei passi che TEAM ha usato per rispondere alla query “Show each continent’s highest peak.”

TEAM ha usato un sottosistema chiamato DIALOGIC per convertire la query in inglese in una espressione logica. All’interno di DIALOGIC, un sottosistema basato su DIAMOND ha eseguito un’analisi sintattica usando la grammatica di DIAGRAM.

Basato su un parse tree e sulla conoscenza circa i concetti usati nel database, un sistema di analisi semantica avrebbe convertito la query nella seguente espressione logica (qui riformulata in una forma English-like per una migliore comprensibilità):

FOR EVERY CONTINENT

WHAT IS EACH PEAK

SUCH THAT THE PEAK IS THE HIGHEST PEAK SUCH THAT

THE CONTINENT IS CONTINENT OF THE PEAK?

TEAM poi ha usato la sua conoscenza circa la struttura del database e circa come i componenti di questa espressione logica sono associati con relazioni nel database per generare l’effettiva query del database e costruire una risposta (answer).

CHAT-80

Tra il 1979 e il 1982, Fernando Pereira e David H.D. Warren hanno sviluppato un sistema chiamato CHAT-80 alla University of Edinburgh come parte della dissertazione Ph.D. di Pereira. CHAT-80 era capace di rispondere a piuttosto complicate domande, poste in inglese, riguardo un database di dati geografici.

Secondo la dissertazione di Pereira, il lavoro su CHAT-80 è iniziato come “un tentativo di chiarificare e migliorare il precedente lavoro NL di Colmerauer.” CHAT-80 era scritto in PROLOG, il linguaggio di programmazione basato sulla logica sviluppato originariamente da Alain Colmerauer. Infatti, la grammatica usata per CHAT-80 consisteva di formule logiche dichiarate in linguaggio PROLOG. Per esempio,

sentence (s(NP, VP), S0,S) :-noun-phrase (NP, N, S0, S1),

verb_phrase (VP, N, S1,S)

è un modo di CHAT-80 di dichiarare che “C’è una frase tra i punti S0 e S in una stringa (di parole) se c’è una noun phrase con numero N (cioè, singolare o plurale) tra i punti S0 e S1 e una verb phrase con numero N tra i punti S1 e S.” Le grammatiche definite dalle clausole (clauses) di PROLOG di questo tipo sono chiamate Definite Clause Grammars (DCGs). Molte clauses di questo tipo erano usate da CHAT-80 per verificare la sintassi (parse) di frasi in inglese. L’effettivo parsing era fatto dal programma PROLOG che consisteva di queste clauses.

In CHAT-80, la computazione del significato (cioè, la semantica) di una query in inglese era guidata dalla struttura sintattica della query (come computato dal programma in PROLOG) ed era espressa come una formula logica. Questa formula era poi trasformata nelle singole queries del database necessarie per rispondere alla originaria domanda. (Per informazioni riguardo come ottenere un versione funzionante di CHAT-80, si veda http://www.nltk.org/howto/chat80.html

Sebbene gli esempi indicano una performance piuttosto di grande effetto, le capacità di CHAT-80 erano vincolate (constrained) dal suo vocabolario e dalla sua grammatica limitate. Queste limitazioni sono descritte in dettaglio nella dissertazione di Pereira.

https://www.lpa.co.uk/ind_hom.htm

Natural Language Access to Computer Systems

Allo SRI, Gary Hendrix stava sviluppando un sistema chiamato LIFER (un acronimo per Language Interface Facility with Elliptical and Recursive Features), programmato in INTERLISP, per rapido sviluppo di “front ends” in linguaggio naturale a databases e altri software. LIFER ha consentito ad un utente non tecnico di specificare un sottoinsieme di un linguaggio naturale (per esempio, l’inglese) per interagire con un sistema di database o altri software. Un parser (analizzatore della correttezza della sintassi) contenuto all’interno di LIFER potrebbe poi tradurre frasi (sentences) e richieste in questo linguaggio in appropriate interazioni con il software. LIFER aveva meccanismi per gestire ellittici (elliptical) (cioè, incompleti) inputs, per correggere errori di spelling e per consentire ai principianti di estendere il linguaggio attraverso l’uso di parafrasi.

Un’interessante caratteristica di LIFER era che il linguaggio che potrebbe gestire era definito in termini di “patterns”, che usavano concetti semantici nel dominio di applicazione. Uno di questi pattern, per esempio, potrebbe essere

WHAT IS THE <ATTRUBUTE> OF <PERSON>

dove le parole WHAT, IS, THE e OF sono parole effettive che potrebbero occorrere in una query in inglese e <ATTRIBUTE> e <PERSON> sono caratteri jolly (“wild cards”) che potrebbero corrispondere ad ogni parola in insiemi predefiniti. <ATTRIBUTE> potrebbe essere definito per corrispondere a parole come AGE, WEIGHT, HEIGHT,…, e <PERSON> potrebbe corrispondere a JOHN, SUSAN, TOM,…, Questo pattern dovrebbe poi riconoscere (“recognize”) una frase come

WHAT IS THE HEIGHT OF SUSAN

Questo metodo di definire una “grammar” deve essere confrontato con le usuali regole sintattiche della phrase-structure come S <= NP VP. Come ho ricordato in precedenza, grammatiche basate su concetti nel dominio di applicazione sono chiamate “semantic grammars.”

LIFER usava una semplificata augmented transition network per analizzare una frase in input. Ciascun pattern definito dalla grammatica corrispondeva ad un possibile “path” nella transition network. Una frase in input era analizzata dal tentativo di farla corrispondere ad uno di questi percorsi, notando che specifici esempi di un carattere jolly (wild card), come <ATTRIBUTE> era usato nella corrispondenza (match). In funzione del percorso preso e dei valori dei caratteri jolly nel percorso, i software erano automaticamente creati ed erano poi usati per fare l’appropriata query al database oppure per effettuare un appropriato comando. Nel 1982, Hendrix lasciò lo SRI per fondare la Symantec, una compagnia che aveva pianificato di sviluppare e commercializzare un sistema di question-answering NL basato su grammatiche semantiche come LIFER. [Forse NLP (o la commercializzazione intesa) non era assolutamente pronto, perché la Symantec fu successivamente riorganizzata per commercializzare software per la computer security e anti-virus].

LIFER era stato usato allo SRI come il componente di NL di un sistema chiamato “LADDER” per accedere a multipli e distribuiti databases. LADDER (un acronimo per Language Access to Distributed Data with Error Recovery) traduceva la query dall’inglese in una ipotetica query al database che ipotizzava una molto semplice organizzazione del database. Usando un sistema chiamato IDA (un acronimo per Intelligent Data Access) questa ipotetica query era trasformata in una serie di reali database queries che tenevano conto dell’effettiva organizzazione del database. Esso considerava la conoscenza sintattica e semantica per tentare di produrre queries molto efficienti e di individuare ogni aggiornamento erroneo al contenuto del database (Molte ricerche su sistemi simili ad IDA furono eseguite in un programma misto tra la Stanford University e lo SRI, chiamato, KBMS, un acronimo per Knowledge Based Management System, con il supporto della DARPA.)

Coerente con il focus di DARPA su applicazioni militari, LADDER era capace di answer questions circa le navi della marina usando informazione riguardo le dimensioni della nave, i tipi, le posizioni (locations) da vari databases. È da notare l’abilità del sistema di correggere errori di spelling, di trattare domande incomplete e accettare parafrasi.

Understanding Queries and Signals

The Setting

Continua Nilsson:

“Fino a circa la metà degli anni settanta, i managers della DARPA erano capaci di attutire l’impatto del Mansfield Amendment (che richiedeva che la ricerca del Defense Department fosse rilevante per necessità militari) descrivendo i programmi di ricerca sui computer in un modo che enfatizzava le applicazioni. Larry Roberts, il Direttore dell’IPTO della DARPA durante gli ultimi anni sessanta e i primi anni settanta, scrisse

Il Mansfield Amendment ha creato un particolare problema durante la mia permanenza alla DARPA. Esso ci ha costretto a produrre un considerevole lavoro d’ ufficio e a dover difendere progetti su una base differente. Esso ci ha fatto avere più lavoro di sviluppo comparato al lavoro di ricerca per ottenere un mix come questo che potremmo difenderlo. Io non penso che ho dovuto lasciar cadere un progetto nel nostro gruppo dovuto al Mansfield Amendment, tuttavia. Noi potremmo sempre trovare un modo per difendere l’informatica…

Le formali sottomissioni al Congresso per AI furono scritte cosicché il possibile impatto fosse enfatizzato, senza considerazioni teoriche.

Cordell Green, che lavorava sotto Roberts all’IPTO, scrisse

Parlando in generale, ogni cosa che è arrivata nel campo dell’AI che noi avevamo pensato sembrasse buona era supportata…

Uno dei miei lavori era di difendere il budget di AI ma ciò era terribilmente difficile…tutti i tipi di informatica sono rilevanti perché essi potrebbero avere un alto impatto su ogni ampia organizzazione dell’elaborazione dell’informazione e il Defense Department è certamente un’organizzazione…tutta questa ricerca dovrebbe essere tenuta viva perché essa ha una potenziale rilevanza militare.

Dalla metà degli anni settanta, tuttavia, la pressione per produrre sistemi utili militarmente divenne molto più intensa. La DARPA, che era stata generosamente di supporto piuttosto che non dirigere la ricerca di base in AI, ha iniziato a focalizzarsi invece sul risolvere “pressanti problemi del DoD”. Sebbene il direttore dell’IPTO della DARPA in quel periodo, J.C.R. Licklider, era sempre comprensivo per la ricerca di base in AI, il top management della DARPA ebbe atteggiamenti ) interamente differenti. Licklider stava avendo difficoltà nello spiegare il suo programma per AI al “front office” della DARPA. Il direttore della DARPA durante i primi anni settanta, Stephen Lukasik, era (secondo Licklider³)

né a favore né contro AI. Egli era per un buon management ed egli ebbe l’idea che forse un po’ della ricerca di AI non era stato ben gestito…[Egli] aveva un’idea fissa che una proposta non è una proposta senza che essa abbia pietre miliari. Io penso che egli credesse che più pietre miliari, la migliore proposta…Io penso che egli non stesse sviluppando un’avversione per AI ma una convinzione che questo è un importante campo che i ricercatori devono avere per apprendere a vivere una maggiore, più rigida, più strutturata amministrazione.”

Il punto di vista di Lukasik circa come i progetti potrebbero essere gestiti ebbe un effetto diretto sulla ricerca di base in AI supportata dalla DARPA. Per esempio, un “Quarterly Management Report” che io ho sottoposto nel febbraio del 1975 che descriveva il progresso sul consultant computer-based dello SRI ha costretto Licklider a chiedere come il report potrebbe essere riformulato per enfatizzare il progresso lungo determinati percorsi in una “PERT Chart” “Ciò che mi piacerebbe avere. “ egli mi scrisse in una lettera datata 3 marzo 1975, “è la PERT Chart – cosicché io potrei marcare i risultati in rosso e vedere dove voi siete rispetto al modello complessivo ….Hai questa carta? Se sì, ti prego di inviarmene una copia. Se no, che ne dici di farne una? Essa ci aiuterebbe realmente e grandemente qui all’ARPA.”

Ovviamente, nella ricerca di base, sebbene si possano descrivere in generale i problemi che si sta provando a risolvere, non si possono descrivere (in anticipo) le soluzioni. Infatti, come i progressi della ricerca esplorativa, nuovi problemi diventano apparenti, così non si possono neanche descrivere tutti i problemi in anticipo. Non si può fare il tipo di piano dettagliato per la ricerca di base che si può fare per applicare la tecnologia già sviluppata a specifiche applicazioni. Sfortunatamente, il management della DARPA stava per essere cambiato da persone che avevano capito come iniziare e gestire la ricerca di base a persone che conoscevano come gestire le applicazioni della tecnologia.

Il cambiamento verso un più breve termine, la ricerca gestita più intensamente divenne più pronunciata quando George Heilmeier sostituì Stephen Lukasik come direttore della DARPA nel 1975. Heilmeier veniva dalla RCA, dove egli aveva diretto il gruppo di ricerca che ha inventato il primo LCD (liquid crystal display). Licklider successivamente scrisse che Heilmeier “voleva comprendere AI nel modo in cui egli aveva capito LCD…”

Uno dei compiti che Heilmeier diede all’IPTO fu di produrre una “roadmap” per il suo programma di ricerca in AI (e anche i suoi altri programmi di informatica) Questa roadmap avrebbe riassunto i passati risultati, indicato le aree dove l’esistente tecnologia potrebbe essere applicata a problemi militari e mostrare le pietre miliari lungo la via. Questo orientamento dal management della DARPA ha causato grandi difficoltà per Licklider, alcune delle quali furono spiegate in un e-mail che egli inviò ad alcuni leaders della ricerca in AI nell’aprile del 1975. (io ero tra coloro che ricevettero il suo “Easter Message” il 2 aprile del 1975). Ecco alcuni estratti:

Lo scopo di questa nota di Pasqua è di aggiornarvi su uno sviluppo in ARPA che mi preoccupa grandemente – e potrebbe, io penso, preoccupare anche voi…

…la direzione prevalente in ARPA è di fare ricerca all’interno degli specifici contesti di problemi militari e non fare ricerca che non abbia un compratore militare pronto a prenderlo appena il concetto è stato ben formulato…

[ci sono] forti pressioni da parte del nuovo Direttore, George Heilmeier, che IPTO ridiriga i tentativi di AI nelle università per lavorare su problemi che hanno una reale validità per la DoD…

…la situazione è complicata dal fatto che ARPA ha supportato la ricerca di base ad un livello piuttosto alto per più di dieci anni (essa ha speso più di $50 milioni su di essa) ed è naturale per un nuovo direttore, o persino per un ex chiedere, “Cosa abbiamo ottenuto da essa in termini di miglioramenti nella difesa nazionale?”

Secondo la nota di Pasqua di Licklider, alcune delle cose che Heilmeier pensò che IPTO potesse fare per il Defense Department erano le seguenti:

• ottenere dai computers di leggere il codice Morse in presenza di altro codice e di rumore (noise)
• ottenere dai computers di identificare parole chiave in un flusso di parlato
• risolvere il “software problem” del DoD
• dare un reale contributo per comandare e controllare e
• fare un buon lavoro sul sonar

Anche se uno degli elementi sulla lista di Heilmeier riguardava l’elaborazione del parlato (speech processing), una delle vittime di questo mandato come Direttore della DARPA era il SUR Program. Nessuno dei sistemi che erano stati sviluppati sotto il programma potrebbe rispondere in tempo reale, e neppure potrebbero trattare vocabolari abbastanza ampi. Heilmeier ha creduto (probabilmente con buona ragione) che la comprensione del significato delle parole pronunciate (speech understanding) era ancora un’attività di ricerca di base. Così, egli pensò, che esso potesse essere supportato, diciamo, dalla National Science Foundation (NSF) ed egli rifiutò le proposte alla DARPA per continuarlo.

Sfortunatamente, la maggior parte delle aree di ricerca che erano sulla lista personale di Licklider (che aveva già richiesto nella sua nota di Pasqua) non era esplicitamente su quella di Heilmeier. (Io non posso resistere al ricordre uno degli elementi sulla lista di Licklider: “Sviluppare un sistema che potesse guidare uomini non sufficientemente addestrati alla manutenzione attraverso la manutenzione di un complesso apparato” Uno degli elementi della lista di Heilmeier era sufficientemente vago, tuttavia, per giustificare il lavoro sia in NLP sia in computer vision. Questo era “command and control”, un’attività che riguardava l’ottenere e presentare una rilevante informazione per i comandanti cosicché essi potevano controllare effettivamente le forze militari.

Gli ufficiali del programma della DARPA Floyd Hollister e il Col. David Russell erano capaci di persuadere il management della DARPA che l’accesso ad ampi e distribuiti databases con il linguaggio naturale basato su un testo scritto (natural language text-based), sarebbe stato un importante componente dei sistemi di command and control . Essi hanno arguito che la tecnologia per questi accessi era sufficientemente molto lunga per essa che sarebbe stata applicata a quelli che essi hanno chiamato “command-and-control test-bed systems” Dopo tutto, Bill Woods e colleghi alla BBN avevano già mostrato pubblicamente LUNAR, un natural language “front end” per databases riguardo rocce lunari. Molti altri ricercatori avevano iniziato a lavorare anche al problema di come comunicare con i computers usando l’inglese o qualche altra lingua. (per esempio, ci furono oltre quaranta articoli su NLP presentati al Fifth IJCAI nel 1977 al MIT e pubblicati nel febbraio del 1977dalla ACM’s SIGART Newsletter ha pubblicato 52 riassunti della ricerca in corso su “Natural Language Interfaces”) Nella successiva parte di questo post, descriverò alcuni dei risultati durante questo periodo sul comunicare con i computers usando natural language.

Una seconda area di grande importanza nel command and control era l’automatizzare l’analisi di foto aeree. Individuare obiettivi di interesse militare in queste foto, come strade, ponti e apparati militari tipicamente hanno richiesto ore di tentativi da parte degli intelligence analysts. Poiché le tecniche che stavano per essere sviluppate dai ricercatori in computer vision avrebbero potuto fornire strumenti per aiutare gli analysts umani, DARPA ebbe buoni motivi per continuare a finanziare la ricerca sulla computer vision. Nel 1976, iniziò il programma “Image Understanding” (IU) per sviluppare la tecnologia richiesta per l’interpretazione automatica e semiautomatica e l’analisi di fotografie militari e immagini correlate. Sebbene inizialmente concepito come un programma quinquennale, esso continuò (con obiettivi più ampi) per oltre venti anni. Io riassumerò il lavoro su image understanding, insieme all’altra ricerca su computer vision nel successivo post.

Fare qualcosa circa il sonar era uno degli elementi della lista di Heilmeier. Infatti, nella sua nota di Pasqua Licklider scrisse “Una delle principali aree di soluzione ottimale di [Heilmeier] è il sound sott’acqua e il sonar e IPTO è nell’acquisto coattivo sul progetto HASP (un approccio ad AI di Ed Feigenbaum).”

Expert Companies

Nuove compagnie e divisioni di aziende fondate avevano iniziato a sviluppare e schierarono queste applicazioni. La prima di queste fu Teknowledge, organizzata da un gruppo della facoltà a Stanford e da ricercatori per commercializzare sistemi esperti e per fare consulenza circa sistemi esperti. Teknowledge ha usato EMYCIN come la sua tecnologia di base. Un’ altra fu Syntelligence, fondata da Peter Hart e Richard Duda (insieme ad alcuni dei ricercatori di PROSPECTOR) per commercializzare sistemi esperti per sottoscrivere assicurazioni e analisi del credito prestito. Alla Syntelligence, i sistemi esperti erano scritti nel linguaggio SYNTEL, sviluppato da René Reboh e Tore Risch e basato sulle idee di PROSPECTOR. Dopo aver lasciato la CMU, Charles Forgy ha fondato la Production Systems Technology nel 1983 “per sviluppare e commercializzare strumenti basati su regole all’avanguardia ”

Tra le altre compagnie formate durante questo periodo ci furono Aion Corporation, Helix Expert Systems. Ltd., Exsys, Inc., Inference Corporation e IntelliCorp. Poiché non era troppo difficile per i clienti che volevano sistemi esperti per sviluppare la loro propria versione (che erano capaci di funzionare a basso costo su workstations e personal computers), molte compagnie dei sistemi esperti hanno cessato di esistere, erano acquisite da grandi compagnie o avevano riorientato i loro investimenti per fornire servizi aggiuntivi o correlati.

Dopo la raffica di entusiasmo sui sistemi esperti si spense un po’ negli anni ottanta e novanta, alcuni sviluppatori si sono concentrati su sistemi per acquisire e distribuire “business rules”. Secondo un’organizzazione chiamata Business Rules Group, una business rule è “una proposizione (statement) che definisce o vincola (constrains) alcuni aspetti del business. Essa è intesa per affermare (assert) strutture di business o per controllare o influenzare il comportamento del business.” Per esempio, una business rule potrebbe dichiarare (state) “When our widget inventory is below 200, notify widget production”. Le business rules prendono la forma delle IF-THEN proposizioni (statements), proprio come le regole dei sistemi esperti. Nelle applicazioni business, i motori di inferenza di sistemi esperti si sono trasformati in motori di regole di business (BREs). Essi sono stati usati o per answer questions circa pratiche commerciali o per intraprendere azioni come ordinazioni o l’invio di avvisi. Alcune delle persone che sono state implicate nel fornire software di sistemi esperti sono passate al software business-rule. Per esempio, nel 2002, Charles Forgy ha fondato la RulesPower, Inc., i cui sistemi di management delle business regole (BRMSs) hanno usato una successiva versione dell’algoritmo Rete. (Nel 2005, RulesPower ha venduto alcuni delle sue azioni alla Fair Isaac Corporation, una compagnia tecnologica di analitica (analytics) e gestione della decisione aziendale (decision management), che ha da allora cambiato il suo nome in FICO.)

Altri Sistemi Esperti

Molti altri sistemi esperti hanno seguito il lavoro su MYCIN e PROSPECTOR. Alcuni, come MYCIN, erano per diagnosi e terapia mediche. Di queste, ricorderò il programma INTERNIST-1 degli informatici Randolph A. Miller e Harry E. Pople e il medico Jack D. Myers alla University of Pittsburgh e il programma CASNET (Casual-ASsociational NETwork) di Casimir A. Kulikowski e Sholom M.Weiss della Rutgers University.

Le serie di programmi per la diagnosi INTERNIST-1 ha contenuto esperienza circa la medicina interna. Parte di questa conoscenza era rappresentata in un tipo di rete semantica (semantic network) o tassonomia di stati di malattia (chiamata una nosology in medicina). In un articolo nel New England Journal of Medicine, Miller, Pople e Myers conclamarono la performance di INTERNIST-1 “su una serie di 19 casi clinico-patologici (Case Records of the Massachusetts General Hospital) e hanno pubblicato nel Journal alcuni casi che erano apparsi qualitativamente simili a quelli dei clinici dell’ospedale ma inferiori a quello dei casi discussi.” Tuttavia, essi hanno concluso che “la forma presente del programma non è [ancora] sufficientemente affidabile per applicazioni cliniche.” Successivamente, molta della conoscenza diagnostica assemblata in INTERNIST-1 fu riassemblata (repackaged) in QMR (Quick Medical Reference), un sistema di supporto alle decisioni diagnostiche per internisti. (Esso è stato da allora interrotto dal suo finale acquirente la First DataBank).

CASNET ha anche usato networks. In quelle, “inference rules” collegate alle osservazioni, agli stati pato-fisiologici, agli stati diagnostici e stati di trattamento. La loro principale applicazione fu ad un glaucoma per il quale essi avevano buoni modelli medici sui quali le regole di inferenza potevano essere usate.

Alla CMU, John McDermott ha aiutato nello sviluppo di un sistema basato sulla regola (rule-based) chiamato XCON (per eXpert CONfigurer) per assistere nell’ordinamento e nel configurare dei sistemi di computer VAX della Digital Equipment Corporation. XCON derivò da un precedente sistema di McDermott chiamato R1. R1 e XCON erano stati scritti in uno speciale linguaggio rule-processing chiamato OPS5, uno della famiglia OPS di linguaggi sviluppati da Charles Forgy alla CMU. (OPS è detto essere un acronimo di Official Production System). I linguaggi OPS hanno usato l’algoritmo “Rete” di Forgy per mettere insieme efficientemente le regole IF-THEN.³⁵ XCON per primo andò in uso nel 1980 nell’impianto di DEC a Salem, New Hampshire.

Il problema di come trattare con informazione incerta era stato evitato in XCON perché esso al più non ha mai incontrato un problema di configurazione che esso non aveva abbastanza conoscenza certa da gestire. Dal 1989, secondo un articolo riguardo XCON e relativo ai sistemi di configurazione al DEC, questi sistemi hanno un totale di 17.500 regole. L’articolo continuò col dire che

…complessivamente il ricavo netto per Digital è stimato essere in eccesso di $40 milioni all’anno.

L’uso dei sistemi di configurazione controlla che completi, consistentemente sistemi configurati sono inviati al consumatore . Ordini incompleti non si ottengono attraverso il processo. In aggiunta, XCON genera configurazioni che ottimizzano la performance del sistema, così i consumatori consistentemente ottengono il migliore punto di vista dei nostri prodotti. Prima dei sistemi di configurazione, noi avremmo spesso inviato le stesse parti configurate differentemente.

In aggiunta a XCON e i suoi fratelli della DEC, molti sistemi esperti erano costruiti e messi in uso da compagnie e laboratori di ricerca durante gli anni ottanta. Nel 1983, la General Electric ha sviluppato il Diesel Electric Locomotive Troubleshooting Aid (DELTA), un sistema prototipo per assistere personale ferroviario nella manutenzione delle locomotive diesel-electric della General Electric. Gli sviluppatori hanno dichiarato che esso “può diagnosticare molteplici problemi con la locomotiva e può suggerire procedure di riparazione per la manutenzione individuale.” Esso aveva 530 regole “parzialmente rappresentanti la conoscenza di un Senior Field Service Engineer.”

Un altro esempio è JETA (Jet Engine Troubleshooting Assistant), sviluppato dagli ingegneri al National Research Council in Canada. Secondo un articolo circa JETA, esso “è stato applicato per risolvere i problemi del motore del jet General Electric J85-CAN-15 motore che potenzia gli addestratori di volo del CF-5 usato dalla Canadian Air Force.”

La conoscenza circa i motori di un jet e i loro possibili guasti e i sintomi sono codificati in frames. Le regole sono usate esclusivamente per “specifiche funzioni di controllo incorporate (embedded) in un frame e per asynchronous user input.”

Un sistema esperto chiamato CHH-ES per credit analysis fu messo in uso alla divisione Credit Clearing House (CCH) di Dun & Bradstreet (D&B) nel luglio del 1989. Esso conteneva approssimativamente 800 regole e potrebbe gestire transazioni online quando i clienti CCH erano chiamati in servizio o quando gli analisti volevano rivedere i casi. Gruppi di casi funzionarono quando essi erano aggiornati nei rilevanti databases. Secondo un articolo circa il sistema “l’accettazione dell’analista (analyst agreement) con CCH-ES continua ad essere approssimativamente il 98.5 percento su base continuativa …[esso] è stato un maggiore successo alla D&B. Esso ha fornito CCH con un sistema esperto di credit analyst che poteva fornire consistentemente decisioni su credit analysis di livello esperto e ad un livello di alta qualità. I clienti hanno uniformemente apprezzato il sistema.”

Molti sistemi esperti sono descritti nel libro The Rise of the Expert Company. In un’appendice a quel libro, Paul Harmon elenca oltre 130 sistemi esperti in uso durante la metà e la fine degli anni ottanta, includendo

• Grain Marketing Advisor per aiutare gli agricoltori a scegliere le strategie di marketing o conservazione per le loro colture di grano,
• ACE per aiutare le compagnie che operano nella telefonia a ridurre l’incidenza dei guasti nei cavi telefonici
• IDEA per aiutare i tecnici a diagnosticare situazioni di difficoltà nella Infotron IS4000 Local Area Network
• Diag 8100 per aiutare con la diagnosi di problemi e guasti in computers IBM 8100 alla Travelers Corporation.
• Intelligent Peripheral Troubleshooter per aiutare la risoluzione dei problemi dei disk drives della Hewlett-Packard
• SNAP per aiutare i venditori all’Infomart (un negozio di computer a Dallas) valutare le loro necessità per i personal computer
• Pile Selection per aiutare progettisti alla Kajima Construction Company a selezionare materiale di calcestruzzo per essere usato nelle fondamenta degli edifici.
• ExperTAX per aiutare a valutare l’applicazione di nuove leggi tax U.S. per clienti di Coopers and Lybrand
• Dipmeter Advisor per aiutare nelle analisi di formazioni geologiche che hanno trovato nelle perforazione pozzi petroliferi.

PROSPECTOR

Continua a narrare N.J. Nilsson:

“Ispirato dal lavoro di Shortliffe con MYCIN, alcuni di noi allo SRI iniziammo a investigare applicazioni non mediche di sistemi esperti. Un’area che noi abbiamo considerato fu la gestione integrata dei parassiti (“integrated pest management”) nella quale la conoscenza riguardo le coltivazioni (crops) e i loro insetti (insect pests) potrebbero essere usate per mitigare gli effetti di predazione di insetti (insect predation) con un uso minimo di insetticidi chimici. Sebbene proposte furono scritte e qualche interesse era stato mostrato dagli scienziati dello U.S. Department of Agriculture e alla Environment Protection Agency, l’idea fu abbandonata quando le proposte non vennero finanziate.

Peter Hart e Richard Duda infine si sono focalizzati su sistemi per fornire consigli a esploratori riguardo possibili depositi di minerali “hard-rock”. Hart ebbe alcune prime discussioni con John Harbaugh, un professore di petroleum engineering a Stanford e con Alan Campbell uno degli studenti laureati di Harbaugh. (Alan Campbell era il figlio dello scomparso Neal Campbell, un esploratore di fama mondiale il quale aveva scoperto ciò che era forse il più grande deposito nel mondo di piombo-zinco. Alan passò molta della sua gioventù in siti minerari. Attraverso Campbell, Hart e Duda incontrarono Charles Park, ex Preside di facoltà della School of Earth Sciences di Stanford e un’autorità su depositi minerari di hard-rock. Park ha aiutato Hart e Duda a codificare la conoscenza sui depositi di piombo-zinco nella forma di regole IF-THEN. Ulteriore lavoro con Marco Einaudi, un professore del Department of Economic Geology di Stanford, portò ad aggiuntive regole e idee sulla rule-organizing. Ultimamente lo U.S. Geological Survey ha fornito finanziamenti per lo sviluppo di quello che divenne il sistema esperto PROSPECTOR per consultazione circa depositi minerari.

Un ampio gruppo di persone ha partecipato al progetto e alla scrittura del programma PROSPECTOR. Duda e Hart condussero il tentativo. Io mi unii al progetto un po’ dopo il lavoro che essi avevano iniziato e dopo aver sentito dalla DARPA che il progetto CBC non sarebbe stato continuato. Altri collaboratori esterni furono John Gaschnig (1950-1982), Kurt Konolige, René Reboh, John Reiter, Tore Risch e Georgia Sutherland. MYCIN ebbe un influsso dominante sulla tecnologia che stava per essere sviluppata – “prima di tutto attraverso il suo uso di regole per rappresentare conoscenza giudicante e la sua inclusione di meccanismi formali per gestire l’incertezza” Altri importanti influssi vennero da un altro sistema di diagnosi medica, INTERNIST-1, che descriverò brevemente. Questi erano il loro uso di taxonomic information e la sua abilità di gestire l’informazione volontaria [piuttosto che solo quella richiesta].

PROSPECTOR ha usato regole per fare inferenze e per guidare il consultation process.

Due esempi di queste regole sono

Rule 3: “Barite overlying sulfides suggests the possible presence of massive sulfide deposit”

e

Rule 22:”Rocks with crystal-shaped cavities suggest the presence of sulfides”.

Le regole erano state codificate come “partitioned semantic networks” – un format originato da Gary Hendrix nella sua tesi di Ph.D. alla University of Texas per l’uso nel rappresentare conoscenza necessaria ai sistemi di NLP. Semantic networks erano anche usate per rappresentare la conoscenza tassonomica usata da PROSPECTOR. Le regole potrebbero essere linkate insieme in quella che è stata chiamata una “inference network”.

Si noti come la Rule 22 aiuta a stabilire una delle premesse per la Rule 3. Si noti anche che la tassonomia è usata per inferire la presenza di solfuri (sulfides) se galena, sphalerite o la chalcopyrite sono note per essere presenti.

Inferenze dalle premesse della regola (rule premises) alle conclusioni della regola (rule conclusions) nella rete (network) dipendevano dalle probabilità e dalla regole di Bayes – non su numeri ad hoc come fattori di certezza (“certainty factors”). Agli esperti geologi era chiesto di quantificare la loro incertezza circa una regola dando ai progettisti due numeri. Uno è il fattore per il quale le probabilità (odds) che favorivano la conclusione sarebbero state incrementate se le premesse erano vere. L’altro è il fatto con il quale le probabilità (odds) che favorivano la conclusione sarebbero state decrementate se le premesse erano false. La regola di Bayes era stata usata in associazione con quei numeri per derivare la probabilità della conclusione date le probabilità delle premises. I metodi di inferenza di PROSPECTOR, anche se essi erano un miglioramento rispetto a quelli di MYCIN, diedero probabilisticamente validi risultati solo per certi tipi di strutture di inference-net. Come Glenn Shafer e Judea Pearl spiegarono, “Le probabilità potrebbero non semplicemente marcare insieme numeri assegnati alle regole IF-THEN. I risultati di calcolo della probabilità sarebbero stati sensibili solo se questi calcoli avessero seguito i principi dalla probability theory.” I sistemi esperti moderni usano il più generale framework di reti bayesiane (Bayesian networks) che saranno descritte successivamente.

Il format usuale per un consulto di PROSPECTOR implicava una sessione con geologi interessati a valutare un certo sito. I geologi potrebbero offrire volontariamente qualche informazione, che avrebbe evocato alcune delle regole di PROSPECTOR. Il sistema poi calcolava quale informazione aggiuntiva sarebbe stata la più efficace nell’alterare la probabilità di qualunque essa fosse che il geologo voleva trovare. PROSPECTOR avrebbe poi posto una domanda per produrre quell’informazione (e la sua probabilità). Attraverso l’elaborazione, l’utente potrebbe offrire volontariamente informazione aggiuntiva in ogni momento.

Poiché PROSPECTOR potrebbe usare informazione offerta volontariamente, un giro del programma non necessitava di essere parte della sessione di consultazione question-and-answer. Invece, un utente potrebbe immettere un insieme completo di dati circa scoperte nel campo (“findings in the field”) in PROSPECTOR, il quale avrebbe poi dedotto le sue conclusioni. Queste scoperte potrebbero derivare da un database, o, forse più utilmente, da una mappa che indicava i contorni di regioni nelle quali vari tipi di minerali erano stati trovati per essere presenti.(Kurt Konolige dello SRI si unì al team di PROSPECTOR attorno a quel periodo e scrisse un programma che aveva consentito a PROSPECTOR di usare map data come un input).

Il più spettacolare esempio dell’uso di PROSPECTOR di map data è occorso quando esso ha identificato con successo la posizione di un deposito di porphyry molybdenum sul Mount Tolman nello stato di Washington. I risultati delle precedenti esplorazioni del sito di Mount Tolman furono usate per produrre mappe che delineano importanti dati geologici rilevanti per i potenziali depositi di molibdeno. PROSPECTOR ha elaborato queste mappe usando regole ottenute principalmente da Victor F. Hollister, un esperto su depositi di porphyry molybdenum e da Alan Campbell. Il risultato dell’elaborazione fu un’altra mappa che indicava la relativa vantaggiosità di un deposito minerario.

Da dati di questo tipo, PROSPECTOR ha prodotto mappe di vantaggiosità.

Si deve essere attenti nel valutare questo risultato. Esso non è il caso di PROSPECTOR che ha scoperto un deposito di minerale grezzo in un sito precedentemente inesplorato. Come è stato sottolineato in una lettere al curatore del journal Artificial Intelligence,

Una grande compagnia di miniere (mining) ha già trovato una massa di molibdeno grezzo trivellando più di 200 buchi di esplorazione in una sola regione…e noi sappiamo che essi intendono fare ulteriori trivellazioni per la loro propria informazione.

[Questa successiva trivellazione] ha mostrato una rimarchevole congruenza con la mappa di vantaggiosità di PROSPECTOR, includendo sia la verifica delle predizioni di PROSPECTOR di una ampia, precedentemente sconosciuta regione di mineralizzazione di grado grezzo e sia la verifica delle predizioni di PROSPECTOR per le aree aride ....

Sfortunatamente, le prolungate e depresse condizioni economiche nell’industria mineraria ha reso quest’area priva di profitto per miniere…Così, il successo di PROSPECTOR è stato scientifico piuttosto che economico.

Il codice di computer per PROSPECTOR era stato consegnato alla U.S. Geological Survey dove Richard B. McCammon ha sviluppato un sistema successivo che egli ha chiamato PROSPECTOR II. Riassumendo il suo sistema, McCammon scrisse^;

PROSPECTOR II , il successore di PROSPECTOR, fu sviluppato alla U.S. Geological Survey. Attualmente, la conoscenza base contiene 86 modelli di deposito e informazione su più di 140 depositi di minerali. In pochi minuti, il geologo può inserire i dati osservati per un’area, selezionare i tipi di modelli di deposito per essere valutati, ricevere consiglio su quei modelli che meglio combaciano con in dati osservati e, per un particolare modello, trovare quale dei dati possono essere spiegati e quale dei dati sono inspiegati, e quali attributi critici del modello non sono stati osservati nei dati.”

Sistemi Esperti

MYCIN

Il progetto HEURISTIC DENDRAL di Stanford ha dimostrato la potenza di dotare i computers con conoscenza esperta (expert knowledge) circa la chimica e la spettroscopia. Feigenbaum, Lederberg e Buchanan, i membri senior del progetto, hanno creduto che un approccio simile potrebbe funzionare su un problema medico. Nei primi anni settanta Buchanan iniziò a parlare con Stanley Cohen, Chief of Clinical Pharmacology alla Medical School di Stanford circa il sistema computerizzato sull’interazione dei farmaci chiamato MEDIPHOR. Attorno allo stesso periodo, Edward (Ted) Shortliffe, uno studente della Stanford Medical School, frequentò un corso a Stanford su AI e diventò anche un assistente del progetto di Cohen. Insieme, Shortliffe, Buchanan e Cohen hanno concepito l’idea di costruire un programma di computer che potrebbe consultarsi con medici circa infezioni batteriche e la terapia. Shortliffe ha chiamato il programma MYCIN, un comune suffisso per agenti antibatterici. Questo programma avrebbe necessità di contenere conoscenza di esperti sulla diagnosi e il trattamento in malattie infettive

La prima questione nello sviluppare MYCIN fu come rappresentare la conoscenza esperta. Shortliffe e Buchanan pensarono che qualcosa di simile alle “IF – THEN rules” usate in DENDRAL sarebbero state appropriate. Se si diagnostica quale malattia potrebbe essere la causa di certi sintomi, e anche nello prescrivere la terapia, i medici sembrano usare un tipo di ragionare IF-THEN: IF i sintomi sono questo-e-questo, THEN la causa è probabile essere così-e-così. La conoscenza dietro a questo tipo di ragionamento è basata sull’esperienza con casi nonché sulla conoscenza scientifica circa le malattie. Si è creduto che la conoscenza IF-THEN necessaria per il programma potrebbe essere ottenuta intervistando gli esperti medici appropriati i quali avevano già pensato in quei termini.

È interessante che, il ragionare IF-THEN riguardo le discipline mediche ha una lunga storia. Riassumendo parte di un libro di J.H. Breasted circa la conoscenza chirurgica contenuta in un antico papiro egizio, Robert H. Wilkins scrisse: “The Edwin Smith Surgical Papyrus, databile dal diciassettesimo secolo è uno dei più antichi di tutti i papiri medici conosciuti.” (Il papiro fu acquistato in un negozio di antiquariato a Luxor da Edwin Smith nel 1882). Wilkins continua a menzionare molte regole dal papiro, una delle quali è la seguente:

Terzo caso

Titolo: Istruzioni concernenti uno strappo in una vertebra del suo collo

Esame: Se tu esamini un uomo che ha uno strappo in una vertebra del suo collo, tu dovresti dirgli:”guarda le tue due spalle e il tuo petto.” Se egli fa così, è possibile vedere che per lui è doloroso.

Diagnosi: tu dovresti dire riguardo a lui: “Uno che ha uno strappo in una vertebra del suo collo. Una malattia che io potrei trattare.”

Trattamento: tu dovresti fasciarlo con carne fresca il primo giorno. Ora conseguentemente tu dovresti trattare con miele ogni giorno fino a che egli si ricovera.

Due altri esperti che si sono uniti allo sviluppo del nascente sistema diagnostico e terapeutico furono Thomas Merigan, Chief of the Infectious Disease Division a Stanford e Stanton Axline, un medico in questa divisione. Nel loro riepilogo della storia del progetto, Buchanan e Shortliffe attribuirono il merito ad Axline per aver dato il nome MYCIN al programma.

Il team sottopose un’applicazione rilasciata con successo al National Institutes of Health nell’ottobre del 1973. Shortliffe ha deciso di combinare i suoi studi medici con il lavoro rivolto ad un Ph.D. in Computer Science basato su MYCIN. Sin dalla versione di LISP che egli ha voluto usare (BBN-LISP, per diventare presto INTERLISP) non era disponibile a Stanford, egli ha usato il computer PDP-10 del gruppo di AI allo SRI.

Le regole IF-THEN dedotte ragionando dagli esperti medici usualmente erano coperte dai rischi con incertezza. Buchanan e Shortliffe raccontano che “Cohen e Axline hanno usato parole come ‘suggests’ o ‘lends credence to’ nel descrivere gli effetti di un insieme di osservazioni sulla conclusione corrispondente. È sembrato chiaro che noi avevamo necessità di gestire proposizioni probabilistiche nelle nostre regole…”

Dopo una disputa sui vari modi di usare le probabilità per qualificare le regole IF-THEN di MYCIN, Shortliffe infine decise di usare piuttosto la nozione ad hoc di fattori di certezza (“certainty factors”).

Ecco, per esempio, (sia la sua forma interna in LISP sia la traduzione in inglese) una delle regole di MYCIN:

RULES036

PREMISE: ($AND (SAME CNTXT GRAM GRAMNEG)

(SAME CNTXTM MORPH ROD)

(SAME CNTXT AIR ANAEROBIC))

ACTION: (CONCLUDE CNTXT IDENTITY BACTEROIDES TALLY 0.6)

IF: 1) The gram stain of the organism is gramneg, and

1. The morphology of the organism is rod, and
2. The aerobicity of the organism is anaerobic

THEN: There is suggestive evidence (0.6) that the identity of the organism is bacteroides

Lo 0.6 in questa regola è significativo per misurare il grado di credenza (“degree of belief”) dell’esperto (in) o certezza (“certainty”) circa la conclusione. Shortliffe pensò che un grado di credenza (belief) non era lo stesso come una valutazione (assessment) di probabilità perché, tra le altre cose, egli ha notato che gli esperti che avevano fornito Rule 036 non necessariamente pensano che la probabilità dell’organismo not essere batterioide dovrebbe essere 0.4. Il sistema originario MYCIN aveva 200 di queste regole. Dal 1978, egli ne ha al più 500.

Le regole di MYCIN erano usualmente evocate in un modo di backwarding-reasoning. Per esempio, una regole della forma “IF x1 and x2, THEN y” sarebbe stata usata se il goal complessivo del sistema era di concludere y. L’uso di questa regola avrebbe condotto all’uso di regole le cui parti “THEN” erano o x1 o x2. Alla fine della catena di regole, un medico utente del sistema (o un database) avrebbe chiesto di fornire informazione circa la parte “IF”. Così, se MYCIN stava provando a stabilire che l’identità di un organismo era batterioide, la RULE 036 sarebbe stata usata e il medico (o il database) avrebbe chiesto se la colorazione di Gram (gram stain) dell’organismo è gram-negativo e ….

MYCIN era stato configurato come un “consulting system”. Cioè, esso ha interagito con un medico utente che ha fornito informazione circa uno specifico paziente. L’uso di regole e il concatenamento di regole (rule-chaining) hanno consentito al sistema di fornire “explanations” per il suo ragionare. Per esempio, dopo una query all’utente evocato dalla Rule 036, se l’utente ha chiesto “Why did you ask whether the morphology of the organism is rod” il sistema avrebbe replicato (in inglese) qualcosa come “because I am trying to determine whether the identity of the organism is bacteroides.”

Così, come ha fatto MYCIN al suo compito primario di raccomandare la terapia? Shortliffe e colleghi hanno condotto molte valutazioni le quali erano chieste ai medici per comparare le raccomandazioni di MYCIN con le loro proprie per molti pazienti. La loro maggiore conclusione era che “il settanta percento delle terapie di MYCIN erano soppesate come accettabili dalla maggioranza dei valutatori”. Essi hanno anche notato inoltre che “il 75% è infatti migliore rispetto al grado di accettazione che potrebbe generalmente essere realizzato dalla facoltà di Stanford di essere stimato sotto gli stessi criteri.”

Una delle innovazioni di MYCIN [confrontata con DENDRAL, diciamo] era che il suo processo di ragionamento (usando le regole) era assolutamente separato dalla sua conoscenza medica (le regole stesse). Così, divenne comune dividere il programma in due parti, cioè, l’“inference engine” per applicare le regole e la “knowledge base” delle regole. Teoricamente, nuove regole potrebbero essere aggiunte senza dover cambiare l’inference engine. Questa separazione suggerisce che si potrebbero costruire expert systems per altre applicazioni semplicemente rimpiazzando la conoscenza medica con altre conoscenze di base senza dover cambiare l’inference engine. William van Melle ha implementato un sistema chiamato EMYCIN (“E” sta per “empty”) per fare proprio ciò. Un progettista di sistemi insieme ad esperti in un determinato campo, X, potrebbero interagire con EMYCIN per produrre regole IF-THEN per il campo X. Usando il suo incorporato inference engine, EMYCIN potrebbe allora usare queste regole per fornire un consiglio ad un utente del sistema durante un consulto. EMYCIN fu usato per costruire molti expert systems differenti in campi così diversi come planning e analisi strutturale meccanica (mechanical structural analysis).

I ricercatori subito scoprirono che una minore variazione dei fattori di certezza (certainty factors) usata da MYCIN e da EMYCIN era equivalente all’usare probabilità invece. Questo collegamento alla probability theory ha implicato conseguenze che né MYCIN né EMYCIN potrebbero evitare. In particolare, il loro ragionare era consistente con la teoria della probabilità solo sotto alcune piuttosto restrittive ipotesi circa come le regole sarebbero state usate. Come Russell e Norvig sottolineano, se queste ipotesi non sono soddisfatte “fattori di certezza (certainty factors) potrebbero funzionare disastrosamente in non corretti gradi di credenza attraverso la sovrastima di evidenza. Quando gli insiemi di regole diventano più ampi, indesiderabili interazioni tra regole diventano più comuni, e i professionisti hanno trovato che fattori di certezza di molte altre regole devono essere modificati (‘tweaked’) se più regole erano state aggiunte”. I metodi moderni usano tecniche probabilistiche più sofisticate, come vedremo in un successivo post.

Anche così, il successo di MYCIN e i vari programmi EMYCIN condussero allo sviluppo di molti più sistemi esperti, alcuni basati su EMYCIN e alcuni usando i loro propri specifici approcci. Come Allen Newell scrisse nella sua introduzione ad un libro di Buchanan e Shortliffe, “MYCIN è il sistema esperto originario che ha reso evidente a tutto il resto del mondo che una nuova nicchia era stata aperta…MYCIN compendiava il nuovo percorso che era stato creato. Così, il raccogliere insieme il record pieno di questo sistema e la storia interna del suo sviluppo serve a registrare un importante evento nella storia di AI”

Consulting Systems

The SRI Computer-Based Consultant

Così narra il Professor Nils J. Nilsson:

“Mentre i miei colleghi ed io allo SRI riflettevamo sui modi per continuare la nostra ricerca sul planning e la vision, noi stavamo per realizzare il progetto “Shakey the Robot”. Finché soddisfacevamo l’interesse della DARPA in applicazioni di rilevante interesse militare, noi potevamo pensare al problema di manutenzione, riparazione e formazione dell’attrezzatura. Inoltre abbiamo sottolineato che ogni tecnologia che potrebbe ridurre le spese per questi elementi e diminuire il necessario per utilizzare esigue risorse umane esperte sarebbe stato estremamente importante per le forze armate. Inoltre, noi abbiamo detto, che questa necessità “non può essere soddisfatta meramente scrivendo di più e meglio manuali. Un sistema informatico sofisticato ci sembra essenziale.”

Noi abbiamo proposto di iniziare il lavoro su questo problema sviluppando un ambiente nel quale ad un apprendista umano dovrebbe essere dato un consiglio circa come smontare e riassemblare un compressore ad aria. Il consiglio dovrebbe essere generato (come necessario, dall’apprendista) da un sistema di pianificazione (planning) e di esecuzione che avrebbe dato suggerimenti circa ciò che doveva fare successivamente. L’apprendista potrebbe chiedere per un consiglio, usare un predefinito ridotto vocabolario, che il sistema dovrebbe analizzare con l’attrezzatura allo stato dell’arte del riconoscimento del parlato (speech recognition) e poi il sistema avrebbe risposto, usando un modulo di generazione del parlato (speech generation). Il sistema avrebbe anche impiegato un sistema machine-vision per aiutare a tenere traccia del progredire e per osservare componenti indicati dall’apprendista.

Sebbene il progetto non durò abbastanza a lungo per realizzare tutti i suoi goals, una prima versione di un sistema “Computer-Based Consultant” (CBC) fu mostrata pubblicamente nella quale all’apprendista [impersonato da Georgia Sutherland, una dei membri del team del progetto] era chiesto di riassemblare un compressore ad aria (un compressore Sears Model 17209, 1/2 HP) che era stato precedentemente parzialmente smontato. Le richieste (requests) e le risposte (responses) sia dal sistema sia dall’apprendista erano parlate. Ecco un campione di una delle interazioni con il sistema (con i miei commenti tra parentesi):

System. Please assemble air compressor

Apprendice: How?

(L’apprendista chiede un consiglio e il sistema, usando il sistema NOAH di Sacerdoti che ho descritto precedentemente, crea un piano gerarchico di assemblaggio)

S: Install pump

(Il sistema menziona la prima azione nel piano di alto livello creato da NOAH.)

25

A. OK

(L’ apprendista sa come installare la pompa e indica che non ha più necessità di consigli riguardo come farlo. In questa fase del progetto CBC, il sistema ipotizzava, senza verifica visiva che l’apprendista aveva completato il suo primo step.)

S: Install pump brace

(Il sistema menziona la seconda azione nel piano di alto livello)

A: How?

(L’apprendista non sa come realizzare questo step e chiede consiglio)

S: Connect pump brace to pump

(Il sistema menziona il primo di passi più dettagliati nell’azione di alto livello per installare il supporto della pompa)

A: OK

(L’apprendista sa come realizzare questo step.)

S: Connect pump brace to belt-housing frame.

(Il sistema menziona il successivo dei passi più dettagliati nell’azione di alto-livello per installare il supporto della pompa.)

Questo tipo di interazione continua finché il compito è completato.

Il sistema manteneva traccia dello stato corrente di assemblaggio usando la rete procedurale (procedural net) creata dal sistema NOAH. Se all’apprendista era stato chiesto “Why?” ad ogni step, il sistema avrebbe usato la rete procedurale per costruire una risposta. La risposta potrebbe essere stata qualcosa come “you must do x because it is one of the actions involved in doing y”, oppure “you must do x because you must do it first in order to do the next action, z” Inoltre all’apprendista potrebbe essere chiesto aiuto nel localizzare una delle parti più grandi del compressore ad aria e il sistema avrebbe usato il suo puntatore laser per mostrarlo ad lei.

Il progetto CBC ha anche fornito un’opportunità per il gruppo di NLP dello SRI per provare alcune idee che stavano sviluppando circa il generare e capire le frasi usate nelle conversazioni. Nel progetto CBC, l’apprendista e la persona che dà consiglio sono i partecipanti in un dialogo sul compito, cioè, il compito di lavorare su un compressore ad aria. La struttura del compito, come modellato dalla rete procedurale generata da NOAH, ha fornito un’importante informazione pragmatica utile per capire la frase. Questa informazione era sfruttata in un sistema chiamato TDUS (un acronimo per Task Dialog Understanding System) che potrebbe coinvolgere in dialoghi più complicati rispetto a quello parlato appena illustrato come esso ha guidato un’apprendista attraverso un compito di assemblaggio (assembly task). TDUS ha integrato il planning system NOAH con un sistema di comprensione del linguaggio naturale (natural language understanding system) (avente componenti sintattiche, semantiche e pragmatiche) per consentire conversazioni basate su un testo (text-based) con l’apprendista.

Io userò un esempio preso da un articolo circa TDUS per illustrare il ruolo che la struttura del compito gioca nel capire una frase. Si considerino le seguenti frasi:

Speaker 1: Why did John take the pump apart?

Speaker 2: He did it to fix it

L’interpretare i referenti delle parole in italico nella seconda frase è aiutato dal riferire al contesto del compito stabilito dalla prima frase. “He” si riferisce a John, “did it” si riferisce al compito di disassemblare e il secondo “it” si riferisce alla pompa. TDUS rende estensivo l’uso del contesto del movimento (shifting “context”) e i goals del dialogo. Come gli sviluppatori di TDUS scrissero,

Quando un dialogo progredisce, i partecipanti continuamente spostano (shift) il loro focus di attenzione e così formano un contesto che si evolve sullo sfondo di quelle espressioni che rispetto al quale delle espressioni sono prodotte e interpretate. Uno speaker fornisce ad un ascoltatore con idee-guida di quello che guarda e come lo guarda – quello su cui deve focalizzarsi, come deve focalizzarsi su di esso e quanto largo o stretto il focalizzarsi dovrebbe essere. Noi abbiamo sviluppato una rappresentazione per focalizzare il discorso, procedure per usarlo nell’identificare oggetti riferiti a noun phrase e procedure per rilevare e rappresentare gli spostamenti nel focalizzare

[Le parole espressione (“utterance”), parlante (“speaker”) e ascoltatore (“hearer”) non devono essere prese letteralmente. TDUS elaborava un linguaggio basato su testo scritto (text-based), non linguaggio parlato. Nella ricerca NLP, queste parole sono spesso usate in un senso generalizzato per riferirsi a frasi, generatori di frase e ricevitori di frase, qualunque sia il medium.]

Il focus era il principale interesse di Barbara J. Grosz che ha continuato il lavoro su questo argomento e il suo ruolo in NLP come professoressa alla Harvard University. Oltre i meccanismi per trattare contesti, goals e focus, TDUS conteneva una grammatica, chiamata DIAGRAM, per riconoscere molte delle strutture sintattiche dell’inglese, i significati (means) per rappresentare e ragionare circa elaborazioni e goals e un struttura (framework) per descrivere come differenti tipi di conoscenza interagiscono quando il dialogo si dispiega.

Una dimostrazione pubblica del sistema CBC, come quello che ho descritto fu data allo SRI il 23 aprile del 1975, per J.C.R. Licklider [che era ritornato a capo dell’IPTO nel 1973]. Ricordando le impressione della sua visita, Licklider successivamente ha affermato

La seconda volta che io fui alla DARPA, c’erano sistemi di AI molto convincenti che trattavano la manutenzione dell’attrezzatura. Io ricordo che lo SRI aveva un programma che ha descritto come smontare una pompa e rimetterla insieme. Non è questo un dispositivo terribilmente complicato, ma era molto convincente vedere un computer che ovviamente ha capito (understood) tutte le parti della pompa e come esse hanno funzionato insieme.

Grazie all’incoraggiamento di Licklider, noi eravamo ottimisti circa il continuare il progetto del CBC e fare piani per un sistema che avrebbe identificato (diagnose) e dato consigli circa il riparare il motore di una jeep militare. Sfortunatamente, uno dei managers del nuovo programma della DARPA IPTO, il colonnello David Russell, non era d’accordo per acquistarlo. Dopo aver visitato SRI un po’ di giorni prima della visita del 23 aprile di Licklider, Russell inviò una e-mail a Licklider dicendo.⁸

Devo ammettere che è considerevole preoccuparsi del programma dello SRI, particolarmente alla luce delle pressioni del management sul programma AI. Guardando il piano del programma progettato su cui Nils stava lavorando, io vedo un programma di 2.2M di dollari sui successivi tre anni con lo scopo di sviluppare uno sperimentale CBC per una jeep…Io non posso vedere come esso può essere difeso come una a breve termine applicazione…

Mentre potrebbe essere difficile, io vorrei suggerire che voi diate un serio pensiero per terminare il programma CBC se esso completa la fase del compressore ad aria e ridirigere lo SRI ad applicazioni più orientate alla Defense o passare il loro lavoro alla NSF. Io riconosco che questa è eresia, ma questo è come io vedo la situazione.

Io non ho discusso direttamente questi commenti con Nils sebbene gli abbia chiesto cosa egli volesse fare se il programma sarebbe stato terminato. Io potrei avere creato un punto di vista negativo basato su una non corretta comprensione del programma e non ho voluto turbare il gruppo di SRI senza i vostri punti di vista sul programma.

Dopo quell’anno, Russell ha sostituito Licklider come Direttore del DARPA IPTO ed ha terminato il progetto CBC. (il lavoro di ricerca su TDUS, tuttavia, è continuato sotto il supporto della NSF.) Il supporto dalla DARPA per il gruppo dello SRI fu susseguentemente reindirizzato (“redirected”) alle interfacce in Natural Language ai databases e per “image understanding” per aiutare gli interpreti della foto. Alcuni di noi hanno scelto invece di cercare il supporto di non-DARPA per lavorare su sistemi di consulenza basati sul computer (computer-based consulting systems). Il lavoro in corso alla Stanford University sui così chiamati expert systems ci hanno incoraggiato in questa direzione.”