容器集群延迟与资源成本的取舍把检索和模型能力用于 Kubernetes 排障成本不只来自一次模型调用。日志采集、索引、上下文拼装、缓存、并发请求和人工复核都会占用资源。若每个告警都把大段原始日志送入模型系统可能在最需要稳定的时候制造额外负载还会让敏感数据暴露面扩大。优化前先分清服务目标是缩短值班人员找到证据的时间还是让模型直接给出根因前者通常更可控。模型可以帮助归类、解释和检索但输出应被当作待验证的假设不能直接转成扩容、重启或修改资源限制的命令。让上下文有来源、预算和边界排障请求可以按时间窗口、命名空间、工作负载和错误类型收集材料。优先传入结构化且与当前事件相关的信息请求错误率、重启原因、资源 requests 与 limits、近期事件、少量相关日志片段和链接。原始日志不应无选择地拼接其中可能包含用户数据、令牌或内部地址进入外部模型前还需执行脱敏和访问审计。“按字符数截断”只能控制文本大小不能准确估算不同模型的 token 数也可能切断关键堆栈。更好的做法是为每类来源制定优先级保留最新且已关联的错误片段保留指标的时间序列摘要记录被省略内容的来源链接。超过预算时返回“证据不足”让使用者继续缩小范围而不是让模型根据残缺材料给出确定答案。缓存也应以问题的稳定性为前提。Pod 名称、日志前缀和事件摘要会随时间变化简单拼接后做哈希可能把不同故障混为一谈或把过期建议用于新的版本。缓存键至少要包含工作负载版本、时间窗口、查询条件和规范化后的特征命中结果应显示生成时间与证据来源并允许用户强制刷新。from dataclasses import dataclass dataclass(frozenTrue) class Evidence: workload: str version: str window_start: str error_summary: str metric_links: tuple[str, ...] def build_question(evidence: Evidence, max_chars: int) - str: text ( f工作负载: {evidence.workload}\n版本: {evidence.version}\n f时间窗口: {evidence.window_start}\n错误摘要: {evidence.error_summary}\n f指标链接: {, .join(evidence.metric_links)}\n 请列出需要验证的假设不要建议执行变更。 ) if len(text) max_chars: raise ValueError(证据超过预算需要先缩小查询范围) return text示例刻意拒绝静默截断。排障时宁可请求更精确的范围也不要让系统在不完整材料上生成看似合理的建议。用测量决定容量与费用延迟应按阶段拆分取数、检索、上下文构造、模型首字节、完整响应和前端呈现。成本则至少包含索引写入、存储、模型输入输出、缓存命中与人工复核时间。比较方案时固定数据集、并发、缓存冷热状态和模型版本并报告样本量与失败请求一次压测中的单个 P99 不能代表线上长期表现。如果模型服务或向量检索变慢首先限制并发、合并重复告警、排队并设置取消传播。关键用户路径不能与长时间诊断任务争用同一个队列和资源池。系统超出预算时应提供延迟较低的确定性摘要或只读仪表盘入口而不是继续堆积请求。最后验证建议质量而不只看速度。抽取有已知结论的历史案例由具备领域知识的人检查模型是否引用了正确证据、是否承认不确定性、是否避免给出高风险动作。将错误分类回写到检索与提示设计中才能在控制成本的同时提高排障辅助的可信度。