我最近重新研究 RAG，最大的感受是，很多人把企业知识库想得太简单了。 上传 PDF，切成 Chunk，生成 Embedding，放进向量数据库，然后接一个大模型，最后做成聊天界面。 这套流程作为入门演示完全没问题，但如果要拿给企业真正使用，麻烦才刚刚开始。 比如一家公司的报销制度，2025 年和 2026 年分别有两个版本。现在员工问住宿报销上限，知识库应该回答哪个版本？ 假如新制度已经生效，但旧文件还存在数据库里，系统把旧版检索出来，然后回答得特别流畅，这算不算幻觉？ 从语言生成角度看，它可能完全忠实于检索材料。但从业务角度看，这个答案已经错了。 还有权限问题，总部可以看到所有门店的数据，门店只能看到自己有权访问的内容。如果只做语义检索，没有在正确的位置进行权限过滤，就可能出现两个用户问同一个问题，系统把不该给他的资料也检索出来。 这在企业里可不是普通的回答不准确，它可能直接涉及数据隔离和信息安全。 再往下还有很多麻烦。扫描 PDF 怎么解析，表格被拆开以后是否还能保留行列关系，文档更新了怎么同步，删除文件以后索引如何清理，两个资料相互矛盾的时候该相信哪个。 这些问题单独拿出来，都可以研究很久。 所以我现在看 RAG，更习惯把它分成两条主要流程。 一条负责把原始资料变成可以检索、可以更新、可以控制访问的数据；另一条负责理解用户问题、检索证据、排序，再根据证据生成回答。 其中每个环节都有自己的错误来源。Embedding 和 Rerank 当然重要，但不能因为换了一个更强的检索模型，就忽略前面资料解析错误或者权限规则不完整的问题。 我想做的企业知识库，至少应该让我查清楚几个东西。 这个答案引用了哪份资料，资料什么时候生效，用户有没有权限读取，系统为什么选择这个版本。如果没有足够证据，也应该能明确说明。 因为企业真正需要的，不只是一个特别会说话的 AI。 它还得知道自己依据的资料是什么，以及哪些话根本没有足够依据说出来。