将这三个概念进行深度融合落地首先需要理清这三者之间的关系和定位我们最容易犯的错是把知识图谱当成第三个答案源和 FAQ/RAG 并列。它不是答案源,它是把 FAQ 和 chunk 串起来的骨架。另外我们很容易简单的将FAQ作为短路问答一旦命中用户问题就直接返回预设答案而不考虑知识图谱和RAG。真正的融合架构是 并行召回 → 融合排序 → 分层决策像下面图示的流程相比简单的查询方案这里有三个变化点:从FAQ短路改成FAQ也是一路候选 —— 只有高置信查找意图才短路,否则参与融合图谱从给chunk加分升级成独立召回通道 —— 实体子图能同时拉出相关 chunk 和相关 FAQ用 RRF(倒数排名融合)统一三路打分 —— 而不是各算各的分没法比融合的命门:让 FAQ 也挂上实体(打通骨架)让FAQ 也做实体抽取这是三者融合的最大断点。一旦 FAQ 也做实体链接:用户问实体 X → 图谱能同时捞出关于 X 的 FAQ 关于 X 的 chunk图谱的关系X 关联 Y → 能从 FAQ 里的 X 跳到文档里的 Y三者被实体这根骨架真正串成一张网,而不是三个孤岛按意图分配主次(而不是一套流程走到底)具体行动:FAQ 入库时(knowledge 表),复用现有的 entity extraction 对 questionanswer 抽实体,写一张 faq_entities 关联表。这是所有融合的地基。关系/对比类问题是纯 RAG 和纯 FAQ 都答不好的 —— 这正是知识图谱唯一能当主角的场景(遍历子图,把关系作为结构化事实喂给 LLM)。最终答案怎么合体呈现用户: “退货流程,还有和换货有什么区别?”FAQ 给确定答案,RAG 补充综合,图谱把关系画出来 —— 三者各司其职,不是三选一。一句话总结:FAQ是答案、RAG是内容、图谱是骨架。用实体把三者挂到同一张网上,并行召回后用RRF融合排序,再按意图决定谁当主角。要打通三者,得让知识图谱变成中枢——chunk 和 FAQ 都往同一套 entity_id 上挂。一句话:一次实体抽取,产出一张骨架;chunk 和 FAQ 都在这张骨架上登记。入库操作过程为什么阶段 D 是命门:阶段 B 已经把文档实体抽好了。阶段 C 生成的 FAQ 里提到退货、“7天”,阶段 D 的链接器一跑,alias 精确匹配直接命中阶段 B 建好的同一个entity_id——不用重新消歧,天然共享骨架。查询时用户问退货,实体子图能同时捞出这条 FAQ 和相关 chunk。三个必须处理好的工程点① 时序:C/D 必须在 B 之后。 实体抽取要成一条串行的后台任务链:async def _enrich(doc_id, chunks, kb_id):await entity_graph.extract_from_document(…) # B:先建骨架faqs await generate_faq_candidates(…) # C:再生成FAQawait link_faq_entities(faqs) # D:挂到骨架asyncio.ensure_future(_enrich(…)) # 整体后台,上传仍秒回② 失败隔离:阶段 A 绝不能被 B/C/D 拖累。 FAQ 生成要调 LLM,可能慢/失败。chunk 索引(A)必须先同步完成、先能检索;B/C/D 是锦上添花的后台增强,挂了不影响文档可用。③ 刷新闭环(provenance 的回报)。 文档更新重新入库时,靠 FAQ 的 source_chunk_ids 反查:哪些自动 FAQ 的源 chunk 变了 → 标记源文档已更新,建议复审。这是把 source_chunk_ids 存下来的最大价值——否则自动 FAQ 会变僵尸。表格/图片内容也顺带打通阶段 C 生成 FAQ 时可以针对表格问这个参数表说明了什么,针对图片问这张图展示的流程是什么——让多模态内容也进 FAQ,不只是躺在 chunk 里。何时生成FAQ“每篇文档解析完就无条件自动生成 FAQ”不建议。因为有四个实际问题,尤其在资源紧张的部署里:更好的设计是触发和入库解耦,而且两条路径互补不要把 FAQ 生成硬编码进入库流程。拆成:为什么路径2(查询驱动)比路径1更该做最该进FAQ的问题,不在文档里,在用户的提问里。 文档驱动是我猜用户会问什么,查询驱动是用户已经问了什么。你已经有 qa_records 表(还带 is_bad_case),这是现成的金矿:某个问题这周被问了 30 次、每次都走 RAG 慢速生成 → 明确信号:该固化成 FAQ聚类后去重是天然的(相似问题归一簇)生成的 FAQ 精准命中真实需求,不是凭空猜关于时序:不管哪条路径触发,FAQ 生成都必须在实体抽取(阶段B)之后,这样才能挂到同一套 entity_id 骨架上。区别只是触发时机:路径1手动/定时触发时,阶段B早就跑完了 → 直接复用已有实体不是解析完立刻同步生成,而是骨架建好后,择机生成推荐的默认策略给用户一个开关,而不是替他决定。 默认关闭自动生成,提供生成候选问答按钮 后台查询驱动挖掘。一句话总结不是每文档解析完就自动生成。 入库只负责建 chunk 实体骨架(必做);FAQ 生成是解耦的、按需触发的动作,且优先走挖用户真实提问(qa_records)这条路,而不是盲目对每篇文档全量生成——省 token、省GPU、少重复、少噪声,还更准。关注文档了解最新进展https://my.feishu.cn/wiki/WkDQwyqgeiZ5yfk2CKnclbDBn8fhttps://weixin.qq.com/g/AQYAABfasyRBJy_77TYaONhyhB4ljdAkdZOS4KUD7qTSEqciBpBhjCfbkzxEeVcL (二维码自动识别) 基于FAQ、RAG和知识图谱构建全新一代私有化知识库系统。
将这三个概念进行深度融合落地首先需要理清这三者之间的关系和定位我们最容易犯的错是把知识图谱当成第三个答案源和 FAQ/RAG 并列。它不是答案源,它是把 FAQ 和 chunk 串起来的骨架。另外我们很容易简单的将FAQ作为短路问答一旦命中用户问题就直接返回预设答案而不考虑知识图谱和RAG。真正的融合架构是 并行召回 → 融合排序 → 分层决策像下面图示的流程相比简单的查询方案这里有三个变化点:从FAQ短路改成FAQ也是一路候选 —— 只有高置信查找意图才短路,否则参与融合图谱从给chunk加分升级成独立召回通道 —— 实体子图能同时拉出相关 chunk 和相关 FAQ用 RRF(倒数排名融合)统一三路打分 —— 而不是各算各的分没法比融合的命门:让 FAQ 也挂上实体(打通骨架)让FAQ 也做实体抽取这是三者融合的最大断点。一旦 FAQ 也做实体链接:用户问实体 X → 图谱能同时捞出关于 X 的 FAQ 关于 X 的 chunk图谱的关系X 关联 Y → 能从 FAQ 里的 X 跳到文档里的 Y三者被实体这根骨架真正串成一张网,而不是三个孤岛按意图分配主次(而不是一套流程走到底)具体行动:FAQ 入库时(knowledge 表),复用现有的 entity extraction 对 questionanswer 抽实体,写一张 faq_entities 关联表。这是所有融合的地基。关系/对比类问题是纯 RAG 和纯 FAQ 都答不好的 —— 这正是知识图谱唯一能当主角的场景(遍历子图,把关系作为结构化事实喂给 LLM)。最终答案怎么合体呈现用户: “退货流程,还有和换货有什么区别?”FAQ 给确定答案,RAG 补充综合,图谱把关系画出来 —— 三者各司其职,不是三选一。一句话总结:FAQ是答案、RAG是内容、图谱是骨架。用实体把三者挂到同一张网上,并行召回后用RRF融合排序,再按意图决定谁当主角。要打通三者,得让知识图谱变成中枢——chunk 和 FAQ 都往同一套 entity_id 上挂。一句话:一次实体抽取,产出一张骨架;chunk 和 FAQ 都在这张骨架上登记。入库操作过程为什么阶段 D 是命门:阶段 B 已经把文档实体抽好了。阶段 C 生成的 FAQ 里提到退货、“7天”,阶段 D 的链接器一跑,alias 精确匹配直接命中阶段 B 建好的同一个entity_id——不用重新消歧,天然共享骨架。查询时用户问退货,实体子图能同时捞出这条 FAQ 和相关 chunk。三个必须处理好的工程点① 时序:C/D 必须在 B 之后。 实体抽取要成一条串行的后台任务链:async def _enrich(doc_id, chunks, kb_id):await entity_graph.extract_from_document(…) # B:先建骨架faqs await generate_faq_candidates(…) # C:再生成FAQawait link_faq_entities(faqs) # D:挂到骨架asyncio.ensure_future(_enrich(…)) # 整体后台,上传仍秒回② 失败隔离:阶段 A 绝不能被 B/C/D 拖累。 FAQ 生成要调 LLM,可能慢/失败。chunk 索引(A)必须先同步完成、先能检索;B/C/D 是锦上添花的后台增强,挂了不影响文档可用。③ 刷新闭环(provenance 的回报)。 文档更新重新入库时,靠 FAQ 的 source_chunk_ids 反查:哪些自动 FAQ 的源 chunk 变了 → 标记源文档已更新,建议复审。这是把 source_chunk_ids 存下来的最大价值——否则自动 FAQ 会变僵尸。表格/图片内容也顺带打通阶段 C 生成 FAQ 时可以针对表格问这个参数表说明了什么,针对图片问这张图展示的流程是什么——让多模态内容也进 FAQ,不只是躺在 chunk 里。何时生成FAQ“每篇文档解析完就无条件自动生成 FAQ”不建议。因为有四个实际问题,尤其在资源紧张的部署里:更好的设计是触发和入库解耦,而且两条路径互补不要把 FAQ 生成硬编码进入库流程。拆成:为什么路径2(查询驱动)比路径1更该做最该进FAQ的问题,不在文档里,在用户的提问里。 文档驱动是我猜用户会问什么,查询驱动是用户已经问了什么。你已经有 qa_records 表(还带 is_bad_case),这是现成的金矿:某个问题这周被问了 30 次、每次都走 RAG 慢速生成 → 明确信号:该固化成 FAQ聚类后去重是天然的(相似问题归一簇)生成的 FAQ 精准命中真实需求,不是凭空猜关于时序:不管哪条路径触发,FAQ 生成都必须在实体抽取(阶段B)之后,这样才能挂到同一套 entity_id 骨架上。区别只是触发时机:路径1手动/定时触发时,阶段B早就跑完了 → 直接复用已有实体不是解析完立刻同步生成,而是骨架建好后,择机生成推荐的默认策略给用户一个开关,而不是替他决定。 默认关闭自动生成,提供生成候选问答按钮 后台查询驱动挖掘。一句话总结不是每文档解析完就自动生成。 入库只负责建 chunk 实体骨架(必做);FAQ 生成是解耦的、按需触发的动作,且优先走挖用户真实提问(qa_records)这条路,而不是盲目对每篇文档全量生成——省 token、省GPU、少重复、少噪声,还更准。关注文档了解最新进展https://my.feishu.cn/wiki/WkDQwyqgeiZ5yfk2CKnclbDBn8fhttps://weixin.qq.com/g/AQYAABfasyRBJy_77TYaONhyhB4ljdAkdZOS4KUD7qTSEqciBpBhjCfbkzxEeVcL (二维码自动识别)