Vietnamese Generative AI Accuracy — What Breaks Is Preprocessing, Not the Model

When a factory tells us that Vietnamese generative AI is not accurate enough, the conversation almost always arrives framed as a model problem. Everything works as expected in Japanese or English, and only Vietnamese underperforms. Most sites respond by switching models, and most of the time nothing improves. What is broken is not the model but the character and word handling that sits upstream of it. This article splits Vietnamese processing into four layers and sets out, use case by use case, which layer you have to fix to get which improvement.

What Is Actually Happening When People Say Vietnamese Generative AI Is Not Accurate

The first reports that come back from a Vietnamese site usually take one of three shapes.

• A search over internal documents fails to return a document that is definitely there. Asking the same question in Japanese returns it
• Aggregating Vietnamese daily reports or inspection records produces totals that do not match what the floor believes. Records for one machine have split into two
• Translation and summarization run, but the output is stiff, proper nouns change, and it does not use the phrasing the company actually uses

None of these fail all the time. They fail some of the time, and that is what makes them hard. If something fails every time, you suspect a setting. If it fails intermittently, nobody can write reproduction steps, and a defect without reproduction steps tends to skip root cause analysis and settle on the explanation that the model simply is not good enough.

So the model gets swapped. A newer model, a bigger model, a model that advertises Vietnamese support. The symptom comes back in the same shape. The number of misses may drop slightly, but the documents that were not being found are still not being found.

The reason is simple. The model sits at the very bottom of the pipeline. A string that was corrupted upstream, or a word that was split incorrectly upstream, becomes the model’s input exactly as it is. If the input is broken, any model will stumble in the same place. Switching does not help because nothing was done to the place that needed fixing.

Vietnamese also carries two conditions that never surface when you work in Japanese or English. The first is that strings which look identical but differ internally get mass-produced. The second is that spaces exist, but they are not word boundaries. Both of these happen upstream of the model.

This article splits Vietnamese processing into four layers — character, word, token, and meaning. The point of splitting it this way is to work out which symptom belongs to which layer, so you can decide what to fix first. Get the order wrong and most of your budget and calendar gets absorbed by the last layer.

Vietnamese Processing Splits into Four Layers — Character, Word, Token, Meaning

A Vietnamese document passes through four layers before it reaches a generative model. From upstream down, they are the character layer, the word layer, the token layer, and the meaning layer.

These four layers behave differently from one another in practice.

The further upstream, the longer a single fix keeps paying off. Layer 1 normalization, once you put it at the entrance, automatically applies to every document that arrives afterwards. Layer 3 model usage fees, by contrast, keep accruing for as long as you keep using the system.

The further upstream, the wider the blast radius when it breaks. Break Layer 1 and search, aggregation, and summarization all go wrong at once. A weak Layer 4 affects only the quality of the generated text.

And the further upstream, the more the symptom looks like the model’s fault. Layer 1 and Layer 2 failures show up intermittently, so the cause never gets pinned down and responsibility gets pushed downstream.

Before going further, it is worth noting how this four-layer model differs when applied to Thai. In Thai, the problem was that there are no spaces between words at all, so the machine has to invent boundaries that do not exist. Vietnamese is the opposite. The spaces are there. But those spaces mark syllable boundaries, not word boundaries. Vietnamese orthography puts spaces between syllables rather than between words, so even when several syllables combine to form a single word, the string itself is broken up by spaces. What the machine has to do, then, is not create boundaries but decide which of the existing boundaries are word boundaries and which are internal to a word, and regroup accordingly. The same four-layer breakdown applied to Thai is set out in where things break when Thai generative AI accuracy falls short. The layer structure is shared, but the work you do in Layer 2 runs in the opposite direction.

That difference matters in implementation. In Thai the symptoms are over-splitting and under-splitting. In Vietnamese the starting point is treating the spaces themselves as word delimiters. Splitting on whitespace runs fine in any language, so nobody thinks to question it. This is the single biggest reason root cause analysis takes longer in Vietnamese than it should.

Layer 1 Character — The Vietnamese That Looks the Same but Is Not

There is only one job in Layer 1. Make strings that mean the same thing resolve to the same byte sequence.

Vietnamese is written in the Latin alphabet. That fact breeds complacency, because it invites the assumption that Latin script can be handled the way English is. But Vietnamese letters carry marks indicating vowel quality and marks indicating tone, and marked characters have more than one internal representation in a computer.

Unicode has the concept of normalization forms. NFC (Normalization Form C, canonical composition) replaces decomposed sequences with precomposed characters represented by a single code point. NFD (Normalization Form D, canonical decomposition) does the reverse, breaking precomposed characters into a base character followed by combining marks. Vietnamese characters carrying tone marks decompose into multiple code points under NFD.

This means it is entirely normal for one word that looks completely identical on screen to be stored as NFC in one document and NFD in another. To a human eye they are the same string. To a computer they are different strings.

The VietUnicode FAQ explains what these form differences actually cause. In summary, a combining diacritic can become unintentionally separated from its base character, and if another character is then mistakenly typed into the gap, a word such as tháng ends up displayed as something like than´g. The same FAQ also touches on string length. The single character “ệ” counts as two or three code points under NFD, and always as one under NFC. In other words, a character count changes depending on the storage form.

That property — character counts varying by form — quietly matters in day to day work. Input field length limits, column alignment on forms, chunk length calculations. All of them assume a character count, so once NFC and NFD are mixed, the results stop lining up.

Vietnamese has a further source of variation, namely where the tone mark is placed. The old style places the tone mark nearer the centre of the word, and the new style places it over the main vowel. hóa and hoá, hủy and huỷ. These are the same word, but different strings. Official textbooks use the new style, while everyday writing is said to show a tendency to prefer the old style. Which means that internal documents contain both.

