RAG Enterprise Adoption 2026｜The Split Between PoC and Production

Requests to let generative AI read internal rulebooks, design specifications and past troubleshooting records have become a routine part of our conversations with manufacturers. Enterprise RAG adoption has visibly accelerated through 2026 as the standard answer to that request. Just as often, though, we hear the other version of the story — the pilot ran, everyone was impressed for a fortnight, and then the project quietly stopped short of production. This article is not about how to build a RAG system. It is about how to decide whether your company should invest in one at all. What separates the companies that stall at proof of concept from the ones that reach production, which cost ranges are realistic, and the volume of work at which the payback arithmetic actually closes — set out in the order you need them before you write the approval request.

What RAG Actually Is — Levelling the Vocabulary Before the Investment Decision

RAG stands for Retrieval-Augmented Generation. It describes a system that, before asking a generative model to answer anything, first searches your internal documents for the relevant passages, retrieves them, and hands them to the model as the evidence from which the answer must be built.

For the purposes of an investment decision, there is only one structural fact you need to hold on to. RAG is a two-storey building — retrieval downstairs, generation upstairs. To the person using it, the whole thing looks like a chat box pointed at company knowledge. Internally, a retrieval step runs first and pulls out the fragments of text whose meaning is closest to the question, and the answer is then assembled strictly within the boundaries of what those fragments say. If the answer is not written on the paper that was handed over, no amount of model horsepower will produce it.

From that structure, the questions RAG handles well and the questions it handles badly follow directly.

If you start a pilot without sharing this boundary internally, users will spend their first week testing exactly the three categories the system cannot handle, watch it fail, and conclude that the technology is useless. The system behaves precisely as designed and the evaluation collapses anyway. Put the shape of an answerable question, with concrete examples, on the table at the very first review meeting.

This article does not cover the engineering that raises retrieval accuracy — chunking strategy, reranking, embedding choices and the rest of the build-side design work. If you have already decided to build and want the construction detail, our companion piece RAG implementation cost and process for multilingual factory knowledge search in Thailand covers that ground in depth. What follows sits one step earlier, and deals only with the material you need to decide whether to build at all.

The RAG Adoption Split — What Actually Separates the Companies That Stall

Here is the substance of the matter. For any company weighing enterprise RAG, the single largest question is whether the money spent will ever reach production.

Two Gartner Forecasts That Mark the Trap

In a press release dated 29 July 2024, Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025. The causes it named were poor data quality, inadequate risk controls, escalating costs, or unclear business value.

Gartner then issued a tighter, more pointed forecast in a press release dated 26 February 2025. By 2026, organisations will abandon 60% of AI projects that are not underpinned by AI-ready data. The qualifier is the part that must not be skimmed. This is not a claim that 60% of all AI projects fail. It applies specifically to projects that are not supported by data prepared to a state where AI can use it. That limiting clause is exactly where the practical value of the forecast sits.

The same release reports a survey of 248 data management leaders conducted in the third quarter of 2024, in which 63% of organisations said they either did not have AI-ready data management practices in place, or did not know whether they did. Two organisations in every three cannot tell you whether their own data is in a state that AI can work with.

Canon IT Solutions’ Measured Results Show the Model Is Not the Problem

Forecasts alone rarely change anyone’s mind, so it is worth looking at published figures from a Japanese company that actually ran RAG internally. Canon IT Solutions published a technical report on a trial deployment of RAG at its employee support centre. Real enquiries were fed into the system as-is, and staff scored whether the responses were genuinely useful. A total of 228 cases were evaluated.

The results were candid. Only around one third of responses were rated “Good”. The interesting part comes next, because the breakdown of causes behind the “Bad” ratings was published as well.

I consider this the first table any company considering RAG should look at. Only 12% of bad answers were caused by the generative model itself. The remaining 88% came from source documents that were incomplete or badly organised, and from failure to find the right document in the first place. The territory that “just switch to a smarter LLM” can reach is overwhelmingly the smaller share.

This is where the two-storey description from the previous section earns its keep. The ground floor — retrieval, and the state of the documents sitting behind it — decides whether the whole thing succeeds, while the upper floor barely registers as a problem at all. These are results from a single company’s trial, so your distribution may differ. But if your numbers land anywhere near this shape, then a proposal built around model selection and parameter counts is addressing roughly one tenth of the actual problem. That is a useful lens to carry into vendor meetings.

