你认为项目的技术亮点是什么？

核心回答示例

这个方案的技术亮点，是把经营指标的业务口径落到 SQL 生成所需的上下文里。例如“本月净销售额”，本例按本期实收减本期实际退款计算，退款看实际发生时间；它和“本月成交订单最终还剩多少钱”是两个问题。

我负责门店指标与上下文适配的设计，把指标定义、别名和依赖字段接入电商问数底座。底座已经会合并字段、指标和取值，我要解决的是：净销售额需要的退款金额、退款日期等信息，能否随指标一起进入模型输入，而不是只召回一个相似的指标名。

选择这条路线，是为了让业务定义能集中维护、沿请求检查。代价是要维护元数据，检索漏掉指标也可能影响结果。验证时用跨月退款、部分退款和门店别名等问题，对照人工 SQL 和结果，分别检查口径有没有进入上下文、最终有没有算对。SQL 能执行只是其中一项检查。

亮点具体落在哪一步

可以用一个假设数据样本讲清差别：十月实收 1000 元，十月退还九月订单款 200 元，另有十月订单在十一月退款。本例的十月净销售额应为 800 元；十一月发生的退款不扣在十月。若把订单的最终退款额直接汇总到订单月份，就改变了业务口径。

这会影响指标说明、依赖字段和日期条件，不能仅靠给“净销售额”增加几个同义词解决。拟议适配需要将这些定义写进指标资料，列出所需的实收金额、退款金额及各自时间字段，并映射到真实表字段。已有合并节点会根据指标的依赖字段补信息，再按表组织成上下文；这段通用能力可以复用。业务适配的检查点是定义和映射是否正确，以及经过后续筛选后，必要条件是否仍在 SQL 生成输入中。

因此，我会保留同一次请求中的指标定义、召回结果、合并与筛选后的资料、SQL 和对照结果。若 SQL 使用了订单日期筛退款，就能继续判断是定义没写清、依赖没配全，还是生成时没有遵循已有条件。允许查询哪些门店，另由业务身份和执行层限制，不能把模型生成了门店条件当作范围控制已经落实。

为什么不用固定 SQL 或一段总提示词

如果只提供几个固定经营报表，参数化 SQL 更直接，也更容易控制口径。这里选择元数据适配，是希望支持指标和条件的灵活组合，同时让名称、定义和依赖有明确维护位置。

把所有规则放进总提示词，也可以作为小规模基线；但指标和表不断增加后，每次都要携带大量无关信息，修改口径也容易漏掉其他提示词。按问题召回资料减少了这类输入，同时引入漏召回的风险。比较两种方案时，应使用相同的问题、模型和数据，对照必要指标及字段的覆盖、计算结果和输入长度；不能只凭提示词缩短就判断更好。

面试官继续问时

“结果和人工 SQL 不一样，是模型问题还是指标适配问题？”

先比较两边是否使用同一口径、同一数据快照和日期范围，再沿请求找首次分歧。若指标定义中就没区分退款日期，应修业务适配；若依赖字段齐全但筛选后丢失，应查上下文处理；若输入已明确但 SQL 仍选错日期，再查生成。SQL 文本不同也可能算出等价结果，判定重点是业务条件与结果。

“怎样证明这项设计值得保留？”

准备容易混淆口径的固定问题，比较通用字段说明与增加指标适配后的表现。除了统计结果是否正确，还要检查适配是否带来错误指标、无关字段或新的漏召回。对于口径仍不明确的问题，能够提出具体补问也是合理结果，不能一律按必须生成 SQL 来验收。

核心回答示例

我认为最值得讲的技术亮点，是让设备适用范围贯穿整条检索链。售后问答中，两种设备可能报同一个故障，但维修步骤并不通用，语义相似度高不代表资料适用。

我负责设备与手册匹配及检索适配的设计。根据型号、硬件或固件版本和手册生效范围，确定允许文档，再接入 Ragent 的各召回通道。底座的主路、补充检索和融合重排可以复用；业务上要保证补充路和全局回退也遵守同一份允许范围，不能主路过滤完，又从其他地方补回不适用的手册。

这个选择增加了设备资料映射和通道适配的工作，但能把“资料适用”与“内容相关”分别检查。验证时保持故障描述不变，替换型号或版本，逐路核对候选、生成上下文和最终引用；还要检查本来有适用证据的问题是否仍能回答，避免只靠拒答把错误资料挡住。

为什么范围需要在召回时生效

Ragent 当前的检索作用域按知识库意图决定定向或全局检索，定向时还会从未命中的库补充候选。这解决的是通用问答的检索范围选择，设备适用性需要另一组业务规则。

