Address Extraction for Voice Orders: From Speech to Dispatchable Fields

The first hard problem in phone orders is not understanding Chinese. It is turning a spoken description into an address field that dispatch can actually use.

Why the address matters

A fleet order can tolerate an incomplete note. It can rarely tolerate the wrong pickup point. The address drives dispatch decisions, driver travel time, and passenger experience, so it must be structured, comparable, and reviewable rather than a block of free text.

The challenge with phone audio is that one place has many descriptions, and one description may point to different places. If the system only transcribes literally, it hands the judgement straight back to a person.

Four kinds of spoken address variation

• Homophones and near-homophones: similar-sounding road names and section numbers are easily confused over the phone.
• Abbreviations and local names: callers often use a local shorthand or landmark instead of a full street address.
• Route descriptions: “turn right at the second junction after the bridge” requires understanding relative order, not just string matching.
• Relative locations: “the rear entrance of the station” or “opposite the convenience store” may lack an administrative area or street number.

Address handling therefore cannot rely on string comparison alone. The system needs to identify address spans, normalise them, compare candidates, and send uncertainty to a human.

A practical pipeline

1. Audio pre-processing: handle volume differences, noise, and sample formats to reduce downstream variation.
2. Speech-to-text: produce a transcript with timestamps that map back to the original audio.
3. Address span candidates: identify likely location phrases instead of assuming the whole utterance is an address.
4. Normalisation and matching: handle city, district, road, section, lane, and alley levels, then match against available address data.
5. Confidence and human review: flag low-confidence, conflicting, or incomplete results for confirmation rather than creating an order immediately.

The point is to leave evidence at every stage. When a person corrects an address, the team can tell whether the problem sits in recognition, extraction, normalisation, or the reference data.

Evaluating address extraction

Evaluation should not stop at a single overall score. Practical signals include:

• Field-level correctness: were pickup, drop-off, time, and passenger count separated correctly?
• Review rate and reasons: unclear audio, address variation, or missing reference data?
• Correction types: which field did a person change, and what does that reveal about the pipeline?
• Performance by scenario: dense urban trips, remote locations, and noisy calls should be observed separately.

These signals need a fixed test set and manual annotation so versions can be compared. Without a baseline, it is impossible to know whether a change helped.

Summary

Address extraction is not a single model call. It is a pipeline of pre-processing, span detection, normalisation, matching, and review. Separating the stages makes failures addressable and makes it possible to describe honestly what the system can currently handle.