TriFleetRCA：面向 Kubernetes 的本地部署 LLM 根因分析

该论文提出 TriFleetRCA，一套在单张本地 GPU 上完整运行的 Kubernetes 根因分析流水线：按 pod、namespace、cluster 三种范围采集证据，先做模板去重再按 BM25 排序，并用 ingest guard 过滤 runbook。在活集群注入四类故障、以 Qwen2.5-14B-Instruct 温度 0 做 100 次分析，三种范围命中率为 0.85、0.90、0.95；去重使命中率从 0.75 升至 0.90，且 token 成本不变。

此前远程站点的根因分析受限于日志分散和不愿外传生产日志，而本地推理虽解除了外传约束，却在 GPU 同时限制模型与上下文预算时缺少活集群基准。该研究给出了可复现的实测数据，并把范围选择、证据排序和 runbook 投毒防护纳入同一评估。

单张 GPU 同时约束模型规模与上下文长度，因此关键不在模型能力而在证据工程：先用模板去重压掉重复日志，再以 BM25 在有限预算内排序，按 pod、namespace、cluster 逐级扩大范围。范围收益几乎全部来自一个故障，即其根因是集群级对象，而 cluster 范围 token 消耗高出 55%。

对运维产品和内部平台而言，这提示本地小模型加检索排序可支撑根因定位，不必把生产日志外送；证据检索层（去重加排序）是提升命中率的低成本手段，但不应默认扩大采集范围，因为范围收益可能被 token 成本抵消。

• 在日志检索层先做模板去重再做排序，把该步骤作为默认配置以提升命中率并保持 token 预算。
• 为 runbook 引入 ingest guard 过滤机制，并保留模型自身拒答作为第二道防线。
• 按故障根因所在层级动态选择采集范围，而非一律使用 cluster 范围以控制 token 成本。
• 在评估中把引用质量与答案准确率分开度量，避免只看命中率掩盖证据错误。

• 该结果是否在不同模型、不同集群规模或不同故障类型下可复现？
• 除四类注入故障外，真实生产环境中的未知故障表现如何？
• ingest guard 对更隐蔽或改写式投毒 runbook 的拦截效果是否仍成立？
• 文中被截断的引用质量与准确率分离结论具体说明了什么？