Denne rapport er et produkt af et INF6 projekt, i faget Verbal interaktion i multimodal kontekst. Rapporten dokumenterer udviklingen af et vejrudsigtssystem. Koden til systemet er at finde på den vedlagte cd-rom. Aalborg Universitet, 2. juni 2004. Lasse Høgh Rasmus Flyger Berg Andersen Side 1 af 13
Denne rapport beskriver et vejrudsigtssystem, der skal ses som et alternativ til de eksisterende systemer, hvor man modtager information på eksempelvis sin mobiltelefon eller PDA. De nuværende systemer er i stand til at give brugerne en forud defineret vejrudsigt, men informationen i denne er meget statisk, da indholdet er defineret på forhånd. Brugeren har altså ingen mulighed for at spørge specifikt til eksempelvis, hvordan temperaturen er om formiddagen eller, hvilken retning vinden tager hen over eftermiddagen. Vi ønsker, at vores system skal give brugeren mulighed for at få lige nøjagtig den information som brugeren ønsker, og ikke en række forud definerede data. Vi ønsker endvidere at systemet skal konstrueres således, at brugeren kan stille et spørgsmål til systemet, og ud fra dette få et konkret og enkelt svar på spørgsmålet. Tørvejr? Figur 1. Det rige billede på figur 1 illustrerer en typisk situation med systemet, hvor en bruger gerne vil vide, hvordan vil vejret blive senere, da der lige nu er regnvejr. I denne situation vil det være til store gene, hvis systemet gav brugeren en masse irrelevant information i forhold til, om hvorvidt det bliver tørvejr eller ej. Brugeren er blot interesseret i om der bliver bedre vejr på et tidspunkt, og altså ikke Side 2 af 13
interesseret i, hvad vejret er lige nu eller nogen anden information som ikke direkte har relevans for situationen. Vores interesse for et sådan system opstod da vi en formiddag ønskede per mobiltelefon at finde ud af, hvordan vejret ville blive om eftermiddagen. For det første var det meget svært at finde ind til informationen, og for det andet var det besværligt, da informationen endelig blev tilgængelig for os, at finde den ønskede information på en mobiltelefons display. Vi har i dette miniprojekt valgt at fokusere på ekstraktion af mening, men beskriver her det overordnet system for at sætte vores fokus i kontekst. Vi vil således i dette afsnit beskrive systemet i brug, samt opridsede mulige problemstillinger der måtte være i forbindelse med dette. Brugeren vil ved opstarten af programmet blive introduceret til systemet, hvor han blandt andet skal specificere, hvilket område vejrudsigten skal være for. Herefter kan brugeren stille de spørgsmål han måtte have til systemet. Ud fra det stillede spørgsmål søger systemet den ønskede vejrudsigt igennem. Finder systemet ikke noget svar på baggrund af det stillede spørgsmål returnerer den enten et svar lydende på; ugyldigt spørgsmål eller vejrudsigten indeholder ikke det ønskede svar. Ved returnering af ugyldigt spørgsmål har systemet vurderet, at spørgsmålet ikke er et gyldigt. Dette vil enten være et resultat af, at spørgsmålet fra brugeren indeholder fejl der er forstyrrende for spørgsmålets syntaks eller semantiske mening, eller fordi brugeren henviser til stednavne, som ikke er indeholdt i den valgte vejrudsigt. Ved returnering af vejrudsigt indeholder ikke det ønskede svar har systemet ikke kunne finde noget match mellem det stillede spørgsmål og vejrudsigten. Side 3 af 13
For at et sådan system skal kunne fungere, er der en række betingelser, som skal overholdes af systemet. De forskellige vejrudsigter skal for det første være til rådighed for systemet. Således kræves det, at der er indgået en aftale med de forskellige udbydere af vejrudsigter om, at disse stiller vejrudsigterne til rådighed for programmet, og at disse konstant holdes opdateret. Et scenarie man kan forestille sig er, at systemet stiller en server til rådighed for udbyderne af vejrudsigterne, hvor disse så uploader vejrudsigterne i et for systemet kendt format. Et problem ved denne løsning eller for den sags skyld ved hvilken som helst løsning, vil være stavefejl fra udbyderens side af. En stavefejl vil kunne betyde at systemet ikke vil være i stand til at hente en bestemt information, uanset hvordan en bruger stiller sit spørgsmål. Således vil det være en nødvendighed, at de enkelte vejrudsigter er gennemlæst, hvilket vil kræve en ekstra indsats fra udbydernes side af. Spørgsmålet bliver således om udbyderne vil være interesseret i dette når økonomi pludselig bliver en del af sagen. Et alternativ er selvfølgelig, at systemet er robust nok til selv at genkende og rette stavefejl. Disse bekymringer vil vi ikke komme nærmere ind på her, men blot erkende at systemet er sårbart i forhold til udbyderne af vejrudsigterne og i takt med, at antallet af vejrudsigter stiger, forøges chancen for fejl betragteligt. Ud fra det foregående afsnit vil vi her afgrænse os til det system der reelt er blevet udviklet igennem dette miniprojekt. Vores program er et ganske simpelt system. Programmet henter først et leksikon, en række patterns og en eller flere vejrudsigter ind i hukommelsen. Programmet laver ordene fra leksikonet om til objekter af klassen Word, indeholdende hvert ord og dette ords semantiske type. Herefter bliver de enkelte ord-objekter i vejrudsigten konverteret til en liste af ord-typer, som kan sammenlignes med de patterns man har valgt at lede efter i vejrudsigten. Endelig skrives de dele af vejrudsigten, som er pattern-matchede på input såvel som de eksisterende patterns, ud. Side 4 af 13
Vi betragter vores program som noget nær den allersimpleste form for syntaksdrevne semantiske analyse det er muligt at lave. Programmet er et helt basalt pattern-matching program, hvor en tekst søges igennem for semantiske patterns, udfra et leksikon, som beskriver hvilken betydning hvert ord kan have. I så fald at programmet finder et match mellem en sætning eller en del af denne og et pattern, skrives hele sætningen ud, da den må formodes at indeholde interessant information. Det leksikon vi har lavet, er bygget op omkring en kort række ord, som er specielle for det domæne vi undersøger. Vi har valgt at lave følgende typer, baseret på den information vi mener vil være interessant at trække ud af en vejrudsigt. TEMPERATURE: Denne type bliver sat på ord som warm, cold etc. LOCATION: Da det ofte er vigtigt at finde information angående en specifik lokalitet, bliver alle stednavne markeret med denne benævnelse. Vi har ikke implementeret genkendelse af komplekse ord, og derfor vil et stednavn som The Tasman Sea blive genkendt som The:ANYWORD Tasman:LOCATION Sea:LOCATION WEATHERTYPE: Forskellige typer af vejr er grupperet under denne benævnelse. Eksempelvis snowy, sunny, cyclone, fair. RAIN: Vi har valgt at typificere regn for sig selv. Dette kunne siges at være en underklasse af WEATHERTYPE, men i vores simple system vil vi gerne have muligheden for at søge helt specifikt efter regn. STRENGTH: Regn forekommer typisk med en benævnelse for hvor kraftig denne er. WINDTYPE: Også vind har vi valgt at typificere for sig selv. Vind eksisterer typisk i forbindelse med en DIRECTION. DIRECTION: Denne type bruges til retningsbestemmelse. Komplekse ord som North to northeast bliver igen genkendt som tre separate ord, hvilket der automatisk er taget højde for i vores patterns, men hvad værre er, at begreber som The North ikke bliver betragtet som LOCATION, men som DIRECTION. Dette er en beklagelig begrænsning i vores program. Side 5 af 13
TIME: Det kan være relevant at søge efter information som beskriver et bestemt tidspunkt på dagen, dette bruger vi TIME til. WEEKDAY: Bruges om betegnelser for ugedage. ANYWORD: Bruges til alle ord som ikke har en specifik betydning indenfor domænet. Vores leksikon og liste af patterns, som vi sammenligner vejrudsigter med, er opstået ved, at vi har trænet på 46 vejrudsigter. Hver vejrudsigt er først blevet søgt igennem for ord, som er blevet sorteret, og sat ind i en fil. Derefter har vi ved håndkraft navngivet hvert enkelt af de ord, som ikke blot har betegnelsen ANYWORD. Endelig er vejrudsigterne blevet kørt igennem endnu en gang, for at finde mønstre af ordtyper i disse. Efter at duplikaterne er blevet fjernet fra disse, har det resulteret i 455 patterns. Inferens og reference Reference- og inferens-regler, er regler, som viser hvorledes ord kan lede tilbage til andre ord, og dermed påtage sig en anden betydning. I vores program vil en typisk reference være et ord som for eksempel there eller it, som refererer tilbage til et ord af typen LOCATION (eksempelvis Tasmania ). Inferensregler siger, hvis man betragter det i boolsk algebra: (A & A => B) => B. Altså: Hvis A er sand, og A medfører B, da er B også sand. Et eksempel herpå kunne være, at hvis Australien er ramt af vulkanudbrud, og Sydney ligger i Australien, da må Sydney være ramt af vulkanudbrud. Dette gælder naturligvis kun så længe man ikke har yderligere information om emnet. Side 6 af 13
Vi har fravalgt at benytte Inferens og reference i vores program, da vi fandt at andre features var vigtigere. FASTUS og os Hvis vi betragter IE systemet FASTUS 1 i forhold til det program som vi har lavet, er der en del forskelle. FASTUS-systemet er bygget op af 6 niveauer 2, som hver har til formål at trække en specifik type information ud af det materiale der undersøges. 1. Tokens: En input stream af karakterer ændres til en sekvens af tokens. Vores program gør dette, ved at læse en vejrudsigt ind som en streng, og derefter tokenize den, og sammenligne den med vores leksikon. Derefter gemmes hvert enkelt ord i n liste som et Word objekt. 2. Complex Words: Fraser bestående af flere ord genkendes. I vores tilfælde kunne dette være ord som mild to warm, som angiver et temperaturinterval. Vores program har ikke denne feature, men hvis den blev implementeret ville det betyde, at stednavne som for eksempel The Tasman Sea ville blive genkendt som ét token, ligesom det førnævnte temperaturinterval. Dette ville betyde en bedre chance for korrekt genkendelse af vigtige tokens, og ville desuden have nedsat mængden af mulige patterns. 3. Basic phrases: Sætninger deles op i grupper af navneord, udsagnsord og de forskellige andre ordklasser som giver mening indenfor det domæne man forsøger at finde information indenfor. I vores leksikon har vi ikke klassificeret navneord og udsagnsord, men blot kaldt ethvert ord som ikke har nogen specifik mening ift. vejr, for et ANYWORD. Dette har af 1 Finite State Automata-based Text Understanding System 2 [Daniel Jurafsky & James H. Martin: Speech and Language Processing. An Introduction to Natural Language Processing, Computational Linguistics, and Speech Recognition. Prentice Hall 2000, s. 580] Side 7 af 13
naturligvis stor betydning for hvor kompleks en genkender man kan lave. 4. Complex phrases: Komplekse ordgrupper identificeres. Dette sker ved at tilføje konjunktion og præposition til de ordgrupper der opstod i trin 3. Det gør vi ikke. 5. Semantic Patterns: Her identificeres semantiske entiteter og hændelser, og disse sættes ind i forud definerede skabeloner. Dette gør vi til dels. Vi vurderer teksten i forhold til de patterns vi har optrænet programmet til at genkende, hvilket betyder at det ofte fremkommer med svar, og at disse endda også ganske ofte er fornuftige. Beklageligvis betyder vores forsimplede tilgang også, at programmet giver svar ud fra alle de patterns der matcher en given sætning, hvilket giver en del gentagne svar. Endelig har alle stednavne den samme semantiske type i leksikonet, hvilket betyder, at søger man efter vejret på en bestemt lokalitet, returnerer programmet alle svar som omhandler en LOCATION 6. Merging: I dette sidste skridt sammenkobles alle referencer til den samme entitet i hele teksten. Vores program er, sjovt nok, ikke helt så robust som FASTUS. Vi implementerer nogle af de features som FASTUS har, men udelader mindst lige så mange. Dette giver os et program som ganske vist ofte præsterer et resultat, men som også ofte laver fejl, eller fremkommer med ufuldstændig information. I det efterfølgende afsnit vil vi afteste programmet, for at vurdere hvor mange fejl det laver. Side 8 af 13
Vi var fra starten af projektet enige om, at systemet skulle undergå en test for at se, hvor succesfuldt det er. Vores indledende tanke var, at lade systemet undergå den samme test som vi blev præsenteret for i en af vore VMK forelæsninger 3. Vi har dog indset, at det vil være uhensigtsmæssigt, at bruge denne evaluering, da systemet ikke kan imødekomme de krav testen stiller i form af et enkelt og entydigt svar. Vores system afleverer således ikke kun et enkelt svar, men en række af svar, hvor antallet af disse afhænger af antal patterns der passer og antal gange det der spørges til, bliver nævnt i vejrudsigten. Herved vil det blive meget svært at definere, hvad der som sådan er et korrekt svar, og hvad der ikke er. Specielt taget i betragtning, at flere af svarene kan være duplicates på grund af vores patterns. I stedet har vi valgt at udføre en af os opstillet test, hvor vi løber ti test-vejrudsigter igennem og ud fra disse ser, hvor mange rigtige og forkerte svar vi får på tre forskellige spørgsmål. Denne test udmøntede sig i følgende resultater. Spørgsmål 1: How will the temperature be today! "! # $ " %! " af 3 [Daniel Jurafsky & James H. Martin: Speech and Language Processing. An Introduction to Natural Language Processing, Computational Linguistics, and Speech Recognition. Prentice Hall 2000, s. 578] Side 9 af 13
Spørgsmål 2: Will it be windy today &! # $ % & Spørgsmål 3: Will it be rainy today &! # $ % Side 10 af 13
Som det fremgår af testen var der en række duplicates som gør det svært at se, hvor succesfuldt systemet egentligt har været. Vi har derfor i nedenstående tabel fjernet de svar, som er duplicates, hvor således der fremkommer et noget mere tydeligt billede af ovenstående test. '()* '()* '()*! # $ % Ser vi nærmere på spørgsmålene i ovenstående tabel, ser vi at spørgsmål 1 er kommet med det rigtige svar fem ud af ti gange, altså systemet kommer med det rigtige svar 50 % af gangene. Dette tal er endnu højere ved spørgsmål 2, hvor det rigtige svar kommer op på 70 %. Ved spørgsmål 3 er det rigtige svar helt oppe på 80 %, hvilket tilsammen med de to andre resultater giver en korrekt svarprocent på 66,6%. Dette resultat kan uden tvivl forbedres betydeligt, ved at se nærmere på brugen af patterns. De patterns der er i systemet er autogenereret ud fra træningsvejrudsigterne. Derudover har vi intet gjort ved vores patterns, hvilket uden tvivl kunne have betydet en forbedring i systemets procent af rigtige svar. Der er med andre ord ikke lagt nogen vægt på patterns i systemet, hvor vi blandt andet kunne have lavet generaliseringer af patterns og således få fjernet nogle af de tåbeligt lange patterns der er i systemet. Nogle af de forkerte svar vi fik tilbage i testen var et direkte resultat af, at pattern matching fejlede, hvor sætninger blev splittet forkerte steder og returneret. Side 11 af 13
Vi har igennem dette projekt valgt at benytte os af Grishmans Information Extraction metode. Dette har blandt andet betydet, at vi har implementeret et leksikon, en række patterns og testet, hvor succesfulde disse har været til at klassificere den ønskede information i templates. Som allerede nævnt i denne rapport ser vi dette program som et meget simpelt program, da vi ikke har implementeret referenceregler eller inferensregler. Dette har ganske naturligt afgrænset projektet omfang, idet vi således ikke har været i stand til at udføre mere komplekse handlinger. Bugs Som sagt er et stort problem for programmet at der er alt for mange patterns, og at disse ikke er generelle, hvorfor der ofte matches flere patterns på den samme del af en vejrudsigt. Et andet problem, som dog umiddelbart vil være løsbart er, at programmet matcher alle patterns på alle spørgsmål. Dermed bliver spørgsmål om temperatur ofte matchet med patterns som har med eksempelvis en kold luftstrøm. Dette er naturligvis ikke hensigtsmæssigt, da dette ikke siger noget om den aktuelle lufttemperatur. Dette mener vi også er forklaringen på den lave procent af korrekte svar på spørgsmål om temperatur. Programmet har også et par andre skønhedsfejl. Igennem testen opstod der til tider mystiske problemer, med svar der ikke umiddelbart gav mening. Dette har ved eftersyn vist sig at have grobund i den måde som vi tokenizer og gemmer vores Words på. Problemet er, at når en vejrudsigt bliver læst ind i programmet, fjernes alle punktummer, ligesom problem med at ord foran komma blev ignoreret af systemet, har nødvendiggjort et hack, som fjerner alle kommaer. Desuden kan der i sjældne tilfælde opstå seriøse fejl, hvis vejrudsigten ikke er formateret efter de regler som programmet søger vha. Dette kan f. eks være, hvis vejrudsigten springer rundt i dagene, da outputtet er delt op efter disse. Side 12 af 13
I forhold til vores system har vi opnået følgende: Vi har set, at det er muligt for systemet, ud fra testen at komme med det korrekte svar 80% af gangene, hvis vi også medregner de rigtige svar, hvor der også forekom forkerte svar. Vi har, ved hjælp af et leksikon og en række patterns, opbygget et system, som går ind og analyserer de enkelte sætninger i en vejrudsigt for således at komme med et svar. De patterns vi har opstillet er som nævnt autogenereret ud fra 46 træningsvejrudsigter. Problematikken i dette valg er, at disse fundne patterns passer perfekt til de 46 træningsvejrudsigter, men at disse selvfølgelig varierer i de 10 testvejrudsigter. Som vi har været inde på er der en række tiltag, som kan tages for at imødekomme problematikken, såsom at få tilpasset de fundne patterns til mere generelle situationer. Vi mener at have lavet et design, som forholdsvist nemt kan arbejdes videre med. Mere avancerede regler og patterns bør i sådan en videreudvikling indbygges i programmet. Ligeledes bør man se nærmere på måden, hvorpå leksikonet og patterns er opbevaret, og om det nu er den mest hensigtsmæssige måde at gøre det på. Det system vi er nået frem til har altså en række mangler i forhold til et endeligt system. Dog kan systemet allerede nu i sin grundform uden større problemer konverteres til at køre på en mobiltelefon eller en PDA, hvilket har været et designmål i sig selv. Side 13 af 13