从文档到可信答案：RAG 知识点化入库、证据门与反馈闭环

上一篇讲的是企业 RAG 智能体的生产分层：NewAPI 做入口，Adapter 做协议和策略，RAGFlow 做知识库，Model Router 和 vLLM 做推理。

但架构分清以后，真正难的问题才出现：把文档上传到知识库，并不等于系统拥有了可信知识。

我对 RAG 的一个基本判断是：模型幻觉往往不是生成阶段才发生的，它更早发生在文档治理、知识边界、召回和证据筛选阶段。前面没有把证据做干净，后面再靠 prompt 要求“不要胡说”，只能算心理安慰。

1. 文档不是知识，chunk 也不是知识

很多 RAG 项目会把“文档上传成功”和“知识库可用”画等号。这个等号很危险。

文档是资料容器。chunk 是检索载体。真正能支撑回答的，是有边界、有来源、有问法映射、有负例约束的知识点。

可以这样理解：

对象	定位	风险
Document	原始资料容器，保留文件、章节、表格和附件	原文很长，里面可能混杂多个主题
Knowledge Point	最小业务语义单元，能独立回答一组相近问题	如果没有来源和边界，容易变成二次创作
Chunk	embedding 和检索使用的文本片段	固定长度切分可能切断语义

一个制度文档可能包含适用范围、申请流程、审批规则、例外情况和处罚条款。如果直接按固定长度切 chunk，模型可能只拿到“申请前 30 日应…”这种半句话。

真正可靠的做法，是先按结构和语义拆知识点，再让 chunk 服务检索性能。

2. 入库阶段要比问答阶段更严格

RAG 的文档 embedding 发生在入库阶段，不是用户每次提问后才把文档重新向量化。

入库主链路可以交给 RAGFlow 托管：

上传文档
  -> 文档解析
  -> chunk
  -> embedding
  -> 写入 doc engine

但这不代表外部治理层可以消失。企业级场景至少要在入库前后补齐这些控制：

环节	目的
文档准入	判断文件是否可读、是否扫描件、是否需要 OCR、是否有敏感信息
文档类型识别	合同、手册、FAQ、表格、API 文档不能用同一种切分策略
tenant / KB / ACL	入库时就要确定谁能检索到这些内容
source span	每个 chunk 必须能回到原文页码、标题路径、段落或表格位置
embedding 版本	模型、维度、chunk profile 一旦变化，就要重建索引
入库质量门	检查召回、引用、负例和权限过滤是否通过

我不建议首版把解析、chunk、embedding、写库、检索全部拆成自研微服务。更稳的方式是“RAGFlow 托管主链路，外部治理层做准入、策略、质量门和回归评测”。

3. Knowledge Point 是知识库的逻辑骨架

Knowledge Point 可以理解为：

可独立回答一个或一组相近问题的最小业务语义单元。

它不是替代 Document，也不是替代 chunk。更准确地说，Document 保留原文真实性，chunk 服务检索效率，Knowledge Point 负责把业务语义、问法边界和评测样本组织起来。

它至少应该包含这些信息：

字段	作用
canonical_question	这个知识点最标准的问题表达
answer_fact	可被引用的事实答案
source_span	原文位置，支撑引用和回溯
aliases	缩写、别名、同义表达
query_variants	用户可能使用的不同问法
negative_queries	看起来像但不该命中的问题
evidence_policy	最小证据数量、冲突处理和拒答条件
eval_samples	后续回归测试使用的问题样本

这套结构的价值，不是为了让知识库“更复杂”，而是为了让它可测试。

如果一个知识点没有标准问法、没有负例、没有引用位置，那么召回结果好坏只能靠体感。体感一旦进入生产，就很难治理。

4. 用户不会按文档原句提问

企业知识库里最常见的错位，是文档写得很正式，用户问得很口语。

文档里可能写：

合同有效期届满前 30 日，由经办部门发起续签评估。

用户会问：

合同过期了咋办？
协议到期还能不能继续用？
到期合同是不是自动终止？
续签是谁来提？

如果只用用户原句做一次向量检索，很容易召回不稳定。

更好的检索入口是“原始问题 + 归一化问题 + canonical question + 高置信问法变体”。但扩展必须克制，不能无限改写。

建议默认最多 4 条查询：

1. raw query
2. normalized query
3. matched canonical question
4. highest-confidence variant

RAG 的难点不是把问题改写得越多越好，而是只增加能提高召回、不会引入噪声的表达。

