Thai Language Generative AI Accuracy and Cost — What Breaks Is Preprocessing, Not the Model

When a Thai site rolls out generative AI, the report that comes back tends to have the same shape every time. It behaves as expected in Japanese and in English, and accuracy drops in Thai alone. Most teams respond by switching to a different model, and most of the time the switch changes nothing. When Thai generative AI fails to perform, the part that is broken is usually not the model. It is the character handling and the word handling that sit upstream of the model. This article splits Thai processing into four layers and works through which layer you have to repair to get which improvement, use case by use case.

What Is Actually Happening When People Say Thai Generative AI Is Not Accurate Enough

The first reports that surface at a Thai site usually take one of three forms.

• A search over internal documents fails to return a document that is definitely there. Asking the same question in Japanese returns it
• Aggregating Thai daily reports or inspection records produces totals that do not match what the shop floor believes. Records for one machine have split into two rows
• Translation and summarization run, but the output reads stiff, proper nouns change from one run to the next, and the level of politeness is inconsistent

None of these fail all the time. They fail some of the time, and that is what makes them hard. A component that always fails invites you to check the configuration. A component that fails intermittently cannot be written up as a reproduction procedure. A defect with no reproduction procedure tends to skip the diagnosis step entirely and settle into the explanation that the model simply is not good enough at Thai.

So the team swaps the model. A newer model, a larger model, a model that advertises Thai support. The symptom comes back in the same shape. The number of searches that miss may drop slightly, but the documents that were not being found are still not being found.

The reason is straightforward. The model sits at the very bottom of the pipeline. A string that was corrupted upstream, or a word that was cut in the wrong place upstream, becomes the input to the model exactly as it is. If the input is broken, every model stumbles in the same place. Swapping does not help because nothing has been done to the place that needs help.

This article divides Thai processing into four layers, the character layer, the word layer, the token layer, and the meaning layer. The point of dividing it this way is to let you sort each symptom into the layer that causes it, and then decide the order in which to fix things. Get the order wrong and most of your budget and most of your calendar disappear into the last layer.

Thai Processing Splits Into Four Layers — Character, Word, Token, and Meaning

A Thai document passes through four layers on its way to a generative model. From upstream to downstream, they are the character layer, the word layer, the token layer, and the meaning layer.

These four layers behave differently from one another in ways that matter in practice.

The further upstream, the longer one piece of work keeps paying off. Layer 1 normalization only has to be built once and placed at the intake point. From then on it applies automatically to every document that arrives afterward. Layer 3 model usage fees, by contrast, keep accruing for as long as you keep using the service.

The further upstream, the wider the blast radius when it breaks. If Layer 1 is broken, search, aggregation, and summarization all go wrong simultaneously. If Layer 4 is merely weak, the damage is confined to the quality of the generated text.

And the further upstream, the more the symptom looks like the model’s fault. Failures in Layers 1 and 2 appear intermittently, so the cause goes unidentified and the blame is passed downstream to the only component anyone can name.

Across the cases we have seen at Thai sites, most of the accuracy problems that arrive as consultations are explained by Layers 1 and 2. The ones that genuinely belong to Layer 4 cannot even be identified as such until the upstream layers have been made solid.

Layer 1, the Character Layer — Thai Strings That Look Identical but Are Not

Layer 1 has exactly one job. Make strings that mean the same thing resolve to the same sequence of bytes.

In Thai this is harder than it is in Japanese. The reason is structural. Thai script stacks vowel marks and tone marks above, below, and beside the consonant letters. When a vowel mark and a tone mark both sit above the same consonant, swapping the order in which they were typed produces a display that is essentially identical. To a human reader it is the same word. To a computer it is a different string.

On top of that, Thai documents carry a set of variations that are specific to the language and to the region.

• Invisible separator characters are embedded in the running text. They exist to control where lines may break, and whether they are present depends on where the text was copied from
• Years are written in the Buddhist era. In inspection records and contracts, the Buddhist era is more common than the Gregorian calendar
• Numbers are written in Thai digits. Sometimes only part of a lot number or a drawing number uses them
• English equipment names and codes vary between full-width and half-width forms, and between upper and lower case

What this looks like on the floor. You reconcile the equipment master against Thai daily reports and get a no-match result. The person handling it puts both on screen side by side and sees exactly the same string in both places. From there the conversation becomes an accusation that the system search is broken, and it drifts toward search engine settings or model choice. What has actually happened is that one side contains a single invisible character the other side does not.