How this looks on the floor. You reconcile the equipment master against Vietnamese daily reports and get no match. The staff member compares the two on screen and sees strings that look exactly the same. From there the conversation turns into “the system’s search is broken” and drifts towards search engine settings or the model. What actually happened is that one side was stored as NFD, or the tone mark sat in the old-style position on one side and the new-style position on the other.

The Layer 1 fix is unglamorous as a feature. Funnel ingestion through a single entrance and always normalize there. Concretely, that means unifying the Unicode normalization form to NFC, settling on either the new style or the old style for tone mark placement, detecting and converting strings that came from legacy encodings, and normalizing fullwidth versus halfwidth and upper versus lower case for alphanumerics. That is all.

What matters is where you put it. If you scatter normalization code across the search side, the aggregation side, and the summarization side, fixing one of them leaves the others out of step. Running it exactly once at the entrance, and agreeing that everything downstream only ever handles normalized strings, makes operations far easier later.

Whether Layer 1 is settled is something you check with a number, not by eye. Count how many distinct strings a word that should be single has fragmented into. As long as that count is still dropping, there is Layer 1 work left to do.

Layer 2 Word — The Spaces Are There, but They Are Not Word Boundaries

This is the most important layer for Vietnamese generative AI.

Vietnamese orthography places spaces between syllables, not between words. And it is common for several syllables to combine into a single word. The word meaning “student”, for example, consists of two syllables and is written with a space between them. To the writer it is one word. To a machine splitting on whitespace it is two units.

Approach this with an English mindset and conclude that splitting on spaces is enough, and the first fault line opens here. Splitting on whitespace throws no error. It runs. But what comes out is syllables, not words. Build your search index in that state, chunk your documents, match your keywords, and evaluate your accuracy, and every one of those operations is now running on syllable units.

In Vietnamese natural language processing, the operation that regroups these syllables into words is called word segmentation. Every system that handles Vietnamese makes this decision somewhere, explicitly or implicitly. Deciding to use the spaces as boundaries as-is is itself one of those decisions.

The problem is that more than one downstream process depends on how you group.

• Search index construction is built on grouped words as its unit
• RAG chunking uses word and sentence boundaries as its cues
• Keyword matching and dictionary lookup compare grouped words against dictionary entries
• Accuracy evaluation also compares against ground truth in grouped units

Change the grouping and all four change at once. Which means that if the grouping is bad, all four break at once. And because they do not break uniformly, the symptom presents as “search hits sometimes and misses sometimes”.

You can confirm how much this layer matters from the model side as well. The README for PhoBERT, published by VinAI Research, carries a note in capital letters stating that input text must already be word-segmented. The original wording is “INPUT TEXT MUST BE ALREADY WORD-SEGMENTED!” PhoBERT’s pre-training data was tone-normalized and word-segmented with VnCoreNLP’s RDRSegmenter, and using the same segmentation tool for downstream tasks is what the project recommends.

This is the practical takeaway. The more a model was purpose-built for Vietnamese, the more it assumes preprocessing. Feed it text that has not been through that preprocessing and you will not see the performance the model actually has. Then someone looks at that result and concludes the model is weak in Vietnamese. What is being evaluated is not the model. It is your own preprocessing.

Where grouping breaks down most easily in documents from a Vietnamese site is on company-specific proper nouns. Equipment names, part names, internal abbreviations, line names. None of these appear in a general dictionary. Words that are not in the dictionary get left as separate syllables, or get incorrectly grouped as a combination of nearby words. Because grouping depends on surrounding context, the same equipment name splits into different units in different documents.

How this looks on the floor. Daily reports for one machine appear as two machines in the aggregate. The staff member reports that a machine they only have one of shows up as two rows. The cause is neither the equipment master nor data entry. It is that the name split into two forms at the moment the document was grouped into words.

The Layer 2 fix is to build a dictionary of company-specific proper nouns and load it into the segmenter. That is less a technical task than an exercise in working through vocabulary alongside local staff. And because it needs an addition every time a machine or part is added, it is never finished in one pass.

How to assemble multilingual knowledge search is also covered in how to approach building factory knowledge search with RAG. When you design a search that includes Vietnamese, deciding up front where Layer 2 gets handled saves a lot of rework. Start by checking whether the query side and the document side are running through different processing.

How to Read Word Segmentation Accuracy Scores — Why the Numbers Change with the Evaluation Data

There are published benchmarks for Vietnamese word segmentation. Looking only at the numbers, this problem appears to be solved already. In practice, there are reasons you cannot read them that way.

Start with the official benchmark. On the VLSP 2013 test set (2120 sentences), RDRsegmenter, the word segmentation module of VnCoreNLP, records 97.90% F1. The current state of the art on the same benchmark is UITws-v1 at 98.06% F1. From those numbers alone you would be tempted to conclude that Vietnamese word segmentation is effectively solved for practical purposes.

Meanwhile, a different benchmark produces markedly different numbers. An independent comparison using the Vietnamese Universal Dependencies Treebank (over 800 sentences) reports underthesea at 80.04%, VnCoreNLP at 78.37%, and PyVi at 57.88%.

Here is the most important caveat, and it goes first. These two sets of numbers come from different evaluation data and cannot be read as a like-for-like comparison. Placing 97.90% next to 78.37% and saying that accuracy drops by 20 points on real data is simply wrong. A different test set means different sentence lengths, a different vocabulary distribution, and a different definition of what counts as correct. These are not numbers showing that the same tool’s performance fell.

There is still value in putting the two sets side by side, because they demonstrate a fact worth knowing: word segmentation accuracy varies substantially depending on the evaluation data. And that fact is exactly what matters in practice.

Three points, to avoid misreading them.

First. A high score on an official benchmark shows a tool’s ceiling, not its performance on your documents. Benchmark test sets are built from general text. The vocabulary distribution differs from what appears in your daily reports and inspection records.

