Forord. Steffen Estrup Nielsen

Transkript

1

2 Forord Denne rapport er udarbejdet i forbindelse med kurset Verbal interaktion i multimodal kontekst på Informatik 6. semester forår Resultatet af denne rapport har været en Information Extraction applikation, der kan trække information ud af vejrudsigter. Kildekoden til applikationen kan findes på denne lokation: Desuden er dokumentationen til koden også tilgængelig, om end den ikke er gennemarbejdet. Desuden kan hele rapporten i pdf-format og vores datamateriale også findes på ovenstående website. Anders Carlsen Peter Siu Hung Cheng Steffen Estrup Nielsen 1

3 Indholdsfortegnelse INDLEDNING 3 VEJRUDSIGTERNE 3 RAPPORTSTRUKTUR 4 TEORI 6 GRISHMAN S IE SYSTEM STRUCTURE 6 EVALUERINGSMETODE 7 ANALYSE 9 FORANALYSE 9 ANALYSEN 10 FINITE STATE AUTOMATA 14 BESVARELSE AF SPØRGSMÅL 16 IMPLEMENTERING 17 LEKSIKONET 18 PATTERN MATCHING 19 KONTEKSTRESOLUTION. 21 REGNER DET SÅ I MORGEN? 21 EVALUERING 23 OPSAMLING 26 LITTERATURLISTE 28 2

4 Indledning I dette projekt vil vi beskrive og delvist implementere et Information Extraction (IE) system. Dette system vil kunne hente data ud fra en vejrudsigt skrevet i naturligt sprog, og delvis kategorisere disse data, så brugeren kan stille simple tekstbaserede spørgsmål og få korrekte svar retur. Indenfor systemer, der opererer med det skrevne naturlige sprog findes foruden IE systemer også text understanding systemer. Forskellen mellem disse to typer af systemer er netop i, hvor vægten lægges i teksten. For et IE system er det kun fragmenter af en tekst, der er interessant at se på for eksempelvis at komme frem til et svar på et spørgsmål, hvor der derimod i et text understanding system fokuseres på at kunne opnå en mening ud fra teksten. (Appelt, 1993). Et system, der returnerer ønskede informationer fra en større mængde tekster, kunne tænkes at blive anvendt i mange forskellige sammenhænge. Et eksempel kunne være finansielle nyheder om firmaregnskaber, skrevet i naturligt sprog på websites eller lignende. Måske ville en virksomhed gerne have disse data kategoriseret automatisk, således de kunne få en liste med de mest essentielle data i disse regnskaber, såsom over/under-skud, omsætning, etcetera. Udbredelsen af IE er dog stadig relativt begrænset, og det skyldes nok til dels de problemer, der er forbundet med at implementere systemer, som en har en lav fejlsekvens. I vores tilfælde drejer det om at få specifikke oplysninger hevet ud af en længere tekst, hvor denne tekst ikke er opbygget på en forudsigelig måde. Dette er et meget kompliceret problem, og der vil, lige meget hvor godt ens system er udarbejdet, altid kunne forekomme sætningskonstruktioner, som ens system ikke ville kunne processere på den ønskede måde. Derudover er der den problemstilling, at et system der tunes til at analysere netop én type tekst, ikke umiddelbart vil kunne overføres til andre typer tekster. Denne og andre problemstillinger vil vi diskutere løbende i rapporten. Vejrudsigterne Vores specifikke system skal gerne kunne give os et svar på, hvordan vejret bliver i den australske delstat New South Wales. Vi har indsamlet 60 vejrudsigter for området i løbet af de sidste par måneder, hvoraf de første 45 skal bruges til at 3

5 til både at tune vores system. De sidste 15 vejrudsigter skal benyttes til en recall og en precision test af den færdige implementering. Vejrudsigterne er skrevet på engelsk, opdateres dagligt og beskriver udover vejret den pågældende dag også vejret en to-tre dage frem. Brugeren skal kunne stille spørgsmål, såsom: Will it rain tomorrow?, og få et relevant svar (), som f.eks.: Yes, there will be scattered showers tomorrow!. Systemet skal altså kunne finde ud af, om det regner og hvor det regner, og om det i så fald regner det sted, hvor brugeren befinder sig. I vores implementering vil vi ikke bruge voice, så disse spørgsmål skrives eller vælges fra en i forvejen defineret liste. Grunden hertil er, at vi mener fokuset for et IE projekt er at trække information ud af en tekst, og ikke nødvendigvis at kunne præsentere denne information gennem et stemmekontrolleret interface. Kommer det mon til at regne i morgen? Webserver WWW Vejrudsigter PC med IE system Figur 1 Rigt billede af IE systemet Rapportstruktur Rapporten vil indeholde følgende elementer efterfulgt af en konklusion/perspektivering: Teori Analyse Implementering Evaluering 4

6 I teoridelen vil vi beskrive den anvendte teori, taget fra Daniel Jurafsky & James H. Martins bog Speech and Language Processing og Ralph Grishmans artikel Information Extraction: Techniques and Challenges. I analysen vil vi med udgangs punkt i datamateriale analysere os frem til, hvordan de grundlæggende elementer i vores system skal virke for at trække de relevante informationer ud af dataene. I implementeringsdelen vil vi mere konkret beskrive, hvordan systemet er blevet implementeret i Java. Til sidst vil vi evaluere på det udarbejdede system. Her vil vi altså teste systemet på vores testmateriale for at måle dets effektivitet. Her vil vi også forsøge at forklare resultaterne. 5