The fix at Layer 1 is unglamorous as a feature. Consolidate the intake path into a single entry point and force every document through normalization there. Concretely, that means character normalization, removal of invisible separator characters, conversion of Thai digits to Arabic digits, conversion of Buddhist era years to Gregorian years, and a consistent form for alphanumeric text. That is the whole list.

What matters is where you put it. If normalization is written separately inside the search path, the aggregation path, and the summarization path, then fixing one of them leaves the others out of step. Running it once at the intake point, and establishing the rule that everything downstream only ever handles normalized strings, makes the operation far easier to live with later.

Whether Layer 1 is solid is something you can verify with a number rather than with your eyes. Count how many distinct strings a word that should be one word has fragmented into. As long as that count keeps falling, there is still Layer 1 work left to do.

Layer 2, the Word Layer — Nobody Has Decided Where to Cut a Language With No Spaces

This is the most important layer for Thai generative AI.

The PyThaiNLP paper describes Thai as “a scriptio continua” script. The most common way of writing Thai puts no space or other separator between words, and none between sentences either. A Thai sentence is not visually divided into words the way Japanese is, and it is not delimited by spaces the way English is. It is written as one continuous run of characters.

That leaves the computer to decide for itself where the word boundaries fall. This process is called word segmentation. Every system that handles Thai is cutting words somewhere, whether it does so explicitly or implicitly.

The problem is that more than one downstream process depends on how that cut is made.

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

In other words, changing the segmentation changes all four of these at once. Turn that around and a bad segmentation breaks all four at once. And because the breakage is not uniform, the symptom presents as search that hits sometimes and misses other times.

At a Thai site, the place where segmentation reliably falls apart is internal proper nouns. Equipment names, part names, in-house abbreviations, line names. None of these appear in a general dictionary. A word that is not in the dictionary gets decomposed by the default segmenter into some combination of nearby words that are. How it decomposes depends on the surrounding characters, so the same equipment name is cut differently in different documents.

What this looks like on the floor. Daily reports for one machine appear as two machines in the aggregate. The person handling it reports that a machine they only have one of is showing up as two rows. The cause is neither the equipment master nor data entry. The name split into two variants at the moment the document was cut into words.

The fix at Layer 2 is to build a dictionary of internal proper nouns and feed it to the segmenter. This is less an engineering task than an exercise in sitting down with local staff and enumerating vocabulary. And because equipment and parts keep being added, it is not something you do once and finish.

How to assemble multilingual knowledge search is covered in how to approach building factory knowledge search with RAG. When you design a search that includes Thai, deciding in advance where Layer 2 will be guaranteed will save you a lot of rework.

How to Read the 71.18% Word Segmentation Figure

Thai word segmentation has published benchmarks. According to the PyThaiNLP paper, NewMM, the default engine in PyThaiNLP, scored 71.18% on the BEST 2010 benchmark, while the best result available at that time was 95.60%.

NewMM cuts words using dictionary-based maximum matching, with Thai Character Cluster boundaries acting as a constraint on where cuts may fall. Take the longest match available in the dictionary. That is the basic behavior.

There are three things you must not miss when reading that figure.

First, 71.18% is the performance of a default setting, not a ceiling on Thai processing. A method scoring 95.60% on the same benchmark existed at the same point in time. Concluding from an out-of-the-box number that Thai word segmentation is roughly seventy percent accurate, and leaving it there, is premature.

Second, the errors are not spread evenly. Because the method is dictionary based, common words that are in the dictionary segment well, and words that are not in the dictionary are where it falls apart. And the important words in your internal documents are, almost by definition, words that are not in a general dictionary. Equipment names, part names, abbreviations, company names. The structure of the problem is that the words you most want to get right in your own documents are exactly the ones most likely to break under the default. That is why you cannot take a general benchmark number and treat it as your own accuracy.

Third, this number is a comparative value on one specific benchmark. What happens on your documents can only be learned by measuring on your documents. Benchmark numbers tell you about the tendencies of a method. They are not something you can adopt as an internal target as they stand.

The practical conclusion is simple. Using the default segmenter as it comes will drop your own vocabulary. So you add a dictionary. And you measure the effect of what you added against your own documents. That is what Layer 2 work consists of.

Layer 3, the Token Layer — The Same Thai Document Can Be Counted 2.62 Times Differently

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

The Typhoon paper states that the Typhoon tokenizer is 2.62 times more efficient than GPT-3.5 at tokenizing Thai. In other words, processing the same Thai document with the Typhoon tokenizer versus the GPT-3.5 tokenizer yields token counts that differ by that factor. This is a measured comparison between two specific tokenizers, and it does not establish an upper bound on the difference between arbitrary tokenizers.

