多轮对话里最容易被低估的问题不是模型“不会回答”而是“回答错了还在坚持”。用户先问“北京天气怎么样”模型还在报降水概率用户紧接着补了一句“算了帮我查北京到上海的高铁”如果模型仍然围绕天气做输出那它就已经在 evolving user intent 里迷路了。这个场景在真实业务里非常常见客服机器人、Agent 工具调用、RAG 问答系统只要对话超过三轮用户随时可能切换主题。模型默认会把整个历史都当作上下文旧意图的信息保留越多新意图受到的干扰就越强。最后的表现就是“反应慢半拍”“答非所问”或者“把上一轮的实体强行塞进当前回答”。这篇文章不讨论理论上的“万能方案”而是先拆解问题再给一套可复现的验证流程如何构造用户意图演化对话集如何用 OpenAI 兼容接口或本地 Ollama 模型跑测试如何统计“当前意图命中率”以及工程上可以采用的缓解手段。无论你是在做对话产品还是在调 Agent 工作流都可以把这套方法直接拿去当基线验证。1. 核心能力速览虽然这不是一个可以直接下载的模型仓库但我们可以把它当作一个“LLM 意图跟踪评估与优化方案”来对待。核心对象是“当用户意图在多轮对话中发生变化时模型是否还能跟住最新意图”。能力项说明研究对象LLM 多轮对话中的用户意图演化跟踪核心问题用户中途改变话题或细化需求时模型被旧上下文带偏评估方式构造意图跳变对话集统计模型最终输出是否匹配当前意图可运行环境Python 3.9OpenAI API 或任意 OpenAI 兼容本地服务推荐硬件使用 API 时无 GPU 要求本地模型按模型规格确定显存主要方法上下文裁剪、意图路由、历史摘要重写、动态系统提示词支持批量任务支持可使用 JSONL 对话集批量跑分是否支持 API支持直接调用 Chat Completions 接口适合读者对话系统、Agent、RAG 应用开发者一句话总结这是一个“问题复现 效果评估 工程缓解”的完整验证链路不需要特殊硬件重点是先跑出基线再针对性地做干预。2. 适用场景与使用边界用户意图演化不是少数场景而是大多数交互式 AI 产品的日常。典型情况包括客服机器人用户先咨询退换货政策然后转而问“那运费谁出”最后又说“帮我查一下最近的网点”。Agent 工具调用用户先让助手查天气再让查机票再让对比两个航班的价格。RAG 问答系统用户先问“这篇文档讲了什么”再问“第三章的具体参数”再问“能不能把第三章导出成表格”。多步任务规划用户给出一个初始目标过程中不断追加限制条件或改变优先级。在这些场景里模型的输入历史本身就是一个“干扰源”。如果应用把所有轮次都原样拼进 prompt模型几乎不可避免地会把早期意图的特征保留到最终输出中尤其是用户的省略表达会让问题变得更明显比如用户说“那个呢”“还是不行”“算了换一个”如果不结合上下文根本无法理解但如果结合了旧上下文又容易延续旧主题。边界条件也需要说清楚本文讨论的是意图跟踪不解决所有对话质量问题。模型事实错误、幻觉、安全对齐问题不是这里的重点。意图演化中的个人信息、订单数据、健康信息等敏感内容必须脱敏处理测试和生产都要做合规审查。如果使用真实用户对话数据需要确保获得授权并做匿名化不能直接拿原始记录做实验。3. 为什么 LLM 会在演化用户意图中迷失要解决问题先要理解模型为什么会“跟丢”。抛开具体模型架构原因可以归纳为四点。第一旧意图在上下文中的占比过高。模型生成当前回答时会关注历史上所有的 token。当早期意图的内容很多比如天气段有较长的预报后续“帮我订票”的新意图只有很少的 token模型注意力分布会明显偏向旧意图。它在生成时可能继续谈论天气或者把“北京”这个实体用在错误的地方。第二用户省略表达依赖旧上下文。真实用户不会每次都完整说明新意图。他们会说“那上海呢”这种省略句模型需要结合前文才能补全问题。问题在于省略句往往与多个历史意图都相关模型缺少显式的“当前用户目标”状态就只能猜。猜对了是运气猜错了就是灾难。第三系统提示词没有显式声明“意图可以改变”。很多 prompt 只告诉模型“你是助手”没有告诉它“如果用户切换话题你应该优先跟随最新意图”。模型在训练时学习到的模式是“对话要连贯”所以它倾向于延续上一轮主题而不是主动识别转折。第四工具调用和 RAG 检索会放大错误。如果模型在意图切换前已经检索了旧意图相关的资料这些资料会被塞进上下文。等用户切换意图后这些检索结果还在模型在生成时既看到了旧资料又看到了新问题结果就是新旧内容混杂。从工程角度看这不是单纯换一个大参数模型就能解决的问题。模型能力越强对意图转折的容忍度越高但只要 prompt 中继续堆叠全部历史任何模型都可能在长对话中发生漂移。最稳妥的做法是在模型之外加一层“意图状态管理”。4. 复现实验设计构造意图演化对话集与其争论模型会不会跟丢不如直接构造一组对话来测试。建议先定义一个小型意图集合比如weather天气查询train_ticket火车票查询hotel酒店预订restaurant餐厅推荐flight机票查询每个测试用例由若干轮 user/assistant 消息组成并且至少在中间发生一次意图切换。为了贴近真实情况用户消息要包含省略表达、修正表达和全量表达三种类型。下面是一个 JSON 格式的测试数据示例{ conv_id: case_001, description: 天气转火车票带地点切换, turns: [ { role: user, content: 北京明天天气怎么样, intent: weather }, { role: assistant, content: 北京明天晴12到20度西北风3级。, intent: weather }, { role: user, content: 那上海呢, intent: weather, note: 地点跳变 }, { role: user, content: 算了不查天气了帮我订一张明天北京到上海的高铁票。, intent: train_ticket, note: 意图切换 } ], expected_final_intent: train_ticket, expected_entities: { from: 北京, to: 上海, date: 明天 } }这里的关键是最后两轮用户先问“那上海呢”紧接着就说“算了不查天气了”。模型需要识别出“上海”这个实体和“高铁票”这个新意图之间的关系而不是继续输出上海天气。建议准备 20 到 50 个这样的用例覆盖以下变体同一领域内实体切换地理位置、日期、价格区间变化。跨领域意图切换天气转交通、交通转酒店、酒店转餐厅。多轮后才切换前 5 轮都是同一意图第 6 轮突然换主题。意图修正用户先说“推荐个火锅”然后说“算了还是吃日料吧”。二义性省略“那个呢”在不同上下文中可能指代不同实体。数据准备完成后就可以开始跑模型了。5. 环境准备与实验数据设计这个实验不依赖特殊硬件。最省事的方式是直接调用 OpenAI 兼容的 API如果想本地验证可以安装 Ollama拉取一个 7B 或更小的对话模型通过http://127.0.0.1:11434/v1暴露 OpenAI 兼容接口。推荐环境如下依赖项用途版本建议Python编写实验脚本3.9requests调用 HTTP 接口最新稳定版即可openai官方 SDK可选1.xOllama本地模型推理最新版json / csv保存测试数据与结果Python 标准库不需要 GPU 也能跑但使用本地模型时建议准备一块至少能运行对应模型显存大小的显卡具体占用以实际模型规格为准。测试数据单独放一个目录建议结构如下intent-eval/ ├── data/ │ ├── cases.json │ └── cases.jsonl ├── scripts/ │ ├── run_eval.py │ └── intent_router.py └── results/ └── output.csvJSON 适合人工阅读JSONL 适合批量逐行读取。后面批量测试脚本会使用 JSONL。6. 模型调用测试从 API 到本地部署先用最简单的脚本把单个测试用例跑通。下面使用requests直接调用 OpenAI 兼容接口这样无论是 OpenAI 官方 API 还是 Ollama、vLLM、LM Studio只要接口兼容都能用。import json import requests import time def chat_completion(messages, base_url, model, api_keyEMPTY): url f{base_url}/chat/completions payload { model: model, messages: messages, temperature: 0.2 } headers { Authorization: fBearer {api_key}, Content-Type: application/json } resp requests.post(url, jsonpayload, headersheaders, timeout120) resp.raise_for_status() data resp.json() return data[choices][0][message][content] if __name__ __main__: messages [ {role: user, content: 北京明天天气怎么样}, {role: assistant, content: 北京明天晴12到20度。}, {role: user, content: 那上海呢}, {role: user, content: 算了不查天气了帮我订一张明天北京到上海的高铁票。} ] result chat_completion( messages, base_urlhttps://api.openai.com/v1, modelgpt-4o-mini, api_keyyour-api-key ) print(result)如果使用本地 Ollama启动服务后把base_url改为http://127.0.0.1:11434/v1model改为本地模型名例如qwen2.5:7b。API Key 随便填一个非空字符串即可。这个脚本可以直接观察模型是否理解“最后意图是订高铁票”。你会看到不同模型的表现差异非常大有的模型能在最后一句直接给出查票建议有的模型还在继续报上海天气也有的模型会混淆“北京到上海的高铁票”和“上海天气”生成类似“上海明天有雨建议改乘高铁”这种混合输出。不需要把所有历史都塞给模型。更贴近生产的做法是只保留最近 N 轮。你可以实验 N1、N3、N全部三种配置对比最终意图命中率。7. 意图跟踪效果如何验证光看单条输出不够需要量化评估。最直接的方式是给模型设置一个“最终任务”在每一轮结束后让模型输出当前用户意图标签和关键实体。如果模型能连续输出正确标签说明它没有被旧意图带偏。评估脚本核心逻辑如下加载 JSONL 测试数据。逐个用例按轮次发送消息。在最后一轮要求模型以 JSON 格式输出当前意图。将模型输出的意图与expected_final_intent对比。统计准确率。示例代码如下import json import csv import requests def load_cases(path): cases [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if line: cases.append(json.loads(line)) return cases def eval_final_intent(case, call_fn): messages [] for turn in case[turns]: messages.append({role: turn[role], content: turn[content]}) messages.append({ role: user, content: ( 请根据以上对话判断用户当前最后想要完成的意图。 可选意图weather, train_ticket, hotel, restaurant, flight。 只输出 JSON格式{\intent\: \...\} ) }) raw call_fn(messages) try: parsed json.loads(raw) return parsed.get(intent) except Exception: # 模型输出可能包含多余文本尝试提取花括号部分 start raw.find({) end raw.rfind(}) 1 if start ! -1 and end start: parsed json.loads(raw[start:end]) return parsed.get(intent) return parse_error def main(): cases load_cases(data/cases.jsonl) def call_fn(messages): # 替换为实际调用函数 return chat_completion( messages, base_urlhttps://api.openai.com/v1, modelgpt-4o-mini, api_keyyour-api-key ) with open(results/output.csv, w, newline, encodingutf-8) as f: writer csv.writer(f) writer.writerow([conv_id, expected, predicted, hit]) hit 0 for case in cases: pred eval_final_intent(case, call_fn) exp case.get(expected_final_intent) ok 1 if pred exp else 0 hit ok writer.writerow([case[conv_id], exp, pred, ok]) print(case[conv_id], exp, pred) total len(cases) print(fFinal Intent Accuracy: {hit / total:.2%}) if __name__ __main__: main()这就是一套可运行的基线测试。不要小看这个指标很多对话系统在 20 条意图跳变用例上的准确率会远低于单轮分类准确率。原因不是模型分类能力弱而是上下文中的旧意图干扰太强。除了自动评估还可以加一个“判官模型”对输出质量打分。比如要求判官判断“模型是否在最后一步正确执行了新意图”。判官模型用更大参数的模型或更稳定的 API 模型人工抽检结果可以给出更细的质量分。但最基础的第一步还是统计final intent accuracy。8. 缓解“意图迷失”的工程方案如果基线测试发现问题不要急着换大模型先尝试下面四类工程干预。它们可以叠加使用而且成本远低于换模型。8.1 添加意图路由层在用户输入进入主模型前先用一个轻量模型或规则分类器识别当前意图并输出一个“意图标签”。这个标签可以插入到系统提示词中让主模型明确知道当前用户目标发生了变化。def route_intent(user_message: str, history_intent: str) - str: # 这里可以接一个小模型也可以写规则 # 示例规则检测到“算了、不查、换、订、买”等词时切换意图 keywords [订, 买, 查天气, 餐厅, 酒店] for kw in keywords: if kw in user_message: return current_intent_changed return history_intent更完整的方式是调用一次轻量分类接口{ model: intent-classifier, input: 算了不查天气了帮我订一张明天北京到上海的高铁票。, candidate_intents: [weather, train_ticket, hotel, restaurant, flight] }意图路由输出后注入系统消息例如当前用户意图train_ticket 请只围绕当前意图完成回答不要执行之前的天气查询任务。这一步能让模型更有针对性地忽略旧意图。8.2 动态历史裁剪不需要每次对话都把全部历史塞进模型。当检测到意图跳变时只保留与当前意图相关的轮次。没有历史就没有干扰。实现上可以给每条历史消息打个标签intent、entity、task_status。当新意图出现时丢弃旧意图的正文只保留必要实体信息。例如前面用例中天气部分可以压缩为历史不再执行用户曾经查询过北京、上海的天气目前已取消。 当前任务查询明天北京到上海的高铁票。这样模型就不会在天气信息上分配注意力。8.3 历史摘要重写如果业务要求保留完整上下文比如用户随时可能回到之前的主题那就用“摘要重写”代替“原文拼接”。每一轮结束后让模型把之前的对话压缩成一段摘要包含已确认事实和未完成任务。当用户切换意图时旧内容已经在摘要中被降权。summary_prompt 请把以下对话压缩为简明摘要只保留关键事实、实体和未完成任务。 不要保留天气详情除非它直接影响当前任务。 def summarize(history): # 调用 LLM 生成摘要 ...这是一种成本与效果的折中既保留长期记忆又降低对当前生成的干扰。8.4 动态系统提示词把“用户可以随时改变意图”写进系统提示词并明确输出规范。例如你是任务助手。用户可以随时切换话题或修改需求。 当你发现用户意图发生变化时必须立刻放弃之前的任务以最新意图为准。 在回答前先思考用户当前最后一句话的需求是什么 如果存在歧义可以问一句确认但不要继续执行旧任务。大部分情况下这一步就能明显提升意图跟随能力。原因是模型不是不懂“意图改变”而是没有收到显式指令。9. 接口 API 与批量任务测试生产环境很少只跑一个用例更多场景是批量评估不同模型、不同系统提示词版本。这时建议把测试用例整理成 JSONL按行读取逐条请求并把结果写入 CSV 或数据库。一个简单的批量跑分命令如下python scripts/run_eval.py \ --input data/cases.jsonl \ --output results/output.csv \ --base_url http://127.0.0.1:11434/v1 \ --model qwen2.5:7b \ --api_key EMPTY如果你的 API 服务支持并发可以用ThreadPoolExecutor控制并发数。注意控制并发不要太高否则本地服务可能 OOM 或延迟飙升。from concurrent.futures import ThreadPoolExecutor, as_completed def process_one(case): pred eval_final_intent(case, call_fn) return case[conv_id], pred with ThreadPoolExecutor(max_workers4) as pool: futures [pool.submit(process_one, case) for case in cases] for future in as_completed(futures): conv_id, pred future.result() print(conv_id, pred)批量任务还需要考虑失败重试。网络抖动、超时、限流都可能导致某一条失败。建议对单条请求增加重试机制注意区分“可重试错误”和“不可重试错误”。def request_with_retry(messages, max_retry3): for i in range(max_retry): try: return chat_completion(messages, ...) except requests.exceptions.Timeout: continue except requests.exceptions.HTTPError as e: if e.response.status_code in (429, 500, 503): time.sleep(2 ** i) continue raise return timeout重试时建议使用指数退避第一次重试等 1 秒第二次等 2 秒第三次等 4 秒。10. 资源占用观察与常见排查使用 API 时你主要关注 token 消耗和响应延迟使用本地模型时重点看显存占用、推理速度和 batch 并发。查看显存占用可以配合以下命令nvidia-smiOllama 还支持查看当前加载的模型ollama ps如果显存不足常见表现是模型加载慢或者推理时被换出到内存延迟变得很高。缓解方式包括换更小模型、降低上下文长度、使用量化版本、关闭并发请求。下面是常见问题排查表问题现象可能原因排查方式解决方案模型一直回答旧意图内容历史上下文过长旧意图干扰强对比只保留最近 3 轮的结果添加意图路由、裁剪历史模型在新意图中引用了错误实体用户省略表达被错误补全查看模型中间推理或输出意图标签要求模型先输出意图和实体再生成回答API 请求超时输入历史过长或服务端负载高查看请求耗时和 token 数压缩历史、增加超时时间、失败重试本地模型显存不足模型过大或并发过高运行nvidia-smi观察使用量化模型、降低并发批量任务卡住某条请求无响应检查日志定位未完成条目增加每请求超时并用 CSV 记录已完成项输出意图是parse_error模型没有按 JSON 输出打印原始输出改用更强模型或使用正则提取加了系统提示词效果不明显提示词没有生成具体约束检查实际拼接后的 prompt把“当前用户意图”标签显式写入最后一轮显存和 token 的精确数字不用猜用nvidia-smi或 API 返回的usage字段观察即可。每一次测试都记录上下文长度和显存数据对比不同配置比空想更有效。11. 最佳实践与合规建议把意图跟踪做稳除了算法和 prompt工程上的细节也很重要。先跑小样本再上全量。第一次评估只准备 10 到 20 条用例人工看每一条输出确认评估指令是否被模型理解。不要一上来就批量跑几百条否则测试数据写错时返工成本很高。保留一套最小可运行配置。把“基础 prompt 单轮意图分类 最近 3 轮历史”固定为一个版本之后每改一个变量都跟这个基线对比。这样可以避免同时改了多个因素最后不知道哪个起了作用。模型输出必须做结构化校验。如果模型需要输出意图标签不要直接拿字符串硬比。先尝试json.loads失败后用正则提取再失败则标记为parse_error。同时记录原始输出方便排查。批量任务要支持断点续跑。每次跑完一条就把结果写盘这样即使中断也能从 CSV 中找出未完成的用例而不是从零开始。接口服务要限制访问范围。如果开启了本地 API 服务默认绑定127.0.0.1不要暴露到公网。生产环境还要做鉴权和限流防止被滥用。数据合规不能省。对话数据中如果包含手机号、订单号、地址等个人信息测试前必须脱敏。涉及人脸、声音、肖像、版权素材时必须确认授权。如果模型会处理医疗、金融等敏感指令还要加人工审核环节。不要用意图跟踪功能去绕过模型自身的安全限制。意图路由让模型“更听话”但前提是用户请求本身合规。任何诱导模型生成违法、暴力、侵权内容的尝试都不应该被支持。多轮对话测试时还建议做“同一意图的不同表达”变体。比如“帮我订票”“订一张票”“买张票”虽然意图相同但省略程度不同模型表现可能完全不同。保证测试集覆盖这些变体评估结果才可信。12. 总结与下一步LLM 在 evolving user intent 中迷失不是某一个模型的 bug而是“全量历史输入 缺少意图状态”带来的系统性问题。它的复现门槛很低随便构造几组“先查天气再订票”的对话就能看到它的缓解成本也很低意图路由、历史裁剪、动态系统提示词都能立刻见效。如果你现在正在做对话类应用可以先做三件事构造 20 组意图跳变对话跑一次基线算出当前模型的最终意图命中率。添加一个最简意图路由把“当前用户意图”动态注入系统提示词。再跑一次同样的测试对比命中率变化。这个流程不需要 GPUAPI 也能跑通。最容易踩的坑是测试数据本身没有覆盖省略表达和意图修正导致评估结果虚高。所以写测试用例时一定要包含“那上海呢”这种依赖上下文的省略句以及“算了不查了”这种撤销式表达。后续还可以往两个方向扩展一是把意图跟踪与 Agent 工具调用结合在每一步工具调用前都校验当前意图二是用长上下文模型做历史摘要同时对摘要做意图标签管理。这两条路都能继续提高复杂对话中的稳定性和可用性。先跑基线再谈优化这是最稳妥的路线。