RAG Implementation for Factories in Thailand and Vietnam: Cost and Search

“We have been told to adopt generative AI, and we want it to read our own manuals and past trouble reports.” Plant managers and regional IT teams across Thailand and Vietnam are raising this more and more often, and the layer that makes it possible is a RAG implementation. One point deserves to come first, though: if the documents you care about amount to only a few dozen files, you will get there faster and cheaper without building RAG at all. This article covers how to decide whether you need one, how the cost breaks down, how to design search when the manuals are in Japanese and the operators ask in Thai, and the failure patterns that keep projects stuck at pilot stage.

Before a RAG implementation, check whether you can avoid building one

Let us start with the part most articles leave out. RAG is a mechanism you should build only when you cannot reasonably avoid it.

Anthropic, one of the companies developing large language models, states a clear threshold in its own technical write-up (global). If your knowledge base is smaller than 200,000 tokens, roughly 500 pages of material, you do not need a retrieval system at all: you can simply place the entire knowledge base into the prompt. With prompt caching, that route is described as faster and cheaper, and it removes the need to build and maintain a search stack.

Divide 200,000 tokens by about 500 pages and you get roughly 400 tokens per page. Picture the manuals on your own shelf. Ten equipment operating manuals of fifty A4 pages each is exactly where that threshold sits. In other words, if your situation is “we want people to be able to look up ten work standards” or “we have thirty quality-procedure PDFs”, it is more rational to try the load-everything-into-the-prompt approach first, before committing to the heavier investment of a full RAG implementation.

One caveat. Token efficiency varies by language, and Japanese and Thai generally consume more tokens than English for the same content. Treat the 500-page figure as an approximation based on English-language material, and leave headroom when your documents are in Japanese or Thai. If you need a precise answer, run your actual files through a token counter and measure.

The three conditions that make RAG necessary

So when does a RAG implementation genuinely become necessary? Three conditions are enough to decide. If even one applies, building retrieval is worth it.

1. Document volume is well past the threshold. The scope runs to hundreds of files and thousands of pages, far beyond the guideline above. It will not fit in a prompt, so you need a mechanism that pulls out only the relevant part.
2. Documents change frequently. Work standards are revised monthly, trouble reports accumulate weekly. You need a design where replacing the source document changes the answer.
3. Access has to differ by user. Inspection records that only Quality may see, unit-price tables that only Purchasing may see. If the visible scope has to change per questioner, that can only be implemented in the retrieval layer.

The third condition is the one most often overlooked, and in practice the heaviest. If every employee may see every document, the design is simple. In a manufacturing group, however, documents that expatriate staff may open and local staff may not are a real, everyday situation. Whether you need this separation moves the cost figures below substantially.

For the wider picture of adopting generative AI, including how to choose the target process and how to organise the team, see our guide to generative AI implementation and cost. This article goes deep on one layer of that roadmap: connecting your own data to the model.

What is RAG: retrieval, context and generation in three stages

RAG stands for Retrieval-Augmented Generation, that is, generation strengthened by search. The mechanism has only three stages.

Stage one is retrieval. The system takes the user’s question and looks through internal documents for the passages most likely to be relevant. Documents have been split in advance into reasonably sized fragments, known as chunks, and stored as embedding vectors that express meaning numerically. The question is converted the same way, and the closest chunks are pulled out in rank order.

Stage two is adding context. Those fragments are handed to the model together with the question, in the form of “using the material below, answer the following question”.

Stage three is generation. The model composes an answer within the boundaries of the material it was given, and returns it with a pointer to the document and section it relied on.

The critical property is that the model does not memorise your documents. It consults them afresh every time. That is why fixing the document fixes the answer. Replace a revised work standard and, from the next day, the system answers using the new procedure.

How RAG differs from fine-tuning

“Making the model learn our internal data” sounds like fine-tuning to many people. Three approaches, compared:

For internal manual search, fine-tuning is a poor fit. As a way to make a model remember facts it carries a high update cost, and it removes the ability to show which document the answer came from. On a factory floor, evidence is not optional. The practical division of labour is: facts by retrieval, tone and format by instruction in the prompt.

Where RAG works in a factory, and where it does not

A common way for a RAG implementation to fail is to point it at work it was never suited for. Draw the boundary early.

Where it works: questions whose answers are written in documents