5. hard negatives 是防误召回的关键

召回只看“命中正确答案”是不够的，还要看“相似但错误的问题不会命中”。

比如“合同怎么续签”和“合同怎么签署”很接近，但业务含义不同。前者问生命周期续约，后者问签署流程。如果系统总是把它们混在一起，答案看起来很像，实际却可能误导用户。

这就是 hard negative 的价值。

正向问题	hard negative
合同到期后如何处理	合同首次签署流程是什么
API Key 如何轮换	API Key 如何申请
PVE 虚机如何重启	PVE 集群如何新建节点
知识库如何发布	知识库如何删除

hard negatives 不只是评测数据，它会反过来塑造知识点边界。一个知识点越能说清“我不回答什么”，它越稳定。

6. Evidence Gate 比 prompt 更可靠

生产级 RAG 不应该把所有候选 chunk 都塞给 LLM，然后祈祷它自己判断。

Evidence Gate 要在生成前做决策：

判断项	可能动作
没有命中内部证据	拒答、澄清或在授权后联网
top1 分数低	降级回答或要求补充问题
证据冲突	标出冲突，要求用户确认
用户无权限	拒绝返回相关内容
问题需要最新信息	进入显式联网授权流程
敏感查询	禁止外发，要求脱敏

这个环节决定系统是否有“不会答”的能力。

很多人喜欢追求“什么都能回答”的智能体，但企业场景里，敢于拒答比自信胡答更值钱。

7. LLM 接收的是文本证据，不是向量

一个容易混淆的问题是：RAG 召回重排后，发给 vLLM 的到底是什么？

答案是 final messages，也就是文本化后的证据上下文、用户问题、系统规则和引用编号。

流程是：

RAGFlow / Adapter 找到证据
  -> 组织 source id、chunk text、metadata、source span
  -> 打包进 final messages
  -> vLLM tokenizer 编码成 input_ids
  -> 模型生成 token
  -> Adapter 汇总答案、sources、usage、audit

vLLM 不知道 Elasticsearch 里有哪些 chunk，也不知道哪个 evidence score 更高。它只看到 prompt。

因此，答案可信度不能只看模型文本。可信来源应该来自结构化的 rag.sources、retrieval trace 和 citation check。

8. 反馈闭环不是点赞按钮

“有用 / 无用”的反馈按钮只是入口，不是闭环。

真正的闭环应该是：

bad answer
  -> 保存问题、命中证据、答案、引用和用户反馈
  -> 判断是缺知识、召回错、重排错、引用错还是 prompt 错
  -> 修正文档、Knowledge Point、query variants 或 hard negatives
  -> 重新入库或重建索引
  -> 用 golden questions 回归测试
  -> 通过质量门后发布

这也是为什么我认为 RAG 项目必须保留“知识库工程”的角色。RAG 不是一次性导入文档后就自动变聪明，它需要持续整理、评测和修复。

好的知识库像一套可维护的产品文档，不像一个无人管理的文件夹。

9. 首版 PoC 应该验收什么

这个项目没有把首版目标放在高并发压测上，而是放在生命周期闭环上。我认为这个选择是正确的。

PoC 最应该验收这些能力：

验收项	标准
文档入库	Markdown、PDF、表格能解析，chunk 能回到原文
检索质量	正确文档能召回，误召回可量化
回答质量	答案基于证据，不用常识补企业制度
引用能力	返回 sources、document、chunk、source span
拒答能力	证据不足时拒答或澄清
权限边界	tenant、KB、user、ACL 在检索前生效
联网边界	Internal 禁网，Web 显式授权后才联网
工具调用	Codex tools / tool_calls 不能被字符串化
反馈修复	坏答案可转成 golden question 并回归验证

这些验收项比单纯 QPS 更早决定项目能不能上线。

性能可以后置优化，可信度如果一开始没有框架，后面补会很痛。

10. 小结

RAG 的质量不是模型单点能力，而是知识生命周期能力。

文档要能准入，知识点要有边界，chunk 要能追溯，问法要能覆盖，负例要能约束，证据要能过门，答案要能引用，坏答案要能回到知识库修复。

我喜欢把这件事概括成一句话：RAG 不是让模型替文档管理还债，而是把文档管理变成可检索、可验证、可修复的工程系统。

下一篇会继续讨论产品化边界：企业 RAG 智能体卖的到底是什么，为什么 Internal/Web 要分开，以及为什么 Token 工厂应该作为并行产品线，而不是塞进 RAGFlow。

---