Adversarial Evaluation for Models of Natural Language

by Noah Smith

Presented at the Front Range NLP Meetup by L. Amber Wilcox-O'Hearn

November 6th, 2013

(These slides were made with hieroglyph.)

Overview

• What is NLP?
• How do we currently evaluate NLP models?

• Intrinsic
• Extrinsic
• Perplexity

• Proposed evaluation:

• Adversarial

Computational Linguistics vs. Natural Language Processing?

Spurious disctinction‽

• Linguist: a scientist who wants to characterise human language.
• Computational linguist: a linguist who uses computational models.
• NLP: uses computational models to perform tasks involving natural language.

Practical difference?

• Scope and applicability.

In both cases, a central goal is to make and use better models.

Evaluation Methods

So, supposing you have designed an NLP model. How do you evaluate it?

In this paper, these methods are discussed:

• Intrinsic
• Extrinsic
• Perplexity

To illustrate the these methods, let's suppose that we want to model POS tagging with an HMM.

Intrinsic Evaluation

In intrinsic evaluation

• Assume the linguistic model is good.
• Goal --> design an algorithm to replicate the expertise of a trained linguist who understands the model.

For POS tagging:

• Typical evaluation uses corpus annotated for POS by linguists.
• Train to match the linguists.

Weakness of Intrinsic Evaluation

• It already assumes what we might like to prove:
  • POS tags characterise the language well.
  • The set of POS tags developed is optimal for the language.
  • The annotations are correct.

In particular, this evaluation technique can never help us design a better set of tags, let alone a theory of word characterisation that improves on the theory of POS.

Extrinsic Evaluation

In extrinsic evaluation

• Abandon the goal of MatchLinguist at our current level of analysis.
• Let a downstream task determine the appropriateness of the model.

Sounds reasonable: Insofar as a model improves the result of our NLP task, it will be desirable for the task to incorporate it.

However, what can we conclude if it doesn't improve the task?

Implicitly Evaluates Architecture

Suppose we have a POS tagger that is being used as a component in a speech recogniser. If a change to our tagger does not improve our results, we still can't be sure the tagger isn't better!

• How is the tagger being used?

• Does it assume some structure?
• Does it take advantage of all available information the tagger could provide?

This kind of evaluation can not take into account the way the model is used, which limits the scope and structure of the model, and can miss improvements. I.e. the model could be a better characterisation of the language and not improve the results of the task.

Perplexity

• Perplexity measures how well a model predicts data.
• Appealing — aligns with the desirable property of predictive power.

Limitations we would like to avoid:

• only applies to models that assign probability scores.
• Comparisons require the same event space.

Of course, improved perplexity cannot guarantee improved results on an extrinsic task, and in practice it often doesn't.

Should a Model be Interpretable by Linguists?

Intrinsic evaluation doesn't work for unsupervised methods.

"it is not at all clear [unsupervised taggers] are actually learning taggers for part-of-speech" -- Garrette and Baldridge 2013

The contentious point is that unsupervised models aren't replicating linguistic expertise.

Similarly, in Chang et al. 2009, the entire paper is based on the problem that the best topic models in terms of predictive power are not the most intuitive to humans.

Subsymbolic phenomenon, symbolic understanders.

The Adversarial Model

• Intended as an improvement to perplexity:
  • Removes probabilistic constraint
  • Instead of prediction, it focuses on the ability to find places where the model fails.
  • Should encourage error analysis.

The evaluation cycle has two roles that evolve with respect to each other:

• Zellig's job is to construct corruptions of natural language and present them as choices for Claude.
• Claude's job is to choose the original text from Zellig's offerings.

Strong Players

A good Claude is one that can reliably distinguish real text from synthesised text.

What makes a good Zellig?

• Transforms from well-formed to ill-formed.

• Even the best Claude cannot tell two well-formed texts apart.

• Distinguishes well between current Claudes.

• As state-of-the-art Claudes improve, it takes more sophisticated transformations to find their weakness.

Negative Evidence

Learning linguistic structure through this cycle is a way to incorporate negative evidence, a powerful tool for grammar induction.

Often an induced grammar is over-general; the more well-formed structures it can produce or recognise, the more ill-formed ones come along for the ride.

By evaluating a model on its ability to detect ill-formed text, we incorporate negative evidence into the iterations.

Role of the Linguist

If linguists are not annotating data or evaluating intuitiveness, how can we use their expertise?

• Designing Zelligs to test theories of language?

Malaprop

Malaprop involves transformations of natural text that result in some words being replaced by real-word near neighbours.

• Takes a small portion of Wikipedia (from Westbury Labs) as a corpus.
• Breaks it into training, development, and test sets.
• By inserting real-word errors, makes two tasks out of the dev set

Malaprop task generation

Two tasks:

• Correction: makes a copy of the dev set with some words in the text changed to orthographic near-neighbours.
• Adversarial: Any sentences with errors are also made into a set of pairs for a Claude to choose from.

Baselines:

• Implements a trigram-based baseline for the adversarial task.
• (Soon) implements a trigram-based baseline for the correction task.

Goals

• Reproducibility
  • All aspects of the code are built using SConstruct.
  • Nothing was done to create the experiment other than run the available code on the available data.
  • All random choices are reproducibly random.
• Create baselines for future work / collaboration on the tasks.

Adversarial Task

The baseline using this Zellig is too easy.

• The data used here resulted in an accuracy of 97%.
• That's fine. It just means that the baseline to improve on first is the Zellig, not the Claude.
  • E.g. Instead of changing some words to random near-neighbours, change them to high probability near-neighbours.

Evaluation code includes some basic error analysis

• Outputs the sentence pairs on which the trigram model failed.

Examples

In the README.