• Equipment maintenance manual search. “What is the first response when alarm E042 appears on this model of filling machine?” answered across several operating manuals at once.
• Cross-year search of past trouble and defect reports. Finding how the same defect was handled in previous years. This is where undocumented, person-dependent knowledge gets surfaced.
• Queries against work standards and company rules. Leave application deadlines, tool check-out procedures, and similar questions that the rules answer but nobody reads.
• Part and drawing specification checks. Material, tolerance, whether a substitute part is permitted, and other facts stated in the specification.
• First-draft answers to customer technical enquiries. Drafting a reply from past responses and specifications, for a human to verify before sending.

Where it does not work: numbers and current state

• Aggregating production results or stock levels. “Last month’s utilisation by line” and “current parts stock” are numbers in a database, not sentences in a document. That is the territory of BI tools and your production management system, and asking RAG will produce wrong figures. Aggregation belongs to the system that does the aggregating.
• Real-time equipment status. “Is machine three running right now?” is a job for IoT-based monitoring. On collecting and visualising machine signals, see implementing factory IoT monitoring.
• Approval and record-keeping themselves. Submitting daily reports and storing inspection records are workflow tasks. If paper forms are still in circulation, moving first to electronic forms and a paperless factory is the correct order of work.

The rule of thumb is one line. If the answer exists as prose in a document, use RAG. If the answer exists as a number in a system, use BI or your core systems. Skip this separation and you invite the verdict “this so-called AI cannot even tell me the stock level”.

Budget a RAG implementation in five cost layers

Here is the core of the article. A RAG implementation cannot be judged from a single lump-sum quotation. Split it into the five layers below and you can see where your own organisation will swell.

Why layer 1 dominates in a factory

General articles about RAG start at layer 2, with vector databases and embeddings. Factory reality is different. The documents you want to consult are usually not in a searchable form at all.

The maintenance manual is a paper binder handed over by the equipment maker. The drawing is a scanned PDF whose contents are an image, not recognised text. Past trouble reports are long paragraphs crammed into spreadsheet cells with photographs pasted alongside. Quality records are scans of handwritten forms. Plants that start from exactly this position are not unusual.

RAG searches text, so a PDF that is still an image is invisible to it. That is where OCR comes in. Securing acceptable recognition accuracy on handwritten forms mixing Japanese and Thai is, on its own, a project-sized question. On that upstream step, see AI-OCR for back-office automation.

Even after text extraction, preparation continues. Three generations of the operating manual for the same machine exist and nobody knows which is current. Revision history is embedded in the body text, so the old and new procedures sit in the same file. No external party can make these calls for you. Only your own staff can decide which document is the valid one, and building that catalogue of current versions is unavoidably internal work.

Japanese domestic cost benchmarks (Japan-specific)

Published benchmarks for RAG implementation cost in Japan are as follows. Every figure in this subsection is based on cases inside Japan, and amounts are stated in JPY without conversion.

A line-item breakdown is also published (Japan-specific). The point worth noticing is that the three named line items do not add up to the totals.

The subtotals: for the PoC, 300,000 + 100,000 + 200,000 at the low end is JPY 600,000, and 500,000 + 100,000 + 500,000 at the high end is JPY 1.1 million. For the production build, 1 million + 600,000 + 500,000 is JPY 2.1 million at the low end, and 1.5 million + 600,000 + 2 million is JPY 4.1 million at the high end. Comparing like for like against the published totals of JPY 1–3 million for a PoC and JPY 3–10 million for a production build, the residual is JPY 0.4–1.9 million for a PoC and JPY 0.9–5.9 million for a production build. Note that these residuals pair low end with low end and high end with high end; a project sitting at the bottom of the total range and the top of the item range would leave almost nothing over.

What is that residual? The sources do not itemise it, but the plausible contents are scoping, project management, and layer 4, integration with existing systems and access control design. On the high side of a production build, that would put more than half of the total in this area. Keep the shape of it in mind: the vector database is JPY 600,000, and permissions plus integration are larger than that.

Global cost benchmarks (global)

Global benchmarks for RAG development are worth seeing alongside. The figures below are global-market levels quoted in US dollars, and they are left in US dollars because the source states no exchange rate.

Dividing at both ends: a production RAG is 2.7 to 3.2 times a simple one (40,000 divided by 15,000 is about 2.7 at the low ends, 80,000 divided by 25,000 is 3.2 at the high ends). An on-premise enterprise RAG is a further 2.0 times at the low ends (80,000 divided by 40,000) and about 1.9 times at the high ends (150,000 divided by 80,000). Note that the source leaves the on-premise band open at the top, at USD 150,000 and above, so the real multiple can be larger than 1.9.