拟议实现先将设备别名归一，取得会影响处理步骤的版本条件，再得到允许手册集合。各实际召回通道使用的范围，应与这份集合取交集；无法直接表达文档级条件的入口，需要继续适配，不能只把集合存进请求对象。生成前再核对候选来源及版本，作为补充检查。

例如设备 A 和 B 都报“启动后报警”，A 手册的步骤需要检查一个部件，B 手册却明确采用另一种处理方式。相关性排序可能更偏向文字更相似的 A 手册。如果用户设备是 B，A 手册就应先被适用规则排除，不能指望重排模型自行理解全部兼容关系。

设备信息缺失时，匹配模块返回具体补问项；不同资料对版本适用范围存在冲突时，保留冲突原因；没有适用资料时返回缺口。这些分支与正常检索一起构成业务行为，不能都退化成“没搜到”。

与只在回答后删引用相比，有什么取舍

后置过滤接入较快，但不适用片段可能已经进入候选预算、重排或生成上下文。删掉最终引用，无法保证生成内容没受它影响；相关候选名额也可能被错误型号占据。召回时限定范围，可以更早约束候选，但需要确认每条启用通道实际消费了限制，并维护资料更新后的映射关系。

如果设备系列很少，按系列分知识库也可以作为简单方案。随着共享手册和兼容版本增多，单纯分库可能带来重复维护，仍需要明确哪份资料适用于哪台设备。是否采用细粒度文档限制，要结合资料组织方式和维护成本判断。

面试官继续问时

“请求里已经有过滤字段，为什么还要逐路检查？”

字段存在只说明能表达条件，不说明下游已经使用它。当前固定版本的请求类声明了 metadataFilters 扩展项，但不能据此认定设备过滤已经生效。需要追到实际通道、检索请求和返回文档，验证每条启用路径；新增通道或回退路径也应加入同样的用例。

“过滤太严，资料明明能用却被排除了怎么办？”

先分清是设备档案缺信息、兼容映射不全，还是范围内的相关证据没有召回。共享手册应通过明确的兼容规则加入允许集合；不能为了答出内容就临时放开全部手册。验证要同时覆盖不适用资料混入和适用资料被排除，两类错误分别记录，才能比较规则调整的收益与代价。

核心回答示例

最值得展开的是来源与结论之间的证据组织。产业研究里，五个网址可能转载同一条消息；“发布样机”和“已经交付”也可能写在同一个产品的不同材料中。只汇总搜索结果，容易把转载当成多份佐证，或者把不同阶段合成一个结论。

我负责来源适配与证据组织的设计：先让工具交出来源内容、原文位置和日期，再统一企业与产品名称，区分事件和事实时间，将支持或冲突的材料关联到结论与报告段落。深度研搜已有的任务拆分、来源助手和报告导出继续复用。尤其是当前知识库工具只返回回答文本，要做证据关联，还需要扩展来源输出，不能从一段摘要反推原文。

这会增加来源处理和关联维护的成本，适合需要回看依据、持续更新的研究初稿。验证时加入转载、时间不同和相互冲突的材料，检查结论是否仍有原文支持；替换一份关键材料后，再看能否定位需要复核的正文和摘要。

从一条产品进展结论展开

假设材料甲说“五月发布样机”，材料乙说“计划七月交付”，八月的一篇转载又重复了甲的消息。三份材料涉及同一产品，但不能得出“八月已有多方证实完成交付”。这里至少要区分产品实体、事件类型、材料发布日期、事实发生或计划时间，以及转载所依据的原始消息。

拟议来源记录保留原始企业或产品称呼及归一后的实体，避免同名企业误合并；同时保留 URL 或文件位置、可定位的原文、发布日期与事实时间。转载归到同一来源线索，用于识别它们共同依赖哪条消息，不因网址变多就增加独立佐证。对一个结论，记录哪些原文支持、哪些冲突、哪些关键条件仍缺失，再关联报告使用它的段落。

工具的输出是这项设计的前提。现有 create_ask_delete 从 RAGFlow 流式响应中取出并拼接 answer，返回的是回答文本。要取得可核对的原文位置，可以扩展工具保留经核验的结构化来源，或另接能返回文档与片段的检索接口；具体接口和定位质量需要分别验证。不能只给返回字符串加几个字段名，就认为来源已经齐全。

为什么不直接让主智能体汇总全部材料