Split Point 1 — Deciding to Clean the Data Later Means You Have Already Lost

The largest single factor separating companies that stall at pilot from companies that reach production is how they treat data quality. In its analysis of why RAG projects fail, AQUA LLC notes that data preparation consumes 40% to 60% of total project effort, and that most organisations badly underestimate it.

In concrete terms, the problems look like this. Two versions of the same policy sit on the server and retrieval picks up the older one. A PDF was produced by scanning and carries no text layer at all, so it never enters the search index. A document is nothing but a table with no explanatory prose, so a retrieved fragment gives no clue what the table is about. Text is written in abbreviations that only one department understands, so the vocabulary never matches the question. A shared folder that nobody maintains still holds a work instruction that was withdrawn three years ago.

None of these are problems that RAG technology solves. Worse, none of them surface during a pilot. A pilot narrows the corpus to a few dozen documents, and those few dozen are tidied by hand before loading, which is precisely why accuracy looks good. Then production loads several thousand documents, every one of the problems above erupts at once, and accuracy collapses. This is the classic route by which a successful pilot becomes a failed rollout.

The countermeasure is straightforward. When selecting pilot documents, deliberately mix documents you have cleaned with documents loaded exactly as they are today. Measuring how much the untouched documents drag performance down gives you the raw material for estimating the data preparation effort that production will require. If a vendor produces a production quote without having measured this, that quote will grow later. It always does.

Split Point 2 — Scope Creep Starts With the Words “Company-Wide Rollout”

The second split point is uncontrolled expansion of scope. It begins as an IT department FAQ. Somewhere in the review cycle HR policies are added, then the quality manual, then sales asks for past proposals to be included, and the project ends up defined as “all internal documents”.

Three things happen simultaneously as scope widens. First, preparation effort grows faster than linearly with the number of document types. Second, because access rights differ by department, permission management has to be built. Third, the evaluation criteria go soft. With ten target workflows in scope, nobody can say which workflow improved by how much, and the effect becomes impossible to explain. Projects whose effect cannot be explained do not get next year’s budget.

Two of the abandonment causes Gartner listed — escalating costs and unclear business value — usually arrive as downstream consequences of scope creep. The most reliable way to hold costs down is to refuse a company-wide target from the outset, pilot on one or two workflows, confirm the effect, and only then widen.

Split Point 3 — Do Not Go Live Without Deciding Who Operates It

The third split point is what happens after go-live. RAG is not a build-and-forget system. Documents change and have to be reloaded. Questions the system failed to answer have to be collected and the gaps in the document set filled. User ratings have to be reviewed and retrieval settings adjusted accordingly.

The AQUA LLC analysis cited above suggests budgeting annual operating cost at roughly 15% to 25% of the initial development cost. More important than the figure is deciding, before go-live, who performs the work. If the arrangement is that someone in IT will get to it “when things are quiet”, updates stop within three months. And a RAG system that has stopped being updated answers with stale information in a confident tone, which makes it more dangerous than what you had before you started.

The realistic answer when assigning ownership is to give update responsibility to the department that owns each document, and leave IT responsible only for keeping the platform running. If the rule is that HR reloads the HR policies when they change, update lag becomes structurally unlikely rather than a matter of goodwill.

Working Out Which Side of the Split You Are On

Here are the three split points rendered as a self-assessment you can run before writing the approval request. Read it this way — if the left column describes you, production is a realistic destination; if the right column describes you, the pilot is where this is likely to end.

If three or more of the right-hand cells apply, you will reach a working system faster by clearing those items before requesting quotes at all. The top three rows in particular are your own homework — choosing a better vendor does not resolve any of them.

RAG Cost Benchmarks for 2026 — Ranges and the Three Factors That Move a Quote

For an investment decision you need more than a total. You need to know what causes the number to move, because only then can competing quotes be compared meaningfully.

Ranges by Scale

Broken down by phase, GXO’s published figures put a proof of concept at JPY 1.0M–3.0M over two to six weeks, a production build at JPY 3.0M–10M over two to four months, and monthly operations at JPY 100K–500K. A layered decomposition of those phase figures is covered in RAG implementation cost and process, so here we take a different cut that maps more directly onto an investment decision — the scale-based benchmarks published by Root Team. When you are deciding which tier to aim for, this division tends to be the more usable one.

