日志与分析

应用上线后，用户反馈“回答不对”“响应太慢”或“最近消耗变高”时，不应只回到提示词里盲目修改。日志用于查看具体发生了什么，分析用于观察整体趋势。

一、用户反馈某次回答有问题：查日志

日志提供按用户、按会话和按消息三种查看方式。

1.1 已知是哪位用户：按用户查找

按用户页面汇总用户的会话数、消息数、来源渠道、Token 消耗、平均首字响应和平均处理时长。

刚完成调试时，可以先筛选“调试”渠道，再根据时间和用户信息找到目标记录。

1.2 已知是哪次对话：按会话查找

按会话页面显示会话标题、用户、消息数量、Token 消耗、响应时间和创建时间。它适合定位一次完整对话，而不是把同一用户的全部记录混在一起查看。

1.3 已知具体输入：按消息查找

按消息页面可以根据用户输入定位单条请求，并查看 Token 消耗、首字响应、处理时长、开始和结束时间。需要继续检查时，点击右侧 详情。

1.4 找到记录后看什么

不要只看模型最后一句回复，还要结合完整输入和上下文判断：

• 用户实际输入了什么；
• 变量是否正确传入；
• 前面的对话是否已经提供相关信息；
• 应用是否使用了知识库或工具；
• 是否出现错误；
• 本次处理消耗了多少 Token；
• 响应时间是否异常。

日志中发现的问题	返回哪里处理
任务理解错误	提示词
动态信息没有传入	变量
院内资料回答错误	知识库
外部调用失败	工具配置
模型能力不适合	模型配置
对前文理解不足	记忆配置

二、用户普遍反映响应慢：看响应指标

首字响应表示用户等待多久开始看到回复，平均处理时长表示完成整次处理需要多久。

响应时间明显增加时，可以结合日志检查是否更换模型、增加知识库检索或工具调用，以及提示词和输入内容是否明显变长。不要只根据一条较慢记录判断整体性能，应结合一段时间内的数据趋势。

三、Token 消耗增长：看用量趋势

分析页面提供今日、本周和本月的 Token 消耗、消息数和用户数，以及对应趋势。

Token 消耗增加可能来自使用人数增加、对话次数增加、提示词变长、上下文轮数增加或模型输出变长。先判断是使用规模增长还是单次任务消耗增长，再决定是否需要优化。

四、定位高使用量来源

用量排行 TOP10 可以帮助找到消息数量或 Token 消耗较高的用户。排行本身不代表异常，找到目标用户后还要结合日志确认是否属于正常高频使用、重复请求或任务失败后的反复重试。

五、查看应用稳定性

稳定性区域包含对话错误记录、平均执行速度和首字响应时长。

如果错误记录增加，应返回日志定位具体请求；如果执行速度或首字响应明显变化，应结合模型、知识库、工具和输入长度进一步排查。

六、刚发布新配置：观察变化

修改模型、提示词、知识库或工具并重新发布后，建议重点观察：

• 错误记录是否增加；
• 首字响应是否明显变长；
• 平均处理时长是否变化；
• Token 消耗是否明显增长；
• 用户反馈的问题是否减少。

如果新版本表现变差，应先根据日志找到具体原因，再决定修改哪一项配置，不要同时调整模型、提示词和参数。

七、常见问题从哪里开始查

问题	第一检查位置
某个用户说应用答错了	按用户日志
某次对话中途失败	按会话日志
某条输入出现问题	按消息日志和详情
大量用户无法正常使用	错误记录
用户普遍等待较久	首字响应和平均处理时长
Token 消耗突然增加	用量趋势和用户排行
新配置发布后效果下降	发布后的日志与分析数据

八、什么时候进入平台级观测

应用日志适合定位用户、会话和消息；需要继续判断具体是哪次模型、知识检索或工具调用出错时，进入链路追踪。需要比较一段时间内的调用量、错误量、耗时和 Token 时，进入统计分析。

排查顺序是：先在应用日志中找到目标请求，再通过链路查看执行细节，最后根据统计数据判断它是单次异常还是普遍问题。