一、概述 在当今数字化时代，动效设计已成为用户体验设计中不可或缺的一环。它不仅显著提升了用户体验，增强了用户粘性，还为业务带来了可观的收益。一个好的动效自然离不开专业且实用的动效设计工具，本文将为大家

重磅更新 btrace 是由字节跳动抖音基础技术团队自主研发的面向移动端的性能数据采集工具，它能够高效的助力移动端应用采集性能 Trace 数据，深入剖析代码的运行状况，进而辅助优化提升移动端应用的性

1、前言 随着大模型（Large Language Models, 以下简称LLM）迅猛发展的浪潮中，幻觉（Hallucination）问题逐渐成为业界和学术界关注的焦点。所谓模型幻觉，指的是模型在生

背景 抖音长期存在renderD128内存占用过多导致的虚拟内存OOM，且多次出现renderD128内存激增导致OOM指标严重劣化甚至发版熔断。因受限于闭源的GPU驱动、现场有效信息极少、线上线下的

虚拟索引技术（virtual index，也称为 hypothetical index）在数据库系统的查询优化、索引推荐等场景中扮演着关键角色。简单来说，虚拟索引可以理解为数据库的'沙盘推演'系统——

背景 在云原生调度中，一次调度往往无法解决所有问题，需要配合重调度来优化资源分配和任务摆放。传统的重调度框架主要集中在识别异常节点或任务，并通过迁移或删除来解决。然而，这些框架往往只能解决局部问题，无

字节跳动豆包大模型团队正式开源首个多语言类 SWE 数据集——Multi-SWE-bench，可用于评估和提升大模型 “自动修 Bug” 能力。 在 SWE-bench 基础上，Multi-SWE-b

DeepSeek-R1（以下简称 DeepSeek）以其优秀的复杂问题推理能力和规划能力脱颖而出，然而其原生函数调用（Function Call）功能的缺失，无法让大模型去选择不同的工具和程序，以获取

在AI编程工具高速发展的今天，Cursor、Trae等工具凭借自然语言生成代码、跨语言支持等能力，极大提升了开发效率。 工具生成的代码注重功能实现。打造一款受欢迎的产品，有了能实现功能的代码并不够，还

随着 LLaMA、DeepSeek、Qwen 等开源大模型的快速崛起，企业在模型部署的灵活性、成本与自主可控性方面迎来了新的机遇。然而，仅靠对模型本身的优化尚不足以将这些模型部署成高效且可扩展的生产级

简介 vArmor 是字节跳动开源的云原生容器沙箱系统，它借助 Linux 的 AppArmor LSM，BPF LSM 和 Seccomp 技术进行容器加固。用户可以通过 vArmor 的 CRD

近日，豆包大模型团队开源 SuperGPQA，一个领域全面且具备高区分度的知识推理基准测试。

该数据集构建了覆盖 285 个研究生级学科、包含 26529 道专业问题的评估体系，不仅涵盖主流学科，更将轻工业、农业、服务科学等长尾学科纳入其中，展现出全面学科的覆盖广度，填补了长尾知识评估领域的空白。

如今，SuperGPQA 已被用于揭示开源模型与闭源方案之间的显著性能差距，为 AI 发展提供了关键评估工具和跨学科分析框架。

随着大语言模型在通用学科中的表现逐渐接近人类水平，研究焦点也随之转向其在真实世界专业领域的应用。然而涉及人类研究领域的长尾学科时，由于有效评估的缺乏，LLM 的能力边界依然模糊不清。

为了全面衡量 LLM 的泛化能力与推理上限，字节跳动豆包大模型团队联合 M-A-P 开源社区推出基准测试 SuperGPQA，这一基准不仅覆盖了二百余个研究生级学科，还确保 42.33% 的题目需要数学计算或形式推理，构建了兼具广泛学科覆盖与复杂问题设计的评估新范式。

实验结果显示，DeepSeek-R1 在 SuperGPQA 上的准确率为 61.82%，在不同知识领域中，当前大语言模型性能仍有很大提升空间，这也进一步凸显 SuperGPQA 在评估模型真实能力方面的重要性和必要性。

⽬前论⽂成果和数据代码仓库均已对外公开，欢迎开源使用！

SuperGPQA: Scaling LLM Evaluation across 285 Graduate Disciplines

论文链接： arxiv.org/pdf/2502.14…

数据链接： huggingface.co/datasets/m-…

代码链接： github.com/SuperGPQA/S…

1. 现有评测基准学科占比失衡，长尾学科覆盖不足 5%

现有大语言模型评估体系主要面临两大核心困境：学科覆盖的严重失衡与评测基准的挑战性失效。

以 MMLU 和 GPQA 为代表的传统基准尽管在数学、物理等主流学科中建立了标准化测试框架，但其覆盖的学科数量通常不足 50 个，仅占人类知识体系的冰山一角。据统计，现有基准对轻工业、农业、服务科学等长尾学科的覆盖率甚至不足 5%。

多基准多维度对比雷达图

不同基准下最新模型的性能对比

更为严峻的是，现有评测体系失去区分度，无法有效衡量模型在真实复杂场景中的推理上限。比如，主流模型如 GPT-4o、DeepSeek-R1 在传统基准上准确率已突破 90%。

这主要源于传统基准构建范式的单一化数据来源与粗放化质量筛选。比如，不加辨别地依赖教科书例题或在线题库（例如 GPQA 中 42% 的问题来自维基百科），导致题目缺乏专业深度，且易被模型通过记忆机制 “破解”。实验发现，GPT-4o 对在线练习网站答案的重复率高达 67.3%，暗示其性能提升可能源于题目数据泄露而非真实推理能力。

此外，众包标注的专业水平参差和主观性问题评估难度进一步加剧了基准的不可靠性——早期尝试中，仅 37% 的众包标注问题通过专家审核，导致超过 60% 的标注资源浪费。

这使得我们无法准确评估模型的泛化能力和推理能力，严重阻碍了模型性能的进一步提升。

2. 首次全覆盖 285 个学科，探索 LLMs 真实能力边界

为突破以上限制，豆包大模型团队和 M-A-P 历时半年推出 SuperGPQA，一项全面的基准测试，实现 285 个研究生级学科全覆盖，旨在探索最先进的大语言模型潜力边界。

• 全面学科覆盖 ： SuperGPQA 覆盖 13 个门类、72 个一级学科和 285 个二级学科，共 26,529 个问题，远超现有的 GPQA（448 题）和 MMLU-Pro（12,032 题），平均每题将会提供 9.67 个选项，挑战性显著高于传统的 4 选项格式。同时，它突破传统评测集仅侧重 STEM 学科的局限，兼顾科学、工程、医学等 STEM 学科与哲学、文学、历史等非 STEM 学科问题，且具有较高区分度。

• 多样的难度分布： 问题难度在各学科间均衡分布，尤其在工程和科学领域，难题比例较高。42.33% 的问题需要数学计算或严谨推理，确保模型在高难度任务中的表现。

• 丰富的语义结构： 通过 t-SNE 可视化，评测集 SuperGPQA 展示了跨学科的聚类模式，工程和科学类问题在语义上高度相似，人文学科则保持独特的知识中心，体现了领域特定的语言特色。

• 一致的题目设计： 平均问题长度为 58.42 字，选项长度一致，增强了迷惑性和挑战性，确保评测的公平性与可靠性。

3. 专家 - LLM 协同，提高题库质量

SuperGPQA 的核心架构由三个关键阶段组成：源筛选、转录和质量检验。该过程涉及 80 多名专家标注员、交互式专家 - LLM 协作系统，为未来类似规模的研究项目提供了方法指导。

SuperGPQA 数据收集处理流程

• 源筛选

为确保题目的高标准质量，团队摒弃了众包注释员收集资源的方式，转而由专家注释员负责从可信来源（如教科书和权威练习网站）筛选和收集原始问题，并要求提供来源截图。这一策略避免了早期大量无效问题的产生，提升了质量检查的效率和准确性。

• 转录

在转录阶段，专家注释员对收集的原始问题进行语言规范化和格式转换，确保所有问题具备统一的学术语言和标准的多项选择题格式。团队发现，即使是最先进的语言模型（LLMs）在生成干扰项时也存在漏洞，因此需要专家统一重写，以提高干扰项的准确性和有效性，确保题目的挑战性和区分度。

• 质量检验

团队在质量检验阶段采用三层检查机制，以保证数据集的整体质量：

1）基于规则的初步过滤： 识别并过滤格式明显不合规范的题目。

2）基于 LLM 的质量检查： 利用多个先进的 LLMs，如 GPT-4、Gemini-flash 等，进行有效性、负面和极端询问检测、多模态排除、领域相关性评估和区分度标记。通过多模型协作，不仅提升效率，还降低数据泄漏风险。

3）专家复审： 由专家注释员对可疑题目进行二次审核，确保最终题库的高可靠性和高区分度。

4. 最优推理模型仍有进步空间

发布评测基准的同时，研究团队也基于 SuperGPQA 对全球 6 个推理模型、28 个聊天模型和 17 个基础模型进行了评测，涵盖闭源、开源和完全开源三类模型。

其中，推理模型和聊天模型采用零样本评估，基础模型采用五样本评估（方法与 MMLU-Pro 类似），并将温度参数设置为 0，推理模型最大生成 token 数为 32K，其他模型为 4K。

我们的实验结果表明，在不同的知识领域中，当前最先进的大语言模型性能仍有很大提升空间，如当前最优模型 DeepSeek-R1 在 SuperGPQA 上的准确率仅为 61.82%。具体评测结果如下图所示：

LLMs 在不同划分层级的表现

LLMs 在不同学科的表现

• 指令微调显著提升性****能

DeepSeek-V3 和 Qwen2.5-72B-Instruct 的得分（47.40 和 40.75），远超其基础版本得分（32.14 和 34.33），验证了指令微调的有效性。

• 大模型表现更均衡

DeepSeek-R1 在简单（63.59）、中等（63.63）和困难（56.87）题目上均表现优异。相比之下，Qwen2.5-14B-Instruct 在同类别题目上的表现差距较大（44.82、37.90、19.97）。

• 推理模型训练范式仍有待优化

DeepSeek-R1 与 DeepSeek-R1-Zero 性能差距不大，尤其在科学与工程领域，后者稍占优势，表明最佳训练方法尚未确定。

• 预训练语料库的持续优化

LLM 系列如 Qwen-max、GPT-4o 模型系列在 SuperGPQA 上的表现随着时间显著提升，显示开发者高度重视长期知识的融入。

