最近我在给芝麻园地搭自己的 RAG 知识库（LanceDB + DeepSeek，之前的文章写过），一直以为「把文档喂进去、能回答」就算成了。直到读到 Hedy Zhang 这篇万字长文《企业 AI 知识库从 0 到 1 真实交付指南》，被里面那个「印错的纸」的案例结结实实震了一下。
这篇文章想讲清楚一件事：企业 AI 知识库从「能演示」走到「能交付」，难点从来不在模型，而在资料、人员、权限、系统、边界和验收。
一个让人后背发凉的案例：印错的纸
项目测试时，系统答错了一个产品问题。排查从模型开始：模型引用了知识库，知识库检索命中了资料，文档解析和扫描图片一致 —— 从技术链路看，每一步都是对的。
但答案就是错的。
一路追到最原始的纸质设计文档才发现：那份资料当年打印的时候就印错了。 老员工其实都知道那里是错的，平时根本不照纸上的内容干活，这个错误早就通过口口相传成了默认背景。但没人重新打印，也没人把更正正式记录下来。
于是纸质资料被扫描、解析、录入知识库后，系统得到了一份「与原文完全一致、但知识本身错误」的资料。
这件事说明了一个残酷的事实：AI 可以准确读取一份资料、准确引用一份资料，但它无法自动保证这份资料原本就是对的。 技术团队能检查扫描和解析是否一致，却不可能只靠技术判断原始图片上的内容究竟对不对。
能演示，是模型、检索、解析都没问题；能交付，是连源头资料都得对。
读完这六点，我对「企业知识库」的理解变了
1. 企业做知识库，通常不是「想要一个 AI」
背后真正要解决的是信息传递问题：同一个产品问题，销售问、业务问、客服问，研发和售后掌握答案却不可能一直重复回答。知识库本质是一个内部客服，先接住高频、有确定答案的问题，真正复杂的问题再转人工。
「需求通用」不等于「交付可标准化」。资料在哪、谁能看、旧资料怎么处理、系统接不接得进去、答案怎么判对 —— 每家企业都不一样。入口看起来相同，真正进场以后，工作量全藏在后面。
2. 大量知识根本不在文档里
老企业的很多流程没进系统：师傅带徒弟是嘴上说的，规则在群里说一次，有些错误大家用久了都知道但没人正式改过，有些「正式文件」干活的人知道不能照做。这些知识靠口口相传维持。
AI 没有任何背景：资料少一条默认规则，它不会自己补；资料是错的，它也不会因为「老员工都知道」就自动改正。所以不能指望客户交个文件夹、导入系统就算完成—— 客户自己都未必知道哪些关键知识只在少数人脑子里。
3. 做交付要「半蹲下来」，别假设 AI 更懂
员工天然怕「你是来替代我的」。一进场就站在员工头顶说「哪些岗位可以自动化」，对方绝不会把真实流程交出来。正确的姿态是半蹲下来，先听：哪个环节最烦、哪里重复劳动最多、哪里最容易出错、现在具体怎么完成。
遇到看起来不合理的需求，不要上来就反驳。先问它从哪来、想解决什么问题、为什么过去没这样做、为什么现在必须做 —— 很多时候不是客户的想法错了，而是你还没理解他所在的业务环境。外部团队懂模型、检索和系统，客户的员工懂产品、流程和行业，哪一边单独做判断都不够。
4. 边界不能只听老板的，要写 SOW、要走变更流程
老板能告诉你的是「想不想做」和「大概多少预算」，但真正签进合同的交付边界，得靠现场访谈（可能持续几天到一周）确认。结论要写进 SOW（工作范围说明），明确两类：一是交付什么，二是项目成立依赖的前置条件（客户要提供什么资料、谁配合、缺了哪项就无法交付）。
最容易产生的误会是：最终目标里出现了某个结果，中间所有依赖都天然属于交付团队。其实不是。资料没数字化、版本混乱、关键规则只在脑子里 —— 这些是范围变化，不是原合同自动包含的工作。
需求变了怎么办？走变更流程。现实中客户更可能接受验收时间后移，而不是直接追加费用。所以前期访谈、POC、SOW 做得越清楚，后面需要重新谈判的次数就越少。
5. 为什么没有「一统天下」的标准产品
因为有三类问题没法被一个通用界面抹平：
-
权限：哪个部门能看到哪些知识，不同角色能问到什么。
-
数据接入：数据不会天然集中在一个整理好的文件夹里，它散在系统、沟通工具里。
-
数据治理：文档量一大，哪些过时、哪些有效、哪些冲突，要先治理。
数据治理的本质是处理「新旧真假」。旧资料不下线就仍会被召回，AI 能找到内容却不知道企业现在执行哪一版。源头不可靠，后面的模型、检索、界面再好，也只是把不可靠的知识更方便地提供给用户。
顺带一个务实观点：复杂 PDF（图片、三维图、尺寸标注、不规则表格）自动识别不稳定、成本高时，人工录入也是交付方案。交付首先要保证事情能做完，而不是证明每一个步骤都由 AI 完成。老系统（ERP/OA）没有接口就不要轻易碰 —— 为了一个知识库强行改造遗留系统，很容易把项目拖进无法控制的范围。
6. 可测才可验：两套测试集
企业项目不能靠演示时问对了几个问题就算完成。文章给了很实操的做法 ——两套测试集：
-
交付团队自己的测试集：按各需求点设计正向 + 反向用例，先交客户确认「范围是否符合真实业务、有没有遗漏」，达标后再交系统。
-
客户自己的验收测试集：不提前给交付团队看，客户测后只反馈达标 / 不达标 / 还差多少。
自然语言输出怎么算通过率？这个项目用的口径是：约 85% 的题目有确定答案（比如某个产品通过了哪些认证、某处电流是多少），机器直接判对错；剩下没有标准答案的题目由人来评估。即使 AI 输出是非结构化文本，也要尽量把验收建立在可判断的问题上，不能全凭「读起来好像不错」。
落到自己的项目上：我踩过哪些，还缺哪些
对照自己的 LanceDB + DeepSeek 实践，我踩过的是工具层的坑：HuggingFace 被墙、权限问题、systemd 不读环境变量…… 但从来没想过「源头资料本身可能是错的」。给我的网站做知识库时，文章版本、过时内容、图片里的尺寸标注，这些恰恰是最容易出错又最容易被忽略的地方。
所以真正值得抄的作业是这两条：
-
验收思路：别只问「答得好不好」，要设计一组可判断的题目（正反用例），确定答案机器判、开放答案人工判，把「感觉还行」变成「数据达标」。
-
源头治理：先分清新旧真假再入库，宁可人工校一遍关键资料，也别让错误源头污染整个知识库。
附：落地检查清单（项目启动前自查）
-
使用场景：服务哪些内部人员？谁在被重复问？接住哪类查询？
-
现场与边界：是否和实际干活的人聊过？哪些能做 / 不能做？SOW 写清前置条件？
-
资料与历史知识：资料分散吗？有没有复杂 PDF？有无口传经验？新旧知识是否区分？
-
权限与数据接入：部门可见性？数据在哪？旧系统有无接口？无接口的是否排除出范围？
-
技术与模型：私有化还是云端定了吗？用的技术团队熟不熟？人工方案评估过吗？固定问题测过模型吗？
-
测试与验收：正反用例？测试集交客户确认？客户独立验收？多数题有确定答案？
-
新范围：知识库 ≠ 数据治理项目？新需求是否重新确认范围？
结尾
企业 AI 交付的目标，** 不是证明 AI 什么都能做，而是把客户真正要用的东西做到可测试、可验收、能稳定运行。** 有些问题用 AI，有些用传统技术，有些用人力更可靠，还有些问题做不了，就明确说做不了 —— 这比硬撑着演示一个假象，要专业得多。