Braintrust 创始人 Ankur Goyal 详解 Topics——用于大规模分析生产环境代理追踪的智能层，百万 token 的追踪包含数百个跨度，打破了所有期待统一文档形状的标准 NLP 工具。受 Anthropic 的 Clio 论文启发，该管道依次执行预处理、切面、嵌入、聚类、命名、分类，LLM 摘要只做一件事，却让其余步骤变得可行，因为原始追踪无需适配嵌入模型的上下文窗口。

我们如何实现大规模连续追踪智能

如果你在生产环境中运行代理，一天中的部分时间很可能花在翻阅无数生产日志上，看看是否有值得关注的内容。你知道其中藏着有价值的情报，但数据不会告诉你应该提出什么问题，或者用什么样的 SQL 查询能捕获它。

我们 Braintrust 团队长期思考这个问题，Topics 就是答案——它让你能以智能方式大规模分析追踪。和 Brainstore 一样，这是我们少数几个重大的、集中的技术赌注之一：完整掌控一个基础组件，而不是拼凑现成的零件。Brainstore 的赌注在存储和查询层，Topics 的赌注则在上层的智能层。

为了发现你本不知道要寻找的模式，你需要在这层智能上运行每一条追踪。我们称之为主动可观测性。问题是，LLM 追踪的形状与标准工具所期望的完全不同。标准 NLP 工具集假设文档形状和大小大致均匀。主题建模期望几百 token 的词袋文档。情感分析期望一个句子或段落。现成的嵌入聚类期望输入能塞进嵌入模型的上下文窗口。

代理追踪并非如此。一条生产追踪可能包含数百万 token 的对话历史、工具调用、中间推理、检索上下文和序列化的应用状态。它们以高量级到达，在“完成”后还会持续更新，而有趣的行为通常埋藏在数百个跨度中的几个里。如果你直接嵌入原始追踪，会得到由表面特征（如消息长度或工具名称频率）主导的噪声聚类。如果你先用 LLM 进行摘要，预算会爆炸。如果你激进地采样，就会漏掉长尾——而 bug 通常就藏在那里。

Topics 背后的灵感来自 Anthropic 的 Clio 论文。与其尝试嵌入或分类原始追踪，不如让 LLM 做一件事：用一两句话沿着单一维度总结追踪。然后嵌入这个摘要，对嵌入进行聚类，再通过第二次 LLM 传递为聚类命名。追踪本身永远不需要适应嵌入模型的上下文窗口，下游管道也无需了解任何关于代理、工具或 token 数量的信息。

这听起来像是一个小动作，架构上确实如此。但操作上，它改变了一切。一旦 LLM 摘要步骤存在，同样的下游管道就可以用于你关心的任何维度：任务、问题、情感，以及你为产品定义的自定义类别，都通过相同的嵌入、聚类、命名和分类阶段流动。

这个赌注引出了三个设计目标。首先，LLM 摘要步骤必须范围紧凑、对批量友好，且成本高效到足以在每条追踪上运行。该步骤的输出是一个切面（facet），它是整条管道构建的工作单元。其次，聚类生成必须足够快，可以在无需操作员干预的情况下临时运行，并且生成的主题映射必须足够稳定，使得跨运行的趋势分析有意义。第三，分类必须足够低成本以连续运行，这意味着分类时不能调用 LLM。

管道有六个阶段：预处理、切面、嵌入、聚类、命名和分类。预处理程序将原始追踪转换为 token。默认预处理程序遍历范围内的每个跨度，将每个跨度解析为 LLM 对话，跨跨度去重消息，并丢弃评分跨度。原始追踪可能巨大，因此输出硬限制为 128K token，之后才到达切面模型。

切面阶段是 LLM 完成其唯一任务的地方。每个切面都有一个提示，例如“用一句话总结用户试图完成什么”，以及一个输出模式。切面模型生成一个短文本块（通常是一两句话），并将其写回追踪。内置切面包括任务、情感和问题。自定义切面可以是任何内容，从用例到 SKU 分段。