7 Teori Vi vil i dette projekt tage udgangspunkt i Grishman Information Extraction model (Figur 2) fra artiklen Information Extraction: Techniques and Challenges af Ralph Grishman. Til evaluering af vores IE-system ønsker vi at gøre brug af evalueringsmetoden, som findes i Daniel Jurafsky & James H. Martins bog Speech and Language Processing på side 578. Grishman s IE system structure Modellen består af seks faser, hvor de første fire faser vedrører en lokal tekst analyse og de to sidste en diskurs analyse. Med andre ord betyder det, at indholdet af en tekst analyseres både som teksten selv og i forhold til dens kontekst. Hvordan dette gøre vil vi beskrive nærmere under beskrivelserne af de enkelte fase. Modellen viser, at der som input er et dokument (tekst), at de seks faser derefter gennemløbes, og man ender til sidst med en eller flere templates. Document Local text analysis Lexical analysis Name recognition Partial syntatactic Scenario pattern Discourse analysis Corererence analysis Lexical analysis: I denne fase inddeles teksten i sætninger eller tokens inference (delsætninger eller flere ord der tilsammen har fremkalder en betydning). Template generation Disse sætninger eller tokens bliver herefter sammenlignet med et allerede Extracted templates udarbejdet leksikon, så man derved kan definere sætningernes og tokens Figur 2 Grishman's struktur for et IE system funktioner i teksten. Et eksempel er Grishman, som bliver kategoriseret under kategorien personnavne. Name recognition: Her skal man tage højde for, at både personnavne og stednavne, såsom virksomhedsnavne, byer og lande, skrives på forskellig måde i en tekst. Navnet Ralph Grishman kan eksempelvis i en tekst også noteres som 6

8 Mr. Grishman. USA kan også skrives som U.S.A. og som United States of America. Virksomheden Hewlett-Packard Corp. bliver ofte noteret som HP. Disse forskellige skrivemåder, eller aliaser, skal identificeres som tilhørende den samme entitet. Partial syntactic analysis: Man ser her på tekstens syntaktiske opbygning, hvilket kan gavne den senere extraction af information. Ordene i teksten bliver inddelt i kategorier, såsom navneord, udsagnsord og tillægsord, hvilke danner forskellige syntaktiske mønstre. Scenario pattern matching: Det er her man ser på de mønstre der kan bruges til at udvinde den ønskede information. Dette er scenariospecifikt, så hvis man vil have informationer om hvorvidt det regner, skal man se på de mønstre, som indeholder elementer af den ønskede type, som f.eks. raintype. Coreference analysis: Under dette punkt arbejdes der eksempelvis med personlige stedord. Man ser ofte i tekster, at en person første gang bliver nævnt ved navn, og man derefter benævner vedkommende med et personligt stedord. For eksempel Ralph Grishman igen, hvor man derefter bruger ordet han. Udover personlige stedord kan der være den bestemte artikel, som refererer tilbage til noget, der er nævnt før. En virksomhed der første gang bliver nævnt med navnet og derefter bliver benævnt som virksomheden (the company) kan være et eksempel på den bestemte artikel. Inference: Fokuset i denne fase er at se, om teksten indeholder nogle logiske slutninger, forstået på den måde, at man ud fra en sætning kan udlede en anden information. I artiklen bruger Grishman følgende eksempel: Sam was president. He was succeeded by Harry. Ud fra denne sætning kan man udlede at Harry er præsident. Yderligere er tidsaspektet ifølge Grishman også noget, som man vil kigge på under denne fase. Tidsaspektet i en tekst har ofte den karakteristik, at den ikke er bestemt. For eksempel ved udtryk som: tidligt om morgenen, senere på dagen, hen på eftermiddagen og om aftenen. Grunden til at tidsaspektet bliver håndteret i denne fase er, at tidsaspektet interagerer med instanser fra diskursen. Evalueringsmetode Til at evaluere vores system ønsker vi at gøre brug af de to begreber recall og precision (Jurafsky, 2000, 578). Recall: er den betegnelse for hvor meget relevant information, der er blevet hentet ud af systemet. Dette gøres ved: antallet af korrekte svar givet af systemet 7

9 totale antal af mulige korrekte svar i teksten Precision: er betegnelsen for hvor stor en mængde af den information, som systemet leverer tilbage, er korrekt. antallet af korrekte svar givet af systemet antallet af svar givet af systemet 8

