项目中的性能问题是如何发现、定位并推动解决的？

对“多门店、多指标查询很慢”这类反馈，我会先保留问题、时间范围和请求标识，按关键词抽取、三路召回、元数据合并、模型生成与数据库执行分段计时，区分复杂问题本来就多做了工作，还是同类请求出现了异常等待。

我负责指标与上下文适配，重点检查合并节点补字段、补主外键时的数据库往返。三路召回本来就并行，因此继续检查并行之后的合并节点。只有记录显示逐项元数据查询占据慢路径，才把缺失字段和候选表先收集去重，增加批量查询接口，并保持原来需要的指标依赖与连接字段。

推进时，我会把同一请求的查询次数、等待时间和合并前后资料交给数据接入同事，共同核对批量接口；如果慢的是最终经营 SQL，则带 SQL、参数和执行计划找数据库负责人。改完用相同数据、问题与负载复测，既看完整结果耗时，也对照人工 SQL 检查退款口径、跨表关系和门店范围，确认没有用少查资料换速度。

对“单人查手册还可以，多人同时提问就变慢”的情况，我会先比较相同故障问题在不同并发下的表现，再把设备匹配、各检索通道、融合、重排和生成串成一条时间线。通道任务从提交到开始执行的排队时间，要与真正查询的时间分开。

我负责设备与手册匹配及检索适配。以重排服务排队为排查场景，我会提供相同问题、候选数量与文本长度，和模型服务负责人一起核对服务端排队及执行时间，再比较受控并发与容量调整。先保留候选和模型条件，才能判断等待是否因资源不足而产生；直接缩小候选池，只能算待验证的质量取舍。

推进不止是提交一条“检索慢”的工单。我会附上慢请求、正常请求、负载条件和预期复测项，明确业务侧补计时、检索侧查队列、模型侧查重排服务。优化前后按同一请求比例复测首段有效回答和完整回答的耗时、超时率及正确证据召回，确认旧版手册没有混入，也没有因大量丢弃通道结果而显得更快。

对“研究任务一直有进度，报告却迟迟不出来”的反馈，我会以一次完整研究任务为单位，记录主智能体委派、来源工具请求、助手返回、证据整理、报告生成和文件导出的时间。先判断时间花在搜集、交接还是生成，不把 WebSocket 推送成功当成任务已经变快。

我负责来源产物到报告之间的证据组织。针对同一企业、同一事实被反复搜集的情况，会把子问题、工具参数和已取得材料关联起来，检查后续调用是在补缺口，还是重复同一次查询。确认重复后，在任务内按实体、事件、时间范围与来源条件复用已核对的材料，把后续任务收敛到尚缺的证据；需要独立核实的来源继续保留。

推进时，把重复调用样例交给助手编排负责人，把单次工具慢请求交给对应来源服务负责人，分别验证任务拆分和工具适配。复测固定题目、材料快照、模型与调用预算，比较完整报告交付时间和调用次数，同时检查关键子问题、独立来源、冲突与引用。调用少了但漏掉关键证据，就不能算优化成功。

对“批量更新手册时问答变慢”的情况，我会先把外部业务服务和 RAGFlow 分开测：设备匹配耗时、检索请求往返、返回片段核对、生成首段内容及完整答复各占多少。平台检索的整体耗时升高，只能说明要继续查平台侧，不能直接认定是向量库或模型慢。

我负责外部 Python 适配服务，会带着设备输入、允许文档、检索参数、慢请求时间和导入批次找平台维护者，对照检索服务与后台解析、Embedding 和索引写入的资源使用。只有确认共享资源竞争，才比较调整导入并发、安排导入窗口或分配独立资源；生成慢则用相同片段与模型输入另查生成服务。

复测保持问答负载和导入压力一致，分别看检索耗时、完整答复耗时、失败率及新手册可检索所需时间。不能靠暂停所有资料更新来掩盖吞吐损失，也不能为了更快返回而丢掉适用手册或无证据处理。改动要同时满足查询质量和业务约定的资料更新时效。