The assistant you've been using doesn't know your policies, your customers or your jobs. A knowledge base fixes that. You keep the information in one organized place, and the AI looks up the right pieces for each question, then answers from them and shows its sources. That look-up-then-answer pattern is called RAG. Done well, the owner and every seat can ask the same system and get answers that match the business.
Excel workbook. Sources, seats and test questions. No signup.
What's inside
- RAG explained without the jargon
- Which information to search and which to look up directly
- Where to keep it, from a shared folder to a real database
- A starter database design, tested, with per-seat visibility
- The assistant's instructions, a test plan and a downloadable starter sheet
The idea in one picture
| Layer | What it is | Your job |
|---|---|---|
| 1. The information | Documents, notes and records, kept in one organized place | Keep it accurate, owned and labeled |
| 2. The finder | Search that pulls the few relevant pieces for each question | Choose a tool for it |
| 3. The assistant | Reads those pieces and writes the answer, naming its sources | Give it strict instructions |
RAG stands for retrieval-augmented generation. In plain words: look it up first, then answer from what you found. The assistant doesn't memorize your business. It looks things up every time. That's why fixing a note fixes the next answer, with nothing to retrain.
Two kinds of information, two ways to read it
| Kind | Examples | How AI should read it |
|---|---|---|
| Documents and notes | Policies, how-tos, past proposals, meeting notes, email threads | Search by meaning, then answer from the passages found (RAG) |
| Structured records | Customers, jobs, invoices, inventory | Ask the database directly: filters, totals and formulas |
| Both together | 'Which overdue customers are on the extended-terms policy?' | Look up the policy as a document and the customers as records, then combine them |
Don't let the AI work out totals from snippets of text. Counts and sums should come from the database or a spreadsheet formula, and the AI should write around the result.
Choose where it lives
The discipline matters more than the tool. Start with the simplest thing that works.
| Option | Good for | Watch out for |
|---|---|---|
| The folders you already have (Google Drive, Microsoft 365, Dropbox) | The easiest start. Sharing rules already exist | Messy folders, duplicates and old versions. Check which sources your AI tool can connect to |
| A notes or wiki tool | How-tos and policies as short, titled pages with built-in sharing | Pages go stale unless someone owns them |
| A spreadsheet or Airtable-style database | Records such as customers, jobs and suppliers | Hard to search long documents |
| A database with vector search (for example Postgres with the pgvector extension) | One place for records, documents and per-seat rules, under your control | Needs a developer or a helper to set up and keep running |
Get the information ready
This is the real work, and no AI can do it for you.
- List every source on the Sources tab of the starter sheet, including what only lives in someone's head.
- Give each one an owner, a role rather than a person.
- Write one topic per page, with a plain title a stranger would search for.
- Put a 'last reviewed' date on every page.
- Merge duplicates and retire old versions. Two conflicting documents produce two conflicting answers.
- Mark what's sensitive, and who may see it.
- Write down the things people just know, such as how we handle a complaint.
Three rungs to build
| Rung | What you do | Effort | Limits |
|---|---|---|---|
| 1. Folder and assistant | Put your organized files where an AI assistant can search them, and ask questions | An afternoon | Access is often one setting for the whole project, and upkeep is by hand |
| 2. A workflow | An automation reads your documents on a schedule, stores them for search and answers from a chat, email or message | A day or two with a helper | You maintain it, and it takes care to enforce who sees what |
| 3. Your own database | Records, documents, search and permissions in one database, with the assistant asking it | A small project | Needs a developer |
A starter database design
For rung 3, or for a helper building rung 2. This is the shape, kept deliberately small.
One table for the notes, with who may see each
create extension if not exists vector;
create table knowledge (
id bigint generated always as identity primary key,
title text not null,
body text not null,
topic text,
owner text, -- a role, e.g. 'office'
visible_to text[] not null
default '{owner,office,field,books}', -- the seats that may see it
reviewed_on date,
embedding vector(1536) -- size of your embedding model's output
);
create index on knowledge using hnsw (embedding vector_cosine_ops);The embedding is a list of numbers that stands for the meaning of the text. Your embedding model produces it, and the size in the table must match that model. 1536 is the size of some popular models. This structure was run against a real Postgres with the pgvector extension.
Find the closest notes, for one seat only
select title, body, reviewed_on from knowledge where 'field' = any(visible_to) -- the asker's seat order by embedding <=> $1 -- $1 is the question, as numbers limit 5;
The rule is applied in the search itself, not in the prompt. Telling an AI 'don't mention payroll' is a request. If payroll is never retrieved, it can't come out. In a test, the field seat got no payroll row back and the bookkeeper seat did.
The assistant's instructions
Instructions for a knowledge-base assistant
Answer using only the sources provided below. If the sources don't contain the answer, say "I don't have that in our records" and suggest who in the business might know. Do not guess. After each answer, list the titles of the sources you used and their last-reviewed dates. If two sources disagree, say so and show both. Never state a price, a date, a number or a policy that is not in the sources.
Test it before anyone relies on it
Write questions in four groups
- Questions it should answer, taken from real weekly questions.
- Questions it should decline, because the answer isn't in your records.
- Questions each seat must not get answered, such as pay.
- Questions where two sources disagree.
Then
- Run every question and mark right, partly right or wrong.
- Fix the notes, not the question.
- Run them all again after any change.
When it goes wrong
| What you see | Usual cause |
|---|---|
| A confident but wrong answer | The right note doesn't exist, or two notes disagree |
| It misses something you know is there | The note is buried in a long page or has a vague title. Split it up and rename it |
| An out-of-date answer | No review dates, or old versions weren't retired |
| Someone saw something they shouldn't | Visibility wasn't applied when the notes were retrieved |
| A total that's off | It estimated from text. Send that question to the database or a formula |
Keep a log of the questions it couldn't answer and read it weekly. That list is your to-do list for what to write down next.
Next: one assistant, every seat →