10 Analyse I dette afsnit vil vi først starte med at foretage en foranalyse af sproget, der bliver anvendt i vejrudsigter. Derefter vil vi redegøre for udarbejdelsen af vores system, jævnfør Grishmans model i teoriafsnittet. Foranalyse Teksterne som vi skal trække informationer ud fra, er som sagt vejrudsigter på engelsk fra Ser man logisk på sproget, der bliver anvendt indenfor vejrudsigter, formoder vi, at der ikke vil forekomme så stort et ordforråd, som der eksempelvis ville være i almindelige nyheder. I Tabel 1 ser en oversigt over antallet af fundne unigrams og unikke unigrams ved 1, 5, 10, 20, 30 og 60 vejrudsigter. Ud fra tallene kan vi se, at det forholder sig sådan, at antallet af unikke 1-grams stiger kraftigt fra 1-5 vejrudsigter. Ser man derimod på forskellen mellem 5 og 10 vejrudsigter er stigningen næsten halveret. Der er altså tydelig tegn på at stigningen af antallet af nye ord flader ud med antallet af fundne ord. Et histogram over unigrams i henholdsvis 10 og 60 vejrudsigter ses i Figur 3 og Figur 4. Antal vejrudsigter Antal fundne unigrams Antal unikke unigrams Tabel 1 Fundne unigrams og unikke unigrams ved 1, 5, 10, 20, 30 og 60 vejrudsigter Sproget der bliver brugt indenfor denne type tekster kan siges at bruge forholdsvis få forskellige ord. Hvis vi ser i tabellen, forekommer der kun 434 unikke ord, uden der er foretaget nogen form for stemming på ordene, det vil sige at f.eks. move og moves ikke bliver kategoriseret som det samme ord. Hvis lignende ord af lignende karakter var blevet kategoriseret som det samme ord ville der være endnu færre forskellige ord. Men set på den anden side vil der heller ikke forekomme alt for mange af det føromtalte ord. Der vil eksempelvis ikke, hvis vi ser på tidsformerne af udsagnsordene, være nogle ord, der 9

11 forekommer i datid, da det ikke passer ind i vejrudsigter, som beskriver enten dagens eller de kommende dages vejr. Figur 4 Unigrams ved 10 vejrudsigter Figur 3 Unigrams ved 60 vejrudsigter I og med, der anvendes få unikke ord i denne type tekster, gør, at det bliver lettere at lave et IE system for disse, da der derved også bliver færre sætningskonstruktionsmuligheder, og at der skal kategoriseres forholdsvis få ord. Udover, at der er færre unikke ord, men også som førnævnt, at det ikke er alle tidsformer, der vil forekomme i teksterne, reducerer det anvendte sprogs kompleksitet yderligere. Desuden mener vi, at ejefaldsord heller ikke vil forekomme i denne type tekster. Et meget afgrænset sprog som dette medfører desuden færre mønstre, som gør at der er mulighed for at opnå en lav fejlprocent. Disse er kun nogle af begrænsningerne i sproget, der er indenfor denne type tekster. Uden at beskæftige os med full parsing, vil vi påstå at det vil være lettere at foretage en full parsing af vejrudsigter frem for andre mere komplicerede tekster. Analysen Som beskrevet i indledningen, er vores domæne weather reports og scenariet er weather in New South Wales (NSW). Det er muligt at få en hel del oplysninger ud af disse vejrudsigter, som for eksempel data om nedbør, nedbørstype, vind, temperaturer (koldt/varmt), højtryk/lavtryk og information om, hvordan vejret specifikt er i de forskellige egne af NSW og derudover står der også vejret for efterfølgende dage. At kunne udvinde alle disse typer information, og skabe en template på baggrund deraf, er dog uden for vores rækkevidde. I stedet vil vi i vores system fokusere på nedbør og nedbørstype. 10

12 Vi vil altså undersøge vejrudsigternes sætningskonstruktioner nærmere for at kunne opstille en template, som det er muligt for os at udfylde. Vi vil også her komme ind på første del af Grishmans IE model, den leksikalske analyse, da vi her vil begynde at diskutere hvilke ordklasser, der eksisterer i teksten. Samtidigt vil vi også se på mønstre (patterns) i sætningerne, som vi på kan opstille regler på baggrund af, og vi så derefter kan bruge i vores IE system. Vi vil i det følgende hovedsageligt diskutere sætninger, der har med nedbørsfænomenet at gøre. Sætninger, der ikke har med nedbørsfænomenet at gøre, vil vores system ignorere, da de ikke bibringer information, der kan bruges til at udfylde vores templates.... with isolated showers developing along the southern coast behind the change. (29 marts) Ovenstående sætning er taget fra en af vores vejrudsigter. For det første har vi substantivet showers, der viser os, at udsagnet har med nedbør at gøre, for det andet har vi adjektivet, isolated, der modererer substantivet. Der er altså ikke tale om f.eks. udbredte, kraftige eller lette byger. Her er der tale om to ordtyper, der er vigtige for os, når vi skal trække de relevante informationer ud af teksten. Navneordsfrasen the southern coast i bestemt artikel giver os en stedsangivelse for nedbøren. Umiddelbart er denne navneordsfrase ubestemt, det vil sige, at den fortæller i forhold til hvad denne sydlige kyst ligger. Vi ved dog, at vejrudsigten er for NSW, og at der derfor må være tale om den sydlige del af NSW s kyst. Verbet developing fortæller os, at regnbygerne udvikler sig langs kysten bag the change (fronten eller opklaringen). Disse informationer mener vi ikke vi kan bruge, da informationen er for relativ. Det vil sige, at vi ikke kan sige præcis, hvornår og hvor disse byger kommer. Vi kan kun identificere, at der eksisterer en tidsvariabel i udsagnet. Udfra denne ytring kan vi altså trække følgende information ud: <RainTypeModerator> <RainType> <Anyword>* <LocationPhrase> Tager vi endnu et eksempel, ser vi, at ovenstående struktur grundlæggende også er gældende her: with the chance of some light patchy rain later in the far southwest corner. (30.marts) 11