这个阶段有一个对成本非常重要的优化。朴素实现会逐个计算切面，因此在一条追踪上运行五个切面大约需要五倍的追踪 token 加上五个切面提示。我们将切面批量处理到单个 LLM 调用中，因此成本是追踪 token 加上每个切面的边际提示 token。无论你运行多少个切面，追踪 token 只支付一次。

切面文本生成后，我们使用嵌入模型对其进行嵌入。这里要注意的是我们嵌入的是什么：切面输出，而不是原始追踪。这正是让管道其余部分可行的原因。一个一致、简短、切题的摘要能干净地嵌入。而一个百万 token 的代理追踪则不能。

一旦积累了足够多的切面嵌入，聚类阶段会在每次生成传递中对最多 50,000 个切面进行采样。默认算法是 HDBSCAN 配合 UMAP 进行降维。HDBSCAN 效果很好，因为它不需要你预先指定聚类数量，并且它会自然地将离群点识别为噪声，而不是强制将每个点归入某个聚类。对于每个聚类的关键词提取，我们使用 c-TF-IDF，与 BERTopic 推广的方法相同。

命名阶段会为每个聚类选取代表性的切面示例，并要求 LLM 生成一个简短的名称和描述。这是生成式的，意味着即使底层成员几乎不变，同一个聚类在下次生成传递时也可能获得略有不同的名称。这就是为什么我们将聚类（而非名称）视为稳定的身份。当生成新的主题映射时，我们会自动将相似的聚类与之前的匹配，并复用它们的 ID。

分类是轻量级部分。对于每条新追踪，我们运行预处理、切面和嵌入阶段，然后在保存的主题映射中查找最近的聚类中心。如果追踪在配置的距离阈值内，它就会被贴上标签。如果不是，则写入 no_match，而不是强行贴上错误的标签。分类时没有 LLM 调用。整个步骤每条追踪大约 100 毫秒。

结果以结构化数据的形式落在追踪上。从那时起，它就像日志中的任何其他列一样。你可以对其进行过滤、分组、跨主题映射连接、从 SQL 查询，或者设置告警。

Topics 的另一半是自动化层，它在后台连续运行管道。一个主题自动化从积累切面数据开始，然后重新计算主题映射，用新映射回填最近的追踪，然后进入空闲状态直到下一个计划运行。一个项目至少需要 400 条追踪才能启动 Topics，并且至少需要 100 个独特的切面摘要才能生成主题映射。低于这些数字，聚类没有意义，我们宁愿什么都不显示，也不展示噪声。

产品中有两个地方你会看到聚类。Topics 视图显示自动化的主题映射：同一组持久的聚类、相同的名称，一致地应用于你的日志。这是你用于趋势仪表板、告警以及需要在几天或几周内进行比较的分析时所需要的。“按切面聚类追踪”操作会对当前查看的任何子集执行临时聚类，参数针对探索调整。两个视图使用相同的管道。区别在于主题映射是持久化并复用，还是即时生成。

所有原生 Topics 推理都在 Baseten 上运行。切面模型看到的是上限为 128K token 的预处理文本，并剥离了附件和指标。嵌入模型只看到切面输出，永远不是原始追踪。聚类步骤处理的是嵌入和切面输出，而非原始追踪内容。Topics 推理可以在美国和欧盟托管，并且 Braintrust 符合 HIPAA 标准。

架构选择转化为一些你作为开发者能感受到的具体特性。管道连续运行，而不是批处理作业。输出是可查询的，而不仅仅在 UI 中可用。一条管道服务于你关心的每个维度。主题身份在重新生成时保持稳定。内置切面和默认预处理程序开箱即用，当你的追踪形状不寻常时，你可以放入自定义 JavaScript 预处理程序，返回你希望聚类的精确跨度。

Topics 是我们公开讨论过的第二个赌注，和 Brainstore 一样，随着我们产品的增长，它变得越来越有用。我们认为它是你可以在追踪上运行的最通用的智能基线层。我们正在构建的更昂贵、更强大的层就位于这个基线之上，并且我们认为随着生产 AI 工作负载变得越来越复杂，这种管道形状将继续有用。