Placing the two sets side by side, the pilot and production build ranges broadly overlap, but the monthly operating figures do not — GXO says JPY 100K–500K while Root Team says JPY 200K–800K, and the whole band is shifted. That gap reflects a difference in what each provider counts as “operations”, so when you collect quotes, settle what work is inside the maintenance fee before you compare any numbers. Note also that both sets are published by development firms about their own services; neither is independent third-party market research. Your own quote falling outside these ranges is not in itself a problem. Being unable to explain why it falls outside them is.

The point to watch is that full production has no effective ceiling. Writing it as “JPY 15M and above” means that, depending on the number of systems to be integrated and the complexity of permission management, the figure is open-ended. Root Team itself concludes that the way to contain cost is to avoid aiming at a company-wide rollout from the start, confirm the effect with a small pilot, and expand scope afterwards.

Most of the Money Goes to Data and the Interface, Not the Model

The structure of the breakdown matters more than the size of the range. GXO publishes a line-item breakdown for a small pilot covering FAQ search for an IT department. The absolute amounts, and how they accumulate across the production and operating phases, are covered in RAG implementation cost and process. Here we extract only the proportions, because those are what bear on the investment decision.

LLM API charges account for 2% of the total. That is the headline of this breakdown. Public debate fixates on which model to use, yet in this cost structure the choice of model barely touches the number. The largest line is data preparation, and adding accuracy evaluation to it means 58% of this pilot went on getting the documents in order and measuring how much difference it made. That is entirely consistent with split point 1 above.

When a quote arrives, hold it against these proportions first. A quote where the data preparation line is unusually small, or where the document says “source data to be provided by the customer”, may show a lower total, but the difference will reappear later as your own staff cost.

The Three Factors That Move a Quote

Two quotes both reading “production build, JPY 5.0M” can mean entirely different things if the assumptions differ. When running a competitive process, fix the following three variables on your side and make every vendor quote against identical conditions. Without that, comparing the numbers is meaningless.

• Number and format of target documents. A quote assuming 100 documents and a quote assuming 1,000 differ by an order of magnitude in data preparation effort. Always state the proportion of scanned PDFs as well.
• Whether permission management is required. The function that controls who can search which documents does not appear as a line item in pilot breakdowns and typically arrives only at production. It cannot be omitted if the corpus contains personnel information or commercial terms. The presence or absence of this single item moves the total by hundreds of thousands to millions of yen.
• How it is embedded into existing systems. Whether you build a dedicated new interface or mount the capability inside an existing intranet portal or business chat tool moves the interface development cost substantially. Of the three factors, this is the one with the most negotiating room.

The Volume of Work at Which Payback Actually Holds

I would not recommend transcribing a vendor’s return calculation straight into an approval request. The assumptions underneath any saving — how many minutes are cut per case, how many cases occur per month, what an hour of that person’s time costs — vary enormously between companies. Even published worked examples apportion the first year on the assumption that production go-live falls in month six, rather than applying a steady-state annual saving to year one.

Practically, pin down three numbers of your own before recalculating. The monthly case volume for the target workflow, the current average handling time per case, and the hourly cost of the person handling it. With those three, you can produce a payback period as a range under any assumed reduction rate.

Suppose an enquiry takes 20 minutes to handle, and the person handling it costs JPY 3,000 per hour. If RAG cuts handling time by 30%, the saving per case is 30% of 20 minutes, which is 6 minutes, or JPY 300. Anchoring on that JPY 300 lets you work backwards to the volume required. On the investment side, we deliberately take the heaviest of the scale-based ranges above, full production covering a company-wide rollout with multiple system integrations. Initial investment is taken at the middle of the JPY 5.0M–15M band, so JPY 10M, and annual operating cost at JPY 400K per month, which sits toward the lower end of the JPY 200K–800K maintenance band, giving JPY 4.8M for twelve months. If you intend to start small and grow in stages, the investment figures for the pilot, production build and operating phases are laid out separately in RAG implementation cost and process, and you can repeat the same procedure at your own scale.

Under these assumptions the annual operating cost of JPY 4.8M is 48% of the JPY 10M initial investment, well above the 15% to 25% guideline from AQUA LLC quoted earlier. That is what happens when a company-wide rollout is assumed — even taking the lower end of the operating range, the ratio still lands there. Real operating cost moves with the number of documents and how often they change. When you run your own numbers, produce two versions with the operating assumption flexed up and down, and your decision will be far more stable.

