问题出现得很突然，日志倒是留得挺全。用 SubQuestionQueryEngine 做对比类问题，一次提问被拆成 4 个子问题串行检索，前端首字从 1.1 秒涨到 3.6 秒，用户以为服务卡死。
刚开始盯着「子问题数量没有上限，复杂问题会拆出十几个」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。子问题默认串行执行，四次检索加四次生成全部累加。也可能是每个子问题都带完整上下文，token 消耗翻倍。
少数情况下是最后的汇总又调一次大模型，链路总长被拉长。
数一次提问拆出多少子问题
python -c "print(len(['电池','整机','屏幕','配件']))"然后确认引擎支持异步并发执行
python -c "from llama_index.core.query_engine import SubQuestionQueryEngine;print(hasattr(SubQuestionQueryEngine,'aquery'))"给子问题数量设上限
python -c "print(min(4,12))"汇总改成模板拼接，省掉一次模型调用
python -c "print(chr(10).join(['电池 12 个月','整机 24 个月']))"怎么算真的好了，看的是同一批现象。对比类问题的首字延迟回到 1.5 秒以内，子问题数量不超过 4 个，答案覆盖两个对比项且顺序稳定。
这里还有个坑。子问题拆分是为复杂问题准备的，简单事实问题走了只会变慢，入口处先做一次复杂度判定更划算。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。