13 Til forskel fra det tidligere eksempel, er der her to RainTypeModerators. Tidsvariablen er igen ubestemt. Teksten giver ikke umiddelbart nogen hints til i forhold til hvornår dette later refererer. Selv vi mennesker, med vores noget mere avancerede kontekstforståelse, kan ikke sige præcis hvornår på dagen later referer. Derfor vil det heller ikke være muligt i systemet at programmere en kontekstresolutions algoritme til dette tilfælde. Vi kunne vælge at tage et tids felt med i vores template og fylde feltet med later (in the day), men dette vil vi dog udelade, da vi ikke kan ræsonnere os frem til en mere præcis definition. I det to ovenstående eksempler er der kun tale om en enkelt lokation. Der kan dog godt forekomme flere lokationer: Isolated showers along the central and north coast. (7.april) Her er der både tale om the central coast og the north coast som lokationer for regnen. Vi er derfor også nødt til at sætte regler op for dette. Hvordan kan vi vide, at central referer til coast? Vi ved, at når der kommer et the, kommer der et ord eller en frase i bestemt artikel. Ved at kategorisere central og north som retninger og coast som en lokation, kan vi sige, at hvis der efter the kommer en retning eller en lokation, er vi stadig i samme navneordsfrase. Hvis der kommer et konjunktiv (f.eks. og ), må vi undersøge, om ordene efter konjunktiv er af henholdsvis typen retning og lokation eller bare retning, hvis ikke, er det ikke en del af samme navneordsfrase. Vi vil uddybe selve implementeringen af dette senere. I følgende eksempel bliver lokationsproblematikken udvidet yderligere: Patchy light rain from a band of middle-level cloud is expected to spread east across the southern and western parts of NSW and clear during the day (31. marts) Her skal der også tages højde for præpositionen of efterfulgt af et substantiv, NSW. Her er altså et forhold mellem retningerne før og substantivet efter præpositionen. Vi har i det forgående vist den generelle ordstilling, med regntype, efterfulgt af lokation. Det omvendte kan dog også være tilfældet som det ses i nedenstående eksempel: 12

14 A cooler southerly change is expected to move up the southern and central coasts, bringing isolated showers. (11. april) I det ovenstående har vi en navnefrase i ubestemt form cooler southerly change, der vedrører en navnefrase i bestemt form the southern and central coasts, og medfører vha. verbet bringing, navneordfrasen isolated showers. Altså et fænomen (a change), der vedrører en lokation (coast) og medfører et nyt fænomen (showers). Ovenstående eksempel er dog forholdsvis isoleret. Som tidligere nævnt, er der i vores vejrudsigt tale om vejrudsigter for den nuværende og de kommende to til tre dage. Derfor er det også nødvendigt at præcisere, for hvilken dag regnvejret gælder. Heldigvis er vejrudsigterne rimeligt struktureret sat op, hvad dette angår. Hver ny dag starter med ytringen on <weekday>, hvor weekday er ugedagens navn. De efterfølgende udsagn er derfor knyttet til denne dag, indtil vi støder på endnu en on <weekday> i teksten. Ud fra ovenstående analyse er vi kommet frem til en template med felter, vi kan udfylde med information omkring nedbør. Templaten er vist i Figur 5. Templaten vil indeholde information om hvilken art af nedbør, der er tale om (byger, regn, sne etc.). Endvidere vil den indeholde information om nedbørens intensitet (kraftig, let, spredt etc.), samt steds og tidsangivelse (dag) for Dag Nedbør Nedbørstype Lokation <hvornår> <nedbørsart> <type af <stedangivelse> nedbøren. Figur 5 Template for den information vi udvinder fra vejrudsigten Det er i denne sammenhæng vigtigt at notere, at målet for vores system ikke som sådan er at returnere alle udvundne informationer til brugeren. Systemet behandler input teksten (altså en vejrudsigt), og skaber en række templates. Brugeren kan så spørge systemet om det regner det sted denne befinder sig (defineret af os), og systemet søger så i de genererede templates efter svaret. Der 13

15 ville ikke være noget i vejen for, at brugeren bliver præsenteret for al den udvundne data, i form af en række templates (hvilket vi naturligvis også gør i vores eksempel applikation). Ud over bare at udfylde templates for alle regnefænomenerne i vejrudsigten vil vi også gerne på baggrund af disse templates besvare spørgsmål som f.eks. Vil det regne på sydkysten i morgen?. For at svare på dette spørgsmål, må vi se nærmere på selve lokationsfrasen. Vi er nødt til i den algoritme, der stiller dette spørgsmål, at opstille regler for hvilke regioner, der er associeret med f.eks. sydkysten. Hvis lokation er defineret som kun the coast eller the south må det inkludere vores lokation også, mens hvis lokationen er the northern coast eller the south west er vores ekskluderet. Det optimale ville være, hvis brugeren kunne spørge efter vejret et vilkårligt sted i NSW, men det har vi dog ikke planer om at implementere, da vi i så fald skulle tage højde for alle mulige lokationer indbyrdes associationer. Endvidere genereres der ingen templates for de lokationer, hvor der ikke er nedbør den pågældende dag. Systemet vil så returnere det svar, at der ingen nedbør er i det pågældende område, baseret alene på det faktum, at det ikke har kunnet finde informationer om det modsatte. Systemet vil altså ignorere tekst som angiver, at der bliver klar himmel i et pågældende område. Dette skyldes ikke kun det faktum, at det vil være lettere at udarbejde dette system, men også at de vejrudsigter, vi har indsamlet til at tune vores system med, kun sjældent nævner, at der ikke er nedbør i et givent område. Finite State Automata På baggrund af den ovenstående forundersøgelse vil vi her opstille en Finite State Automata (FSA) for den grammatik, der kan udfylde vores template. FSA en bygger alene på den generelle form udsagnene med regn forekommer, og altså ikke det enkeltstående tilfælde, hvor ordstillingen var omvendt. FSA en symboliserer endvidere kun den del af vores algoritme, som processorer teksten for de enkelte dage. At finde ud af hvornår vejrudsigten for en ny dag starter i teksten, er som tidligere beskrevet relativt simpelt. FSA en kan ses i Figur 6: 14