Second. Errors are not evenly distributed. Common words present in the dictionary or the training data get grouped well; words that are absent break. And the important words in internal documents are usually the absent ones. Equipment names, part names, abbreviations, company names. The structural consequence is that the words you most want to get right in your own documents are the ones most likely to fail out of the box. That is why you cannot take a published benchmark figure as your own accuracy.

Third. Which dictionary you have matters more than which tool you choose. The numbers above compare tools against each other, but the difference on your own documents moves far more with the presence or absence of a proper noun dictionary than with the choice of tool. Building the dictionary comes before spending time on tool selection.

The practical conclusion is straightforward. Use the default segmentation as-is and it will fail on your own vocabulary. So add a dictionary. And measure the effect of what you added on your own documents. That is the substance of Layer 2 work.

Layer 3 Token — How General-Purpose Tokenizers Get Along with Vietnamese

Layer 3 is where text gets split into the units the model counts. This layer affects cost and how much fits, more than accuracy itself.

The tokenizers used by general-purpose large language models are built to match the distribution of their training data. A tokenizer built on data dominated by English converts English efficiently into short token sequences. For other languages, a single word tends to decompose into several tokens. Vietnamese uses tone-marked characters heavily, which makes it a language particularly exposed to this effect.

As a concrete figure, GPT-4’s byte-level BPE tokenizer is reported to require 2.5 times as many tokens for Vietnamese as for English. This number needs a note about the citation path, however. The 2.5x figure is what a subsequent paper citing it (arXiv 2606.15044) records as the analysis result of Petrov et al.’s 2023 NeurIPS paper (Language Model Tokenizers Introduce Unfairness Between Languages). This article was not written on the basis of directly checking the table in the Petrov paper itself. When you cite it, pass that path along with the number.

One more thing to keep separate. This 2.5x is “the ratio between Vietnamese and English on a general-purpose GPT tokenizer”. The ratio discussed in the Thai article was “the efficiency difference when the same Thai document is processed by a general-purpose tokenizer versus a Thai-specific tokenizer”, which is an entirely different axis of comparison. Never put a cross-language comparison and a cross-tokenizer comparison in the same table. The moment you do, both numbers lose their meaning.

There are two places where this difference bites in practice.

Billing. On usage-based pricing, token count maps straight to the invoice. For document-heavy use cases, such as reading years of inspection records every day, that ratio becomes a direct difference in running cost.

How much fits in the context. How many pages of Vietnamese document you can put into a given context window changes. In RAG, the documents retrieved by search get handed to the model. Poor token efficiency means fewer documents can be passed. Fewer documents means thinner grounding for the answer. Through that path, Layer 3 does indirectly touch accuracy.

That said, Layer 3 is a multiplier, not a cause. If Layer 2 is broken and search is not retrieving the right documents, packing those documents in efficiently will not improve the answer. Treating tokenizer selection as an optimization to run after upstream is settled is the natural order.

Layer 4 Meaning — Only Now Do You Choose a Model

Layer 4 covers how the string it receives is interpreted and how output is generated. The symptoms that belong here look like this.

• Translations are stiff, overly literal, or do not use the phrasing the company actually uses
• Instructions are ignored. A specified format is not honoured
• Content appears that is not in the source
• Honorifics and levels of politeness are inconsistent. The register is wrong for the audience or the situation

There is a way to tell whether something is a Layer 4 problem. Hand the same input over after a human has cleaned it up. If that fixes it, the problem is upstream. If a human reselecting the retrieved documents makes the answer correct, what is wrong is search on the Layer 2 side. If a human correcting orthographic variation and normalization form mismatches makes it pass, that is Layer 1. Only when it breaks the same way even with human-prepared input does the conversation become a Layer 4 one.

Compare models without doing that separation first, and the conclusion of your comparison becomes untrustworthy. Comparing two models while upstream is still unstable makes it impossible to tell whether a difference came from the models or from which documents happened to be retrieved.

For Vietnamese, this separation needs one extra layer of care. As the previous section showed, some models built for Vietnamese assume word-segmented input. Compare them without running the preprocessing and a model that does not assume preprocessing can post better numbers. That is not a difference in model capability, it is a difference in whether preprocessing was applied. Run the same preprocessing across every model in the comparison, and read each model’s preprocessing requirements before you start. A comparison that ignores either of those two rules can invert its own conclusion.

What actually informs a Layer 4 decision is measured performance on your own evaluation set. Public benchmark rankings are useful for narrowing candidates, but they do not always agree with the ranking on your documents and your tasks.

Where Vietnamese-Capable Models Stand Today — PhoGPT, Viettel, SEA-LION

Here is what can be confirmed about the models investing in Vietnamese. Where something cannot be confirmed, this article says so.

A few notes on the above.

PhoGPT’s parameter count differs between its name and its actual figure. The name is PhoGPT-4B, but what the paper states is 3.7B parameters. Writing only “4B” in an internal comparison document throws the scale comparison with other models slightly off. It looks like a detail, but it matters the moment you line up scale and cost estimates side by side. The vocabulary size of 20480 and context length of 8192 are likewise assumptions worth carrying when you put it next to other models.

Note that the Viettel announcement is media-sourced. The information that a 120 billion parameter model was announced on 4 June 2026 comes from Vietnamese media reports. It has not been confirmed against Viettel’s own technical documentation. This article therefore says nothing about that model’s performance or benchmark position. Hold off on anything beyond the fact that an announcement was made until primary sources appear.

SEA-LION’s ranking is a self-reported claim. The statement that it ranks 5th of 55 models on SEA-HELM and 1st among open models under 200B parameters comes from AI Singapore itself. Because the party providing the benchmark is announcing its own model’s position on it, avoid putting that straight into internal documents as an objective evaluation. Treat it as an entry point for shortlisting candidates, and make the final call on your own evaluation set.