That source also states plainly that the largest cost driver is not the model itself but the access control layer, integration with existing systems and compliance work. It agrees with what the Japanese breakdown implies. Before worrying about model API fees, put budget behind permissions design.

Designing permissions when one knowledge base serves several countries

For a group operating plants in Thailand, Vietnam and elsewhere, layer 4 carries an extra question that a single-site project never meets: who, at which site, may see which document. Two failure modes recur.

The first is defining permissions site by site as the roll-out proceeds. Site A gets a rule set, site B invents another, and within a year nobody can state the group-wide rule. The alternative is to fix the axes once, before the first site goes live: site, function, and document class. A person’s visibility is then the intersection of those three, and a new site is onboarded by mapping its people onto axes that already exist rather than by inventing policy again.

The second is leaving the identity source undecided. If the group directory holds the authoritative list of employees but transfers, secondments and contractor accounts are maintained locally in each country, the search layer will keep showing documents to people who moved on months ago. Decide which system is the single source of truth for identity, decide how a mover or leaver propagates to the knowledge base, and decide how temporary and contractor staff are represented, before any documents are indexed. Retro-fitting all of this after a successful pilot is close to a rebuild, which is one reason pilots stall.

It is also worth stating explicitly that this is a business decision, not an IT one. Whether a Thai process engineer may open a Vietnamese site’s defect reports is a question for the group’s management and HR, not for the vendor configuring the index.

Present layers 1 to 4 as investment and layer 5 as annual running cost

When you write the funding request that goes to the parent company, regional headquarters or group IT, fix the definitions in advance. This is where splitting into layers pays off.

• Investment, or initial cost, equals layers 1 + 2 + 3 + 4, including scoping and project management. Document preparation, search infrastructure, UI, integration and access control.
• Annual running cost equals layer 5 only. Model usage fees, the work of reflecting document updates, and internal effort on accuracy improvement.

Mixing the two breaks the request. The classic accident is including the first year of running cost inside the investment figure and then subtracting running cost again inside the return calculation, counting it twice.

Check it against a published case from Japan (Japan-specific). An organisation with 300 employees, targeting the IT department’s FAQ, ran a PoC at JPY 1 million over two weeks, then a production build at JPY 6 million over three months, with monthly operation of about JPY 200,000. Under the definitions above:

• Investment, layers 1 to 4 = PoC JPY 1 million + production JPY 6 million = JPY 7 million
• Annual running cost, layer 5 = JPY 200,000 x 12 months = JPY 2.4 million
• Three-year total cost of ownership = JPY 7 million + JPY 2.4 million x 3 = JPY 14.2 million
• Five-year total cost of ownership = JPY 7 million + JPY 2.4 million x 5 = JPY 19 million

The payback formula is investment divided by (annual saving minus annual running cost). For this case, JPY 7 million divided by (annual saving minus JPY 2.4 million). The part that matters: the moment the annual saving falls below JPY 2.4 million, the payback calculation stops existing. Long before any return on investment, running cost alone puts the project underwater.

If you assume an annual saving of JPY 4.8 million, then 7 divided by (4.8 minus 2.4) gives payback in about 2.9 years. That JPY 4.8 million is not a sourced figure; it is a placeholder to show the shape of the formula. When you prepare your own request, measure the time currently spent searching in the target process and fill that cell with your own numbers. A saving figure with no measurement behind it will not survive review.

One more caution: the sources do not state whether the Japanese benchmark of JPY 100,000–500,000 per month includes internal effort on document updates and accuracy improvement (Japan-specific). Assume layer 5 also carries internal labour and budget your own people’s time separately.

When accuracy disappoints, the cause is usually retrieval, not the model

After a pilot ends, the most common verdict is “it is not as clever as we expected”. Break the cause down and most of it sits on the retrieval side rather than the generation side. A model can only answer within the material it is handed, so if the right material never arrives, no amount of model capability will produce the right answer.

Contextual retrieval, hybrid BM25 and reranking, in three steps

Anthropic has published measured results for improving the retrieval side (global). Every figure below uses the same baseline: conventional embeddings-only RAG, comparing the retrieval failure rate when the top 20 chunks are retrieved.

Confirming the arithmetic: 5.7% falling to 3.7% is 1 minus 3.7 divided by 5.7, about a 35% reduction. To 2.9% is 1 minus 2.9 divided by 5.7, about 49%. To 1.9% is 1 minus 1.9 divided by 5.7, about 67%.

This is the most commonly misread passage in the field. The measurement is global, not country-specific, and it means the retrieval failure rate fell by 67%, not answer accuracy rose by 67%. In absolute terms the failure rate moved from 5.7% to 1.9%, a fall of 3.8 percentage points. If a vendor proposal claims “67% higher accuracy”, ask what baseline was used and what exactly was measured.