• 开源模型面临挑战

尽管透明 LLM 如 MAP-Neo-7B 和 OLMo-2-1124-13B 表现尚可，但与业界的非透明开源和闭源模型相比，尤其在困难题上仍显不足。

• 不同能力的模型表现差异

其中，Doubao-1.5-pro 以 55.09% 的准确率在 Chat Models 中位列第一，我们发现，通用大语言模型（如 Doubao 系列）在常见专业问题的知识回忆方面表现不错，但在长尾领域的推理方面存在困难。

o3-mini 系列在简单和中等难度题目的分数低于 Doubao-1.5-pro ，但在困难问题上却明显超过它，说明推理模型在难题上表现突出，却在广度知识覆盖方面存在不足。

5. 历时半年，探索模型真实能力边界

SuperGPQA 评测集搭建历时半年，近百位学界学者及硕博同学、业界工程师参与标注。通过 LLM - 专家协作的构建流程、285 学科全面覆盖和多样难度分布设计，SuperGPQA 填补了长尾领域专业评估的空白，有望成为衡量 LLM 泛化能力与推理上限的关键工具。

其实验结果不仅揭示了当前模型能力与通用人工智能之间仍存在巨大差距，也为 AGI 发展提供了跨学科分析框架。未来我们也将进一步扩展数据集范围、改进人类与模型协作标注模式，以应对快速演进的人工智能技术挑战。

作者：Data-TnS-Engineering-FE 团队

前言

曾几何时，代码敲击声回荡在深夜的办公室，你是否也曾幻想过有一个全能助手替你分担工作？如今，这个美好的愿景不再是空中楼阁。

想象一下，当你正为产品设计苦思冥想时，突然耳边传来 AI 的灵感火花；

在开发过程中，AI 像是个比你还了解自己的最佳拍档，为你提供独到的建议；

当繁琐的测试工作如排山倒海而来，它早已帮你先行解决那些隐秘的 Bug；

交付环节则如同一个老练的质检专家，在每一个细节上都帮你擦亮眼睛；

而在运维阶段，它更是你的“夜间守卫者”，早早预警潜在问题；

有人说，AI 的到来让开发者的身份发生了质的飞跃，从“头发稀疏的代码独行侠”变成了“开挂勇士”。在 AI 的协助下，谁不想在产品设计上满怀创意、在代码编写上行云流水、在测试中无懈可击，在运维中高枕无忧呢？

在这个充满奇思妙想的科技时代，AI 既是你的忠实伙伴，又是你的全能助手，更是一位风趣的导师。它不知疲倦地助你不断攀登职业高峰，让每一步开发都像是一场精彩绝伦的探险。是时候跳出你的舒适区，体验 AI 如何点亮开发者们的星辰大海。

准备好了吗？接下来，我们将揭开这段 AI 助力开发的奇妙旅程，从产品设计到运维管理，为你重新定义“效率”、“质量”和“体验”。 每一刻都充满了独特的惊喜和乐趣，相信这将是一段你不想错过的神奇之旅。让我们一起踏上这段充满无限可能的旅程，重新发现开发的独特魅力与无穷乐趣。

“在 AI 的魔法世界里，开发者不再是孤军奋战的英雄”

助力业务发展

随着 LLM 能力的迭代和更新，越来越多过去 LLM 无法很好解决的问题重新进入了大家的视野。在人审领域下人们一般都会围绕着 LLM 是否可以完全替代审核员对内容进行审核进行讨论与探索。在进一步进行详细的 LLM 赋能人工审核流程相关的例子前我们需要先了解一下“人类审核员”面对的一些挑战和要求：

• 能处理复杂的内容（e.g.可能既可以是 A，也可以是 B，还可以是 C）并给出最合适的答案
• 质量 & 稳定性：对于相同类型的内容要给出相同的结果
• 效率：在不损伤质量的前提下需要达成一些数量上的要求

先说结论目前 LLM 的能力还无法完全替代审核员，更多的是在各方面提供辅助从而提升审核员的审核质量和效率。所以在产品结合的思路上，我们主要关注在如何利用 LLM 简化或加速审核员对于单一任务的操作并完成了一些功能的落地。

前置思考

说到 LLM 最出名的当属于 ChatGPT 了，如 GPT-4o

当我们思考 LLM 能为审核员带来什么样的辅助时我们首先想到的就是如何利用这些现有的天花板模型。这些模型一般都有良好的指令执行能力，并且在处理一些通用文字相关的问题时一般具有非常好的表现。

例如我们可以提供一段文字内容给模型，并告诉模型我们希望它帮助我们从中提取出不符合某些规则的内容如：潜在的语言攻击，歧视内容，潜在色情内容等等。

当有了模型识别出来的内容后可以通过一些特殊的形式展示这些信息如高亮等。 这可以帮助审核员在审核过程中快速捕捉到内容中存在的潜在风险并加速其对当前内容的审核。听起来是不是很简单？实际上将一个如此简单的辅助能力从离线验证到最终上线需要考虑的远远不止这些：

• 成本：模型是以 token 来进行计算的。一段文字会先被转换成 token 然后再传给模型，同时模型输出的也是一堆 token 然后会再被转换成我们看得懂的语言。所以如何无损高效的压缩传给模型的内容是一个非常重要的课题。（如删除重复的内容等）
• 合规：因为模型在迭代过程中需要大量的训练数据，厂商都会收集模型在实际使用过程中的数据以补充其训练数据集。如果将一些敏感或隐私数据不经过处理的直接传给模型可能会带来合规风险。（如公司的保密数据，或者用户的不公开信息等）我们可不希望当其他人问模型你的银行卡密码时模型能准确无误的回答上来hhh。
• 时延：模型能力强大是有取舍的。可以姑且先理解为（在计算资源不变的前提下）模型的规模越大->模型的能力越强 -> 每次回答你问题的速度就越慢。同时给模型输入越多时返回的时长也会相应的延长。
• 其他 n+ 问题：服务可用性，模型拒绝回答，模型选型等等...

但是由于模型能力的局限性，我们只能对标准文字内容审核提供符合标准的辅助能力。那对于像视频或者音频中出现的文字，或者话语或者一些复杂的问题怎么办？

例如我们想对于一个歌曲中的歌词进行风险识别。

这个时候我们就要引入分步的解决思路，歌曲中歌词的风险识别可以被拆分成如下工作流

暂时无法在飞书文档外展示此内容

举例来说，在预处理环节我们可能会需要对 ASR 转换的文字内容进行整理如加入标点符号，分句断句等。模型对于长文字内容的处理能力会随着内容变长而下降。我们需要根据业务的诉求和实际情况进行灵活调整。抛去 ASR 环节不说，后边三步可以有两种实现思路：

1. 在一个 Prompt 中通过分步的方式指导模型进行处理

   1. 会更好的保留整体的上下文，但是可能会碰到如内容太长超出 context window size 的情况并且随着内容的变长模型的完成时间也会变慢。

2. 将每一步拆分开然后通过串行调用的方式完成多次模型调用。

   1. 可能会丢失一些上下文内容，但是因为进行拆分后每一部分的长度都是相近的所以在模型响应时长和 context window 上限的问题上则有比较好的表现。

如果我们想让模型帮我们翻译火星文呢（没办法，业务上就是有这个诉求 hhh）

对于一些有高定制化诉求的场景普遍厂商也会开放对现有模型就行二次训练的能力。比如对于将内容从 A 语言翻译到B 语言并且对语言风格/用词有明确需求时，可以考虑对基本模型做一次 SFT（Supervised Fine Tuning） 。也就是对自身特殊诉求收集数据集并使用这个数据集对模型进行二次训练以达到更好的表现。

如果你说识别什么的还是太复杂了，有没有更简单的应用场景？

在实际产品开发过程中，我们经常性的需要对圈定/给定的一组数据进行频繁的离线验证以确保目前的能力表现是符合我们预期的。又或者在产品迭代的过程中我们时常需要一个指标/分数来量化当前的能力/体验。举例来说，在进行多目标语言混合翻译的能力开发过程中，我们在 prompt enginnering 过程中需要时刻关注模型的表现并确保每一次修改都不会对能力造成较大的退步。Multidimensional Quality Metrics (MQM) 是一个多维度指标翻译质量分析框架。我们可以通过自然语言的方式向模型输入我们的对于（译文与原文对比）不同维度上的要求如：

• 翻译准确性

  • 是否丢失一些信息
  • 是否凭空捏造了一些信息
  • 翻译错误/未准确翻译
  • 未翻译
  • ...

• 流畅度

  • 语法是否正确
  • 标点是否正确
  • 拼写
  • ...

• 风格

  • 是否用了一些抽象的词

  • 是否是正式文风

  • ...

得益于 LLM 优秀的自然语言处理能力和跨语言能力，LLM 可以基于我们输入的多个维度来对译文进行评估并最终给出评估结果。需要注意的是为了保证模型输出结果的准确性我们一般不会直接要求模型输出如：0-10 分的打分。我们会尽量让模型在一个给定的状态下进行枚举。如：严重程度（严重， 普通， 可忽略不计）并通过代码对枚举进行映射后计算出最终的得分。这样可以最大程度上避免 LLM 输出不稳定和幻觉等问题。

实际上 MQM 这种多维度评估体系也可以应用在翻译之外的领域，如润色、故事生成等。甚至可以被用在图片打分。他们背后的原理都是类似的，都是通过发挥 LLM 出色的自然语言理解能力 + 通过自然语言描述框架来实现一些复杂的打分工作。

功能落地

上边我们只是利用了 LLM 的自然语言处理能力。如果我们想让模型帮我们回答一些不是通识性知识点的问题时该怎么办呢？

暂时无法在飞书文档外展示此内容

模型也可以像人一样，碰到不会的东西时可以先去查询然后再基于查询结果进行判断和回答。

比如说我们想为审核员提供一个问答机器人回答一些审核领域相关的问题，或者基于以往的审核结果进行回答。

又或者我们想基于某一个数据库中的结果对审核员的问题进行回答

但是对于不同类型的内容，知识库在生产过程中采用的分割策略，结构等会大大影响最终问答质量的表现。如：

• Chunking: 如当对于大段内容进行拆分时要拆分的多细，拆分后的信息是否应该保留整体上下文方便后续参考时使用等。
• Embedding Model: 需要针对需要支持的语言来选择向量化模型，不同的模型在召回准确度上也有不小的区别。

当我们检索到的相关知识后可以通过将这些信息连同原始问题一并作为输入给模型并让模型基于相关知识点尝试回答。

