ChatGLM3-6B-128K对话日志分析：用户意图长期追踪-深圳市維司達科技有限公司

ChatGLM3-6B-128K对话日志分析：用户意图长期追踪

1. 为什么需要追踪用户意图的长期变化

你有没有遇到过这样的情况：客服团队每天处理成百上千条用户消息，但翻看聊天记录时，总觉得“好像哪里不对劲”，却说不清具体问题出在哪？产品团队开了好几次复盘会，讨论用户反馈，但每次结论都差不多——“用户希望体验更好”“大家觉得功能不够直观”。这些模糊的判断背后，其实藏着大量未被挖掘的线索。

真实场景里，用户的需求从来不是静止的。一个电商App的用户，上个月可能频繁咨询“怎么修改收货地址”，这个月突然集中问起“如何查看跨境订单关税”，下个月又开始大量搜索“退货到海外仓的流程”。这种变化不是随机的，而是业务发展、市场环境、用户认知共同作用的结果。关键在于，我们能否从海量对话中捕捉到这些细微却重要的信号。

ChatGLM3-6B-128K模型的出现，让这件事变得可行。它不像传统模型那样只能看几轮对话就“断片”，而是能一口气消化相当于120页A4纸的完整对话历史。这意味着，我们可以把过去三个月甚至半年的用户对话日志一次性喂给它，让它站在全局视角，帮我们看清用户行为背后的逻辑脉络。这不是简单的关键词统计，而是真正理解用户在不同阶段关心什么、困惑什么、期待什么。

很多团队还在用Excel手工整理高频问题，或者依赖基础的文本聚类工具。这些方法在数据量小、周期短时还能应付，一旦对话日志超过几万条，时间跨度拉长到数月，它们就容易漏掉关键转折点。比如，某个功能上线初期用户普遍表示“找不到入口”，两周后抱怨“操作步骤太多”，一个月后却开始询问“能不能批量处理”。这三个阶段的问题看似不同，实则指向同一个核心痛点——交互路径设计不合理。只有具备长上下文理解能力的模型，才能把散落在不同时段的碎片信息串联起来，还原出完整的用户心路历程。

2. 实战方案：从原始日志到可执行洞察

2.1 数据准备与脱敏处理

拿到原始对话日志，第一件事不是急着跑模型，而是做干净的数据清洗和脱敏。这一步看似枯燥，却直接决定了后续分析的可靠性和合规性。我们不需要原始的手机号、身份证号、具体地址，但需要保留足够的上下文来理解用户意图。

实际操作中，我们采用三级脱敏策略：第一级是硬性规则过滤，用正则表达式匹配并替换所有符合手机号、邮箱、银行卡号格式的字符串；第二级是语义识别脱敏，调用轻量级NER模型识别出“北京朝阳区建国路8号”这类地址表述，统一替换为“[城市][区域][道路]”；第三级是人工校验抽样，随机抽取5%的日志请业务同事快速过一遍，确认脱敏后是否还保留了分析价值。

举个例子，原始日志可能是：“用户张三（138****1234）在2024年3月15日14:23咨询：我在北京朝阳区建国路8号华贸中心下单的订单123456789，显示已发货但物流没更新，能帮我查下吗？”脱敏后变成：“用户[姓名]在[日期][时间]咨询：我在[城市][区域][道路]下单的订单[订单号]，显示已发货但物流没更新，能帮我查下吗？”这样既保护了隐私，又完整保留了“地理位置”“订单状态”“物流异常”这几个关键分析维度。

数据格式也很重要。我们最终整理成标准JSONL文件，每行一条对话记录，包含字段：session_id（会话唯一标识）、timestamp（时间戳）、role（user或assistant）、content（脱敏后的内容）、category（业务分类，如售前、售后、技术等）。这种结构化格式，让后续的批量处理和模型调用变得非常顺畅。

2.2 模型调用与意图建模

部署ChatGLM3-6B-128K，我们选择Ollama作为运行环境，原因很简单：一行命令就能拉起服务，对硬件要求友好，而且API接口和OpenAI完全兼容，现有代码几乎不用改。启动命令就是ollama run EntropyYue/chatglm3，几秒钟后服务就绪。

真正的挑战在于如何设计提示词（prompt），让模型不只是回答问题，而是完成深度分析任务。我们摒弃了“请总结这段对话”的简单指令，转而构建了一个分层分析框架：

首先，让模型对单次会话进行原子级标注，输出格式严格限定为JSON：

{ "primary_intent": "物流查询", "secondary_intent": "加急处理", "sentiment": "焦虑", "urgency_level": 3, "resolution_status": "未解决" }