What the table above shows is a hard constraint. At full-rollout scale, any workflow receiving fewer than roughly 1,330 enquiries a month cannot cover even its annual operating cost from time savings alone. Lower the scale you are aiming at and the required volume falls proportionally, so re-run it at whatever range your company would realistically take. This is not a pessimistic conclusion — it is a criterion that constrains the choice of target workflow and the size of the investment at the same time. If the volume is not there, you have three moves. The first is to reselect the target workflow for one with higher volume. The second is to evaluate the benefit not only as time saved but alongside other effects such as reducing dependence on specific individuals and shortening the ramp-up period for new staff. A worked example using internal helpdesk enquiries, showing why first-line time savings alone struggle to balance the books, is set out under different assumptions in Internal helpdesk AI 2026 and the four version gaps that make answers go stale. It uses different figures for both handling time and hourly cost, so it is worth reading the two as alternative models. The third move is to mount the capability on an existing system, compressing both the initial cost and the operating cost themselves.

Additional Decisions for Enterprise RAG at Thailand and ASEAN Sites

Everything so far applies equally in Japan. Deploying at a site in Thailand or elsewhere in ASEAN adds four further items to the decision. Working through them before the approval request reduces the number of review cycles. The issues that arise across generative AI generally rather than RAG specifically — local staff literacy, alignment with head-office guidelines and so on — are covered in Generative AI implementation pitfalls 2026 and the 95% stall. What follows is confined to decisions specific to RAG.

Version drift across languages. At Japanese-owned plants in Thailand, the same document routinely exists in Japanese, English and Thai, and just as routinely the three versions are not synchronised. The Japanese version is current, the Thai version is two years old. Because RAG tends to favour documents in the same language as the question, a Thai member of staff asking in Thai can be answered from the outdated version. Which language version governs, and at what point translation is inserted, are design decisions that can only be changed early. There are three approaches to translation — translating the full corpus, translating the query, and multilingual embeddings — and they differ in both initial cost and update burden. That comparison is tabulated in RAG implementation cost and process, and is worth reading before requirements definition.

The entry point local staff will actually use. Team leaders on a production floor may have no habit of opening an intranet portal in a browser. A purpose-built web application that nobody navigates to is not used. What does get opened reliably on site is the chat application people already use daily, or a terminal installed on the floor. Simply moving the entry point there changes the usage rate. As noted above, interface work is one of the factors that moves a quote — and if the capability can ride on an existing chat tool, you get lower cost and higher usage at the same time, which is one of the rare decisions where cost and effect point the same way.

Where data sits, and internal policy. Thailand’s Personal Data Protection Act is in force, so handling documents containing personal information requires a clear lawful basis for processing and a settled position on cross-border transfer. On top of that, where the Japanese parent’s information management policy also applies to overseas sites, you need an agreed interpretation of how much data may be sent to an external API before go-live, or the project stops days before launch. The RAG-specific trap here is that the original documents are not the only thing to check. There are four categories to trace — the original documents, the text extracted from them, the numerical representations built for retrieval, and the usage logs — and each needs its storage location confirmed. That mapping is set out in detail in RAG implementation cost and process. Whether you call an external API, host a model in your own environment, or run a mixture of both is a platform decision that bears heavily on both cost and accuracy, and it deserves to be worked through separately from the RAG design itself. The criteria for that choice are collected in Enterprise LLM deployment strategy — API, self-hosted or hybrid.

The division of roles between head office and the local site. Run head-office-led, the design ends up assuming head-office documents and the Japanese language, and does not fit local practice. Run purely locally, alignment with head-office information management policy becomes a problem later and the system gets rebuilt after go-live. The arrangement that works in practice is platform and rules from head office, target documents and operations from the local site. Which documents to include, who updates them and which language governs cannot be decided from anywhere but the site. Conversely, which model to use, where data is stored and how much may leave the company are head-office control matters. Write that boundary down before the approval request.

Draw a Line Before Extending Into AI Business Automation

Many companies that put RAG in place next consider extending into AI business automation — not merely searching and answering, but carrying the work through to execution. The direction is natural enough, but a line has to be drawn in between.

Start by levelling the terminology. RAG searches internal documents and answers, and its role is fundamentally limited to reading and answering. It does not write and it does not execute. AI business automation, by contrast, takes a judgement and carries out the actual processing. Internally both tend to get discussed as “introducing AI”, but the difference asserts itself after go-live.