当我们积累了一系列能力后，如果快速的向其他方向上推广和扩展？

随着越来越多基于 LLM 能力的需求落地，我们发现其实所有的 LLM 能力都可以被总结为：一个带顺序的分步流程。其中模型调用只是工作流中的一个步骤/节点。如果我们能快速的复用这个分步流程就可以快速的对取得成功的能力进行推广。

（分步流程可视化示意图）

随着我们对现有的一些优秀 LLM 编排能力库/平台的深入了解，我们发现现有的方案都无法很好的对我们的业务场景提供100%的支持。甚至大多数都无法通过合规这一环节。更不用说可能业务有自己的模型、数据库、基础能力等等。我们需要在业务下实现一套定制的流程引擎。

流程引擎本质上可以被拆解为一下两种图的类型：

• DAG 有向无环图。一般用作承载经典 Workflow 场景。需要注意的是这种图不能包含循环所以一般被用作实现单一 Agent 能力。
• FSM 有限状态机。用作实现如 Multi-Agent 场景或有环的场景。是 DAG 的一个补充。但是需要注意的是因为状态机同时之后有一个激活状态所以并发分支等能力无法通过 FSM 实现。

当我们实现了上述两种流程引擎后可以进行组合实现更复杂的能力如：FSM 中嵌套 DAG，DAG 中嵌套 FSM 等等。

当我们有了上述流程引擎和对应的 DSL 之后。我们就可以在业务间快速复用能力（只要复制一下 DSL 或基于现有的 DSL 做二次开发就好了）。

可能你会问，为什么不根据需求直接把这些逻辑写在代码里呢？实际上在日常开发过程中我们发现大部分功能都是通过对有限能力的组合来实现的。如果不做流程引擎的建设会带来很大效率上的降低以及多余的开发量。

其他实践

Hornbill 是内部用于多个平台的 Oncall 工单管理工具，拥有三种升级策略。我们处理工单的团队包括用户运营团队和研发工程师，并在创建工单时自动拉入相关人员进行协作。由于审核员需要快速处理大量审核任务，Hornbill 通过 24 小时的用户运营团队快速解决问题，技术问题会被升级至研发解决。

Hornbill SDK 可整合到平台中，帮助用户在提交工单前通过 FAQ 寻找解决方案，从而减少不必要的工单。每周约有 几百个由用户运营团队处理的工单，因此减少工单数量可以让团队将时间用于更高价值的任务。

为了提高工单解决的效率并减少工单数量，我们引入了 AI 功能。

首先，相似工单检测能够有效识别并链接具有相同问题的工单，通过创建问题描述的嵌入向量，并使用向量相似性计算如余弦相似度，系统在用户提交新工单时可提示已有相似工单，推荐用户加入现有工单而非新建，或在工单提交后提醒用户操作团队进行链接，从而减少重复工单处理的工作量。

其次，AI 摘要生成功能则通过自动生成问题的总结，在群聊中梳理出问题描述、原因和结论，提供给不同班次的用户操作团队以保持问题处理的一致性。这一功能通过将所有的群聊内容传递给大型语言模型生成总结，从而避免因班次交接导致的上下文丢失，提高工单解决的连续性和效率。这些先进的 AI 功能减少了用户操作团队在票务处理上的重复性工作，让他们能够将更多时间投入到更具价值的任务中，不仅提升了团队的工作效率，也提高了用户问题解决的速度和质量，为用户提供了更优质的体验。

另外，Hornbill SDK FAQ 搜索功能旨在解决用户自行反馈且可通过非技术知识解决问题的工单。 通过将常见问题生成 FAQ，用户可以搜索相关知识库，并根据输入查询定制 FAQ 内容，使其更易理解。方法是为常见的可自解决问题创建 FAQ，并对 FAQ 问题进行向量嵌入，将其存储在向量数据库中。当用户输入问题时，我们利用余弦相似度比对向量嵌入，以找到匹配的 FAQ，并通过大型语言模型总结 FAQ 内容，展示给用户。这一功能减少了不必要的工单，提升了用户的自助解决效率。

总结

当我们完成了对流程引擎的落地，同时在流程中有技巧性的使用 LLM。基本上领域下的产品/业务诉求都可以基于这一套框架来实现。LLM 除了可以为我们做分类，识别等功能以外也可以帮助我们做离线验证/数据评估等工作。 与可视化编排界面配合可以大幅降低使用门槛。对于一个想要使用 LLM 能力来实现业务诉求的业务方，不论是 PM 同学还是运营同学都可以进行尝试可以大大解决研发的人力缺口。

提升开发体验

AI 编程在今年有了比较大的发展，因为出现了 Cursor、Windsurf、v0、bolt.new 这些，在不同场景下，成为了能指数级提升生产力的工具。这不仅仅得益于越来越强的模型能力，也得益于许多在应用/交互上的创新与探索。

工具形态

传统工具的替代品

搜索、文档工具、设计稿代码生成工具等

多智能体自然语言编程

代表工具：gpt-pilot、gpt-engineer、MetaGPT

这类工具直接通过自然语言与一个多智能体系统进行交互，多智能体系统会在内部划分多个角色/任务，如：程序员/开发/调试、架构师/设计、产品经理/拆解、项目经理/任务管理等。

但这类工具要将整个工程从新建到功能推进完全交给智能体维护，用户只能通过指令和自然语言对话对工程进行控制，并且受限于上下文窗口，也无法构建复杂的平台系统。使得这些工具都没有办法用于程序员日常的生产和实际的项目里。只能作为非专业人士的玩具，或者 AI 研究的尝试。

blog.pythagora.ai/2023/09/04/…

github.com/geekan/Meta…

代码辅助工具

代表工具：Github Copilot、Continue.dev、MarsCode

以 continue.dev 为例，这类工具的核心功能大概就是上述几类：以代码块/文件为上下文 Chat、Tab 自动补全、选中代码块进行自然语言编辑、在聊天框中对代码块进行应用。

这些功能已经在开发中被普遍使用了，开源的模型、插件对这些功能的支持也非常成熟了，不同公司内部也有类似的解决方案。

好用，但还不够强大，伴随着这些功能的组合和深度优化，期待更具生产力的工具逐步被开发出来并具备商业价值。

🆕 复合型编程IDE/插件

代表工具：Cursor、Windsurf、Cline

暂时无法在飞书文档外展示此内容

Windsurf 的 Cascade 工具，与 Cursor 的 Composer 类似

暂时无法在飞书文档外展示此内容

在代码辅助工具的基础上进一步增强代码整合能力，包括：

• 能够有效汇总上下文
• 能够将代码块转化为文件变更，以支持同时编辑多个文件
• 能够管理AI批量编辑后文件的暂存状态，并灵活跳转到不同历史编辑版本

这些能力大大提高了使用体验和生产效率。

Cursor 在刚出来的时候也收获了大量非程序员以及博主们的力捧，但我们在日常使用中依然不多。主要还是因为无法直接用于我们日常工作的工程，但随着一些使用方法的探索，以及模型能力/上下文检索能力的进一步提升，越来越多的编程人员开始在日常工作中使用，以提升生产效率。

而下面的最佳实践也提供一种日常使用的工作流，该工作流基于文档，构建长期 AI 可维护的大型项目。

🆕 快速原型构建机

代表工具：v0、Bolt.New

其实和上面的 IDE 差不多，但更多的结合了 WebIDE 和 WebContainer 的优势。

常规的使用场景是：对于完全没有技术背景的角色来说，他们不知道如何为自己的需求创建一个工程并完成前期的原型验证工作，而这类 WebIDE 工具则提供了一个完美的平台让他们来得到一个可供开箱即用的工程原型。

在此之后，则可以将这个工程下载到本地，使用 Cursor 继续进行工程的后续维护和开发。

最佳实践

虽然新的工具将功能可用性提升了，但存在短板，需要结合一些使用的条件和方法：

• 需要应用一整套闭环的工作流。其重点在各种文档的记录上（项目记忆力），让人和文档交互，完善设计，才能最终让 LLM 能更好的结合上下文生产出可靠的代码。
• 不是所有场景都可以。逻辑性代码完全没问题，但无法还原视觉设计的细节。因此，在工作流中，通过 AI 完成逻辑代码的部分后，样式工作还得需要前端工程师来编写。
• 技术栈和工程结构有限制。需要选择用比较老，且主流的技术栈和版本，社区训练物料比较多。
• 合规和数据安全问题。

工作流

暂时无法在飞书文档外展示此内容

这个工作流以文档为核心，适时的对项目和变更进行总结，以便在新增需求的时候，工具可以获得足够且精简的上下文，来精确生成新需求所需要的设计和代码。这些文档包括：

1. 整个项目的描述，包括：项目简介、技术栈、文档结构、项目架构等全局信息
2. Feature 文档，以及每个 feature 的技术实现细节
3. 模块文档，在每个模块下，对于该模块代码的总结和索引

本质上讲，现阶段，如果我们将 AI Coding 工具拟人化，它有很多缺点：记忆力差，没有从代码仓库中持续积累特定于此仓库的经验，相当于每次找了一个新人来开发

所以，一个好的工具、开发者，应该是能够合理组织和提供一个指令足够的上下文的；一个完全适配的项目应该是，简单化模块化的原子能力 + 清晰的模块声明。类似于微前端、微服务这种组织形式可能更有利于文档的组织

未来展望

工作模式

这有一篇来自于红杉资本的文章（中文版）描述了他们对生成式AI发展的展望：

虽然我对这个发展路径以及时间节点存疑，但也同样让我在想，结合AI，未来的编程是怎么样的呢？什么样的目的、什么样的实现方式、什么样的产品形态呢？往大了想，这些都太难回答了

但在一些小点上，站在程序员的角度，还是有一些想象的：

• 近几年，就可以看见程序员的能力模型要求会有一些变化，更有 AI 辅助经验的，在生产力上会比纯手写更有优势

  • 就像在应用层，高级语言编程替代汇编语言（wiki： 编程语言世代）

• 语言本身的学习变得简单，当 JS 开发工程师想使用其他语言时，变得没什么门槛了

• 没有合规模型工具的公司，在生产力上会落后，人也一样

• 会出现便宜的 AI 辅助编程解决方案，例如：

  • 针对特定技术栈的小参数 LLM ，本地 32G 内存的笔记本，就可以足够提升生产力了

更远的未来，如果产品形态和生产方式发生质的改变：