There is one common misreading worth eliminating here. This 2.62 figure is not a comparison with English. It is the difference between processing the same Thai document with a general purpose tokenizer and processing it with a tokenizer optimized for Thai. So you cannot say that Thai costs 2.62 times more than English. There are also secondhand summaries circulating on the web that name GPT-4 as the point of comparison. The comparison in the original source is GPT-3.5. When you cite it, cite it as the original states it.

There are two situations where this difference bites in practice.

Billing. With usage-based pricing, token count translates directly into money. In document-heavy applications, for example feeding several years of inspection records through the system every day, that factor becomes a straight difference in running cost.

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

Even so, Layer 3 is a multiplier, not a cause. If Layer 2 is broken and search is not retrieving the right documents, packing the wrong documents in more efficiently does not make the answers better. Selecting a tokenizer is best treated as an optimization to be performed after the upstream layers are settled.

Layer 4, the Meaning Layer — Only Here Do You Choose a Model

Layer 4 is where the string that was handed over is interpreted and where output is generated. The symptoms that belong here look like this.

• Translation reads stiff, or literal, or does not use the phrasing your company actually uses
• Instructions are not followed. A specified format is not respected
• Content appears that is not in the source
• Politeness is inconsistent, and the register does not fit the audience or the situation

There is a way to tell whether you are looking at a Layer 4 problem. Hand the model the same input after a human has cleaned it up by hand. If that fixes it, the problem was upstream. If a person reselecting the retrieved documents produces a correct answer, the fault is on the Layer 2 search side. If a person fixing garbled characters and inconsistent spellings makes it work, the fault is Layer 1. Only when the same failure persists even with human-prepared input are you actually in Layer 4 territory.

If you compare models without doing that triage first, the conclusion of the comparison is not trustworthy. Comparing two models while the upstream is unstable makes it impossible to tell whether the difference came from the models or from which documents happened to be retrieved on that run.

What gives you something to decide on at Layer 4 is a measured result on your own evaluation set. Public benchmark rankings are useful for narrowing the candidate list, but the ranking on your documents and your tasks may not agree with them.

Where Thai-Capable Models Stand Today — Typhoon 2, SEA-LION, and Frontier Models

Here is what can be confirmed from primary sources about the model families that are investing in Thai.

A few notes on that table.

The size range of Typhoon 2 is really a range of design options. Having everything from 1B to 70B available means you can architect a system where documents that cannot leave your premises are handled by a small on-premises model. Typhoon2-Vision has OCR built in, and Typhoon2-Audio handles speech input and output. For document OCR and for meeting minutes, those two enter the shortlist.

SEA-LION is developed by AI Singapore. AI Singapore is supported by Singapore’s National Research Foundation and hosted by the National University of Singapore. The model family is built on a policy of handling multiple Southeast Asian languages within one framework, so it covers not only Thai but the languages of neighboring countries under the same umbrella. For a company with sites in Vietnam or Indonesia in addition to Thailand, that is a difference that shows up in operations.

SEA-HELM is on the evaluation side. It is not a model. It is an evaluation framework and leaderboard weighted toward Southeast Asian languages. This article does not go into individual model scores or rankings, because we have not been able to verify those numbers against primary sources. Use it as an entry point for narrowing candidates, and make the final call on your own evaluation set. That is the safe way to use it.

There is no need to exclude frontier models. General purpose large models handle Thai. That said, since we could not confirm comparative Thai scores against a primary source this time, this article will not claim that Thai-specific models are always better, nor that frontier models are always better. What has not been verified is stated as not verified.

The thing to settle first in model selection is not the ranking but the constraints. Do you need speech or OCR? Can the documents leave the company? Does the model have to run inside your own environment? What is the response time requirement? Once those are decided, the candidate list narrows to a handful. Everything after that is measurement on an evaluation set.

Which Layer to Fix for Each Use Case

This is the core of the article. The same complaint that Thai accuracy is poor has a different dominant layer depending on the use case. Work on the wrong layer and you will have spent money without changing the symptom.

Below we look at each of the six use cases in detail.

Internal Document Search (RAG) — Layer 2 Dominates

RAG retrieves documents relevant to a question and hands them to a model to answer from. Given that structure, the model can do nothing about a document that search failed to retrieve. A document that was not retrieved may as well not exist.

Across the consultations we have handled at Thai sites, most of the causes behind Thai RAG search failing to hit were at Layer 2. The way the question was segmented did not agree with the way the documents were segmented. When internal proper nouns in particular get decomposed differently on the two sides, keywords that should match do not match.