The gap becomes visible when things go wrong. With RAG, a wrong answer still leaves room for the user to read it and exercise judgement. Add execution to that and a wrong judgement becomes an action directly. The nature of the blast radius changes, not just its size.

The order of extension therefore has to be — run RAG, measure the correctness of its answers over a defined period, confirm from real data which categories of question achieve sufficient accuracy, and only then add execution within that category. Moving to automation without measuring accuracy is precisely what Gartner means by inadequate risk controls.

The prerequisite for holding that order is a design in which every answer returns which document, and which part of it, the answer was based on. You cannot mount automatic execution on a system whose reasoning cannot be traced. A concrete design worked through on equipment manuals appears in Equipment manual search AI 2026 — citations matter more than accuracy, and the priority it argues for — citations over raw accuracy — is also a necessary condition for moving into automation.

What to Look For in a Vendor Proposal

Finally, how to read the proposals themselves. Judge on how the vendor answers the following five points, not on the thickness of the document or the length of the reference list.

The second row separates vendors most sharply. A vendor who can say “let us build the evaluation question set together” understands that accuracy is a measurable quantity. One that can only describe quality in adjectives has no route to improvement when, after go-live, the system turns out to be less useful than hoped. This pairs directly with the evaluation method row in the self-assessment table earlier. If the buyer has not decided how success will be measured and hands that question to the vendor, neither party can judge the outcome and only the cost accumulates.

Note that these are ways to read a proposal on receipt. The more technical list of questions to put in an actual meeting is collected as eight items in RAG implementation cost and process, and is best used once you have narrowed the field to two or three candidates.

How TOMAS TECH Can Help

TOMAS TECH is based in Bangkok, Thailand, and supports Japanese manufacturers at their Thai and wider ASEAN sites with implementation of the PEGASUS production management system and with applied AI. On RAG specifically, we are consulted well before the decision to build, across the following ground.

• Carving out the target workflow and running the payback calculation. We work through the three numbers used in this article with your real data to establish which workflow has the volume and the saving to justify the investment.
• Surveying the current state of your documents and estimating preparation effort. We look at the proportion of scanned PDFs, the drift between language versions and the state of version control before producing an effort figure.
• Designing and evaluating the pilot. We propose how to build the evaluation question set, and how to measure with cleaned documents and untouched documents deliberately mixed together.
• Integration approach with existing systems. Where production management or equipment data systems exist, we map out how document search and those systems should divide the work.
• Clarifying head-office and local responsibilities. We document the points needed for the approval request, including alignment with information management policy.

Having a base on the ground, and designing around how Thai manufacturing sites actually work, is what distinguishes us from a vendor operating out of Japan. Being able to work through requirements while looking at both head-office policy and local practice also tends to matter on cross-border projects.

Frequently Asked Questions

What is RAG, and what kinds of questions is it suited to

RAG stands for Retrieval-Augmented Generation. Before asking a generative model to answer, the system searches internal documents for the relevant passages, retrieves them, and hands them over as the evidence from which the answer is built. It suits questions whose answer exists as prose somewhere in a company document — interpreting a policy, confirming a procedure, finding a comparable past case. It is weak on questions whose answer exists as a number inside a core system, on questions requiring aggregation or comparison across many documents, and on knowledge that was never written down at all. If you do not share this boundary internally before starting a pilot, users will test only the weak categories and the evaluation will suffer for reasons that have nothing to do with the system working correctly.

How much does RAG cost to implement

As of 2026, GXO’s phase-based pricing guide puts a proof of concept at JPY 1.0M–3.0M and a production build at JPY 3.0M–10M. Monthly operating cost varies by source, with GXO giving JPY 100K–500K and Root Team giving JPY 200K–800K. By scale, a small pilot covering one or two workflows runs JPY 500K–2.0M, a lightweight production system for one or two departments including permission management runs JPY 3.0M–5.0M, and a full production rollout across the company with multiple system integrations runs JPY 5.0M–15M and above. In a published pilot breakdown, LLM API charges were just 2% of total cost while the largest line, data preparation, took 40%. Knowing that most of the money goes to data and the interface rather than the model makes it far easier to judge whether a quote is reasonable. The phase-by-phase breakdown of amounts is collected in our companion article on RAG implementation cost and process.