The number of models SEA-HELM evaluates tells you how wide the field is. As of 5 August 2026 it evaluates 61 open-weight and 9 closed-weight models. There are already enough Vietnamese-capable candidates that shortlisting is mandatory. Put the other way round, starting a comparison without criteria for narrowing the field means never finishing it.

What you should settle before ranking is your constraints. Can documents leave the company? Does the model need to run in your own environment? What is the latency requirement? Does the same framework need to handle Japanese and English alongside Vietnamese? Answer those and the field narrows to a handful. Everything beyond that is measurement on your evaluation set.

Which Layer Actually Pays Off, by Use Case

This is the heart of the article. The same complaint that Vietnamese accuracy is poor has a different dominant layer depending on the use case. Work on the wrong layer and you end up having spent money without changing the symptom.

Each of the six use cases in detail follows.

Internal Document Search (RAG) — Layer 2 Dominates

RAG retrieves documents relevant to a question and hands them to a model to answer from. Structurally, there is nothing the model can do about a document that search missed. A document that was not retrieved might as well not exist.

Most of the reasons Vietnamese RAG search misses sit in Layer 2. The grouping applied to the question does not match the grouping applied to the documents. When company-specific proper nouns in particular split into different units on each side, keywords that ought to match do not.

It is worth restating the difference from Thai here. In Thai, the machine had to create boundaries where none existed. In Vietnamese, you have to regroup text that is already space-separated according to a criterion of where one word ends. The direction of the work is reversed, so a design carried over from Thai will not mesh. The default behaviour of splitting on whitespace in particular runs in Vietnamese without raising a single error, and the result is syllable units. Because no error appears, it takes longer to discover than the Thai equivalent.

Layers that pay off are 1 and 2. Align the characters and group the words. Fix this and documents that were being missed start being found. Layer 3 affects how many documents you can pass, which thickens the grounding.

The layer that barely helps is a Layer 4 model swap. Changing the model does not change the search results. The phrasing of the answer changes, and the symptom that the document cannot be found remains.

The layer to start with is Layer 2. Build a dictionary of company-specific proper nouns and run the same segmentation on the query side and the document side. That alone changes the hit rate.

Chatbot — Capture with Layer 2, Answer with Layer 4

An internal enquiry bot straddles two layers at once. The first half is capturing what is being asked, which is affected by Layer 2. The second half is how to answer, which is Layer 4.

The common symptom in Vietnamese chatbots is that the same question asked a different way stops being recognized. Enquiry text is shorter than a daily report, colloquial, and mixed with tone mark input variation. The shorter the sentence, the more directly a grouping failure hits the result. On top of that, input from smartphones sometimes arrives with tone marks dropped entirely, so you need to decide up front how much of that Layer 1 should absorb.

Layers that pay off are 2 and 4. Hold a dictionary of enquiry vocabulary at Layer 2 and shape the answer patterns at Layer 4. The layer that barely helps is Layer 3, because each message is short enough that tokenizer differences do not meaningfully affect either cost or context length. The layer to start with is Layer 2, and specifically collecting vocabulary from the enquiries that actually arrived.

Multilingual chatbots viewed from the cost and process side are covered in what a multilingual chatbot costs and how to roll one out internally. Because the layer that has to be handled differs by language, building that into the design keeps operations stable.

Minutes and Transcription — Layers 1 and 4

For putting Vietnamese meetings into text, speech becomes text first, and summarization and decision extraction ride on top of that.

Layers that pay off are 1 and 4. Straight out of transcription, the text carries orthographic variation. Personal names, equipment names, and company names appear in several spellings within one meeting. In Vietnamese, the presence and position of tone marks are the main source of that variation. Fail to align it at Layer 1 and the downstream summary will treat one person as two, or list one decision as several separate items. Layer 4 affects speaker separation and summary quality.

The layer that barely helps is Layer 3. Layer 2, however, cannot quite be called irrelevant. If the operation involves searching minutes later, Layer 2 starts to matter at that point. Understanding it as “Layer 2 has little effect on transcription alone and starts to matter the moment search or aggregation is added” keeps the judgement right.

The layer to start with is Layer 1, specifically unifying the tone mark form for the personal and equipment names that come up in meetings.

Form OCR — Layer 1 Dominates

Delivery notes, inspection certificates, work instructions. Pulling data out of paper and PDFs. This is a domain where Layer 1 is close to everything.

Text straight out of recognition mixes NFC and NFD, varies between new and old style tone mark placement, and, for strings coming from older formats, carries mojibake originating in legacy encodings. Push that into a core system and you get a run of defects: lot numbers not matching, a supplier registered as a separate company.

Layers that pay off: Layer 1. Unified normalization form, unified tone mark form, legacy encoding detection and conversion. In addition, recognition accuracy itself is a Layer 4 model question, and the decision of whether to use an OCR-capable model belongs there.

The layer that barely helps is Layer 2. Most field values on a form do not need to be grouped into words at all. Segmenting a part number or a quantity gains you nothing. Layer 2 only comes into partial play if you use word matching to reconcile field labels.

The layer to start with is Layer 1, and specifically NFC unification and absorbing tone mark placement variation. Both have clear symptoms and can be handled with standard patterns, which makes them worth putting first in the sequence.

Translation — Layer 4 Dominates

Japanese into Vietnamese and Vietnamese into Japanese is the use case among the six here that leans most heavily on Layer 4. Naturalness of the output, terminology consistency, honorifics and level of politeness. These are decided by the quality of the model’s interpretation and generation.

The layer that pays off is Layer 4. Give it a glossary, vary the instructions by document type, compare models. Layer 1 also helps, but its role is input cleanup. Hand over text with mixed normalization forms and the model’s handling becomes unstable.

The layer that barely helps is Layer 2. Translation passes whole sentences, so there is generally no need to insert your own segmentation. Spending effort here will not improve the output. The exception is when you use a model that assumes word-segmented input. Read the requirements of the model you are using first.

