# 基于 ES 混合检索与知识图谱的高频应用场景与实施路线 > 文档性质：场景扩展规划与实施建议。 > > 目标：基于当前已具备的 ES 混合检索、文档治理链、事项图谱、Research、QA 能力，筛选出高频、易落地、能显著提升效率或辅助决策的应用场景，并给出分阶段实施方案。 --- ## 1. 结论摘要 如果以“高频使用、能快速见效、尽量复用现有能力”为优先原则，最值得优先推进的不是大型分析平台，而是直接嵌入日常工作流的助手型场景。 建议优先级如下： | 优先级 | 场景 | 是否现阶段可实施 | 主要价值 | |--------|------|------------------|----------| | P0 | 收文分办助手 | 可以 | 缩短分办耗时，降低转错部门概率 | | P0 | 审稿与引用校验助手 | 可以 | 降低错引、漏引、引用过期风险 | | P0 | 事项预审助手 | 可以 | 降低补件率，提高一次性告知质量 | | P0 | 咨询答复助手 | 可以 | 提升答复效率和口径一致性 | | P1 | 一页式政策简报助手 | 可以 | 压缩汇报材料准备时间 | | P1 | 新政影响排查助手 | 可以，但需补中间层 | 支持制度调整与执行部署 | | P2 | 督办执行监测助手 | 后续扩展 | 支持督办、闭环追踪、风险发现 | | P2 | 主题地图与专题追踪 | 后续扩展 | 支持跨周期专题治理与研究 | | P2 | 治理分析与风险洞察 | 后续扩展 | 支持面向管理层的统计分析 | | P3 | 条款级合规审查与证据回链 | 需等待 Phase 2 | 支持更细粒度的法条依据定位 | 核心判断： - 现阶段最容易落地的是“建议型”和“校验型”场景，而不是“自动决策型”场景。 - 最容易高频使用的是收文、审稿、办事预审、咨询答复四类日常动作。 - 最适合作为第二阶段扩展的是政策简报和新政影响排查，因为它们对当前 Search + Graph + Research 复用度高。 --- ## 2. 场景筛选原则 本文档按以下五个维度排序： 1. 使用频率：是否属于日常反复发生的工作动作。 2. 效率收益：是否能直接缩短查询、整理、判断、答复时间。 3. 决策价值：是否能辅助分办、审稿、执行部署、管理判断。 4. 落地难度：是否可以在当前接口和数据基础上实现 MVP。 5. 组织阻力：是否可以先以“辅助建议”形式上线，而不触发高风险审批流程。 “容易落地”在本项目中的判断标准： - 不新增复杂图谱 schema。 - 不依赖条款级 Article 抽取与条款级关系。 - 优先复用现有 Search、Document、Graph、Matter、Research、QA 链路。 - 优先新增中间层接口和页面，不改动现有主链路底座。 --- ## 3. 当前能力基线 当前系统已经具备以下可复用能力，可直接支撑场景扩展： | 能力层 | 当前已具备内容 | 对扩展场景的作用 | |--------|----------------|------------------| | 检索层 | ES 混合检索、搜索建议、高亮、聚合、权限过滤 | 负责召回相似文档、相似案例、相关政策 | | 文档层 | 文档详情、版本链、依据链、修订史、同主题、推荐 | 负责引用校验、治理关系展示、依据回链 | | 图谱层 | 实体搜索、相关文档、图谱概览、事项图谱 | 负责串联部门、事项、主题、地域、文件关系 | | 事项层 | matters 列表、matter card、requirements | 负责事项预审、条件材料时限问答 | | Research | 多会话、资料导入、seed_doc_ids、引用输出 | 负责简报、专题梳理、长文本生成 | | QA | 独立 SSE 问答、上下文导入、引用文档回跳 | 负责咨询答复、轻量问答场景 | | 前端交互 | 资料篮、统一导入弹窗、轻预览、版本抽屉 | 负责跨页上下文沉淀和复用 | 因此，现阶段不需要先做新的“大平台”，而是应该优先做若干个工作流入口，把已有能力包装成更贴近日常工作的助手。 --- ## 4. 优先级总表 ### 4.1 现阶段可以实施的场景 | 优先级 | 场景 | 目标用户 | 频率 | 落地难度 | 现有复用度 | 建议定位 | |--------|------|----------|------|----------|------------|----------| | P0 | 收文分办助手 | 办公室、收文岗、综合处室 | 很高 | 低 | 高 | 辅助建议，不自动派单 | | P0 | 审稿与引用校验助手 | 起草岗、审稿岗、法规岗 | 很高 | 低 | 高 | 校验面板，不自动改稿 | | P0 | 事项预审助手 | 窗口、审批岗、热线坐席 | 很高 | 低 | 很高 | 自然语言导向事项卡 | | P0 | 咨询答复助手 | 热线、政务服务、业务处室 | 很高 | 中低 | 高 | 带引用答复草稿 | | P1 | 一页式政策简报助手 | 综合处、研究室、领导秘书 | 中高 | 中低 | 高 | 模板化输出 | | P1 | 新政影响排查助手 | 政策处、法规处、牵头部门 | 中高 | 中 | 中高 | 新旧政策差异与影响范围 | ### 4.2 后续扩展场景 | 优先级 | 场景 | 目标用户 | 频率 | 落地难度 | 依赖变化 | |--------|------|----------|------|----------|----------| | P2 | 督办执行监测助手 | 督查室、办公室、专项办 | 中高 | 中高 | 需补执行反馈和状态口径 | | P2 | 主题地图与专题追踪 | 研究室、综合处、专题专班 | 中 | 中高 | 需补主题聚合与专题页 | | P2 | 治理分析与风险洞察 | 管理层、综合分析岗 | 中 | 高 | 需补稳定统计指标与分析接口 | | P3 | 条款级合规审查与证据回链 | 法规岗、审查岗 | 中 | 很高 | 需等待 Phase 2 条款图 | --- ## 5. 现阶段优先实施场景 ## 5.1 P0-1 收文分办助手 ### 业务目标 围绕一篇新收文件，快速给出： - 建议主办部门 - 建议协办部门 - 相似历史件 - 相关依据文件 - 相关事项或政策主题 ### 为什么高频且容易落地 - 收文分办是非常典型的日常动作。 - 当前已经有混合检索、发文机关、事项、主题、部门相关图谱信息。 - 可以先做“辅助建议”，不进入自动派单，组织阻力低。 ### 当前可复用能力 - `POST /api/v1/search` - `GET /api/v1/document/{doc_id}` - `GET /api/v1/graph/document/{doc_id}/recommendations` - `POST /api/v1/graph/search` - `POST /api/v1/graph/related-docs` - `POST /api/v1/qa` 或 `POST /api/v1/research` 生成建议说明 ### 建议 MVP 功能 1. 输入来文标题、摘要或正文。 2. 返回 Top N 相似历史文件。 3. 返回候选主办部门和协办部门。 4. 返回判断依据，包括相似文档、发文机关、主题、事项。 5. 提供“复制分办建议”与“查看相似历史件”能力。 ### 建议后端实现 建议新增中间层接口： - `POST /api/v1/workbench/routing-suggest` 建议处理流程： 1. 对来文文本做轻量摘要和关键词抽取。 2. 用 ES 混合检索找相似历史文件。 3. 从召回文件中统计高频办理部门、关联事项、关联主题。 4. 通过图谱补充发文机关、部门、事项关系证据。 5. 由 LLM 输出“建议主办 / 协办 + 原因说明”，但保留原始证据列表。 ### 建议前端实现 建议新增页面： - `frontend/src/views/RoutingSuggestView.vue` 也可以先挂到管理后台或 Mock 工作台中，作为 MVP 试点入口。 页面结构建议： - 左侧：来文输入区 - 中间：建议主办 / 协办卡片 - 右侧：相似历史件、相关事项、依据文件 ### 数据与模型要求 - 不新增图谱 schema。 - 只需保证 Document 与 Organization、PolicyTheme、Matter 关系可稳定查询。 - 建议补一个“历史主办部门”映射字段或业务侧人工配置表，提高建议质量。 ### 验收指标 - 分办建议生成时间可接受。 - Top 5 相似历史件能为人工判断提供有效参考。 - 主办部门建议命中率达到试点部门可接受水平。 - 人工最终分办耗时下降。 --- ## 5.2 P0-2 审稿与引用校验助手 ### 业务目标 对拟稿或答复稿进行依据校验，减少： - 引用不存在 - 引用已废止 - 引用不是最新版本 - 依据链缺失 - 表述与正式文件口径不一致 ### 为什么高频且容易落地 - 起草、审稿、答复都频繁发生。 - 当前已具备文档检索、版本链、修订史、依据链能力。 - 可以先做“校验和提醒”，不做自动改稿，组织接受度高。 ### 当前可复用能力 - `POST /api/v1/search` - `GET /api/v1/document/versions/{content_hash}` - `GET /api/v1/graph/document/{doc_id}/revision-history` - `GET /api/v1/graph/document/{doc_id}/policy-chain` - `POST /api/v1/qa` ### 建议 MVP 功能 1. 输入拟稿标题和正文。 2. 自动抽取正文中提到的文件名、文号、机关名称。 3. 检查引用文件是否存在。 4. 检查是否已废止或有更新版本。 5. 给出相似正式文件和可补充依据。 6. 输出“校验通过项 / 风险项 / 建议补充项”。 ### 建议后端实现 建议新增接口： - `POST /api/v1/workbench/draft-review` 建议处理流程： 1. 用规则 + LLM 轻量抽取正文中的文件引用。 2. 使用搜索接口对引用文件做标准化匹配。 3. 对命中的文档查询版本链和修订史。 4. 对正文关键句做检索，推荐可能应引用的相关文件。 5. 输出结构化校验结果。 ### 建议前端实现 建议新增页面： - `frontend/src/views/DraftReviewView.vue` 页面结构建议： - 左侧：文稿输入区 - 中间：校验结果区 - 右侧：引用文件详情、版本链、可补充依据 ### 数据与模型要求 - 不新增 schema。 - 建议增强对文号和标题归一化匹配的规则。 - 建议复用现有 normalized title / doc_code 口径。 ### 验收指标 - 引用识别准确率可接受。 - 对已废止、已修订文件能给出明确提醒。 - 校验面板可支持试点部门日常使用。 - 审稿平均耗时下降。 --- ## 5.3 P0-3 事项预审助手 ### 业务目标 让用户用自然语言输入诉求后，系统直接给出： - 最可能匹配的事项 - 办理条件 - 所需材料 - 办理时限 - 办理部门 - 依据文件 ### 为什么高频且容易落地 - 窗口、审批、热线、服务导办都高频。 - 当前已具备 Matter 搜索、Matter 卡、requirements、QA 能力。 - 本质是把现有事项能力包装成更直接的业务入口。 ### 当前可复用能力 - `GET /api/v1/graph/matters` - `GET /api/v1/graph/matters/{matter_id}` - `GET /api/v1/graph/matters/{matter_id}/requirements` - `POST /api/v1/qa` - 已有 `/matters`、`/matters/:matterId` ### 建议 MVP 功能 1. 输入自然语言问题，例如“建设项目审批需要什么材料”。 2. 返回 Top 3 候选事项。 3. 展开事项卡和 requirements。 4. 支持直接追问材料、时限、对象、依据。 5. 支持导入 QA 或 Research。 ### 建议后端实现 短期可不新增后端主接口，先在前端编排现有 matters + QA。 中期建议补一个轻量匹配接口： - `POST /api/v1/workbench/matter-precheck` 建议处理流程： 1. 用关键词和语义检索匹配候选事项。 2. 拉取候选事项卡和 requirements。 3. 对于无法唯一定位的情况，返回候选列表而不是强制问答。 4. 需要解释时再调用 QA 输出摘要说明。 ### 建议前端实现 优先方案：直接在 `/matters` 页增加“自然语言预审”模式。 也可新增： - `frontend/src/views/MatterPrecheckView.vue` 页面结构建议： - 顶部：一句话输入框 - 中部：事项匹配列表 - 下方：事项卡详情与 requirements - 右侧：依据文件与进一步问答入口 ### 数据与模型要求 - 不新增 schema。 - 重点提升事项名称别名、常见口语表达映射。 - 可补充一个事项别名词表或领域同义词表。 ### 验收指标 - 自然语言能够稳定定位到正确事项。 - 材料、时限、部门三类高频问题可直接回答。 - 预审后人工补件率下降。 - 一次性告知质量提升。 --- ## 5.4 P0-4 咨询答复助手 ### 业务目标 针对群众咨询、内部业务咨询、政策口径咨询，快速给出： - 答复草稿 - 依据文件引用 - 适用事项或适用对象 - 风险提示或需人工确认项 ### 为什么高频且容易落地 - 热线、窗口、业务处室答复都很高频。 - 当前已具备独立 QA、引用回跳、事项卡、Research 能力。 - 可以先做“答复草稿 + 引用”，不直接替代人工定稿。 ### 当前可复用能力 - `POST /api/v1/qa` - `POST /api/v1/research` - Matter 相关接口 - 文档详情、依据链、修订史 ### 建议 MVP 功能 1. 输入咨询问题。 2. 输出答复草稿。 3. 展示引用文件列表。 4. 展示适用事项、条件、材料、部门。 5. 支持导出答复文本或导入 Research 深挖。 ### 建议后端实现 短期可直接在现有 `/qa` 上增加“答复模式”模板，不必单独做复杂链路。 中期建议新增接口： - `POST /api/v1/workbench/reply-assistant` 建议处理流程： 1. 判断问题更偏政策依据、事项材料还是部门职责。 2. 对应调用 Matter、Search、Graph、QA。 3. 统一输出“结论 + 依据 + 风险提示 + 引用列表”。 ### 建议前端实现 优先方案：在现有 `/qa` 中增加“答复模式”入口。 中期可新增： - `frontend/src/views/ReplyAssistantView.vue` 页面结构建议： - 左侧：问题输入与场景类型 - 中间：答复草稿 - 右侧：引用文件、事项信息、风险提示 ### 数据与模型要求 - 不新增 schema。 - 建议增加答复模板和标准口径模板。 - 建议明确答复中“自动生成内容”与“引用依据”的展示边界。 ### 验收指标 - 首次答复耗时下降。 - 答复口径一致性提升。 - 引用文件可回跳、可核验。 - 人工修改成本可接受。 --- ## 6. 第二阶段建议场景 ## 6.1 P1-1 一页式政策简报助手 ### 价值 围绕某一主题、事项、部门或新文件，自动生成一页式简报： - 核心结论 - 关键文件 - 时间演进 - 依据链 - 相关事项 - 风险与建议 ### 为什么可以较快实施 - 可以直接复用 Research + 图谱关系 + 引用能力。 - 本质上是模板化输出，不要求全新底层能力。 ### 建议实施方式 - 在 Research 中增加“简报模板”模式。 - 增加导出 Word / Markdown / 简报卡片能力。 - 补一个 `brief_mode` 或单独中间层接口即可。 ### 建议优先级 - 放在 P1，优先级高于主题地图与治理分析。 --- ## 6.2 P1-2 新政影响排查助手 ### 价值 在一份新文件发布后，快速回答： - 影响哪些既有文件 - 影响哪些事项和办理口径 - 影响哪些部门和地域 - 哪些制度文件可能需要同步调整 ### 为什么值得做 - 对法规处、政策处、牵头部门有较高价值。 - 这是“辅助决策”价值最直接的场景之一。 ### 为什么比 P0 稍晚 - 需要在中间层做更多关系归纳和影响范围聚合。 - 输出必须更稳，不能只给“相似文档”，而要给“受影响对象”。 ### 建议实施方式 建议新增接口： - `POST /api/v1/workbench/impact-assessment` 建议处理流程： 1. 对新政文档做主题、事项、部门、地域抽取。 2. 用 Search 找相似旧文件。 3. 用 Graph 找依据链、修订链、相关事项和相关部门。 4. 归纳输出“影响对象清单 + 调整建议”。 ### 建议优先级 - P1，在收文分办和审稿校验稳定后推进。 --- ## 7. 后续扩展场景 ## 7.1 P2-1 督办执行监测助手 ### 适用对象 - 督查室 - 办公室 - 专项工作专班 ### 价值 - 发现“有文件、无执行反馈” - 发现“有部署、无责任归口” - 发现“地区执行口径不一致” ### 主要前提 - 需要补执行反馈、进度状态、责任清单等数据源。 - 当前图谱与检索底座不够，需要再接业务过程数据。 ### 优先级判断 - 有价值，但不属于最容易落地的首批场景。 --- ## 7.2 P2-2 主题地图与专题追踪 ### 适用对象 - 研究室 - 综合分析岗 - 专题工作专班 ### 价值 - 长周期观察某个主题下的发文、修订、执行脉络 - 对专题研究和年度梳理有帮助 ### 主要前提 - 需要更稳定的主题聚合和专题页设计。 - 需要解决主题命名、主题归并、时间维度展示问题。 ### 优先级判断 - 应放在当前高频助手场景之后。 --- ## 7.3 P2-3 治理分析与风险洞察 ### 适用对象 - 管理层 - 综合分析岗 - 政策研究岗 ### 价值 - 看政策覆盖率 - 看失效文件分布 - 看依据链断点 - 看部门与地域间执行差异 ### 主要前提 - 需要稳定的分析指标口径。 - 需要独立的统计接口和分析页。 - 需要避免做成“只好看不好用”的大屏。 ### 优先级判断 - 价值高，但落地难度和指标治理成本更高，建议后置。 --- ## 7.4 P3-1 条款级合规审查与证据回链 ### 适用对象 - 法规岗 - 合规审查岗 - 审稿把关岗 ### 价值 - 回答“依据哪一条” - 回答“哪条规定了这个要求” - 支持条款级审查与引用回链 ### 主要前提 - 必须等 Phase 2 条款图完成。 - 需要条款级 Article 节点和条款级关系稳定可用。 ### 优先级判断 - 这是后续增强方向，不应提前挤占当前高频助手场景排期。 --- ## 8. 推荐实施顺序 ### 8.1 第一批：高频且最容易落地 1. 收文分办助手 2. 审稿与引用校验助手 3. 事项预审助手 4. 咨询答复助手 建议原因： - 都是日常高频动作。 - 都能复用当前能力。 - 都可以先做“辅助建议 / 校验”而不是“自动决策”。 - 都容易通过试点快速验证价值。 ### 8.2 第二批：效率提升与辅助决策 1. 一页式政策简报助手 2. 新政影响排查助手 建议原因： - 对研究和管理层价值高。 - 但需要更稳定的中间层编排和模板设计。 - 适合在 P0 场景稳定后再推进。 ### 8.3 第三批：平台型和分析型能力 1. 督办执行监测 2. 主题地图与专题追踪 3. 治理分析与风险洞察 4. 条款级合规审查 建议原因： - 需要更多数据源、稳定指标或条款图底座。 - 不适合作为当前阶段的优先投入方向。 --- ## 9. 交付建议 ### 9.1 近期可直接启动的 MVP 包 建议拆成两个小包推进： #### MVP 包 A：工作流助手 - 收文分办助手 - 审稿与引用校验助手 共同特点： - 目标用户清晰 - 高频 - 易量化 - 技术上主要是 Search + Graph + 文档治理链编排 #### MVP 包 B：服务答复助手 - 事项预审助手 - 咨询答复助手 共同特点： - 适合复用 Matter + QA + Research - 对窗口、热线、审批支持明显 - 易形成对外可见的提效效果 ### 9.2 推荐验收方式 每个场景都按同一套方式验收： 1. 有独立入口页或模式入口。 2. 能输出结构化结果，而不只是聊天文本。 3. 结果必须附带引用依据或证据列表。 4. 失败时可回退到 Search / QA / Research 主链路。 5. 有可量化指标，例如耗时、命中率、补件率、引用错误率。 --- ## 10. 最终建议 如果当前要选“最值得做、最容易落地、最可能被高频使用”的方向，建议按以下顺序推进： 1. 收文分办助手 2. 审稿与引用校验助手 3. 事项预审助手 4. 咨询答复助手 这四个场景最符合当前项目的能力边界： - 不依赖条款图 - 不要求全新 schema - 不会破坏现有主链路 - 可以复用已有检索、图谱、事项、QA、Research 能力 - 可以先以“辅助建议”和“校验提醒”形式落地 后续扩展建议依次推进： 1. 一页式政策简报 2. 新政影响排查 3. 督办执行监测 4. 主题地图与治理分析 5. 条款级合规审查 这条路线更符合当前系统阶段：先把高频工作流做成真正会被天天用的助手，再逐步扩展到专题研究、管理分析和更细粒度的证据定位。 --- ## 11. 相关专题规划 围绕 Research 对标 ChatGPT Deep Research 的改造方案，另见： - [research-deep-research-alignment.md](prd/research-deep-research-alignment.md)