16 <raintype> <anyword <rainpower> <anyword <rainpower> q 0 q 1 <raintype> q 2 <anyword and <raintype>, <rainpower> q 3 <anyword> <anyword th <anyword q 4 <adj> q 5 th and, of <location>, <direction> <location>, <direction> q 7 q 6 <location>, <direction> <location>, <direction <anyword>, punktum <anyword> punktu q 8 Figur 6 Finite State Automata I q0 looper vi indtil vi enten støder på en raintype eller en raintypemoderator. Siden der kan være flere raintypemoderators, må vi også i q1 loope. Herfra kan vi gå til q2, hvis vi finder en regentype. Hvis det næste ord vi støder på hverken er en raintypemoderator eller raintype, hopper vi tilbage q0 og starter forfra, da der så ikke er tale om et udsagn vedrørende regn alligevel. Det kunne f.eks. være isolated clouds, hvor clouds jo så ikke er en regntype. Fra q2 kan vi gå til accepttilstanden i tilfælde af at vi støder på et punktum. I så fald lykkedes det ikke at identificere lokation. Det kunne f.eks. være i tilfælde af, at vores system 15

17 støder på den omvendte ordstilling som beskrevet tidligere. Det skal måske her nævnes, at FSA en kun er designet til den hyppigst fremkomne ordstilling. Vi går til q3 og tilbage til q2, hvis vi støder på et konjunktiv, mere præcis og. Dette gøres, da vejrudsigterne til tider grupperer flere regntyper sammen, f.eks showers and thunderstorms. Det næste, vi ønsker, er at finde den navneordsfrase nedbørsfænomenet er forbundet til. I vejrudsigterne er lokationsfraserne altid i bestemt artikel, det vil sige, de starter med ordet the på engelsk. Finder den et the, hopper den til q4. Er det efterfølgende ord associeret med loccation eller retning kan vi hoppe til næste state, q6, da der så er definitivt tale om en lokationsfrase. Støder vi ind i et adjektiv, f.eks the far north coast må vi igennem et ekstra tjek i q5 for at finde ud af om det efterfølgende er en lokation eller retning, hvis ingen af disse forekommer skal algoritmen hoppe tilbage til q2. I q6 kan vi loope, da der kan forekomme en længere kombination af lokationer og retninger. I tilfælde af, at der er flere lokationer i frasen hoppes der til q7, når ordet and rammes. Samme tilstand bruges, hvis der stødes på præpositionen of, den første lokationsfrase kan være en del af en ny lokationsfrase, og stødes der efterfølgende på en lokation eller retning, hoppes der tilbage til q6. Når der til sidst rammes et ord (eller tegn), der ikke har med hverken lokation, retning, and eller of er vi færdige og algoritmen hopper til accepttilstanden. Besvarelse af spørgsmål Førnævnte FSA kan udfylde templaten, men ikke svare på spørgsmålet: Vil det regne på sydkysten i morgen. Som vi nævnte tidligere, må vi gruppere alle de lokationer, der har med sydkysten at gøre og sammenligne disse med lokationsfeltet i templaten. Det er efter vores opfattelse ikke nødvendigt at opsætte en FSA for dette, da der i bund og grund vil være tale om en sammenligning med meget få regler. 16

18 Implementering I det efterfølgende afsnit vil vi se på, hvordan vi konkret omsætter vores FSA til en algoritme, der trækker det relevante information ud af vejrudsigten. Først har vi dog udarbejdet et mere generelt klassediagram for vores implementering, som ses i Figur 7. Det skal her bemærkes, at vi ikke har haft som mål, at programmet skulle være korrekt objektorienteret. Diagrammet er alene Userinterface Start main method() 1 Userinterface Userinterface() actionlistener() Funktionalitet WeatherReport loadweatherreport( ) tokenize() 1 1 WeatherExtractor loadweatherreport( ) matchpatterns() 2 0..* 0..* 0..* Dictionary Word RainTemplate makedictionary( 0..* ) loaddictionary 1 Figur 7 Klassediagram for implementeringen 17