• 那人可能可以专注于新的领域的扩展，而不用纠结于现有生产工具的熟练度了
• 模型越来越强大，实现这件事，真的可能会变成**「念咒语」**

工具链

现在的技术栈、工程化等方式还是基于人来建设的，但当 AI 编程占领主导之后，会有什么样的工具链来驱动呢？什么样的工具链对于 AI 编程更友好。

例如上面提到的最佳实践的工作流来说，整体围绕文档驱动，在生成文档的时候，我们也需要将项目代码转换成上下文提供给大语言模型，而 github.com/yamadashy/r… 就是一种可以将仓库代码打包成 LLM 上下文的工具。

这块还处于特别早期，因为具体的工作流还没有固化下来，但可以预见，会有越来越多的工具链产生。

推动测试进程

为什么做单元测试

LLM 生成单元测试代码，在 22 年底就已经取得了非常惊艳的效果：用例工整，分支覆盖详尽，mock 数据齐全。生成的用例如果可用，提交到仓库后会成为代码资产的一部分。如果用例有问题，这部分代码也不会直接影响到生产环境。所以，AI 单元测试是大语言模型第一次尝试落地工业生产环境的完美试验场景。

另外，单元测试本身就是研发环节中非常重要的一部分。全面的单元测试可以辅助发现很多变更引起的风险和问题。业界知名的开源软件必定包含大量自动化运行的单元测试，这在多人协作开发过程中至关重要。

我们在 23 年也尝试过使用 AI 生成单测。但是当时代码报错多、人工修复成本大，初步尝试的结果不尽如人意，于是暂且搁置了。24 年中，在业务痛点的驱使下，我们重启了 AI 单测的调研。这一次我们找到了新的角度，解决了报错多和人工修复成本大的问题，让大家看到了 AI 单测落地的可能性。

AI 单元测试效果如何

衡量标准

在讨论效果如何之前，首先要讨论如何衡量效果。怎样算效果好，怎样算不好？

在 23 年的调研中，我们没有具体的评判标准，只通过看到的结果得出一些主观判断。在 24 年的实践中，我们尝试以客观的评判标准为主，主观的感受为辅。

由于评判标准是为了服务于我们的目标，所以我们先花了点时间思考我们到底希望 AI 在单测这件事上做什么？我们希望通过引入 LLM，对编写单测提效，同时通过大量单测代码的引入，提高 bug 召回率，提升代码质量，减少线上bug。

基于这个目标，最终我们梳理出这样的指标体系：

• 核心指标：bug 召回率

• 准入指标：单测可执行率，单测覆盖率

• 过程指标：

  • 千行代码用例数、测试用例独立性
  • 单测执行时长
  • 项目渗透率、单测可维护性、研发接受度
  • 单测生成速度

实际效果

所以实际效果如何呢？

横向观测下，我们对比生成 case 数、case 可执行率以及单测覆盖率。大部分模型都基本满足了准入要求，小部分模型可能由于发布时间较早或提示词适配度低等工程原因，没有取得可用的表现。

在解决了一些难点问题后，我们在试点仓库做了推进。对于千行以下源码的小批量生成，单测可用率保持在 100%，覆盖率保持在 80% 左右。随着源码复杂度增加，可用率和覆盖率均略有下降，但整体表现已经进入了值得期待的状态。

除了客观数据，研发接受度（主观感受）也很重要。通过阅读我们看到，纯逻辑类函数 AI 可以做到考虑各种情形、针对特定情形 mock 数据并给出断言；React 组件 AI 可以做到考虑多种情况，并且试图在渲染的 dom 结构中寻找关键元素做断言，配合人工矫正生成部分快照可以低成本、高覆盖率完成单测编写；同时AI在边界条件测试上比人类更加严谨，也会通过函数名、注释等信息发现人类考虑不周之处。

从效率和 bug 召回的角度，我们都看到了希望，因此，我们开始在部门内推进 AI 单元测试。

为何会取得不错的效果

首先，我们标准化了基础设施，解决了一些基建问题。如果一类 case 有 3 种写法，那么我们选择其中一种我们最希望的写法让 AI 固定下来，同时帮 AI 打通任何调用 API 上的难题。

其次，人类程序员要懂单元测试。比如 Arrange-Act-Assert 单测组织方式，如何 mock 数据，如何模拟交互，如何合理断言等等。如果人本身不擅长做这件事，也就没办法更好地评判 AI 做的好还是不好。这和使用 LLM 学习其他领域、进行创意启发等场景是不同的，人类必须是相比 AI 更专业的角色。

最后，靠业界优秀论文和公司内团队支撑。从 23 年到 24 年，在 AI 单元测试领域出现了不少靠谱的论文，比如 Meta 的 arxiv.org/pdf/2402.09… 团队也是在调研之后，和公司内 Codeverse 团队一起，在我们的业务上落地了 AI 单元测试能力。

AIGC 落地的最后一公里

AI 单测真正的落地，还需要业务仓库研发同学的协助，不只是基础配置和存量单测代码的合入，还有对后续日常研发流程的改变。

接入AI单测能力，我们提供了3个模块：基础依赖包、流水线配置、ut-helper 本地工具。由于模型在纯函数上表现更好，在组件上略有欠缺，所以我们的推进策略是优先覆盖 P0 仓库的所有工具函数和通用组件，对于业务属性较强的代码暂不推进。 通过收集流水线上报的单测执行数据，我们建立了数据看板，展示仓库接入率、全量覆盖率、增量覆盖率和单测执行失败明细。

对于研发日常的影响，大家问的最多的问题是：生成了 case 之后还需要人类 review 吗？AI 有帮助人类纠错的能力吗？我们希望是不需要人工介入且能帮助发现潜在风险，而且也看到了一些希望。随着存量代码的覆盖完成，增量代码的覆盖更是对人类和 AI 的协作的考验。 AI 是否真的能在研发需求迭代过程中帮助研发规避潜在风险，部门的 bug 估分比是否能切实下降，这都是我们拭目以待的事情。

总结

在今年的实践中，我们对于 AI 落地这件事又有了更多的认识。它不是人类驱使一个远远强大于自己的怪物，落地工业生产场景仍然是靠人类往前迈一步，指挥 AI 在指定范围内做事。另外，AI 在真实落地中的挑战远不止模型训练，AI 和 AI、AI 和基建之间，有很多工程化的工作，它们可以在很大程度上改变最终的效果，有时会比实验室的大模型 pk 榜有趣得多。

保障交付质量

交付质量（Delivery Quality）是指在软件开发过程中，最终交付给客户或用户的软件产品所具备的质量水平。它涵盖了多个方面，包括功能性、可靠性、性能、安全性、易用性、可维护性等。交付质量的高低直接影响到用户满意度、产品市场竞争力以及企业的声誉。

交付质量对于软件开发非常关键，交付质量的劣化会带来用户满意度下降、维护成本增加、品牌声誉下降等问题，甚至会缩短产品的生存周期。交付质量的保障覆盖软件开发过程的所有环节，包括需求设计、开发、测试、发布上线、运维阶段，本文将从各个软件开发环节展开聊一下质量保障的手段和能力。

质量保障传统手段

完整的质量保障策略，需要各个阶段的努力，常见的质量保障框架包括基础的规范、工具、质量防控手段和质量度量：

暂时无法在飞书文档外展示此内容

保障交付质量是一个比较大的话题，交付质量问题可能出现在软件的开发生命周期任意一个环节，需求设计环节中的需求逻辑问题、开发阶段的代码质量问题和测试阶段的测试漏放问题最终都会导致交付质量的下降，常见的质量保障手段和理论基础：

• 持续集成/持续交付（CI/CD） ：持续集成（Continuous Integration, CI）和持续交付（Continuous Delivery, CD）是一种自动化软件交付流程的方法，通过频繁地集成代码、自动化测试和部署，确保软件始终处于可发布状态。

• 测试驱动开发（TDD） ：测试驱动开发（Test-Driven Development, TDD）是一种开发方法，要求开发者在编写功能代码之前先编写测试用例。通过这种方式，确保代码在开发过程中始终符合预期，提高代码质量和可维护性。

• 行为驱动开发（BDD） ：行为驱动开发（Behavior-Driven Development, BDD）是一种协作开发方法，通过自然语言描述系统行为，确保开发团队、测试团队和业务团队对需求有共同的理解。BDD 强调从用户的角度出发，编写可执行的测试用例。

• DevOps：DevOps 是一种文化和实践，旨在通过开发（Development）和运维（Operations）团队之间的紧密协作，实现快速、可靠的软件交付。DevOps 强调自动化、监控和反馈，确保软件在整个生命周期中保持高质量。

• 质量保证（QA）自动化：质量保证自动化工具和框架可以帮助开发团队自动化测试流程，确保软件在不同环境和配置下的稳定性和可靠性。

大模型如何赋能

LLM 的越加成熟为交付质量的提升带来了更多的可能，在整个软件开发生命周期过程中，当前阶段下 LLM 想要替代某一个角色的所有工作还不太可能，但是 LLM 已经可以在各个阶段为各个不同角色带来正向的作用，以下是一些相关的实践参考：

代码生成与重构

LLM 可以根据上下文生成高质量的代码片段，或者重构现有代码以提高其可读性和性能。代码生成能力在 LLM 上的应用和探索已经有较久的时间，随着模型能力的增强和各种工具的诞生和强化，代码生成和重构能力已经达到一个基本可用的状态，同时也有更多的专门为代码而生的代码模型逐步问世，例如 Claude 3.5 Sonnet、CodeGemma、Code Llama、Codex。

相关实践：

1. MarsCode：智能编程助手，提供以智能代码补全为代表的核心能力，支持主流编程语言及 IDE，能在编码过程中提供单行或整个函数的建议；同时提供代码解释、单测生成、问题修复、AI Chat等辅助功能，提升编码效率与质量；

代码审查自动化

LLM 可以用于自动化代码审查，帮助开发者在代码提交前发现潜在的问题。例如，LLM 可以检测代码中的潜在错误、不规范的编码风格、安全漏洞等。

测试用例生成

LLM 可以根据代码逻辑生成测试用例，帮助开发者覆盖更多的代码路径，提高测试的全面性和有效性。例如，LLM 可以生成边界条件测试、异常处理测试等。

自动化部署与监控

LLM 可以辅助自动化部署流程，确保代码在不同环境中的正确性和一致性。此外，LLM 还可以帮助监控系统状态，及时发现和处理潜在问题。

相关实践：

• 基于日志系统的自动化归因和排障能力，能实现在大范围故障中实现智能归因，找到根因，在实践中已经取得较好的效果；