What should we check to avoid stalling at the pilot stage

Three things. First, the state of the target documents — establish in advance whether someone can immediately say which version is current, and how much of the corpus is scanned PDF. Second, scope — narrow to one or two workflows and agree the conditions for expansion before you start. Third, operational ownership — decide which department updates what, and when, before go-live. Proceeding into a pilot with these three unresolved is how you end up on the most expensive path of all, where the pilot produces good results and production falls apart.

Is it safe from an information leakage standpoint to use internal data with generative AI

It depends on the configuration. Where data is sent to an external LLM service, you need to confirm the scope of data transmitted, whether the provider may use it for training, and where it is stored — through both the contract and the settings. Hosting a model in your own environment removes external transmission but raises both initial cost and operating burden. Operating in Thailand adds the Personal Data Protection Act perspective, which requires a settled position on documents containing personal information and on cross-border transfer. There is also a RAG-specific point, which is implementing permission management so that documents a user is not entitled to see never appear in their search results. That function does not appear as a line item in pilot breakdowns and typically arrives only at production, so make sure its presence or absence is aligned across the quotes you compare.

Summary

For a company weighing RAG adoption, the decision turns on the readiness of your data and your operations, not on the merits of the technology. Gartner forecast that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, and further that by 2026 organisations would abandon 60% of AI projects not underpinned by AI-ready data. That qualifier matters — the forecast does not claim that projects with prepared data fail at the same rate.

In the 228 evaluated cases published by Canon IT Solutions, only 12% of bad answers were attributable to the generative model itself, while documents that were deficient or missing accounted for 46% and poor retrieval accuracy for 42%. What an investment decision should examine is not which model you will use but how well ordered your own documents are.

On cost, the pricing guides published by development firms put a proof of concept at JPY 1.0M–3.0M and a production build at JPY 3.0M–10M, with monthly operations ranging from JPY 100K to JPY 800K depending on the source. The breakdown matters more than the total — in the published pilot example, 58% of cost went to data preparation and accuracy evaluation, and LLM API charges came to 2%. Whether the investment pays back is then decided by volume. Assuming 20 minutes per case, an hourly cost of JPY 3,000 and a 30% reduction, and taking a full-rollout scale of JPY 10M initial investment with JPY 4.8M in annual operating cost, you need more than roughly 1,330 cases a month simply to cover the annual operating cost, and roughly 2,260 cases a month to recover the initial investment within three years as well. Substituting your own numbers into that calculation is the first task before writing the approval request.

At Thailand and ASEAN sites, four further decisions join the list — version drift across language editions, the entry point local staff will actually use, where data sits alongside internal policy, and the division of roles between head office and the local site. All four are design decisions that can only be made early, so settle them before requirements definition.

As a way to start, narrow to a single high-volume workflow, run the pilot with cleaned documents and untouched documents mixed together, and capture correctness and citation validity as numbers. Get that first design right and the data will guide every decision after it.

Which workflow to start from, whether your documents are in a usable state, and whether the volume supports payback all depend on how much documentation you hold, what condition it is in, and how your existing systems are put together. Through production management and applied AI work at Japanese-owned plants and offices in Thailand, TOMAS TECH is regularly asked to help sort out exactly these preconditions. Even if nothing has been decided internally yet, you are welcome to tell us about your current concerns and the workflow you have in mind through our contact page. We are happy to start from the practical end, with how to choose the target workflow and what a pilot should measure.

References

• GXO — RAG implementation cost benchmarks and breakdown, covering pilot, production build and monthly operating ranges plus a worked pilot breakdown for a company of around 300 employees
• Root Team — RAG development cost benchmarks and outsourcing considerations, with cost by scale from small pilot to full production and maintenance and operating fees
• Gartner — Prediction that at least 30% of generative AI projects will be abandoned after proof of concept by the end of 2025, press release dated 29 July 2024
• Gartner — Prediction that 60% of AI projects not underpinned by AI-ready data will be abandoned by 2026, with 63% from a survey of 248 data management leaders, press release dated 26 February 2025
• Canon IT Solutions — Technical report on an internal RAG trial covering 228 evaluated cases, with bad ratings caused by deficient or missing documents 46%, poor retrieval accuracy 42% and the generative model 12%
• AQUA LLC — Analysis of why RAG projects fail, noting data preparation at 40% to 60% of total effort and annual operating cost at 15% to 25% of initial development cost