The layer to start with is Layer 4, and specifically sorting out the glossary and document classes. Translate contracts, work instructions, and internal notices under one setting and one of them will always read wrong.

Classification and Aggregation — Layers 1 and 2

Aggregating Vietnamese daily reports and defect reports by category. This one is decided by Layers 1 and 2 working together.

Aggregation results turn on whether the key words match. If an equipment name has split into two strings, the aggregate splits into two rows; if grouping is unstable, the same defect lands in a different category. Layers that pay off are 1 and 2. In Vietnamese, Layer 1 fragmentation happens along two axes, NFC versus NFD and new style versus old style, so one word can split into three or more forms.

The layer that barely helps is Layer 4. Swapping the model does not change the fact that one machine was already split in two at the input stage. Even in a design that hands the classification judgement itself to the model, it will not absorb input variation.

The layer to start with is Layer 1, specifically NFC unification of the words used as aggregation keys. Equipment names, line names, defect categories. Aligning those three alone moves the aggregate closer to what the floor believes.

One thing holds across every use case. Look at the “layer to start with” column and translation is the only use case where model selection belongs first; the remaining five all start from Layer 1 or Layer 2. Chatbots and minutes run Layer 4 in parallel, but even there the first thing you touch is upstream. Opening with “let us change the model” gets the order wrong in five of the six use cases.

Five Pitfalls Specific to Vietnamese

Here is where the layer discussion above lands as concrete symptoms. These are the five that documents from a Vietnamese site trip over most easily.

Tone Mark Placement Variation — The Same Word Exists in Two Spellings

Vietnamese tone marks have two placement conventions. The old style places the mark nearer the centre of the word, and the new style places it over the main vowel. hóa and hoá, hủy and huỷ. The same word, but different strings. Official textbooks use the new style, while everyday writing is said to show a tendency to prefer the old style.

How this looks on the floor. Exact match search fails. Duplicate detection stops working and one item gets registered twice. Keyword aggregation splits one word across two rows. Because the staff member is looking at the same word on screen, it gets reported as a system defect.

Which layer. Layer 1. Decide on a rule that converges on one of the two spellings and convert at the entrance. Which one to converge on is realistically decided by whichever form dominates the data already in your existing systems.

Unicode Normalization Mismatch — Looks the Same, Is Not

This is the NFC versus NFD difference. Whether the character is stored as a single precomposed code point, or decomposed into a base character followed by combining marks. Vietnamese characters carrying tone marks decompose into multiple code points under NFD.

How this looks on the floor. A word typed by hand into the search box does not match, but pasting it from a document does. Or the reverse. Character counts also wobble. As the VietUnicode FAQ notes, “ệ” counts as two or three code points under NFD and always as one under NFC. Input field length limits and form column alignment produce different results depending on the storage form.

Which layer. Layer 1. Unify to NFC at the entrance. Technically it does not matter whether you converge on NFC or NFD, but the point is to pick one and hold to it on every path. The problem is not having decided, not which one you chose.

IME Composition Breakage — Characters Separating Mid-Input

Vietnamese input uses schemes such as Telex and VNI. These input methods can reportedly emit either precomposed (NFC) or decomposed (NFD) text from the same keystrokes. Which one you get depends on the software.

On top of that, if the application does not correctly handle grouping combining marks into a single character, the display breaks. In 2026, a defect was reported in a production tool where typing “ư” produced a separated, duplicated display along the lines of “u ư”. That case occurred in a command line tool for developers, but the cause was the application failing to handle IME composition correctly, and the same structural problem can occur in a business system input field.

How this looks on the floor. Local staff report that “the characters go wrong on this screen only”. Because other screens are fine, it does not get treated as a system-wide problem and tends to be left alone as an individual environment issue. Let data entered in that state accumulate and you build up records that later match neither search nor aggregation.

Which layer. Layer 1. But normalization at the entrance alone is not enough; you need a step that verifies the behaviour of the input field itself on real hardware. On the actual terminal and browser the local staff use, hand-type a tone-marked word, save it, and check the saved byte sequence. Put that check on the rollout checklist.

Mojibake from Legacy Encodings — Appears When You Ingest Historical Documents

Vietnamese has 8-bit legacy encodings that predate Unicode. TCVN3, VNI, VSCII. These assign tone-marked characters to standard ASCII keys in proprietary ways, and produce mojibake in any environment without the matching font. Major browsers dropped support for these 8-bit encodings, other than Windows-1258, in 2014.

How this looks on the floor. Old work standards, historical inspection records, CSV exported from a long-running core system. Ingest these into your current system and only the Vietnamese portions turn into unintelligible symbol strings. Or it presents as text that looks readable but matches nothing in search. The second form is the nastier one. Nobody notices it is mojibake, and that data keeps flowing into the search corpus.

Which layer. Layer 1. Insert a step before ingestion that identifies the source data’s encoding and converts it. Identification can be automated, but conversion results need visual verification by local staff. When a mechanical conversion gets the source encoding wrong, it can produce a different string that still looks plausible.

Syllable and Word Boundaries Left Unhandled — Using Spaces as Boundaries

The fifth is the problem at the centre of this article. Build search, chunking, and keyword matching without word segmentation, and one word made of several syllables gets handled as separate units.

How this looks on the floor. Search misses “sometimes”. Only one syllable of a two-syllable word matches, and irrelevant documents come out on top. In aggregation, one item splits into several. And the nastiest part is that this process emits no error whatsoever. Splitting on whitespace terminates normally. Nothing is left in the logs. Because it looks like it is working, it never gets raised as a candidate cause.

Which layer. Layer 2. Put an explicit segmentation step in place and run the same one on the query side and the document side. And give it a dictionary of company-specific proper nouns. Writing those three things into the design is what pays off later.

Building Vietnamese Evaluation Data — The Shortest Path to Being Able to Talk About Accuracy