团队协作与沟通

LLM 可以促进团队成员之间的协作与沟通，例如通过自动生成会议纪要、任务分配建议等，帮助团队更高效地协同工作。

相关实践：

1. 飞书智能伙伴：飞书智能伙伴在群聊、会议、邮件等多个办公场景提供智能化能力，极大的提高了工作效率和沟通协作的质量；

展望大模型可探索方向

LLM 能力在交付质量保障中展现了较为强大的能力，在代码生成、代码审查、测试用例等方向已经存在一定的成熟度，但仍存在较大的潜力：

1. 准确性提升：通过不断优化模型、训练策略、评估指标完善等策略，不断提升模型能力的准确性，降低心智负担
2. 业务定制化：与现有的完善保障体系进行工具和流程的集合，融入业务特性，建设个性化 Agent，降低 LLM 使用成本，提升 LLM 能力覆盖度
3. 全流程自动化：探索 LLM 自动化保障体系，管控整个需求开发周期，能够在各环节产物进行自动化质量保障，例如需求文档质量保障、代码质量问题回捞、用例质量保障、发布过程保障、线上运维监控等功能串联，形成全套的自动化方案

当前的发展现状来看，LLM 的能力还是在融入当前成熟的质量保障框架能力中，提升软件研发生命周期的的效率和质量，长期展望来看，LLM 会逐步接管质量保障的各个环节，实现高度自动化

运维管理优化

为什么需要更智能的运维

研发同学的一天，可能大部分时间不是用于开发，而是在处理各种各样的信息，比如告警、oncall、指标异常等等。

从这个角度讲，日常的运维管理比单纯的开发占据了研发的更多时间。从时间分配的角度上来说，对运维提效，可能比对开发提效相比带来的体感提升更大。

传统运维从触达渠道上可以分为两种方式：

1. 系统日志上报，总结出各种各样的指标，当指标出现异常时，发送告警给研发
2. 某系统 fatal 故障，发送卡片让研发检查自己负责的服务是否有问题

在这种模式下，主要的痛点在于：

1. 收到这些运维管理的信息后，研发需要查询大量的上下文，然后定位问题
2. 对于没有达到告警阈值的一些 case，缺乏触达能力

在这个基础上，我们需要更智能的定位分析能力和数据处理总结能力

AI 落地的思路

• 如何处理海量的数据

用 AI 来分析海量数据，一个痛点就是受限于现在AI的语境，无法直接把所有数据都扔进去分析。

但是如果用知识/向量库的方法，用 RAG 的方法去分析，又无法让 AI 站在所有数据的角度去分析。

所以其中的一个思路是把分析的步骤拆解，一次给出局部的数据，然后通过对局部数据的分析，一步步缩小数据范围，在这个范围内给出更大体量的数据，然后让其做出更具体的分析。

• 更多的上下文

在AI对于数据分析的基础上，查找出对应数据的上下文，然后让其总结分析。

比起单纯的数据类告警，这种分析帮助研发节省下在不同平台里查询上下文的时间。举个例子，当我们收到监控平台报警，可能会需要去埋点上报、流量监控等多个平台再去找一些次级数据，验证一些初步的判断。

在这一步，如果可以自动化的取到数据，然后给出初步的分析，就可以提高处理的效率。

• 趋势性的数据分析

把尽可能多的数据提供给 AI，相当于 AI 帮我们观察了各种 dashboard，比如很多需要人去分析得出的尖刺，就可以让 AI 去查找。相比写死代码去分析，更加的智能弹性和节省开发人效。

数据分析的实践

目前 PAI 的数据分析，即遵循了这样的步骤：

1. 观察整体PAI数据，分析出有尖刺的时间点
2. 在有尖刺的时间点内，给出PAI的全部次级数据，深入分析
3. 基于次级数据查找监控平台的对应错误，提供上下文以供分析
4. 总结所有分析，并结构化数据发出推送卡片

暂时无法在飞书文档外展示此内容

	出现演练事故，PAI的报警给出了准确的时间段，并在这个基础上给出了具体的usecase和场景，甚至具体的API。LLM能较大提升分析的效率，仅目前的分析看时间抓取的准确率达到100%，后续增加多数据源的输入（事故通报，上线记录，更多slardar错误抓取等）能增强分析的深度。

总结

一个很深入的感受是，随着 AI 能力的进化，对 AI 的使用反而应该更加的精细。

使用他要像对待一位新加入的同事，如果要让他负责你日常中的运维管理工作，你需要注意：

1. 整理好并清晰的告诉他做这件事的步骤
2. 准确的提供数据和保持语义化
3. 尽量充分的上下文

结语

回顾过去的一年，AI 技术的飞速进步已深刻改变了团队的工作方式，也让我们逐渐认识到，AI 早已不再是遥不可及的梦想，而是我们日常工作中的得力助手。

团队在过去一年中对 AI 进行了大量的探索和研究。AI 单测的引入如及时雨，不仅提升了测试覆盖率和代码质量，还显著减少了人工修复的成本。AI 在内容审核领域极大地提升了审核员的工作效率和质量。在开发效率方面，AI 提供了全方位的智能代码补全、自动化代码审查、代码生成与重构、代码审查自动化等能力，涵盖了开发的方方面面，这极大的提升了我们开发效率。尽管目前 AI 相关工具还有很多不足之处，但 AI 发展的速度已让我们不得不正视起来。未来，当模型的准确性进一步提高，AI 有望在开发和生产的各个环节中提供更加全面和高效的解决方案。

技术的进步和应用场景的拓展，预示着 AI 将在我们日常开发中扮演愈发重要的角色。通过与 AI 的协作，我们相信技术生产力将达到新高度，为用户带来更好的体验。在这场技术革命中，我们迎风破浪，勇敢前行。以更开放的心态拥抱变革，用创新推动技术进步。每次新场景的落地和应用，都是团队智慧与汗水的结晶。

未来已来，我们早已做好准备，你呢？

DeepSeek 作为大模型新锐，凭借其在算法、架构及系统等核心领域的创新突破，迅速获得业界瞩目。在巨大的热度下，面对海量请求，越来越多用户遇到了请求失败、调用超时、结果无法返回等稳定性问题。

火山引擎边缘大模型网关通过一个 API 接入多家模型服务，利用全球边缘节点就近调用，提升响应速度；支持故障自动切换、重试和超时控制，确保服务可靠性；兼容 OpenAI 接口标准，可快速集成 DeepSeek 等模型，降低接入成本。

目前，火山引擎边缘大模型网关已全面支持 DeepSeek 系列模型，可通过两种方式进行模型使用：

• 一是通过平台预置模型， 边缘大模型网关新增由火山方舟提供的 DeepSeek R1、DeepSeek V3、DeepSeek-R1-Distill-Qwen-7B/32B，您可直接使用并对其创建网关访问密钥，无需与三方模型提供商交互；

• 二是通过自有三方模型， 边缘大模型网关新增由 DeepSeek 开放平台提供的 DeepSeek R1、DeepSeek V3 以及火山方舟提供的 DeepSeek R1、DeepSeek V3、DeepSeek-R1-Distill-Qwen-7B/32B，您可以将您在第三方模型平台的密钥纳管至边缘大模型网关，以实现通过边缘大模型网关签发的网关访问密钥进行对应模型的访问与调用。

01 3 步快速调用 DeepSeek

火山引擎边缘大模型网关支持通过一个 API 接口访问多家大模型提供商的模型与智能体，在端侧基于遍布全球的边缘计算节点就近调用。利用边缘云基础架构优势，提高模型访问速度，为终端用户提供更快速、可靠的 AI 服务体验。

在接入大模型的同时，通过配置调用顺序、自动重试、请求超时等能力，能够实现模型调用失败自动请求备用模型、单次请求失败自动重试、单次调用响应时间配置。通过产品化的配置，您可以迅速创建出与 OpenAI 的 API 和 SDK 完全兼容的网关访问密钥（API），并通过选配 DeepSeek 模型进行调用，节省大量适配成本，快速完成业务接入。

Step1 选择 DeepSeek 调用方式

调用平台预置 DeepSeek

边缘大模型网关的平台预置模型中上新了由火山方舟提供的 DeepSeek 模型，您可通过登录产品控制台查看支持模型，并通过点击创建网关访问密钥进行勾选。使用平台预置的模型 DeepSeek，您无需与模型提供商进行交互，可以直接通过边缘大模型网关进行模型配置与调用。

调用自有三方 DeepSeek

如果希望使用在火山方舟平台或 DeepSeek 开放平台购买的 DeepSeek 模型调用额度，您需要通过在边缘大模型网关平台创建对应模型提供商的调用渠道，在创建调用渠道时，需要提供您在第三方模型平台的密钥，同时勾选大模型以明确当前调用渠道可进行调用的模型配置。

完成调用渠道配置后，您可通过创建网关访问密钥勾选对应的 DeepSeek 模型，实现大模型的快速调用。

Step2 创建网关访问密钥

完成前序的 DeepSeek 模型选择后，您可在网关访问密钥创建的第二步进行模型调用配置，以更好地保障在终端业务调用时的稳定性。

• 通过设置调用顺序，您可以手动调整上一步选择的模型调用顺序，可以根据不同厂商的容灾策略以及不同尺寸模型的降级进行设置，在前一个模型调用失败后，大模型网关将依次调用后续模型，直到成功调用一个模型。如果所有模型都调用失败，则返回错误响应。

• 通过重试次数，您可以设置对一个模型进行调用的最大重试次数。当一个模型调用失败后，大模型网关将重新尝试调用此模型，直到重试次数耗尽。

• 通过启用缓存，大模型网关会就近调用结果返回在边缘节点，从而加快重复查询、缩短响应时间并降低成本。

• 通过设置**缓存的保留时长，**一旦超过指定时长，缓存将被清除。

• 通过请求超时定义，您可以设置单次模型调用的超时时长，模型请求发出后，若在超时时长内未收到响应，则判定该请求失败。

Step3 服务调用与观测

当您根据上述流程完成网关访问密钥创建，您可以在网关访问密钥列表中查看已完成创建的信息。在详情页面，可以看到基本信息、用量统计、请求方式等详细信息。

通过详情页调用示例，您可以获得由边缘大模型网关提供的请求示例代码，包含 Curl 和 Python。当您从网关访问密钥绑定的模型中选择一个模型后，代码中的model参数值将自动替换成模型对应的值。如果网关访问密钥绑定了多个同一类型的模型，那么当选择一个模型后，可以通过单击右侧的图标查看模型故障转移的预览效果。当前模型调用失败时，大模型网关将依次调用后续的模型。在调用时，您需要将详情页 - 请求方式中的密钥替换示例代码中的$VEI_API_KEY。

