AI Wiki Platform for Corporate Knowledge Base

Why an AI wiki does not find the answer in the corporate knowledge base

An employee phrases a question in their own words — “how to refund a client for a canceled order” — while search across corporate documents looks for exact matches.

The policy says “refund upon termination,” there are no common words, and the results are either empty or consist of formally matched but irrelevant pages. The person scrolls through them, does not find the answer, and goes to chat to someone who “definitely knows.”

The second reason is fragmented knowledge sources. A wiki, file storage, ticketing system, email, messenger conversations: each has its own structure, its own owner, and its own access rights model.

Until documents are brought together, search sees only one island and is silent about the rest. If everything is consolidated into one index without accounting for rights, an employee will receive a fragment of a document they are not allowed to read.

The third reason is inaccurate answers from the neural network. The AI wiki completes the wording based on the only paragraph found, without checking the date and status of the document, and produces confident text without a link to the primary source. It cannot be verified, and after the second or third such answer, people stop using the tool.

The outcome is predictable: the load on experts grows, the same questions are asked again, and the queue to the knowledge holder does not clear. We will break down how this is closed — from a unified access layer to sources to an answer with a link to a specific document.

What changes after implementation: speed, accuracy, coverage

Before implementation, the path to an answer looks like this: an employee opens search across the base, gets a list of documents, and reads five to seven pages to assemble fragments into a single decision.

Some questions go to specialized chats with experts — they answer from memory, and versions of answers gradually diverge. We start by measuring this baseline from request logs, not from feelings.

The first effect is time to a ready answer. We measure from the question being asked to an answer with links, separately the median and the tail of the longest queries: it shows where the base lacks documents.

In practice, this is minutes instead of tens of minutes, and the gap grows on questions that require bringing together three or four sources.

The second is the share of answers with a verified source. Each answer comes with a quote and a link to a specific document in Confluence, so it is verified in one click, not taken on faith.

On a test set of questions with reference answers, we measure accuracy and analyze discrepancies: where the answer is incomplete, where the document is outdated, where the query requires clarification from the author.

The third is coverage. We look at how many departments and employees return to the base repeatedly, and how the flow of questions to experts in specialized chats changes.

For new employees, the difference is fundamental: not “there is no one to ask,” but finding the answer independently on the first working day.

AI wiki options: external service, customer perimeter, hybrid

The deployment method determines where document texts and embeddings physically reside, who is responsible for updates, and how long launch will take.

For a knowledge base, this is not an abstract infrastructure choice: it determines whether internal sources can be connected and how isolation of confidential data is ensured.

In practice, a hybrid is more often chosen: confidential data remains inside, while heavy operations with models are moved outside.

We describe both perimeters, the data flow scheme, and the points where a leak is possible — before work begins, so that the solution meets security requirements rather than bypassing them.

Work stages: from source audit to handover to support

Development of a wiki platform begins not with code but with an inventory of what has already been written.

The order of work determines whether answers will rely on current versions and whether access control will not collapse on the very first request from an employee in an adjacent department.

1. Audit of knowledge sources. We compile a list: where documents are located, what formats they are in, where duplicates and outdated versions are, and which materials have no owner at all.
2. Scheme of connections between systems. We decide what is pulled from accounting systems directly and what remains as files, and by what attributes employees, projects, and departments are matched.
3. Access rights setup. We inherit groups from the directory and delimit them by section; we check that an answer does not splice together fragments that an employee is not supposed to see.
4. Assembly and indexing. We divide documents into semantic fragments and set a citation rule: each answer leads to a specific document and its version.
5. Answer quality acceptance. We run real employee questions, calculate the share of answers with a correct link, analyze misses, and further train the system on them.
6. Handover to support. We provide the base update regulation, a map of section owners, and control rules so that quality does not degrade after launch.

Each stage is closed with an artifact that can be checked — therefore acceptance is based on facts, not on feeling.

Delivery scope: configurations, integration schemas, regulations

Everything described in the project documentation remains in the customer perimeter — not in chat and not in the contractor's memory.

We hand over a repository of configurations, schemas, and regulations, according to which your team reproduces the environment from scratch, changes the model, or connects a new source without us.

The check is simple: an engineer who did not participate in the project deploys the stand using these materials and explains why the system answered exactly that way.

• Knowledge source map — a list of systems from which the base is assembled: file storages, wiki spaces, request databases, mail archives. For each source, the owner, update frequency, and selection rules are specified, as well as what is deliberately excluded from the index.
• Access policies and roles — a role model tied to directory groups and rules for rights inheritance: an employee receives in an answer exactly those fragments to which they have access in the source system. A separate item is the assistant's behavior when rights in the source have changed but the index has not yet been rebuilt.
• Integration schema — connectors, synchronization schedule, processing of document changes and deletions. Failure points are marked: where the assistant answers based on the last agreed version, and where it honestly reports the absence of data.
• Answer generation setup — templates for model queries, rules for citing the source fragment, and the threshold below which an answer is not issued at all.
• Instructions for employees — 1–2 screen memos: how to formulate a query, how to verify the link to the primary source, where to report an incorrect answer. Plus a memo for content owners on how to keep documents suitable for search.
• Answer quality metrics — share of answers with a verified link to the source, frequency of requests with no data found, usefulness rating from employees, time to answer. A dashboard with thresholds that require intervention when exceeded.
• Operations regulation — procedure for updating the model and rebuilding the index, incident response, and a responsibility matrix on the customer side.