Everything above assumes you can measure. Fix layers without measuring and you cannot tell whether you fixed anything.

The procedure for building Vietnamese evaluation data is as follows.

• Narrow to a single target task. Search means search only, translation means translation only. Trying to measure several tasks with one evaluation set makes it impossible to read which layer’s improvement did the work
• Sample from real internal documents. Do not use composed example sentences. Composed examples get written in NFC-aligned new style, which means the Layer 1 problems are absent from the start
• Decide ground truth with local staff. What counts as correct cannot be decided from the Japan side alone. In translation and classification especially, ground truth will not settle without a local working sense of the business
• Write the judgement criteria out in prose first. “Natural translation” cannot be measured. Reduce it to conditions that can be judged, such as whether it follows the glossary, whether numbers are preserved, whether the specified format is used
• Cut a version and freeze it. Adding to or amending the evaluation set midway makes comparison against the previous run impossible

The second item deserves particular care in Vietnamese. Compose your evaluation sentences on the Japan side and they will be clean Vietnamese. NFC-aligned, consistent in tone mark placement, free of any mojibake from legacy encodings. Measure against that data and the Layer 1 problems do not exist. Then the moment you go live, every problem you had eliminated comes back. Always sample from documents actually produced on the floor.

The thing that pays off most in Vietnamese evaluation is labelling errors with their layer. For every failed case, record whether it originated in Layer 1, Layer 2, or Layer 4.

Do this and the next layer to work on is decided by data. If most errors originate in Layer 2, you know that comparing models is pointless. If errors have concentrated in Layer 4, that is when it becomes worth spending money on model selection. An evaluation without labels only produces a figure for what percentage was correct overall, which does not let you decide the next action.

As a Vietnamese-specific refinement, it helps to split Layer 1 into two. Errors from normalization form mismatches, and errors from tone mark placement variation. The countermeasures differ, so counting them together leaves you without a course of action.

On the size of the evaluation set, this article does not give a count. The right number varies with the target task and how the errors arise, and no generalizable figure could be confirmed against a primary source. Practically, starting from the criterion of covering every failure mode you currently know about, then adding as new modes appear, is the easiest way to keep it running.

Breaking Cost into Five Layers

The cost of Vietnamese generative AI is not just model usage fees. If anything, it is the parts other than model usage fees that squeeze the budget later.

One clarification first. The five cost layers here resemble the four processing layers described earlier in numbering, but they are not the same thing. The correspondence is as follows.

• Cost Layer 1 is the cost of building processing Layer 1 (character layer)
• Cost Layer 2 is the cost of building and maintaining processing Layer 2 (word layer)
• Cost Layer 3 is the usage fee proportional to processing Layer 3 (token layer)
• Cost Layer 4 is the cost of the evaluation data needed to measure processing Layer 4 (meaning layer)
• Cost Layer 5 is the operational cost that spans all four layers

This article gives no monetary figures. The range is wide depending on use case, document volume, number of target languages, and the state of internal documents, and no generalizable market rate could be confirmed against a primary source. Instead, hold on to the differences in the nature of the costs.

The distinction between one-off and continuing costs. Layer 1 is close to a build-once cost. Layers 2 and 5 continue. Layer 3 accrues with usage. Judge on the initial estimate alone without making that distinction and the running cost six months in comes as a surprise.

Layer 3 carries a multiplier. As noted above, GPT-4’s byte-level BPE tokenizer is reported to require 2.5 times as many tokens for Vietnamese as for English (a figure recorded by a subsequent paper citing it, as the analysis result of Petrov et al.’s 2023 paper). On usage-based pricing, that difference maps directly to the invoice. In document-heavy use cases it shows up as a difference in monthly running cost. But this is a comparison against English, not a comparison between tokenizers. Whenever you use it to justify an estimate, always attach what was compared with what.

The most commonly skipped is Layer 4. Building evaluation data produces an unglamorous deliverable and does not directly make anything run, so it is the first thing cut from a budget. Skip it, though, and every subsequent discussion becomes impressionistic. You never get past “it feels better since we changed models”.

Layer 5 bites six months in. Dictionaries go stale if left alone. New equipment arrives, new abbreviations appear, and segmentation accuracy quietly degrades each time. Who updates the dictionary, how often, and based on what. Without deciding that, the more time passes the closer you drift back to the pre-launch state.

Vietnamese adds one further cost. Handling legacy encodings in historical documents. This falls under Layer 1, but depending on the volume of documents involved it can be the single largest item within Layer 1. And because it is a one-off cost, leaving it off the initial estimate means it appears as an addition partway through. Decide whether historical documents are in scope for search before you estimate.

Three Additional Considerations at a Vietnamese Site

Compared with deploying generative AI within Japan, a Vietnamese site adds the following three.

The AI Law Is Already in Force

In Vietnam, Law on Artificial Intelligence No.134/2025/QH15 was passed by the National Assembly on 10 December 2025 and came into force on 1 March 2026. Grace periods are provided for AI systems already operating before the effective date, set at 12 months for general sectors and 18 months for healthcare, education, and finance. Both run from the effective date (12 months after the effective date corresponds, on a calendar basis, to roughly March 2027 — that calendar date is this article’s own calculation, not the wording of the primary source).

What matters here is that Thailand and Vietnam are at different stages. Thailand’s artificial intelligence act is at draft stage and has neither been enacted nor come into force. Vietnam’s is in force. When you try to build a common operating model across ASEAN, that difference in stage is the first branch point. “Nothing is settled yet, so let us wait and see” holds in Thailand. It does not hold in Vietnam.

A greenfield deployment has the easier design job, since there is no grace period discussion to have. You can build the requirements in from the start. Conversely, if you already have systems running, check the grace period start date and scope early. The relationship between AI deployment in Vietnam and the legal framework is also covered in the points to cover when deploying AI in Vietnam.