Layers that help are 1 and 2. Align the characters, then align the words. Fix that and documents that were not being found start being found. Layer 3 affects how many documents you can hand over, so it thickens the grounding.

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

Where to start is Layer 2. Build a dictionary of internal proper nouns and run both the question side and the document side through the same segmenter. That alone changes the hit rate.

Chatbots — Catch With Layer 2, Answer With Layer 4

An internal help desk bot straddles two layers at once. The first half is working out what is being asked, which is subject to Layer 2. The second half is how to answer, and that is Layer 4.

The common failure with Thai chatbots is that the same question phrased differently stops being recognized. Inquiry text is shorter than a daily report, more colloquial, and carries spelling variation. The shorter the sentence, the more directly a segmentation failure hits the result.

Layers that help are 2 and 4. Hold a dictionary of inquiry vocabulary at Layer 2, and shape the answer patterns at Layer 4. The layer that barely helps is Layer 3, because the text per request is short enough that tokenizer differences do not move either the bill or the context length very much. Where to start is Layer 2, and specifically collecting vocabulary from the inquiries that have actually arrived.

A treatment of multilingual chatbots from the cost and rollout angle is collected in what a multilingual chatbot costs and how to roll one out internally. The layer you have to guarantee differs by language, and building that into the design keeps operations stable.

Meeting Minutes and Transcription — Layers 1 and 4

For turning Thai meetings into text, speech is transcribed first, and summarization and decision extraction ride on top of that.

Layers that help are 1 and 4. Immediately after transcription, the text comes out with inconsistent spellings. Personal names, equipment names, and company names end up in several spellings within a single meeting. If you do not align those at Layer 1, the downstream summary treats one person as two, or lists a single decision as two separate items. Layer 4 affects speaker separation and the quality of the summary.

The layer that barely helps is Layer 3. Layer 2, though, cannot quite be dismissed. If the operation includes searching the minutes later, Layer 2 starts mattering at that point. Transcription on its own is only lightly affected by Layer 2, and the moment you put search or aggregation on top of it, Layer 2 becomes live. Understanding it in that order keeps you from misjudging the priority.

Where to start is Layer 1, and specifically consistent spelling of the personal names and equipment names that come up in the meeting.

The places where summaries break in multilingual meetings are laid out in where AI meeting minutes break in multilingual meetings. In meetings where speakers switch languages mid-sentence, the failure points differ from a Thai-only meeting.

Document OCR — Layer 1 Dominates

Delivery notes, inspection certificates, work instructions. The use case of pulling data out of paper and PDFs. This is an area where Layer 1 is close to the whole story.

Text straight out of recognition mixes Thai digits with Arabic digits, carries years in the Buddhist era, and has invisible separator characters scattered through it. Feed that into a core system and you get a run of defects. Lot numbers do not match, date ordering goes wrong, expiry checks do not fire.

The layer that helps is Layer 1. Normalize the digits, convert the calendar, normalize the character encoding. Beyond that, recognition accuracy itself is a Layer 4 model question, and the decision about whether to use a model with OCR built in belongs there.

The layer that barely helps is Layer 2. Field values on a form mostly do not need to be cut into words at all. Segmenting a part number or a quantity gains you nothing. Layer 2 is only partially involved when you use word matching to reconcile field labels.

Where to start is Layer 1, and specifically normalizing Thai digits and Buddhist era years. Those two have symptoms that are easy to recognize and countermeasures that can be made routine, which makes them worth putting first in the sequence.

Translation — Layer 4 Dominates

Translation from Japanese into Thai and from Thai into Japanese is the use case most weighted toward Layer 4 of the six listed here. Naturalness of the output, consistency of terminology, level of politeness. All of these are decided by the quality of the model’s interpretation and generation.

The layer that helps is Layer 4. Give it a glossary, vary the instructions by document type, compare models. Layer 1 helps too, but its role is cleaning the input. Handing over text that still contains invisible separator characters disturbs the model’s judgment about where words end.

The layer that barely helps is Layer 2. In translation you hand over the whole sentence, so there is basically no need to interpose your own segmenter. Spending effort here does not improve the translation.

Where to start is Layer 4, and specifically the glossary and the sorting of documents into classes. Translate contracts, work procedures, and internal announcements under the same settings, and one of the three will always come out wrong.

The thinking behind document classes as a way to stop translation drift is covered in how to design AI translation automation for manufacturing. The essential move is to start from the premise that different document types demand different qualities from the translation.

Classification and Aggregation — Layers 1 and 2

The use case of taking Thai daily reports and defect reports and aggregating them by category. Here the outcome is decided by Layers 1 and 2 working together.