Translated into working language, the three methods are:

• Contextual embeddings attach a short description of what each fragment is and where it sits before the fragment is embedded. On its own, “adjust the pressure to 0.3 MPa” tells you nothing about which machine it belongs to. Add the context “pressure adjustment step within the daily inspection procedure for filling machine B” and the fragment becomes retrievable.
• Hybrid BM25 combines meaning-based retrieval with conventional keyword matching. It handles model numbers and part codes, which meaning cannot reach but exact strings can. In factory documents this matters a great deal.
• Reranking takes a deliberately generous set of candidates and reorders them by relevance to the question using a separate model.

How chunking goes wrong

Splitting accidents that recur in factory documents:

• A table is cut in half. A specification table is split at a chunk boundary, leaving the header row and the value rows in separate fragments. Values then get retrieved with no indication of what they measure.
• Drawing notes get separated from the drawing. A note such as “material changes require QA approval” is stored apart from the figure it applies to.
• Revision history is mixed into the body. Text describing the superseded procedure gets returned as if it were current. The root cause is that the old version was never excluded during preparation.
• Heading hierarchy is lost. A heading such as “4.2 Handling abnormalities” is cut away from its body, and nobody can tell which chapter’s handling it describes.

The remedy is to stop splitting by raw character count and split on heading structure and table boundaries instead. Then either keep a table whole inside one chunk, or duplicate the header onto every row so it survives the split.

Design the system so it can say “I do not know”

To be trusted on the floor, decide these three things at the start.

1. Always return a link to the source document. Show the document name and page beneath the answer, with the original openable. Whether a human can verify the answer determines whether the tool gets adopted.
2. When no relevant document is found, return “no matching description was found” rather than a guess. This is implemented through prompt design and by setting a minimum retrieval score. A system that returns plausible falsehoods loses trust the first time it reaches the floor.
3. Match the assertiveness of answers to the task. For safety-related procedures, append a standing line instructing the reader to check the original document before starting work.

Designing a system that answers Thai questions from Japanese manuals

Here is the issue specific to plants in Thailand and Vietnam that other guides almost never address. Technical documents are in Japanese or English; the operators asking questions work in Thai, Vietnamese or Burmese. How you design around that mismatch decides whether the system is used.

Three options for where translation happens

There are three approaches.

The realistic answer is not to pick one of the three but to combine them. The base is options 2 and 3 together: translate the question into Japanese as well, gather candidates in parallel with direct multilingual retrieval, and merge them with reranking. On top of that, maintain a formal Thai version under option 1 only for documents where a misreading leads directly to an incident, such as safety training material and emergency response procedures. Translating and dual-managing everything makes both initial cost and update effort scale with document volume, so the scope has to be chosen deliberately.

The Thai script has no spaces between words

The writing system is the detail most often missed in search design. Thai does not put spaces between words. Sentences are written as continuous strings, so keyword search first requires word segmentation to estimate where the boundaries lie.

Japanese has the same property, but Japanese morphological analysis is commonly bundled into search products, whereas Thai segmentation is often not enabled in a default configuration. When you add keyword matching such as the BM25 hybrid described above, a system with no Thai segmentation produces a particular failure: retrieval works acceptably in every language except Thai. In a multilingual deployment, evaluate retrieval quality separately for each language. Testing in Japanese, concluding “it works well”, and never testing in Thai is the textbook version of this mistake.

Vietnamese has spaces, but they separate syllables rather than words: may nen khi (air compressor) is three syllables and one term. A default tokeniser that splits on whitespace will break such terms apart, so keyword search will not behave as you expect unless you supply a compound-word dictionary or fall back to n-grams. On top of that, you will see a mix of properly toned text and input with the diacritics omitted, so add normalisation of that variation to the preprocessing step.

Do not let model numbers, abbreviations or proper nouns be translated

This is the most fragile point in any multilingual set-up. Pass text through machine translation unfiltered and equipment model numbers and in-house abbreviations get translated too. Once a model number has been translated, that string no longer matches anything in the index.

The remedy is a do-not-translate list: equipment model numbers, part numbers, drawing numbers, internal system names, department abbreviations, standard designations. Only your organisation can compile this glossary, but once built it is reused across translation, retrieval and answer generation. Within a RAG implementation, it is one of the tasks with the clearest return for the effort.

Answer in the questioner’s language, cite in the original

The operating pattern we recommend is this:

• The body of the answer comes back in the language of the question. Ask in Thai, get Thai.
• Source documents are shown as links in their original language, untranslated. A Japanese maintenance manual is linked as the Japanese PDF.
• Quoted passages are shown with original and translation side by side. A translation alone cannot be checked against the original on the floor.

That way an operator grasps the substance in their own language and can go to the original when something looks off. When a Japanese or regional manager opens the same screen, they can see exactly which document and which passage produced the answer. For a system operating as a multilingual chatbot, keeping the original-language link is the practical control that stops a translation error from becoming an incident.

When each site’s documents are in a different language

A group knowledge base adds a further wrinkle. The Thai plant’s work standards were written in Thai and Japanese, the Vietnamese plant’s in Vietnamese and English, and group-level standards exist only in the parent company’s language. Cross-site search then has to answer questions that a single-site design never asks.

Treat the language of each document as a first-class metadata field from the start, alongside site, function and version, rather than inferring it later from the file. That single field is what lets you evaluate retrieval per language, restrict a search to group-level standards when local variants would confuse the answer, and tell a user that the authoritative text exists only in another language.

Second, decide which documents are authoritative across the group and which are local. If a Thai engineer’s question is answered from a Vietnamese site’s local procedure, the answer may be technically retrievable and still wrong for that plant. The question here is authority, not permission: even where access is allowed, the retrieval scope for a routine operational question should usually default to the asker’s own site plus group-level standards, with cross-site search offered as a deliberate action.

Third, keep an evaluation set in every language you serve, not only in the language your project team happens to speak. This is the same point as Thai segmentation, one level up: a group platform that has only ever been judged in one language has only ever been judged for one site.

Regulatory and data questions for a RAG implementation in Thailand

The ground rules for building in Thailand (Thailand-specific).

In Thailand, PDPA is the legal foundation and the AI law is still in draft

As of 2026 Thailand has not yet brought a standalone AI law into force. The ETDA, the Electronic Transactions Development Agency, is consolidating earlier drafts into a single risk-based AI framework, and the expected contents include classification of prohibited and high-risk uses, mandatory impact assessments, and tighter treatment of automated decision-making. It has not been enacted, so do not describe it as being in force in internal documents.

The foundation for compliance today is therefore the PDPA, Thailand’s Personal Data Protection Act. In the context of a RAG implementation, the question is whether personal data has found its way into the knowledge base. Because an AI framework may add obligations later, a design that can already explain which documents are stored where and under whose authority will absorb regulatory change with less rework. Confirm the details and their applicability to your own case in writing with the competent authority or a local specialist.

Keep HR, health and payroll documents out of the knowledge base

As a working rule, make the following documents out of scope by default:

• Personnel evaluations, transfers and disciplinary records
• Health check results and medical records
• Salary, bonus and individual working-hour details
• Applicant CVs and interview notes

Being able to search these looks convenient, but once they are in the index any failure of permissions design becomes an immediate disclosure of personal data. “It seems useful, so put everything in” is the most dangerous judgement available. If such material genuinely has to be covered, build it as a completely separate index and a separate system with a restricted user list.

Reconciling parent-company IT policy with local data residency

Group IT policy commonly requires data to be held in the home country or in a named region, while local requirements point elsewhere. A RAG implementation makes this concrete because it creates four distinct kinds of data, each of which may end up in a different place: original documents, extracted text, embedding vectors, and the logs of questions and answers. Check the location of all four separately. Do not stop at checking the region of the model API. Configurations where the vector database and the logs sit in another region are common.

The practical instrument is a simple matrix: the four data types as rows, and for each one the storage location, the legal basis, the retention period and the owner. Fill it in before procurement rather than after, and take it to both sides of the argument at once. Group IT can then approve or reject a specific arrangement rather than a general intention, and the local entity can state which parts it cannot accept. Where the two cannot be reconciled by a single region, the usual resolution is to split by data type: originals and logs stay local because they carry the most identifiable content, while embeddings and application components sit in the regional platform that group IT already governs.

Two points are worth agreeing in writing while the design is still on paper. First, whether question-and-answer logs count as personal data in your interpretation, since they carry the user identity alongside the query. Second, who is allowed to use those logs for accuracy improvement, and whether that includes the vendor. Both are far cheaper to settle before launch than after a group audit.

Where Thailand currently stands, in numbers

