如何识别简历中容易被深挖的项目表述并准备证据？

我的适配重点是门店业务定义怎样进入 SQL 生成。例如问“华北地区本月净销售额”，先明确按本期实收减本期实际退款计算，退款归到实际发生的月份，再将这个定义对应到金额、日期和门店字段。

指标定义、门店别名和数据映射是业务适配。底座的合并节点已经会对字段去重、补指标依赖、关联取值和补主外键，我会复用这些处理，再查看新增的业务定义有没有进入合并结果和生成输入。若还需要调整合并逻辑，就用改动前后的同一请求说明原来缺了什么、修改后补了什么。

校验通过仍可能选错销售口径，或漏掉门店条件。我会把指标定义、生成 SQL 和人工对照结果放在一起，先看计算与筛选是否一致。底座还有一个执行边界：首次校验失败进入 correct_sql，之后直接到 run_sql，纠错结果没有再次校验。若增加纠错复验，需要另外修改这条连接并验证失败分支。

我增加的是设备适用关系。比如两种设备都报“启动后报警”，相关片段可能很相似，但维修步骤未必通用。模块先统一型号别名、核对版本，再按手册生效范围输出允许检索的文档；缺少会改变处理步骤的条件时，返回具体补问项。

Ragent 的 RetrievalScope 按意图选择全局、定向或补充知识库，并不等于设备文档限制。因此业务范围还要接入每条实际召回通道，包括补充检索，再核对进入生成的片段和最终引用。若现有接口只能限制知识库、不能表达适用文档，就需要扩展对应入口。

这些是底座已有能力。这个案例采用固定知识问答流程，底座另有 AgentScope 的 Agent 链路。我的设计范围是设备匹配及检索适配：让同一故障在不同型号或版本下进入不同的资料范围，并通过候选片段和引用核对范围是否生效。

我的设计放在来源产物与报告生成之间。每条证据保留来源、原文位置、材料日期和事实时间，再关联到结论与报告段落。例如“发布样机”和“开始交付”是不同事实，不能因为都提到同一产品就合并成一个结论；同一消息的多次转载则归为一条来源线索。

新材料到来后，先找它影响的结论，再标记引用这些结论的正文和摘要待复核。标记复核范围、自动改写和研究人员确认是不同步骤，可以分别展示完成程度。

这里还需要补齐来源输出。底座已有主智能体、三个来源助手和文件交付，但当前 RAGFlow 工具只把 answer 文本交回主智能体。要让证据关联回原文，还得扩展工具输出，取得结构化来源和位置，不能从回答摘要反推出处。

实时进度由 WebSocket 推送，报告文件保存在任务目录；执行状态则由 InMemorySaver 保存在进程内。服务重启后文件可能还在，图执行状态却不会因此恢复。若扩展恢复能力，需要另外实现持久化检查点和恢复逻辑，再用中途重启任务验证。

平台提供手册入库、解析切分、索引和检索，我的设计负责设备规则与查询的连接。外部 Python、FastAPI 服务先把型号和版本映射到适用手册，再对应到平台知识库与文档。

本例按 RAGFlow v0.27.2 的片段检索接口设计：业务服务把允许范围放进 dataset_ids 和 document_ids，收到响应后核对来源文档、版本及原文位置，只有适用片段才进入生成。这样用同一故障换一个设备，就能解释请求范围和回答依据为什么随之变化。

我会在业务服务停止请求并返回资料缺口。这个版本在没有额外元数据过滤时，空文档列表会失去文档限制，所以不能用它表达“没有适用文档”。如果已有适用文档、只是没检索到故障证据，就保持原范围检查入库和召回，返回证据缺口。