边缘大模型网关可根据您通过网关向模型发出的请求以及模型的响应来统计您的用量。不同模型提供商对模型用量的计量方式有所不同，根据模型调用计量方式，您的调用详情可以在用量统计中进行查看。

同时，通过云监控 - 大模型网关模块，您可以查询以网关访问密钥为维度的总用量（已消耗的 tokens 总量）与用量速率（每秒消耗的 tokens 额度）。

02 200 万 tokens 免费额度，体验边缘大模型网关

当前，火山引擎边缘大模型网关已适配 15+ 种主流大模型厂商及多个智能体提供商，点击www.volcengine.com/docs/6893/1… 了解并咨询 DeepSeek 模型~ 了解更多边缘大模型网关产品详情。

文档详情：

www.volcengine.com/docs/6893/1…

摘要：抖音集团安全研究团队发起Jeddak星火计划，致力于支持安全计算领域科学研究与技术攻坚，解决机密计算、密态计算、隐私数据保护等领域的关键问题。即日起开启课题征集申报，诚邀高校及研究机构的学者报名

为支持以更长周期攻坚 AI 课题，豆包大模型团队正式启动 Seed Edge 研究计划！ Seed Edge 以寻找通用智能的新方法为目标，专注于对智能边界的探索和长期研究挑战。 Seed Edge

作者｜Eino 项目组 今天，经过字节跳动内部半年多的使用和迭代，基于 Golang 的大模型应用综合开发框架 —— Eino，已在 CloudWeGo 正式开源啦！ Eino 基于明确的“组件”定义

来源｜字节跳动基础架构-可观测团队

背景

随着字节跳动业务规模不断扩大，对存量和新增业务的服务质量承诺变得越发关键。稳定性治理方面：怎样支持保障服务线上的高可用性，或者在出现故障/事故时，如何高效且迅速地止损、定位分析影响面已成为一个重要议题。

稳定性建设所涉及的话题十分广泛，涵盖流程梳理与标准化、数据标准化、SLO 定义、故障自愈、事故复盘和演练等方面，字节跳动基础架构可观测团队提供的稳定性平台建设思路是“事前预防、事中处理、事后复盘、事后补救/反哺事前”这四个阶段。

其中， 观测数据标准化以及一系列配套的数据链路，如：数据埋点、数据消费、数据存储、数据查询、离线数仓等，都是后续稳定性建设的重要数据基石。

并且，由此引申出排障/止损效率的问题，由于字节的服务/基础设施是分层建设的，包括端侧客户体验层、网络接入层、应用服务层、基础设施层、IDC\资源层等，不同层面的统计/描述口径是否一致、能否对应，以达到在跨层间能上卷下钻和平层内过滤聚合的“车同轨书同文”效果，这对于大幅提升整体排查效率， 让 SRE/GOC 同学能够自助完成端到端的问题排查就显得尤为重要。

拥有统一的观测数据标准， 能够在很大程度上提升团队间的排障效率，从人工分析的方式提升至更大程度的自助/自动化排障的阶段。

埋点标准化的重要性

提高研发效率 & 降低研发协同成本

• 面向排障方面：跨层间的上下文过滤便捷，术语统一。
• 进行历史数仓分析（容量优化）时，整体数据处理逻辑的适配成本会大幅降低。
• 用户的学习曲线陡峭，理解心智负担沉重。

为 AIOps 提供强有力的数据支撑

观测数据属于 AIOps 的五大基石（数据、知识、算法、代码联动、人机协同）之一。在清华裴丹老师的《AIOps 落地的 15 条原则》里，也都提及了数据的重要性。

拥有数据标准化和统一的访问体验，为后续稳定性的终极目标 MTTR 1-5-10（1 分钟发现，5 分钟响应以及 10 分钟快恢复）提供了数据层面的保障。包括同层数据的聚合 / 过滤，以及跨层数据的下钻和上卷，都会有统一的使用方式。

名词解释

名词	解释
Metrics 2.0	字节跳动内部使用广泛的时序数据处理引擎，提供了时序数据收集、存储和聚合查询的功能。2.0 版本提供引入多值概念，打平prometheus 4类指标类型语义、支持秒级打点& 存储周期定制化等多租户特性、 端到端高性能优化的分布式时序集群版本。
BytedTrace	BytedTrace是字节跳动使用的一套集成了 Tracing/Logging/Metrics 三种能力的可观测性解决方案，提供了从采集、传输、存储、检索到前端产品化交互的整套能力。它定义了统一的数据模型（Trace 、Span 、Event、Metrics 等），提供了各语言配套 SDK，并与公司各主流框架组件实现默认集成。
观测埋点 TagKV	Metrics TagKV 是一种用于标记和管理度量数据的键值对（Key-Value Pair）格式。通常用于监控系统、分布式追踪系统和日志管理系统等领域，TagKV 提供了一种灵活且高效的方法来分类和筛选数据。
Measurement	可观测对象的某个指标，如服务的上游调用延时，物理机的 CPU 使用率。Measurement 是带有可观测对象的 context的，是语义化的，同时能识别在不同条件下应该使用哪个版本的指标以及对应的 TagKV。而且可以根据观测对象的元数据条件，同时关联多个时序数据源，便于按需时序数据源切换。
SLO	Service Level Objectives，服务级目标是指服务提供方对所提供服务的某些性能或质量指标所设定的目标值。这些指标通常用于衡量服务的可用性、性能和其他关键属性，旨在确保服务达到预期的质量水平。
TCE	Toutiao Cloud Engine，为字节跳动内部提供的高度可用、弹性扩展的容器服务。
PSM	Product Subsys Module，是字节跳动内部服务的唯一标识。
GOC	Global Operations Center，基于字节跳动各类研发，运维体系下的高可用产品能力，结合稳定性保障策略及运营机制，提供字节跳动全线基础产品的可靠性服务与设施稳定性保障，达成字节跳动全线业务各类场景下的端到端高可用性。

字节埋点标准化挑战与拆解思路

挑战： 历史上可观测性埋点质量偏低

首先，我们对埋点标准化进行定义，包括但不仅限于如下的标准定义，包括覆盖完整、定义统一、计量准确、面向引擎友好等四大方面。

简而言之，在 2020 年以前，从覆盖完整、定义统一、计量准确、面向引擎友好等维度来看，字节整体的观测数据埋点存在一定的差距。

具体如下：

• 负载均衡 埋点

  • 计量准确：中等水平

    • 存在较严重的打点丢失问题

  • 面向引擎友好：较低水平

    • 指标打点对于配置预计算不友好
    • 指标名膨胀也比较严重

• 微服务 埋点

  • 覆盖完整：中等水平

    • 20 年前 Tracing 方案还在 V1 版本

  • 计量准确：中等水平

    • 遇到高基数的指标会被封禁

  • 面向引擎友好：较低水平

    • 指标打点对于配置预计算不友好
    • 指标名膨胀也比较严重
    • 加权计算也不好实现

• 语言 运行时 埋点

  • 定义统一：较低水平

    • Golang & C++ 框架 不同的版本定义的指标格式都不太一样

  • 面向引擎友好：较低水平

    • 指标打点对于配置预计算不友好

• 容器指标 埋点

  • 覆盖完整：较低水平

    • 没有日志采集覆盖

  • 计量准确：中等水平

    • 遇到高基数的指标会被封禁

  • 面向引擎友好：较低水平

    • 指标打点对于配置预计算不友好

• 基础架构 存储 & 数据库 埋点

  • 覆盖完整：较低水平

    • 存储、数据库、MQ 客户端没有黄金指标打点
    • 没有日志采集覆盖

  • 计量准确：较低水平

    • 不同存储、数据库、MQ 产品打点格式 都不一

  • 面向引擎友好：较低水平

    • 指标打点对于配置预计算不友好

思路： 分层&向后兼容推进埋点标准化

总结来说，之前的字节服务端观测数据质量大致存在三类问题。

• 同层数据/跨层数据不一致。
• 观测的多模态数据类型（指标、日志、链路）的数据定义不统一。
• 观测数据格式对引擎不够友好，例如所有数据都在 default 租户的一个大仓里，再比如很多观测指标的定义对于预计算不友好。

针对上述问题，我们采取了如下的多个思路逐一进行解决。

实施思路

一方面，在埋点侧就尽可能统一埋点 TagKV 定义，而且平台级 TagKV 都通过环境变量或者请求上下文自动注入对应的 Tag Value， 以防止由业务手工注入带来的人工错误。

另一方面，对于指标、链路和日志侵入式 SDK，我们通过字节内部的远程过程调用框架以及存储、数据库、消息中间件的客户端 SDK 搭载嵌入中间件，对于业务来说，能相对透明地升级到最新特性的版本。另外， 对于远远低于 SDK 基线版本的服务， 我们也通过字节软件供应链安全治理平台通过编译卡点的不同程度[warning 提示/发布卡点]推动业务升级。

在 负载均衡、应用、中间件、存储计算组件等各个纵向方面， 我们也主动与对应的平台对接，推动指标、日志、链路的埋点注入。

最后，在指标埋点上也额外关注对于多租户的声明，以达到一定的分库分表功能，以及多值声明，以最大程度减少数据消费和存储成本。如下所示， 就是团队在各个不同观测对象的埋点方面所做的业务推进情况。

难点： 识别和解决

类似观测数据标准化的工作历经多年，牵涉的团队众多，整个过程并非毫无波折。遇到问题时要解决问题并思考能否将其标准化或者平台化，同时也要考虑能否尽可能地复用其他团队的能力和工具来助力我们进一步推广。当时如何高效地推动业务升级是我们的主要目标。

[业务推进] 高效推动业务升级观测SDK

在 Metrics SDK 需要升级到基线版本的情况下，以前的做法是在字节软件供应链安全治理平台上配置版本拦截，提醒用户升级，但是整体升级效率比较低，我们也无法跟踪用户的升级进展。因此我们联合字节软件供应链安全治理平台团队实现 SDK 自动升级功能。

Metrics ****SDK 自动升级

Metrics ****SDK 自动升级功能可以自动实现在当前业务代码库的代码提交期间，如果检测到对应集成的metrics SDK 低于基线版本，则会向用户推送代码提交失败的通知，提醒用户需要主动升级到metrics SDK基线版本或以上的操作。

