AI marketing & MarTech
Marketing knowledge bases: when RAG is useful
Decide when a marketing knowledge base needs RAG. Check source ownership, retrieval, answer quality and permissions with a practical evaluation worksheet.
A marketing team often needs an approved answer rather than a creative one: which product supports a feature, where an offer applies or which customer result can be cited.
A knowledge base can make that information easier to find. Retrieval-augmented generation, usually shortened to RAG, can add a drafted answer using retrieved material. Whether that extra layer is useful depends on the task, the sources and the quality of retrieval.
This guide helps you decide between a source pack, ordinary search and a RAG workflow. It sits within the AI marketing guide, with a narrower focus on grounding factual work in maintained information.
Begin with the question people cannot answer reliably
Do not start with “we need a chatbot”. Start with a recurring question and the consequences of an incorrect answer.
A campaign editor may need current market eligibility. A sales colleague may need the exact scope of an approved customer result. A local team may need terminology and product conditions for an adaptation.
Observe the current search process. Can people find the governing document? Do they understand it once found? Are they combining several sources? Does the problem come from missing information or from retrieval?
RAG cannot recover an approved answer that the organisation has never written down. Nor can it decide which contradictory source is authoritative without a governing rule.
Define the expected response: a source link, an exact approved passage, a summary with citations or a draft for an editor. Those outputs have different complexity and review requirements.
For a small stable task, a manually curated source pack may solve the problem. Adding infrastructure before confirming the need can create another system to maintain without improving the decision.
Understand what retrieval adds
RAG retrieves relevant material, supplies it as context to a language model and asks the model to generate a response. The stored material and the generated answer are separate things.
The original RAG paper by Lewis and colleagues combined a generative model with retrieved Wikipedia passages and evaluated knowledge-intensive tasks. Its benchmark findings are evidence for that research setting, not proof that a marketing implementation will produce accurate approved claims.
In practice, a useful system must find the right source, retain the important conditions and use them correctly in the answer. A citation is helpful only if it supports the adjacent claim.
Retrieval is not the same as updating the model’s underlying training. New source material can be supplied through the retrieval layer, but the team still needs to manage ingestion, versions and which sources are eligible.
If the task is mainly tone or sentence structure, focus first on the brand voice rubric. A larger factual library does not by itself create a recognisable editorial voice.
Choose the simplest adequate approach
Compare alternatives against the actual job instead of ranking them by technical sophistication.
Swipe or use the arrow keys to see every column.
| Approach | Useful situation | What you still need | Main limitation |
|---|---|---|---|
| Curated source pack | Few stable sources for a specific task | An owner and current approved material | Manual updating and selection |
| Search with source links | People can interpret documents themselves | Findable content and clear authority | Reader still combines information |
| Retrieval plus draft | Repeated questions need summarised answers | Good retrieval and answer review | Generation can change the source meaning |
| Structured record lookup | Exact fields such as availability are required | Maintained records and access rules | Limited to defined fields |
This table is a decision aid, not a universal architecture prescription. A hybrid process may use exact records for product eligibility and retrieval for explanatory documentation.
Test ordinary search before adding generation. If the right document cannot be found, a fluent answer can hide the retrieval problem.
If a source pack works, improve the content workflow around it. The economic case for a more complex system should include the cost of maintaining and reviewing it.
Make the knowledge base usable
A folder of documents is not yet a governed knowledge base. Identify what each document means, who owns it and who is allowed to use it.
For each source, record a stable identifier, title, owner, version, effective period, market, language and intended audience. Add an approval status and a route for reporting corrections.
Keep approved customer claims separate from internal sales assumptions. An internal estimate should not become public proof simply because it is easy to retrieve.
Retire superseded sources through a defined process. Leaving old and current campaign rules side by side without status metadata creates avoidable ambiguity. Check that removal reaches the retrieval index, not only the original folder.
Where product conditions matter, keep them near the relevant statement. Dividing a document into passages that separate a benefit from its eligibility rule can produce misleading context.
A bilingual collection also needs a source relationship: which language governs the facts, which adaptations are approved and whether both versions remain current. Use the localisation quality guide to check meaning after retrieval and drafting.
Test retrieval without judging the final prose
Create a representative question set with expected source passages. Include frequent questions, ambiguous wording, missing information and market-specific conditions.
Run the retrieval step and inspect what it returns before evaluating the generated answer. Record whether the governing passage is present, whether irrelevant material crowds it out and whether the source version is correct.
Microsoft’s RAG evaluator documentation distinguishes retrieval evaluation from final-response evaluation. That separation is useful beyond its particular tooling; the worksheet here does not require those products or adopt their default thresholds.
A retrieval failure needs a retrieval or source correction. Rewriting the final prompt may improve expression while leaving the wrong market document in the context.
Have domain owners label the expected evidence. If no one can agree which passage answers the question, resolve the content governance problem before using it as a test case.
Keep part of the evaluation set separate from examples used during improvement. Repeatedly tuning to the same questions gives a narrow view of readiness.
Then test the answer using known good context
Supply the correct passages and examine whether the generated answer preserves their meaning. This helps distinguish generation problems from retrieval problems.
Check factual support, completeness, relevance and citation placement. An answer can be entirely supported yet omit a decisive restriction. It can also cite the right document while adding an unsupported benefit.
Require a useful response when the source is insufficient. That may be an explicit uncertainty, a request for market information or a route to the source owner. “I cannot establish this from the approved material” can be a better output than a confident guess.
Do not use the model’s own assurance as the acceptance criterion. A human reviewer should inspect consequential claims and the source passages that support them.
Connect the result to your AI output evaluation scorecard. Keep the specific RAG dimensions visible so an aggregate score does not conceal missing evidence.
A hypothetical campaign knowledge base
Imagine an invented software company with an old launch offer, a current Italian eligibility note and a general English product brochure.
A colleague asks: “Can we advertise the introductory offer to all Italian customers?” Retrieval returns the old offer and the brochure but misses the current market note.
The model drafts a convincing yes with links to both retrieved documents. Those citations exist, yet they do not support current Italian eligibility.
The team records a retrieval failure, then tests generation with the correct market note. The next draft recognises that eligibility is limited to a named plan and that approval is required.
A second question asks for a documented customer efficiency result. The library contains a feature description but no approved result. The acceptable answer should report that gap and identify the responsible owner, rather than convert the feature into a measured outcome.
The team’s fixes are precise: add effective-period metadata, improve market filtering and define a no-evidence response. The example does not demonstrate a real accuracy rate or a promised return.
All sources, events and outcomes in this scenario are hypothetical. They illustrate why working citations are not sufficient evidence of a correct answer.
Treat permissions and retrieved text as design requirements
A person’s ability to ask a question should not grant access to every document in the library. Test permissions using realistic roles, including someone with limited access.
Microsoft’s Foundry RAG guidance recommends access control during retrieval and treating retrieved material as untrusted input. Its specific product implementation is one example; permission requirements must be verified for your chosen system.
A source document is evidence to interpret, not an instruction that can override the workflow. Include controlled tests where a document contains irrelevant directions or an attempt to redirect the answer.
Ask the implementation team to show what happens when permission checks fail, a source is removed or the retrieval service is unavailable. The desired behaviour should be defined and observed, not assumed from a supplier description.
Avoid using a prompt as the only permission boundary. Governance belongs in the surrounding system and source process as well as the drafting instructions.
The AI governance guide helps assign owners for these decisions.
A practical RAG evaluation record
Use one record per question and keep the source evidence attached.
Swipe or use the arrow keys to see every column.
| Field | Record |
|---|---|
| Task | The user, question and intended action |
| Expected evidence | Approved document and relevant passage |
| Eligibility | Market, version and access conditions |
| Retrieved evidence | Actual passages returned and their order |
| Retrieval judgement | Relevant, incomplete, wrong or unavailable |
| Answer judgement | Supported, complete and useful, or reason for rejection |
| Citation check | Which claim each link actually supports |
| Exception response | Behaviour when evidence or permission is missing |
| Decision | Fix sources, retrieval, generation or workflow |
Aggregate only after reviewing the individual records. Include the denominator, question categories and unresolved issues. A single average across easy and consequential tasks is hard to act on.
Account for maintenance before expanding
A RAG service adds source maintenance, indexing, monitoring, evaluation and incident handling. Those costs continue after the demonstration.
Name the person who updates campaign conditions and the person who checks that updates appear in answers. Establish a review cadence tied to how quickly the information changes.
Keep records of the source version, configuration and answer for important evaluations. When behaviour changes, that history helps distinguish a source change from a system change.
Use the automation ROI guide to compare the complete cost with a simpler approach. Faster answers are valuable only if the accepted output and review burden improve the actual task.
Start with a question set and a source inventory. If ordinary search meets the requirement, use it. If summarised answers add useful value, test retrieval and generation separately before widening access.
If you need to decide whether RAG fits a marketing workflow, tell me which questions your team needs to answer.
Apply this to your project
Tell me the decision you are facing, the constraints and what you have already tried.
Keep exploring
AI content workflows: from brief to editorial review
Build an AI content workflow with reliable sources, clear approval roles and useful review measures. Includes a reusable brief and publication checklist.
AI localisation: evaluate quality before publication
Evaluate AI localisation with an error rubric for meaning, terminology, voice and delivery. Includes a bilingual example and a release decision worksheet.
Brand voice with AI: make your writing recognisable
Build a brand voice rubric for AI writing using examples, exclusions and tone decisions. Includes a bilingual worked example and an editorial review sheet.