19 ment som en oversigt over vores implementering. Leksikonet Først vil vi se nærmere på den klasse, der i systemet hedder Dictionary. Som vi også nævnte i teoridelen, er et IE systems første opgave at lave en leksikalsk analyse, og metoderne til at gøre dette har vi placeret i denne klasse. På baggrund af denne klasse skal der laves to objekter. Det første objekt vil være vores samlede leksikon med alle de ord systemet kender til. Ordene hentes ind fra en ekstern tekstfil. Hvert ord vil være mærket med en type. Her et kort uddrag af vores leksikon:... southern direction southwest direction state location storms raintype... Vi har valgt manuelt at fylde vores leksikon med ord, der er relevante for at udfylde felterne i vores template. Praktisk har vi gjort dette løbende, mens vi har tunet vores system til testdatasættene. Man kunne også, på baggrund af hele testsættet, have skabt en ordliste, og så ellers have gået i gang med at kategorisere ordene. Vi tror dog ikke, at dette vil øge præcisionen af vores system betydeligt. Vores leksikon består desuden kun af enkelt ord, og altså ikke af ordpar. Det andet objekt, der skal laves på baggrund af Dictionary -klassen er et leksikon over selve input-vejrudsigten. En funktion vil putte alle ordene i vejrudsigten i en array og sammenligne dem med leksikon-objektet for det samlede leksikon. Resultatet vil se ud som leksikonuddraget for det samlede leksikon. I run-time vil begge leksikonet dog ikke være i en tekstfil, men i en arrayliste, da det er noget lettere at arbejde med. Derudover er leksikonerne stadig så små, at det ikke vil have nævneværdig indflydelse på systemets ydelse. Det samlede leksikon blev på 84 unikke ord, sammenlignet med en unigrams analyse af træningsvejrudsigterne der viser, at der er 381 unikke ord i alt. Grunden til at vores leksikon kun er så cirka ¼ del af det samlede, skal delvis findes i at vi arbejder inden for et begrænset domæne inden for vejrudsigterne. Det vil sige at vi kun har hentet ord ind der har været relevante for nedbør og 18

20 lokation. Inden for vejrudsigter indgår der desuden også oplysninger om temperaturer, vind med mere som ikke er relevant for at udfylde vores template. Selv om vi har markeret f.eks. coast og south som henholdsvis en lokation og en retningen i vores leksikon, diskriminerer vores algoritmer ikke mellem de to, da det simpelthen ikke har været nødvendigt for at fange lokationsfrasen. Grunden til at vi oprindeligt havde skabt to ordklasser, var at vi dermed kunne holde systemet åbent for også at registrere oplysninger om vindstyrke og naturligvis vindretning. F.eks. indgår der en retning i denne frase: Northwest winds ahead of the change. Dette indgår dog ikke i vores implementering. Pattern Matching I WeatherExtracter klassen ligger systemets vigtigste funktion, kaldet matchpatterns. Det er her vi har forsøgt at omsætte vores FSA til en algoritme i JAVA, der udfylder vores template. Resultatet i pseudokode kan ses i Figur 8 (algoritmen i sin fulde længe er for stor at vise her). 19