远程过程调用 框架 & 基础组件客户端 集成 ****BytedTrace ****SDK 集成

观测团队多年来持续推动公司的远程过程调用 框架以及基础组件客户端 集成 BytedTrace SDK ****。 ****借助字节软件供应链安全治理平台进行递进式卡点推广，依靠代码血缘平台来推动框架、组件的基础库版本实现升级。在存有流量的微服务上，BytedTrace SDK的覆盖比例按照 TCE pod 接入情况来计算，当前已达到 95%。

从服务的优先级角度而言，公司当前96% 的 P0 服务中已接入 Bytedtrace SDK 。

[业务推进] 提升基础组件观测埋点质量

TCE 调度 / 运行时 打点格式设计思路

前文提到，提升业务层、应用层、容器层等多层间指标的跨层关联和下钻能力是指标标准化的一个重要目标，而实现跨层关联的关键动作在于保证同一含义的指标 TagKV 在各层上的定义保持统一，为实现这一点，我们对各个层次上的核心组件进行了统一的设计，具体如下：

层次	核心组件/着手点	埋点标准化设计思路
业务层	Metrics 2.0 SDK	- 内置统一的平台级TagKV，提供横向跨语言、跨服务的TagKV统一
应用层	运行时 指标、远程过程调用 指标	- 横向上，提供统一的、跨语言的指标名定义

• 纵向上，对齐Metrics 2.0 SDK 平台级TagKV规范 | | 容器层 | 与调度合作，对容器指标采集agent(TCE调度)进行标准化改造 | - 对齐Metrics 2.0 SDK 平台级TagKV规范 |

1. 首先，我们在 Metrics 2.0 SDK 内置定义了一套平台级 TagKV，这样所有使用 Metrics 2.0 SDK 的业务打点都会携带标准的预定义的 TagKV。这些共同TagKV包括： _cluster、_psm、_pod_name、_ipv4 等。

2. 在应用层，挑选了对业务排障、应用观测常用且通用的两类指标（运行时、远程过程调用）进行标准化，目标是在横向上，提供跨语言、统一的指标名、TagKV语义定义等；在纵向上，对齐 Metrics 2.0 SDK 平台级 TagKV 规范，以便于跨层关联。以 运行时 指标为例，其定义规范如下：

   1. 不同语言的指标采用统一命名约定：runtime. {runtime} . {metric}[ . {field}]
   2. 不同语言类似含义指标采用统一命名风格：如 go、java 中统计堆对象申请量的指标都命名为memory.allocated_bytes
   3. 必须包含 Metrics 2.0 SDK TagKV 规范的平台级 TagKV，如 _psm、_pod_name 等

3. 在容器层，与调度团队共同推动其 TCE 容器指标采集 agent(TCE调度) 的指标标准化改造，指标 TagKV 对齐Metrics 2.0 SDK TagKV 规范。

通过将这些核心组件进行标准化改造，为跨层的指标关联和下钻提供了能力基础。同时，在每个核心组件的指标定义上，我们还通过以下两个方式进一步提升埋点的性能和成本收益，第一点是对各个组件使用独立租户，实现资源的隔离，保障写入稳定性和查询性能；

指标	租户名	集群类型
运行时	apm.runtime	独立集群
远程过程调用 框架	apm.rpc	独立集群
TCE 容器指标	computation.tce	独立集群

第二点是在语义明确的前提下，尽量使用多值格式定义指标，降低存储成本。以 TCE调度 指标为例，将原来 mem 相关的四个指标合并为一个多值指标的四个字段，存储成本大致可以被认为降低至四分之一。

原指标	改造后多值指标名	改造后多值字段
tce.host.mem_total	inf.tce.host.mem	total
tce.host.mem_free	free
tce.host.mem_available	available
tce.host.mem_used	used

[配套工具] 帮助平滑迁移观测数据

[工具1] 语义 化指标替换

我们提供语义化指标替换，称为Measurement，其能力就是对原始 Metrics 打点的语义化封装；同时能识别在不同条件下应该使用哪个版本的指标以及对应的 TagKV。这两个关键能力能够促使在做数据迁移时，观测大盘和报警基本达到比较平滑的状态。

原始 Metrics 打点：直接写入时序数据库（可以是 metrics \ influxdb \ prometheus）的数据。

语义 化 封装：用标准的语义化来包装原始的 metrics 打点数据。 比如 go 服务的 gc 数量的 metrics 打点是 go.{{.psm}}.numGcs，其中{{.psm}}为具体的 psm， 我们会定制一个语义化指标名叫 "runtime.go.gc_num"来表达 go 服务的 gc 数量，包括用统一的 TagKV 来封装对应的原始 TagKV。 不管是 open api 还是前端调用， 都用指标 "runtime.go.gc_num" 对measurement 服务进行调用。

不同条件下的查询 路由：需要这个能力是因为在字节内部原始 Metrics 的打点会不断的升级， 比如 golang 运行时 历史上会有 v1 、v2 、v3 多个版本，我们需要能够在给定的输入信息条件下去查询到对应的指标版本。这个判断条件实现的逻辑一般为可用输入的 psm 名字构成 Metrics go v1 的指标名，再根据指标名的数据是否存在来判断是 runtime v1、runtime v2 或者 runtime v3 的版本，指标判断也以此类推。或者可以通过 psm 的 scm 编译信息确定该 psm 编译的 golang 运行时 版本是 v1、v2 或者 v3。 通过对应条件的判断来做到对应数据的查询路由。

在有了 Measurement 能力后，我们抽象出了 Measurement 服务，该服务作为观测大盘和报警的一个数据源。在尽量不需要用户介入的情况下完成数据打点的迁移和替换。

当前借助 Measurement 能力，针对公司的 远程过程调用、HTTP 等框架，容器引擎、FaaS、机器学习推理等平台，还有负载均衡、缓存、数据库、消息队列等基础组件，以及golang 运行时 等，均进行了统一的标准化语义封装，这些语义化封装在观测平台上均有所展现。

[工具2] Metrics 前缀分流

怎样帮助业务顺利地迁移到新租户，同时确保新老指标的查询方式均可使用，是我们在推动业务租户迁移时所面临的较大挑战。

针对上述问题，观测团队起初推进引导用户主动迁移至新租户，旨在实现租户隔离，提供更优的稳定性保障，进行精细化容量治理以降低成本。然而，后来发现主动迁移的速度太慢，赶不上打点量的自然增长。于是，推出了让用户无感知的被动租户迁移方案。大致思路是依据某些特定的指标前缀，主要涵盖一级 / 二级前缀，通过特定配置把这些指标分别路由到不同的新租户，并且在新租户上支持查询翻译，即便用户不修改查询租户，继续用 Default 租户查询仍能正常获取数据。该方案具有以下优势：

1. 业务在读写两侧无需进行代码变更，就能将流量迁移到新租户集群。
2. 最大程度减少不同租户间因集群变更和读写流量变化对线上稳定性产生的相互影响，提供更出色的稳定性保障。
3. 精准对接业务线租户，便于后续进行打点流量治理、容量规划以及资源充值等操作。

具体的实现由 Metrics 组件中各模块的相互配合完成，包括写入、控制面、查询、数仓等方面，大致的实现流程如下：

前缀分流租户的整个过程存在众多细节，为减少过程中的过多人为操作，防止出现某些环节被遗忘的情况，观测团队设计了分流流程工单以及白屏化运维平台，尽可能让整个操作流程实现自动化，提高分流租户的效率。此外，前缀分流迁移新租户的整个过程对于业务来说成本为零，同时对于 观测团队而言不像依赖业务方主动迁移那样周期漫长，其周期短、生效时间快，能够收敛团队人力的持续投入。

总的来说，观测团队提供了一种让用户无感知、实现无缝迁移新租户的方案，用户的核心观测大盘和报警也无需修改，最大程度降低了埋点标准化对用户的打扰。

埋点标准化字节的实践与效果

观测数据质量前后对比

经过 2020-2022 年推进 BytedTrace SDK 覆盖率、2023 年推动云基础组件和应用层指标租户迁移之后， 从埋点标准化的 4 个维度看，都有不同程度的质量提升。

• 负载均衡

  • 计量准确：较高水平 [2020年为中等水平]

    • 通过 2.0 SDK 三个特性， 基本消除丢点的问题：

      • 打点本地聚合
      • 面向字节流的 codec 编码
      • Agentless 投递

  • 面向引擎友好：较高水平 [2020年为较低水平]

    • 实现面向预计算友好的效果

  • 成本收益：

    • Metrics 2. 0 打点商品成本相对 1.0 下降 94%
    • Metrics 2. 0 很好地解决了打点封禁问题，特别是在一些配置量巨大的核心集群，解决了其超过 90%打点无法查询的情况
    • Metrics2. 0 TLB 机器成本初步统计主容器和 adaptor 打平，同时相对 1.0 节约了 ms2 的 15000 核资源

• 微服务

  • 覆盖完整：较高水平 [2020年为中等水平]

    • 80%以上 PSM 覆盖到 BytedTrace SDK 集成

  • 计量准确：中等偏上水平 [2020年为中等水平]

    • 高基数的指标封禁问题 由于迁移到了新租户 可以做封禁阈值定制化
    • 
    • [计划中] 升级 bytedTrace 内的 metrics 2.0 SDK 降低丢点的风险

  • 面向引擎友好：较高水平 [2020年为较低水平]

    • 实现面向预计算友好的效果

  • 成本收益：

    • 以计算关键组件 Consumer 为例，新租户只需要老租户 20%的资源，就可以完成相同数据的写入计算；其他写入计算类组件也类似
    • 以存储关键组件 tsdc 为例，新租户只需要老租户 55%的资源，就可以完成数据的写入、存储

• 语言 运行时

  • 定义统一：较高水平 [2020年为较低水平]

    • 统一了不同语言和框架的 运行时 打点格式

• 容器指标

  • 覆盖完整：中等水平 [2020年为较低水平]

    • TCE调度 接入日志租户

  • 计量准确：较高水平 [2020年为中等水平]

    • 引入多值 降低指标名数量

    • 高基数的指标封禁问题 由于迁移到了新租户 可以做封禁阈值定制化

    • 通过 2.0 SDK 三个特性， 基本消除丢点的问题

      • 打点本地聚合
      • 面向字节流的 codec 编码
      • Agentless 投递

  • 面向引擎友好：较高水平 [2020年为较低水平]

    • 实现面向预计算友好的效果