然后，针对跨时段分析，我们设计了一个“时间切片对比”提示词：“你是一位资深用户体验分析师。请基于以下按时间顺序排列的100条用户对话摘要（每条含时间、意图、情绪、解决状态），分析过去30天内用户关注焦点的变化趋势。重点关注：1）哪些意图类别出现频率显著上升或下降；2）同一意图下，用户情绪和紧急程度是否发生系统性变化；3）未解决问题的分布是否有聚集性特征。请用一段连贯文字描述你的发现，避免使用列表。”

这个设计的关键在于，把抽象的“意图追踪”拆解成模型能精准执行的具体任务。它不依赖模型自己发明概念，而是引导它在我们定义的框架内进行推理。实践下来，模型对意图变化的捕捉准确率远超预期，尤其擅长发现那些人工容易忽略的渐进式转变——比如“退货政策咨询”数量没变，但其中“是否支持无理由退货”的提问比例从15%升至42%，这明确指向用户对退货门槛的认知发生了集体性偏移。

2.3 可视化分析与工具集成

分析结果如果只是一堆JSON或文字报告，很难推动业务落地。我们把它接入了现成的可视化工具链，核心是三个动态看板：

第一个是“意图热力图”，横轴是时间（按周粒度），纵轴是意图类别，每个格子的颜色深浅代表该周该意图的出现频次。当鼠标悬停时，会显示具体数值和环比变化。这个图让我们一眼就看到，“跨境清关咨询”在第四周突然升温，结合运营日志，发现是那周刚好有东南亚大促活动上线。

第二个是“情绪-解决状态散点图”，X轴是情绪强度（1-5分），Y轴是解决状态（0=未解决，1=已解决），每个点代表一次会话。我们特别关注左上角（高情绪+未解决）的密集区域，这些是亟待干预的服务风险点。上周这里聚集了27次会话，全部指向同一个新上线的自助退货功能，用户反复尝试失败后情绪飙升。

第三个是“意图演化路径图”，用有向箭头连接不同意图，线宽代表转化频次。比如从“商品咨询”出发，有粗箭头指向“下单疑问”，细箭头指向“竞品对比”，这说明大部分咨询用户最终会进入购买流程，但有一小部分会转向比价——这部分用户正是精准营销的潜在对象。

这些看板不是静态快照，而是通过API实时对接模型服务。每当新一批日志入库，后台脚本自动触发分析流程，几分钟后看板数据就刷新了。产品团队晨会打开看板，就能直接讨论：“上周‘支付失败’意图的情绪值平均上升了1.2分，但解决率反而降了8%，是不是新接入的某家支付渠道出了问题？”

3. 关键效果：从数据到决策的闭环

3.1 识别出被忽视的用户行为拐点

最让我们意外的发现，来自对“沉默用户”的重新解读。传统上，我们把连续30天没发消息的用户归为“流失”，但用ChatGLM3-6B-128K分析他们的最后几次对话，发现了截然不同的模式。

模型从237位“沉默用户”的历史对话中，识别出三类典型轨迹：第一类是“问题解决型”，他们在最后一次对话中明确表达了“好的，明白了，谢谢”，且之前的问题都得到了及时响应，这类用户大概率是自然休眠，无需过度干预；第二类是“流程卡点型”，他们最后的消息停留在“提交申请后一直没收到确认邮件”，且后续无人跟进，这类用户是典型的被动流失，修复流程就能挽回；第三类最隐蔽，叫“认知升级型”，他们最后的对话是“你们这个功能和XX平台比，哪个更适合中小企业？”，之后便不再出现——模型判断，他们其实在做深度竞品调研，我们的回复没能提供足够有区分度的价值主张。

这个发现直接改变了我们的用户召回策略。过去一刀切地给所有沉默用户发优惠券，现在则分层触达：对第一类用户，发送行业洞察白皮书保持连接；对第二类用户，主动推送问题解决进度；对第三类用户，则定向发送与竞品对比的详细分析报告。试点一个月后，第三类用户的7日回访率提升了3.2倍。

3.2 揭示服务流程中的隐性瓶颈

客服质检通常聚焦于单次对话的规范性，但ChatGLM3-6B-128K帮我们看到了更深层的系统性问题。我们选取了1000个完整会话（从用户首次提问到最终关闭），让模型分析整个服务链条。