21 While (wordlist!= empty){ If Word = <weekday> then day = weekday If (word.type = raintype or rainpower){ While (word.type!= <punktum>){ If word.type = rainpower Rainphrase += word If wordtype = raintype Rainphrase += word If wordtype = konjunktiv and word(next).type = raintype Rainphrase += word Word.movenext } } If (raintype.found){ While (word =! <punktum>){ If (word=<the> and (word(next).type = direction or location or adjektiv)){ Location.add(word) thefound = true } If (thefound and ( word.type = direction or location or adjektiv)) Location.add(word) If (thefound and ( word.type = konkunktiv, præposition) If (word(next)type = location, direction, adjektiv) Location.add(word) If ((thefound and word(next)=<punktum>) or!(thefound and word.type=<location> or <direction> or <the> or <adjektiv> or <konjunktiv> or <præposition>){ Template.make Exitloop } Figur 8 Pseudokode for matchpatterns() Ovenstående, forholdsvis grove pseudokode, skal ikke ses som en erstatning for at se i selve koden, hvor der også er tilføjet kommentarer, der vil lette forståelsen for læseren. Vi nævnte i foranalysen, at vores FSA havde et problem hvis lokationsfrasen kom før nedbørsfrasen, da FSA en kun var designet til at håndtere at nedbørsfrasen kom først. I ovenstående algoritme ville der dog ikke være kompenseret for dette ved at søge baglæns fra nedbørsfrasen, i de tilfælde, hvor algoritmen ikke er i stand til at bestemme en lokation. Vi har dog stadig undladt at implementere det, da der er tale om så få tilfælde af denne ordstilling. 20

22 Kontekstresolution. Vi ville som nævnt ikke implementere en kontekst resolution i programmet, om end det er nødvendigt for at øge recall raten for systemet. F.eks. kan den nuværende algoritme ikke finde lokationen for f.eks. denne sætning. Southeasterly winds along the north coast in association with an upper level trough should bring isolated showers and possible thunderstorms to that region. I denne sætning vil det være let at tilføje en simpel form for kontekstresolution til algoritmen, idet that region henviser til the north coast, som er den eneste lokationsfrase i sætningen. Altså hvis algoritmen ikke finder en lokationsfrase efter raintypen eller den støder på et pronomen, leder den før i sætningen efter en lokationsfrase, der kan henvise hertil. Dette har vi dog ikke nået at implementere. Regner det så i morgen? Det er jo så spørgsmålet. Vi har valgt ikke at bruge tilstandsdiagrammer til at løse dette inferencing problem. Egentlig er der også her tale om et mini-ie problem. Vi har en liste over ord, der er associeret med sydkysten, som vi vil sammenligne med en liste af ord i lokationsfeltet. Ifølge Michael Sipser er finite automatas og regular expressions ækvivalente (Sipser, 1997). Vi har da også her anvendt JAVA s indbyggede regular expressions til at søge i lokationsfeltet. Først måtte vi dog opstille en liste over udtryk, der er associeret med sydkysten: The south hvis den ikke efterfølges af en lokation The southern parts The southern coast the coast mid-south coast the far southeast the southeast the southern half of the coast the southern border m.fl. 21

23 Vi kan dog slet ikke være sikre på, at lokationsfeltet kommet til at se præcis ud som ovenstående. F.eks. kan der i lokationsfeltet stå the central and southern coast. Det regulære udtryk skal altså ignorere central and. Resultatet er en række regulære udtryk (Her vist i det format JAVA tillader 1 ). Et eksempel på et af vores regulære udtryk kan ses her: ([a-z ]* and )?(the )?((far )?)(southern southeast south)? (coast coasts corner border)( and [a-z ]*)? Dette udtryk genkender f.eks. The southern coast eller the far south coast. Vi har splittet vores regulære udtryk op i flere dele. I princippet kunne det hele være i et enkelt regulært udtryk, men desværre bliver det så meget svært at overskue. I lokationsfraser som f.eks. The south and north coast, hvor der altså er tale om to forskellige lokationer: The north coast og the south coast, har vi ikke splittet udtrykket op i vores lokationsfelt, og vi løser altså problemet med søgningen via regulære udtryk. Havde vi valgt at splitte udtrykket, hvor der indgik et konjunktiv, for det meste et og, ville sammenligningen af lokationsudtryk være noget simplere. Det var da også denne form, der ville være hensigtsmæssigt, hvis man skulle sammenligne med leksikon over lokationer. 1 Se eventuelt mere på 22

24 Evaluering For at kunne vurdere effektiviteten og pålideligheden af et information extraction system, er det naturligvis nødvendigt at evaluere dette. I information extraction fokuserer man på to variabler, når man ønsker at vurdere, hvor godt et system er. Disse to er recall og precision, som henholdsvis giver et billede af, hvor godt et system er til at udvinde information, og hvor godt et system er til at udvinde korrekt information. Vi har derfor udført en test på en del af vores tekstmateriale. I alt havde vi som sagt ca. 60 vejrudsigter, 45 af disse er brugt som baggrund for identificering af mønstre og til tuning. De sidste 15 har vi brugt til at udføre recall og precision på vores system. Vi har kontrolleret to ting i denne test: om vi får et rigtigt svar på spørgsmålet will it rain tomorrow on the south coast? (kolonne 2) og hvorvidt de genererede templates for hver vejrudsigt er korrekte, forkerte eller ukendte (kolonne 3-6). Ukendte templates er dem, hvor vi ikke kender lokationen for hændelsen nedbør. Dette har så givet os følgende resultater: Testeksempel Svar Templates Korrekte Forkerte i alt templates templates Ukendte 1 8.maj Korrekt maj Korrekt maj Korrekt maj Korrekt maj Korrekt maj Korrekt maj Korrekt maj Forkert maj Korrekt maj Korrekt maj Korrekt maj Korrekt maj Korrekt maj Korrekt maj Korrekt Total 14/ Tabel 2 Evalueringsresultater 23

25 Vi kan altså se, at vores system har en god precisionscore, hvad angår vores hovedspørgsmål, helt nøjagtigt 14/15 = 0,93. Recall scoren vil her være den samme, da vores system ikke kan give ukendt som et svar. I et tilfælde hvor vores system ser templates med ukendt lokation, vil den ignorere dette i forhold til spørgsmålet. Kigger vi på alle templates samlet bliver precisionscoren endnu højere: 45/(45+2) = 0,96. Recall bliver så en del lavere, nemlig 45/58 = 0,78. Vores system må altså siges at være rimeligt præcist, da mængden af forkerte svar er meget lille. Til gengæld har vi en del tilfælde, hvor en af templatevariablerne er ukendte. Så er det jo man kan diskutere, hvad der er vigtigst: at brugeren får et rigtigt svar eller at han altid får et svar. Ville vi udarbejde et system, hvor vi kunne svare på alle spørgsmål angående regn og tilhørende lokation, ville det nok være muligt at lave dette med høj nøjagtig, men brugeren ville langt fra være sikker på at få et brugbart svar i hvert eneste tilfælde. Når det drejer sig om vejret vil vi dog sige, at precision er vigtigere end recall. Den høje precisionscore i vores test skal nok også tages med forbehold. Antallet af vejrudsigter brugt i testen skulle nok have været en del højere, før man med sikkerhed ville kunne konkludere noget generelt om vores system precisionscore for denne type af tekst. I testmaterialet har vi være forholdsvis heldige, da ordstillingerne og de anvendte ord har lignet, det vi anvendte til analysen rimeligt godt. For spørgsmålet om det regner på sydkysten, kan vi desuden også få et rigtigt svar, selv om templates egentlig er udfyldt forkert. Vi går i vores system ud fra, at hvis der en lokation, der er associeret med vores område ikke bliver nævnt regner det heller ikke der. Derfor kan der være fejl i de generede templates uden svaret på spørgsmålet nødvendigvis er forkert. I det tilfælde algoritmen svarer forkert på spørgsmålet er der netop fejl i templaten, hvor algoritmen ikke kan udfylde lokationsfeltet. Her løber algoritmen netop ind i den omvendte ordstilling af locations og nedbørsfrasen: Cloud will develop in the southeast of the state with a light shower or two. (15.maj) Vi var på forhånd klar over at vi ikke ville kunne svare på dette med den nuværende algoritme. Hoveddelen af fejlene er da også relateret til dette problem. Desuden er vi i testfasen stødt på uventede fraser som systemet ikke kan løse: Scattered coastal showers(8.maj) 24

26 Her indgår lokationen som en del nedbørsfrasen. Isolated showers in Alpine region I ovenstående er lokationen er der en grammatisk fejl, idet Alpine region ikke er sat i bestemt artikel. Hvis lokationsfrasen ikke starter med the vil vores system ignorere frasen. Grammatiske fejl og stavefejl er forholdsvis udbredt i vejrudsigterne. Stavefejlene kan man rimeligt nemt tage højde for gennem leksikonet, mens man er nødt til at tage for de grammatiske fejl i selve algoritmen. Det har af gode grunde ikke været inden for vores rækkevidde. Desuden er et par af fejlene i templateudfyldningen forekommet i forbindelse med, at en lokation ikke var repræsenteret i vores leksikon. I dette tilfælde manglede adjektivet higher og lokationen peak (the higher peak). Den høje precision og recall score kan også relatere til at vi ikke har givet os i kast med at løse problemet omkring hvornår på dagen regnvejret muligvis fremkommer. Men vi mente ikke, at vejrudsigten gav nok hints til, at vi kunne løse dette tilfredsstillende. Desuden har det kun i få tilfælde været nødvendigt med kontekstresolution, hvilket netop ikke er implementeret i vores algoritmer. 25

27 Opsamling I vores system har vi fået implementeret funktioner, der kan foretage en delvis parsing af inputteksten, nemlig den del relevant til nedbør. Vi har hovedsageligt fokuseret på udarbejdelsen af scenario templates, og vi har ikke forsøgt at klassificere alle navneord, stedord og lignende, men dette ville være et vigtigt element i et mere omfattende IE system. Hvis man ser på de forskellige områder indenfor IE, så står der også klart, at det er indenfor scenario template udarbejdelse, at de største udfordringer ligger. I forhold til lexical analysis, name recognition og så videre, er præcisionen scenario pattern matching fasen noget lavere. Den pattern matching der foregår, er meget afhængig af det pågældende scenario, og kræver omfattende tilpasning, hvis den skal kunne bruges til tekster med andre scenarioer. Eksisterende IE systemer har problemer med at opnå præcision på over 60 % hvad dette angår, hvor præcisionen for name recognition kan kommer over de 90 % (Cunningham, 1999, 7ff). Information Extraction er et interessant område, der potentielt kan øge effektiviteten i informationssøgning betragteligt, når systemerne der anvender IE bliver mere modne. Inden for området arbejdes der meget med at kunne udarbejde systemer, der let kan tilpasses nye domæner og scenarier, hvilket desværre ikke er tilfældet i dag. Dette er et af de største problemer teknologien skal have overvundet, før dens udbredelse kan forøges betragteligt. Som det er i dag kan IE systemer sagtens anvendes til datamining og kategorisering af tekster, som den er bygget til parse, men pålideligheden er stadig ikke høj nok til, at man helt kan undvære et menneskeligt check af resultaterne. Tiden man sparer kan dog stadig være betragtelig, men udarbejdelsen af systemet kan altså også tage en del tid. Vi kan bare se på vores arbejde over den sidste uges tid med at udvinde information om regntyper fra en tekst med ca. 250 ord. Vi har arbejdet intensivt med at udvikle en algoritme, der kan gøre dette, og denne kan dog stadig kun svar på et spørgsmål. Endvidere vil det være meget svært at tilpasse vores system til en anden type tekst, eller for den sags skyld en anden type vejrudsigt. Som tidligere nævnt anvender vi ikke voice-funktioner i vores system, men vi er også af den mening, af et voicesystem ville omfatte nogenlunde de samme problemstillinger, som har været evidente i vores projekt. Om vi havde lavet 26

28 systemet på sådan en måde, hvor brugeren selv kunne indtaste et spørgsmål eller om vi havde lavet det med voice, mener vi, at den centrale problemstilling i dette projekt også vil være gældende her. Dette er netop, at det stillede spørgsmål også skal analyseres for, hvad det er, der ønskes svar på. Det er da også naturligt sprog begge type systemer skal analysere på og forsøge at trække mening ud af. Det skrevne sprog har rimelig faste grammatikker. Det talte naturlige sprog har ikke helt så faste grammatikker, hvilket vil opsætte store udfordringer for en algoritme, der skal trække mening ud af dette. Desuden har vi også en hypotese om at man i det talte naturlige sprog bruger mange personlige stedord, hvilket medfører at et sådan system skal have en omfattende kontekstresolution. 27

29 Litteraturliste [Appelt 1993] Appelt, Douglas E., Jerry R. Hobbs, John Bear, David Israel & Mabry Tyson, FASTUS: A Finite-state Processor for Information Extraction from Real-world Text, 1993, SRI International [Cunningham 1999] Cunningham, Hamish, Information Extraction - a User Guide ( 1999, Second Edition, University of Sheffield [Grishman 1997] Grishman, Ralph, Information Extraction Techniques and Challenges from Information Extraction A Multidisciplinary Approach to an Emerging Information Technology, 1997, Springer-Verlag Berln Heidelberg [Jurafsky 2000] Jurafsky, Daniel & James H. Martin, Speech and Language Processing, 2000, Prentice-Hall Inc. [Sipser 1997] Sipser, Michael, Introduction to the Theory of Computation, 1997, PWS Publishing Company 28