How AI Converts Chinese Names to Pinyin

Ask a model to convert 王小明 to pinyin and you will get Wang Xiaoming. Ask a second time and you may get Wáng Xiǎomíng. Both are correct pinyin. They are not interchangeable, and the difference between them survives or dies depending on parts of your system that have nothing to do with the model.

Two different outputs, one request

Hanyu Pinyin, standardised in China as GB/T 16159 and internationally as ISO 7098, is a tonal orthography. Every syllable carries one of four tones or is neutral, and the tone is written as a diacritic over the main vowel: ā á ǎ à. The tone is not decoration. It is part of the syllable in the same way the vowel is, and dropping it merges syllables that are as different as “bat” and “bet”. Toneless ma stands for at least five common words.

Real systems nonetheless want the toneless form most of the time. Passports, airline manifests, bank records, email addresses and most database columns are ASCII, and the toneless form is what a Chinese passport prints. So the two outputs serve different jobs: tone-marked pinyin is for anything a learner or a linguist reads, toneless pinyin is for anything a machine stores or a border officer compares. A model asked for “pinyin” with no further instruction has to guess which of those you meant, and it will guess differently for a name in a sentence than for a name in a list.

There is also a third form you will meet without asking for it: the numeric convention, Wang2 Xiao3ming2, where the tone is a digit after the syllable. It exists because it is ASCII-safe and reversible, it is common in dictionaries and in older corpora, and a model will sometimes produce it when you ask for tones and it has decided diacritics are unavailable.

Why the tone marks disappear

The usual explanation is that the model “dropped” them. It often did not. There are three separate places a tone mark can be lost, and they need different fixes.

• The model chose the toneless form. The overwhelming majority of pinyin in the training data is toneless, because that is what appears in names, addresses, and product listings. Absent an instruction, the toneless form is the high-probability continuation. This is a prompting problem and the fix is in the prompt.
• Your storage layer normalised them away. A tone mark can be encoded two ways: ǎ as the single precomposed code point U+01CE, or as plain a followed by the combining caron U+030C. Both render identically. A column with a stripping normaliser in front of it, an ASCII-folding search analyser, or a latin1 connection charset will silently keep the base letter and discard the combining mark from the second form while mangling the first. See the difference between combining and precomposed characters.
• The comparison stripped them. Output can be perfect and still fail a test that compares against a toneless expectation. This is the one that wastes the most time, because the data is right and the assertion is wrong.

Distinguish them before changing the prompt: log the raw bytes of one output, not the rendered string. If U+01CE or U+030C is present in the response body, the model did its job and the loss is downstream.

Surnames a character lookup gets wrong

Chinese has polyphonic characters — one character, several readings — and a painful number of them are surnames whose surname reading is not their common reading. A naive per-character mapping picks the frequent reading and is wrong for the person.

• 单 is dān as the word for “single” and Shàn as a surname.
• 解 is jiě as “to untie” and Xiè as a surname.
• 区 is qū as “district” and Ōu as a surname.
• 仇 is chóu as “enmity” and Qiú as a surname.
• 查 is chá as “to check” and Zhā as a surname.
• 朴 is pǔ in ordinary use and Piáo as the surname — the character used for the Korean surname Park.

A language model is actually better at these than a lookup table, because it has the context that a lookup table does not: told explicitly that the string is a personal name and that the first character is the family name, it will usually take the surname reading. Told nothing, it treats the string as text and may not. That is the single highest-value sentence you can add to the prompt, and it costs nothing.

Two more conventions decide whether the output is usable. Capitalisation in the standard is per word, not per syllable: the given name is one word, so Wang Xiaoming is correct and Wang Xiao Ming is not, though the hyphenated Wang Xiao-ming appears in older material. And the apostrophe rule matters more than it looks: pinyin inserts an apostrophe before a syllable beginning with a, o or e where the boundary would otherwise be ambiguous, which is the entire difference between Xi’an (two syllables, the city) and Xian (one syllable, a different word).

A prompt that pins the format

The instruction has to name the form, the tone convention, the capitalisation and the ordering, and it has to say that the input is a name. Anything left unsaid is re-decided per row.

SYSTEM
You convert Chinese personal names to Hanyu Pinyin (GB/T 16159).

Rules, applied to every input without exception:
- The first character is the family name. Use the surname reading
  where a character has one (单 Shan, 解 Xie, 区 Ou, 仇 Qiu, 查 Zha).
- Write tone marks as diacritics on the vowel: a a a a. Never use
  tone numbers. Never omit a tone.
- Capitalise the family name and the given name as two words.
  The given name is one word, not two.
- Insert an apostrophe before a syllable starting with a, o or e
  when the syllable boundary is ambiguous.
- Output JSON only: an array of
  ["hanzi", "toned", "toneless"] triples, in input order.

USER
王小明
单田芳
吕欣怡

Asking for both forms in one response is the part that saves work later. You get the toneless string for your ASCII column and the toned string for display from a single call, and because the model produced them together they cannot disagree about which syllable was read — which they will if you make two calls and one of them takes a different surname reading.

1. Send one name you already know the answer to, and read the raw response body rather than the rendered output. Confirm the diacritics arrived as bytes.
2. Send a batch of ten containing at least two polyphonic surnames from the list above. Those are the rows that tell you whether the surname instruction is being honoured.
3. Write the toneless field to your ASCII column and the toned field to a utf8mb4 or equivalent Unicode column. Do not derive one from the other in the database.
4. Normalise both to NFC before storing, so a later equality comparison does not fail against a combining-mark form. See the difference between NFC and NFKC before choosing which.
5. Keep the original characters. They are the only canonical key; every Latin form is derived and lossy.

Checking the output without reading Chinese

You can verify a great deal mechanically. Strip the tone marks from the toned field and compare against the toneless field — they must be identical, and a mismatch means the model produced two different readings in one response. Check that every syllable in the toneless field is a member of the finite set of legal pinyin syllables; there are roughly four hundred of them without tone, the list is fixed, and anything outside it is a hallucinated syllable. Check that the family name field is one syllable, or two for the compound surnames such as Ouyang and Sima.

One thing you cannot check mechanically is ü. The vowel in lǚ (the surname 吕) is a different vowel from the one in lù (陆), and ASCII-only systems render it inconsistently — lu, lv and lyu all appear on real documents for the same surname. Decide which one your system uses and state it in the prompt, because the model has seen all three and will not be consistent on its own.

If the same names also need to be counted or budgeted for, the character-to-token relationship for Chinese is its own subject — what Chinese text actually costs in tokens covers why a short name is not a cheap one.