The knowledge is already there. In your FAQ, of course. But also in thousands of resolved tickets, agent-approved responses, and specific cases accumulated over the years.
A common mistake is to try to reorganize everything into a perfect document database before launching an AI project. Then, whenever an answer is incorrect, to keep adding more and more documents.
Generative AI offers a different approach: leveraging existing knowledge—provided you know how to find it. After all, in customer service, the sheer volume of documents is often a red herring. What matters is the quality of the sources provided for each request.
For a long time, a customer service knowledge base primarily referred to a collection of well-written, structured, and regularly updated articles.
This documentation remains essential. It contains the official rules, procedures, and answers that the company wants to make available. However, it does not always cover the full scope of the support experience.
Knowledge also exists in:
This content is less formal than an FAQ. It also addresses the actual issues customers face much more directly.
So the issue is no longer just: How can I write more documentation?
It becomes: How can we find the right knowledge among everything that already exists?
The RAG, or Retrieval-Augmented Generation, combines searching for information in an external source with the generation of a response by a language model. The principle has been formalized in a research article published in 2020.
A general-purpose model knows how to write. It doesn't necessarily know your return policy, country-specific exceptions, the status of an order, or the actual procedure followed by your teams.
RAG provides him with this information exactly when he needs it. Our RAG guide for customer support explains how this works.
In its simplest form, the process looks like this:
customer question -> knowledge search -> relevant sources -> response generation
Agentic RAG goes a step further: it can rephrase the search query, fill in missing context, verify its findings, and decide whether to continue or stop. Our article on the practical impacts of Agentic RAG in customer service explains this evolution through use cases, quality control loops, and technical diagrams.
Here, the question is different: what information should actually be provided to the system?
When an answer is wrong, adding documents seems reassuring. You tell yourself that the information will eventually turn up in the batch.
But every additional document potentially introduces both useful information and noise: duplicates, outdated versions, rules applied to a different area, and responses that are similar but incompatible with the client's situation.
At Klark, we compare, among other things, variants that present six or eight documents to the system in order to measure, on a case-by-case basis, the effect of the additional context on retrieval.
Depending on the request, the client, and the structure of the knowledge, two additional documents may be helpful, have no effect, or dilute the key information.
So the right metric isn't the volume of information provided. We need to assess whether the source cited is authoritative enough, whether it truly addresses the issue, and whether the other documents reinforce or obscure the answer.
This distinction changes the assessment. Before adding content, you should ask yourself:
Adding twenty pages of FAQs won't fix a misconfigured filter.
A single brand may operate in multiple countries, handle multiple products, manage multiple stores, use multiple sales channels, or have multiple sales policies. Two documents can both be correct yet incompatible because they apply to different contexts.
Filtering the knowledge base helps reduce the corpus even before classification. A French inquiry about a specific product should not be handled based on a U.S. policy or documentation intended for a different product line.
But the filters themselves must be tested.
A filter that is too broad lets in noise. A filter that is too strict may exclude the only useful document. The quality of a system is therefore measured not only by what it finds, but also by what it excludes.
This mechanism can power a co-pilot, an automation tool, or an AI solution integrated into customer service. In each case, the scope of knowledge must align with the actual context of the ticket.
Tickets contain a considerable amount of operational knowledge.
They show how a policy is actually implemented, which phrasing works, which exceptions come up, and which cases pose problems for staff members.
This does not mean that the entire history should be injected without verification. A ticket may contain:
Conversations must therefore be selected, put into context, cleaned up, and evaluated. The ticket is a possible source, not an official default rule.
This distinction is important. The benefit doesn't come from a massive copy-and-paste job from the helpdesk into the template. It comes from the ability to extract the right examples and compare them with the reference sources.
An international team is all too familiar with this problem: a procedure changes, and then it has to be rewritten in several languages, adapted for each country, and checked to ensure that each version remains up to date.
This duplication automatically leads to discrepancies.
Generative AI makes it possible to leverage knowledge that is too vast and scattered to be reviewed manually for each ticket.
A team can start with reference sources, link them to the relevant geographic context, and then adapt the response into the client’s language without systematically copying every piece of content.
Multilingualism does not eliminate governance. It simply prevents us from confusing governance with an endless proliferation of files.
A successful demonstration on three questions does not prove that a system is ready for actual use.
We need to build a representative set of queries: frequently asked questions, ambiguous phrasing, different products, local policies, missing information, and cases where the AI should stop.
For each application, the evaluation must distinguish between at least four topics:
This separation avoids having to change the model when the problem lies with the corpus, or having to rewrite the knowledge base when the problem lies with the classification.
It also allows us to test various technologies without relying on a single vendor. Klark is LLM-agnostic: we evaluate new models and methods, then test what they actually bring to customer service.
Human supervision remains essential. It serves to validate sources, detect recurring errors, and determine where automation can be improved. This is also the principle outlined in our article on Agentic AI and human supervision.
A customer service knowledge base is no longer just a neatly organized library of articles.
This knowledge already exists in FAQs, procedures, internal memos, and the thousands of tickets handled by the teams. RAG makes it possible to leverage this knowledge without requiring the model to know everything in advance.
But the race to accumulate as many documents as possible quickly leads to information overload. A well-chosen source—properly vetted and presented at the right time—is better than a context filled with similar, outdated, or contradictory documents.
Your knowledge is probably already in your tickets. The real work now is to find it with enough precision to make it useful.
Your knowledge base is probably already more extensive than you realize.
Klark helps support teams find the right source, in the right context, without having to rewrite their entire history.
About Klark
Klark is a generative AI platform that helps customer service agents respond faster and more accurately, without changing their tools or workflows.