Aggregation results change depending on whether the key words match. If an equipment name has split into two strings, the aggregate splits into two rows. If segmentation is unstable, the same defect lands in different categories. The layers that help are 1 and 2.

The layer that barely helps is Layer 4. Changing the model does not change the fact that one machine already split into two at the input stage. Even in a design where the classification decision itself is delegated to the model, the model will not absorb variation in the input.

Where to start is Layer 1, and specifically normalizing the words that serve as aggregation keys. Equipment names, line names, and defect types. Aligning those three alone moves the aggregate output much closer to what the shop floor believes.

There is one observation that holds across all six use cases. Look down the column for where to start and you will see that translation is the only use case where model selection belongs first, and the remaining five all begin at Layer 1 or Layer 2. Chatbots and meeting minutes have Layer 4 running in parallel, but even there the first thing you touch is upstream. Opening with a model swap gets the order wrong in five of six use cases.

Six Pitfalls Specific to Thai

Now to bring the layer discussion down to concrete symptoms. These six are where documents at sites in Thailand trip people up most often.

Buddhist Era Years — Date Comparison Breaks Silently

In Thai inspection records, contracts, and official documents, years are written in the Buddhist era (พ.ศ.). Buddhist era 2569 is 2026 in the Gregorian calendar.

What this looks like on the floor. Ingest without converting to the Gregorian calendar and the dates load correctly as numbers, while every comparison and every sort comes out wrong. Mix Buddhist era years and Gregorian years in the same column and sorting introduces a gap of several centuries. If you have built expiry checks, deadlines that have passed are judged not to have passed. And because nothing raises an error, nobody notices.

Which layer. Layer 1. Convert to the Gregorian calendar at the intake point and retain the original notation as well. Being able to render it back into the Buddhist era for display makes verification much easier for local staff.

Thai Digits — The Same Number Becomes a Different Number

Thai has its own digits (๐๑๒๓๔๕๖๗๘๙). They correspond to Arabic 0 through 9, and to a computer they are entirely different characters.

What this looks like on the floor. Sometimes only part of a lot number or a drawing number uses Thai digits. It shows up when handwritten slips are transcribed, or where an old form template is still in use. The result is that the same lot number exists as two different strings, and the aggregate lists them as two different lots. The person handling it reports that the same number appears on two rows, but as strings they are genuinely different, so the system is behaving correctly.

Which layer. Layer 1. Put normalization to Arabic digits at the intake point.

Combining Order — Identical on Screen, No Match in Search

Thai script writes vowel marks and tone marks stacked onto consonant letters. When two or more marks sit above the same consonant, swapping the order in which they were typed leaves the display essentially unchanged. But if the sequence of code points differs, the strings are different.

What this looks like on the floor. Local staff type a word by hand into the Thai search box and get no results. Copy the same word and paste it, and it hits. What reaches the person in charge is a report that search sometimes does not work, and with no explanation available it gets left alone. What actually happened is that the input order differed from the order stored in the document.

Which layer. Layer 1. Running text through character normalization collapses the orderings into one canonical form.

Zero-Width Space — The Separator You Cannot See

Because Thai puts no space between words, a machine cannot determine line break positions on its own. To solve that, an invisible separator character is sometimes embedded in the running text to mark positions where a line break is permitted.

What this looks like on the floor. The same sentence returns different search results depending on whether it was pasted from a word processor or from the web. Count the characters and the count does not match what you see. Run it through the segmenter and the word splits in two at the position where the separator was. Here too, the symptom presents as search that occasionally misses.

Which layer. Layer 1. Removal is the default, though for display data where you want to preserve line break appearance there is a case for keeping them. Keeping the two separate, so that the stripped version feeds search and aggregation while the version with separators feeds display, lets you have both.

Mixed English and Thai — The Script Switches Inside One Sentence

In shop floor documents at Thai sites, equipment names, part names, in-house abbreviations, and units are written in English while the explanatory text is written in Thai. Inside a single sentence, the writing system switches several times.

What this looks like on the floor. Segmenters commonly treat the boundary between Thai script and Latin script as a word boundary, which severs the English portion from its Thai context. As a result the Thai modifier immediately preceding an English equipment name attaches to a different word, and the unit of meaning shifts. In search, only the English portion is picked up and the context is lost. In translation, English model numbers sometimes get translated.

Which layer. Layer 2, primarily. Register the words that should stay in English in the dictionary so that both the segmentation and the handling are fixed. In addition, Layer 1 has to align full-width against half-width and upper case against lower case.

