Skip to main content

9 docs tagged with "Staged pipeline"

The six-stage runtime pipeline and the Knowledge Ladder decomposition.

View all tags

A walkthrough — NY-NY Steakhouse, Houston, TX

The knowledge ladder explains why the v0.5.0 pipeline grew two new information layers (Stage 2.7 phrase grouper, expanded Stage 5 reconcile). This article walks through what they actually do on one concrete input, end-to-end.

CRF decoder

A Conditional Random Field (CRF) is a structured-prediction layer that finds the best whole-sequence label assignment instead of picking each token's label independently. Mailwoman's model card carries crfatinference a Viterbi search over a frozen, hand-coded validity table, with no learned transition scores anywhere in the loop. This page explains what ships, and how it got here.

How it works now

Mailwoman runs addresses through a staged pipeline. Each stage adds one kind of knowledge the stages below it cannot easily derive. Two models are involved, not one: a small coarse-placer that guesses the country up front (Stage 1.5), and the main neural classifier that labels the tokens (Stage 3). Rule classifiers run alongside the neural classifier, and a policy registry decides whose vote wins for each address component. Outside knowledge — postcodes, the gazetteer — reaches the model as soft hints called anchors, which inform a decision but never override it.

The knowledge ladder

The staged pipeline is a contract for decomposition by what each layer knows. Every stage is the rightful home of a particular kind of information; pushing work to the wrong stage produces fragile systems that try to learn things from data that they could have looked up, or look up things that they could have learned. This article catalogues the layers, what each one knows, and the two layers we don't ship yet but should.

The pipeline contract

You don't have to take Mailwoman's pipeline as-is. The runtime coordinator (createRuntimePipeline) accepts each pipeline stage as an injectable function or interface; an integrator can swap any of them for a custom implementation without forking the core.

The staged pipeline

Reading Addresses that break geocoders makes one thing obvious: no single model handles every failure class well. Different failures want different fixes. Some want preprocessing rules, some want a small classifier, some want a transformer, some want a resolver that returns candidates instead of pretending to be sure.

The tokenization tautology

Traditional address parsers split the input into tokens, classify each token independently, then try to reassemble the pieces into a coherent parse. This sequence contains a structural circularity: you cannot group tokens correctly without knowing their types, and you cannot type them correctly without knowing their groups. The traditional architecture resolves this with heuristics, exceptions, and solver post-processing. The exception pile grows without bound.

What is a concordance?

In Mailwoman's architecture, a concordance is the resolver's answer to the question: "Do these parsed components form a coherent place in the real world?" It is the mechanism that prevents the parser from emitting a parse that is structurally valid but geographically impossible — like "Paris, Texas" labelled as "Paris, Île-de-France" or "NY-NY Steakhouse, Houston TX" with "NY" tagged as a region.