技术深度解析
Kelet的架构代表了传统应用性能监控（APM）与LLM专用诊断智能的复杂融合。其核心是一个多阶段分析流水线。首先，系统从LLM应用栈中摄取结构化遥测数据，包括每个请求的元数据（使用的模型、提示令牌数、补全令牌数、延迟、成本）、实际的提示-补全对，以及用于智能体工作流的思维链或工具调用序列。这些数据被索引并存储在一个为时间和语义搜索优化的向量数据库中。
第二层摄取来自用户环境的“真实情况”信号。这些包括显式反馈（点赞/点踩、评分）、隐式行为信号（消息编辑、会话放弃、表明困惑的后续问题）以及业务指标（AI交互后转化率下降、支持工单升级）。Kelet的关键技术创新在于其关联引擎，该引擎使用统计分析和机器学习来识别遥测异常与负面用户信号之间的模式。
在底层，关联引擎可能采用了以下几种技术：
1. 遥测数据异常检测：使用如孤立森林或自编码器等算法，识别延迟、令牌使用量或成本模式中的异常值。
2. 故障语义聚类：将提示-补全对进行向量嵌入，并使用聚类算法（如DBSCAN、HDBSCAN）对相似的故障模式进行分组。
3. 因果推断模型：应用贝叶斯网络或倾向得分匹配等方法，建立应用状态与负面结果之间可能的因果关系，而不仅仅是相关性。
4. LLM即法官集成：使用次要的、可能能力更强的LLM，依据检索到的证据或既定准则来评估主模型输出的质量，从而为监督学习故障模式创建带标签的数据集。
该领域一个相关的开源项目是Arize AI的Phoenix，它提供了LLM追踪、评估和监控能力。其GitHub仓库（`arize-ai/phoenix`）已获得超过3200颗星，提供了嵌入漂移检测、LLM评估套件和追踪数据可视化等功能。虽然Phoenix在根因分析的自动化程度上不如Kelet的目标那样高，但它代表了构建更高级诊断系统的基础工具。
| 诊断维度 | 传统APM | LLM专用工具（如Phoenix） | 高级根因分析（Kelet目标） |
|---|---|---|---|
| 主要数据 | 日志、指标、追踪 | LLM追踪、嵌入向量、评估结果 | LLM追踪 + 用户行为信号 |
| 故障检测 | 错误代码、延迟峰值 | 质量评分、幻觉检测 | 质量衰减与因果因素的关联分析 |
| 根因分析 | 服务依赖关系映射 | 提示/响应模式分析 | 多信号因果推断 |
| 自动化水平 | 中等（告警） | 中等（评估） | 高（自动化假设生成） |
数据要点：该表格展示了从通用监控到专用LLM可观测性，再到自动化诊断的演进过程。像Kelet这类工具的关键区别在于集成了外部用户信号，这提供了必要的“真实情况”，从而能够从观察异常转向理解其影响和原因。
主要参与者与案例研究
LLM可观测性与诊断市场正在迅速成型，并出现了几种不同的方法。Weights & Biases (W&B) 已将其MLOps平台扩展，加入了LLM评估和追踪功能，利用了其在机器学习团队中的强势地位。Arize AI 通过其Phoenix产品，已显著转向LLM可观测性领域。Langfuse 和 LangSmith（来自LangChain）专门为LLM链和智能体提供深度追踪和调试功能，其中LangSmith与流行的LangChain框架集成尤为紧密。
Kelet似乎通过专注于静默失败问题和自动化根因分析（RCA），而非仅仅是追踪或评估，来确立自己的差异化定位。其最接近的竞争对手可能是Gantry，后者专注于LLM应用的持续评估和反馈集成。然而，Gantry的方法更侧重于数据管理和评估，而Kelet则强调诊断自动化。
早期企业部署中的一个案例可以说明对此类工具的需求。一家大型金融服务公司部署了一个基于GPT-4的客户服务聊天机器人。该机器人在测试中表现优异，但部署后，数字服务渠道的客户满意度在六周内开始出现无法解释的逐步下降。手动调查揭示了问题所在：模型逐渐形成了一种倾向，即给出过于谨慎、充满法律免责声明的回答，导致客户感到沮丧并放弃对话。由于没有明确的错误日志，这个问题在数周内都未被发现，直到对客户行为数据进行深入分析后才得以暴露。这个案例凸显了传统监控在应对LLM输出质量“渐变”或“漂移”时的不足，以及将用户行为信号与模型内部遥测数据关联起来的必要性。