Confirm the specific scope of application and the substance of the obligations with local specialists on a case by case basis. This article limits itself to the fact that the law is in force and the number of months in the grace periods.

Dictionaries and Evaluation Data Require Local Staff Involvement

The Layer 2 dictionary cannot be maintained by engineers alone. The people who know the correct form of equipment names and abbreviations are on the floor. In Vietnamese, there is the further judgement of which tone mark form is authoritative. There is no technically correct answer to that; it is settled by local convention and the distribution of existing data.

The same applies to Layer 4 evaluation data. What counts as correct cannot be decided from the Japan side alone. In classification and translation especially, ground truth will not settle without a local working sense of the business.

What you need is to define, as a business process, who updates the dictionary, how often, and looking at which inputs. Embedding it in an existing workflow is the realistic approach, for example by including “add to dictionary” in the procedure that runs when new equipment arrives. Go live without deciding this and you simultaneously have no mechanism for noticing that accuracy is falling.

Mojibake Will Always Appear When Connecting to Existing Systems

A Vietnamese site may be running a long-lived core system, or business systems built locally. Where those hold data in legacy encodings, handling mojibake during integration into the current system is unavoidable.

What gets overlooked here is that mojibake does not always appear in an unreadable form. Interpreted as the wrong encoding, the result can be a different string that still reads plausibly as Vietnamese. Data in that state passes a visual check. And then it accumulates as records that match neither search nor aggregation.

The countermeasure is to identify the source data’s encoding before integration and have local staff read a sample of the converted output. Ask them to confirm not whether it is readable, but whether it says the same thing as the original document.

What to Do in the First 90 Days

Here is a 90-day sequence designed to keep the order right.

• Day 1 to Day 30 — Narrow to a single document type and build only the Layer 1 normalization. NFC unification and tone mark form unification. At the same time, count how many forms a word that should be single has fragmented into. That count is your progress metric for Layer 1
• Day 31 to Day 60 — Layer 2. Build the company proper noun dictionary together with local staff. And always include a session where you review segmentation output by eye. Watching only the numbers hides how words outside the dictionary are being grouped
• Day 61 to Day 90 — Build the Layer 4 evaluation set and compare two models. Model comparison comes last. Compare before Layers 1 and 2 are settled and you cannot read whether a difference came from the model or from the input

There is something deliberately left out of these 90 days: Layer 3 tokenizer optimization. Layer 3 pays off as a cost optimization but contributes nothing to isolating an accuracy problem. Spend the first 90 days identifying and eliminating the causes of symptoms, and start cost optimization once operations are running, when you will have better information to decide with.

One more thing. Narrowing to a single document type is not about limiting scope, it is about making causes visible. Handle daily reports, inspection records, and contracts simultaneously and each breaks differently, so you lose track of which countermeasure helped what. Establish the pattern on one type and you can apply the same pattern from the second onwards.

For the Day 1 to Day 30 period, Vietnamese adds one task. Find out, path by path, whether the target documents are stored as NFC or NFD. Even within one system, data that arrived through a web input field and data that arrived through file ingestion can be in different forms. Building the list of paths takes a day, but without it you cannot decide where normalization goes.

Five Common Failures and How to Avoid Them

Changing the Model First

This is the most common pattern we see in enquiries from Vietnamese sites. A report that Vietnamese accuracy is poor, and the first response is a model swap. As the use case table in this article shows, translation is the only use case where model selection belongs first; the remaining five start upstream.

How to avoid it. Collect cases where the symptom appeared and check whether a human cleaning up the input fixes them. If it does, the problem is upstream. That check needs no special preparation and can be run before you procure any model.

Splitting on Spaces and Thinking Those Are Words

This failure is specific to Vietnamese. Because the text is Latin script separated by spaces, English-style processing runs straight through. No errors appear. As a result, search and aggregation both operate on syllable units.

How to avoid it. In the design review, ask one question: where does Vietnamese text get grouped into words? If no answer comes back, or the answer is “we split on whitespace”, you have found a candidate cause. This check does not require reading any implementation.

Feeding Raw Text to a Model That Requires Word-Segmented Input

Some models built for Vietnamese assume the input has already been word-segmented. The PhoBERT README states explicitly that input text must be word-segmented. Hand it raw text without reading that condition and the performance will not appear. Then someone looks at that result and marks the model down.

How to avoid it. At the point you add a model to your shortlist, check the required preprocessing conditions in the README or paper and add them as a column in your comparison table. Confirm before comparing that every model in the comparison has been through the same preprocessing and that each model’s requirements are satisfied.

Proceeding Without an Evaluation Set

This is the state where decisions get made on “it feels better since we changed models”. You cannot distinguish between an actual improvement and having happened to try better questions.

How to avoid it. Decide that no model comparison happens until the evaluation set exists. What you can do before an evaluation set exists is upstream layer work. And take the evaluation documents from the floor rather than composing them on the Japan side.

Writing Normalization in Several Places

This is the state where the search side, the aggregation side, and the summarization side each have their own normalization code. Fix NFC unification in one place and another path stays as it was. In Vietnamese there are two axes, normalization form and tone mark form, so the more paths there are the more combinations fall out of step.

How to avoid it. Funnel ingestion through a single entrance and normalize only there. Agree that downstream only ever receives normalized strings.

Frequently Asked Questions (FAQ)

Is Vietnamese generative AI less accurate than Japanese?

It depends on the use case. For Layer 4 centred use cases such as translation and summarization, there are genuine differences in how models handle Vietnamese. On the other hand, much of what feels worse than Japanese in search and aggregation is a difference in how well Layers 1 and 2 have been set up. It can simply be that the Japanese documents already have consistent orthography while the Vietnamese documents mix NFC and NFD and mix new and old style tone mark placement. Unless you compare under matched conditions, you cannot tell whether the difference is the model’s language capability or your preprocessing.