Polite Sentence-Final Particles — Clues to Speaker and Politeness

Thai has politeness particles that attach to the end of a sentence. A male speaker uses ครับ and a female speaker uses ค่ะ, so the form varies with the speaker’s gender.

What this looks like on the floor. In transcribed meeting minutes, these particles are a clue for inferring who is speaking. Strip them out in preprocessing as words that carry no meaning and speaker separation downstream becomes weaker. In translation the opposite applies. Render them literally and the target text reads unnatural, and drop too many of them and the level of politeness no longer matches the original.

Which layer. It depends on the use case. For meeting minutes, the rule is not to delete them in Layer 1 preprocessing. For translation, the rule is to write into the instructions how politeness should be reproduced at Layer 4. The same particle is something to keep in one use case and something to drop in another. If you have unified preprocessing across all use cases, this is where the conflict surfaces, so it is safer to build preprocessing so that it can be varied per use case.

Building Thai Evaluation Data — The Shortest Path to Talking About Accuracy

Everything above assumes you can measure. Fix a layer without measurement and you will not know whether you fixed it.

The procedure for building Thai evaluation data goes like this.

• Narrow to a single target task. Search only if it is search, translation only if it is translation. 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 invented example sentences. Invented sentences contain no spelling variation, no invisible separator characters, and no Buddhist era dates, so the Layer 1 and Layer 2 problems have been eliminated before you start
• Decide ground truth together with local staff. What counts as correct cannot be settled from the Japan side alone. In translation and classification especially, ground truth does not converge without local operational judgment
• Write the acceptance criteria out in prose first. A natural translation cannot be measured. Reduce it to conditions that can be judged, such as whether it follows the glossary, whether numeric values are preserved, and whether the specified format was used
• Cut a version and freeze it. Adding to or amending the evaluation set midstream destroys comparability with the previous run

And the thing that pays off most in Thai evaluation is tagging each error with a layer label. For every case that came out wrong, record whether it originated in Layer 1, Layer 2, or Layer 4.

Do that and the layer you work on next 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, then and only then is it worth spending money on model selection. An evaluation without labels produces only a single overall percentage, which is not enough to decide the next action.

On the size of the evaluation set, this article does not give a number of items. The appropriate count varies with the target task and with how errors occur, and we have not been able to confirm a generalizable figure against a primary source. In practice it works well to start from the criterion that the set must contain every failure mode you currently know about, and to add to it each time a new failure mode appears.

Breaking Cost Into Five Layers

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

One clarification first. The five cost layers here have numbers that resemble the four processing layers described earlier, but they are not the same thing. The correspondence runs as follows.

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

This article does not quote figures. The range is wide depending on use case, document volume, number of target languages, and the state of your internal documents, and we have not been able to confirm a generalizable market rate against a primary source. Instead, hold on to the differences in the nature of these costs.

The distinction between one-time cost and continuing cost. Cost Layer 1 is close to build-once-and-done. Cost Layers 2 and 5 continue. Cost Layer 3 accrues in proportion to use. Judge on the initial quote without making this distinction and the running cost six months later will come as a shock.

Cost Layer 3 carries a multiplier. The 2.62 factor discussed earlier applies to this layer. Handling the same Thai documents, the number of tokens counted changes with the tokenizer. In document-heavy use cases that difference shows up as a difference in running cost every month.

The most commonly skipped item is Cost Layer 4. Building evaluation data produces an unglamorous artifact and does not make anything visibly work, so it is the first thing cut from a budget. But skip it and every discussion afterward becomes impressionistic. You cannot get past the point where somebody feels the new model seems better.

Cost Layer 5 bites six months in. Dictionaries go stale if left alone. New equipment arrives, new abbreviations are coined, and with each one segmentation accuracy quietly declines. Who updates the dictionary, how often, and based on what input. Without those decisions, the longer the system runs the closer it drifts back to its pre-launch state.

Three Extra Considerations for Thai and ASEAN Sites

Compared with deploying generative AI inside Japan, a Thai site adds three considerations on top.

Regulation Is at a Different Stage in Each Country

In Thailand, ETDA published a new draft of an artificial intelligence act on July 2, 2026. The public hearing period is reported as roughly 30 days. As of August 2026 this law has not been enacted and is not in force. The points contained in the current draft include a framework that sorts risk into three tiers, a requirement for foreign operators to appoint a local representative, an obligation to attach machine-readable markings to AI-generated output, and joint liability that may attach even without fault.

As background, a public hearing was held in June 2025 to consolidate two separate drafts, and the work has remained at the drafting stage since then.

