Lately I’ve been building my own RAG knowledge base for Zhimalab (LanceDB + DeepSeek, covered in an earlier post), assuming that “feed in documents, get answers” was basically the whole job. Then I read a 10,000-word guide by Hedy Zhang called Enterprise AI Knowledge Base: A Real 0-to-1 Delivery Guide, and the “misprinted paper” story in it hit me hard.
The point of this post: moving an enterprise AI knowledge base from “demo-ready” to “delivery-ready” has almost nothing to do with the model. The real difficulties are documents, people, permissions, systems, scope, and acceptance.
A chilling case: the misprinted paper
During testing, the system answered a product question incorrectly. The debugging started at the model: the model cited the knowledge base, retrieval hit the right document, and the parsed text matched the scanned image. Every step of the technical pipeline was correct.
Yet the answer was wrong.
Tracing all the way back to the original paper design document revealed: that document was misprinted when it was originally produced. The veteran employees all knew it was wrong and never actually worked from the paper copy — the error had become shared background knowledge passed down by word of mouth. But nobody reprinted it, and nobody formally recorded the correction.
So after the paper was scanned, parsed, and loaded into the knowledge base, the system ended up with material that was identical to the source, but wrong as knowledge.
This exposes an uncomfortable truth: an AI can read a document accurately and cite it accurately, but it cannot automatically guarantee the document was right in the first place. A technical team can verify that the scan matches the parse, but it cannot judge, purely by technology, whether the content on the original image is correct.
Demo-ready means the model, retrieval, and parsing all work. Delivery-ready means even the source material has to be correct.
Six takeaways that changed how I see enterprise knowledge bases
1. Companies don’t build knowledge bases because they “want an AI”
The real need is an information-delivery problem: the same product question gets asked by sales, by business folks, by support — while R&D and after-sales hold the answers but can’t keep repeating them. A knowledge base is essentially an internal helpdesk: it first absorbs the high-frequency, answerable questions and routes the genuinely complex ones to humans.
“Universal demand” doesn’t mean “standardized delivery.” Where the documents live, who can see what, how stale material is handled, whether systems can be integrated, how answers are judged correct — these differ for every company. The entry point looks the same; the real work hides behind it.
2. Much of a company’s knowledge isn’t in documents at all
In older companies, many processes never made it into systems: processes passed down verbally from master to apprentice, rules announced once in a group chat, errors everyone quietly knows about but never formally corrected, and “official documents” that people on the ground know not to follow literally. This knowledge survives by word of mouth.
An AI has none of that context: if a document is missing a default rule, it won’t fill it in; if a document is wrong, it won’t self-correct just because “everyone knows.” So you can’t expect a client to hand over a folder, import it, and call the project done — clients themselves often don’t know which critical knowledge lives only in a few people’s heads.
3. Squat down instead of standing over people; don’t assume the AI knows more
Employees naturally fear “you’re here to replace me.” If you walk in and announce which jobs can be automated, nobody will hand over their real processes. The right stance is to squat down and first listen: which step is the most annoying, where is the most repetitive work, what’s most error-prone, how is it actually done today.
When a requirement seems unreasonable, don’t argue back immediately. Ask where it came from, what problem it solves, why it wasn’t done differently before, and why it must be done now — more often than not the client isn’t wrong; you just haven’t understood their business environment yet. The external team knows models, retrieval, and systems; the client’s employees know products, processes, and the industry. Neither side can judge alone.
4. Scope isn’t set by the boss; write an SOW and follow a change process
A boss can tell you whether they want it and roughly how much they’ll spend, but the delivery scope that actually goes into the contract has to be confirmed through on-site interviews (which can take days to a week). The conclusions should be written into an SOW (Statement of Work) covering two things: what you’ll deliver, and the preconditions the project depends on (what the client must provide, who participates, what’s missing that would block delivery).
The most common misunderstanding: if a goal appears in the final target, then every dependency along the way automatically belongs to the delivery team. It doesn’t. Documents that aren’t digitized, version chaos, rules that live only in employees’ heads — these are scope changes, not work automatically included in the original contract.
When requirements change, follow a change process. In practice, clients are far more likely to accept a later acceptance date than extra budget. The clearer your early interviews, POC, and SOW, the fewer renegotiations you’ll have later.
5. Why there’s no “one product to rule them all”
Because three kinds of problems can’t be flattened by any generic UI:
- Permissions: which departments can see which knowledge, what different roles can ask.
- Data integration: data doesn’t naturally sit in one tidy folder; it’s scattered across systems and messaging tools.
- Data governance: with a large document corpus, you must first decide what’s outdated, what’s valid, and what conflicts.
Data governance is essentially handling “new vs. old, true vs. false.” If old material is never de-listed, it still gets retrieved; the AI can find content without knowing which version the company actually follows. If the source is unreliable, no amount of better models, retrieval, or UI helps — it just delivers unreliable knowledge more conveniently.
One pragmatic note: when complex PDFs (images, 3D drawings, dimension callouts, irregular tables) are too unstable or costly to parse automatically, manual entry is a legitimate delivery approach. Delivery first means getting the job done, not proving every step was done by AI. And if legacy systems (ERP/OA) expose no API, don’t touch them — force-fitting a legacy system for a knowledge base project is a fast way to drag the project out of controllable scope.
6. Only what’s testable is acceptable: two test sets
Enterprise projects can’t be considered done because a few demo questions went well. The guide offers a very practical approach — two test sets:
- The delivery team’s own test set: design positive and negative cases per requirement, have the client confirm “does this match real business, are there gaps,” and only hand over the system once you pass.
- The client’s own acceptance test set: not shared in advance; the client tests and only reports pass / fail / how far off.
How do you compute a pass rate for natural-language output? This project’s approach: roughly 85% of the questions have definitive answers (e.g., which certifications a product passed, the current at a certain point), judged automatically by the machine; the remaining open-ended questions are evaluated by humans. Even when AI output is unstructured text, try to anchor acceptance on judgeable questions rather than “it read pretty well.”
Mapping it to my own project: what I hit, and what I’m missing
Comparing with my own LanceDB + DeepSeek build, the pitfalls I hit were all tooling-level: HuggingFace being blocked, permission issues, systemd not reading shell env vars… But I never considered that the source material itself might be wrong. When building a knowledge base for my own site, document versions, outdated content, and dimension callouts inside images are exactly the places most likely to be wrong and most easily ignored.
So the two pieces of homework really worth copying:
- Acceptance thinking: don’t just ask “is the answer good”; design a set of judgeable questions (positive and negative), let the machine judge the definitive ones and humans judge the open ones, and turn “feels fine” into “passes the data.”
- Source governance: sort new/old, true/false before ingestion; even hand-verify key documents — don’t let a wrong source poison the whole knowledge base.
Appendix: implementation checklist (run before project kickoff)
- Use case: Who are the internal users? Who keeps being asked the same questions? Which queries will the base absorb?
- On-site & scope: Have you talked to the people doing the actual work? What’s possible / not possible? Is the SOW’s preconditions clear?
- Documents & tacit knowledge: Are materials scattered? Any complex PDFs? Any word-of-mouth experience? Are new vs. old knowledge separated?
- Permissions & integration: Department visibility? Where does the data actually live? Do legacy systems have APIs? Are API-less systems excluded from scope?
- Tech & models: Decided on private vs. cloud? Is the team familiar with the stack? Was a manual approach evaluated? Was the model tested with a fixed question set?
- Testing & acceptance: Positive/negative cases? Was the test set confirmed by the client? Does the client run independent acceptance? Do most questions have definitive answers?
- New scope: Is a knowledge base ≠ a data-governance project? Are new requirements re-scoped?
Closing
The goal of enterprise AI delivery is not to prove that AI can do everything, but to make what the client actually needs testable, acceptable, and stable in production. Some problems are solved with AI, some with traditional tech, some are more reliably done by humans, and some can’t be done yet — say so clearly. That’s far more professional than propping up an illusion.