• 基础架构 存储 & 数据库

  • 计量准确：较高水平 [2020年为中等水平]

    • 引入多值 降低指标名数量

    • 高基数的指标封禁问题 由于迁移到了新租户 可以做封禁阈值定制化

    • 通过 2.0 SDK 三个特性， 基本消除丢点的问题

      • 打点本地聚合
      • 面向字节流的 codec 编码

  • 面向引擎友好：中等水平 [2020年为较低水平]

    • 打点格式调整的 支持预计算配置

  • 成本收益：

    • 以 mysql 迁移为例

      • Mysql 租户 成本节省 45.7%
      • Mysql 租户 带宽节省了 80%

截止到今年年初， Metrics 在中国国内区域已经接入 60+ 租户，占总流量的 70% 左右。

赋能效果总结

加速微服务端到端根因定位

通过指标标准化 & 多模观测数据 [指标， 日志，链路]标签术语的标准化， 我们实现面向微服务的上卷 & 下钻关联分析。

也使得使得跨层问题根因分析有了可能性：

目前端到端根因定位覆盖了60%以上的报警场景，日均触发根因定位 50余万 次，用户对定位结果的正反馈率超过80%。

简化服务性能离线数仓构建

在实现了在线观测数据的标准化，并将其导入统一的存储介质之后，构建字节整体关于服务性能、容量、吞吐量的数仓大盘就更加便捷。比如 展现某服务的单核 QPS 分时热力图 如下:

目前基于微服务应用性能数仓已覆盖公司超97%的微服务量化，有效支持字节跳动各业务线服务性能、服务应用健康度度量，由此带动一系列精准的成本优化。

观测底座自身收益

• 从稳定性角度看，由于引入metrics多租户概念，所以我们能够通过逻辑租户映射到物理资源，从而降低故障半径，减少不同租户间流量的相互干扰。
• 从成本角度看，我们能够依据每个租户的副本数、存储时长 TTL、打点的最小精度以及多值定义，最大程度地降低写入流量和存储容量的成本。metrics 多租户迁移前后对比，成本节省幅度在 20% ~ 80% 不等。

总结

历经上述观测埋点套件 BytedTrace SDK推广、Metrics 指标标准化迁移和推广、部分业务接入日志多租户，字节后端观测数据的质量在覆盖完整度、定义统一、计量准确、面向引擎友好四个方面上取得了显著的质量提升。这也为后续的全景全栈高效排障奠定了坚实的基础，帮助更多业务团队在业务稳定性方向持续建设。

---

依托字节跳动内部可观测团队大规模技术实践，通过内外合力，在火山引擎上推出了应用性能监控全链路版（APMPlus）、托管 Prometheus（VMP）、云监控等可观测产品，致力于为用户提供全面、智能、高效、易用且安全的全栈可观测解决方案。

目前 APMPlus Server 端监控已正式 GA 并支持最新的大模型链路追踪相关能力，欢迎咨询了解。

🔗 相关链接

APMPlus ： www.volcengine.com/product/apm…

VMP ： www.volcengine.com/product/pro…

云监控 ： www.volcengine.com/product/clo…

前言

设计素材行业为设计师和创意工作者提供丰富的视觉和创意资源。数字媒体和互联网的迅猛发展，促使这一行业市场规模不断扩大，用户对设计素材的个性化和定制化需求与日俱增。卓特视觉，作为Adobe Stock中国区官方合作伙伴，自2014年成立以来，始终致力于推动中国创意产业的繁荣发展。在AI的技术浪潮中，卓特视觉选择与火山引擎veImageX（一站式图片解决方案）携手合作，旨在通过AIGC加成，更加智能和高效的生成设计素材，进一步拓宽创意表达的边界。

卓特视觉（Droit Vision），Adobe Stock中国区官方合作伙伴，全面整合全球范围内的高质量图片、矢量插画、高清视频及音效音乐等素材资源，专注于为新媒体、设计、广告、各类垂直行业及个人用户，提供一站式的视觉素材和解决方案，助力创意人士和企业提升其视觉作品的品质和影响力。

至今，卓特视觉在线销售高清正版图片总数超5.6亿和超3,600万条高清视频。自2014年成立以来，卓特视觉成功为众多知名企业提供了安全、高效、优质的视觉创意解决方案，赢得了广泛的企业级客户信任。

场景概述

在设计素材行业，传统的商业模式通常由创作者提供内容并上传至平台，平台负责销售和分发，同时负责版权等问题，用户通过付费获取平台的高质量素材资源，平台则根据销售情况与创作者分成。而在AI的技术推动下，平台会提供一系列的AIGC工具，帮助用户实现图片生成、放大、扩展、风格转换等效果，同时收取使用这些功能的费用。

图片来自卓特视觉官网

方案介绍

火山引擎veImageX基于字节跳动的图像领域最佳应用实践，提供端到端的一站式图片解决方案。

整体架构

一套方案解决上传、存储、图像处理、分发、解码、QoS&QoE监控的全链路方案，覆盖从内容生产端到图像消费端。

veImageX的服务端具备强大的实时处理能力，不仅包含了裁剪、缩放、格式转换等基础图像处理功能，还提供了画质评估、画质增强、智能裁剪、超分、盲水印等丰富的AI组件能力。

卓特视觉接入了veImageX的哪些能力

一、画质评估

画质评估组件支持模仿人类对于图像的视觉感受，从而对图像的各方面进行评分。评分指标有大众美学评分、噪声强度评分、纹理丰富度评分和色调均衡程度评分等。veImageX通过抖音集团内部的大量线上业务实验发现，图片画质优劣对点击率、停留时长等消费类指标有正相关影响，间接影响用户收益指标。卓特视觉通过画质评估组件，对线上的海量素材文件进行了广泛的评估，在网站尽量展示评分较高的图片，并在用户查询图片时，优先推荐同类型中评分高的图片。这一系列举措不仅提升了网站整体的图片质量及用户的满意度，还促进了业务增长，并获得了良好的用户口碑。

二、智能裁剪

智能裁剪是 veImageX 提供的全新图片裁剪附加能力，支持对输入图片进行指定尺寸变换，能够自动判断主体区域的位置，并支持自动化适配不同尺寸图片内容的裁剪。卓特视觉的用户分布在各行各业，用途包含宣传页、海报、杂志、电商平台、户外广告等，对图片的尺寸和表现侧重点都有个性化的要求，卓特视觉通过智能裁剪能力批量对原图进行裁剪，自动化适配用户对于不同尺寸的要求，同时确保在任何尺寸下，图片主体都能处于最佳位置。快速高效满足客户需求的同时，也拓宽了产品的适用边界。

三、存储

卓特视觉目前拥有超过5.6亿的正版素材，并且数量仍在持续高速增长，占用的存储空间日益庞大，成本也与日俱增，veImageX提供存储服务，同时支持根据上传时间变更存储类型的智能降冷策略，有效节省存储的成本。此外， 为了进一步帮助企业降低存储成本，veImageX通过自研BVC算法，提供全球领先的极限图片压缩比，对比JPEG压缩率提升8-10倍，在不降低图片质量的前提下，在保持图片清晰度基本不变的情况下，单张图片体积节约超过70%，可以实现显著的成本节约。

四、分发

veImageX作为端到端的图片解决方案，除了强大的AI图像处理能力，还提供存储和分发能力，在分发阶段，veImageX利用自建 CDN 节点进行灵活的智能调度，为国内外用户提供极致的观看体验。卓特视觉通过使用veImageX的高效分发方案，确保了全球用户访问的快速和稳定。

设计素材行业其他需求的能力

一、智能生图能力

用户在平台可能会遇到不符合设计标准的素材，不仅影响了创作效率，同时也会影响平台的口碑，因此，引入AIGC智能生图能力显得尤为重要，当现有素材无法满足需求时，可以通过AIGC快速生成。veImageX结合豆包的AI生图方案，最新上线了智能生图能力，封装了文生图、图生图一站式解决方案。支持将豆包生成的图片进行后处理，包含存储、压缩、二次处理、超分辨率、盲水印、裁剪、适配、分发等。典型功能如下图展示：

• 文生图场景

• 图生图场景

此外，veImageX智能生图能力还支持桥接第三方模型文生图、图生图服务，直接对接veImageX进行上传、编码、存储与管理，并支持完善的后处理服务。大大扩展了方案的灵活性。

二、智能审核

设计素材平台如果遇到涉黄、涉暴的素材上传，不仅涉嫌法律风险，而且对平台的品牌可信度将会是极大的折损，而面对每天数以十万计的素材，人工审核显然无法满足。veImageX 提供了图片智能审核功能，支持分类型智能检测图片中涉黄、涉暴恐、违法违规等十几种禁用行为，并返回最终识别结果。识别并预警用户上传的不合规图片，协助平台快速定位处理。

三、盲水印

在设计素材行业，素材的版权归属一贯容易产生争议。在版权意识和版权法逐渐完善的今天，稍有不慎可能就会产生法律纠纷。veImageX兼顾版权追踪和图片美观，支持对图片添加盲水印，同时支持对图像提取盲水印信息，方便追踪溯源。盲水印是一种肉眼不可见的水印方式，可以在保持原图图片美观的同时，又可以保护资源版权。对原图进行解码后，可以得到盲水印信息证明图像的版权归属，避免未经授权的复制和拷贝而造成的版权问题。

四、超分辨率

设计素材平台的用户在制作海报、广告牌等场景时，往往需要对原始素材进行放大，同时需要保持放大后图像的清晰度，即所谓的“无损放大”。veImageX支持将图像做2-8倍智能放大，并保持处理后图像的清晰度，使图像更加清晰、锐利、干净，给用户带来良好的视觉体验。

五、智能背景移除

用户在使用平台提供的设计素材时，如果发现图片中的主体部分符合需求，但是为了配合使用场景、符合品牌调性等原因，需要对原始图片中的背景进行移除。veImageX的智能背景组件，支持保留图像的主体并抠除其复杂的背景，从而生成保留主体的透明底图片。veImageX提供了多种图像处理模型，支持精细化图像主体轮廓处理，可大幅度提升图像处理效率，降低人工成本。

结语

在AI的技术浪潮中，传统的设计素材行业正在向AI时代迈进，以满足客户日益个性化、精细化、创意化的诉求。火山引擎veImageX凭借夯实的技术底座和强大的AI能力，与卓特视觉携手合作，共同迈入设计素材行业AI新纪元，助力我国视觉版权服务市场的蓬勃发展。

了解更多：www.volcengine.com/product/ima…