There is useful survey evidence on the digital maturity of Thai organisations (Thailand-specific). The Thailand Digital Outlook 2026 survey, covering 834 businesses nationwide, found average digital maturity at 2.12 on a 4-point scale, reaching the middle band for the first time. That is up from 1.56 in 2025, a rise of 0.56 points or about 36%. Even so, 2.12 out of 4 represents only about 53% of the scale. The areas identified as weak are digital product and service development, and R&D.

Meanwhile only about 18% of Thai companies have actually embedded AI into their operations, according to survey work cited from the ETDA (Thailand-specific). Put the other way, more than 80% have not.

And about 65% of manufacturing organisations cite concerns about data quality as a major barrier to adopting AI (Thailand-specific). That is the same reality this article describes as layer 1, document preparation and digitisation being the largest cost, seen from another angle. The recognition that the data is not ready is already widely shared on the ground.

Regulatory and data questions for a RAG implementation in Vietnam

Vietnam’s situation differs from Thailand’s (Vietnam-specific).

Vietnam’s AI law is already in force

Vietnam’s National Assembly passed Southeast Asia’s first standalone AI law in December 2025, and it took effect in March 2026. It introduces risk classification, accountability, and governance obligations for high-impact AI systems.

What matters for a RAG implementation is judging which risk category your own use falls into. Search assistance over internal manuals would appear limited in impact, but the treatment can change if those answers feed into personnel evaluation or hiring decisions, or if they are used as work instructions with direct safety consequences. Confirm decree numbers, specific procedures and the availability of any incentives in writing with the competent authority or a local specialist. This article deliberately does not go into the detail of the instruments.

An accountability obligation implies that you may need to be able to record which documents were the basis, which model produced the answer, and when. The design principle stated earlier, always returning a link to the source document, is therefore reasonable from this angle too, not only for winning trust on the floor.

93% of Vietnamese firms adopting or considering AI, 13.8% deployed enterprise-wide

According to Deloitte research, 93% of Vietnamese companies have adopted or are considering AI, the highest level in Southeast Asia. Yet only 13.8% have deployed it enterprise-wide (both figures Vietnam-specific).

The gap between those two numbers is 79.2 points, and of the companies adopting or considering, only 13.8 divided by 93, about 15%, have reached enterprise-wide deployment. Stopping at pilot stage is the norm, not the exception.

Why do pilots stall? Return to the cost structure and the reason becomes visible. A pilot builds layer 1 through part of layer 3: a small set of documents tidied up and a chat screen attached. The wall in front of enterprise-wide deployment is layer 4, integration with existing systems and access control design. That layer requires taking stock of permissions department by department and building a mechanism that follows staff transfers, which is organisational work more than technical work. Try to reach enterprise-wide deployment on a pilot-sized budget and this is the layer where you stop.

Six patterns that make a RAG implementation fail

The material so far, restated as six failure patterns.

1. Loading everything in without organising the documents. Superseded and current versions go in together, the old procedure comes back as an answer, and trust is gone. The remedy is to treat the inventory and version control of target documents as layer 1 work with effort budgeted against it.
2. Leaving access control design until later. The pilot is built with everyone able to see everything, and adding permissions for production turns into a rebuild. As the cost breakdown shows, permissions are among the heaviest layers. Include them in the design from the start.
3. Running a pilot with no evaluation criteria. Judging by “how it felt to use” produces divided opinions and no decision. Building the evaluation set first, described below, resolves this.
4. Not naming an owner for document updates. Six months after go-live the documents are stale, nobody is fixing them, and answer quality drifts down. Write document update effort explicitly into layer 5 and name the responsible department before launch.
5. Halting the whole project on “the AI got it wrong”. RAG is not a mechanism with a 100% correct-answer rate. What matters is whether you have a team that can separate a given error into retrieval or generation and then fix the chunking or the retrieval method. Decide up front that errors will be logged and fed into improvement rather than used to stop the work.
6. A vague line between in-house and outsourced work. Neither “leave it all to the vendor” nor “do it all ourselves” works. The next section draws the line.

Where to draw the in-house and outsourced line, and eight questions for vendors

What only your organisation can do

• Selecting target documents and fixing the valid version. Only the site can judge which procedure is current.
• Building the evaluation set. A mapping from questions that genuinely arise on the floor to the document passages that answer them. This cannot be produced without your own knowledge.
• Deciding access policy. Who may see how far is a management and HR decision.
• Maintaining the glossary. The do-not-translate list of model numbers and abbreviations.

What is suited to outsourcing

• Building the search infrastructure: vector database, embeddings, index design
• Implementing access control, with policy from you and implementation from outside
• Integration with existing systems: production management, document management, identity platforms
• Chunking design and retrieval tuning, including work to optimise hybrid retrieval
• Executing the digitisation process, including OCR