结果揭示了一个反直觉的瓶颈：不是响应速度慢，而是“问题界定”环节存在巨大损耗。模型统计显示，平均每个会话需要3.7轮对话才能准确定义用户真实需求，其中2.1轮消耗在客服反复确认基本信息上（“请问您的订单号是多少？”“您能再描述下具体现象吗？”）。更关键的是，模型发现，当用户首次提问包含3个以上具体要素（如“iOS17.5系统、微信8.0.45版本、点击分享按钮后闪退”）时，问题界定轮次直接降到1.2轮，解决效率提升65%。

这个洞察促使我们重构了前端交互：在用户进入客服入口时，增加一个极简的“问题速写”弹窗，预设几个勾选项（系统版本、APP版本、问题现象、发生场景），用户只需点选，生成的摘要就自动附在首条消息里。上线两周后，客服人均处理时长下降了22%，用户满意度NPS提升了11个百分点。

3.3 预测产品迭代的优先级排序

最实用的价值，是把模糊的产品规划变成了数据驱动的决策。我们不再凭经验争论“该先做A功能还是B功能”，而是让模型基于真实对话数据给出建议。

具体做法是：收集过去半年所有提及“A功能”和“B功能”的对话，提取用户原话中的诉求强度（如“必须要有”“希望能有”“要是能……就好了”）、使用场景（个人/企业/开发者）、关联痛点（与哪些现有问题同时出现）。然后，让ChatGLM3-6B-128K对每个功能生成一份《需求成熟度评估》，包含三个维度：紧迫性（近期提及频次增速）、影响面（涉及用户类型广度）、实施杠杆率（解决后能连带缓解多少其他问题）。

上季度的评估结果显示，“多账号协同编辑”功能在企业用户中紧迫性指数飙升，且与“权限管理混乱”“版本覆盖不全”两个高频痛点强相关。而另一个呼声很高的“暗黑模式”，虽然提及总量高，但78%来自个人用户，且极少与其他痛点交叉。最终，我们调整了开发排期，把协同编辑提前了两个迭代周期。上线后首月，企业客户续约率提升了9%，验证了数据预测的有效性。

4. 实践心得与避坑指南

4.1 不要试图让模型替代人的判断

刚开始，我们曾天真地想让模型直接输出“应该做什么”。结果发现，模型给出的建议往往过于理想化，比如“建议立即重构整个用户认证体系”。这听起来很专业，但完全忽略了工程资源、上线节奏和灰度策略等现实约束。

后来我们调整了思路：把模型定位为“超级助理”，它的任务是呈现事实、揭示关联、量化影响，而不是做决策。比如，当发现某类问题解决率持续低于行业均值时，模型的任务是列出所有相关对话片段、统计各环节耗时、对比成功与失败案例的差异点，然后由产品经理结合业务目标、技术债现状和市场窗口期，做出最终判断。这种人机协作模式，既发挥了模型的分析优势，又保留了人的战略定力。

4.2 数据质量永远比模型参数更重要

我们曾以为，只要用上128K上下文的大模型，分析效果就一定好。直到一次失败的尝试：用未经清洗的原始日志直接分析，模型输出大量关于“乱码”“链接失效”“重复提交”的无效结论。根源在于，日志里混杂了大量系统自动生成的错误日志、测试账号的刷屏消息、以及客服内部沟通的备注。

这让我们深刻意识到，再强大的模型也是“垃圾进，垃圾出”。现在，我们建立了严格的数据准入标准：每批日志入库前，必须通过三道过滤——自动化脚本剔除非用户消息、业务规则过滤掉测试流量、人工抽检确认脱敏质量。宁愿少分析10%的数据，也要确保分析的100%是真实用户声音。这个原则带来的回报是，分析报告的业务采纳率从最初的43%提升到了89%。

4.3 从小场景切入，快速验证价值

很多团队一上来就想分析全量日志，结果陷入数据准备、模型调优、结果解读的泥潭，几个月不见成效。我们的建议是，找一个“小而痛”的场景先打样。

比如，我们最初只聚焦“退款失败”这一类问题，只取最近7天的2000条相关日志。目标极其明确：找出导致失败的TOP3技术原因，并估算每种原因影响的用户量。一周内，我们就输出了清晰报告，技术团队当天就定位到一个数据库索引缺失的bug，修复后退款失败率下降了68%。这个立竿见影的效果，迅速赢得了各方信任，后续才逐步扩展到更复杂的分析场景。

这种“小步快跑”的方式，不仅降低了试错成本，更重要的是，它让业务方真切感受到AI不是炫技，而是能解决眼前真问题的工具。当客服主管看到自己团队的痛点被精准定位，当技术负责人拿到可落地的根因分析，他们就成了最坚定的支持者。