四、减少串行模型调用

很多大模型应用的延迟并不来自单次模型调用，而是来自多个模型调用串行执行。比如一个请求需要先调用模型判断意图，再调用模型改写 Query，再调用模型判断是否检索，最后再调用模型生成回答。如果这些步骤全部串行执行，整体等待时间会被不断放大。 优化思路是：能合并的步骤尽量合并，能并行的步骤尽量并行，能用程序逻辑完成的步骤不要交给模型。 ​ 1. 合并相近任务 在知识库问答、智能客服等场景中，用户的表达方式往往是不固定的。例如，下面几种问法本质上可能都在询问同一个问题： - 企业版在哪里看每个人的用量明细？ - 团队成员各自用了多少 token，在哪里查？ - 管理员能不能看到每个成员的调用量？ 如果系统要处理这类问题，通常需要先完成几件事：判断用户意图、判断是否需要检索知识库、把用户问题改写成更适合检索的关键词。 一种比较低效的方式是把这几个步骤拆成多次模型调用： 第一次模型调用：判断用户意图 第二次模型调用：判断是否需要检索知识库 第三次模型调用：改写检索 Query 但这三个任务都依赖同一句用户输入，而且输出结果都比较简单，因此可以合并到一次模型调用中完成。 开发者可以提前定义好输出字段和可选意图类型，例如： 请根据用户问题输出 JSON： - intent：用户意图，只能从 usage_detail_query、billing_query、technical_issue、other 中选择 - need_search：是否需要检索知识库 - search_query：如果需要检索，请生成适合知识库检索的关键词；如果不需要，则为空字符串 当用户输入： 企业版在哪里看每个人的用量明细？ 模型可以一次性输出： { "intent": "usage_detail_query", "need_search": true, "search_query": "企业版 成员 用量明细 查看方式" } 其中， intent 是模型从开发者预设的意图类型中选择出来的结果； need_search 是模型根据规则判断是否需要检索知识库； search_query 是模型对用户问题进行改写后生成的检索关键词。