On selecting a vendor in Thailand, see also how to choose a system development company in Thailand.

Eight questions to put to a vendor

Items to settle while you are receiving proposals.

1. How will you measure accuracy? How many evaluation questions, and which metrics? Will you report retrieval failure rate separately from answer correctness?
2. What is the baseline? State the comparison behind any claim of improved accuracy.
3. How will access control be implemented? Filtered at retrieval time, or removed after retrieval? How does it follow staff transfers?
4. When a document is updated, what is the procedure and elapsed time before answers reflect it? Automatic or manual, and who performs it?
5. Will you evaluate retrieval quality in Thai and Vietnamese separately from Japanese or English? Is word segmentation in place?
6. Where is data stored? Answer for all four: original documents, extracted text, vectors, and question-and-answer logs.
7. How is the behaviour designed when there is no answer? Is there a mechanism that prevents a guess being returned?
8. If the contract ends, what remains with us? Can we take the prepared documents, extracted text, evaluation set and glossary? Can they be exported in a form not locked to a specific product or licence?

The eighth question matters most. The highest-value asset created by a RAG implementation is not the search infrastructure but the prepared documents and the evaluation set. Check that your contract leaves those with you.

A four-step route to a working RAG implementation

The path can be organised into four steps.

Step 1: narrow to a single process

Absorb requests from several departments at once and both document types and permissions become complicated immediately. Start with one process. Choose it on three criteria: a high proportion of documents already digitised, a high frequency of questions, and simple access separation. Maintenance manual search and internal rule enquiries are the areas most often selected.

Step 2: build a 30-question evaluation set first

Before the pilot starts, collect 30 questions that genuinely arise on the floor and write down, for each, the document name and the passage that constitutes the correct answer. This is the single most important preparation in a RAG implementation.

Mix these types into the 30:

• Questions answerable from one place, straightforwardly
• Questions that require cross-referencing several documents
• Questions whose answer is not in the documents at all, where “no matching description was found” is the correct response
• Questions containing model numbers and abbreviations
• Questions written in Thai or Vietnamese

A pilot without this data cannot be judged pass or fail. With it, you can compare several vendors’ proposals on identical ground and keep measuring the effect of improvements after go-live. It takes time from your own staff, and it cannot be outsourced.

Step 3: judge the pilot

Test with a limited document set and a limited group of users, and score with the 30 questions from step 2. The judgement is not “was it useful” but how many were answered correctly, how many retrieved the wrong document, and how many correctly returned “I do not know”. For each error, record whether retrieval failed to find the right document, or whether the right document was retrieved and the answer was still wrong. The first calls for retrieval-side work, the second for revisiting the prompt or the chunking.

As a duration guide, Japanese benchmarks put a PoC at 2–6 weeks (Japan-specific).

Step 4: production build and start of operation

Production work is mostly layer 4, integration with existing systems and access control design. In parallel, settle the layer 5 operating arrangements: who owns document updates, who receives reports of wrong answers, and how often the evaluation set is re-run to confirm accuracy. Go live without those three and the system will be unused within six months.

As a duration guide, Japanese benchmarks put a production build at 2–4 months (Japan-specific).

Frequently asked questions about RAG implementation

What is RAG?

RAG, retrieval-augmented generation, is a mechanism that searches your own documents for passages relevant to a question, hands them to a large language model, and has the model compose the answer. The model does not memorise your documents; it consults them each time, so updating a document updates the answer. The ability to show the source document is an equally important property for enterprise use.

How much does a RAG implementation cost?

Japanese benchmarks put a PoC at JPY 1–3 million, a production build at JPY 3–10 million, and monthly operation at JPY 100,000–500,000 (Japan-specific). Global benchmarks put a simple RAG at USD 15,000–25,000, a production RAG at USD 40,000–80,000, and an on-premise enterprise RAG at USD 80,000–150,000 and above (global). In a factory, however, if documents remain on paper or as scanned images, layer 1 digitisation and preparation will run above these levels. In the funding request, present layers 1 to 4 as investment and layer 5 as annual running cost, separately.

Should we choose RAG or fine-tuning?

If the goal is searching internal documents, start with RAG. Fine-tuning requires retraining every time a document changes and cannot show the source document. Fine-tuning does have a role where you need to fix the tone or output format of answers. The practical division is facts by retrieval, consistency of expression by prompt instruction or fine-tuning.

Can we build RAG if our manuals exist only on paper?

