Dependency Parsing
Prerequisite Knowledge
This lecture builds on the following concepts from earlier lectures. If any feel unfamiliar, review the linked notes before proceeding.
Previously Covered in This Subject
- Ambiguity in natural language — covered in Lecture 1 (Why Language Is Hard: Ambiguity Everywhere) and Lecture 9 (Ambiguity in Natural Language)
- Grammar and context-free grammar — covered in Lecture 9 (Grammar and Context-Free Grammar)
- Phrases and head words — covered in Lecture 9 (Phrases and Head Words)
- Chart parsing, CKY, and probabilistic parsing — covered in Lecture 9 (Chart Parsing; Probabilistic Context-Free Grammar; CKY Parsing and Chomsky Normal Form)
- Contextual word embeddings and transformers — covered in Lecture 2 (Contextual Word Embeddings: A First Look) and Lecture 7 (Transformers and BERT for POS Tagging)
10.1 From Phrase Structure to Dependency Parsing
10.1.1 Why Parsing and Word Relations Matter
Hook. Read the sentence I saw a girl with a telescope. Who was holding the telescope — the girl, or the person doing the seeing? The words are identical in either reading; only the relations between them change. That is exactly the problem this session's technique exists to solve: recovering the connections among words that carry the meaning.
Parsing is a foundational step for almost every modern NLP application. Question answering needs to know which words the user's question binds together, conversational AI has to track what modifies what, and machine translation has to carry the relations across languages. Dependency parsing in particular shows up in agentic AI and in many current AI applications, so this is a practical, widely used technique, not just a classroom exercise.
The meaning of a sentence depends totally on how its words are connected to each other. There is a lot of ambiguity in natural language, and the relation among words decides which reading is meant. So the step that recovers those connections — parsing — is one of the most important pieces of any NLP pipeline.
Before this session we covered phrase structure parsing: chart parsing, CYK parsing, and probabilistic parsing, all built on context-free grammar rules that group words into phrases (a noun phrase goes to a noun phrase plus a word phrase, and so on). We also covered evaluation — precision, label precision, and label recall — with a worked example. In dependency parsing, the viewpoint changes: we do not look at phrases at all. We look at the individual words and ask how each word depends on the others. The output is a set of relations between words rather than a tree of phrase labels.
Phrase structure grammars run into real trouble with sentences like I saw the man on the hill in Texas with the telescope at noon on Monday: a standard context-free parser returns an astonishing 132 different valid trees for it, because each prepositional phrase can attach at several points in the tree. Free-word-order languages such as Hindi and Russian make the situation worse — their words can move around freely, which breaks the rigid "boxes" of phrase-structure rules altogether. Dependency grammar sidesteps both problems by ignoring phrase boundaries and working directly with word-to-word relations.
| Phrase structure parsing | Dependency parsing | |
|---|---|---|
| Unit of analysis | Phrases (NP, VP, PP, ...) built by grammar rules | Individual words and their relations |
| Output | A tree of phrase labels over the whole sentence | A set of directed relations between words |
| What carries meaning | The phrase structure (which bracket goes where) | Which word depends on which word |
| Handles free word order | Poorly — the box structure breaks | Naturally — relations survive word movement |
10.1.2 The Ambiguity Problem
The classic example is I saw a girl with a telescope. This sentence has two interpretations depending on whether the phrase with a telescope attaches to girl or to saw:
- If with a telescope attaches to girl, the girl is carrying the telescope.
- If it attaches to saw, the seeing was done through a telescope.
Both readings use the same words in the same order; only the dependencies differ. This is exactly why the relations among words are so important in NLP applications — the relations, not the word order alone, carry the meaning.
Two parses, one sentence. Draw the relations as arrows from head to dependent. In the first reading the preposition with depends on girl (girl → with → telescope): the girl has the telescope. In the second reading with depends on saw (saw → with → telescope): the seeing happened through the telescope. The word sequence is untouched — the starting point of one arrow decides the meaning.
That single arrow makes the difference concrete for machines. A machine translator must know which reading is meant before it can choose whether the telescope travels as a possession of the girl or as an instrument of seeing; a question-answering system that misbinds with a telescope answers the wrong question. Dependency parsing exists to draw those arrows correctly, and the rest of this lecture builds the machinery that draws them: first by hand with transition rules, then with learned weights, then by searching for the best tree.
Pitfalls.
- Assuming the ambiguity is rare: attachment ambiguities like this one are everywhere in natural language, which is why a parser must make a choice for nearly every preposition.
- Forgetting that both readings are grammatically valid: the problem is not bad grammar but missing relations — the parse must pick the relation that the context supports.
Recap. Parsing recovers the connections among words, and those connections — not the word order alone — decide what a sentence means. Dependency parsing does this by asking how each word depends on the others, instead of how words group into phrases. Next we meet the vocabulary of that answer: head words, roots, and dependency graphs.
10.2 Head Words, Roots, and Dependency Graphs
10.2.1 Head Words and Roots
Hook and intuition. In a solar system, the sun holds the planets in orbit, and the planets carry their own moons. Dependency grammar treats a sentence the same way: the main verb is the sun — the gravitational center of the sentence — the nouns are planets orbiting it, and adjectives and determiners are moons around those planets. Every word except the center is pulled by exactly one other word; those pulls are the dependencies. The analogy breaks where a real word can have many dependents spread on both sides — a planet with several moons of its own — which is common in real sentences.
Every sentence — in English, in Indian languages, in any language — has a head word, also called the governor: the single most important word of the sentence. All the other words are dependent on it.
Take the sentence Bills on ports and immigration were submitted by Brownback, Senator, Republican of Kansas. The word submitted is the main word here. Look at the other words and you will find that they all connect to one another through submitted. This head word is also called the root — the point from which the dependency tree is plotted. The dependencies flow from the head word out to every other word in the sentence.
Phrases have their own head words too. In a noun phrase, the noun is the head: all words in the phrase relate through the noun. In a verb phrase like walked into the store, the verb walked is the head that connects the rest of the phrase. So head-word thinking applies at the sentence level and at the phrase level.
When dependency relations are drawn as arrows, the arrows always point from the head word to the dependent word. In the prepositional phrase with telescope, with is the head of the prepositional phrase, and telescope is the head of the noun phrase a telescope, so the arrow runs from telescope down to a. This arrow convention (head → dependent) is the standard way to read a dependency tree.
10.2.2 Dependency Graphs and Notation
A dependency parse is naturally a graph. Each word in the sentence is one node, and each relation between words is an arc (an edge). Every sentence can be represented by a set of nodes and a set of arcs:
where is the set of words and is the set of relations among them.
The mathematical notation for a relation is simply — an arc from word to word . When the type of the relation matters, it is written with a label , but the label is optional: we are often interested only in whether two words are related, not in what kind of relation it is. Indirect relations (paths or dominance) are denoted by : if can reach through an intermediate node , the connection passes through :
Graph notation, compactly. A dependency parse is a directed graph : collects the words (nodes), collects the relations (arcs). Each arc is written , meaning word is the head of word ; an optional label names the relation type. An indirect relation (path through intermediate words ) is denoted .
10.2.3 Conditions on Dependency Graphs
Not every graph of relations is a valid dependency parse. Four conditions are needed, of which the first three are mandatory everywhere:
- Connected ( is connected). All nodes must be connected to one another through at least one relation. A word that is an "island" — linked to nothing — is impossible in a grammatically correct sentence; if a word had no connection, it would serve no purpose.
- Acyclic (no cycles). If saw is the head of I, then I cannot be the head of saw. A relation like and together forms a cycle, and cycles are not allowed.
- Single head constraint. Every word has exactly one incoming arrow. A word cannot have multiple head words, so multiple incoming edges are impossible. Outgoing edges are fine — the head word connects to many dependents — but incoming is always exactly one.
- Projectivity (not mandatory for every algorithm). Projectivity forbids crossing edges. It is important for English because English is written left to right, so the relations are left-to-right as well: if saw connects to girl over the words between them, you cannot also draw a relation that crosses over that span. This condition is used by the arc-eager parser; the graph-based algorithm we will see later does not require it. It is listed here for completeness.
The three universal conditions. Think of each condition as a rule about who can be whose boss: (1) no island words — everyone is linked into the sentence; (2) no loops — if A is the boss of B, B cannot be the boss of A; (3) one boss per word — everyone has exactly one incoming arrow, while a boss may have many dependents. Any graph that satisfies these three is a valid dependency tree; the fourth condition, projectivity, is optional and depends on the algorithm.
Scope. The first three conditions hold for every well-formed dependency tree in any language. Projectivity is different: it is an assumption about how languages are written. English is largely projective because it is written left to right, but non-projective parses do occur, and free-word-order languages produce crossing arrows more often. Algorithms that require projectivity (the transition-based parser later in this lecture) silently fail on crossing relations; algorithms that do not require it (the graph-based one) can recover them. The sentence graph always follows the single-head rule — that is what makes it a tree rather than a tangle.
Visual intuition. Picture the Bills on ports and immigration were submitted ... sentence as a row of words with curved arrows drawn above them. From submitted — the root — arrows fan out to every other word, and each word receives exactly one arrow tip. Because the arrows never cross each other, the picture looks like a tidy arch over the sentence: that non-crossing property is projectivity in visual form. The one-sentence takeaway: a valid parse is a single connected, acyclic arrow diagram in which every word has exactly one incoming arrow.
Pitfalls.
- Pointing the arrow the wrong way: arrows run head → dependent, not dependent → head. The root of the sentence is the word everything ultimately depends on, and it has no incoming arrow.
- Drawing two arrows into one word: that violates the single-head constraint — a word cannot have two bosses.
- Allowing a cycle: and together is never a valid tree, even if both arcs are grammatically plausible on their own.
10.2.4 Relation Labels
The optional label on an arc names the type of relation: subject, direct object, determiner, and so on. In a labeled parse you can read, for example, that one word is the direct object of the verb, another is the direct subject of the verb, and a third is the determiner of the noun cup. Having gold-labeled data that says what kind of relation each arc is will always help an application, but if the labels are unavailable, you can still work with the unlabeled relations.
Standard label sets exist for this: the Universal Dependencies project provides a uniform annotation scheme used across many languages, with labels such as nsubj (nominal subject), dobj (direct object), det (determiner), prep (preposition), pobj (prepositional object), amod (adjectival modifier), and tmod (temporal modifier). Because the same labels are reused for many languages, models trained on one language's treebank can transfer grammatical knowledge to another.
Labeled parse of I saw a girl with a telescope. Reading the arrows as head → dependent: saw is the head, with nsubj I and dobj girl; girl carries det a and prep with; with carries pobj telescope; telescope carries det a. The label on the prep arc is what distinguishes the two readings from section 10.1 — if with depends on saw instead of girl, the same labels describe the other interpretation. Even fully labeled, the relation structure stays a plain directed graph: labels enrich the arcs, they do not change their shape.
Real-world & domain connection. Labeled dependency trees are the backbone of the Universal Dependencies treebanks, which are built from resources such as the Penn Treebank and annotated by human experts across dozens of languages. Production NLP pipelines — including the parsing components inside question-answering, machine translation, and conversational AI systems — first recover the unlabeled relations, then assign labels such as subject and object, because downstream systems act on both the structure and the roles.
Recap. Every sentence has one head word (the root); arrows run from head to dependent; a valid parse is a connected, acyclic graph with exactly one incoming arrow per word; and arc labels — optional, but standardized as in Universal Dependencies — name the relation types. With this vocabulary in hand, the next topic builds such a tree mechanically, one relation at a time.
10.3 Deterministic (Arc-Eager) Parsing: The Four Transitions
Hook. Imagine a factory assembly line. Words arrive on a conveyor belt; a workbench beside it holds the words being processed right now; a robotic arm looks at the word on top of the workbench and the word at the front of the belt and decides, step by step, whether to attach an arrow between two words or to move a word across. The first parser family of this lecture works exactly that way — and, as the trace below shows, just four distinct moves are enough to build a whole dependency tree.
10.3.1 Parser Configuration
The first family of dependency parsing algorithms is deterministic parsing: we find the relations among the words using a fixed sequence of simple, deterministic steps — that is why it is called deterministic. At every step exactly one move is chosen by a fixed rule (or, as we will see in the next section, by a learned classifier) — there is no backtracking and no search over alternatives.
The state of the parser at any moment is a parser configuration, written as a triple:
- — the stack: the words currently being processed. The stack is LIFO — last in, first out.
- — the buffer: the words of the sentence that have not been parsed yet. The buffer is FIFO — first in, first out. Initially it holds every tokenized word of the sentence (including the full stop).
- — the arcs: the relations the parser has already discovered. Arcs may carry labels like the labels discussed above, or they may be unlabeled.
The initial configuration is
with an empty stack, the whole sentence in the buffer, and no arcs. At every step the parser checks the last word in the stack against the first word in the buffer — LIFO and FIFO determine how words are taken out, which is why the parser compares those two positions. A transition moves the parser from one configuration to the next, and parsing proceeds as a sequence of transitions. The goal at the end: the buffer must be empty, and the arcs set then contains all the relations of the sentence. The stack may or may not be empty at termination — that is allowed. Some textbooks apply a few extra reduce operations to empty the stack too, but it is not required, because reduce never adds an arc.
10.3.2 The Four Transitions
Four operations are enough to parse a sentence with this algorithm. They are the malt parser's transitions, which we focus on; other parsing algorithms exist in Jurafsky and Martin but are not required for the exam.
LEFT-ARC. We compare the last word of the stack with the first word of the buffer. If there is a left-arc relation — the buffer word is the head of the stack word — we add the arc to and remove the last word from the stack. The buffer is untouched: the buffer word may itself be a dependent of other words later. So the one-line rule to remember: left arc removes the last word in the stack.
RIGHT-ARC. If the relation runs the other way — the last word of the stack is the head of the first word of the buffer — we add the arc to , and then push the buffer word onto the stack, keeping it there. We cannot remove the stack word here: that word is a head, and it may be the head of other words still waiting in the buffer. So the one-line rule: right arc adds the first buffer word to the stack (and does not remove the head).
SHIFT. If no word in the stack is related to the first word of the buffer — which is always true at the start, when the stack is empty — we simply move the first buffer word onto the stack. It is always added at the last (top) position, so the LIFO order is preserved. Shift adds no arc.
REDUCE. Suppose the last word of the stack is not related to the first word of the buffer, but the second-last word of the stack is. Because the stack is LIFO, we cannot reach down and attach the buffer word directly — we cannot bypass the top word. So we reduce: we remove the last word from the stack, adding nothing to the arcs and changing nothing in the buffer, just to clear the way for the relation below. The one-line rule: reduce removes the last word in the stack, with no arc and no buffer change.
When generating the gold transitions (the oracle) from a labeled parse, the operations are checked in a fixed order: left arc first, then right arc, then reduce, then shift. This order is the standard arc-eager definition: at each configuration the parser tries LEFT-ARC (it applies only when the word on top of the stack does not yet have a head), then RIGHT-ARC (it applies when the stack and the buffer are both non-empty), then REDUCE (it applies only when the top word already has a head), and only if none of them matches the gold tree does it SHIFT the front word of the buffer onto the stack. Because the check order is fixed, every configuration has exactly one correct next operation — the sequence is deterministic. The preconditions are what make LEFT-ARC and REDUCE mutually exclusive: a word that has no head yet cannot be reduced, and a word that already has a head cannot receive a left arc, since that would give it a second head.
| Operation | Arc added | Stack changes | Buffer changes |
|---|---|---|---|
| LEFT-ARC | (buffer word heads stack word) | remove the last word | unchanged |
| RIGHT-ARC | (stack word heads buffer word) | push the buffer word | remove the first word |
| SHIFT | none | push the buffer word | remove the first word |
| REDUCE | none | remove the last word | unchanged |
10.3.3 Worked Example: "He sent her a letter."
Trace of He sent her a letter . (seven tokens, full stop included). The gold dependency graph below is human-labeled training data, and we replay it transition by transition, adding the relation labels from the gold tree.
C0. Stack empty. Buffer: [He, sent, her, a, letter, .]. Arcs: empty.
C1 — SHIFT. The stack is empty, so there is nothing to relate to the buffer; shift is the only possible first move. The buffer is FIFO, so the first word He moves to the stack. Stack: [He]. Buffer: [sent, her, a, letter, .]. Arcs: empty.
C2 — LEFT-ARC. The last stack word He and the first buffer word sent have a left-arc relation (arrow from sent to He, the subject of the verb). Add the arc and remove He from the stack. Stack: []. Buffer: unchanged. Arcs: {sent → He}. The arc can be written either as (sent, He) or as sent → He — the same thing.
C3 — SHIFT. Stack empty again. Move sent onto the stack. Stack: [sent]. Buffer: [her, a, letter, .].
C4 — RIGHT-ARC. sent is the head of her, so we add sent → her, and now we push her onto the stack without removing sent. Why? Because sent is a head and may be head of more words still in the buffer — and indeed it later connects to letter and to the full stop. Stack: [sent, her]. Buffer: [a, letter, .]. Arcs: {sent → He, sent → her}.
C5 — SHIFT. Check the last stack word her against the first buffer word a: no relation. Check sent against a: no relation either. Since no stack word relates to the first buffer word, we must shift. Stack: [sent, her, a]. Buffer: [letter, .].
C6 — LEFT-ARC. The relation between a and letter is a left arc: letter is the head of a (a determiner relation). Add letter → a and remove a from the stack. Stack: [sent, her]. Buffer: [letter, .]. Arcs: {sent → He, sent → her, letter → a}.
C7 — REDUCE. Now the tricky step. Is her related to letter? No. Is sent related to letter? Yes — there is a right-arc relation from sent to letter. But we cannot apply it yet: the stack is LIFO, and the last word her sits on top of sent. We cannot bypass her to reach an indirect relation, so we first reduce: remove her from the stack. No arc is added, the buffer is untouched. Stack: [sent]. Buffer: [letter, .].
C8 — RIGHT-ARC. Now the path is clear. sent is the head of letter (the direct object), so add sent → letter and push letter onto the stack. Stack: [sent, letter]. Buffer: [.]. Arcs: {sent → He, sent → her, letter → a, sent → letter}.
C9 — REDUCE. Is letter related to the full stop? No. Is sent related to the full stop? Yes. Reduce removes letter. Stack: [sent]. Buffer: [.].
C10 — RIGHT-ARC. Add sent → . (the punctuation attaches to the verb) and push the full stop onto the stack. Stack: [sent, .]. Buffer: []. Arcs: {sent → He, sent → her, letter → a, sent → letter, sent → .}.
Termination: the buffer is empty and all arcs from the gold graph are present, so the parse is complete. (If we wanted an empty stack, a couple of extra reduce steps would clear it, but they would add no arcs, so they are optional.)
The whole run used all four operations: two shifts, three left arcs, three right arcs, and two reduces, in the order SHIFT, LEFT, SHIFT, RIGHT, SHIFT, LEFT, REDUCE, RIGHT, REDUCE, RIGHT.
Sense-check. Every word has exactly one incoming arrow (He ← sent, her ← sent, a ← letter, letter ← sent, . ← sent), all five arcs of the gold graph are in , and the buffer is empty — the trace reproduced the full gold tree.
Cost. A single parse is linear in the length of the sentence: every transition either removes a word from the buffer or removes a word from the stack, and each word enters the stack once, so the number of steps is at most for words — . The price of this speed is that the parser is greedy: it decides each step once and never revisits a decision, so an early mistake can cascade and distort everything that follows. That is exactly the weakness the graph-based family at the end of this lecture attacks with a global view.
10.3.4 Student Questions and Answers
Q: How do we know whether the relation is left arc or right arc at a given step? A: From the gold figure — the training data. That figure is given to you, and you read the relation direction off it. Every choice in this trace is inferred from the training data.
The next question attacks the step where the trace seems to contradict itself: after the right arc the stack keeps its word, while after the left arc it does not.
Q: Why did we not empty the stack after the right arc, when we did remove the word after the left arc in C2? A: Because this word is a head word. In the left-arc case the stack word is a dependent, so removing it is safe. After a right arc the stack word is the head — the arrow goes from it to the buffer word — and a head can be the head of many other words still in the buffer. Here sent is the head of He, of her, of letter, and of the full stop. If we had removed it from the stack, we could never have found the relation between sent and letter. You do not know, while processing step by step, whether a head has more dependents to come, so you must retain it. That is exactly why right arc pushes the buffer word onto the stack instead of removing anything.
A second student asked where new words land when they enter the stack.
Q: Why is her added at the end of the stack, in the last position? A: Because of LIFO. The "first in, first out" and "last in, first out" rules govern taking words out of the stack and buffer, not putting them in. Words are added sequentially in order, and the parser compares the last stack word with the first buffer word, so each new word is appended at the top.
Then came the deeper doubt: if the word is done being processed, why keep it at all?
Q: What is the point of keeping her in the stack at all? We already processed it. A: Words leave the stack only through an operation: left arc or reduce. her entered through a right arc, and after a right arc no word is removed. To remove her we would need a left arc on it, or a reduce — and reduce is possible only when the first buffer word has a relation with a word below the top of the stack. Here a has no relation with sent (sent → a does not exist in the gold graph), so reduce cannot be applied and shift is forced. There is no way to drop a word from the stack without performing an operation.
Another student wanted the rule for shift stated simply.
Q: When exactly do we apply shift? A: Whenever no word in the stack has a relation with the first word of the buffer, we simply shift that buffer word onto the stack. The stack being empty at the start is just the first instance of this rule.
A follow-up asked whether the head sent would still be kept if the rest of the sentence were shorter.
Q: sent is a head word — it has relations to letter, to the full stop, to her. If there were no letter and no full stop, would we still keep sent as head? A: Yes. Whenever there is a right-arc relation, the stack word is a head, and you do not know until the end of the sentence whether it has more dependents. A head can have relations with multiple words — here sent has a relation with almost every word. You process to the end of the sentence and only then can you be sure.
The last question of the session was about how many dependents one head may have.
Q: Can any word have more than two outgoing relations, or is it only one? A: Outgoing can be multiple; incoming is always exactly one. Think of The intelligent girl went to market: went is the head of girl, and girl is the head of both the and intelligent. Multiple arrows out of a word are fine. What is forbidden is multiple arrows into a word — every word has a single head, the single head constraint. That answers both questions: one head per word, many dependents per head.
Pitfalls.
- Confusing LIFO and FIFO on insertion: these rules decide removal order, not placement order — words are always appended at the end of the stack, and the buffer always loses its front word.
- Removing the head after a RIGHT-ARC: the stack word that just became a head may govern more words still in the buffer, so it must stay.
- Applying REDUCE to a word that has no head yet: reduce clears words that are already fully attached — in the trace, her and letter were reduced only after their arcs had been added.
- Assuming the stack must be empty at the end: only the buffer has to be empty; leftover stack words are harmless, because reduce never adds an arc.
Real-world & domain connection. The four arc-eager transitions are the blueprint of the malt parser and of the transition-based parsers embedded in production NLP toolchains; the later neural parsers keep these exact operations and replace only the scoring of the moves — which is where the next section heads.
Exam note: Expect a numerical on arc-eager parsing: given a sentence and its gold dependency picture, write the four transitions — left arc, right arc, reduce, shift — from the initial configuration to the end of the sentence (buffer empty). The full trace of He sent her a letter . above is the template: every operation, every stack and buffer update, every arc added. Only the malt parser's arc-eager transitions are in scope; other parsing algorithms in Jurafsky and Martin are not required for the exam.
Recap. Arc-eager parsing builds the dependency tree step by step with a stack, a buffer, and an arc set, applying exactly one of four deterministic operations until the buffer is empty. Next, we learn how the parser chooses the right operation — by training weights on the gold transitions from a treebank.
10.4 Training the Deterministic Parser: Data Generation and Weight Learning
Hook. A parser that must be told the right move by a human-drawn gold graph is not yet a useful program. So how does a real parser decide its own moves? The answer: it learns weights for a small set of conditions, and the weights tell it which operation to apply at each step. The training data comes from the very transitions traced in section 10.3 — one labeled sentence in a treebank yields one sequence of correct moves.
10.4.1 From Transitions to Training Data
The arc-eager transitions are not just a way to parse; they are the machinery for generating training data for a classifier. Human-labeled treebanks — the Penn Treebank is the standard example — give us sentences paired with gold dependency graphs. Running the arc-eager algorithm over those graphs produces, for every configuration, the correct next operation: left arc, right arc, reduce, or shift. Those gold operations are the oracle: the target labels for learning.
Why go through this conversion? Because machine learning and deep learning algorithms cannot consume a dependency graph directly. They need feature–label pairs. Each configuration gives a feature description (the stack, buffer, and arc contents), and the gold transition is its class. Since there are exactly four operations, this is a four-class multi-class problem, and the configurations become the training tuples.
At test time the roles are reversed. A new sentence arrives (for example, something like She sent him a letter), the buffer holds all its words, the stack and arcs start empty, and at every step the learned weights select the best operation — finding, say, a left arc between a and letter, a right arc between sent and him — until the buffer is empty. The operations are the relations: each left arc and right arc drawn at test time is a discovered dependency.
10.4.2 The Weight-Learning Algorithm
The weights are learned the same way as in any linear classifier. The configuration is encoded as a feature vector , and each of the four operations gets a score that is the dot product of the weight vector with the feature vector:
The chosen operation at each step is the argmax — the highest-scoring class. During training, all weights start at zero, exactly like gradient descent initialization, and the update rule is:
The feature vector of the gold operation is added, the feature vector of the predicted operation is subtracted, and the old weights are updated accordingly. This is a perceptron-style update: the update literally adds the features of the correct move and subtracts the features of the bad move. If the prediction was right, the two vectors are equal and the weights do not change at all; every mistake moves the weights so that the gold operation scores higher and the wrong operation scores lower next time.
Learning continues while the error is being minimized, or for a fixed number of iterations — the same stopping logic as batch or mini-batch gradient descent: process all training examples (one sentence per pass, or all of them), then repeat until a fixed iteration count or an accuracy criterion is reached.
Decoding for a test sentence : start from the initial configuration, and while the buffer is not empty, compute the four scores with the learned weights, apply the argmax operation, advance the configuration, and repeat. That is the whole loop: pick the best operation, apply it, move on, until every word in the buffer has been processed.
10.4.3 Worked Example: "John saw Mary"
Weight learning for John saw Mary, first iteration. This standard example is used in class and also appears in the Jurafsky and Martin textbook. John and Mary are nouns; saw is a verb. These part-of-speech tags can be found automatically.
The three conditions. (1) the stack is empty; (2) the top of the stack — the last word in the stack — is a noun while the top of the buffer — the first word in the buffer — is a verb; (3) the top of the stack is a verb while the top of the buffer is a noun. Initial weights: all features are weighted 5, except the features of left arc, which are weighted 5.5.
Part 1 — feature vector. There are 4 classes (left arc, right arc, reduce, shift) and 3 conditions, so the feature vector has entries, . Each condition is Boolean: 1 if satisfied, 0 otherwise. The vector is written as four blocks of three — one block per class, each block holding the three conditions for that class — combined into a single row for convenience (keeping four separate vectors would also work, but the combined form is easier).
In the initial configuration C0 the stack is empty, so the first condition is 1 for every class; the stack holds no word, so the noun and verb conditions are 0 for every class:
- left arc: [1, 0, 0]
- right arc: [1, 0, 0]
- reduce: [1, 0, 0]
- shift: [1, 0, 0]
as blocks in one 12-entry vector. With initial weights of 5 everywhere except 5.5 on the left-arc block, the dot product for each class is:
The argmax is LEFT-ARC with score 5.5.
Part 2 — the update. But the gold transition for this sentence's first step — taken from the oracle, the arc-eager run on the training data — is SHIFT, not left arc. The initial random weights are wrong, so we update:
The gold shift vector contributes +1 to the shift block's first slot; the predicted left-arc vector contributes −1 to the left-arc block's first slot. The updated weights are so: left-arc first-slot 5.5 − 1 = 4.5, shift first-slot 5 + 1 = 6, and all other 10 slots unchanged at 5.
Part 3 — the next step. Now apply the shift operation: John moves to the stack. Stack: [John], buffer: [saw, Mary], arcs empty. John is a noun, saw is a verb, so the condition values are: stack empty → 0; top of stack is noun and top of buffer is verb → 1; top of stack is verb and top of buffer is noun → 0. The step-2 feature vector is so [0, 1, 0] in every class block, the scores are recomputed with the updated weights, the argmax picks the second transition, and the weights are updated again. The same procedure repeats for the rest of the sentence and then for the other training sentences until the final weights are learned. For the exam, only the first iteration of this process is needed.
Sense-check. The single mistake moved the gap between the two rivals by exactly 2: left-arc's score over shift fell from 5.5 − 5 = +0.5 to 4.5 − 6 = −1.5, so an empty-stack configuration now favors shift — the operation the gold graph actually requires.
The condition wording deserves one caution. The third condition appears in one place in the source as "the top of the buffer is a verb" and in another as "the top of the stack is a verb". The lecture notes define the three features as the conjunctive pairs used above — stack noun and buffer verb, stack verb and buffer noun — and only those agree with the numbers in Part 3 ([0, 1, 0] after John is shifted: John is a noun, so the stack-top-verb condition is 0). Both wordings agree on the examinable first step at C0, where the stack is empty and every class block reads [1, 0, 0].
This weight-learning example was flagged in class as a little overwhelming — that is expected. Work through it again slowly, one step at a time, and raise any doubts at the start of the next session.
10.4.4 Student Questions and Answers
Q: What exactly are we trying to learn here? A: The weights of all the features — the conditions built from the stack, the buffer, and the arcs — so that once we know the weights we can choose the right operation. And the operations are nothing but the relations among the words: every right arc and left arc we apply is a discovered dependency. Learn the weights on training data, then use them to draw the arcs of a test sentence.
The next exchange was about the single word argmax, which carries the whole decision.
Q: What do you mean by argmax in the algorithm? A: Argmax picks the best operation among the four — left arc, right arc, shift, or reduce — at each step. Concretely, you feed the configuration features to a classifier (say a deep network), it outputs a score per class, and argmax selects the highest one. During training that is how the predicted operation is produced for the weight update.
Another student wondered whether the feature vector always has exactly one 1.
Q: Is it necessary that exactly one condition is satisfied at every step? A: No. In this small example only one condition happens to be satisfied at a time, but with more features several can be 1 simultaneously. If we had a fourth condition such as "top of the stack is a noun" alongside the existing ones, both could be true at once, and the feature vector would carry 1s in both slots. Every feature is checked at every step; there is no guarantee of a single 1.
A practical doubt followed: what do these conditions look like inside a real program?
Q: In a real system we cannot literally pass "the stack is empty" to a program. How does the feature vector actually look in practice? A: These conditions are the standard features of arc-eager parsing. If you use machine learning — logistic regression, SVM, and similar — you do feature engineering and hand-build these conditions. If you use deep learning, the network learns the feature representations itself from the training data. Either way, the stack-and-buffer conditions are the conventional feature set for this algorithm.
The next doubt was about scale: one sentence seems like very little training.
Q: We used one sentence here, so we get one iteration of updates. In practice, do we use many sentences? A: Yes. One training sentence is just one example. In practice you collect many sentences, run arc-eager on each to get the gold transition sequences, and learn the weights across all of them. It is exactly like gradient descent: you can update the weights after every training example (stochastic) or after the whole batch (batch), whichever you choose.
An observation from a student linked the step-by-step nature of parsing to sequence models.
Q: The algorithm is sequential, step by step, like an RNN. Would an RNN be a better fit? A: That is a good observation. Parsing is inherently sequential — each operation depends on the previous configuration — and we will look at neural network algorithms for parsing in the next session on neural parsing approaches, where this question gets a proper answer.
The following question unpicked the shape of the feature vector: 12 values but one dot product.
Q: The feature vector has 12 values in one row. When we multiply it with the weights we get one value. Then why do we have multiple values for argmax? A: Because the dot product is computed per class. Multiplying the weight vector with the left-arc feature vector gives one scalar; with the right-arc vector, another; with shift, another; with reduce, another. You get four scalars, one per class, and argmax is the largest of the four. The 12-entry row is just the four class blocks written together; each class still contributes one scalar score.
The oracle came up next — where the "correct answer" of the update comes from.
Q: Is the oracle (optimal transition) predefined? Is it used as the true value for the weight update, and does the next step use another optimal transition? A: Yes on both counts. The gold transition for each step comes from the oracle — the arc-eager run on the training data, which is what "oracle" means here. The first step's gold transition for this sentence is shift; the next step's gold transition is a different one, whatever the arc-eager run produces for that configuration. The gold sequence for the whole sentence is available in the training data, because weight learning always happens on labeled training data — the same requirement you have for neural networks, transformers, everywhere.
Finally, the class asked directly what to expect in the exam.
Q: Can we expect a numerical question on the exam? A: Yes, two kinds. First: given a sentence and its gold dependency picture, write the arc-eager transitions — the four operations — all the way to the end of the sentence. Second: a weight-learning problem like this one — given the conditions and the gold standard values, define the feature vector and the initial weight vector, compute the scores, take the argmax, and update the weights. Only one full iteration is expected; the next iteration will not be asked.
Pitfalls.
- Forgetting that the feature vector is written per class: the 12-entry row is four blocks of three, and each class scores only its own block — the dot product for left arc never touches the shift block.
- Reversing the update sign: the rule is plus the gold features and minus the predicted features; the reverse would reward the mistake and punish the correct move.
- Expecting exactly one 1 in the feature vector: with richer feature sets several conditions can be true at once.
- Thinking one sentence trains the parser: one sentence is one example; learning runs over the whole treebank, exactly like gradient descent over many batches.
Real-world & domain connection. This pipeline — replay gold trees from a treebank into transition sequences, then learn a classifier that picks the next operation — is how production transition-based parsers (the malt parser and its descendants) are trained. The same feature–label pattern underlies statistical parsing generally, and the neural parsers of later sessions replace the hand-built conditions with learned representations while keeping this training loop intact.
Exam note: Expect a numerical on weight learning: given the conditions (features) and the gold standard (oracle) values, define the feature vector and the initial weight vector, compute the per-class dot products, find the argmax, and apply the weight update . Only the first full iteration is asked; the follow-up iterations will not be on the exam.
Recap. A treebank sentence plus its gold graph is converted, by replaying the arc-eager transitions, into a sequence of configurations and correct operations; the parser learns a weight vector that scores each operation as a dot product of features, and at test time it applies the highest-scoring operation at every step until the buffer is empty. The next section looks at the second family — graph-based parsing, which picks the best whole tree instead of one operation at a time.
10.5 Graph-Based Dependency Parsing
Hook. The transition-based parser decides one relation at a time and never changes its mind. What if a parser could instead see every possible relation between every pair of words, give each a score, and then pick the best whole tree at once? That is graph-based parsing — like drawing the most efficient road network across a country: score every possible road, then keep the best connected network that links every city with no loops and exactly one entry point per city.
10.5.1 Sentences as Weighted Graphs
The second family of algorithms takes a different view: treat the sentence as a graph and search for the best tree. As before, the words are the vertices and the relations are the arcs. Since we need to know which word is the head, the graphs are directed — digraphs, where an arc points from the head to the dependent. The word multi-digraph appears here because at the start we do not know what relations exist: arcs could run in any direction between any pair of words, and multiple different relations can hold at once.
This idea of several simultaneous relations is the same intuition behind multi-head attention in transformers: different attention heads capture different kinds of relationships (one head might track part-of-speech-style relations, another verb–argument structure, another something like "capital of city"). We will see the transformer architecture properly in the next session on contextual word embeddings. For now, graph-based dependency parsing focuses on a single directed relation between two words.
Each sentence has a single root — the head word of the whole sentence. The root has only outgoing edges to all the other words; every other node may have edges to and from every other node. So with words there are candidate arcs leaving the root, plus candidate arcs between all the remaining pairs, and initially we do not know which ones are correct.
The search uses the idea of a weighted spanning tree from network theory. Every candidate edge has a weight learned from the training data. For any tree, we compute the sum of its edge weights:
where is the weight of the edge from word to word , and is a spanning tree over the words. The tree with the maximum total weight — the argmax over all candidate trees — is taken to be the correct set of relations among the words.
A spanning tree touches every vertex, has no loops, and gives every word exactly one incoming arc (the root none) — so a spanning tree and a valid dependency tree are the same object. The maximum spanning tree (MST) is the one with the highest total weight, and it is the parse the algorithm returns.
| Transition-based (arc-eager) | Graph-based | |
|---|---|---|
| Decision style | Local: one operation per step, never revised | Global: choose the best whole tree at once |
| Search | A single left-to-right run over the sentence | Maximum spanning tree over all candidate arcs |
| Typical cost | Linear in sentence length | Quadratic in sentence length (dense graphs) |
| Projective only? | Yes — crossing relations cannot be drawn | No — crossing relations can be recovered |
| Error behavior | Early mistakes can cascade | Errors spread across edge scores; no single irreversible step |
10.5.2 Chu-Liu-Edmonds Algorithm
Finding the maximum spanning tree could be done by enumerating candidates, but the standard method is the Chu-Liu-Edmonds algorithm, named after the researchers (Chu, Liu, and Edmonds) who proposed it. It is a greedy maximum spanning tree algorithm, and it is simple — the only complication is what to do when the greedy choices produce a cycle.
The greedy rule: we know the single head constraint — exactly one incoming edge per word — so for every node we independently select the incoming edge with the maximum weight:
If the resulting collection of best-incoming edges contains no cycle, we are done: that is the parse tree.
The algorithm runs in four steps: (1) greedy selection — for every word, keep the incoming arc with the highest weight; (2) check — if the kept arcs contain no cycle, they are already the maximum spanning tree, so stop; (3) contraction — if a cycle appears, collapse the words of the cycle into one temporary vertex and recompute the incoming weights as path sums through the cycle; (4) unpacking — repeat the selection on the contracted graph, then expand the temporary vertex back into the original words, keeping the winning path.
Cost. For a sentence of words the candidate graph is dense — every word may relate to every other word — and the Chu-Liu-Edmonds algorithm runs in time on such a graph: one pass to pick the best incoming arc per vertex, plus one pass for each cycle contraction. That is slower than the linear transition-based run, but the search is global: the answer is the mathematically best tree, not the first tree reached.
10.5.3 Worked Example: "John saw Mary" — the Greedy Step
Greedy maximum-incoming selection for John saw Mary. Use the same sentence with edge weights learned from the training data (how those weights are learned comes next session — for now they are given). For each word, list the candidate incoming edges and pick the maximum:
- John: incoming candidates root → John (10), saw → John (20), Mary → John (0). Keep saw → John (20); discard the other two.
- saw: incoming candidates John → saw (30), Mary → saw (11), root → saw (9). Keep John → saw (30); discard the others.
- Mary: incoming candidates saw → Mary (30), root → Mary (3), John → Mary (9). Keep saw → Mary (30); discard the others.
The greedy selection leaves three edges: John → saw (30), saw → John (20), saw → Mary (30). Two of them, John → saw and saw → John, form a cycle between John and saw: John is the head of saw and saw is the head of John at the same time, which violates the acyclic condition.
Sense-check. Every word kept the heaviest incoming arc it could find, and each word has exactly one incoming edge — the single-head constraint is satisfied — but the acyclic condition is broken, so the greedy result is not yet a tree and the algorithm has more work to do.
If the greedy step had produced a tree, the algorithm would end right there. For instance, if the weight of root → saw had been 35 instead of 10, then saw's best incoming edge would be root → saw (35) instead of John → saw (30), and the greedy result — root → saw (35), saw → John (30), saw → Mary (30) — would already be a valid tree with the verb as root. Cycles only trigger extra work, and with well-learned weights they should be rare, because it is the learned edge weights that determine whether a cycle forms at all.
One caution about the numbers in the source figure: the per-edge weights shift between the greedy phase and the cycle phase — for example saw → John appears as 20 here and as 30 during cycle removal — and the class acknowledged that the figure carries a typo from the book. The four path sums computed in the next step (40, 29, 31, 30) and the final tree follow the numbers exactly as presented in class, so those are the numbers to use and to expect on the exam.
10.5.4 Breaking Cycles: Contraction and Expansion
Cycle contraction and expansion for the John–saw cycle. When a cycle appears, Chu-Liu-Edmonds breaks it in two steps: contract and expand.
Contract. Combine the two words of the cycle — John and saw — into one temporary vertex . This is only an intermediate step; the two words are separated again at the end. Because the vertex is now one word, the incoming edge weights must be recomputed as path sums through the cycle: an outside word reaches the combined vertex by one edge into the cycle plus one edge inside the cycle. The four incoming paths are:
The path going out of the cycle — saw → Mary (30) — is untouched: it involves no cycle, so it stays. Individual paths through the cycle can no longer be taken; with the combined vertex, only the total path sums exist.
Re-greedy. Now apply the same rule to the contracted graph: only one incoming edge is allowed for , so keep the maximum of {40, 29, 31, 30} = 40, and discard the other three.
Expand. The combined vertex is not a real word, so split the 40 back into its original pieces: root → saw (10) and saw → John (30). The final tree is:
Reading it back: the root is the head word, John is the subject of saw (a left arc), and Mary is the object (a right arc).
Sense-check. The final tree is connected, acyclic, and single-headed, and its total weight 10 + 30 + 30 = 70 beats every alternative — the runner-up, rooted at John, sums to 9 + 30 + 30 = 69. The contraction turned the cycle problem into an ordinary one-arc-per-word choice, and the expansion restored the original words.
The four path sums 40, 29, 31, 30 and the final tree above follow the numbers exactly as stated in class. One caution: the source figure contains a typo in an edge weight, acknowledged in class as carried over from the book — saw → John appears as 20 in the greedy figure but as 30 in the path sums and the final tree. Keep the numbers as stated here; they are the ones used for the exam.
That is the entire algorithm: greedy maximum-incoming selection; if a cycle appears, contract the cycle words, recompute the incoming path sums, re-select greedily, and expand back. Multiple cycles would be handled the same way — treat each cycle as a single word and recompute — though multiple cycles are unlikely when the edge weights are learned properly.
10.5.5 Student Questions and Answers
Q: Where does the 40 come from? A: It is a path sum through the combined word: root → saw (10) plus saw → John (30). Since John and saw are treated as one word , the two edges combine into one incoming edge of weight 10 + 30 = 40.
A second student asked how the other incoming sums arise.
Q: How does the 31 arise? A: The same way, from the Mary side: Mary → saw (11) plus saw → John (20) gives 31. And the other paths are root → John (9) + John → saw (20) = 29, and Mary → John (0) + John → saw (30) = 30.
The next doubt was about why the two-edge paths must be taken together at all.
Q: Why do we take Mary → saw and saw → John together, rather than individual edges? A: Because once John and saw are combined into a single node, you cannot take independent paths anymore — the node is one word, so its incoming weight is the total of the two-edge path. We add 11 and 20 for that path, and 0 and 30 for the other.
Another student asked what the final tree actually says about the sentence.
Q: What does the final tree actually mean? A: It shows the head word and the relations. The root arrow tells us which word is the head of the whole sentence; the left arc to John says John is the subject; the right arc to Mary says Mary is the object. Even a complicated sentence like I saw a girl with a telescope can be captured this way — the same machinery draws whichever attachment reading the weights support.
The last question was about whether cycles can pile up.
Q: What if multiple cycles form, or a cycle that also has incoming relations? A: You solve each the same way: treat that cycle as a single word and recompute its incoming weights, exactly as we did for John and saw. Multiple cycles are themselves very unlikely — cycles appear when the weight learning is not proper. If the edge weights are learned well from the training data, cycles will be rare. How those edge weights are learned is the next session's topic.
Scope. The algorithm assumes the edge weights are learned from good training data: cycles are a symptom of improper weight learning, and with well-learned weights they are rare. It also assumes a single root with no incoming arc and exactly one incoming arc per word (the single-head constraint). It does not assume projectivity — crossing arcs can be recovered — but the search space is still restricted to trees, so every word must be reachable from the root.
Visual intuition. Picture the contraction step of the example: the two-word cycle is a small ring — John points to saw, saw points back to John — which collapses into one bubble . From outside, four arrows reach the bubble: two from root (weight 40 via saw, 29 via John) and two from Mary (31 via saw, 30 via John). The heaviest, 40, wins; splitting the bubble open again reveals the path root → saw → John, and the ring's other arc (John → saw) is dropped. The takeaway: contraction turns a cycle problem into an ordinary single-incoming-arc choice, and expansion restores the original words.
Pitfalls.
- Treating the greedy result as final when it contains a cycle: a cycle means extra work — contract, re-select, expand — not a finished tree.
- Adding path-sum edges as independent arcs: after expansion, the winning path replaces the individual edges — the final tree contains only original word-to-word arcs.
- Forgetting to unpack the combined vertex: the answer must be a tree over the original words, not over temporary bubbles.
- Expecting cycles when weights are well learned: a cycle usually signals bad edge weights, not a special sentence structure.
Real-world & domain connection. Graph-based dependency parsing is the basis of the MST parser family, trained with global updates that compare the whole predicted tree against the gold tree. The maximum-spanning-tree idea comes from network theory, where it is used to lay out efficient telephone, power, and transport networks; the multi-digraph view — several relations between the same two words — is also the conceptual bridge to multi-head attention in transformers, where different attention heads capture different relation types at once.
Recap. Graph-based parsing scores every candidate arc, keeps the best incoming arc per word, and — when that greedy choice forms a cycle — contracts the cycle into one vertex, recomputes the incoming weights as path sums, re-selects, and expands, ending with the maximum spanning tree of the sentence. The lecture closes with one look ahead: how this multi-relation view connects to contextual embeddings and transformers.
10.6 Looking Ahead: Contextual Word Embeddings and Transformers
10.6.1 Why Transformers Matter
The multi-digraph idea — several different relations holding between words at the same time — is a natural bridge to the next topic: contextual word embeddings and the transformer architecture, including the key, query, and value matrices of the attention mechanism. The class check showed that key-query-value matrices have not been covered in depth yet (a brief mention appeared in the computer vision session on transformers), so they will be developed from scratch. The topic is flagged as a bit involved, but it matters everywhere: transformers are the basic building block of LLMs, generative AI, most modern NLP courses, and agentic AI. Multi-head attention will tie directly back to the idea that multiple relations among words can be captured simultaneously.
In dependency parsing, each arc label — subject, object, modifier — is one kind of relation between two words. Attention heads generalize this picture: instead of one labeled arc per pair of words, the model computes, for every pair, a soft strength for each of several relation types at the same time, and all of them coexist inside the network rather than competing for a single tree. That is the bridge: a dependency tree keeps one chosen relation per pair, the multi-digraph keeps several, and attention keeps several weighted ones.
This lecture's two parsing families are also a preview of two learning styles that return in transformer models: the step-by-step scoring of a classifier inside the transition-based parser, and the global optimization over a structure behind the maximum spanning tree. Both styles reappear when we study how attention is trained and used.
Exam Guidance Summary
Both numerical questions below come straight from the worked examples — reread the traces before the exam.
- Expect a numerical on arc-eager parsing. Given a sentence and its gold dependency picture, produce the sequence of transitions — left arc, right arc, reduce, shift — from the initial configuration to the end of the sentence (buffer empty). The full trace of He sent her a letter . above is the template: every operation, every stack and buffer update, every arc added.
- Expect a numerical on weight learning. Given the conditions (features) and the gold standard (oracle) values, define the feature vector and the initial weight vector, compute the per-class dot products, find the argmax, and apply the weight update . Only the first iteration is asked; the follow-up iterations will not be on the exam.
- Scope: the malt parser (arc-eager) transitions only. Other parsing algorithms in Jurafsky and Martin are not required for the exam; the four operations covered here are the focus.
- The weight-learning example was flagged in class as dense — if it feels heavy, that is expected. Go back through the worked example slowly: feature vector → dot products → argmax → update, one step at a time.
- Review the material after the session; questions about the deterministic part are welcome at the start of the next session.
The graph-based worked example follows the same pattern as the deterministic one: greedy selection, cycle contraction with path sums, expansion. Practise writing the transition sequence and the weight update with a fresh sentence and a fresh gold picture — the mechanics are the same every time.
Key Industry Applications
- Agentic AI and modern NLP apps: dependency parsing is used across current AI applications, from question answering to conversational AI to machine translation. Agents that read instructions or queries need the same word relations to act on them, which makes this a practical, widely used technique.
- Question answering: you need to know which words the question binds together — which relations hold among them — before you can answer it. An attachment error changes which entity the question asks about.
- Conversational AI: tracking what modifies what in a user's utterance is part of understanding it; a wrong attachment produces the wrong intent.
- Machine translation: the dependency relations carry the sentence structure that has to survive translation; many MT systems parse the source into dependencies before generating the target sentence.
- Treebanks and training data: human-labeled resources like the Penn Treebank feed the arc-eager transition generation, which produces the feature–label pairs for the parsing classifier — the same pattern as training data generation in statistical parsing.
- Parsing classifiers: the deterministic parser is trained as a four-class classifier (logistic regression/SVM-style feature engineering for ML; learned features for deep learning), and the graph-based parser searches for the maximum-weight spanning tree, a network-theory idea applied to grammar.
- Transformers and multi-head attention: the multi-digraph view of many simultaneous word relations prefigures multi-head attention in transformers, the building block of LLMs, generative AI, and agentic AI — covered in the next session on contextual word embeddings.
- Named references: Jurafsky and Martin (Speech and Language Processing; the textbook and the Stanford NLP course material), the NPTEL course notes for the weight-learning example, the Penn Treebank, the malt parser (arc-eager) algorithm, and the Chu-Liu-Edmonds maximum spanning tree algorithm.
NLP Lecture 10 notes · Dependency Parsing
Sections Breakdown
Why word relations carry meaning, phrase structure versus dependency parsing, and the ambiguity problem.
Head words and roots, graph notation for dependencies, the conditions on valid dependency graphs, and relation labels.
Parser configuration, the left arc, right arc, reduce, and shift transitions, the worked trace of 'He sent her a letter.', and student Q&A.
Turning gold treebank graphs into training transitions, the perceptron-style weight update, the 'John saw Mary' worked example, and student Q&A.
Sentences as weighted graphs, the Chu-Liu-Edmonds algorithm, contraction and expansion to break cycles, and student Q&A.
How the multi-digraph view of dependencies bridges to multi-head attention and transformer architecture.
Expect a numerical on arc-eager transitions and a numerical on weight learning (first iteration only); only the malt parser's four transitions are in scope.
Dependency parsing powers question answering, conversational AI, machine translation, and agentic AI; treebanks feed the parsing classifiers, and the multi-digraph view prefigures multi-head attention.
Exam Revision Notes
Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.
From Phrase Structure to Dependency Parsing
Must-know: In dependency parsing the output is a set of directed relations between words, not a tree of phrase labels; the relations among words, not word order alone, carry the meaning.
⚠️ Top pitfall: Assuming the two readings of an ambiguous sentence differ in grammar; both readings are grammatically valid, only the relations differ.
Self-check: Why does the sentence 'I saw a girl with a telescope' have two interpretations?
Connects to: 10.2
Head Words, Roots, and Dependency Graphs
Must-know: A valid dependency tree is connected, acyclic, and single-headed; projectivity (no crossing arrows) is required by the arc-eager parser but not by the graph-based algorithm.
⚠️ Top pitfall: Drawing arrows from dependent to head: arrows always run from the head word to the dependent word.
Self-check: Which three conditions must every valid dependency graph satisfy?
Connects to: 10.1, 10.3
Deterministic (Arc-Eager) Parsing: The Four Transitions
Must-know: Left arc removes the last stack word; right arc adds the first buffer word to the stack and keeps the head; shift moves the first buffer word onto the stack; reduce removes the last stack word with no arc. The oracle checks left arc, right arc, reduce, then shift.
⚠️ Top pitfall: Removing the head after a right arc: the stack word that just became a head may govern more words still in the buffer, so it must stay.
Self-check: In the trace of 'He sent her a letter .', why is C7 a reduce instead of a right arc?
Connects to: 10.2, 10.4
Training the Deterministic Parser: Data Generation and Weight Learning
Must-know: Score each operation as w^T * phi(t), pick the argmax, and update w_new = w_old + phi(gold) - phi(predicted); only the first iteration is asked on the exam.
⚠️ Top pitfall: Reversing the update sign: the update adds the gold features and subtracts the predicted features; the reverse would reward the mistake.
Self-check: After the first update in 'John saw Mary', what are the left-arc and shift first-slot weights?
Connects to: 10.3, 10.5
Graph-Based Dependency Parsing
Must-know: Chu-Liu-Edmonds: greedy maximum-incoming selection; if a cycle appears, contract the cycle words, recompute incoming weights as path sums, re-select greedily, and expand back into the original words.
⚠️ Top pitfall: Treating the greedy result as final when it contains a cycle: a cycle means contract, re-select, and expand, not a finished tree.
Self-check: Where does the weight 40 for the combined node W_JS come from in the 'John saw Mary' example?
Connects to: 10.3, 10.6
Looking Ahead: Contextual Word Embeddings and Transformers
Must-know: Multi-head attention captures several kinds of relations between words at once, generalizing the multi-digraph idea from graph-based dependency parsing.
Self-check: How does multi-head attention relate to the multi-digraph view of dependencies?
Connects to: 10.5
Exam Guidance Summary
Must-know: Two numericals: arc-eager transitions for a given sentence and gold picture, and the weight-learning update for the first iteration only.
⚠️ Top pitfall: Going past the first iteration in the weight-learning numerical: only one full iteration is asked.
Self-check: Which two numerical question types can be expected on the exam?
Connects to: 10.3, 10.4
Key Industry Applications
Must-know: Dependency parsing is used in QA, conversational AI, MT, and agentic AI; the Penn Treebank feeds transition generation, and the multi-digraph idea prefigures multi-head attention.
Self-check: Which human-labeled resource feeds arc-eager transition generation for training parsing classifiers?
Connects to: 10.3, 10.4, 10.5, 10.6
Was this lecture useful?
BitsNotes AI Assistant
Subject Notes AssistantConfigure AI Chat
Choose how to access the chatbotSigned in as
Powered by BitsNotes — 20 messages per day. No API key needed. Want unlimited access? Use "Bring Your Own Key" mode.
Sign in to use AI Chat
Get 20 free AI messages per day to ask questions about your lecture notes. Sign in with Google or GitHub — it takes 5 seconds.
Sign In to BitsNotesSwitch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.