Which generative AI is strongest in Vietnamese?

Within what can be confirmed, VinAI Research publishes PhoGPT-4B as a Vietnamese-specific base model. The precise figure is 3.7B parameters, pre-trained on a 102 billion token Vietnamese corpus, with vocabulary size 20480 and context length 8192. A chat version, PhoGPT-4B-Chat, also exists. For Southeast Asian languages there is AI Singapore’s SEA-LION, and AI Singapore states in its own announcement that SEA-LION v4 ranks 5th of 55 models on SEA-HELM and 1st among open models under 200B parameters. Separately, Viettel AI was reported on 4 June 2026 to have announced VT-Super-120B-A12B, a 120 billion parameter Vietnamese model, but that is media-sourced and we have not confirmed its performance against a primary source. Which one fits your company is something only measurement on your own evaluation set can answer with certainty.

Do we need to build Vietnamese word segmentation ourselves?

You do not need to build the segmentation mechanism itself. Existing tools such as VnCoreNLP and underthesea are available. What you do need to supply is the dictionary, and specifically the dictionary of company-specific proper nouns. Equipment names, part names, abbreviations, line names. None of these appear in a general tool’s dictionary, so out of the box they get left as separate syllables or grouped incorrectly. That part only you can build. In addition, check up front whether the model you plan to use requires word-segmented input. Some models, such as PhoBERT, require it explicitly.

Why does search miss in Vietnamese RAG?

In most cases the cause is Layer 2. Vietnamese is space-separated, but those spaces are syllable boundaries, not word boundaries. Treat the spaces as word delimiters and search operates on syllable units. If the grouping on the query side and the document side does not match, keywords that ought to match do not. Next comes Layer 1, where NFC and NFD mismatches and tone mark placement variation block matching. Changing the model does not change search results, so a model swap does not address this symptom.

Does Vietnamese generative AI cost more?

On the token side, there is a disadvantage when you use a general-purpose tokenizer. GPT-4’s byte-level BPE tokenizer is reported to require 2.5 times as many tokens for Vietnamese as for English. Note, though, that this figure is what a subsequent paper citing it records as the analysis result of Petrov et al.’s 2023 paper, and this article has not directly checked the table in the original paper. On usage-based pricing, that difference affects the invoice. In practice, dictionary maintenance and operational costs often bite harder later than model usage fees, and in Vietnamese the handling of legacy encodings in historical documents can land as an initial cost. It is safer not to build the cost discussion out of model usage fees alone.

How should we measure Vietnamese accuracy?

Sample from real internal documents, decide ground truth with local staff, write the judgement criteria out in prose first, and freeze the version. Do not use example sentences composed on the Japan side. Composed examples get written in NFC-aligned new style, so the Layer 1 problems disappear from the outset. Then label every error as originating in Layer 1, Layer 2, or Layer 4. In Vietnamese, splitting Layer 1 further into normalization form mismatches and tone mark placement variation makes the course of action easier to settle. With those labels, the next layer to work on is decided by data.

Summary

When Vietnamese generative AI accuracy falls short, what is broken is the preprocessing, not the model. Here are the key points of this article.

• Vietnamese processing splits into four layers: character, word, token, and meaning. The model sits at Layer 4, and changing only that leaves the upstream breakage in place
• Layer 1 is the layer that aligns strings which look the same but differ internally. NFC and NFD mismatches, tone mark placement variation, IME composition breakage, and mojibake from legacy encodings all land here
• Layer 2 is the crux. Vietnamese has spaces, but they are syllable boundaries, not word boundaries. Splitting on whitespace runs without any error, which is why it never gets raised as a candidate cause
• On word segmentation accuracy, RDRsegmenter scores F1 97.90% on the VLSP 2013 test set (2120 sentences), and the state of the art on that benchmark is UITws-v1 at 98.06%. Meanwhile, on the Vietnamese Universal Dependencies Treebank (over 800 sentences), the figures are underthesea 80.04%, VnCoreNLP 78.37%, and PyVi 57.88%. These cannot be compared directly because the evaluation data differs, but together they show how much the numbers move with the evaluation data
• Layer 3 affects cost and how much fits. GPT-4’s tokenizer is reported to require 2.5 times as many tokens for Vietnamese as for English (a figure reaching us via a subsequent paper citing Petrov et al.’s 2023 paper)
• The more a model was purpose-built for Vietnamese, the more it assumes preprocessing. PhoBERT makes word-segmented input mandatory
• The dominant layer differs by use case. Translation is the only use case where model selection belongs first; RAG, chatbots, minutes, form OCR, and classification and aggregation all start from Layer 1 or Layer 2
• Cost splits into five layers. The most commonly skipped is building the evaluation data, and skipping it makes accuracy impossible to discuss
• Vietnam’s AI Law came into force on 1 March 2026. Existing systems have a grace period of 12 months for general sectors and 18 months for healthcare, education, and finance. Thailand is at draft stage, so the two countries are at different stages
• In the first 90 days, work through normalization, then dictionaries, then the evaluation set. Put model comparison last

An enquiry about Vietnamese accuracy can start simply by isolating which layer it is happening in. It is fine to be at an exploratory stage, whether you want a one-off look at which layer your documents are breaking at, or just want to talk through how to build an evaluation set. Get in touch via our contact page.

References

• VnCoreNLP (GitHub) A Vietnamese Natural Language Processing Toolkit
• arXiv A Fast and Accurate Vietnamese Word Segmenter
• undertheseanlp NLP-Vietnamese-progress Word Segmentation Leaderboard
• huybik Word Tokenizer Benchmark
• VinAIResearch PhoBERT (GitHub)
• VietUnicode FAQ
• arXiv PhoGPT Generative Pre-training for Vietnamese
• AI Singapore SEA-HELM Leaderboard
• VILAF Vietnam Enacts its First Law on Artificial Intelligence