Internal Knowledge Assistant
Internal Knowledge Assistant
An answer desk over your own documents, where every answer names the file it came from.
What this is
An internal knowledge assistant is a chat surface over documents the business already owns. Somebody asks a question in plain language and gets an answer back with the file it came from named. The material is whatever the company already keeps: SharePoint, a file share, an intranet, a folder of PDFs on a server.
It works by retrieving. When a question arrives the indexed content is searched, the passages that match are pulled, and the model answers from those passages rather than from general knowledge. Nothing is learned from the documents, which is why this is weeks of work rather than a research programme.
The corpus sets the scope, which is why these projects finish. One bounded body of material — the operations manual, the policy library, the pricing rules — is a project. Every document in the company is not.
What you get
What gets built
The chat window is the smallest part of it. These are the pieces that decide whether the answers are any good.
The corpus, decided
Which material is in scope, which is excluded, and where it lives today. Most estates hold four copies of the same policy with different dates, so agreeing which one is authoritative is part of the work.
Retrieval that finds exact identifiers
Keyword search alongside vector search. Part numbers, policy numbers, case references and product codes are exactly what embeddings match worst and keyword matching handles best.
Answers with citations
Every answer names the document and the section behind it, so the person reading can check it in one click. An uncited answer is not something a professional can act on.
A chat surface where people already are
Teams for a Microsoft estate, a browser page where it is not. Nobody adopts a knowledge tool that lives in an application they have to remember to open.
Permission-trimmed results
Each person gets answers built only from content their account already entitles them to open. That is a build decision taken before switch-on, not a setting toggled afterwards.
Freshness on a schedule
The indexer runs on a cadence rather than once. Changed documents get picked up, and anything missed while the embedding endpoint was throttling is caught on the next pass.
A scored question set
Real questions from the people who do the work, with the correct answers recorded. It is what makes a later change provable rather than arguable.
A record of what it could not answer
The questions that came back thin, wrong or unanswered are collected as a list. That list is the highest-value input into the next round of retrieval work.
How it works
How the work runs
Pick the corpus
One bounded body of material and the people who own it. The first assistant answers a defined set of questions rather than everything.
Get the content into a retrievable shape
Extraction per format, chunk size and overlap chosen and written down, and a named embedding model with the reason recorded. Those parameters are the difference between an index that answers and one that returns the wrong paragraph confidently.
Score it before anyone sees it
The question set is run and the answers are checked for whether the passage cited actually supports what was said. A number comes out of that, and it is the baseline everything later is compared against.
Put it in front of real users
Real questions from real staff, with the misses collected and fed back into retrieval rather than into a longer prompt.
What matters
What decides whether the answers stay right
None of these show up in a demonstration. All of them decide how the system reads a year later.
Chunking is a tuning decision with real numbers behind it
Microsoft's own worked example splits one 200-page book into 85 chunks under one setting and 13,361 under another. That spread is index size, embedding spend, query latency and answer quality all at once.
The embedding model is a one-way door
The vectoriser has to match the model that encoded the content, so changing it invalidates every vector stored and forces the whole corpus to be re-embedded. On a corpus of any size that is a scheduled outage and a real bill, so it gets decided once with the reasoning recorded.
Permissions decide what the assistant will say
Retrieval removes the two things that were keeping old sharing invisible: knowing a document exists and knowing where to navigate. SharePoint defaults to the most permissive sharing option, so an inherited tenant is assumed to start there and reviewed before switch-on.
Keyword and vector search fail on different things
Vector search is weakest exactly where an exact identifier is the question. Hybrid retrieval with semantic reranking is the default here and pure vector is used only where similarity genuinely is the query.
The index goes stale unless the indexer runs on a schedule
Content changes, and throttling during indexing causes documents to be missed quietly. A one-off index build drifts away from the source of truth within weeks.
Non-deterministic answers need a scored set
The same question can return two different answers, so checking one by hand proves nothing. The build includes a set of real questions with known-correct answers that gets re-run after every change.
Who it is for
Who this is for
Firms where one person is the index
Everybody interrupts the same colleague because only they know how the pricing works, or what the policy actually says. When that person is on leave the work slows down and nobody can say by how much.
Professional practices with a document estate
Accountants, law firms, engineering and design practices, where the answer to most questions is in a file somebody has to go and find. The file exists and is correct; locating it is the cost.
Multi-site and field operations
Staff on a shop floor, on site or in a branch who need a process answer on a phone instead of a call back to the office. The alternative is a call to somebody who is busy, or a guess.
HR and operations teams answering the same questions
Policy, leave, onboarding and expenses questions arriving one at a time at a team of three or four people. The same handful of questions is most of the volume, and the answers are already written down.
Questions
Frequently asked questions
Does the model learn from our documents?
No. The documents are indexed, and the model reads the matching passages at the moment a question is asked. On Azure, prompts and completions are not used to train foundation models without your instruction.
Where do the documents and the index live?
In a cloud account your company owns. CloudCentric builds and administers it, and the content and the subscription stay under your name.
Can people get answers from things they should not see?
Retrieval is permission-trimmed, so answers are assembled only from content the person asking already has rights to. A retrieval pipeline over a plain file share has no permission model until one is built, so that work is scoped explicitly rather than assumed.
How is accuracy measured?
Against a set of real questions whose correct answers are recorded, scored on whether the answer is supported by the passage it cites. A figure quoted before anybody has seen your content would be made up.
What does it run on?
For a Microsoft estate, Azure AI Search with a model deployed in your own subscription. Where the estate is already on AWS, the same shape is built with Bedrock knowledge bases. Either way the index and the documents sit in an account your company owns.
How long does the first one take?
A single bounded corpus is normally three to six weeks. The chat surface itself is days; the time goes into content preparation, retrieval tuning and the permission review.
Also on this site
Name the question everybody asks the same person
That question, and the documents that answer it, are the corpus to start with.
(844) 422-7000