1. 日志齐全却定位不到根因问题出在哪很多团队在接入AI能力之后第一反应就是先把日志打全。请求参数、响应内容、耗时、token消耗、调用链路ID能记的都记上。结果真出故障的时候打开日志平台一查满屏都是记录却依然说不清这次故障到底是怎么发生的。这个现象非常普遍我自己在几个项目里都遇到过一开始也以为是日志不够多后来才发现问题根本不在数量上。先把这个场景说清楚。所谓AI调用有日志通常指的是在应用层记录了一次模型调用的输入输出。比如用户问了一句话系统把这句话拼进prompt发给模型模型返回一段文本这段文本被记录下来了。看起来链路是完整的但故障排查时你会发现你看到的只是结果快照而不是过程录像。这两者的差别就像看一张事故现场的照片和看一段行车记录仪视频的区别。为什么会有这个落差核心原因在于AI调用不是一次简单的函数调用它是一条包含多个阶段的流水线。从用户输入进入系统到最终结果返回中间至少经过输入预处理、上下文拼装、检索增强如果有RAG、prompt模板渲染、模型推理、后处理、结果落库。应用层日志往往只覆盖了拼装后的prompt和模型返回的文本而前面那些环节的状态全都没有被记录下来。我见过一个很典型的案例。某团队做智能客服用户反馈答非所问。查日志prompt里确实包含了正确的知识片段模型返回的文本也通顺。单看这条日志完全没问题。但把同一会话的前几轮对话拉出来一看发现上一轮用户问了一个无关问题系统把那个问题的检索结果也塞进了上下文导致这一轮的prompt里混入了干扰信息。这个上下文污染的过程在单条调用日志里是看不出来的。所以第一个要建立的认知是日志记录的是点故障排查需要的是线和面。一条调用日志是一个点一次会话是多条日志连成的线而整个系统的运行状态是面。只盯着点看永远拼不出全貌。那怎么把点变成线和面关键在于补全三类信息。第一类是链路标识让同一次用户请求触发的所有操作能串起来包括预处理、检索、模型调用、后处理。第二类是中间态快照不只是记录最终prompt还要记录prompt是怎么一步步拼出来的每个片段来自哪里。第三类是决策依据比如检索召回了哪些文档、为什么选了这几条、模型调用的参数是什么、有没有触发重试或降级。这三类信息补上之后日志才真正具备排查能力。但这里有个坑要注意不是所有信息都值得记。全量记录中间态会导致日志量爆炸存储成本飙升查询速度变慢。我的经验是默认记录链路标识和关键决策点中间态快照按采样率记录。比如正常请求采样1%异常请求超时、报错、用户负反馈全量记录。这样既控制了成本又保证了故障时能拿到完整现场。还有一个容易被忽略的点时间戳的精度和时钟同步。AI调用链路里各环节可能分布在不同的服务、不同的机器上。如果时间戳只精确到秒或者各机器时钟有偏差你根本没法判断是检索慢导致模型调用被推迟还是模型本身慢。我建议统一用毫秒级时间戳并且确保所有节点走同一个时间源。这个细节看起来小但在排查偶发超时这类问题时往往是决定性的。2. 一次AI故障的完整排查链路应该长什么样上一节说了日志缺什么这一节讲清楚完整的排查链路应该包含哪些环节。我把它拆成五个阶段每个阶段都有明确的输入、输出和记录要求。你可以对照自己的系统看看哪个阶段是缺失的。2.1 阶段一请求入口与身份确认这是链路的起点。用户的一次操作进入系统首先要记录的是谁发起的、什么时候发起的、发起的入口是什么网页、App、API、定时任务。这里的关键是生成一个全局唯一的链路ID后续所有环节都带着这个ID走。很多系统在这里就埋了雷。比如链路ID只在应用层生成但预处理服务是独立部署的它收到请求后自己又生成了一个新ID导致链路断掉。正确的做法是链路ID在入口生成后通过请求头或上下文对象一路透传任何环节都不允许重新生成。注意链路ID的透传要覆盖异步调用和消息队列场景。如果预处理是异步的链路ID必须作为消息体的一部分传过去不能只放在线程本地变量里。2.2 阶段二输入预处理与上下文拼装这个阶段是故障高发区也是最容易被日志遗漏的地方。用户输入往往需要经过清洗、意图识别、实体抽取、多轮对话历史拼接等操作。每一步都可能引入问题。我建议在这个阶段记录三类信息原始输入、每一步处理后的中间结果、最终拼装完成的上下文。特别是多轮对话场景要记录本轮实际使用了哪几轮历史而不是只记录历史对话列表。因为系统可能因为token限制做了截断截断策略本身就是故障排查的关键线索。举个例子。某系统设置了最大上下文长度超出后从最早的历史开始丢弃。某次故障中用户发现AI忘记了前面说过的关键信息。查日志历史对话确实被截断了但截断逻辑是按轮次丢弃而用户的关键信息恰好在被丢弃的那一轮里。如果日志里只记录了截断后剩余的历史你就无法判断截断策略是否合理。只有记录了截断前的完整历史和截断规则才能定位到这个问题。2.3 阶段三检索增强与知识召回如果系统用了RAG检索增强生成这个阶段必须重点记录。核心要记的是查询改写后的实际检索语句、召回的文档ID列表及相似度分数、最终选入prompt的文档片段。这里有个常见误区只记录最终选入的文档不记录召回但被过滤掉的文档。这会导致你无法判断是检索没召回到正确文档还是召回到了但被过滤逻辑误杀了。这两种情况的修复方向完全不同。前者要优化检索模型或索引后者要调整过滤阈值或重排策略。我通常会在日志里加一个字段叫召回决策轨迹记录每个候选文档的分数、是否被选中、被选中的原因比如分数最高、或者满足某个业务规则。这个字段在排查答非所问类问题时特别有用。2.4 阶段四模型调用与推理这是最核心的阶段也是大家日志记得最多的阶段。但记得多不等于记得对。我见过很多系统只记录了请求的prompt和返回的文本却漏掉了几个关键参数模型名称和版本、温度值、最大token数、是否流式返回、调用的API端点。这些参数为什么重要因为模型行为对参数非常敏感。同一个prompt温度从0.1调到0.8输出可能完全不同。如果故障发生时你不知道当时用的温度值就无法复现问题。模型版本同理不同版本的模型在相同输入下表现可能有差异。另外重试和降级必须记录。AI调用经常因为限流、超时触发重试。如果日志里只记录了最终成功的那次调用你就看不到前面失败了几次、失败原因是什么。我建议每次调用尝试都记一条日志用同一个链路ID关联并标记第几次尝试和是否最终成功。2.5 阶段五后处理与结果返回模型返回的原始文本往往需要经过后处理格式化、敏感词过滤、结构化解析、业务规则校验。这个阶段的问题容易被忽视因为大家觉得模型都返回了后面能出什么错。实际上后处理引入的故障一点都不少。比如模型返回了一段JSON后处理解析时因为某个字段缺失抛异常系统降级返回了默认文案。用户看到的是抱歉我暂时无法回答但日志里模型调用是成功的。如果你不记录后处理的输入和输出就会误判为模型没返回有效内容。这个阶段要记录模型原始返回、后处理每一步的操作和结果、最终返回给用户的内容。特别是当后处理做了内容修改时要记录修改前后的差异。3. 日志之外还需要哪些可观测性手段配合光靠日志有些问题是查不清的。日志是离散的事件记录而AI系统的故障往往表现为指标异常或链路性能劣化。这时候需要指标Metrics和链路追踪Tracing来配合。3.1 指标发现问题的第一道防线指标的作用是告诉你出问题了日志的作用是告诉你问题出在哪。两者配合才能既快又准。AI调用场景下我建议至少监控这几类指标指标类别具体指标监控目的调用量总调用次数、按模型/业务线拆分发现流量突增或突降成功率成功调用占比、失败原因分布快速判断是否大面积故障延迟P50/P95/P99耗时、各阶段耗时定位性能瓶颈资源token消耗量、并发数、限流触发次数判断是否触及配额上限质量用户负反馈率、重试率、降级率发现调用成功但结果不对的问题其中质量指标最容易被忽略但恰恰是AI系统特有的。传统接口调用成功就是成功但AI调用成功不代表结果正确。用户点了踩、重新问了一遍、或者直接转人工这些都是质量问题的信号。把这些信号和调用日志关联起来才能发现日志看起来正常但实际有问题的故障。3.2 链路追踪把散落的日志串起来链路追踪的核心价值是可视化。它把一次请求经过的所有服务、所有调用、所有耗时用一张图展示出来。对于AI调用这种多阶段流水线链路追踪能让你一眼看出时间花在哪了。我遇到过一个问题用户反馈AI响应慢。查日志模型调用耗时正常只有几百毫秒。但用户端感知的延迟有好几秒。后来通过链路追踪发现时间花在了预处理阶段的检索上检索服务因为索引重建导致查询变慢。如果只看模型调用日志这个问题永远查不出来。链路追踪的落地要点是每个阶段都要有独立的Span并且Span上要打上关键标签比如模型名称、检索文档数、是否命中缓存。这样在追踪系统里你可以按标签筛选和聚合快速定位异常模式。3.3 会话回放还原用户真实体验日志和追踪都是从系统视角看问题而会话回放是从用户视角看问题。它把同一个用户的一次完整会话多轮对话按时间顺序还原出来包括用户输入、系统响应、中间的关键决策。这个手段在排查多轮对话中的上下文问题时特别有用。因为很多问题不是单次调用能暴露的而是多轮累积的结果。比如前面提到的上下文污染只有把整个会话拉出来看才能发现上一轮的检索结果影响了这一轮。会话回放的实现方式有两种一种是基于日志重建把同一会话ID的所有日志按时间排序展示另一种是前端埋点直接记录用户看到的界面变化。前者成本低但可能缺失信息后者更真实但需要前端配合。我建议两者结合后端日志保证完整性前端埋点保证真实性。4. 排查AI故障时最容易踩的几个坑这一节讲几个我亲身踩过或者见别人踩过的坑。这些坑的共同特点是看起来是小事但排查时能让你多花好几个小时。4.1 坑一把日志有记录等同于日志可排查这是最根本的认知错误。日志有记录只说明你存了东西日志可排查要求存的东西能回答为什么。很多团队的日志字段是开发随手加的没有经过排查场景的验证。结果真出故障时发现关键字段缺失或者字段含义模糊。我的做法是每上线一个新功能先模拟一次故障看日志能不能支撑排查。比如故意让检索返回空结果看日志里能不能看出检索为空这个事实。如果看不出来就补字段。这个习惯能帮你提前发现日志设计的盲区。4.2 坑二日志级别设置不当关键信息被淹没AI调用日志量很大如果全部用INFO级别查询时会被大量正常请求淹没。但如果关键信息用了DEBUG级别生产环境又不输出故障时什么都看不到。我的建议是分级策略入口和出口用INFO中间决策点用INFO但带采样详细中间态用DEBUG且仅异常时开启。具体来说链路ID、模型名称、耗时、成功/失败状态这些用INFO全量记录检索召回的文档列表、prompt拼装的中间片段这些用INFO但只对异常请求或采样请求记录更细的调试信息用DEBUG通过动态日志级别调整在需要时开启。注意动态调整日志级别要谨慎高并发场景下突然开启DEBUG可能导致日志量暴增影响系统稳定性。建议配合限流和采样。4.3 坑三忽略异步和并发场景下的日志顺序AI系统里异步操作很多异步检索、异步后处理、流式返回。这些场景下日志的写入顺序和实际执行顺序可能不一致。如果你按日志时间戳排序来还原执行过程可能会得出错误结论。解决办法是在日志里记录逻辑时序而不仅仅依赖物理时间戳。比如给每个阶段分配一个序号或者记录父操作ID和子操作ID通过父子关系还原调用树。这样即使日志写入有延迟也能正确还原执行顺序。4.4 坑四没有建立正常基线无法判断异常排查故障的前提是知道正常是什么样。如果平时不记录正常请求的指标分布故障时就无法判断当前值是否异常。比如模型调用P99耗时突然从800ms涨到1200ms如果你不知道正常基线是800ms可能就忽略了。我建议对核心指标建立动态基线比如用过去7天的同时段数据计算均值和标准差当前值偏离超过2个标准差就告警。这样不需要人工设定阈值也能适应业务量的自然波动。4.5 坑五排查完不沉淀同样的问题反复查这是最可惜的坑。每次故障排查完定位到了原因修复了问题但没有把排查过程沉淀成文档或自动化检查项。下次遇到类似问题又从头查一遍。我的做法是每次故障后更新两份东西一份是排查手册记录这类问题的排查步骤和关键日志字段另一份是监控规则把这次故障的特征转化成告警规则。比如这次是因为检索召回为空导致答非所问那就加一条监控检索召回数为0时触发告警。这样下次同样问题在发生前就能被发现。5. 从日志到可观测性AI系统需要补的课聊到这里可以做一个阶段性的梳理。AI调用有日志却查不清故障本质上是可观测性建设没有跟上AI系统的复杂度。传统应用的日志体系是为确定性调用设计的而AI调用是概率性流水线两者的排查需求不同。传统应用里一次调用失败日志里通常有明确的错误码和堆栈。排查路径是线性的看错误码、定位代码行、修复。AI系统里一次调用成功但结果不对日志里没有任何错误排查路径是网状的要看输入、看上下文、看检索、看模型参数、看后处理任何一个环节的微小偏差都可能导致最终结果异常。所以AI系统的可观测性建设重点要从记录结果转向记录决策过程。具体来说要补三块第一块是上下文可观测。不只是记录最终prompt还要记录prompt的构造过程每个片段的来源和权重。这样当结果异常时能快速定位是哪个片段引入了问题。第二块是决策可观测。AI系统里有很多隐式决策检索选哪几条、上下文截断到多少、用哪个模型、温度设多少。这些决策平时是代码里的默认值故障时却成了关键变量。要把这些决策显式记录下来并且能按决策维度聚合分析。第三块是质量可观测。传统监控关注是否成功AI系统还要关注是否有效。要建立从用户反馈到调用日志的回流机制把负反馈、重试、转人工这些信号关联到具体的调用记录上形成质量闭环。这三块补上之后日志才真正从记录变成洞察。回到标题的问题AI调用有日志为什么还是查不清一次故障因为日志记录的是发生了什么而排查故障需要的是为什么发生。这两者之间隔着上下文、决策和质量三层信息。把这三层补上日志才能回答为什么。我在实际项目里的体会是可观测性建设不是一次性的工程而是随着系统复杂度增长持续迭代的过程。每次故障都是一次补课的机会把排查过程中发现的信息缺口补上系统的可排查性就会越来越好。最怕的是故障修了就完事日志还是老样子那下次故障还得从头再来。