一次性汇总适合资料少、只交付一次的任务，实现也更简单。这里选择显式保存证据与结论关系，是因为研究人员还需要回答“这句话依据哪份材料”“新消息影响哪些段落”。没有关系记录时，新增材料往往只能重新通读或整篇重写。

这条路线也有成本：实体归一可能错，转载识别可能把独立采访误合并，结论拆得太细又会增加维护负担。因此可以先围绕产品发布、交付等关键事实建立关联，逐项核对。材料更新后先标记受影响结论和段落待复核；自动局部重写、摘要同步和研究人员确认，还需要分别实现和验收。

面试官继续问时

“同一时间的两份材料冲突，怎么选？”

先回到原文，检查说的是不是同一实体、事件和统计范围，再比较材料是否直接接近事实来源。如果条件相同仍有分歧，就在结论中保留分歧和各自依据，继续寻找能消除冲突的材料。转载数量不能作为投票，更晚发布也不自动代表事实更新。

“怎样验收材料更新的影响定位？”

固定一份报告和材料快照，人工先标出被替换材料支持的结论，以及正文、摘要等使用位置，再和系统标记比较。同时放入一份与已有结论无关的新材料，检查是否过度标记。能找到受影响位置，是这一阶段的判据；报告已经正确重写，是下一阶段要另查的结果。

核心回答示例

这条路线的亮点在外部设备资料适配：把设备型号与版本映射成适用手册，再转换为平台知识库和文档范围，让业务规则真正进入检索请求。

RAGFlow 负责文档入库、切分、索引和片段检索；我负责外部 Python 服务的范围映射、请求分支和响应核对设计。这里特意区分“没有适用手册”和“有手册但没找到故障证据”：前者停在业务服务，不请求平台；后者保留原范围返回证据缺口。按本例固定版本的实现，没有额外元数据过滤时，传空文档列表会失去文档限制，不能拿它表达“什么都不允许查”。

与直接接平台聊天入口相比，这样更方便按请求控制设备资料范围，但增加了映射维护和答复集成工作。验证时核对映射、实际请求和返回片段：空匹配的平台调用次数应为零，非空时只使用允许且能支持答复的资料。

两种空结果为什么需要不同处理

本例基于 RAGFlow v0.27.2 的片段检索接口。适配服务维护“设备型号与版本—适用手册—平台知识库及文档”的对应关系，匹配到非空文档后，才构造 dataset_ids 和 document_ids 请求。响应返回后，再核对来源文档是否在允许集合中、版本是否适用、片段是否支持当前故障问题，随后交给生成环节。

如果设备根本没有适用手册，问题发生在业务资料匹配阶段，服务应返回缺口，平台调用次数为零。这个分支不能省略：该版本在没有额外元数据过滤、文档列表为空时，会将文档条件转成 None，检索仍受知识库范围约束，却不再按这份文档集合限制。若同库存在其他型号的高相似手册，就可能搜出不适用内容。

另一种情况是匹配到正确手册，但没有检索到故障证据。此时要保留原来的适用范围，继续判断是资料没有覆盖、切分或召回漏掉证据，还是阈值等配置影响；不能自动扩大到其他型号。型号缺失与版本冲突也分别返回补问项或冲突原因，便于售后人员采取下一步动作。

为什么选择平台外的适配服务

设备规则来自业务档案和手册生效关系，放在独立服务中，便于与资料管理、设备查询和答复接口一起维护。平台现有的解析、索引和检索直接复用，这项设计不要求重写平台核心。

如果只服务少量固定设备，也可以按设备系列和兼容版本组织知识库，再绑定平台聊天入口，减少外部答复集成。不过，共享手册可能被重复组织，更新时需要维护多处关系；平台聊天入口也有自己的绑定和检索约束，不能直接照搬片段检索接口的参数。本例选择外部代理，是为了明确掌握每次请求的文档范围，同时承担这部分映射和维护成本。

面试官继续问时

“请求已经限制文档，为什么还检查响应？”

请求核对用于确认发出了什么限制，响应核对用于确认实际拿回了什么资料，两者针对不同环节。适配服务需要把平台文档 ID 对回手册及版本，来源不符的片段不进入生成上下文；范围正确但内容不足，也应返回证据缺口。最终引用正确，并不能单独证明中间没有使用错误片段。

“怎样证明空匹配处理没有把本来能回答的问题都挡住？”

用同一故障分别配上有适用手册、缺设备条件、无适用手册和有手册无故障证据四组样本。除了核对无适用手册时没有平台调用，还要检查有适用证据时能够走完受限检索和答复，缺条件时能指出具体补充项。调用少或拒答多都不能单独作为方案有效的依据。