Yes, but digitisation comes first. Paper and scanned-image PDFs are not searchable as text, so OCR is required. That step is layer 1, and in a factory it is where cost tends to concentrate. For forms that are handwritten or mix Japanese and Thai, start by verifying recognition accuracy. The realistic route is to narrow the scope and digitise in order of how frequently a document is consulted.

Can someone ask in Thai and search a Japanese manual?

Yes, with the right design. There are three approaches: translate the documents and hold both versions, translate the query and then search, or search directly with multilingual embeddings. In practice, combining the latter two and maintaining a formal Thai version only for safety-critical documents is the workable pattern. In addition, Thai has no spaces between words, so word segmentation is required; without it, retrieval fails in Thai alone. Build the do-not-translate glossary for model numbers and abbreviations at the same time.

How long does a RAG implementation take?

Japanese benchmarks put a PoC at 2–6 weeks and a production build at 2–4 months (Japan-specific). In the published case of a 300-employee organisation targeting its IT department FAQ, the PoC took two weeks and the production build three months. Those durations assume documents are already digitised. If digitisation from paper or scanned images is needed, budget that step separately.

Summary: the five layers in one page

The key points, arranged along the five cost layers.

• Layer 1, document preparation and digitisation. The layer most likely to be heaviest in a factory. Organising paper, scanned PDFs, drawings and spreadsheets, and fixing which version is valid, can only be done in-house. Before you begin, check whether the scope is under 200,000 tokens, roughly 500 pages, in which case consider skipping RAG and placing the material into the prompt (global).
• Layer 2, search infrastructure. In the Japanese breakdown, the vector database sits at JPY 600,000 for a production build (Japan-specific). Relatively light.
• Layer 3, application and UI. The more it is embedded into tools people already use, the more it sticks.
• Layer 4, integration and access control design. This is where the residual in the Japanese breakdown sits, and where the global source places the main cost drivers. It is also the layer where enterprise-wide roll-out stalls.
• Layer 5, operation. Model usage fees, document updates, internal effort on accuracy. Keep it out of the investment figure and present it as annual running cost.

On accuracy, the main battleground is retrieval. Stacking contextual embeddings, hybrid BM25 and reranking in sequence reduced the retrieval failure rate from 5.7% to 1.9%, a 67% reduction, against a baseline of embeddings-only RAG (global). That is a reduction in the failure rate, not a 67% rise in accuracy.

Then there is language. In plants in Thailand and Vietnam, the language of the technical documents and the language of the operators do not match. Choose where translation happens from the three options, handle Thai word segmentation, and keep model numbers and abbreviations out of the translation. Answer in the questioner’s language and cite sources in the original with links. For a group platform, add language as metadata, keep an evaluation set per language, and separate group-level standards from site-local documents. Design to that level and the system gets used.

On regulation the two countries differ: Thailand rests on the PDPA with the AI law still in draft (Thailand-specific), while Vietnam’s AI law has been in force since March 2026 (Vietnam-specific). Confirm the details in writing with the competent authority or a local specialist.

If you are considering a RAG implementation and would like nothing more than help separating which documents to start with, that is a reasonable place to begin. We can look together at whether the material in front of you is at a scale that warrants building retrieval, or small enough to put into a prompt. We are also happy to discuss multilingual search design and how far to integrate with an existing production management system. Please get in touch through our contact page.

References

• Anthropic, “Introducing Contextual Retrieval” https://www.anthropic.com/news/contextual-retrieval
• GXO, “RAG implementation cost breakdown” (2026-04-14) https://gxo.co.jp/column/rag-implementation-cost-breakdown-2026
• AITIP, “RAG construction steps and cost benchmarks” https://aitip.jp/rag-construction/
• ScalaCode, “RAG Development Cost” https://www.scalacode.com/blog/rag-development-cost/
• Bangkok Post, “AI adoption helps Thai firms become digitally mature” https://www.bangkokpost.com/business/general/3283789/ai-adoption-helps-thai-firms-become-digitally-mature
• Bangkok Post, “Data quality concerns a barrier to adoption of AI” https://www.bangkokpost.com/business/general/3051260/data-quality-concerns-a-barrier-to-adoption-of-ai
• DataGuidance, “Thailand: ETDA announces AI 2026 strategy to promote trust” https://www.dataguidance.com/news/thailand-etda-announces-ai-2026-strategy-promote-trust
• Vietnam Briefing, “Vietnam’s AI Law: Regulatory Milestone and Business Implications” https://www.vietnam-briefing.com/news/vietnams-ai-law-regulatory-milestone-business-implications.html/