What can be said about practical impact right now is that building to requirements that are not final is premature, while there is value in structuring things so requirements can be added later. Marking of generated output, and logging of the model and the inputs used to generate it, are the kinds of requirements that are hard to add retroactively. Handling the logging design in advance keeps the rework small once the requirements settle.

Note also that the stage differs by country within ASEAN. Vietnam is already at the in-force stage, though this article limits itself to noting the fact that Thailand and Vietnam are at different stages. For the details of each country’s requirements, consult that country’s primary sources.

Running Operations in Three or More Languages

At a Thai site, Japanese, Thai, and English run simultaneously. Reporting to the Japanese head office is in Japanese, the shop floor works in Thai, and equipment vendor documentation is in English.

The thing to settle here is which language is the master. If the master is not designated, discussions start from comparing translated versions against each other, and nobody can decide which one is right. Preprocessing works the same way. Set up normalization and the dictionary in the master language and derive the other languages from the master, and you only have to maintain one set of dictionaries.

Assign Someone to Maintain the Dictionary

The Layer 2 dictionary cannot be maintained by engineers alone. The people who know the correct notation for equipment names and abbreviations are on the shop floor. At the same time, leaving dictionary updates to shop floor goodwill does not last.

What is needed is to define, as a job, who updates the dictionary, how often, and based on which inputs. The realistic approach is to embed it in an existing workflow, for example by including a dictionary addition step in the procedure for bringing in new equipment. Launch without settling this and you will simultaneously have no mechanism for noticing that accuracy is falling.

What to Do in the First 90 Days

Here is a 90 day sequence designed so the order does not get scrambled.

• Day 1 to day 30 — Narrow to one type of document and build only the Layer 1 normalization. In parallel, count how many variants a word that should be one word has fragmented into. That count becomes your progress indicator for Layer 1
• Day 31 to day 60 — Layer 2. Build the internal proper noun dictionary together with local staff. And make sure you schedule sessions where segmentation output is inspected by eye. Watching only the numbers hides how the words that are not in the dictionary are breaking
• 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 solid and you cannot tell whether a difference came from the model or from the input

There is something deliberately left out of this 90 days. Layer 3 tokenizer optimization. Layer 3 works as a cost optimization, but it contributes nothing to isolating an accuracy problem. Use the first 90 days to identify and eliminate the causes of your symptoms, and take up cost optimization once operations are running, by which point you will have the evidence to decide on.

One more thing. Narrowing to one document type is not about limiting scope. It is about making causes visible. Handle daily reports, inspection records, and contracts at the same time and each breaks in its own way, 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 type onward.

Five Common Failures and How to Avoid Them

Swapping the Model First

This is the most common pattern among the consultations we take at Thai sites. A report arrives saying Thai accuracy is poor, and the first response is a model migration. As the use case table in this article shows, translation is the only use case where model selection belongs first, and the other five start upstream.

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

Building Search Before Deciding How Words Are Cut

The state where search, chunking, keyword matching, and evaluation are each using a different segmentation. Each one appears to work on its own, so the problem only surfaces when search accuracy becomes impossible to explain.

How to avoid it. Settle on one segmentation process and one dictionary, and structure everything so that all processes reference them. Build into the design the fact that updating the dictionary requires rebuilding the search index.

Proceeding Without an Evaluation Set

The state where decisions advance on the basis that the new model seems better. You cannot distinguish between the model improving and the questions you happened to test being easier.

How to avoid it. Decide that no model comparison happens until the evaluation set exists. What you can do before there is an evaluation set is the upstream layer work.

Writing Normalization Code in Several Places

The state where the search path, the aggregation path, and the summarization path each contain their own normalization code. Fix Buddhist era conversion in one place and the other paths stay on the old behavior.

How to avoid it. Consolidate the intake path into a single entry point and normalize only there. Establish the rule that downstream only ever receives normalized strings.

Not Assigning Dictionary Updates or Their Frequency

The classic pattern where accuracy is high right after launch and declines over time. New equipment and abbreviations never enter the dictionary, so Layer 2 grows stale bit by bit.

How to avoid it. Build a dictionary addition step into the procedures for equipment installation and new product launch. On top of that, include periodic re-measurement against the evaluation set in operations, so that a decline can be detected as a number.

Frequently Asked Questions (FAQ)

Is Thai generative AI less accurate than Japanese?

It depends on the use case. In Layer 4 centered use cases such as translation and summarization, models do differ in how well they handle Thai. On the other hand, most of what feels worse than Japanese in search and aggregation is a difference in how well Layers 1 and 2 have been prepared. It is often simply that the Japanese documents already have consistent notation and the Thai documents do not. Unless you compare under equalized conditions, you cannot tell whether you are looking at a difference in a model’s language ability or a difference in preprocessing.

