1. 这不是“加个监控”就能糊弄过去的事为什么大模型系统必须重构可观测性思维你有没有遇到过这样的情况线上跑着一个客服对话机器人用户反馈“回答越来越离谱”但日志里只看到一串成功的200响应或者团队花三个月调优的RAG流程在A/B测试中点击率反而下降了5%而所有指标面板都显示“一切正常”。这不是玄学这是当前LLM应用落地中最普遍、最隐蔽的失效模式——我们还在用微服务时代的那套可观测性Observability工具和思路去诊断一个本质完全不同、行为不可预测、输出非结构化的智能体系统。标题里这个“Observability Evaluation in LLMs and Agentic Systems”说的不是给大模型加几个metrics埋点那么简单它是一场从底层认知开始的范式迁移。核心关键词——可观测性Observability、评估Evaluation、大语言模型LLMs、智能体系统Agentic Systems——每一个词背后都站着一套被颠覆的工程逻辑。传统可观测性关注“系统是否在运行”而LLM系统的可观测性必须回答“系统是否在正确地思考”传统评估聚焦于准确率、F1值这类静态打分而智能体系统的评估必须覆盖目标达成度、推理链鲁棒性、工具调用合理性、甚至人类偏好的对齐程度。这篇文章写给两类人一类是正在把LLM集成进生产环境的工程师你们手里的Prometheus和Grafana已经快失语了另一类是设计Agent工作流的产品与算法同学你们需要的不是一份“模型输出样例”而是一套能穿透黑箱、定位失效根因的诊断体系。接下来的内容没有PPT式的概念罗列只有我在三个真实生产级Agent项目金融投顾助手、跨系统IT运维协调员、生物医药文献摘要生成器中用血泪换来的实操框架、踩过的坑、以及那些文档里绝不会写的参数取舍逻辑。2. 从“监控三支柱”到“认知四象限”LLM系统可观测性的底层重构2.1 为什么Metrics/Logs/Traces这套老办法在LLM面前集体失灵先说结论不是工具不行是问题域变了。我们来拆解一下传统“可观测性三支柱”在LLM场景下的失效点Metrics指标失效传统指标如QPS、延迟、错误率对LLM系统几乎无意义。一个RAG问答API返回200不代表答案有用延迟从800ms降到300ms如果答案质量同步下降20%这到底是优化还是灾难我见过一个电商推荐Agent把平均响应时间压到400ms以内结果用户跳出率飙升因为模型为了赶时间直接跳过了关键的检索步骤用纯幻觉编造商品信息。这里的“错误率”根本无法定义——是HTTP 500算错还是答案事实性错误算错抑或是违反安全护栏算错三者权重如何分配Metrics本身不提供上下文它只告诉你“有异常”但从不告诉你“哪里异常、为何异常”。Logs日志失焦传统日志记录的是函数调用栈、SQL语句、状态变更。而LLM的日志是什么是几万字的prompt、中间生成的token序列、向量数据库的相似度分数、工具调用的原始输入输出……这些日志体积巨大单次调用日志动辄几十MB且高度非结构化。更致命的是它们缺乏可追溯的因果链。比如最终答案出错是因为检索到的文档不相关还是LLM在整合时忽略了关键约束还是工具调用返回了脏数据日志里堆砌的全是“发生了什么”却找不到“为什么发生”。我在调试一个医疗问答Agent时发现它总在特定药品名后给出错误剂量建议。翻遍日志只看到“Retrieved doc: [doc_id_789]”但doc_id_789到底是什么内容它和用户问题的语义匹配度是多少模型在阅读这份文档时注意力权重分布如何这些关键信息原始日志里一概没有。Traces链路追踪失真OpenTelemetry等工具能完美追踪“API - Router - Retrieval - LLM - Formatter - Response”的调用路径但它把每个环节都当作一个原子黑盒。Trace里显示“LLM.invoke()耗时2.3s”但这个2.3秒里模型是在认真推理还是在反复自我否定还是卡在某个低概率token采样上Trace无法告诉你内部的认知状态。更麻烦的是Agent系统存在动态分支——根据上一步输出决定下一步调用哪个工具、是否重试、是否求助人类。这种非线性的、数据驱动的控制流让静态的Trace图谱变得支离破碎根本无法还原真实的决策路径。所以我们必须抛弃“监控三支柱”的旧地图绘制一张新的“认知四象限”图谱。这四个象限不是并列关系而是层层递进、相互验证的诊断维度Input Integrity输入完整性确保进入系统的原始信号是干净、完整、意图明确的。这包括用户query的语义解析是否含歧义、隐含诉求、外部数据源如数据库、API的实时性与可信度校验、以及多模态输入如图片OCR文本的保真度评估。这不是简单的格式校验而是对“系统感知世界”的第一道把关。Reasoning Transparency推理透明性这是LLM可观测性的核心命门。它要求我们能穿透模型的“思考过程”观察其内部状态。具体包括Prompt工程效果的量化不同模板对答案一致性的影响、检索增强中相关文档的语义匹配度与多样性分析、模型在生成过程中各token位置的置信度logprobs、以及最关键的——思维链Chain-of-Thought的可验证性。例如一个数学题Agent不仅要输出答案还要输出其推理步骤可观测性系统必须能自动验证每一步骤的逻辑正确性而不仅仅是最终答案。Output Fidelity输出保真度评估最终交付物是否符合预期目标。这远超传统的accuracy。它包含事实性Factuality——答案是否与可靠知识源一致忠实性Faithfulness——答案是否严格基于提供的上下文而非幻觉安全性Safety——是否规避了有害、偏见、违规内容效用性Utility——答案是否真正解决了用户的实际问题需结合用户行为日志如后续点击、停留时长、人工修正率来反推。我曾为一个法律咨询Agent设计过一个“效用衰减曲线”如果用户在得到答案后30秒内发起新提问且新问题明显是对前一个问题的澄清或追问就标记为“效用不足”这比任何静态打分都更能反映真实价值。Systemic Resilience系统韧性衡量整个Agent工作流在面对扰动时的稳定能力。这包括当主检索源失效时降级策略如切换到备用知识库或启用纯LLM模式的触发时机与效果当工具调用超时时重试逻辑是否引入了新的错误以及最关键的——人类反馈闭环Human-in-the-loop的接入效率。一个真正有韧性的系统不是永不犯错而是能最快地被人类发现、理解、并修复错误。这要求可观测性数据必须能一键生成“故障复盘包”包含完整的输入、中间状态、输出、以及所有相关的元数据时间戳、版本号、配置哈希值供人类专家快速介入。这四个象限共同构成了一个动态的、可操作的诊断框架。任何一个象限的异常都会在其他象限留下可追踪的痕迹。比如“输出保真度”下降往往能在“推理透明性”中找到线索如某次检索的top-k文档匹配度集体低于阈值而“系统韧性”不足则会直接暴露在“输入完整性”的监控中如大量请求因上游API超时而被丢弃。这才是LLM时代应有的可观测性底座。2.2 评估Evaluation不是测试而是持续的“价值审计”如果说可观测性是“望闻问切”那么评估就是“出具诊断报告并开具处方”。在LLM领域评估Evaluation这个词被严重滥用了。很多人把它等同于“跑个benchmark”用一个公开数据集如MMLU、GSM8K打个分就宣布模型“很强”。这在研究阶段或许可行但在生产环境中这是极其危险的。生产环境中的评估本质上是一场持续的“价值审计”——它要回答的核心问题是“这个系统此刻正在为我们的业务目标创造多少真实价值它的价值创造过程是否健康、可持续、可解释”这就引出了评估的两个根本性转变第一从静态打分到动态归因。传统评估输出一个单一数字如Accuracy87.3%。而生产级评估必须输出一个归因树Attribution Tree。以一个销售话术生成Agent为例它的最终目标是提升转化率。评估报告不能只说“话术生成准确率85%”而必须分解这85%的准确率有多少来自Prompt优化12%有多少来自检索知识库的更新8%有多少来自LLM模型本身的升级5%又有多少被下游的语音合成模块的失真所抵消-3% 这个归因树必须能精确到每一次调用、每一个配置变更、每一个数据版本。没有归因优化就是盲人摸象。我负责的一个项目上线后转化率不升反降。最初的评估报告只显示“整体准确率微升0.2%”毫无价值。后来我们强制要求所有评估必须绑定Git Commit Hash和Data Version Tag才发现在一次看似无关的prompt模板微调中模型对“限时优惠”这一关键短语的敏感度被意外降低了导致生成的话术普遍缺乏紧迫感——这个细节在宏观的准确率数字里完全被淹没。第二从通用基准到场景专属。MMLU再好也测不出你的客服Agent能否在用户情绪暴躁时用恰当的语气化解冲突。生产评估必须是“场景原生”的。这意味着你需要为每一个核心业务场景构建一套专属的、小而精的评估数据集Evaluation Dataset它必须包含真实世界样本Real-world Samples不是合成的而是从线上流量中脱敏采样覆盖长尾case如方言、错别字、多轮纠缠。多维标注Multi-dimensional Annotations同一个样本由不同角色产品、法务、客服主管从不同维度打分。例如一个投诉处理回复法务关注合规性0-10分客服主管关注情绪安抚效果0-10分而产品关注是否引导用户完成了关键动作如提交表单是/否。对抗性样本Adversarial Samples专门设计用来“攻击”系统弱点的样本。比如针对一个金融风控Agent构造一系列语义上极度相似但风险等级天差地别的句子“我想提现” vs “请帮我把钱转到境外账户”测试其判别边界是否清晰。这种场景专属的评估其成本远高于跑一个公开benchmark但它带来的收益是质的飞跃。它让你能精准定位“我的系统在哪种情况下会失败”而不是泛泛而谈“我的系统还不错”。这正是从“技术可行性”迈向“商业可靠性”的关键一步。3. 构建你的第一套生产级可观测性流水线从零开始的实操指南3.1 数据采集层不是“全量埋点”而是“精准捕获认知信号”在LLM系统中盲目追求“全量日志”是灾难的开始。一次典型的Agent调用产生的原始数据prompt、context、response、tool calls、embeddings轻松超过100MB。存储、传输、索引的成本会指数级增长而99%的数据对诊断毫无价值。我们必须像外科医生一样进行“精准捕获”。核心原则只捕获能直接服务于四个象限诊断的信号。我们按象限梳理必采信号认知象限必采信号采集方式为什么必须采实操技巧Input Integrity用户原始Query未清洗、Query的语义解析结果意图、实体、情感倾向、上游数据源的元数据最后更新时间、数据量、可用性状态在API网关或Router层拦截没有原始Query无法回溯用户真实意图没有上游元数据无法判断是模型问题还是数据问题对Query做轻量级哈希如MD5前8位作为ID避免存储明文上游元数据用Prometheus Gauge实时上报便于关联分析Reasoning TransparencyPrompt模板ID 版本号、检索到的Top-K文档ID及对应相似度分数、LLM生成的每个token的logprob仅前100个token、工具调用的完整输入/输出JSON在LLM调用前/后、工具调用前后HookPrompt ID是归因的基石相似度分数是诊断检索失效的唯一依据logprobs是分析模型“犹豫”或“自信”的金标准严禁全量logprobs只采top-k tokensk50~100足够用protobuf序列化比JSON节省70%体积工具调用I/O必须带tool_name和call_id用于构建执行图谱Output Fidelity最终Response全文、Response的结构化解析如提取的日期、金额、操作指令、人工审核标记如有、用户后续行为30秒内是否重试/跳转/关闭在Response返回前拦截Response全文是所有下游评估的源头结构化解析是自动化校验的前提用户行为是效用性的黄金指标对Response做语法树解析如spaCy提取关键字段存为独立字段便于聚合查询用户行为通过前端埋点后端Session ID关联延迟容忍≤500msSystemic Resilience每个组件的SLO达标率如检索P95延迟500ms、降级策略触发次数、人工介入事件ID含处理人、耗时、结论各组件内部埋点 人工工单系统WebhookSLO是韧性的量化体现降级次数是系统压力的晴雨表人工介入是终极的“价值审计”证据SLO达标率用Prometheus Histogram计算比Counter更精准人工介入事件用统一Schema通过Kafka实时流入可观测性平台关键避坑点提示绝对不要在LLM调用时将整个prompt context尤其是长文档作为字符串写入日志。这会导致日志服务瞬间崩溃。正确的做法是只记录context的摘要如文档ID列表、总token数、平均相似度并将原始context存入对象存储如S3日志中只存一个可追溯的URI。我亲眼见过一个团队因为这个错误导致ELK集群连续三天无法响应线上问题排查完全停滞。注意logprobs的采集有性能开销。在高并发场景下可以采用“采样采集”策略对10%的请求全量采集logprobs对另外90%的请求只采集最高置信度token的logprob。这足以支撑大部分诊断需求且性能损耗可控。3.2 存储与索引层为“认知数据”选择正确的数据库捕获到的数据必须存放在能支撑复杂查询的引擎里。这里没有银弹必须按数据特性分而治之时序指标Metrics与状态快照SLO, Availability继续使用Prometheus。它的优势在于毫秒级写入、强大的聚合函数如rate(),histogram_quantile()和与Grafana的无缝集成。对于LLM特有的指标如“平均检索文档相似度”我们将其定义为一个Prometheus Gauge每次检索后更新。SLO达标率则用Histogram统计P95延迟并用histogram_quantile(0.95, rate(...))实时计算。高基数、高吞吐的原始事件流Logs, Traces放弃Elasticsearch。它的存储成本和查询延迟在LLM场景下不堪重负。我们转向ClickHouse。原因有三1) 列式存储对logprobs、相似度分数这类数值型字段查询极快2) 支持高效的GROUP BY和HAVING能轻松实现“找出所有相似度0.3且最终答案错误的检索”3) 原生支持JSON解析可以直接在SQL里SELECT JSONExtractFloat(event_json, similarity)。我们将所有捕获的信号按trace_id全局唯一和timestamp分区写入ClickHouse的llm_events表。图谱化的关系数据Execution Graph这是诊断Agent动态分支的核心。我们需要一个图数据库来存储“谁调用了谁、为什么调用、结果如何”。我们选用Neo4j。每个节点代表一个实体User,Query,Document,ToolCall,LLMResponse每条边代表一个关系:TRIGGERED_BY,:USED_AS_CONTEXT,:GENERATED。例如一次完整的Agent执行会生成一条路径(User)-[:SUBMITTED]-(Query)-[:TRIGGERED]-(Retrieval)-[:RETURNED]-(Document)-[:USED_AS_CONTEXT]-(LLM)-[:GENERATED]-(Response)。有了这个图谱我们就能用Cypher查询“找出所有因Document节点的source属性为legacy_db而导致Response节点的factuality_score0.6的路径”这在关系型数据库里是噩梦般的JOIN。向量嵌入Embeddings用于高级语义搜索如“找出所有与本次错误答案语义相似的历史案例”。我们使用Qdrant。它专为向量搜索优化支持高效的近似最近邻ANN查询并且能与标量过滤如timestamp 2024-01-01 AND status error无缝结合。我们将每次检索的query embedding和top-k document embeddings连同trace_id一起存入Qdrant。当一个新错误发生时我们先用它的query embedding在Qdrant中搜索相似历史再用返回的trace_id去ClickHouse中拉取详细日志形成“语义结构”的双重诊断。架构图文字描述所有采集探针Instrumentation Probes将数据发送到Kafka Topic。一个Flink作业消费Kafka根据数据类型metric/log/graph/vector进行分流Metrics写入Prometheus PushgatewayLogs/Events写入ClickHouseGraph数据写入Neo4jVectors写入Qdrant。整个流水线无单点故障且各组件可独立水平扩展。3.3 分析与可视化层让数据自己讲故事有了数据和存储最后一步是让工程师和产品经理能直观地“看见”问题。这绝不是简单地把ClickHouse表拖进Grafana。我们必须构建一套面向“认知诊断”的仪表盘。核心仪表盘设计基于GrafanaDashboard 1实时健康视图Real-time Health这是值班工程师的第一眼。它不展示任何原始数字而是用状态灯趋势箭头呈现四个象限的健康度Input Integrity绿色95% query有有效意图解析黄色90-95%红色90%Reasoning Transparency显示“平均检索相似度”的P50/P90并用折线图对比昨日同期Output Fidelity用饼图显示今日错误类型的分布事实性错误、安全性违规、效用不足并高亮占比最高的Top 3Systemic Resilience显示“降级策略触发率”和“人工介入平均响应时间”关键技巧所有指标都必须配置动态基线Dynamic Baseline。例如“平均检索相似度”的基线不是固定值而是过去7天同一小时段的移动平均。这样凌晨3点的自然低谷就不会被误报为故障。Dashboard 2深度诊断视图Deep Dive当某个象限变红时点击进入此视图。它是一个“钻取式”界面第一步按Trace ID筛选。输入一个已知的bad trace_id或从健康视图中点击一个错误事件。第二步执行图谱渲染。Grafana插件调用Neo4j API将该trace_id对应的完整执行图谱节点边可视化。你可以直观看到是哪个ToolCall节点返回了异常结果进而导致了下游LLM节点的错误。第三步上下文关联。图谱中每个节点都可点击点击Document节点右侧弹出该文档的原文摘要和与query的相似度热力图点击LLMResponse节点弹出其logprobs分布直方图和事实性校验报告由一个独立的RAG校验服务生成。第四步语义相似搜索。点击Query节点后台自动用其embedding在Qdrant中搜索返回3个最相似的历史bad case及其各自的诊断报告链接。Dashboard 3归因分析视图Attribution Analysis这是给算法和产品同学用的。它回答“这次A/B测试为什么B组转化率高”它的核心是一个多维交叉分析矩阵。X轴是实验分组A/BY轴是评估维度事实性、安全性、效用性单元格内是该维度的得分及变化量。更重要的是它支持“下钻”点击B组的“效用性”单元格图表会自动切换X轴变为“Prompt模板版本”Y轴变为“用户停留时长中位数”从而证明是新模板提升了用户粘性。所有数据都来自ClickHouse的聚合查询毫秒级响应。实操心得Grafana的变量Variable功能是灵魂。我们定义了$trace_id,$prompt_version,$tool_name等多个变量。一个仪表盘通过切换变量就能从“全局健康”视角瞬间切换到“单次故障”、“版本对比”、“工具效能”等任意视角。这比维护十几个独立仪表盘高效得多。4. 评估即代码Evaluation-as-Code将评估逻辑沉淀为可复用、可版本化的资产4.1 为什么“评估脚本”必须像“生产代码”一样管理很多团队的评估还停留在Jupyter Notebook阶段算法同学写个脚本跑一遍数据截图发个报告。这在项目初期尚可但一旦进入迭代期就会陷入混乱。你无法回答“上周五上线的那个prompt优化对‘事实性’指标的具体影响是多少” 因为那个评估脚本可能已经被覆盖、修改甚至丢失了。评估必须成为软件开发生命周期SDLC的一等公民即“评估即代码Evaluation-as-Code”。核心实践将每一次评估都定义为一个独立的、可版本控制的、可参数化的Python函数。这个函数的签名Signature是标准化的def evaluate_factuality( responses: List[str], # LLM生成的答案列表 contexts: List[List[str]], # 每个答案对应的检索上下文列表 ground_truths: List[str], # 对应的标准答案可选用于有监督评估 config: Dict[str, Any] None # 评估配置如模型选择、阈值 ) - Dict[str, Any]: 评估LLM答案的事实性Factuality。 返回一个包含score、details每个样本的细项得分、metadata的字典。 # ... 核心评估逻辑 ... return { score: 0.85, details: [ {sample_id: 0, factuality_score: 0.92, hallucination_reason: None}, {sample_id: 1, factuality_score: 0.78, hallucination_reason: Invented a non-existent drug name} ], metadata: {evaluated_at: 2024-01-15T10:30:00Z, config_hash: a1b2c3...} }这个函数被存放在一个独立的Git仓库llm-evaluation-library中与模型代码仓库llm-models和应用代码仓库llm-app完全解耦。每次评估都是通过CI/CD流水线拉取指定commit hash的评估函数传入线上采样的数据运行并生成报告。这带来了三大好处可追溯报告里明确写着“本次评估使用了evaluate_factualityv1.2.3”任何人想复现只需checkout该commit。可复用evaluate_safety,evaluate_utility等函数都遵循同一套接口规范可以被任何项目导入使用。可组合一个复杂的评估任务可以由多个基础函数组合而成。例如一个“综合健康度”评估就是evaluate_factuality、evaluate_safety、evaluate_utility三个函数的加权平均。4.2 构建你的评估函数库从基础到进阶一个成熟的评估函数库应该覆盖从基础到高级的各个层次。以下是我们在生产中验证过的、最实用的几类基础事实性评估Basic Factuality使用一个小型、快速的“校验模型Checker Model”。我们不依赖GPT-4这种重型模型而是微调一个deberta-base任务是给定answer和context预测answer是否被context所支持Entailed、矛盾Contradicted或中立Neutral。训练数据来自公开的FEVER数据集。这个模型小500MB推理快100ms且结果稳定。evaluate_factuality函数的核心就是调用这个checker模型并统计Entailed的比例。高级事实性评估Advanced Factuality当基础评估不够时启动“多跳验证Multi-hop Verification”。例如答案中提到“某药物的半衰期是12小时”评估函数会用NER识别出实体“药物名”和数值“12小时”调用一个专门的医药知识图谱API查询该药物的官方半衰期比较两者是否在合理误差范围内如±2小时。 这种评估成本高只对高价值、高风险的样本如医疗、金融启用。效用性评估Utility Evaluation这是最难量化但也最有价值的。我们的方案是行为代理Behavioral Proxy。我们定义了一系列与业务目标强相关的用户行为作为效用的代理指标对于客服Agentuser_clicked_on_suggested_link用户点击了答案中推荐的链接对于销售Agentuser_submitted_contact_form_within_2min用户在2分钟内提交了联系表单对于教育Agentuser_rated_response_5stars用户给了5星评价evaluate_utility函数不直接评估答案内容而是查询数据仓库统计在该答案返回后的指定时间窗口内上述代理行为的发生率并与历史基线进行对比。这直接将LLM的输出锚定到了真实的商业结果上。安全性评估Safety Evaluation我们采用“双模型共识Dual-Model Consensus”策略。同时运行两个不同的安全模型一个开源的、基于规则的模型如llama-guard擅长检测明确的违规词。一个闭源的、基于大模型的模型如Claude擅长理解语境和隐含意图。evaluate_safety函数只在两个模型都判定为“安全”时才给出高分。只要有一个模型报警就触发人工审核流程。这极大地降低了漏报率也避免了过度审查。实操心得评估函数的性能至关重要。我们为每个函数设定了严格的SLA95%的调用必须在500ms内完成。为此我们做了大量优化对debertachecker模型使用ONNX Runtime进行推理加速速度提升3倍。对知识图谱查询添加了本地缓存Redis缓存命中率90%。对用户行为查询预计算了滚动窗口的聚合指标评估时只需查表。5. 真实战场上的问题排查一份来自生产环境的“故障速查手册”5.1 典型故障模式与根因定位路径在三个项目中我们总结出了LLM系统最常出现的7类故障。每一种我们都固化了标准的排查路径。这份手册是每个值班工程师的案头必备。故障现象可观测性线索四个象限排查路径Step-by-Step解决方案经验之谈现象1答案质量随机波动时好时坏- Reasoning Transparencylogprobs分布异常宽泛高方差- Input IntegrityQuery的情感倾向标注频繁在“愤怒”和“中性”间跳变1. 在ClickHouse中用WHERE query_emotion IN (anger, neutral) AND logprob_stddev 0.5筛选样本2. 查看这些样本的Prompt模板ID确认是否混用了不同风格的模板3. 检查Router层的负载均衡策略是否将同一用户的多次请求路由到了不同版本的模型实例上根因是Router的sticky session会话保持未开启导致用户在A/B测试中被随机分配。方案强制开启基于user_id的sticky session并在评估报告中增加“用户一致性”指标同一用户连续5次请求使用相同模型版本的比例。现象2检索结果相关性突然下降- Reasoning TransparencyTop-1文档相似度P50从0.75骤降至0.45- Systemic Resilience检索组件的P95延迟从300ms飙升至2s1. 在Prometheus中查看检索服务的http_request_duration_seconds_bucket确认是否大量请求落入了le2的桶2. 在ClickHouse中SELECT doc_source, COUNT(*) FROM llm_events WHERE similarity 0.5 GROUP BY doc_source发现90%的低分文档来自legacy_db3. 检查legacy_db的连接池监控发现连接数耗尽根因legacy_db的连接池配置过小高并发下连接耗尽导致检索服务降级到一个低质量的备用索引。方案立即扩容连接池并在评估函数中增加“降级来源”字段让evaluate_retrieval能自动区分主索引和降级索引的效果。现象3工具调用频繁失败但错误码都是200- Reasoning Transparencytool_call_input中包含大量{timeout: 3000}而tool_call_output中status为timeout- Output Fidelity最终答案中频繁出现“我无法访问该系统请稍后再试”1. 在Neo4j中运行CypherMATCH (t:ToolCall) WHERE t.status timeout RETURN t.tool_name, count(*) ORDER BY count(*) DESC锁定问题工具2. 查看该工具的上游API监控发现其P99延迟超标3. 检查Agent的工具调用逻辑发现其timeout参数硬编码为3000ms而上游API的P99是3500ms根因工具调用的超时阈值设置不合理且未实现指数退避重试。方案将超时阈值改为上游API的P99 * 1.5并在工具调用封装层加入指数退避Exponential Backoff逻辑。现象4答案中出现大量重复内容Repetition- Reasoning Transparencylogprobs显示在重复段落的起始token处logprob异常高模型“过于自信”- Input IntegrityQuery中包含大量重复的关键词如用户反复输入“重要重要重要”1. 在ClickHouse中SELECT query, response FROM llm_events WHERE response LIKE %重要重要重要%确认Query特征2. 分析该Query的tokenization发现重要被分成了[重要, , 重要, , 重要, ]导致模型在生成时过度关注该token3. 检查预处理Pipeline发现缺少“重复符号去重”步骤根因预处理缺失导致模型被噪声token干扰。方案在Router层增加一个轻量级的“Query净化”步骤使用正则re.sub(r([^\w\s])\1{2,}, r\1, query)将连续3个以上的标点符号压缩为1个。现象5系统对新出现的术语如新药名、新法规完全无知- Input IntegrityQuery中包含的新术语在检索的context中完全未命中相似度为0- Reasoning TransparencyLLM在生成时对unktoken的logprob异常高1. 在Qdrant中用新术语的embedding进行搜索确认知识库中确实无匹配2. 检查知识库的更新流水线发现其ETL任务因上游数据源格式变更而失败已停摆3天3. 查看knowledge_update_statusPrometheus Gauge
LLM系统可观测性重构：从监控三支柱到认知四象限
1. 这不是“加个监控”就能糊弄过去的事为什么大模型系统必须重构可观测性思维你有没有遇到过这样的情况线上跑着一个客服对话机器人用户反馈“回答越来越离谱”但日志里只看到一串成功的200响应或者团队花三个月调优的RAG流程在A/B测试中点击率反而下降了5%而所有指标面板都显示“一切正常”。这不是玄学这是当前LLM应用落地中最普遍、最隐蔽的失效模式——我们还在用微服务时代的那套可观测性Observability工具和思路去诊断一个本质完全不同、行为不可预测、输出非结构化的智能体系统。标题里这个“Observability Evaluation in LLMs and Agentic Systems”说的不是给大模型加几个metrics埋点那么简单它是一场从底层认知开始的范式迁移。核心关键词——可观测性Observability、评估Evaluation、大语言模型LLMs、智能体系统Agentic Systems——每一个词背后都站着一套被颠覆的工程逻辑。传统可观测性关注“系统是否在运行”而LLM系统的可观测性必须回答“系统是否在正确地思考”传统评估聚焦于准确率、F1值这类静态打分而智能体系统的评估必须覆盖目标达成度、推理链鲁棒性、工具调用合理性、甚至人类偏好的对齐程度。这篇文章写给两类人一类是正在把LLM集成进生产环境的工程师你们手里的Prometheus和Grafana已经快失语了另一类是设计Agent工作流的产品与算法同学你们需要的不是一份“模型输出样例”而是一套能穿透黑箱、定位失效根因的诊断体系。接下来的内容没有PPT式的概念罗列只有我在三个真实生产级Agent项目金融投顾助手、跨系统IT运维协调员、生物医药文献摘要生成器中用血泪换来的实操框架、踩过的坑、以及那些文档里绝不会写的参数取舍逻辑。2. 从“监控三支柱”到“认知四象限”LLM系统可观测性的底层重构2.1 为什么Metrics/Logs/Traces这套老办法在LLM面前集体失灵先说结论不是工具不行是问题域变了。我们来拆解一下传统“可观测性三支柱”在LLM场景下的失效点Metrics指标失效传统指标如QPS、延迟、错误率对LLM系统几乎无意义。一个RAG问答API返回200不代表答案有用延迟从800ms降到300ms如果答案质量同步下降20%这到底是优化还是灾难我见过一个电商推荐Agent把平均响应时间压到400ms以内结果用户跳出率飙升因为模型为了赶时间直接跳过了关键的检索步骤用纯幻觉编造商品信息。这里的“错误率”根本无法定义——是HTTP 500算错还是答案事实性错误算错抑或是违反安全护栏算错三者权重如何分配Metrics本身不提供上下文它只告诉你“有异常”但从不告诉你“哪里异常、为何异常”。Logs日志失焦传统日志记录的是函数调用栈、SQL语句、状态变更。而LLM的日志是什么是几万字的prompt、中间生成的token序列、向量数据库的相似度分数、工具调用的原始输入输出……这些日志体积巨大单次调用日志动辄几十MB且高度非结构化。更致命的是它们缺乏可追溯的因果链。比如最终答案出错是因为检索到的文档不相关还是LLM在整合时忽略了关键约束还是工具调用返回了脏数据日志里堆砌的全是“发生了什么”却找不到“为什么发生”。我在调试一个医疗问答Agent时发现它总在特定药品名后给出错误剂量建议。翻遍日志只看到“Retrieved doc: [doc_id_789]”但doc_id_789到底是什么内容它和用户问题的语义匹配度是多少模型在阅读这份文档时注意力权重分布如何这些关键信息原始日志里一概没有。Traces链路追踪失真OpenTelemetry等工具能完美追踪“API - Router - Retrieval - LLM - Formatter - Response”的调用路径但它把每个环节都当作一个原子黑盒。Trace里显示“LLM.invoke()耗时2.3s”但这个2.3秒里模型是在认真推理还是在反复自我否定还是卡在某个低概率token采样上Trace无法告诉你内部的认知状态。更麻烦的是Agent系统存在动态分支——根据上一步输出决定下一步调用哪个工具、是否重试、是否求助人类。这种非线性的、数据驱动的控制流让静态的Trace图谱变得支离破碎根本无法还原真实的决策路径。所以我们必须抛弃“监控三支柱”的旧地图绘制一张新的“认知四象限”图谱。这四个象限不是并列关系而是层层递进、相互验证的诊断维度Input Integrity输入完整性确保进入系统的原始信号是干净、完整、意图明确的。这包括用户query的语义解析是否含歧义、隐含诉求、外部数据源如数据库、API的实时性与可信度校验、以及多模态输入如图片OCR文本的保真度评估。这不是简单的格式校验而是对“系统感知世界”的第一道把关。Reasoning Transparency推理透明性这是LLM可观测性的核心命门。它要求我们能穿透模型的“思考过程”观察其内部状态。具体包括Prompt工程效果的量化不同模板对答案一致性的影响、检索增强中相关文档的语义匹配度与多样性分析、模型在生成过程中各token位置的置信度logprobs、以及最关键的——思维链Chain-of-Thought的可验证性。例如一个数学题Agent不仅要输出答案还要输出其推理步骤可观测性系统必须能自动验证每一步骤的逻辑正确性而不仅仅是最终答案。Output Fidelity输出保真度评估最终交付物是否符合预期目标。这远超传统的accuracy。它包含事实性Factuality——答案是否与可靠知识源一致忠实性Faithfulness——答案是否严格基于提供的上下文而非幻觉安全性Safety——是否规避了有害、偏见、违规内容效用性Utility——答案是否真正解决了用户的实际问题需结合用户行为日志如后续点击、停留时长、人工修正率来反推。我曾为一个法律咨询Agent设计过一个“效用衰减曲线”如果用户在得到答案后30秒内发起新提问且新问题明显是对前一个问题的澄清或追问就标记为“效用不足”这比任何静态打分都更能反映真实价值。Systemic Resilience系统韧性衡量整个Agent工作流在面对扰动时的稳定能力。这包括当主检索源失效时降级策略如切换到备用知识库或启用纯LLM模式的触发时机与效果当工具调用超时时重试逻辑是否引入了新的错误以及最关键的——人类反馈闭环Human-in-the-loop的接入效率。一个真正有韧性的系统不是永不犯错而是能最快地被人类发现、理解、并修复错误。这要求可观测性数据必须能一键生成“故障复盘包”包含完整的输入、中间状态、输出、以及所有相关的元数据时间戳、版本号、配置哈希值供人类专家快速介入。这四个象限共同构成了一个动态的、可操作的诊断框架。任何一个象限的异常都会在其他象限留下可追踪的痕迹。比如“输出保真度”下降往往能在“推理透明性”中找到线索如某次检索的top-k文档匹配度集体低于阈值而“系统韧性”不足则会直接暴露在“输入完整性”的监控中如大量请求因上游API超时而被丢弃。这才是LLM时代应有的可观测性底座。2.2 评估Evaluation不是测试而是持续的“价值审计”如果说可观测性是“望闻问切”那么评估就是“出具诊断报告并开具处方”。在LLM领域评估Evaluation这个词被严重滥用了。很多人把它等同于“跑个benchmark”用一个公开数据集如MMLU、GSM8K打个分就宣布模型“很强”。这在研究阶段或许可行但在生产环境中这是极其危险的。生产环境中的评估本质上是一场持续的“价值审计”——它要回答的核心问题是“这个系统此刻正在为我们的业务目标创造多少真实价值它的价值创造过程是否健康、可持续、可解释”这就引出了评估的两个根本性转变第一从静态打分到动态归因。传统评估输出一个单一数字如Accuracy87.3%。而生产级评估必须输出一个归因树Attribution Tree。以一个销售话术生成Agent为例它的最终目标是提升转化率。评估报告不能只说“话术生成准确率85%”而必须分解这85%的准确率有多少来自Prompt优化12%有多少来自检索知识库的更新8%有多少来自LLM模型本身的升级5%又有多少被下游的语音合成模块的失真所抵消-3% 这个归因树必须能精确到每一次调用、每一个配置变更、每一个数据版本。没有归因优化就是盲人摸象。我负责的一个项目上线后转化率不升反降。最初的评估报告只显示“整体准确率微升0.2%”毫无价值。后来我们强制要求所有评估必须绑定Git Commit Hash和Data Version Tag才发现在一次看似无关的prompt模板微调中模型对“限时优惠”这一关键短语的敏感度被意外降低了导致生成的话术普遍缺乏紧迫感——这个细节在宏观的准确率数字里完全被淹没。第二从通用基准到场景专属。MMLU再好也测不出你的客服Agent能否在用户情绪暴躁时用恰当的语气化解冲突。生产评估必须是“场景原生”的。这意味着你需要为每一个核心业务场景构建一套专属的、小而精的评估数据集Evaluation Dataset它必须包含真实世界样本Real-world Samples不是合成的而是从线上流量中脱敏采样覆盖长尾case如方言、错别字、多轮纠缠。多维标注Multi-dimensional Annotations同一个样本由不同角色产品、法务、客服主管从不同维度打分。例如一个投诉处理回复法务关注合规性0-10分客服主管关注情绪安抚效果0-10分而产品关注是否引导用户完成了关键动作如提交表单是/否。对抗性样本Adversarial Samples专门设计用来“攻击”系统弱点的样本。比如针对一个金融风控Agent构造一系列语义上极度相似但风险等级天差地别的句子“我想提现” vs “请帮我把钱转到境外账户”测试其判别边界是否清晰。这种场景专属的评估其成本远高于跑一个公开benchmark但它带来的收益是质的飞跃。它让你能精准定位“我的系统在哪种情况下会失败”而不是泛泛而谈“我的系统还不错”。这正是从“技术可行性”迈向“商业可靠性”的关键一步。3. 构建你的第一套生产级可观测性流水线从零开始的实操指南3.1 数据采集层不是“全量埋点”而是“精准捕获认知信号”在LLM系统中盲目追求“全量日志”是灾难的开始。一次典型的Agent调用产生的原始数据prompt、context、response、tool calls、embeddings轻松超过100MB。存储、传输、索引的成本会指数级增长而99%的数据对诊断毫无价值。我们必须像外科医生一样进行“精准捕获”。核心原则只捕获能直接服务于四个象限诊断的信号。我们按象限梳理必采信号认知象限必采信号采集方式为什么必须采实操技巧Input Integrity用户原始Query未清洗、Query的语义解析结果意图、实体、情感倾向、上游数据源的元数据最后更新时间、数据量、可用性状态在API网关或Router层拦截没有原始Query无法回溯用户真实意图没有上游元数据无法判断是模型问题还是数据问题对Query做轻量级哈希如MD5前8位作为ID避免存储明文上游元数据用Prometheus Gauge实时上报便于关联分析Reasoning TransparencyPrompt模板ID 版本号、检索到的Top-K文档ID及对应相似度分数、LLM生成的每个token的logprob仅前100个token、工具调用的完整输入/输出JSON在LLM调用前/后、工具调用前后HookPrompt ID是归因的基石相似度分数是诊断检索失效的唯一依据logprobs是分析模型“犹豫”或“自信”的金标准严禁全量logprobs只采top-k tokensk50~100足够用protobuf序列化比JSON节省70%体积工具调用I/O必须带tool_name和call_id用于构建执行图谱Output Fidelity最终Response全文、Response的结构化解析如提取的日期、金额、操作指令、人工审核标记如有、用户后续行为30秒内是否重试/跳转/关闭在Response返回前拦截Response全文是所有下游评估的源头结构化解析是自动化校验的前提用户行为是效用性的黄金指标对Response做语法树解析如spaCy提取关键字段存为独立字段便于聚合查询用户行为通过前端埋点后端Session ID关联延迟容忍≤500msSystemic Resilience每个组件的SLO达标率如检索P95延迟500ms、降级策略触发次数、人工介入事件ID含处理人、耗时、结论各组件内部埋点 人工工单系统WebhookSLO是韧性的量化体现降级次数是系统压力的晴雨表人工介入是终极的“价值审计”证据SLO达标率用Prometheus Histogram计算比Counter更精准人工介入事件用统一Schema通过Kafka实时流入可观测性平台关键避坑点提示绝对不要在LLM调用时将整个prompt context尤其是长文档作为字符串写入日志。这会导致日志服务瞬间崩溃。正确的做法是只记录context的摘要如文档ID列表、总token数、平均相似度并将原始context存入对象存储如S3日志中只存一个可追溯的URI。我亲眼见过一个团队因为这个错误导致ELK集群连续三天无法响应线上问题排查完全停滞。注意logprobs的采集有性能开销。在高并发场景下可以采用“采样采集”策略对10%的请求全量采集logprobs对另外90%的请求只采集最高置信度token的logprob。这足以支撑大部分诊断需求且性能损耗可控。3.2 存储与索引层为“认知数据”选择正确的数据库捕获到的数据必须存放在能支撑复杂查询的引擎里。这里没有银弹必须按数据特性分而治之时序指标Metrics与状态快照SLO, Availability继续使用Prometheus。它的优势在于毫秒级写入、强大的聚合函数如rate(),histogram_quantile()和与Grafana的无缝集成。对于LLM特有的指标如“平均检索文档相似度”我们将其定义为一个Prometheus Gauge每次检索后更新。SLO达标率则用Histogram统计P95延迟并用histogram_quantile(0.95, rate(...))实时计算。高基数、高吞吐的原始事件流Logs, Traces放弃Elasticsearch。它的存储成本和查询延迟在LLM场景下不堪重负。我们转向ClickHouse。原因有三1) 列式存储对logprobs、相似度分数这类数值型字段查询极快2) 支持高效的GROUP BY和HAVING能轻松实现“找出所有相似度0.3且最终答案错误的检索”3) 原生支持JSON解析可以直接在SQL里SELECT JSONExtractFloat(event_json, similarity)。我们将所有捕获的信号按trace_id全局唯一和timestamp分区写入ClickHouse的llm_events表。图谱化的关系数据Execution Graph这是诊断Agent动态分支的核心。我们需要一个图数据库来存储“谁调用了谁、为什么调用、结果如何”。我们选用Neo4j。每个节点代表一个实体User,Query,Document,ToolCall,LLMResponse每条边代表一个关系:TRIGGERED_BY,:USED_AS_CONTEXT,:GENERATED。例如一次完整的Agent执行会生成一条路径(User)-[:SUBMITTED]-(Query)-[:TRIGGERED]-(Retrieval)-[:RETURNED]-(Document)-[:USED_AS_CONTEXT]-(LLM)-[:GENERATED]-(Response)。有了这个图谱我们就能用Cypher查询“找出所有因Document节点的source属性为legacy_db而导致Response节点的factuality_score0.6的路径”这在关系型数据库里是噩梦般的JOIN。向量嵌入Embeddings用于高级语义搜索如“找出所有与本次错误答案语义相似的历史案例”。我们使用Qdrant。它专为向量搜索优化支持高效的近似最近邻ANN查询并且能与标量过滤如timestamp 2024-01-01 AND status error无缝结合。我们将每次检索的query embedding和top-k document embeddings连同trace_id一起存入Qdrant。当一个新错误发生时我们先用它的query embedding在Qdrant中搜索相似历史再用返回的trace_id去ClickHouse中拉取详细日志形成“语义结构”的双重诊断。架构图文字描述所有采集探针Instrumentation Probes将数据发送到Kafka Topic。一个Flink作业消费Kafka根据数据类型metric/log/graph/vector进行分流Metrics写入Prometheus PushgatewayLogs/Events写入ClickHouseGraph数据写入Neo4jVectors写入Qdrant。整个流水线无单点故障且各组件可独立水平扩展。3.3 分析与可视化层让数据自己讲故事有了数据和存储最后一步是让工程师和产品经理能直观地“看见”问题。这绝不是简单地把ClickHouse表拖进Grafana。我们必须构建一套面向“认知诊断”的仪表盘。核心仪表盘设计基于GrafanaDashboard 1实时健康视图Real-time Health这是值班工程师的第一眼。它不展示任何原始数字而是用状态灯趋势箭头呈现四个象限的健康度Input Integrity绿色95% query有有效意图解析黄色90-95%红色90%Reasoning Transparency显示“平均检索相似度”的P50/P90并用折线图对比昨日同期Output Fidelity用饼图显示今日错误类型的分布事实性错误、安全性违规、效用不足并高亮占比最高的Top 3Systemic Resilience显示“降级策略触发率”和“人工介入平均响应时间”关键技巧所有指标都必须配置动态基线Dynamic Baseline。例如“平均检索相似度”的基线不是固定值而是过去7天同一小时段的移动平均。这样凌晨3点的自然低谷就不会被误报为故障。Dashboard 2深度诊断视图Deep Dive当某个象限变红时点击进入此视图。它是一个“钻取式”界面第一步按Trace ID筛选。输入一个已知的bad trace_id或从健康视图中点击一个错误事件。第二步执行图谱渲染。Grafana插件调用Neo4j API将该trace_id对应的完整执行图谱节点边可视化。你可以直观看到是哪个ToolCall节点返回了异常结果进而导致了下游LLM节点的错误。第三步上下文关联。图谱中每个节点都可点击点击Document节点右侧弹出该文档的原文摘要和与query的相似度热力图点击LLMResponse节点弹出其logprobs分布直方图和事实性校验报告由一个独立的RAG校验服务生成。第四步语义相似搜索。点击Query节点后台自动用其embedding在Qdrant中搜索返回3个最相似的历史bad case及其各自的诊断报告链接。Dashboard 3归因分析视图Attribution Analysis这是给算法和产品同学用的。它回答“这次A/B测试为什么B组转化率高”它的核心是一个多维交叉分析矩阵。X轴是实验分组A/BY轴是评估维度事实性、安全性、效用性单元格内是该维度的得分及变化量。更重要的是它支持“下钻”点击B组的“效用性”单元格图表会自动切换X轴变为“Prompt模板版本”Y轴变为“用户停留时长中位数”从而证明是新模板提升了用户粘性。所有数据都来自ClickHouse的聚合查询毫秒级响应。实操心得Grafana的变量Variable功能是灵魂。我们定义了$trace_id,$prompt_version,$tool_name等多个变量。一个仪表盘通过切换变量就能从“全局健康”视角瞬间切换到“单次故障”、“版本对比”、“工具效能”等任意视角。这比维护十几个独立仪表盘高效得多。4. 评估即代码Evaluation-as-Code将评估逻辑沉淀为可复用、可版本化的资产4.1 为什么“评估脚本”必须像“生产代码”一样管理很多团队的评估还停留在Jupyter Notebook阶段算法同学写个脚本跑一遍数据截图发个报告。这在项目初期尚可但一旦进入迭代期就会陷入混乱。你无法回答“上周五上线的那个prompt优化对‘事实性’指标的具体影响是多少” 因为那个评估脚本可能已经被覆盖、修改甚至丢失了。评估必须成为软件开发生命周期SDLC的一等公民即“评估即代码Evaluation-as-Code”。核心实践将每一次评估都定义为一个独立的、可版本控制的、可参数化的Python函数。这个函数的签名Signature是标准化的def evaluate_factuality( responses: List[str], # LLM生成的答案列表 contexts: List[List[str]], # 每个答案对应的检索上下文列表 ground_truths: List[str], # 对应的标准答案可选用于有监督评估 config: Dict[str, Any] None # 评估配置如模型选择、阈值 ) - Dict[str, Any]: 评估LLM答案的事实性Factuality。 返回一个包含score、details每个样本的细项得分、metadata的字典。 # ... 核心评估逻辑 ... return { score: 0.85, details: [ {sample_id: 0, factuality_score: 0.92, hallucination_reason: None}, {sample_id: 1, factuality_score: 0.78, hallucination_reason: Invented a non-existent drug name} ], metadata: {evaluated_at: 2024-01-15T10:30:00Z, config_hash: a1b2c3...} }这个函数被存放在一个独立的Git仓库llm-evaluation-library中与模型代码仓库llm-models和应用代码仓库llm-app完全解耦。每次评估都是通过CI/CD流水线拉取指定commit hash的评估函数传入线上采样的数据运行并生成报告。这带来了三大好处可追溯报告里明确写着“本次评估使用了evaluate_factualityv1.2.3”任何人想复现只需checkout该commit。可复用evaluate_safety,evaluate_utility等函数都遵循同一套接口规范可以被任何项目导入使用。可组合一个复杂的评估任务可以由多个基础函数组合而成。例如一个“综合健康度”评估就是evaluate_factuality、evaluate_safety、evaluate_utility三个函数的加权平均。4.2 构建你的评估函数库从基础到进阶一个成熟的评估函数库应该覆盖从基础到高级的各个层次。以下是我们在生产中验证过的、最实用的几类基础事实性评估Basic Factuality使用一个小型、快速的“校验模型Checker Model”。我们不依赖GPT-4这种重型模型而是微调一个deberta-base任务是给定answer和context预测answer是否被context所支持Entailed、矛盾Contradicted或中立Neutral。训练数据来自公开的FEVER数据集。这个模型小500MB推理快100ms且结果稳定。evaluate_factuality函数的核心就是调用这个checker模型并统计Entailed的比例。高级事实性评估Advanced Factuality当基础评估不够时启动“多跳验证Multi-hop Verification”。例如答案中提到“某药物的半衰期是12小时”评估函数会用NER识别出实体“药物名”和数值“12小时”调用一个专门的医药知识图谱API查询该药物的官方半衰期比较两者是否在合理误差范围内如±2小时。 这种评估成本高只对高价值、高风险的样本如医疗、金融启用。效用性评估Utility Evaluation这是最难量化但也最有价值的。我们的方案是行为代理Behavioral Proxy。我们定义了一系列与业务目标强相关的用户行为作为效用的代理指标对于客服Agentuser_clicked_on_suggested_link用户点击了答案中推荐的链接对于销售Agentuser_submitted_contact_form_within_2min用户在2分钟内提交了联系表单对于教育Agentuser_rated_response_5stars用户给了5星评价evaluate_utility函数不直接评估答案内容而是查询数据仓库统计在该答案返回后的指定时间窗口内上述代理行为的发生率并与历史基线进行对比。这直接将LLM的输出锚定到了真实的商业结果上。安全性评估Safety Evaluation我们采用“双模型共识Dual-Model Consensus”策略。同时运行两个不同的安全模型一个开源的、基于规则的模型如llama-guard擅长检测明确的违规词。一个闭源的、基于大模型的模型如Claude擅长理解语境和隐含意图。evaluate_safety函数只在两个模型都判定为“安全”时才给出高分。只要有一个模型报警就触发人工审核流程。这极大地降低了漏报率也避免了过度审查。实操心得评估函数的性能至关重要。我们为每个函数设定了严格的SLA95%的调用必须在500ms内完成。为此我们做了大量优化对debertachecker模型使用ONNX Runtime进行推理加速速度提升3倍。对知识图谱查询添加了本地缓存Redis缓存命中率90%。对用户行为查询预计算了滚动窗口的聚合指标评估时只需查表。5. 真实战场上的问题排查一份来自生产环境的“故障速查手册”5.1 典型故障模式与根因定位路径在三个项目中我们总结出了LLM系统最常出现的7类故障。每一种我们都固化了标准的排查路径。这份手册是每个值班工程师的案头必备。故障现象可观测性线索四个象限排查路径Step-by-Step解决方案经验之谈现象1答案质量随机波动时好时坏- Reasoning Transparencylogprobs分布异常宽泛高方差- Input IntegrityQuery的情感倾向标注频繁在“愤怒”和“中性”间跳变1. 在ClickHouse中用WHERE query_emotion IN (anger, neutral) AND logprob_stddev 0.5筛选样本2. 查看这些样本的Prompt模板ID确认是否混用了不同风格的模板3. 检查Router层的负载均衡策略是否将同一用户的多次请求路由到了不同版本的模型实例上根因是Router的sticky session会话保持未开启导致用户在A/B测试中被随机分配。方案强制开启基于user_id的sticky session并在评估报告中增加“用户一致性”指标同一用户连续5次请求使用相同模型版本的比例。现象2检索结果相关性突然下降- Reasoning TransparencyTop-1文档相似度P50从0.75骤降至0.45- Systemic Resilience检索组件的P95延迟从300ms飙升至2s1. 在Prometheus中查看检索服务的http_request_duration_seconds_bucket确认是否大量请求落入了le2的桶2. 在ClickHouse中SELECT doc_source, COUNT(*) FROM llm_events WHERE similarity 0.5 GROUP BY doc_source发现90%的低分文档来自legacy_db3. 检查legacy_db的连接池监控发现连接数耗尽根因legacy_db的连接池配置过小高并发下连接耗尽导致检索服务降级到一个低质量的备用索引。方案立即扩容连接池并在评估函数中增加“降级来源”字段让evaluate_retrieval能自动区分主索引和降级索引的效果。现象3工具调用频繁失败但错误码都是200- Reasoning Transparencytool_call_input中包含大量{timeout: 3000}而tool_call_output中status为timeout- Output Fidelity最终答案中频繁出现“我无法访问该系统请稍后再试”1. 在Neo4j中运行CypherMATCH (t:ToolCall) WHERE t.status timeout RETURN t.tool_name, count(*) ORDER BY count(*) DESC锁定问题工具2. 查看该工具的上游API监控发现其P99延迟超标3. 检查Agent的工具调用逻辑发现其timeout参数硬编码为3000ms而上游API的P99是3500ms根因工具调用的超时阈值设置不合理且未实现指数退避重试。方案将超时阈值改为上游API的P99 * 1.5并在工具调用封装层加入指数退避Exponential Backoff逻辑。现象4答案中出现大量重复内容Repetition- Reasoning Transparencylogprobs显示在重复段落的起始token处logprob异常高模型“过于自信”- Input IntegrityQuery中包含大量重复的关键词如用户反复输入“重要重要重要”1. 在ClickHouse中SELECT query, response FROM llm_events WHERE response LIKE %重要重要重要%确认Query特征2. 分析该Query的tokenization发现重要被分成了[重要, , 重要, , 重要, ]导致模型在生成时过度关注该token3. 检查预处理Pipeline发现缺少“重复符号去重”步骤根因预处理缺失导致模型被噪声token干扰。方案在Router层增加一个轻量级的“Query净化”步骤使用正则re.sub(r([^\w\s])\1{2,}, r\1, query)将连续3个以上的标点符号压缩为1个。现象5系统对新出现的术语如新药名、新法规完全无知- Input IntegrityQuery中包含的新术语在检索的context中完全未命中相似度为0- Reasoning TransparencyLLM在生成时对unktoken的logprob异常高1. 在Qdrant中用新术语的embedding进行搜索确认知识库中确实无匹配2. 检查知识库的更新流水线发现其ETL任务因上游数据源格式变更而失败已停摆3天3. 查看knowledge_update_statusPrometheus Gauge
