回复@icefighter: ServiceNow 和 Datadog 是企业 IT 架构中两个至关重要但功能维度完全不同的平台。如果用医疗系统做比喻：Datadog 是 24 小时监护仪（实时监测心跳、血压），而 ServiceNow 是整个医院的病历管理与协作系统（挂号、分诊、开方、流程审批）。
以下从核心定位、功能重叠及协作关系三个维度进行深度拆解：
1. 核心定位：实时观测 vs. 流程管理
2. 详细对比：它们分别解决什么问题？Datadog：深耕“技术细节”Datadog 属于 APM（应用性能管理） 和 可观测性 领域。它通过采集海量数据来告诉你系统“发生了什么”：
实时监控： 监控云基础设施（AWS/Azure/K8s）的运行指标。
日志管理： 汇总成千上万个服务器的日志，快速检索故障点。
链路追踪： 看到一个用户请求是如何经过 A 数据库、B 接口、C 服务，并在哪里变慢的。
AI 告警： 自动识别异常波动并发出告警。
ServiceNow：深耕“业务流程”ServiceNow 属于 ITSM（IT 服务管理） 领域。它通过结构化的工单来告诉你系统故障后“该由谁、怎么做”：
事件/工单管理： 记录故障，指派给负责人，跟踪解决进度（SLA）。
资产管理 (CMDB)： 记录公司有多少服务器、笔记本电脑、软件授权。
变更管理： 如果要更新核心数据库，需要在 ServiceNow 里提交审批流程。
员工自助： 员工申请新电脑、入职流程审批都在这里完成。
3. 约束与交集：ITOM 领域的碰撞这两个工具在 ITOM（IT 运营管理） 领域有重叠，这也是最容易混淆的地方：
ServiceNow 有监控模块 (Cloud Observability)： 以前叫 LightStep，ServiceNow 试图向上游延伸，直接做监控。
Datadog 有事件管理 (Incident Management)： Datadog 试图向下游延伸，让工程师直接在 Datadog 里协作处理故障，而不用跳去 ServiceNow 开工单。
4. 协作关系：1 + 1 > 2在实际企业中，它们通常不是“二选一”，而是黄金搭档。典型的协作链条如下：
触发： Datadog 检测到数据库延迟过高，自动触发一个告警。
流转： Datadog 通过集成接口，自动在 ServiceNow 里创建一张“紧急事故工单”。
治理： 管理员在 ServiceNow 里看到工单，确认受影响的资产（CMDB），并根据流程指派给相应的专家组。
同步： 专家在 Datadog 里排查修复，ServiceNow 里的工单状态会实时同步更新。
总结建议如果你是初创公司或小型开发团队： 优先上 Datadog，因为你首先需要看到系统跑得稳不稳。
如果你是大型企业： ServiceNow 是地基，它解决了跨部门协作和合规性问题；然后再用 Datadog 这种深度工具来填补技术监控的空白。//@icefighter:回复@icefighter:我是 Oppenheimer 的 Ittai Kidron。Alexis，你的演讲非常有意思，谢谢你对“小模型 vs 前沿模型”做出的论证。
如果我们反过来思考：你们用 75 万美元就训练了一个高准确率的小模型。那么从第三方的角度来看，进入门槛在哪里？换句话说，AI 对你们业务的风险是什么？机会显而易见，收入潜力也明显，但风险在哪里？
⸻
Alexis Le-Quoc
联合创始人 & CTO
我认为，真正的护城河在于数据优势。
以我们的时间序列模型为例，我们拥有的是真实、合法、海量、非公开的数据。这是第一层优势。
第二层优势在于：我们构建 eval（评估集）的体量与质量。训练代理不仅仅是模型本身，而是大量真实场景验证。
确实，理论上没有明显的“资本门槛”。别人也可以做小模型。但数据质量才是关键护城河。
比如，在我们这个领域生成高质量合成数据并不容易。它不像文本生成图像那样简单采样、重混。软件系统的结构与运行行为之间关系极其复杂。你不能简单对某个大模型说：“给我一堆合成数据。”
此外，我们天然处在数据流的中心。客户日常使用 Datadog 产生的数据，本身就成为训练素材。这是别人无法轻易获得的。