Building an index means three decisions: the chunking unit, whether to search with keywords, vectors or both, and which embedding model to use. All three are semi-permanent, since changing any of them means rebuilding. The research is cautious: semantic chunking isn't consistently better, splitting by sentences or by document structure is usually enough, and overlap has small, setup-dependent effects. In one Traditional Chinese study, the correct passage ranked first 57% of the time with vector search alone, keyword search 76%, and the two combined 81%. Don't choose by feel: compare two setups on order 11's test questions, changing one thing at a time.
Evaluate in two layers: did retrieval find the source passage, and is the answer grounded in it and correct. Looking only at answers can fool you: one study found that when the context wasn't enough to answer, models still got 35% to 62% right using their own knowledge, which breaks on questions only your organization can answer. Use order 11's test questions for both layers, and evaluate permission-crossing and unanswerable questions too; calibrate LLM judges against human samples. After launch, turn escalated and complained-about conversations into failure cases, hand them back to document owners, and add them to the test set.
Metadata serves three purposes: returned for citation, used in search, and used to filter before retrieval; exact conditions like model, year or region belong in fields, and one study that wrote the company and year in front of every chunk raised top-five hits from 33% to 55%. Take filter values from source systems as fixed options, store dates as numbers, and don't let an LLM generate them freely.
When documents become text, what breaks usually doesn't throw an error: multi-column paragraphs joined in the wrong order, merged table cells flattened, headers and footers mixed into the body, OCR typos in scans, images and strikethroughs gone. High OCR accuracy doesn't mean good RAG either: in one study, documents with strikethroughs and color marks scored 82.9% on OCR but only 52.8% on question answering. Chunking matters more than switching tools: from the same conversion output, chunking by heading hierarchy with the heading path attached raised table questions from 66.6% to 99.8%. So always spot-check parsed output against the originals for these failure types.
Filter permissions at retrieval time: each chunk carries the groups allowed to see it, each query carries the user's groups, and anything that doesn't match never becomes a candidate, rather than letting the model read it and then telling it not to say it. AI doesn't create new permissions, but it makes documents that were shared too widely findable with a single question, so clean up oversharing before launch. When permissions change, the index doesn't necessarily follow: some connectors update permissions only on full crawls, up to a day late. Filtering has a cost too: with strict conditions, some vector databases return too few results. Before launch, add a permission-crossing question to your test set.
Documents in a knowledge base may carry personal data or hidden instructions for the AI, and the latter has been demonstrated on Slack AI and Microsoft 365 Copilot. Telling the model to ignore them in the system prompt does little; it's safer to add personal-data and instruction gates at ingestion and limit what the model can do. No detection tool catches everything, so every layer only reduces the risk.
Importing the whole shared drive is the most common way to start an AI knowledge base, and the most common mistake. When old and current versions are retrieved together, the model blends them: in one study, even with the current information retrieved, adding a single outdated passage cut the overall score by more than 24%. First build a source inventory recording each source's owner, update frequency, access restrictions and handling decision; collect only one workflow's well-governed sources in the first batch; and keep only the current version of each document, labeling any old version you must keep with its version and expiry date. After importing, check the file counts, because some connectors import nothing and report no error when they lack permissions.
When documents change or are deleted, the index doesn't keep up on its own. A sturdier incremental sync uses a content hash to find which documents changed and redoes only those; deletion has to reach every place a document is stored, including the full-text index and the vector store. Many tools don't handle deletion by default, and deletes and updates can take a while to take effect. Why clean up thoroughly: one preprint put a single outdated document into the context, and two small models flipped three to four in ten medical questions they had answered correctly; when told to answer from the documents, that rose to between two-thirds and three-quarters.
A wiki that people understand can still trip up an AI: what it sees is a few chunks cut out of the pages, without the navigation, heading hierarchy or surrounding text. So before building RAG, write a set of test questions: each with its answer and its source passage, plus a few deliberately unanswerable ones. Azure's RAG guide does this in parallel with content analysis; one study found that evaluating only with AI-generated questions overstated retrieval performance by 29 to 37 percentage points, so mix in real users' questions. If your knowledge base is under about 500 pages, you may not need RAG at all: put the whole thing in the prompt.
Personal notes, a team wiki and a knowledge base for AI differ in who reads them: your future self, your colleagues, a model. All three have to answer what to keep, how to organize it, how it gets found and who maintains it. Research on personal collections finds that most 'finding' is re-finding things you have already seen; research on enterprise wikis finds that once the person who tidied or wrote the content leaves, it starts to decay.
Before choosing a note tool, ask five things: can other programs open its files, do links survive renaming, can you search and filter, does it sync across devices, and does it work offline. Obsidian's notes are just Markdown files in a folder on your computer, but syntax such as block references can't be followed outside Obsidian, and on iPhone only two sync methods are officially recommended. Notion's databases are powerful, but an export takes only one view, callouts become HTML, and an export can't simply be uploaded back to restore your workspace. Before switching tools, export once and open the result in another program.
For files people create themselves, research keeps finding that most retrieval happens by clicking through folders, and better search tools haven't changed that much; few people use tags, and those who do mostly apply just one. So notes are worth organizing, but each note needs only one main home, the structure shouldn't get too deep, and folders shouldn't get too full. PARA sorts things by how close they are to your current work, Johnny.Decimal allows at most ten per level and fixes each item's place with a number; the numbers in both are their authors' experience, not experimental findings.
Getting team documents to look alike and make sense takes two templates and one principle. The principle is fewer but fresh: Google's documentation guide says a small set of fresh, accurate docs beats a large pile in disrepair, and if something exists elsewhere, link to it. The how-to template runs prerequisites, steps, how to confirm it worked, and whom to ask when it fails; in one study, installation instructions rewritten to a template scored better on eight of ten aspects readers rated. Architecture decision records (ADRs) note why a decision was made; when one is reversed, you don't delete it, you mark it superseded and link to the new decision. Research also finds ADRs are often tried and dropped, and that the "considered options" section is the most problematic, often missing or misplaced, so keep the template short and keep that section.
A common team-wiki argument is whether to organize by department or by task. The research is more cautious than you might expect: employees who know the org chart were actually faster on an intranet organized by department, and label quality mattered far more than the organizing scheme. A safer approach: give the main structure a scheme where every page has an owner, then add a few task-based entry pages that hold only links, and title pages with the words readers will search for. Before organizing, use card sorting to learn how readers think; afterwards, use tree testing to check whether they can find things.
Documentation going out of date is normal, and it throws no errors: eight in ten of GitHub's most popular projects have at some point left references in their docs to code that had been deleted. There are four ways to maintain docs: give every page a responsible role, set verification expiry, change the docs in the same change as the process, and fix pages when they're used. Each one fails in its own way: the owner leaves, expiry notices get treated as spam, the rule exists but nobody follows it, and articles nobody uses never get checked. The deletion principle: delete what's certainly wrong first, and archive what's correct but rarely used. By the end you'll be able to draw up a maintenance table for your team: document type, responsible role, review cycle, and deletion conditions.
When colleagues can't find something, it usually isn't missing: of 50 zero-result queries at one university library, only one in ten was for something it didn't have. Sort the gaps in three to six months of search logs into can't be found, doesn't exist and different words, and fix titles and synonyms first; AGENTS.md files for AI need the same care, since one evaluation found they didn't raise success rates overall while raising costs by about a fifth.
Research on rotting team wikis keeps finding three things: gaps and outdated pages are complained about more often than wrong ones; the people who write have no time or have left; and managers want something different from the people who actually write. Not every wiki rots: wikis hold up better when the writers are also the readers, or when the documents solve a clear problem. Diátaxis sorts documents into four kinds (tutorials, how-to guides, reference and explanation), and two questions tell you which kind a document should be, so you can see which kind your team is missing.
Schedule a 30-minute weekly review: empty the inbox, deal with finished projects, and pick one question from an MOC to think further about. Summarizing needs no schedule; add a layer only when you touch a note anyway. An LLM can find duplicates, suggest possibly related notes and flesh out key points you've written first; the sentence in your own words, deciding what matters and whether to delete are yours. In one 30-person study comparing three kinds of AI help, the group given complete AI notes learned the least and edited the least.
To decide whether to keep something, ask three questions in order: can I name a concrete use for it, can I find it again later, can I write one sentence of my own about it. No use, don't keep it; if the original is findable again keep only a link, otherwise save a copy; only items with that sentence go into the knowledge base, the rest go on a to-read list. Empty the inbox every week. The reason behind it: every keep-or-skip decision risks two errors, keeping too much buries what matters and keeping too little means searching again, and loosening or tightening your threshold only trades one error for the other.
After this post you'll be able to rewrite a reading summary as two or three notes that link to each other, and build a map note (MOC) once your notes pile up. The method comes down to four principles: one concept per note, organize by concept rather than by book, write in your own words, and state why you make each link. It goes back to Luhmann's slip box; research supports the idea that generating something yourself beats just reading it, but I found no credible controlled experiment on the Zettelkasten itself.
RAGFlow puts document parsing, human chunk review, retrieval tests, chat, and citations in one platform; it fits layout-heavy PDFs and tables, but carries more deployment weight and platform state than a Python library.
GitBook is a Git-based documentation platform with Markdown editing, version control, and multi-user collaboration. Ideal for technical docs, API references, and internal knowledge bases. The free plan is sufficient for individuals and small teams.