知识库工程（四）：今天的知识库怎么用
当前知识库已经不止“上传文档后聊天”。文档理解、关键词与向量混合召回、重排、引用、多模态解析、知识图谱、Agent 工具和长期记忆逐步进入同一套产品。能力增加后，使用重点从“能否回答”转到“证据是否正确、版本是否有效、权限是否一致、过程能否评测”。
RAGFlow 和 WeKnora 展示了两种正在靠近的产品形态。RAGFlow 从文档解析与 RAG 工作流扩展到上下文层、Agent 编排和 Memory；WeKnora 把快速问答、ReAct Agent、Wiki 与知识图谱放在同一框架中。它们都说明知识库正从单次检索组件演进为 LLM 的上下文基础设施。
一条可用的知识链路
原始文件进入系统后，需要解析版面、表格、标题层级和图像，再形成适合检索的文本单元。切片同时写入关键词索引和向量索引，查询从两路取得候选，融合后交给重排器。选中的证据经过权限、版本、去重与 token 预算处理，再进入 LLM 或 Agent。
链路中的前半段决定“资料是否可找”，后半段决定“证据如何被使用”。很多效果问题来自解析：扫描 PDF 没有 OCR，表格行列被打散，标题与正文断开，页眉在每个切片中重复。直接更换 LLM 通常无法修复这些缺陷。
混合检索覆盖精确词与语义
BM25 对编号、专有名词和错误码敏感，向量检索能覆盖改写、同义表达和自然语言问题。两路候选的原始分数没有统一尺度，常用 Reciprocal Rank Fusion 按名次融合：
$$ \operatorname{RRF}(d)=\sum_{r\in R}\frac{1}{k+\operatorname{rank}_r(d)} $$
$R$ 表示检索通道集合，$k$ 用于削弱头部名次差异。融合后的候选还可以交给 Cross-Encoder 重排器，让模型同时读取问题与段落，输出更细的相关性判断。Cross-Encoder 计算成本较高，适合处理几十条候选，不适合扫描完整语料。
切片策略也属于检索模型的一部分。短切片定位精确，却容易缺少上下文；长切片语义完整，会占用更多预算并混入无关内容。父子切片是一种折中：用短片段召回，再把其所属的较大段落送入模型。表格、代码和规章条款还需要按结构切分，固定字符数只能作为兜底。
GraphRAG 处理跨文档关系
向量检索擅长找到与问题相近的局部文本，跨多份文档的实体关系、组织结构和事件链可能需要图结构。GraphRAG 通常先抽取实体、关系与证据来源，形成图并生成社区层级的摘要；查询时根据局部实体或全局主题选择图节点、摘要和原文。
图谱并不会天然提高答案质量。实体消歧错误会把同名对象合并，关系抽取会遗漏限定条件，社区摘要也可能压缩掉关键事实。高质量 GraphRAG 需要保留每条关系对应的原始证据，并允许回到文档核对。文档规模小、问题以精确查找为主时，混合检索加重排通常更直接。
多模态 RAG 的难点在文档结构
PDF 和演示文稿中的知识并不全在正文。图表、流程图、页内坐标、批注和跨页表格都会影响含义。多模态解析可以用视觉语言模型描述图像，也可以采用 OCR、版面检测和表格识别组合。生成的描述需要与原图、页码和区域坐标绑定，否则引用只剩一段无法核对的文本。
检索阶段可以同时保存文本向量与图像向量，再按问题类型选择通道。问“图中红线代表什么”需要读取图像及其邻近说明；问“合同到期日”更适合结构化字段或 OCR 文本。所有内容统一转成一段描述会损失位置和视觉关系。
Agentic RAG 会主动调整检索
基础 RAG 对每个问题执行一次固定检索。Agentic RAG 可以先拆解问题，选择知识库，改写查询，检查证据是否充分，再决定补充检索、网络搜索或调用计算工具。它适合跨来源研究、故障分析和需要多步验证的任务。
自主性也增加了成本和不确定性。查询改写可能偏离原问题，多轮检索会重复取回同一资料，外部搜索还会引入不可信内容。运行时需要限制检索轮数、工具范围、时间和 token，并记录每轮查询与选中证据。证据不足时返回缺口，比无限循环更可控。
RAGFlow 与 WeKnora 的当前侧重
根据本文核对时两个项目主分支 README，可确认的产品能力如下。表格只描述项目官方列出的方向，不代表同一数据集上的效果对比。
| 关注点 | RAGFlow | WeKnora |
|---|---|---|
| 文档处理 | 强调复杂非结构化文档理解、模板化切片、切片可视化与人工干预 | 支持多类文档、按批次选择解析与切片配置，并提供解析过程追踪 |
| 检索 | 多路召回、融合重排、可追溯引用 | BM25、稠密检索、GraphRAG、父子切片和多种向量存储 |
| 知识来源 | 文件、网页及 Confluence、S3、Notion、Google Drive 等同步来源 | 文件、URL、飞书、Notion、语雀、RSS 等导入或同步来源 |
| 生成与 Agent | RAG 工作流、Agent 模板、MCP、代码执行组件与 Agent Memory | 快速问答、ReAct Agent、MCP、网络搜索、Wiki Mode 与长期知识组织 |
| 使用形态 | 面向 RAG 与 Agent 的上下文层，可自建并配置模型 | 自建知识框架，覆盖 Web、CLI、浏览器扩展及多个消息渠道 |
选择产品时，先拿自己的文档和问题做验证。复杂 PDF 关注解析后的表格、标题和图像；多知识库场景关注权限过滤；Agent 场景关注工具审批、轨迹和停止条件；持续同步的数据源关注增量更新、删除传播和版本冲突。功能清单只能说明入口存在，无法代替真实语料评测。
哪些任务不该先上 RAG
数据已经在关系数据库中，并且问题要求精确聚合时，SQL 或受控查询工具更可靠。规则明确的计算、审批和交易应由程序执行，LLM 只负责解释或收集参数。资料量很小且每次都必须完整阅读时，直接放入上下文可能更简单。答案要求逐字一致时，模板或原文摘录比生成式回答稳妥。
知识源质量差时也不宜急着建立向量索引。重复文件、过期制度、缺失权限和扫描错误会被检索系统放大。先完成内容清理、版本标记和访问控制，再讨论 Embedding 模型与重排器，投入顺序更合理。
评测决定知识库能否持续使用
离线评测需要覆盖精确事实、语义改写、跨文档问题、无答案、版本冲突和权限隔离。检索阶段记录 Recall@k、MRR 或 nDCG，生成阶段检查答案要点、引用支持和拒答。涉及 Agent 时，还要观察目标是否完成、动作是否越权、循环在何处终止以及消耗了多少资源。
线上反馈不能只收“有用”或“无用”。应记录用户指出的错误句、缺失来源和期望文档，再脱敏加入回归集。索引、Embedding、重排、Prompt 或模型任一变化，都要带版本跑同一批问题。知识库的长期价值来自可更新与可核对，而非一次演示中的流畅回答。
从信息检索、外部记忆走到 Agent，核心问题始终没有变化：系统依据哪些资料做出当前回答。RAGFlow、WeKnora 把更多环节放进一套产品，真正决定结果的仍是文档结构、检索策略、证据治理和持续评测。