Which generative AI is strongest in Thai?

Within what can be confirmed from primary sources, SCB 10X released Typhoon 2 on January 10, 2025, with text models in five sizes from 1B to 70B. There is also Typhoon2-Audio for speech input and output and Typhoon2-Vision with OCR built in. For Southeast Asian languages there is SEA-LION from AI Singapore, covering more than 11 SEA languages, with SEA-LION v4.5 dated May 20, 2026 as the latest. As an evaluation framework there is SEA-HELM. Individual scores and rankings could not be confirmed against primary sources, so this article does not take a position on ranking. The only reliable way to know which one fits your company is to measure on your own evaluation set.

Do we have to build Thai word segmentation ourselves?

You do not need to build the segmentation machinery itself. Existing libraries handle that. What you do have to supply is the dictionary, and specifically the dictionary of internal proper nouns. Because NewMM, the default engine in PyThaiNLP, works by dictionary-based maximum matching, segmentation falls apart around equipment names and abbreviations that are not in the dictionary. That part can only be built by your own organization.

Why does Thai RAG search fail to find things?

Across the consultations we have handled at Thai sites, the cause was frequently at Layer 2. The way the question was segmented and the way the documents were segmented did not agree, so keywords that should match do not match. Cases where internal proper nouns are decomposed differently on the two sides are especially common. Layer 1 is next, where invisible separator characters and notation variation block matching. Changing the model does not change the search results, so a model migration does not address this symptom.

Is Thai generative AI more expensive?

The tokenizer changes how many tokens the same Thai document counts as. The Typhoon paper states that the Typhoon tokenizer is 2.62 times more efficient than GPT-3.5 at tokenizing Thai. Under usage-based pricing that difference feeds straight into the bill. However, this is a comparison between tokenizers processing Thai documents, not a comparison with English. In practice, dictionary maintenance and operational costs often bite harder later than model usage fees do, so it is safer not to build the cost discussion out of model usage fees alone.

How should we measure Thai accuracy?

Sample from real internal documents, decide ground truth together with local staff, write the acceptance criteria out in prose first, and freeze the version. Do not use invented example sentences. They contain no notation variation and no invisible separator characters, so the Layer 1 and Layer 2 problems have been eliminated before you begin. Then tag every error with whether it originated in Layer 1, Layer 2, or Layer 4. With those labels in place, the layer to work on next is decided by data.

Summary

When Thai generative AI fails to deliver accuracy, what is broken is preprocessing, not the model. Here are the key points of this article.

• Thai processing splits into a character layer, a word layer, a token layer, and a meaning layer. The model lives at Layer 4, and swapping only that leaves the upstream breakage in place
• Layer 1 is where strings that look identical but differ underneath get aligned. Buddhist era years, Thai digits, invisible separator characters, and combining order all live here
• Layer 2 is the crux. Because Thai puts no space between words, something has to decide where words are cut. Search, chunking, keyword matching, and evaluation all depend on that decision simultaneously
• NewMM, the default engine in PyThaiNLP, scored 71.18% on the BEST 2010 word segmentation benchmark, against a best available result of 95.60% at that time. Left at the default, it falls apart on your own vocabulary that is not in the dictionary
• Layer 3 affects cost and how much fits. The Typhoon tokenizer is 2.62 times more efficient than GPT-3.5 at tokenizing Thai. This is not a comparison with English
• The dominant layer differs by use case. Translation is the only use case where model selection belongs first, while RAG, chatbots, meeting minutes, document OCR, and classification and aggregation all start at Layer 1 or Layer 2
• Cost splits into five layers. The most commonly skipped is building evaluation data, and skipping it makes accuracy impossible to discuss
• In the first 90 days, work through normalization, then the dictionary, then the evaluation set. Put model comparison last

A consultation about poor Thai accuracy can begin simply by isolating which layer the problem is occurring in. Wanting to take one look at which layer your documents are breaking in, or wanting to talk through only how to build the evaluation, is a perfectly good stage to reach out at. Please get in touch through our contact page.

References

• arXiv PyThaiNLP Thai Natural Language Processing in Python
• arXiv Typhoon Thai Large Language Models
• SCB 10X Introducing Typhoon 2
• AI Singapore SEA-LION
• AI Singapore SEA-HELM Leaderboard
• Mondaq Thailand Releases New Draft Artificial Intelligence Act
• Norton Rose Fulbright Thailand’s draft AI law