Erfahrungen beim Grammar Engineering

Übersicht

• Beschreibung eines aktuellen Projekts
• Probleme für NLP-Systeme
• Definitionen
• Warum ist es so schwierig, natürliche Sprache zu formalisieren?
• Testen einer Grammatikkomponente
• Werkzeuge für die Grammatikentwicklung
• Zusammenfassung

Ziel der Vorlesung ist die Beschreibung der Schwierigkeiten bei der Erstellung einer Syntaxanalyse-Komponente für ein praktisch einsetzbares NLP-System. Dies wird illustriert an dem z.Zt. an der Universität Zürich entwickelten UIS-System.

Motivation

Grammar writing is much more difficult than rule writing. The intricate interrelations of the individual rules of a grammar make grammar writing a complex and error-prone process, much like computer programming. (Friedman "Computational Testing of Linguistic Models in Syntax and Semantics"; 1989)

... the concern was raised that none of the improvements in the actual formalisms such as powerful type systems and additional data types have brought the systems any closer to exploitation in industrial strength systems and that moreover efficient processing models might even have become less likely through this development. (Uszkoreit 1993)

Beschreibung eines aktuellen Projekts

Ziel des Projekts

Ein Frage-Antwort System, das es erlaubt, (eingeschränkte) natürlich-sprachliche Fragen zu stellen, die vom System natürlich-sprachlich beantwortet werden.

Anwendungsbereich