Acceptance follows the same list: we check each item on your stand and by your employees, not on demo data.

Case: service desk knowledge base and operator answer time

A service desk of 40 operators kept knowledge in Confluence: articles were written for the product, not for the customer's wording. Search by article title gave the needed result in 40% of cases, and the rest went into chat with senior engineers.

The average time for an operator to prepare an answer was 11 minutes, and every fourth customer returned with the same question.

What was changed

We analyzed the flow of requests over a quarter and restructured it into the base structure: tagging by symptoms instead of product sections, access rights by roles and regions, and a mandatory link "request — article".

An operator sees only verified articles, while a senior engineer sees drafts. A draft that was not confirmed by an answer twice is automatically archived, so the showcase does not become overgrown.

A separate effect was that the class of repeat requests stopped growing, where a customer reached another operator and began explaining the problem from scratch: the answer is now assembled from one verified article.

We handed over the tagging and access rules to the support team — new articles enter the showcase without development involvement.

How word search differs from semantic answer

Exact word search works via an inverted index: a document is broken into lexemes, and the query finds those fragments where the same words occur.

Morphology and stop words smooth over some discrepancies, but synonyms and rephrasings remain out of scope — “how to apply for vacation” and “procedure for granting rest” produce different results with the same meaning.

Semantic search by query meaning is structured differently: both the query and each fragment of the knowledge base are converted into a vector representation, and proximity is calculated by the distance between them, not by letter matches.

The wording “the client asks to return the money” finds the refund policy even if the word “money” is not in the text. Synonyms are pulled from the ISO 25964 thesaurus and from statistics of real employee queries.

The weak point of semantic search is that it always finds something, even when there is no correct answer in the base.

Therefore, both mechanisms work in tandem: exact matches are mandatory for part numbers, error codes, and abbreviations, where the match must be literal; semantic proximity picks up the rest; and the overall result undergoes reranking — fragments relevant both in meaning and in query terms are raised to the top.

The quality of results in a knowledge base is measured not by “similarity” but by whether the employee reached the answer.

Hence two strict requirements: a link to the source in the answer — indicating the document and section, so that the quote can be verified — and a set of test pairs “question — correct document,” which regularly check that search has not lost its ability to find.

Without a link, a semantic answer is indistinguishable from a confident fabrication; with it, this is a working tool whose logs show which topics the base lacks.

Limitations and risks: data quality, access, load

The platform by itself does not make a knowledge base current — answer quality is limited by source quality. If the index contains three versions of the same policy, any result will be confident and incorrect. Some limitations are closed not by the model but by document lifecycle rules and access control.

Below are four doubts most often raised during pilots and how we address them.

How is a conflict of policy versions resolved?

A version is a unit of indexing, not a line of text. If there are two active editions, the system does not choose silently: it shows both with scope and approval date.

Priority is configured by document attributes — usually the edition with the narrower scope wins because it is more specific.

How is access delimited?

Rights are inherited from the corporate directory and checked during fragment selection, not when the answer is output. An answer cannot retell a document unavailable to the user — otherwise the content of closed sections leaks through quotes. Guest and temporary roles work according to the same scheme.

What happens under peak load?

Indexing of new documents and answer generation go through a queue with a limit on parallel tasks, while index search remains responsive. Frequent questions are served from cache, and the user sees a status instead of a timeout. The morning peak of requests does not bring down the service for others.

Let's discuss the task: what to send for assessment and a work plan

To come back with an assessment, solution design, and implementation stage plan, a short set of inputs is enough.

The more specific the initial data for assessment, the fewer assumptions in timelines, and the earlier it is clear which part of the knowledge base will have to be prepared manually rather than simply migrated.

• Where knowledge currently resides: corporate wiki, file storages, ticketing system, correspondence archives — and what of this is considered reliable.
• Volume and structure: approximate number of pages and sections, content languages, share of outdated and duplicate materials.
• Samples: 20–30 real pages, including poorly tagged ones, with tables and attachments.
• Users and roles: how many people will ask, what access groups exist, who owns the sections.
• Typical questions: 15–20 phrasings from support and from colleagues — this is the future validation set.
• Limitations: where data is allowed to be stored, what is required for access control and request logging.
• Integration points: messenger, employee directory, ticketing system — where the answer should arrive and where content should come from.
• Acceptance criteria: share of answers with a link to the source, answer speed, absence of fabricated links.

From this set, we assemble a solution design — how content enters search, how it is updated when edits are made, and how it is checked before publication — and lay out the order of work by stages with an acceptance point at each.

Discussing the task takes one conversation: describe it and send what you already have at hand; we will clarify the missing parts along the way.