修复 Mastra 中的 AI 可观测性
OpenTelemetry 是现代系统监控的标准。传统的链路追踪（traces）适用于大多数软件，但在 AI 应用中却会失效。
在构建 AI 时，你需要得到具体的答案： • 哪个模型生成了输出？ • 你使用了哪个供应商？ • 消耗了多少 token？ • 哪个 embedding 模型处理了你的文档？ • 该操作的成本是多少？
这些问题在检索增强生成（RAG）系统中最为关键。
在为 Mastra 贡献代码时，我发现了 RAG embedding 可观测性方面的空白。Mastra 为许多 AI 任务导出了元数据，但 RAG embedding span 却缺乏标准属性。
可观测性工具能看到 embedding 操作，但无法理解其上下文。它们遗漏了模型详情、供应商信息和 token 使用情况。
RAG 流水线遵循以下步骤： • 文档 (Documents) • 分块 (Chunking) • Embedding 模型 • 向量数据库 (Vector Database) • 相似度搜索 (Similarity Search) • LLM 生成
Embedding 阶段至关重要。如果此处缺乏数据，性能调试将会变得非常困难。
OpenTelemetry 使用语义规范（semantic conventions）来创建通用语言。与其让每个工具都使用自定义名称，不如让大家遵循同一个标准。这使得工具能够读取如下属性：
• gen_ai.system
• gen_ai.request.model
• gen_ai.usage.input_tokens
我提交了一个 pull request，将 Mastra RAG embedding 数据映射到这些 OpenTelemetry 标准中。
工作内容包括： • 导出 embedding 模型元数据 • 导出供应商信息 • 映射 token 使用指标 • 使属性与全球标准保持一致
这使得可观测性系统无需编写自定义代码即可理解 embeddings。
生产环境中的 AI 系统需要可见性。你需要知道哪个模型导致了延迟，或者哪个供应商的成本最高。标准化的遥测（telemetry）会自动提供这些答案。
开源教会了我们一个深刻的道理：并非每一个优秀的贡献都是增加新功能。有时，最好的工作是让现有系统变得更容易监控和运行。
如果你在构建 AI 基础设施，请不要忽视可观测性。最优秀的 AI 系统都是可观测的。
可选学习社区：https://t.me/GyaanSetuAi