Informationen zur Universität Zürich (zunächst Themen der Studentenverwaltung (Immatrikulation, Exmatrikulation, Studienfachwechsel) und Fragen zu den Veranstaltungen (Was findet wann und wo statt?)

Der Projekt-Plan zeigt eine Übersicht über die geplanten Komponenten.

Ziel der Syntax-Komponente:

• Lieferung einer funktionalen Struktur
• weitgehende Eliminierung (oder zumindest kompakte Repräsentation) von Mehrdeutigkeiten

Vorgehen bei der Erstellung der Syntax-Komponente:

• Auswahl des Formalismus: ID/LP- kombiniert mit PS-Regeln
• Auswahl eines Parsers: Bottom-Up Chart-Parser
• Auswahl einer Morphologiekomponente: Gertwol (in Kooperation mit Celex)
• Festlegung von Eingabe- und Ausgabeformaten
• Zusammenbau und Testen der Analyse-Software
• Manuelle Analyse (eines Teils) der Eingabetexte
• Abgrenzung von Grammatikmodulen: NP-Syntax, VG-Syntax, Satz-Syntax
• Schreiben von Grammatik-Regeln
• Testen der Grammatik
• Verfassen von Systemdokumentation und Benutzerhandbuch

Probleme bei diesem Vorgehen:

• Die Morphologiekomponente liefert falsche, doppelte, ungewollte Werte; manche Werte fehlen; die Morphologie-Informationen sind in einem unbrauchbaren Format.

  Lösung: spezielles, möglichst flexibles Lexikon-Interface

• Der Parser liefert manche Analysen doppelt, andere fehlen.

  Lösung: das Parsing-Programm muss sehr gut ausgetestet werden

• Der Parser braucht zu lange, um alle Ergebnisse zu liefern.

  Lösung: das Parsing-Programm muss bzgl. Effizienz optimiert werden; evtl. müssen Heuristiken eingebaut werden, die Analysen mit geringer Wahrscheinlichkeit nicht verfolgen.

• Die Grammatik wird unübersichtlich und unverständlich.

  Lösung: Modularisierung der Grammatik, Ausführliche Kommentierung der Grammatik, Werkzeuge zur Unterstützung von abstrakten Sichten auf die Grammatik, Werkzeuge zur Unterstützung von Konsistenzprüfungen

• Der Parser liefert zu viele Analysen für einen Satz.

  Lösung: alle Möglichkeiten zur Auflösung von Mehrdeutigkeiten müssen ausgeschöpft werden (z.B. Substantivvalenz, Selektionsrestriktionen, Abfolge-Wahrscheinlichkeiten, Interaktion mit menschlichem Experten)

Probleme für NLP-Systeme

Thesen von R. Seiffert

[Seiffert 1992] stellt unter dem Titel "How could a good system for practical NLP look like" folgende Thesen auf:

1. Auf der Suche nach Eleganz haben wir die Kontrolle aus den Augen verloren.
2. Eine schleche Spezifikation kann nicht effizient verarbeitet werden.
3. Deklarative Spezifikationen führen nicht automatisch zu reversiblen Prozessen.
4. Es gibt keinen universellen, eleganten, effizienten Formalismus, der alle Probleme in NLP lösen kann.
5. Die Entwicklung grosser Grammatiken erfordert ausgefeilte, verlässliche und gut dokumentierte Werkzeuge, die das Grammar Engineering im Team unterstützen.

Thesen von K. Jensen (Coling 88)

Why Computational Grammarians can be skeptical about existing linguistic theories

1. NLP arbeitet mit grossen Datenmengen, linguistische Theorien beschäftigen sich mit kleinen Datenmengen.
2. Natürliche Sprachdaten enthalten viele störende Einzelheiten, die von ling. Theorien nicht beachtet werden (z.B. Interpunktion, Datum- und Massangaben).
3. NLP muss alle und nicht nur die vermeintlich 'grammatischen' Konstruktionen einer Sprache behandeln können.
4. NLP ist eher am Abdeckungsgrad einer Grammatik interessiert, während ling. Theorien eher an Vollständigkeit orientiert sind.

Thesen von D. Roesner (Coling 88)

Why implementors of practical NLP systems cannot wait for linguistic theories

1. Viele Probleme, die in ling. Theorien intensiv behandelt werden, kommen in natürlichen Sprachdaten nur selten vor.
2. Einige Probleme, die in ling. Theorien nur marginal behandelt werden, stellen grosse Anforderungen an NLP (z.B. komplexe NPs).
3. Ling. Theorien werden oft nur sehr speziell auf eine Sprache zugeschnitten und lassen sich nur schwer auf eine andere Sprache übertragen.
4. NLP-Systeme müssen auf Benutzerfreundlichkeit Rücksicht nehmen (z.B. Umlaute korrekt behandeln).
5. NLP-Systeme müssen mit unbekannten Wörtern zurechtkommen.
6. Ling. Theorien betrachten vor allem Sprachanalyse. Für die Sprachgenerierung wird viel extralinguistisches Wissen benötigt.

Thesen von J. Tsujii (Coling 88)

Reasons why I do not care for grammar formalisms

1. Das schwierigste Problem für NLP ist die effiziente Behandlung von Mehrdeutigkeiten. Ling. Theorien haben darauf keine Antwort.
2. Eine elegante ling. Theorie führt nicht notwendigerweise zu einem elganten und effizienten NLP-System. Eine ling. Theorie wird oft dadurch elegant, dass sie die Komplexität auf eine andere Ebene verschiebt.

Thesen von U. Hahn

Forschungsstrategien und Erkenntnisinteressen in der anwendungsorientierten automatischen Sprachverarbeitung

[Hahn 92] unterscheidet:

• Linguistische CL
• Sprachverstehensorientierte CL
• Ingenieurorientierte CL

Charakterisierende Merkmale von ingenieurorientierter CL:

• Beschäftigung mit realistischem Sprachmaterial
• Methodenmix
• Beständigkeit der grundlegenden Methodenannahmen
• Experimenteller Ansatz
• Anwendungsszenarien

Definitionen

Linguistic Engineering

Unter Linguistic Engineering verstehen wir in Analogie zum Software Engineering das systematische Vorgehen bei der Entwicklung und Wartung von NLP-Software nach ingenieurwissenschaftlichen, technologischen und linguistischen Gesichtspunkten. Wir betrachten Linguistic Engineering als eine spezielle Art des Software Engineering, die sich auszeichnet durch das Anwendungsgebiet "natürliche Sprache". Anders formuliert: Software Engineering angewendet auf natürliche Sprache ist Linguistic Engineering.

Grammar Engineering

Grammar Engineering ist ein Modul im Linguistic Engineering Prozess. Linguistic Engineering und Grammar Engineering teilen die Orientierung an ingenieurmässigen Methoden und Prinzipien. Grammar Engineering setzt ein, wenn im Linguistic Engineering der zu erfassende Teilbereich der natürlichen Sprache festgelegt wird. Es unterstützt die Erfassung und Gruppierung der zu behandelnden Phänomene und begleitet die Erstellung der linguistischen Syntax bis zur Fertigstellung des Grammatikmoduls, das dann in das Gesamtsystem integriert wird.

Warum ist es so schwierig, natürliche Sprache zu formalisieren?

• Natürliche Sprache enthält Ambiguitäten auf allen Ebenen.

• NLP-Software muss auf grosse Mengen von linguistischem und allgemeinem Wissen zugreifen.

• Die Ebenen der natürlichen Sprache sind verschränkt. Semantische Eigenschaften bedingen die syntaktische Verarbeitung, und syntaktische Eigenschaften bedingen die morphologischen Verfahren.

• Natürliche Sprache bietet keinen klar abgrenzbaren Datenbereich. Ihre angemessene Verwendung ist abhängig von Adressatenkreis und Situation. Sie unterliegt dialektalen und diachronischen Veränderungen und fachspezifischen Erweiterungen.

• Wenn natürliche Sprache als Eingabe- oder Ausgabemedium von NLP-Software genutzt wird, dann muss eine besonders starke Orientierung an den Prinzipien der Software-Ergonomie erfolgen, da die Gefahr von Missverständnissen zwischen Mensch und Computer aufgrund der häufigen Ambigheit und Vagheit sprachlicher Äusserungen besonders gross ist. Prinzipien der Software-Ergonomie sind:

  • Aufgabenangemessenheit
  • Selbstbeschreibungsfähigkeit
  • Erwartungskonformität
  • Steuerbarkeit
  • Fehlerrobustheit

Testen einer Grammatikkomponente

muss auf mehreren Ebenen geschehen

1. Sind genau die Sätze, die als grammatisch erkannt werden sollten als solche erkannt worden?
2. Wurden jedem grammatischen Satz genau die erwarteten Strukturen zugewiesen?
3. Wurden in jeder Struktur genau die erwarteten Merkmalstrukturen bei den entsprechenden Konstituenten berechnet?
4. Zusätzlich: Wurden alle Grammatikregeln mindestens einmal genutzt? (vollständige Regelausnutzung)

Wie kann effizientes und systematisches Testen einer Grammatikkomponente organisiert werden?

Mein Vorschlag ([Volk 95]): Einsatz einer Testsatzsammlung

Eine Testsatzsammlung ist eine Kollektion von

• grammatikalisch wohlgeformten Sätzen einer natürlichen Sprache und
• kontrastiv ausgewählten ungrammatikalischen Ketten (Non-Sätzen)

Dabei gelten die folgenden Bedingungen:

1. Die Wörter der Sätze und Non-Sätze stammen aus einem kontrollierten Vokabular.
2. Sätze und Non-Sätze sind im Hinblick auf ihre grammatikalischen Eigenschaften annotiert. D.h., jedem Satz werden Merkmale zugewiesen, die seine Eigenschaften beschreiben.
3. Die Sätze unterscheiden sich paarweise in mindestens einem Merkmal. Gleiches gilt für die Non-Sätze.
4. Ein Non-Satz stimmt bis auf ein Merkmal mit einem in der TSS enthaltenen Satz überein. In diesem besonderen Merkmal verletzt der Non-Satz die Grammatikalität.

Vorteile von Testsatzsammlungen gegenüber Korpora

• Die Sätze der TSS können auf die Bestände eines Lexikons abgestimmt werden. Das entspricht dem Testprinzip, nach dem immer nur ein Aspekt getestet werden soll, um so beim Auftreten von Fehlern auf die Ursache gezielt schliessen zu können.

• In einer TSS werden die Phänomene systematisch aufgelistet und annotiert und können dadurch als Grundlage für das Testen von Grammatiken, aber auch für die Grammatikentwicklung dienen. Im Gegensatz dazu garantieren die Auswahlkriterien eines natürlichen Korpus das Auftreten einer bestimmten syntaktischen Konstruktion nicht.

• Das Testen einer Grammatik mit natürlichen Korpora verursacht eine grosse Zahl redundanter Testläufe, da die Verteilung der syntaktischen Konstruktionen in der Sprache sehr ungleich ist. Wenige Konstruktionen kommen sehr oft, aber viele Konstruktionen kommen nur sehr selten vor.

• Eine TSS enthält eine gezielte Auswahl von Non-Sätzen. Diese kommen in natürlichen Korpora nicht vor.

Probleme bei Testsatzsammlungen

• Wie erreicht man eine systematische Abdeckung aller Syntaxphänomene?
• Wie grenzt man lexikalische von syntaktischen Phänomenen ab?
• Mach welchem Schema annotiert man die Sätze?
• Wie isoliert man einzelne Phänomene?
• Wie erzeugt man Non-Sätze?
• Wie entgeht man der Künstlichkeit konstruierter Sätze?

Werkzeuge für die Grammatikentwicklung

Editor-Programme

• müssen linguistiknahe Notation unterstützen
• müssen Modularisierung unterstützen
• müssen spezielle Hilfefunktionen unterstützen

Konsistenzprüfer

z.B. Test auf Transitivität in LP-Regeln

Tracer

erlauben das Beobachten des Einsatzes der Grammatikregeln

Testsatzsammlung

übersichtliche Verwaltung der Testsätze und Testergebnisse

Zusammenfassung

• Das Erstellen von Grammatiken für NLP-Systeme ist ein komplexer Prozess.
• Die ingenieurwissenschaftliche Sicht deckt sich oft nicht mit der linguistischen Sicht auf Theoriebildung.
• Eine Testsatzsammlung ist eine mächtige Ressource für die Grammatik-Entwicklung.
• Grammatik-Entwicklung erfordert spezielle Werkzeuge zum Editieren, Browsen und Testen.