导读

2023 年被称为大模型元年，但真正让人记住的模型并不多。到了 2024 年，技术与应用的双重驱动，让大模型进入前所未有的“快车道”。2025 年初，DeepSeek 的爆火更是点燃了全球的热情，每周都有数个乃至十余个新模型问世，文本、语音、图像、视频全线开花。可是在这琳琅满目的发布与宣传中，谁才是真正的 SOTA？通用榜单、技术报告的数据真的可靠么？面对眼花缭乱的分数、榜单与宣传语，企业和开发者又该如何选型？这篇文章带你穿梭大模型“井喷之年”的浪潮，揭开榜单背后的真相，并分享一套面向业务实践的评测方法论。读完之后，你也许会发现：选模型，不只是追逐最新的名字，而是一次关乎判断力与洞察力的考验。

01 大模型井喷之年

作为大模型元年的 2023 年，虽然有百余款模型发布，但是经过 2024 年的应用实践的洗礼之后，真正被大家记住的大模型并不多。随着技术与应用的双重驱动，在 2024 年 Q4，我们发现大模型的发布数量、发布速度都呈现除了前所未有的规模。尤其是在 DeepSeek 火爆全球的 2025 年 Q1，大模型更是呈现出了井喷之势，几乎所有的场景，无论是文本、推理、语音、图片、视频，都会不停地有新的 SOTA 模型发布，模型之间的竞争也逐渐呈现白热化态势。

2025 年之前的数据可以参考：

x.com/i/grok?conv…

在 2025 年 3 月，我们提出这个春天是大模型的春天，在这个大模型的春天里，乱花渐欲迷人眼，处处早莺争暖树。今天，当再次回顾年初的判断时，我们虽然猜到了大模型白热化竞争的趋势，但是依然没有猜到竞争会如此之快、如此之烈。

当时我们认为，2025年，每周至少会有1款大模型发布，但是在第 30 周 ~ 第 33 周的这4周时间里，有 3 周每周都有 10 款大模型发布。大模型的发布周期慢慢的从“年”为单位，提升到“月”为单位。

通过下图的文心系列大模型的发布节奏能够看出，文心系列大模型的发布节奏从之前的“年度”发布已经提升到“月度”发布。对于 Wan 系列的开源视频生成大模型而言，也能看出，Wan 系列模型的迭代周期也已经达到了“月度”发布。

02 究竟谁才是真正的SOTA？

正如 Dr Singularity 前几天发的一篇帖子那样：每个小时，都会有人发布新的模型、新的测试基准、新的突破。每个小时，也总有新的 SOTA 出现，那么究竟谁才是真正的 SOTA 呢？我们如何从繁花般的 SOTA 中汲取技术上的优势，以便可以应用于自己的模型研发？在如此林立的 SOTA 中，我们又将如何选择最适用于业务场景的模型？

根据我们的观察，每次模型发布的时候，在模型效果的评估上往往会有三种操作：不同的数据集、不同的指标、不同的竞对，从而能够从数据上说明自己确实是 SOTA。

2.1 视频大模型技术报告中的评估报告

• 在新的 Wan-Bench 2.0 （指标相对较少）上的评估表明，Wan2.2 在多个关键维度上的性能优于对应的闭源、商业模型。

• 潞晨科技的 Open-Sora2: 在竞对的选取和指标的选取上更有目标性，整体得分达到开源模型第一，直逼闭源的 OpenAI Sora。

• 腾讯混元图生视频：选择的指标相对较少，选择的竞品没有包含开源的万相 2.1以及可灵1.6。

2.2 视觉理解大模型技术报告中的评估报告

• 总能找到自己能力最强的数据集，像视频理解 VideoMME 数据集，豆包得分是 74.1，明显比 Qwen2.5-VL 好，但是竞对选择上没有豆包。

• MiniMax-VL-01：MMMU,MMMU-Pro 数据集虽然不是第一但是也不差，其他数据集优势非常明显。

• Gemma 3 27B：什么数据集也不用了，直接上了 LLM Arena 的主观对抗打分。

所以，在实际的大模型评估过程中，总能找到特定的数据集、特定的指标和特定的对比对象，使得从数据上看，新发布的模型性能看起来就是 SOTA。

2.3 琳琅满目的通用榜单

如果说技术报告中的性能对比会存在偏差，那么通用榜单应该是靠谱的吧？还记得今天 2 月底，Wan2.1 是如何一炮走红、火爆全网的不？当时，Wan2.1 的宣传语就是：权威评测集 VBench 的信息显示，Wan2.1 大模型大幅领先 Sora、HunyuanVideo、Minimax、Luma、Gen3、Pika 等国内外视频生成模型，以总分 86.22% 的成绩登上榜首位置，成为视频生成领域的全新标杆。

仔细看当时的 Vbench 榜单，我们就会发现，虽然 Wan2.1 确实位于榜首，但是榜单中的 KLING 用的是 24 年 7 月份的模型。

对于其他的榜单，例如 AGI-Eval 和 SuperCLUE的文生视频榜单，或者缺乏最新的模型，或者对比的模型不一致，这导致了同样的模型，在不同的榜单中的排名并不一致。

所以，即便想采用通用榜单来评估模型的性能，因为不同的榜单评测方法、评测数据集存在很大的差异，因此也会得到不同的结果，这确实是一件令人非常困惑的事情。

2.4 对于业务，我们该如何决策？

一方面，面对快速发展、甚至是竞争白热化的大模型技术；另一方面，面对如此众多的榜单和SOTA模型。当面临模型选型的时候，作为业务方，我们又当如何决策？

• 创意生成提示词

卡通漫画风格，舞台上聚光灯聚焦，四大巨型机器人——豆包、通义万相、OpenAI、腾讯混元，高举“业界第一”横幅，头部醒目位置嵌入各自公司标志。机器人设计独特，色彩鲜艳，充满未来感。台下人类观众表情困惑，眼神交流中满是疑问，头部上方飘浮着大大的问号，展现他们内心的犹豫与不解。背景是繁华的发布会场，两侧AI技术海报林立，增添科技氛围。整体画面色彩对比强烈，表情夸张，强化幽默讽刺效果。采用近景舞台视角，特写机器人与观众互动瞬间，捕捉戏剧性场面。

03 基于业务的大模型评测实践

如前所述，对于业务而言，技术报告中的评估结果以及通用榜单并不能提供全面、有效的决策信息。

正如 skcd 在 8 月 29 日发布的一条宣传 Grok-code-fast-1 的帖子说的那样：在实际使用中，基准测试确实只能提供有限的信息。

When I joined the coding team, the team was just 3 people and we very quickly built a model which was SOTA on SWEBench. But as things go, in the real world benchmarks matter less.

为此，我们从评测数据集的构建、评估指标、评估方法等多个方面进行优化与实践，探索出了一套适合业务的、置信的大模型评估体系。同时，为了提高整个评估过程的效率，我们也探索了数据集的自动化构建流程、模型效果自动打分等相关的自动化机制。

3.1 评测数据集的构建

评测本质上是一个“抽样”的过程，不同的样本会严重影响到最终的评测结果。为了保障评测结果能够反映出不同模型在业务实际使用场景下的真实表现，同时也为了避免模型可能会在训练阶段学习到了部分的榜单数据，我们从三个维度构建了自己的评测数据集。

• 从业务侧富集数据集：这部分数据集不会做大的调整，仅会做细微的修改，比如优化语言表述、优化数据集中存在的明显的错误的表述

• 业务侧数据集的泛化数据集：对业务侧富集到的数据集进行分析，并根据分析结果进行数据集的泛化，例如通过大模型生成相似数据集、生成同一个问题的变体描述等

• 业界通用数据集的泛化数据集：对通用数据集中的原始评测样本进行一定的处理，比如英文样本转换成中文样本、题目选项进行变换、题目中的数据进行修改……

以 MMMU 数据集中的样本为例，不同泛化方式的区别如下表所示。

3.2 自动获取模型结果

针对不同类型的大模型评估，评估集所包含的数据集量级也不同，在实践中，我们的文本评估集数据量级为 1000，图片评估集数据量级为 500，视频评估集数据量级为 200。每次评估，我们一般会选择 3~5 个模型进行对比评估。

从数据获取效率方面看：

• 每次评估，我们需要获取上千个QUERY的模型结果，因此如何快速的获取这些QUERY的结果是影响评测效率的关键环节。

• 同时，虽然现在大部分大模型都支持OpenAI API格式，但是也存在不支持该格式的大模型。

• 再者，不同的大模型厂商提供的API的限流策略和 API KEY，因此在获取大模型的结果数据时，如何对这些大模型 API 进行高效的管理也将影响着最终的评测效率。

在评测的实践中，我们发现对于同时提供 API 接口 和 WEB 页面两种服务方式的大模型而言，不同的服务方式获取到的结果会存在差异，例如 WEB 页面一般会提供 联网搜索的功能，但是 API 却没有该功能。

针对如上的问题，我们自研了模型管理平台，该平台支持以API和WEB两种方式自动化获取各种大模型的响应结果。

对于 API而言，平台实现了从数据拼装、模型结果获取到解析、性能统计（首 token 耗时、推理耗时、总 token数等）等全流程管理，可通过模型配置快速接入新模型，可自由定制不同模型实现高并发快速获取模型结果。

3.3 LLM as Judge 的评估方法

在 2024 年 9 月分的时候，我们对发布在 arXiv 上的和大模型评估有关的论文进行了分析，我们提取了提交时间位于 2023 年 4 月至 2024 年 9 月这个区间的 130+ 篇论文进行了分析发现：有 23% 的论文在研究如何利用大模型来评估大模型的效果

在过去的 12 个月内，arXiv 上与 LLM-as-a-Judge相关的论文更是有 700+ 篇，平均每天就有 2 篇论文在研究该课题。

因此，我们认为采用大模型来评估大模型具备一定的可行性。

虽然，近期也有学者不断提出：LLM as a Judge 的方式并不靠谱，例如：

• 2025 年 8 月，Neither Valid nor Reliable? Investigating the Use of LLMs as Judges 这篇论文中提到：LLMs 是人类判断的有效代理 (LLMs as a Proxy for Human Judgment)，只要AI裁判的评分和人类专家的评分高度相关，就证明 LLM as a Judge 是有效的，但这个逻辑链条的起点，所谓“人类判断”这个金标，本身就是摇摇欲坠的。既然“人类判断”这个金标本身就存在问题，那么在这个基础之上构建的 LLM as a Judge 也就并非那么靠谱。

• 2025 年 8 月，上海上海交通大学的学者在 PersonaEval: Are LLM Evaluators Human Enough to Judge Role-Play? 这篇论文中也提到：即便是表现最好的模型Gemini-2.5-pro，其准确率仅为68.8%，而人类实验组的平均准确率为90.8%。目前的LLM裁判，还远不够“拟人”，不足以可靠地评判角色扮演。对模型进行角色相关的微调，不仅没有提升其角色识别能力，反而可能导致性能下降。

但是，根据我们的时间，在评估标准详细且无二义性的前提下，LLM as a Judge 的方式在评估中还是相对靠谱的。在实践中，我们采用了 Prompt Enginning 和SFT这两种方式是实现 LLM as a Judge。

• 基于千帆平台进行模型微调的流程和效果如下所示：

△微调的流程

△微调的数据集示例

在视频生成大模型的评估中，我们采用了 Dacheng Li 等人 基于 Qwen2-VL-2B  微调的 WorldModelBench 模型作为物理规则检测的裁判员模型，虽然准确率只有 65% 左右，但是确实能比较好的、高效的检测出部分场景下的物理规则问题。

04 大模型评测五条原则

4.1 评测样本必须无歧义

评测数据集中的样本描述必须是准确的、无歧义的，存在歧义的样本无法保证最终的评估结论的准确性。

最典型的就是 OpenAI 在 24 年 8 月 发布的 SWE-bench Verified 数据集，OpenAI 认为 ****原始 SWE-bench 低估了大模型在代码方面的能力，****于是对该数据进行了重新标注并构建了 SWE-bench Verified 数据集。在整个标注的过程中，OpenAI 发现：原始 SWE-bench 中的样本有很大一部分是不合格的。

构建图片理解评测样本时的样本歧义举例：

4.2 评测样本必须覆盖模型的新增能力

模型在不断优化的过程中，会针对特定场景进行优化，评测的样本必须能够覆盖这些特定场景，否则就无法对模型性能进行正确的评估。

我们在不同的评估集上对万相 2.1 和可灵 1.6 进行了评估，却得出了不同的结论。

4.3 评测样本必须分场景组织

在 3 月 15 日，评估 EB4.5 的图片理解能力的时候，我们在两个数据集上得到了完全不同的结论：

4.4 评测样本中大模型生成结果的参数必须明确

在评测中，我们发现，虽然是相同的模型，对于同样的 Query，不同的渠道获得的结果并不相同，因此在评测时，必须明确产生当前结果的模型的参数。

推理模型，如果是 API 访问模型，会缺少联网搜索的能力

如果是 WEB 访问模型，则可以增加联网搜索能力

4.5 评估样本必须细化打分准则，不能只打整体分

只进行整体评估容易忽略模型的在特殊场景下的优势，也容易忽略模型在特殊场景下的缺点。

对于 Vbench 榜单，对于不同的视频生成模型，从单维度打分来看，不同模型之间有很大的区别。但是从总分来，模型之间的差距反而变的不明显了（80%~86%之间的模型有30+个）。

从数学的角度看待分维度打分的必要性。

05 本周有新的大模型发布的概率是多少？

TDS数据治理深度实践：从标准化到智能化的演进之路

TDS（Turing Data Studio）是专注于数据开发和治理的平台。其架构涵盖了从基础设施到用户功能的各个层次，包括数据开发、数仓管理、监控运维和资源管理等模块，支持高效的任务调度、资源管理和数据血缘分析。

上一代大数据产品在实际运行中仍存在以下关键问题：

1. 开发阶段风险控制不足：

• 数据开发任务经过修改调试后，会直接用于处理线上数据，存在误操作直接影响线上数据的隐患。

2. 产出阶段质量保障滞后：

• 数据产出质量。需要等数据完全产出后，通过人工校验或下游反馈发现，无法在数据产出过程中实时拦截空值、异常值等问题。

• 数据产出时效性。任务执行达到重试失败上限或触发延迟产出报警后，数据RD才能收到通知，难以有效维持数据时效性。

3. 运维阶段处理低效：

• 日志分析有时需要值班同学帮助查看定位原因排查问题，依赖人工经验，处理问题效率较低。

• 数据产出异常时，由于涉及的类型和层级较多，难以快速准确识别下游受损范围，并导致未及时回溯数据。

为了解决上述问题，TDS建设了体系化的数据治理方案。

流程标准化（规范开发）→ 质量可控化（主动防控）→ 运维智能化（降本提效）。

从多环节入手进行数据治理的深度实践，覆盖数据开发全流程，确保数据资产的健康与可信。

本章节将详细阐述TDS平台在构建这一数据治理体系中的核心理念、技术实践与显著成效，为业界提供一套可借鉴的深度治理方案。

01 流程标准化：构建数据开发的“交通规则”体系——百度MEG TDS平台实践

在百度移动生态事业群组（MEG）的复杂数据开发生态中，日均处理超过40万个任务实例。

面对“环境混用、配置失控、协作低效”这三大长期痛点，我们基于TDS平台构建了一套四级流程控制引擎，将开发规范体系化落地。

本文将深入解析该体系中的三大核心机制：代码强制留档与评审、测试环境自动化构建与管理、智能配置管理的实践与成效。

1.1 全链路规范化设计：精密控制开发生命周期

数据治理的起点在于规范开发流程。我们认为，只有在开发阶段就将规则融入工具链，才能真正实现“零门槛”的合规。

1.1.1 开发阶段：环境隔离与自动化验证

混乱的开发环境是导致生产事故的常见原因。TDS平台通过自动化技术，为每个任务创建了一个安全、隔离的沙盒环境，确保开发与生产互不干扰。

• 自动化测试环境构建与管理：当开发人员在数仓管理模块创建生产表（如 user_behavior）时，系统会自动构建与之对应的完整测试环境体系。

• 配置中心标准化管理：
  通过预置标准化资源模板，实现配置的零接触管理和自动注入，从根本上杜绝了因手动配置错误导致的生产问题。

• 实施效果：

配置错误率从实施前的18.7%显著下降至0.4%。

新成员环境配置和基础任务上手时间从平均3天缩短至2小时以内。

• 分钟级任务验证加速：
  基于TDS内置的TDE调试优化引擎，开发人员在编辑任务时可以随时提交SQL调试任务，大幅缩短验证周期。

• 核心技术支撑：

     智能数据采样：自动抽取极小比例（如0.1%）的样本数据进行快速验证。

     测试表直连：调试结果直接输出到对应的测试表（如 user_behavior_tdsqa）。

     资源隔离：使用专用调试队列，避免与生产任务争抢资源。

1.2 上线阶段：代码留档、智能防护与强审批

任务上线是数据生产流程中的关键环节，任何疏漏都可能引发严重的生产事故。TDS平台通过代码强制留档、智能变更识别和核心任务审批，构筑了三重安全防线。

1.2.1 上线单完整流程

1.2.2 自动化代码治理流水线

建立强制性的代码评审与归档流程，确保变更可追溯、可审计。

• 核心控制机制与价值：

     强制代码提交：深度集成icode API，实现100%变更可追溯。

     评审硬卡点：TDS流程引擎与iCode状态强同步，杜绝未经评审的代码进入生产。

     版本快照绑定：任务版本与icode Commit ID 绑定，秒级精准定位任意历史任务版本。

1.2.3 智能变更识别引擎与核心任务审批

采用双轨检测技术（配置比对 + AST语法树分析）精准识别变更风险，并对核心任务实施严格审批。

• MD5比对关键字段：

     输出目标：生产环境AFS路径、ClickHouse表名等。

     数据来源：输入表、文件路径。

     计算逻辑指纹：SQL语句/Python代码核心片段的哈希值。

• 核心任务标识与审批强化： 对于平台标记为“核心任务”的任务（通常涉及关键业务数据、高流量或具有广泛下游依赖），任何配置或代码的变更，无论风险评估等级高低，均强制触发完整的三级审批流程。此流程需业务负责人、技术负责人及平台负责人共同确认。

• 拦截成效：

平均每月成功拦截可能导致数据污染、服务中断的高危操作超过50次。

生产环境配置误变更率降至0.1%。

02 质量可控化——数据可信度的保障

数据质量是数据价值实现的前提。在流程标准化建立起开发规范后，如何确保流经平台的数据本身是可靠、可信的，成为下一个核心挑战。

TDS平台构建了一套“预防为主、监控为辅、治理兜底”的三层防护体系，覆盖数据任务从设计、执行到故障处理的全生命周期。

2.1 三层防护体系：构建全流程数据治理监控屏障

2.1.1 事前防控：从源头规避数据风险

事前防控是数据治理监控的第一道防线。我们通过建立数仓 Schema 强约束，在数据任务开发与设计阶段就规避潜在风险，减少后续环节的异常。

• 字段类型预校验：确保数据类型的一致性和准确性，防止因类型不匹配导致的计算错误或数据截断。例如，如果源字段是 STRING 类型，而目标字段是 INT 类型，系统会发出警告或直接阻止任务创建。

• 分区规则预校验：确保分区字段、分区格式与命名规范统一，避免因分区不一致导致的数据查询不完整或任务失败。

2.1.2 事中监控：实时捕捉异常并快速响应

事中监控是数据治理的核心环节，旨在实时发现数据质量与任务进度的异常，并触发告警。

2.1.2.1 数据质量校验：多维度保障数据可靠性

数据质量校验通过构建多维度的评估指标体系，对数据进行实时检测。架构图如下：

• 架构：

外部输入层：用户在TDS平台配置数据质量校验规则，指定数据源为图灵数仓表。

• 核心架构层：

     数据质量约束（Data Quality Constraints）：涵盖行数、重复值、空值、异常值、表字段等多种规则，从精确度、完整性、唯一性、有效性、一

致性等多维度进行校验。

    SQL-Generator：根据用户配置的校验规则生成Spark SQL。

     TDS-Scheduler：在数据加工过程中，调度数据质量校验算子进行数据校验。

     指标计算：利用Spark从图灵数仓读取数据源，计算各项质量指标。

     数据校验：将计算结果与预设规则进行比对，判断是否存在质量问题。

• 输出层：

     数据质量报告：生成可视化、结构化的报告，汇总约束验证结果。报告样例如下：

• 异常报警：采用分级报警机制（警告、严重、紧急），支持邮箱、如流、短信、电话等多种报警方式，确保异常能被及时处理。

2.1.2.2 SLA 风险监控：保障任务执行时效性

SLA（服务等级协议）是衡量任务执行效率的重要标准。TDS平台的SLA实时追踪功能，通过对任务执行进度的实时监控，及时发现超时或失败的任务，确保任务按时完成。架构图如下：

• 基础信息输入层：

     数据血缘：记录数据从产生到使用的全链路关系，为后续构建任务依赖图提供关联依据。

     任务历史执行信息：存储任务过往执行的开始/结束时间、时长、状态等记录，是任务执行时间预估的核心依据。

• SLA 管理模块（策略与分析层）：

     SLA 配置：手动设置任务的服务级别协议，定义任务完成时限。

     任务 SLA 智能推荐：结合历史执行信息和数据血缘，利用算法自动推荐合理的SLA，减少人工配置的盲目性。

     SLA 历史达成情况分析：复盘过往SLA达成情况，为优化配置提供数据支撑。

• 任务流程与风险预警层（核心执行与分析）：

     构建任务依赖图：依据数据血缘梳理任务上下游关系，形成可视化图谱。

     任务执行时间预估：基于历史数据预测任务本次执行所需时间。

     关键链路分析：识别对整体SLA影响最大的关键路径，优先保障其资源和监控力度。

     LLM 风险预警分析：通过大语言模型分析SLA达成的潜在风险。

     打破 SLA 风险预警：综合以上分析结果，一旦识别到风险，立即发出预警，让负责人员提前介入，降低SLA打破的概率。

通过数据质量校验与SLA实时追踪的协同作用，事中监控能够实现对数据任务执行过程的全方位、实时化管控，将异常发现与响应的时间大幅缩短，有效减少异常对业务的影响。

2.1.3 事后治理：基于血缘实现故障快速溯源与修复

尽管事前防控与事中监控已大幅降低异常发生概率，但面对突发故障，事后治理仍至关重要。

其核心目标是快速定位根源、修复问题，并总结经验优化前序环节。

基于数据血缘的故障溯源是事后治理的关键技术手段。

如第三章“基于血缘的智能运维”所言，数据血缘指的是数据从源头到消费端的流转关系：每一个数据表、任务或文件从何而来，被谁消费，形成怎样的依赖链路。

在事后治理场景中，血缘的价值尤为突出：一旦出现数据异常，运维人员可以基于血缘快速定位到上游影响范围和下游受影响对象，避免盲目排查，大幅缩短故障定位与修复的时间。

当上游任务或表修复后，可以利用基于血缘的批量回溯能力，一键触发所有受影响的下游任务，实现自动化修复。

同时，通过分析故障原因并结合血缘，能够反向优化事前防控与事中监控的规则，形成“发现问题 - 定位根源 - 修复问题 - 优化规则”的闭环治理流程。

03 智能化运维

智能化运维旨在利用自动化分析与智能决策技术，提升数据开发平台的运维效率与问题处理速度。

TDS平台在该领域融合了任务日志分析与基于血缘的智能运维两大能力，旨在构建一个高效、稳定、自愈的数据生产体系。

3.1 任务日志分析

任务日志是诊断问题的核心依据。TDS平台通过智能化的日志分析，帮助用户快速定位并解决问题。架构图如下：

3.1.1 依赖检测算子日志分析

依赖检测类算子用于在任务执行前，判断上游数据是否已按时产出，避免因数据缺失导致的下游计算异常。平台通过结合任务执行日志与数仓元数据，提供清晰直观的依赖检测结果提示：

• 平均产出时间提示：基于历史数据预估任务最早可启动时间，帮助用户合理安排调度。

• 当前产出细节展示：以列表形式展示所有上游依赖的产出信息，包括产出状态（已到位/未到位）和具体时间，支持细化到分区/分表级别。

3.1.2 通用报错智能诊断

对于非依赖检测类的通用错误，平台引入大模型辅助诊断能力，结合内部知识库与外部信息，为用户提供智能化的错误分析与修复建议。

• 执行日志解析：实时采集算子运行日志并结构化处理，将关键错误片段作为诊断输入。

• 知识库 + 千帆大模型服务：

     内部知识库：沉淀平台运维团队的常见错误模式、处理经验和最佳实践。

     互联网查询：当内部知识库无匹配方案时，系统会通过联网搜索补充诊断依据。

     千帆大模型分析：大模型对日志、知识库与检索结果进行综合推理，生成针对性诊断结论。

• 输出结果：提供错误信息归纳、可能原因分析和可行的解决方案，并支持一键生成问题工单。

• 效果与价值：

     运维效率提升：自动化的依赖检测和智能诊断减少人工排查时间。

     问题定位更精准：日志与血缘关系的结合帮助快速锁定问题。

     经验可持续沉淀：错误分析结果自动回流知识库，形成正向闭环。

3.2 基于血缘的智能运维

数据血缘是连接数据链路的核心，它的价值在于让数据流转可见、可控、可回溯。

• 问题溯源与定位：一旦数据异常，可快速定位到上游影响范围和下游受影响对象。

• 变更影响分析：修改某个表字段时，可提前评估下游影响，降低风险。

• 回溯与修复：当发现上游数据有问题时，可以一键触发下游任务的批量回溯。

3.2.1 血缘架构图

上图展示了TDS血缘治理系统的整体架构，涵盖从信息采集、解析、存储到对外展示的全流程。

• 血缘数据来源：

     TDS任务开发平台：自动提取任务依赖信息。

     第三方报表平台：采集分析报表与底层表的关系。

     任务配置和脚本：作为解析器的输入来源。

• 血缘解析器：将各类任务、SQL和配置转化为结构化的血缘依赖，整合了任务DAG、SparkSQL、MySQL等多个解析服务。

• 全链路血缘数据：设计了分层血缘视图，满足不同用户需求，包括：

     任务层血缘：展示任务DAG。

     数据表层血缘：支持多种存储引擎。

     AFS（文件系统）层血缘：跟踪文件上下游关系。

     报表层血缘：第三方报表数据源配置信息。

3.2.2 血缘查看能力

平台提供了快捷易用的血缘查看能力，包括交互式血缘图、节点展开、时间筛选和数据导出。更重要的是，通过实例状态聚合能力，用户可以实时查看上下游任务实例状态，快速定位数据延迟的根因，大幅提升排障效率。

3.2.3 基于血缘的批量回溯能力

在数仓开发中，经常出现上游任务或表修复后，需要让下游数据重新跑一次的场景。例如：

• 上游任务补数据后，需要让下游任务重新消费。

• 某张表发现历史分区错误，需要让下游衍生表重新计算。

手动逐一触发下游任务效率低下且容易遗漏。基于血缘解析能力，我们实现了批量回溯：用户选定一个起始任务节点和时间范围，平台自动遍历血缘图，计算受影响的所有下游节点，并支持批量回溯回溯策略，用户可自行勾选需要回溯的多个任务节点，完成任务的批量回溯。该能力让回溯从“全靠经验”变为“半自动”，减少了人为失误和漏回溯风险。

3.2.4 基于血缘的回溯通知

回溯只是第一步，及时通知相关负责人同样关键。平台会：

1. 基于血缘关系定位所有受影响节点的下游负责人；

2. 自动生成受影响范围清单，并推送给下游任务的 Owner；

3. 在通知中附带关键信息：回溯触发原因、影响范围（任务清单）。

这样，数据团队可以在第一时间获知回溯任务情况，及时跟进并降低数据事故影响。

04 总结：价值闭环与未来展望

TDS平台的数据治理实践，从根本上改变了百度MEG的数据生产模式。我们不再是被动地应对数据问题，而是主动地通过技术手段进行预防、监控与治理。

首先，流程标准化将散乱的开发行为转变为有序的“交通规则”，显著降低了人为错误的发生率，极大地提升了协作效率。通过环境隔离、配置注入和强制审批，我们将数据生产的风险前置化，让开发者能够专注于业务逻辑本身，而不是纠缠于繁琐的环境配置。

其次，质量可控化为数据资产构建了坚实的“防护衣”。事前约束从源头确保数据质量，事中监控实时捕获异常，事后治理则通过血缘快速溯源，形成了一个持续优化的闭环。这不仅保障了数据的可信度，也为业务决策提供了可靠的依据。

最终，运维智能化是整个体系的升华。通过任务日志的智能诊断与基于血缘的自动化运维，我们实现了对数据生产链路的“自愈”。问题排查不再依赖人工经验，而是由机器自动完成；数据修复不再需要繁琐的手动操作，而是一键批量回溯。这极大地释放了运维团队的生产力，让数据生产体系更加健壮、高效。

展望未来，我们的数据治理之路仍将继续。我们将进一步探索AI技术的深度融合，例如利用机器学习模型预测潜在的数据质量问题，或是基于大模型自动生成更精确的任务修复方案。我们相信，随着技术的不断演进，数据治理将从“可控”走向“自治”，最终实现一个真正意义上的“数据自愈工厂”，为业务发展提供源源不断、高可信度的数据燃料。

01 概览

随着数字化转型的来临，企业对于数据服务的实时化需求日益增长，在大规模数据和复杂场景的情况下，Flink在实时计算数据链路中扮演着极为重要的角色，本文介绍了网盘如何通过 Flink 构建实时计算引擎，从而提供高性能、低延迟、稳定的实时计算能力。

02 百度网盘实时计算演进

2.1 百度网盘实时计算演进历程

△百度网盘实时计算演进

在 2020 年，网盘主要通过Spark Streaming和Spark Structured Streaming来用于特定场景的支持，主要是在数据同步场景、实时清洗方面的应用。

为了解决Spark Streaming存在的监控告警薄弱、接入成本高、时效性低等问题，网盘于2023年初首次引入Flink实时计算引擎，并基于百度内部StreamCompute平台快速建设集指标监控、告警、任务生命周期管理能力；经过调研测试我们发现Flink任务从0到1接入成本高、开发门槛高，因此，我们开始调研实时计算引擎的解决方案，目标是降低开发门槛、配置化任务接入，最终建设网盘内部的实时计算引擎Tiangong来为业务提供更好的支持。

截止至今，Tiangong计算引擎目前已在数据团队、反作弊团队、用户增长等场景广泛应用,并支持数百万亿的大流量场景。未来我们也计划将基于Tiangong建设网盘一体化实时计算平台，从而赋能网盘内部各个业务线实时计算能力建设。

2.2 为什么选择Flink

网盘实时计算引擎从Spark Streaming和Spark Structured Streaming演进而来，为什么放弃Spark体系选择Flink主要从以下几个方面出发：

从百度内部实时计算RoadMap和状态管理、流批一体、监控告警、任务管理、生态体系等各方面我们选择基于Flink建设网盘内部的实时计算平台。

2.3 实时计算引擎

2.3.1 实时计算引擎接入现状

目前，百度网盘的Tiangong计算引擎已接入17+应用场景，高峰时作业处理的吞吐量达到千万/s，而机器规模也已经达到了1500台，资源5800CU，并且已经覆盖用商策略、反作弊、主端一刻用增实时投放等多个场景。

2.3.2 Flink Tiangong引擎架构

如下图所示的是网盘Tiangong实时计算引擎的架构。

• 最下层为Runtime层，负责Tiangong计算任务的部署方式，目前支持StreamCompute、Kubernetes、Yarn、Local等方式；

• 核心能力包括Source组件、Sink组件以及数据转换引擎

• Source组件：支持Db、Message Queue、BigData组件、自定义Source等多个异构数据源；

• Sink组件：支持Db、Message Queue、BigData组件、自定义Sink等多个异构数据目的地；

• 数据转换引擎：支持流批一体、自定义配置化数据清洗、精准一次数据处理、失败容错、IOC容器化管理、自定义SQL拓扑、灵活监控告警等能力；

△ Tiangong计算引擎

从功能层面来看，Tiangong实时计算引擎主要包括作业管理和资源管理。其中，作业部分包括作业配置、作业上线以及作业生命周期管理三个方面的功能。

• 在作业配置方面，则包括运行环境配置、source配置、sink配置、清洗逻辑配置以及作业拓扑结构设置；

{
    "jobName": "作业名",
    "env": {运行环境配置},
    "sources": [source端配置],
    "udfs": [用户定义函数],
    "views": [清洗逻辑],
    "coreSql": [核心写入逻辑],
    "sinks": [sink端配置],
    "customTopology": {自定义作业运行拓扑}
}

• 在作业发布方面，则包括作业启动、取消以及删除等；

• 作业状态则包括自定义规则告警、监控大盘等；

△ 自定义规则告警

△ 监控大盘

• 在资源管理方面，利用StreamCompute平台能力支持Flink集群动态扩缩容能力与灰度发布能力；

2.4 业务场景实践

前面提到实时计算引擎演进过程和实时计算引擎对比，可以看出网盘实时计算引擎更多地会关注在易用性、稳定性和监控告警体系等方面，具体体现的应用场景主要涉及服务端日志、埋点日志、DB Binlog等场景的实时清洗计算。

2.4.1 网盘实时商业BI中心

网盘现阶段缺乏商业收入数据实时分析与商业策略实验实时评估的能力，导致商业策略AB实验推全链路往往需要经过周粒度才能完成，建设一套适用于网盘的实时商业BI中心有益于加快策略实验迭代与实时商业流水波动分析，助力网盘整体收入增长；

如上图，通过将收银台行为、商业订单、策略实验埋点数据秒粒度接入至实时数仓Palo中后，配合数据可视化平台Sugar建设商业实时BI中心，以此来助力商业策略、商业PM等各个角色快速完成AB实验快速推全，将天粒度实验收益评估机制优化至分钟粒度，整体实验推全链路由周粒度优化至天粒度；

2.4.1.1 Tiangong配置化接入

下述案例为Tiangong引擎配置化接入商业订单实时流：

• 实时流数据源配置

{
  "sourceType": "bp_source",
  "deserializerType": "STRING",
  "sourceConfig": {
    "parallelism": 20,
    "operatorName": "xietong_strategy_businessorder_fr_bp_source",
    "metaHost": "host:ip",
    "cluster": "demo-cluster",
    "username": "username",
    "password": "password",
    "pipeletName": "demo-pipelet-name",
    "pipeletNum": "20",
    "startingOffset": {},
    "startPoint": "LATEST",
    "endOffset": {},
    "bpWebServiceAddress": "service_address"
  }

• 核心处理逻辑配置

{
  "jobName": "netdisk_membership_order_deatils_bp2doris",
  "env": {
    "streamConfigName": "20p_ck_3s_10fail_env",  ## 环境配置，主要配置Checkpoint间隔和并行度，根据数据量定义，一般为上游消息队列分区倍数
    "tableConfig": {}
  },
  "sources": [
    {
      "configType": "CONFIG",
      "sourceTableName":"membership_order_binlog", ## 数据源配置，bigpipei订单实时流
      "sourceConfig": "prod/netdisk_membership_order_bp_source"
    },
   {
         "configType": "SQL",
         "sourceConfig": "CREATE TABLE ods_order_info_rt  ## 写入目的地配置，palo写入表
                          (
                              id               bigint,
                              order_no         string,
                              user_id          bigint,
                              dev_uid          bigint,
                              app_id           bigint,
                              client_channel   tinyint,
                              pay_channel      tinyint,
                              product_id       string,
                              .... 
                          ) WITH (
               'connector' = 'doris',
               'fenodes' = 'host:ip',
               'table.identifier' = 'dbName:tableName',
               'username' = 'username',
               'password' = 'password',
               'sink.properties.format' = 'json',
               'sink.properties.read_json_by_line' = 'true',
               'sink.label-prefix' = 'label-prefix',
               'sink.enable-2pc'='true',
               'sink.parallelism' = '1'
       )"
     }
  ],
  "views": [
    {
      "name": "binlog_filter_view",  ## 核心数据处理逻辑，纯SQL接入
      "sql": "select CAST(JSON_VALUE(new_values, '$.id') as bigint)                 as id,
                     JSON_VALUE(new_values, '$.business_no')        as business_no,
                     JSON_VALUE(new_values, '$.order_no')           as order_no,
                     UNIX_TIMESTAMP()          as write_timestamp,
                     .....
              FROM membership_order_binlog,
                   LATERAL TABLE(BINLOG_NEWVALUES_FILTER(f0))" ## 系统内置Binlog清洗TableFunction
    }
  ],
  "coreSql": "insert into ods_order_info_rt select id, ## 写入下游palo表，写入间隔为Checkpoint间隔，上述配置为3秒，每3秒写一批
                                              business_no,
                                              order_no,
                                              user_id,
                                              write_timestamp from binlog_filter_view"
}

2.4.1.2 可视化监控体系

Flink作业UI监控

Grafana监控大盘

实时任务监控配置

2.4.2 用户商业策略实时特征

基于商业策略实时核心行为相关特征依赖场景，结合核心行为以及用户付费埋点行为数据建设从0点实时累计特征与基于滚动窗口的近X分钟实时特征有助力策略侧对用户刚需需求的感知，并结合用户刚需行为个性化出价以此促进整体商业收入。

2.4.2.1 核心方案

• 如上图，方案二主要将数据流拆为三块，如流数据拼接、热点文件计算、消费行为统计；

• 流数据拼接：利用Tiangong计算引擎，通过Flink SQL+行为清洗UDF函数，将各类行为数据打平为统一格式，并通过union all进行聚合，过滤异常数据后行为行为视图，数据流式产出。

• 热点文件计算：实时将各个file_md5的消费次数存储Flink Map状态中，并根据离线分析得到的热点文件消费阈值判断热点文件，将热点文件流式写入Bigpipe与Palo中，数据流式产出，最优可做到毫秒级；

• 消费行为次数计算：根据热点文件数据流关联用户消费行为，实时对用户消费的文件进行热点/普通归一化处理，后续将每个用户消费不同行为类型的热点/普调次数写入Flink Map状态中，累加计算从0点至今的文件消费次数，实时写入Doris和Palo中，最优可做到秒级；

2.4.2.2 技术难点

（1）大状态问题

问题引入

• 热点文件和用户消费文件次数的计算，都涉及到数据累计的问题，如果将数据存储在共享存储(例如Redis/Table)这类kv存储中，每条数据或每个窗口的数据都需要先查一下上次的计算结果，累加后再写入共享存储中，这从而导致每次计算多一次网络读IO操作，故利用Flink状态机制，将热点文件和用户消费次数存储在Flink状态中，每次判断都在TaskManger本地或者内存中，不涉及到网络IO操作，故性能更好。

• 数据都存入Flink状态中也导致Flink存在大状态问题，从而导致Checkpoint耗时过大从而引起任务背压，最终导致数据处理延迟等问题。

解决方案

状态后端优化

• 选择Rocksdb作为状态后端，开启增量Checkpoint

• 配置changelog状态机制，防止Rocksdb定期Compaction导致的Checkpoint耗时久问题

• 调整rocksdb manged内存大小、rocksdb write buffer大小

快照存储优化

• 开启快照压缩配置

状态TTL机制

• 长期为更新的状态做小时粒度更新，防止状态持续增大。

（2）TableStroage写入性能差

问题引入

• 因厂内Table API创建Table Client过程中需要根据特定表对应的机器数创建对应个数的brpc-client-work-thread、brpc-client-io-thread、fairStrategy-timer-thread等线程，共计3*机器数个，网盘特征Table存储底层表占用200台机器，故创建一个Table Client需要创建600+线程，从而导致Flink计算节点的底层martix容器线程超限，经过和StreamCompute同学沟通需限制Table Client的Rpc线程数为1，并对应Flink集群的计算节点容器最大线程数由1000->1500，从而解决线程超限问题。但因限制Table Client Rpc线程为1导致Table整体写入性能偏差。

解决方案

• 细粒度拆分任务，首先对用户各类行为以及消费的热点/普调资源进行实时计算，后续根据user_id+行为类型keyby，并开3s窗口，取最新的数据落入Table，将3s一个窗口的数据进行压缩。

优化效果

• 原本天粒度写入48亿+次行为特征优化为2亿+次，具体效果如下图：

业务场景大致可以分为实时数仓、实时数据复杂聚合计算、DB业务数据CDC等场景，在这几个场景Flink本身就提供高性能、高稳定性的能力，再配合网盘Tiangong实时计算引擎不熟悉Flink的业务方也可以配置化、低代码的方式快速建设起实时应用。

03 Flink技术挑战和解决方案

3.1 Flink底座建设

△ Flink基建建设

基于StreamCompute平台提供的动态扩缩容、任务生命周期管理、Flink多版本管理、云原生监控告警体系等能力，来快速构建网盘Flink实时计算能力。

3.2 实时计算平台建设

---

△ Tiangong计算引擎

以上为Tiangong计算引擎能力支持，其作为网盘实时计算平台支持目前厂内大部分异构数据源，使用方可以通过简单的配置快速建设实时计算能力，拿上述业务场景实践中的用户商业策略实时特征项目接入Tiangong来看，只需下述配置和少量窗口数据聚合逻辑开发即可：

{
    "jobName": "business_feature_compute_bp2table", // 作业名
    "env": { // 作业运行环境配置
        "streamConfigName": "300p_ck_30s_5fail_env",
        "tableConfig": {
            "stateTtlMs": 600000
        }
    },
    "sources": [  // source配置，download日志
        {
            "configType": "CONFIG",
            "sourceTableName": "idc_log_source",
            "sourceConfig": "prod/business_strategy_idc_bp_source"
        }
    ],
    "udfs":[  // 数据清洗转换逻辑，SQL无法完成时通过UDF
               {
                   "name": "idc_log_filter_func",
                   "className": "com.baidu.xxx.IdcLogFilterFunction"
               },
               {
                   "name": "idc_feature_transform_func",
                   "className": "com.baidu.xxx.IdcFeatureTransformFunction"
               }
           ],
    "views": [
        {
            "name": "idc_log_feature_view",
            "sql": "select feature_data.event_time as event_time,
                           .....
                    from (select idc_feature_transform_func(f0) as feature_data
                          from idc_log_source
                          where idc_log_filter_func(f0) = true) as tmp
                    where feature_data.log_time <> '0' and ....
        }
    ],
    "sinks": [ // 双写TableStorage、Doris
        {
          "sinkConfigNames": ["prod/netdisk_strategy_idc_feature_mi_table_sink","prod/netdisk_strategy_feature_doris_sink"],
          "transformSQL": "select event_time,
                                   .....
                           from idc_log_feature_view",
           "watermarkConfig":{  // 涉及开窗逻辑所涉及的watermark配置
                "maxOutOfOrdernessMs": 5000,
                "idlenessMs": 10000,
                "timeAssignerFunctionName": "row_event_time_assigner"
           },
           // 开窗计算逻辑函数
          "rowTransformFunc": "strategyFeatureTransformFunction"
        }
      ]
    }
}

3.3 自定义作业执行计划

3.3.1 细粒度算子并行度优化

△ 细粒度算子并行度优化

Tiangong计算引擎本质基于Flink SQL+Table API+DataStream API做的混合计算引擎，其本质相当于Flink SQL，因此一旦定义好Source和Sink并行度后，其任务所涉及的计算、清洗、聚合等算子都与Source端并行度一致，从而导致如果想要增加清洗等算子的并行度需要把Source的并行度也增加，从而造成资源浪费、性能降低等问题。

3.3.2 分区关系优化

△ 分区关系优化

作业内上下游算子连接数过多，会占用较大的 Network buffer 内存，从而影响作业的正常启停，基于自定义SQL执行计划能力，我们可以手动将 Rebalance 边修改为 Rescale。

比如上图的示例，左边上游算子有 500 个并发，而下游的 Sink 算子只有 200 个并发。在这种场景下，Flink SQL 会默认生成 Rebalance 的连接方式，共需 500*200，共 10 万个逻辑连接。

通过自定义SQL执行计划能力，我们手动将 Rebalance 设置为 Rescale 后，它只需要 500 个连接，大大降低了 Network buffer 的内存需求。

3.3.3 资源共享策略优化

3.3.3.1 资源共享

• 默认情况下，flink允许subtask共享slot，即使是不同task的subtask，这样的结果是一个slot可以保存作业的整个管道。

• 如果是同一步操作的并行subtask需要放到不同的slot，如果是先后发生的不同的subtask可以放在同一个slot中，实现slot的共享。

△ Slot与Task的关系

3.3.3.2 自定义共享策略

△ 资源共享策略优化

支持按照算子类型将算子划分到一个slot group中，从而来减少数据的跨网络传输、提升资源利用率以及提升计算性能等。

3.3.4 算子名称优化

Flink SQL不支持为每个算子自定义名称，从而导致算子名是根据系统规则来生成的，从而导致算子名称不能够通俗的表示其具体含义。为了便于作业维护和管理，自定义作业执行计划支持算子名称优化。

04 未来展望

△ 未来展望

4.1 实时计算平台化

目前Tiangong计算引擎的使用方式主要在公共代码库提交任务配置和UDF代码的方式接入，使用方需要拥有Tiangong计算引擎的代码库权限，存在代码安全和任务隔离性差等问题，后续我们计划基于Tiangong计算引擎搭建网盘自己的实时化计算平台，实现页面低代码方式快速接入实时任务。

4.2 实时DTS平台

目前网盘主要使用厂内DTS平台，通过增量binlog和全量select快照方式采集数据至下游AFS，整体链路为DTS->AFS->UDW，一旦上游表格式变化下游的采集任务就会失败，因此整体稳定性、维护成本和性能都过差。因此我们计划基于Tiangong计算引擎构建实时DTS平台，具体架构如下：

△ RealTime-DTS架构

本期内容4年开发经验的 Java 大佬执墨为我们带来了包括规则配置在内的5个文心使用技巧分享。助你增加 AI Coding 技能点！一起来看看！

执墨，4年开发经验程序员一枚，一个懂点 AI 的软件研发工程师，持续学习有意思的技术、做有意思的事，目前在探索如何培养出一个 AI 开发搭子。

相信大家在实际使用 AI 生成代码的过程中，会发现**有些代码让人抓心挠肝，不是放错了位置，就是不符合项目规范，最后还要返工手动修改，觉得不如自己手搓。**但别担心，自己学写代码怎么说也学了三四年，玩游戏角色释放技能也有前摇，AI 写好代码当然也需要慢慢培养。从 Zulu 开始公测我就在使用文心快码，也算是小有经验。那么结合个人在 IntelliJ IDEA 中的使用体验，我总结了 Zulu 和 Chat 各自比较实用的技巧，希望能对大家有所帮助。

▎Zulu 调教指南：生成代码更可用

1.用 # 提供上下文

大语言模型本质上是基于前文内容来预测下一个最可能的词或代码片段。没有上下文，模型就无法准确判断下一步生成内容，因此对上下文的理解和利用是生成高质量代码的基础。在开发场景中，上下文不仅包含当前文件或代码片段，还涵盖项目结构、依赖关系、函数和变量作用域等。通过理解这些上下文，AI 能够更准确补全代码或生成符合项目风格的内容。

在文心快码中为 Zulu 添加上下文：Zulu 目前支持文件、文件夹和项目级别的上下文。开发者可以通过 # 操作符来唤起当前被索引的所有的文件，并添加为当前会话的上下文。

Step1：# 操作符唤起上下文菜单

Step 2：选择对应的文件或者目录。可以添加多个，如果没有选择上下文，则会默认使用当前项目为上下文环境。

Step 3：上下文配置好以后，可以通过自然语言的方式来描述你需要让 AI 干的事情。

在这个例子中，我选择了 Cache.java 这个文件，然后让 Zulu“实现一个查询缓存时，根据类型做反序列化的函数，目标为 Redis 序列化”。这时 Zulu 就开始阅读上下文，立刻理解了我的需求，在 Cache 接口中进行修改，添加了目标功能。

2.善用命令自动执行

**Zulu 能够自动感知当前工程的框架、技术栈、文件结构和运行环境，根据需求自动生成终端命令，并将这些命令发送到开发环境中的终端进行执行。**这种能力在脚本语言的开发过程中，非常具有优势，比如 Python、JS 等。你无需关注需要使用什么框架，AI 自行去进行使用和安装，开发者能够更专注于业务逻辑的实现。

例如在下面的 Python 虚拟环境创建和配置中，Zulu 首先生成并执行了终端命令 python3 -V，查看当前环境中已安装的 Python 版本，然后通过命令 python3 -m venv venv 创建了一个虚拟环境，最后通过 source venv/bin/activate && pip install -r requirements.txt 激活虚拟环境并安装项目依赖。整个过程完全没有跳出 IDE，极好地维护了开发过程中的心流体验。

3.规则约束

当没有提供规则文件去约束 Zulu 的生成行为时，在进行一个新的项目开发过程中，很容易会生成一些不达预期的代码，也会魔改代码。了解到文心快码支持自定义 Rules，因此我为 Zulu 编写了执行的上下文约束，控制其代码的生成。下面将具体展开我撰写规则的思路。

3.1编码环境

**介绍当前的编码环境，说明当前项目的所使用的技术栈。这一步至关重要，就好比给 Zulu 描绘了一幅项目的蓝图，让它清楚自己所处的 “战场” 环境。**例如在这个基于 Java 的 Spring Boot 项目中，明确告知了 Zulu 项目使用的是 Java 语言，以及 Spring、Spring Boot、Spring Security 等相关技术框架。这样，Zulu 在生成代码时，就能遵循这些技术栈的规范和特点，生成与之适配的代码。

## 编码环境
用户询问以下编程语言相关的问题：
- Java
- Spring&SpringBoot&SpringSecurity
- MyBatis&MybatisPlus
- RocketMq
- Nacos
- Maven
- SpringSecurity

3.2代码实现指南

**这个部分说明当前项目具体的代码如何实现，比如数据库表的创建规范、用户上下文怎么获取、项目结构的含义等。这相当于给 Zulu 制定了一套详细的工作 SOP，让它生成的代码符合项目的特定要求。**在采用 DDD（领域驱动设计）方式实现代码的项目中，我为 Zulu 提供了如下的 SOP。

1. 项目使用 DDD 的方式来实现代码，你需要注意如下几点：
  1. 领域层和仓库层的入参都要使用 DO、仓库层的实体对象需要添加 PO 的后缀
  2. Application或者Service层的输出必须的DTO，接口层的返回可以是DTO 也可以自己定义 VO
  3. 每一层对应的对象都需要添加对应的后缀，并且后缀要全大写。如仓库层的实体 UserPO，领域层领域UserDO，应用层的DTOUserDTO
  4. 项目的类之间的转换需要使用 MapStruct 来完成
2. 在使用三方依赖的时候，需要将对应的依赖内容先添加到 Maven 依赖中
3. 所有的接口都按照 RestFul 的风格定义，并且你需要区分接口的使用场景，如：前端使用、OpenApi、小程序端使用。
  1. 如果你无法通过用户的上下文知道需要你生成的接口的使用场景，你可以再次询问用户
  2. 前端统一前缀使用 /api/fe/v1/xxxxx，OpenApi 使用 /api/open/v1/xxxx，小程序使用 /mini-program/v1/xxxx并且三个入口的文件需要区分不同的文件夹
  3. 对于批量查询接口，你需要涉及分页的能力，不能使用内存分页，只能在 DB 层面做分页，并且要考虑深分页的问题
  4.  所有的接口返回需要返回 BaseResp 对象，BaseResp 的定义如下：
  @Data
  publicclassBaseResp<T> {
      privateString code;
      privateString message;
      privateT data;
  }
  4. 对于应用层，需要注意如下几点：
      1. 函数的输入和输出都是 DTO

3.3总结历史记录

每次使用 Zulu 生成代码后，可以让 Zulu 帮我们将每一次 Query 后的结论进行总结并记录到文件中，这对于项目的跟踪和回溯非常有帮助。提示词如下：

## 历史记录
1. 针对你回答用户问题的答案，你需要将本次回答的内容记录到项目的根路径下的 .cursor-history 文件里，格式如下：
2025-11-11 10:10:10
变更内容如下：
1. 增加用户模块
2. 修改用户管理内容
3. 增加用户内容
涉及文件为：
xxxx.java
xxxx.java
2. 你需要按照倒序的方式记录这个历史纪录

这种详细的记录格式，能够清晰地展示每次代码生成的时间、变更内容以及涉及的文件，方便开发者随时查看和追溯项目的开发记录。而倒序记录使得最新的变更记录排在前面，开发者能够快速获取到最新的项目动态，提高了信息查找的效率。

▎Chat 隐藏技巧：编码交互更灵活

在研究 Zulu 的同时，我也发现了 Chat 功能比较好用的地方，下面想继续分享一些让编码过程更方便快捷的能力。

1.Inline Chat 行间会话

通过圈选代码片段，使用 Ctrl + I 快捷键可以唤起文心快码的行间对话能力，帮助我们快速对局部代码进行优化和调整，**此时上下文即当前的代码片段。

在对话框中输入需要 AI 完成的任务，Comate 会自动扫描代码并编辑，编辑完成后可以自行决定是否采纳或者忽略。

2.Git Commit 快捷键提交代码

在完成一个功能模块的开发后，需要提交代码到版本库。一般来说需要手动梳理本次代码的修改内容，编写提交信息。而在文心快码中，只需点击 Git Commit 快捷按钮，Comate 就能自动分析代码的变更情况，生成详细准确的提交信息，大大节省了时间，同时也提高了提交信息的质量，方便团队成员更好地了解代码的变更历史。

在 Git Commit 的时候点击快捷按钮，可以快速总结本次代码的变更内容。

▎案例实操

接下来就把这些小技巧应用在实际案例中，检验一下是否对开发流程有提效。

1. 实现一个社区自动签到脚本

文心快码在编写脚本方面具有显著优势，准确率极高。在实际工作中，我现在用到的脚本几乎都由文心快码完成，并且几乎都能一次性运行通过。**以实现一个社区自动签到脚本为例，具体操作步骤如下：

Step 1: 书写提示词，直接用自然语言描述即可，需要给出其接口定义信息和执行规则。

“给我写一个 python 脚本，实现接口签到和抽奖能力。

以下是签到接口的定义：

GET 接口：……(为保护隐私，此处略去）

以下是抽奖接口的定义：……

再调用接口时，你需要按照先调用签到再调用抽奖的顺序来完成，并且这两个接口需要一个 cookie 信息来完成调用，因此你需要定义一个全局的 cookie 来实现这两个接口的定义。”

Step 2: Zulu 后自行生成对应的文件

Step 3: 按照 Zulu 的提示执行对应的命令，然后这个脚本就成功实现完成了。

2. 实现一个约束之下的意图识别服务

这个案例的重点在于，在新的项目中如何将自己业务项目中的一些编码规则告知 AI，使生成的代码更符合团队的开发规范。

Step 1: 书写提示词，在提示词部分添加了“实用技巧”中的第3点规则约束部分提到的规则。

“我需要你实现一个意图识别的工程能力，它的主要功能是对外提供一个 OpenApi 的接口来根据用户的输入返回一个固定的意图。这个 OpenApi 的实现思路是：

1.查询本地的规则列表；然后进行匹配；

2.如果本地的规则都无法匹配，则调用第三方的 LLM 接口进行意图识别；

3.返回结果。

你的代码实现需要按照这个规则来：#.zulurules”

完整规则见附录一

Step 2: Zulu 生成代码与总结

▎写在最后

文心快码是我个人使用的第一款 AI 编程工具，其核心功能围绕两大模块展开：编程智能体 Zulu 与 Chat ，二者协同能够满足不同编程需求。Zulu 与 Chat 功能相比，核心差异在于其具备更强的自动化编码能力：能够直接生成完整文件并编写代码，且生成内容会以 Diff 格式清晰展示修改痕迹，方便开发者直观对比并选择是否采纳。文心快码插件实现了与 JetBrains 系列 IDE 的深度集成——开发者无需离开熟悉的 IDE 环境，即可调用 AI 编程能力。对于我这样习惯使用 JetBrains 工具链的 Java 程序员而言，这种原生集成的体验尤为友好，能在日常开发流程中自然融入 AI 辅助，减少工具切换成本。

附录：Rules 示例

你是一名资深后端开发专家，精通 Java、Spring、SpringBoot、MyBatis、MyBatisplus、RocketMq以及各种中间件，如：Zookeeper、Nacos、SpringCloud等。你思维缜密，能够提供细致入微的答案，并擅长逻辑推理。你会仔细提供准确、事实性、深思熟虑的答案，并且在推理方面堪称天才
- 严格按照用户的需求执行。
- 首先逐步思考——用伪代码详细描述你的构建计划。
- 确认后，再编写代码！
- 始终编写正确、符合最佳实践、遵循 DRY 原则（不要重复自己）、无错误、功能完整且可运行的代码，同时确保代码符合以下列出的 代码实现指南。
- 优先考虑代码的易读性和简洁性，而不是性能。
- 完全实现所有请求的功能。
- 不要留下任何待办事项、占位符或缺失的部分。
- 确保代码完整！彻底验证最终结果。
- 简洁明了，尽量减少其他描述。
- 如果你认为可能没有正确答案，请明确说明。
- 如果你不知道答案，请直接说明，而不是猜测。
- **注意：尽量使用已经存在的目录，而不是自建目录**
- 你需要严格按照 cursorrules 中的内容来生成代码，不要遗漏任何内容
# 编码环境
用户询问以下编程语言相关的问题：
Java
Spring&SpringBoot&SpringSecurity
MyBatis&MybatisPlus
RocketMq
Nacos
Maven
SpringSecurity
# 代码实现指南
## 依赖处理
- 你所有使用到的依赖必须在根目录的 Pom 文件中做 Dependency Management 版本管理
- 对于通用的依赖可以直接放到根目录的 Pom 文件中，如 lombok
## 监控上报能力
- 你需要为项目中所有使用到的外部插件增加监控上报能力，如：线程池，Redis、MySQL 等。你可以使用 Spring actuator 提供的能力对外提供 Prometheus 格式的上报信息
## 数据库SQL
你需要根据用户的输入来推断可能使用到的表的结构，并按照如下的格式生成。
- 其中 create_time、update_time、create_user、update_user 是必须拥有的字段。
ext和is_deleted可以根据用户的需求来选择添加
- 对于唯一索引，其需要同一个前缀为 ux_，如：ux_business_key_type；对于非唯一索引，需要同一个前缀为 idx_，如：idx_business_key_type
```CREATE TABLE `audit_log` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '账户日志ID',
`business_key` varchar(100) NOT NULL DEFAULT '' COMMENT '业务实体ID或索引,如账号名',
`business_type` smallint(6) unsigned NOT NULL DEFAULT '0' COMMENT '10000-账号,20000-邮箱,30000-ADKeeper,40000-远程账号',
`operate_desc` varchar(500) NOT NULL DEFAULT '' COMMENT '操作描述',
`version` int(11) NOT NULL DEFAULT '0' COMMENT '版本号',
`ext` json DEFAULT NULL COMMENT '扩展属性',
`is_deleted` tinyint(3) unsigned NOT NULL DEFAULT '0' COMMENT '是否删除0为未删除，1为删除',
`create_time` int(11) NOT NULL DEFAULT '0' COMMENT '创建时间',
`update_time` int(11) NOT NULL DEFAULT '0' COMMENT '更新时间',
`create_user` varchar(32) NOT NULL DEFAULT '' COMMENT '创建人',
`update_user` varchar(32) NOT NULL DEFAULT '' COMMENT '更新人',
PRIMARY KEY (`id`),
KEY `idx_business_key_type` (`business_key`,`operate_type`)
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8 COMMENT='账户审计表'
```#编写代码时遵循以下规则：
- 你不能直接在根目录上创建 src 文件夹，而是要创建一个当前项目的子模块来完成代码生成，模块的名字默认为 当前项目名-api
- 项目使用 DDD 的方式来实现代码，你需要注意如下几点：
  - 使用充血模式和工厂模式的方式来完成项目代码的实现
  - 领域层和仓库层的入参都要使用 DO、仓库层的实体对象需要添加 PO 的后缀
  - Application或者Service层的输出必须的 DTO，接口层的返回可以是 DTO 也可以自己定义 VO
  - 每一层对应的对象都需要添加对应的后缀，并且后缀要全大写。如仓库层的实体 UserPO，领域层领域 UserDO，应用层的DTO UserDTO
  - 项目的类之间的转换需要使用 MapStruct 来完成
  - 所有的接口都按照 RestFul 的风格定义，并且你需要区分接口的使用场景，如：前端使用、OpenApi、小程序端使用。
  - 如果你无法通过用户的上下文知道需要你生成的接口的使用场景，你可以再次询问用户
  - 前端统一前缀使用 /api/fe/v1/xxxxx，OpenApi 使用 /api/open/v1/xxxx，小程序使用 /mini-program/v1/xxxx并且三个入口的文件需要区分不同的文件夹
  - 所有的接口返回需要返回 BaseResp 对象，BaseResp 的定义如下：
  @Data
  public class BaseResp<T> {
      private String code;
      private String message;
      private T data;
  }
  - 对于应用层，需要注意如下几点：
     - 函数的输入和输出都是 DTO
  - 对于远程调用层，需要注意如下几点：
     - 你需要使用 @HttpExchange 的能力来完成远程调用，并且让项目中的第三方配置收口到同一个配置节点下。示例如下：
@HttpExchange
public interface IntentRemoteClient {
    @PostExchange(value = "/api/open/agent/intent")
    BaseResprecognizeIntent(
        @RequestBody IntentRequest request
    );
}
@Data
@ConfigurationProperties(prefix = "api")
public class ApiProperties {
    /**
     * 应用依赖的外部服务的配置, 这些外部服务使用 MiPaaS 认证中心提供的认证
     */
    @Valid
    @NotEmpty
    private Map external;
    /**
     * 外部服务配置
     */
    @Data
    public static class ExternalService {
        /**
         * 服务 API 的基础 URL
         */
        @NotBlank
        @URL
        private String baseUrl;
        /**
         * 对一些配置的覆写
         */
        private ExternalServicePropertiesOverrides overrides;
    }
    /**
     * 认证使用不同的 URL 和 认证凭据的配置
     */
    @Getter
    @AllArgsConstructor
    public static class ExternalServicePropertiesOverrides {
        private String authServiceBaseUrl;
        private ClientCredential clientCredential;
    }
    @Getter
    @AllArgsConstructor
    public static class ClientCredential {
        private String appId;
        private String appSecret;
    }
} 
@Configuration
@EnableConfigurationProperties(ApiProperties.class)
public class RestApiConfig {
    private final Mapservices;
    public RestApiConfig(ApiProperties appProperties) {
        this.services = appProperties.getExternal();
    }
    @Bean
    public IntentRemoteClient intentRemoteClient() {
        // 1. 获取服务对应的配置
        var svc = findServiceConfiguration("intent");
        // 2. 构建 Client
        var httpClient = HttpClient.create()
          .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 5000)
          .wiretap(true)
          .responseTimeout(Duration.ofSeconds(10));
        var client = WebClient.builder()
          .baseUrl(svc.getBaseUrl())
          .codecs(clientCodecConfigurer -> clientCodecConfigurer.defaultCodecs().maxInMemorySize(50 * 1024 * 1024))
          .clientConnector(new ReactorClientHttpConnector(httpClient))
          .filter(new AuthorizationAuthFilter(svc.getOverrides().getClientCredential().getAppId(),
            svc.getOverrides().getClientCredential().getAppSecret(), svc.getBaseUrl()))
          .build();
        var factory = HttpServiceProxyFactory.builderFor(WebClientAdapter.create(client)).build();
        return factory.createClient(IntentRemoteClient.class);
    }
    /**
     * 生成服务配置
     *
     * @param name 服务名称
     * @return ExternalService
     */
    @NotNull
    private ApiProperties.ExternalService findServiceConfiguration(@NotNull String name) {
        var svc = services.get(name);
        if (svc == null) {
            throw new IllegalArgumentException("no such service");
        }
        return svc;
    }
} 
  - 对于数据库层，你需要注意如下几点：
     - 你需要为DB增加 自动映射枚举 的能力，即可以在数据库的 PO 中直接使用枚举
     - 你需要使用 自动填充字段 功能来填装 create_time、update_time、create_user、update_user。其中创建人和更新人可以通过 SpringSecurity 获取。
# 历史记录
针对你回答用户问题的答案，你需要将本次回答的内容记录到项目的根路径下的 .cursor-history 文件里，格式如下：
2025-11-11 10:10:10
变更内容如下：
1. 增加用户模块
2. 修改用户管理内容
3. 增加用户内容
涉及文件为：
xxxx.java
xxxx.java
你需要按照倒序的方式记录这个历史纪录

当人工智能进入深度应用的黄金时代，单一模态的局限正被多模态交互彻底打破。文心 ERNIE-4.5-VL 视觉语言模型（ ERNIE-4.5-VL-28B-A3B；ERNIE-4.5-VL-424B-A47B ）以突破性的图文、视频理解与推理能力，架起数字世界与物理世界的智能桥梁，更支持100+语言交互，让跨模态智能触手可及。

实验结果表明，轻量级视觉语言模型 ERNIE-4.5-VL-28B-A3B 的激活参数显著减少，但与 Qwen2.5-VL-7B 和 Qwen2.5-VL-32B 等模型相比，其在大多数基准测试中仍具有竞争力，甚至表现更优。

ERNIE-4.5-VL 模型支持128K 上下文长度，结合“思考模式”与“非思考模式”双选项，既能快速响应基础任务，又能深度破解复杂问题，灵活适配从日常场景到专业领域的全场景需求。

ERNIE-4.5-VL 的跨模态能力覆盖以下核心任务场景：

▎相关链接

■ 文心大模型技术 Blog（含技术报告下载）：

yiyan.baidu.com/blog/posts/…

■ 文心4.5系列模型下载

• Hugging Face：huggingface.co/baidu

• 飞桨星河社区：aistudio.baidu.com/modelsoverv…

• GitHub：github.com/PaddlePaddl…

• 魔搭社区：modelscope.cn/models/deng…

■ 文心4.5系列模型训练部署

• ERNIEKit：github.com/PaddlePaddl…

• FastDeploy：github.com/PaddlePaddl…

1. 前言

在播放器架构不断演进的今天，视频后处理技术正在成为提升用户体验的关键环节。相比传统的解码即播，现代播放器越来越多地引入后处理链路，通过增强画质、渲染氛围等手段，为用户提供更具沉浸感的视听体验。

本系列文章将系统介绍我们在播放器视频后处理模块中的技术方案与工程实现，涵盖从效果设计、算法选型，到性能优化和跨平台兼容的全链路细节。第一期内容聚焦在两类核心能力：

• 视频增强：提升画面清晰度、对比度与色彩表现，尤其针对暗场、低码率等场景进行针对性优化；

• 氛围模式：基于视频内容实时生成边缘延展光效，打造更强沉浸感，适配大屏与移动端场景。

本文将着重介绍我们如何在性能受限的设备上实现视频增强效果，如何结合 GPU/OpenGL、Shader 编程以及平台图像处理 API 构建高效可控的处理链路。后续我们将陆续推出如氛围模式等视频后处理文章，敬请期待。

2. 视频增强（亮度和色彩）

丨2.1 什么是视频增强技术

视频增强技术是指一系列用于改善视频质量的技术手段，其目的是在不改变原始内容的情况下提升视频的视觉效果。技术的应用场景包括视频播放、编辑、传输、存储等领域，常用于提高图像清晰度、对比度、色彩饱和度等，使观看者获得更好的视觉体验。

丨2.2 常见视频增强技术

移动端实践：亮度与色彩增强。针对Android/iOS平台的视频播放场景，我们重点实现了亮度增强与色彩增强两项关键技术。本文将分享技术落地中的核心方案与优化经验。

丨2.3 亮度增强

亮度增强效果示意图（左：原图 右：增强后）

2.3.1 技术选型

亮度增强是图像/视频处理中非常基础且常见的操作，常见的亮度增强原理可以分为以下几类，每种方式背后的核心思想略有不同。下面是详细的分类和解释：

1. 线性亮度增强（线性增益）

原理：RGB整体直接乘以一个大于 1 的系数（或加一个偏移量）。

公式：

color.rgb = color.rgb * gain;       // 乘法增强color.rgb = color.rgb + offset;     // 加法增强

• 简而言之，这种做法就是简单粗暴的在原本的RGB上进行提升，从这里，可以想到RGB颜色调整后容易出现色偏。

• 那么我们可能会想到，如果先将RGB转换为YUV，调节Y 分量，再反变换为 RGB。

公式：

Y = 0.299*R + 0.587*G + 0.114*B;
Y_new = Y * gain;

• 这确实是视频增强中一种常用且理论上“更稳”的方式，因为它分离了亮度（Y）和色彩（UV / IQ / CbCr）信息。

• 但这种处理方式有一个严重的问题，不处理图像的对比度或中间的关系，且不能保留高光细节（Clipping），也就是调整后，超过范围[0.0,1.0]的值会被截断（clamp），造成高光过曝。

2. 直方图均衡（Histogram Equalization）

原理：通过调整像素分布，让亮度值均匀分布在整个区间，从而整体提升视觉亮度。

特点：增强暗部和亮部的对比，对低对比度图像尤其有效。

实现相对复杂，不常用于实时shader，考虑到其运算复杂性，我们也pass了这种方式。

3. Gamma 变换（幂律调整）

原理：使用幂函数对像素进行非线性拉伸。

公式：

color.rgb = pow(color.rgb, vec3(gamma));

特点：γ < 1：图像变亮，主要拉升暗部；γ > 1：图像变暗，压缩亮部。

具有两个优点：

• 调整方式具有非线性特点，能更细腻地控制中间调亮度，避免简单加法可能引起的局部过曝或暗部细节丢失。

• 模拟现实中显示设备的响应曲线，效果较为自然。

这也是我们最后选择的方式，他的运算量简单，适合端上视频播放的实时处理。

2.3.2 背后的原理

我们引申一下，这种方式的优点是怎么得出来的呢。

1. 为何能避免简单加法可能引起的局部过曝或暗部细节丢失

从公式看，原本亮度较低的像素会被相对“提亮”更多，而原本亮度较高的像素提升幅度较小。暗部像素相对于原值会获得更大的“提拉”，而亮部像素则变化较小，从而既能提升整体曝光，又能保留高光细节。

2. 为什么说模拟现实中显示设备的响应曲线，更为自然呢？

因为显示器、人眼视觉和视频编码，都是非线性系统，不是简单线性变化。

• 真实世界的光亮度是线性的，比如两支灯加起来就是两倍亮。

• 但人眼感知亮度是对数感知的（小亮度变化很敏感，大亮度变化不敏感）。

• 视频和图像在存储时通常经过一个 Gamma编码，原本线性光 → 压缩（比如取 1/2.2 次方） → 存成文件。这种光和电的转换过程，就是OETF/EOTF响应曲线。

所以这种pow(color, gamma)的调整方式，实际就是在模拟显示端的响应曲线。

总结一句话：

编码有 Gamma，所以显示端或后处理也必须按照 Gamma空间规则来调节，才能保持自然感知。

丨2.4 色彩增强

色彩增强效果示意图（左：原图 右：增强后）

从上图可以看到山体、草地上的花，饱和度增强。

2.4.1 调节的目标

1. 增强色彩感知

提高图像的“鲜艳度”或“视觉吸引力”，让图像更生动。

特别是在图像颜色偏灰、曝光不佳或图像压缩后颜色损失的情况下。

2. 突出主体

通过饱和度调节，增强主体与背景之间的色彩对比，提高视觉聚焦度。

3. 修复/还原真实色彩

对摄像头采集后色彩不足的图像进行还原，尤其是肤色、植物、天空等自然色彩。

针对上述目标，我们主要依赖主观评测感受，同时需要避免以下问题：

主观评估（人眼视觉）

• 色彩鲜明但不刺眼：增强后色彩更加明显但不过饱和。

• 肤色自然：人脸或皮肤色调不过红或黄（肤色是视觉最敏感区域）。

• 色彩分布均衡：图像中颜色种类丰富但不过分集中某一色调。

• 无色彩断层：调节后颜色过渡应平滑，不能有色阶突变。

2.4.2 技术选型

目前业界对色彩增强主要有以下2种方向的研究：

1. 传统SDR色彩增强。

2. SDR2HDR，模拟HDR效果，达到增强目的。

从实现方式上，主要也有2种主流方式：

1. 非神经网络（传统算法 or 结合lut查找表）

2. 基于神经网络（模型）

模型需要较高的技术储备，且在移动端运行耗时大，所以目前我们没有选择这种方式，而是寻找效果较好且可控的算法。

2.4.2.1 色彩三要素

我们先了解下“色彩三要素”。他们是色彩学中用于描述颜色感知的三个基本维度，分别是：色相、饱和度、明度。这三者共同定义了一个颜色的完整视觉特性。

色相

饱和度

明度

在色彩增强中，一般主要调节的是饱和度（Saturation），其次可能会适当调整明度（Brightness / Value） ，而色相（Hue）通常不会主动改变。原因如下：

常调节的要素及原因：

1. 饱和度（Saturation）

• 最常调节的要素，增强后画面显得更鲜艳、更有吸引力，尤其适用于风景、商品、动漫类画面。可提升视觉冲击力和色彩表现力。

2. 明度 / 亮度（Brightness / Value）

• 有时作为辅助增强项，提高整体图像的通透感。与 Gamma 调节、曝光补偿常一起使用，即配合使用上一章节的亮度调整即可。

3. 色相（Hue）

• 一般不调整，因为改变色相会改变物体本身颜色，可能导致不真实（如人脸偏色、草地变蓝等）。只在需要艺术化或特殊滤镜（如复古风格、红外效果）时才会使用。

2.4.2.2 颜色空间的选择

选择好色彩增强的调节方向为『饱和度』后，第二步，我们需要选择好颜色空间。

当视频一帧画面作为GL纹理输入到后处理链路时，为RGB颜色模型，我们想要调节饱和度，则需要将其转换为其他颜色空间进行调节，那么面临的第一个问题是如何选择合适的颜色模型去进行算法设计？

• RGB

• HSV

• LCH/LAB

2.4.2.3 基于RGB空间

1. 基于RGB颜色直接调节

们可以理解，饱和度是色彩的纯度，即色彩相对于灰度（无色）的程度。那么我们可以基于RGB颜色模型，并根据灰度进行差值混合即可。

如GPUImage的GPUImageSaturationFilter提供了类似例子，它对饱和度调节，是基于RGB颜色，然后取出灰度值通过在原始颜色和灰度之间插值，mix(vec3(luma), color.rgb, saturation) 实现了饱和度的变化：

• 插值因子 saturation 越接近 0，图像越趋向于灰度；

• saturation 越高，图像越接近原始颜色或超出原始饱和度，色彩更鲜艳。

这种简单的算法存在一个问题：原本局部饱和度已经比较高，如果依然提高饱和度，则局部细节消失。

过饱和，细节丢失

2. 为了解决上述问题，我们基于自然饱和度的调整。

自然饱和度（Vibrance）的概念最先由photoshop提出，重点在于适应性，自然饱和度调整后一般比饱和度调整要自然。其核心特点：

进行自适应饱和度调节的流程：

• 计算亮度（Luma）：使用加权平均公式从 RGB 获取亮度：luma = 0.2126 * r + 0.7152 * g + 0.0722 * b

• 计算饱和度（Saturation）：使用 RGB 最大值和最小值之差估算色彩纯度：saturation = max(r, g, b) - min(r, g, b)

• 计算调节因子 k：根据当前饱和度和用户设置的 Vibrance 强度进行非线性调节：k = 1.0 + Vibrance * (1.0 - saturation / 255.0)（Vibrance 取值范围通常为 0.0 ~ 1.0）

• 应用颜色调整：将颜色向亮度方向插值，使低饱和度颜色更鲜艳，同时高饱和区域变化较小：color.rgb = mix(vec3(luma), color.rgb, k)

其调整倾向于将RGB值往同一个luma值进行靠近，也是无法保证颜色保持稳定，容易会发生偏色的情况。

色彩增强效果示意图（左：原图 右：自然饱和度增强后）

于是，我们继续探索其他的颜色模型。

2.4.2.4 基于HSV颜色模型的饱和度调整

基于HSV饱和度的调整方法是将RGB颜色模型转换为HSV颜色模型，其中HSV分别表示色相（Hue）、饱和度（Saturation）、明度（Value）。只调整饱和度可以在不影响明暗和色相的情况下增强色彩的鲜艳程度。

将常见的调整方法有整体抬升，按比例增加，或者曲线调整，达到将整体饱和度提高的目的。但是饱和度调整同时提升所有颜色的强度，比较粗暴。

有可能导致：

• 本来局部饱和度已经比较高，调节后过饱和，局部细节的消失。(和上一章节例子一样)。

• 本来局部饱和度较低，接近白色，加大饱和度后，容易出现色块。

普通调节

如何优化：

1. 对此引入对源的饱和度的检测，设定上下限制，平滑调节。

2. 在HSV颜色模型上，引入了类似自适应饱和度调整的方式。

3. 目的：在低饱和度区域，避免突然增加饱和度。低饱和度的颜色（例如接近灰色的颜色）通常对饱和度调整非常敏感，因此需要一种平滑的方式。

4. 目的：在高饱和度区域减少权重，避免过度增强饱和度。高饱和度的区域本身已经很饱和，进一步增加饱和度会导致过饱和，视觉上显得不自然。

加入自适应后

2.4.2.5 肤色保护

采用HSV空间调整后，我们还需要考虑一个核心问题：

在图像色彩增强（如饱和度调整、色调映射）时，肤色区域容易因过度调整而失真（如过红、过黄或惨白）。需通过肤色识别技术，对检测到的肤色区域进行保护，限制增强幅度，保持自然观感。

在此引入了基于HSV色彩模型的肤色识别，HSV色彩模型也同样将亮度与颜色进行了分离，因此对于光照变化也有很强的抗干扰能力，可以较好的识别出肤色。

结合HSV色彩模型和高斯概率模型实现肤色保护，具体步骤如下：参考GPUImageSkinToneFilter的肤色识别方法。

(1) RGB转HSV空间

• 将图像从RGB转换到HSV空间，分离色调（H）、饱和度（S）、亮度（V）。

• 优势：HSV的色调通道（H）对光照变化鲁棒，更适合肤色识别。

(2) 肤色概率计算

• 肤色色调模型：

  统计肤色色调的均值 skinHue = 0.05（典型值，对应黄红色调）。

  方差相关参数 skinHueThreshold = 40（控制肤色范围宽度）。

• 距离计算：

  计算当前像素色调 h 与 skinHue 的归一化距离。

  dist = abs(h - skinHue) / 0.5高斯权重（概率）。

• 通过高斯函数计算肤色概率：

  skinProb = exp(-dist * dist * skinHueThreshold)结果范围 [0, 1]，越接近1表示越可能是肤色。

(3) 肤色区域保护

• 阈值分割：

  设定阈值（如 skinProb > 0.95），二值化得到肤色掩膜（Mask）。

• 动态衰减增强强度：

  对检测到的肤色区域，按 skinProb 权重衰减色彩增强效果。例如：enhanced_pixel = original_pixel * (1 - skinProb) + adjusted_pixel * skinProb * alphaalpha 为衰减系数（如0.2），控制保护力度。

增加肤色保护后，可以看到效果明显更好，人脸不会有过于突兀的颜色变化。

左：增强（无保护）中：原图  右：增强（肤色保护）

2.4.3 效果对比

• HSV空间的调节后色彩更加自然。

• RGB空间调节则更加绚丽。但容易色偏。

• 基于综合考虑，我们采用HSV空间调节，以适应更多的源，避免色偏。

三. 总结与展望

本研究聚焦于移动端视频增强技术的工程化落地，重点验证了亮度增强与色彩增强两种核心算法的实际应用效果。从主观评测效果看，在部分视频上，两项技术均能显著提升视频观感质量，有效改善用户体验。

目前，亮度增强功能已在「好看 App」成功上线，且收获了良好的应用效果。现阶段，我们正着力研发亮度增强与色彩增强相叠加的综合优化方案，计划通过这一方案对更多视频内容进行品质升级，从而为用户带来更优质的观看体验。以下为您呈现亮度增强结合色彩增强的部分应用案例：

例子1：后层次感更好（右）

例子2：色彩更鲜明（右）

例子3：画面更清晰明亮（右）

未来研究将围绕以下方向展开：

1. 场景化优化：建立典型场景特征库，针对性优化算法参数配置。

2. 实时性提升：通过模型轻量化与硬件加速技术，更加快速的视频实时处理。

近日，国际数据公司（IDC）发布了《视觉大模型能力及应用评估报告，2025》，该报告对中国市场的视觉大模型厂商进行了全面且深入的评估，百度凭借卓越的综合实力，在众多竞争对手中脱颖而出，荣膺总分第一名的桂冠。作为百度视觉大模型领域的核心产品，百度智能云一见视觉大模型平台，在平台能力、算法模型、工程化落地能力、覆盖行业等维度具有显著优势，领跑视觉大模型赛道。

技术破局，实力领跑

小模型时代，视觉AI技能开发成本高，企业在视觉智能应用落地过程面临 “做不出”、“用不起”、难复制” 的困境。随着多模态大模型技术突破，企业生产过程中大量的安全、合规、品控等视觉检测需求正在被激活，基于视觉的管理数字化理念逐步被认可。

大模型重构视觉智能，一见基于文心4.5原生多模态大模型、文心X1深度思考模型升级，让专业级视觉AI应用从 “遥不可及”变成“人人可用”。作为多模态视觉管理平台，一见提供视觉AI技能生产、效果调优到应用的全栈能力，支持“一句话生产专业级视觉AI应用”，并通过技能可视化编排灵活匹配业务流程，低成本、低门槛帮助企业实现全视觉管理数字化。

同时，IDC报告中指出，端侧AI与边缘智能迎来发展，大小模型协同、轻量化的部署展现应用潜力。

一见采用云边协同架构，通过大模型自动生产并持续调优小模型，在保障端到端视觉AI应用效果的同时，大幅降低应用成本。轻量级小模型部署在边缘侧，可实现秒级快速触发；云端大模型负责深度理解复杂场景，兼顾响应效率与处理精度，这种 “边缘+云端” 的协同模式，让企业在享受高精度应用效果的同时，有效控制硬件投入与运维成本。这一能力也在IDC报告中得到了充分认可，成为一见领跑大模型赛道的重要支撑。

多场景落地，价值凸显

目前，一见已在餐饮连锁、钢铁、电力、矿山、港口、铁路、化工、水务、公安等20+行业落地，服务数百家头部客户，护航企业生产运行全环节，帮助企业实现全视觉管理数字化。

>>管安全：筑牢安全生产防线

一见为某风电集团构建的安全生产集中管控体系，覆盖了全国近300个风电场站、数万台风机，实时识别员工不规范作业与设备异常，集控人效提升300%+，隐患处理响应从小时级压缩至分钟级，巡检效率提升6-10倍，为能源安全筑牢“智能防线”。

>>管质量：破解质量检测难题

在冶金材料领域，一见与中国钢研联合打造的金相分析大模型，将传统依赖人工的检测方式升级为AI自动化分析。其95%的分割准确率（金相分析的核心指标），不仅解决了传统检测中“漏检率高、效率低” 的痛点，更让曾经依赖老师傅经验的冶金质检，转型为可标准化复制的智能流程。

>>管工序：传承老师傅操作经验

在制造行业，一见为某装备制造企业打造工序合规分析系统，破解复杂装配环节老师傅“经验断层” 难题。只需上传一段标准工序操作视频，一见便能基于多模态视频理解自动拆解老师傅的标准操作步骤，分钟级生成工序识别AI技能，上线后实时识别操作并纠偏，新员工误操作率降低90%。

>>管物料：实现精细运营管控

一见助力某头部连锁品牌实现物料精细管理，依托一见多模态大模型能力打造智慧运营中枢，精准优化资源配置，实现供应链及人效的智能管理，物料盘点效率提升60%，降低人工盘点工时。

>>管服务：重构门店管理范式

一见帮助某餐饮连锁企业实现锅底上桌检测、顾客离座识别等6类场景，实现了全国1000多家门店服务质量的量化管理，**订单覆盖率从抽检5%提升至95%，AI识别准确率达95%，**门店满意度大于98.2%。

多年的技术沉淀与20+行业的深耕实践，加速一见在视觉大模型领域形成独特的竞争力。技术普惠，一见将持续以技术创新为锚点，让视觉智能深度融入企业生产运行的每个环节，重新定义看见的价值，成为企业全视觉管理数字化跃迁的助推剂。

近日，2025中关村论坛系列活动——中关村人工智能与未来城市论坛在中关村国家自主创新示范区展示中心举办。论坛上，发布了应用范式创新升级成果、智能体产品、可信数据空间成果等。

中科大脑联合百度智能云等伙伴共同打造并发布21个智能体产品，涵盖城市治理、城市服务、公共安全、教育健康、政务办公等领域，是基于海淀人工智能创新街区和全国多地探索实践的积淀，作为标杆引领行业成长。

智能体产品作为智慧城市建设的重要支撑，论坛上，百度智能云、中科大脑、北京邮电大学、北京大学通用人工智能研究院等多家单位共同启动智能体生态合作计划，聚焦共创融合应用场景、共育繁荣创新生态和加强科技成果转化三个关键维度，携手擘画“数启新纪元 ”下智慧城市建设的未来图景。

百度智能云利用大模型技术，构建城市治理智能中枢，实现政务场景全流程智能化升级，打造集专业文书生成、城市治理监测、政务数据查询、便民服务办理、民生诉求响应于一体的城市智能体解决方案，推动政务服务从"人工处理"向"智能驱动"转型。

>>全流程公文智能：构建覆盖"提纲-撰写-审核"的公文智能生产体系，集成政策法规、公文范例等专业语料库，实现文书自动生成与合规性校验，公文处理效率显著提升。

>>多模态治理协同：整合视频监控、物联感知等多源数据，通过多模态大模型实现违法行为智能识别与执法预警，构建"监测-处置-反馈"闭环管理机制，提升非现场执法覆盖率。

>>政务问数穿透查询：建立跨部门数据关联分析模型，支持领导决策场景下的复杂数据即时穿透查询，实现复杂数据3秒穿透查询，辅助科学决策。

>>智能办事服务：融合"问答-导引-办理"全流程服务能力，提供疑问解答、办事导引、智能回填、边聊边办多项便民功能，有效提升在线办事效率。

>>民生诉求闭环响应：集成法律法规库和典型案例库，根据用户咨询的民生问题给出建议的解决方案引用相关法律依据，实现民生咨询智能分类与处置方案自动生成，根据用户咨询的民生问题给出建议的解决方案引用相关法律依据，AI法治护航解忧于民。

百度智能云具备从算力、平台到应用的全栈技术能力，全面支撑大模型在产业中的高效部署与落地。在算力层面，百度智能云已成功点亮昆仑芯三万卡集群，昆仑芯已在多个行业实现规模化部署。硬件之上，结合百度百舸GPU云平台，围绕落地大模型全旅程的算力需求，在集群创建、开发实验、模型训练、模型推理四大方面，为企业提供“多快稳省”的AI基础设施，最大化释放硬件性能。在平台层面，千帆大模型平台始终致力于为用户提供全流程、一站式的AI服务。目前，千帆平台还提供了包括文心大模型等在内的超过100多个模型和全面的模型开发工具链，企业既能灵活调用现有的成熟智能体，也可以根据业务需求灵活开发定制化应用。在应用层面，百度智能云推出了“行业场景智能体家族”。这些智能体支持快速轻量化定制，可高效接入业务系统，显著加速AI在金融、制造、政务等行业的落地进程。

■ 背景：扩散模型推理成本亟待优化

扩散模型（Diffusion Models）近年来在高保真图像和视频生成上取得了令人瞩目的成果。然而，这类模型在推理阶段需要经过数十步乃至上百步的迭代去噪，每一步都要运行庞大的 U-Net 或 Transformer 模型，导致推理耗时巨大。对于高分辨率生成或视频生成等应用，迭代推理的开销更是呈指数级上涨，使实时应用变得非常困难。如何在不牺牲生成质量的前提加速扩散模型的推理，已成为学界和工业界共同关注的课题。

01

扩散模型推理优化的总体方案

基于上述需求，PaddleMIX 从模型蒸馏、模型推理缓存（Training-Free）以及深度学习框架编译优化等多个技术维度出发，打造了 Fast-Diffusers 扩散模型推理加速工具箱，便于开发者根据实际场景灵活组合运用，从而有效提升扩散模型的推理速度。在第一期中我们介绍了动态跳过冗余计算（SortBlock）、智能缓存复用特征（TeaBlockCache）和数学近似预测（FirstBlock-Taylor）等 Training-Free 加速算法，在保持与原始模型几乎一致的生成质量的同时，将扩散模型的推理速度提升了2倍以上。本期稿件将从蒸馏加速和框架高性能优化两个方面介绍 Fast-Diffusers 工具箱中扩散模型的加速策略。

图1 推理加速工具箱

▎蒸馏加速方案和框架性能优化

主流的扩散模型蒸馏加速方法包括有一致性模型（Consistency Models），渐进式蒸馏（Progressive Distillation）以及分布匹配蒸馏（Distribution Matching Distillation）等。一致性模型建立在概率流常微分方程（PF-ODE）上，使用一致性函数将 PF-ODE 轨迹上任何时间步的点映射到轨迹的起点，支持一步生成高质量样本，同时保留多步采样能力以平衡计算成本与生成质量。分布匹配蒸馏通过分布级对齐（Distribution Matching）而非路径级模仿，在保持图像质量的同时实现数量级的速度提升，通过要求学生模型生成的图像分布应与教师模型生成的分布的一致性，完成一步生成图像的过程。

PaddleMIX 最新发布的扩散模型工具箱 PPDiffusers 中，集成了一致性模型 PCM(Phased Consistency Distillation)和 DMD2(Improved Distribution Matching Distillation for Fast Image Synthesis)算法，同时 **PaddleMIX 推出自研蒸馏加速模型 FLUX-Lightning，实现4步快速的高质量高分辨率图像生成，生成效果超越业界开源和闭源模型，达到业界 SOTA 水平。**另外使用飞桨深度学习编译器 CINN 进一步优化推理性能，对比 torch compile、Onediff、TensorRT 等主流推理优化框架，推理性能取得了显著的性能提升。

02

FLUX-Lightning 简介

PPDiffusers 提出了基于 FLUX 的蒸馏加速模型 FLUX-Lightning，可以在4步极少步数下，生成高分辨率高质量的图像，定量指标和定性指标均超越业界开源和闭源模型，达到了业界 SOTA 水平。

图2 FLUX-Lightning 4步推理结果

我们提出的 FLUX-Lightning 模型主要包含4个部分，区间一致性蒸馏（Phased Consistency Distillation），对抗学习（Adversarial Learning），分布匹配蒸馏（Distribution Matching Distillation），矫正流损失（reflow loss），完整框架如下图所示。

图3 FLUX-Lightning 框架

▎区间一致性蒸馏

▎对抗学习

为了进一步提升少步数下的图像生成质量，FLUX-Lightning 模型引入了对抗学习（Adversarial Learning），使用 discriminator 在 latent space 判别真实样本和虚假样本。

discriminator 模型由冻结的 teacher denoiser 和多个可训练的 discriminator heads 组成，前者负责提取图像特征，后者负责进行判别工作。图3展示了以 FLUX 为 teacher denoiser 的 discriminator 模型结构，FLUX 包含19个 FluxTransformerBlock 和38个 FluxSignleTransformerBlock，共计57个 TransformerBlock，将每个 TransformerBlock 的输出的图像特征 hidden states 输入到可训练的 discriminator heads 中，discriminator heads 由多个卷积层和残差结构组成，判别输入样本为真实样本还是虚假样本。

图4 discriminator 网络架构

▎分布匹配蒸馏

▎矫正流损失

▎算法流程

算法完整流程如下所示

03

飞桨编译器高性能推理

深度学习编译器是一种专门为深度学习模型优化和部署而设计的工具，用于提高模型的计算效率、降低内存占用、加速训练推理过程，核心价值在于弥合高层算法描述与底层硬件指令集之间的语义鸿沟。编译器功能上是将高层次的深度学习模型转换为低层次的、高效的、底层硬件可执行的代码。编译器通过将框架输出的初始计算图转化为具有严格语义定义的中间表示层，保留计算图的完整结构，随后在中间表示层实施多轮迭代优化，最终通过目标硬件感知的代码生成模块，将优化后的中间表示转化为高度特化的机器指令序列。简单来说，深度学习编译器在深度学习框架和底层硬件之间充当了“翻译”的角色，能够将用户定义的神经网络模型描述转化为底层硬件能够理解和执行的指令。编译器在实现这种转换的过程中，应用了一系列优化技术，以提高模型在各种硬件平台上（如 CPU、GPU）的执行效率。以下是飞桨框架编译器（CINN, Compiler Infrastructure for Neural Networks）整体流程图。

▎生成模型结合 CINN 推理性能优化

针对多模态生成模型推理时间长的问题，基于飞桨深度学习编译器 CINN，我们对于 FLUX 模型在 A800单卡推理情况下进行了飞桨框架推理性能优化实验，对比基于 xDiT 优化框架提供的 Torch Compile、Onediff 和 TensorRT 推理优化性能指标作为竞品。通过编译器优化所带来的性能加速，飞桨在 FLUX.1-dev 和 FLUX.1-schnell 这两个官方模型配置的推理中都取得了显著的性能提升，并且实现对比竞品的性能优势。

飞桨单卡推理性能测速和性能优化提升如下表所示。

FLUX 模型动态图编译器推理性能

通过表格中的性能测速对比可以发现，对于 FLUX.1-dev 模型的推理性能，输出图像维度为1024p 和512p 的情况下，使用飞桨编译器优化对比原生动态图推理性能提升分别达到31.8%和36.7%，而对于 FLUX.1-schnell 模型的推理性能，使用编译器优化对比原生动态图推理性能提升分别达到30.8%和34.6%，对于不同配置下 FLUX 系列模型都表现出了显著性能提升。

飞桨单卡推理性能测速和性能竞品对比如下表所示。

▎FLUX 模型推理性能竞品对比

我们对于市场上文生图大模型推理性能优化策略进行了性能分析，包括 torch compile、Onediff、TensorRT 等主流推理优化框架。通过对比可以发现基于飞桨编译器优化实现的 FLUX 推理在各个配置下都体现出了领先的推理性能。对于 FLUX.1-dev 模型，输出图像维度为1024p 和512p 的情况下，飞桨编译器推理性能对比竞品中性能最优的 Torch compile 推理性能提升分别达到1.4%和6.5%, 对于 FLUX.1-schnell 模型，飞桨编译器推理性能对比竞品中性能最优的 Onediff 推理性能提升分别达到1.4%和6.5%, 体现出了飞桨框架在市场中的推理性能方面的领先性，以及在 FLUX 模型各不同配置和参数设置情况下稳定的性能优势。同时我们也将该技术应用到自研蒸馏加速模型 FLUX-Lightning 中，开启 CINN 后在 A800上单卡推理时延能从2.21s 进一步降低到1.66s。

04

实验结果

▎实验设置

数据方面，我们基于 laion-aesv2数据集筛选45w 数据，筛选条件为：图像长宽都大于1024，美学指标 aes>6，水印概率分数<0.5。使用 COCO-10k 作为评测数据集。

模型方面，选用目前文生图领域最新的 FLUX 模型作为基础模型，由于 FLUX 模型自带 CFG 蒸馏，将 guidance scale 进行 embedding 后作为模型输入，所以训练时默认使用 CFG-augmented ODE solver。

评测指标，方面选择 CLIP 指标和 FID-FLUX，其中 FID-FLUX 指标参考 PCM 模型的 FID-SD 指标，使用原始 FLUX dev 模型的生成结果（50 step）计算 FID 分数。CLIP 指标用于评价生成结果与 prompt 的符合程度。

模型训练方面，使用 lora 训练的方式（lora rank=32），有效节省计算资源消耗。模型总 loss 如下所示，其中

▎定量结果

消融实验定量结果显示，我们使用的 Adversarial Learning，Distribution Matching Distillation 以及 reflow loss 都获得了模型效果的提升，证明了 FLUX-Lightning 优化点的有效性。

表1 消融实验

为了进一步验证 FLUX-Lightning 模型的效果，我们和目前 SOTA 的基于 FLUX 的蒸馏加速模型进行了全面的对比，包括 FLUX schnell，TDD (Target-Driven Distillation: Consistency Distillation with Target Timestep Selection and Decoupled Guidance)，SwD (Scale-wise Distillation of Diffusion Models)以及 hyper-flux，其中 flux schnell 和 Hyper-FLUX 是闭源模型，TDD 和 Swd 为开源模型，且所有模型均基于 FLUX 蒸馏得到。对比结果如下所示，在 FID-FLUX 指标上 FLUX-Lightning 模型获得了最好的效果（8.0182），CLIP 指标上也展现出了具有竞争力的分数。

表2 定量实验结果

备注：消融实验使用28w 数据实验，完整 FLUX-Lightning 模型使用全量45w 数据训练

▎定性结果

下面展示了我们的 FLUX-Lightning 模型和其他竞品之间的图像生成效果对比，可以看到 FLUX-Lightning 模型在图像质量、prompt 一致性、生成准确性方面都超过了其他竞品。具体来说：

FLUX-Lightning 在人体部位的生成上更加准确。例如第一行大部分竞品生成的脚部都很怪异，FLUX-Lightning 生成了正确的脚部同时更加符合“没有被毯子盖住”的含义。第二行和第三行中大部分竞品生成的手指数量不对或者形状不对，FLUX-Lightning 的手指数量性状则完全正确。

FLUX-Lightning 具有更好的文字生成的能力。在第4行中需要生成“New York City, 100 miles”的文字，TDD 生成了模糊不清的文字，SwD 缺少“miles”，Hyper-FLUX 的“100”很模糊，FLUX schnell 生成了不需要的“ew caft”的乱码，只有 FLUX-Lightning 生成了清晰的“New York City, 100 miles”文字。

FLUX-Lightning 可以生成更合理的人体姿态。第5行展示了抛棒球的运动员，TDD 和 Hyper-FLUX 的手臂部分出现明显扭曲，SwD 的手部和棒球合在了一起，FLUX-Lightning 生成的整体动作以及局部特征更加合理准确；第6行展示了跑步的运动员，SwD 生成的腿部和 FLUX schnell 生成的手臂都有明显问题，TDD 和 Hyper-FLUX 则是生成了不合理的背部文字，只有 FLUX-Lightning 生成了正确的跑步姿势以及背部“8”的文字。

FLUX-Lightning 生成内容和 prompt 更加契合。第7行要求生成“一家三口”，SwD 和 flux schnell 仅仅生成了两个人，Hyper-FLUX 则是生成了2个男人，TDD 生成了一家三口但是人物形态扭曲，FLUX-Lightning 正确生成了一家三口，同时人物形态正常。第8行中，TDD 和 FLUX schnell 没有体现出“大象扬起鼻子”的样子，SwD 和 Hyper-FLUX 的图像细节和背景丰富度较差，FLUX-Lightning 在大象形态和背景丰富程度上更加优秀。最后一行中，TDD 和 SwD 的手部细节扭曲，Hyper-FLUX 没有展现出“正在梳头”的状态，flux schnell 则是生成了奇怪的梳子，FLUX-Lightning 在人物细节、物体细节和动作上都更胜一筹。

▎人工评测

为了更加全面地评测 FLUX-Lightning 的效果，我们进行了图像生成效果的人工评测。具体来说，我们生成了50个富有挑战性的 prompt，对 TDD，SwD，Hyper-FLUX，FLUX schnell 及 FLUX-Lightning 共计5个模型的生成结果进行排序，4位评审员采样盲评的方式，按照结果好坏从高到低分别得到10分，7分，5分，3分，1分，最终取平均分。部分 prompt 示例如下所示，第一行中，需要考察生成结果是否包含“3个女性”，“医院”，“病床，医疗设备”等元素。第二行中，考察生成模型是否包含“蒙古包”，“马头琴”以及“墙上的乐器”等元素，同时还要依据人物是否扭曲、图像质量等多个维度进行评判。

图5 人工评测 prompt 示例

人工评测结果如下所示，其中 FLUX-Lightning 获得了最高分7.37分，表明 FLUX-Lightning 可以生成更符合人类审美的图像，体现了模型的优异效果。

表3 人工评测结果

05

使用教程

PaddleMIX 已将 FLUX-Lightning 模型开源集成到其扩散模型推理库（PPDiffusers）中，源码和使用说明都可以在 PaddleMIX 的 GitHub 仓库中获取，代码链接为：

github.com/PaddlePaddl…

感兴趣的开发者可以查阅开源代码，了解各模块的实现细节和参数配置，并对自己的扩散模型进行蒸馏加速。

▎训练

数据准备：下载 laion 训练数据和数据列表

wget https://dataset.bj.bcebos.com/PaddleMIX/flux-lightning/laion-45w.tar.gz
wget https://dataset.bj.bcebos.com/PaddleMIX/flux-lightning/filelist_hwge1024_pwatermarkle0.5.txt

数据解压之后，文件结构如下所示

|-- your_path
   |-- laion-45wlaion-45w
      ｜-- 0000000.txt
      ｜-- 0000001.txt
      ｜-- 0000002.txt
      ....
   |-- filelist_hwge1024_pwatermarkle0.5.txt

模型训练命令:

python -u -m paddle.distributed.launch --gpus "0,1,2,3,4,5,6,7" train_flux_lightning_lora.py \
    --data_path "your_path/laion-45w" \
    --file_list_path "your_path/filelist_hwge1024_pwatermarkle0.5.txt" \
    --pretrained_teacher_model "black-forest-labs/FLUX.1-dev" \
    --output_dir outputs/lora_flux_lightning \
    --tracker_project_name lora_flux_lightning \
    --mixed_precision "bf16" \
    --fp16_opt_level "O2" \
    --resolution "1024" \
    --lora_rank "32" \
    --learning_rate "5e-6" \
    --loss_type "huber" \
    --adam_weight_decay "1e-3" \
    --max_train_steps "28652" \
    --dataloader_num_workers "32" \
    --guidance_scale "3.5" \
    --validation_steps "20000" \
    --checkpointing_steps "1000" \
    --checkpoints_total_limit "30" \
    --train_batch_size "1" \
    --gradient_accumulation_steps "1" \
    --resume_from_checkpoint "latest" \
    --seed "453645634" \
    --num_euler_timesteps "100" \
    --multiphase "4" \
    --gradient_checkpointing \
    --adv_weight=0.1 \
    --adv_lr=1e-5 \
    --pre_alloc_memory 76 \
    --use_dmd_loss \
    --dmd_weight 0.01 \
    --apply_reflow_loss \
    --reflow_loss_weight 0.01

▎推理

下载模型权重

wget https://dataset.bj.bcebos.com/PaddleMIX/flux-lightning/paddle_lora_weights.safetensors

推理命令

python text_to_image_generation_flux_lightning.py --path_to_lora your_path/paddle_lora_weights.safetensors --prompt "a beautiful girl" --output_dir ./

text_to_image_generation_flux_lightning.py 中的内容为

# Copyright (c) 2025 PaddlePaddle Authors. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
import argparse
import os
os.environ["USE_PEFT_BACKEND"] = "True"
import paddle
from ppdiffusers import FluxPipeline
parser = argparse.ArgumentParser(description="Simple example of a training script.")
parser.add_argument(
    "--path_to_lora",
    type=str,
    required=True,
    help="Path to paddle_lora_weights.safetensors",
)
parser.add_argument(
    "--prompt",
    type=str,
    required=True,
    default="a beautiful girl",
)
parser.add_argument(
    "--guidance_scale",
    type=float,
    required=False,
    default=3.5,
)
parser.add_argument(
    "--height",
    type=int,
    required=False,
    default=1024,
)
parser.add_argument(
    "--width",
    type=int,
    required=False,
    default=1024,
)
parser.add_argument(
    "--lora_scale",
    type=float,
    required=False,
    default=0.25,
)
parser.add_argument(
    "--step",
    type=int,
    required=False,
    default=4,
)
parser.add_argument(
    "--seed",
    type=int,
    required=False,
    default=42,
)
parser.add_argument(
    "--output_dir",
    type=str,
    required=False,
    default="./",
)
args = parser.parse_args()
pipe = FluxPipeline.from_pretrained("black-forest-labs/FLUX.1-dev", map_location="cpu", paddle_dtype=paddle.bfloat16)
pipe.load_lora_weights(args.path_to_lora)
with paddle.no_grad():
    result_image = pipe(
        prompt=args.prompt,
        negative_prompt="",
        height=args.height,
        width=args.width,
        num_inference_steps=args.step,
        guidance_scale=args.guidance_scale,
        generator=paddle.Generator().manual_seed(args.seed),
        joint_attention_kwargs={"scale": args.lora_scale},
    ).images[0]
result_image.save(os.path.join(args.output_dir, "test_flux_lightning.png"))

使用 CINN 技术加速推理 FLUX-Lightning 方法如下：

export FLAGS_use_cuda_managed_memory=true
export FLAGS_prim_enable_dynamic=true
export FLAGS_prim_all=true
export FLAGS_use_cinn=1
python text_to_image_generation_flux_lightning_cinn.py --path_to_lora your_path/paddle_lora_weights.safetensors --prompt "a beautiful girl" --output_dir ./ --inference_optimize

06

总结与展望

本文介绍了 PaddleMIX 最新推出的 FLUX-Lightning 模型，通过区间一致性蒸馏（Phased Consistency Distillation），对抗学习（Adversarial Learning），分布匹配蒸馏（Distribution Matching Distillation），矫正流损失（reflow loss）等技术，在保持图像生成质量的前提下，可以做到4步快速生成，大幅提升了图像生成的性能，叠加上 CINN 推理优化，单图推理仅需1.66s（A800）。模型效果也达到了业界 SOTA 的水平，定量和定性结果显示超越了目前市面上基于 FLUX 的各种开源和闭源的蒸馏加速模型，开发者可以根据需求简单地对自己的扩散模型进行蒸馏加速。

展望未来，随着扩散模型在更大规模数据和更多应用领域的发展，此类推理高效化的需求将更加迫切。我们有理由相信，蒸馏加速方法还有很大潜力可挖——例如使用 TrigFlow 消除 CM 模型中的量化误差、更加高效的对抗损失设计等，都有望在保持图像生成质量的前提下进一步提升生成效率。PaddleMIX 也将持续完善多模态模型的工具链，在提供强大模型能力的同时兼顾实际部署效率。希望这些加速方法能够帮助开发者更快地落地扩散模型应用，激发出更丰富的创意，实现高质量生成与高效推理的双赢。

▎开源代码链接：

PaddleMIX 扩散模型加速插件相关代码已在 GitHub 开源 。欢迎大家访问仓库获取源码并提出宝贵意见，共同推进扩散模型技术的发展与应用！

github.com/PaddlePaddl…

导读

随着AI时代的到来，各类AI工具层出不穷，业界都在探索一套完整的AI加成的提效方案，我们团队基于自身特色，利用起团队沉淀好的历史知识库，落地了一套深度结合AI的工作流，用AI武装研发团队，实现研发效率的提升。

背景

• 各类AI研发工具层出不穷，很多现成工具可使用，业界都在探索一套完整的AI加成的提效方案

• 团队内部规范文档完备，但是没有融入开发流程中

• Code review、研发自测、接口文档更新消耗大量时间

目标

1. 拥抱AI时代，让团队更先进。

2. 用AI武装研发团队，通过资源的配合与协调，实现研发效率的提升。

思路

1. 拆分研发流程，并找到AI结合点，并将其串联起来。

2. 深度探索AI IDE，得出最佳实践。

3. 利用起团队的知识库，为AI提供辅助能力。

定位

1. 这是一个锚点，自此开始团队研发流程向AI化转变。

2. 这是一个开始，带动团队与其他同学review当前研发流程，共建更多研发工作流。

01 研发链路

对研发链路进行拆解，得到不同阶段的AI工作流形态，并基于当前形态向下一形态进行推进。

当前我们团队正处于阶段1接近完成，阶段2正在开始探索实践的阶段，因此下面我们会基于我们团队在这些方面的实践进行分享。

原本研发链路：

AI加持研发流程：

AI 工作流

对上面涉及到的AI工作流进行补充说明

AI-Cafes：AI生成需求文档，制作产品原型图，节省产品人天。

AI-Docs：需求文档转技术文档，节省研发梳理过程，节省研发人天。

AI-DocsCoding：基于技术文档，生成基础无业务逻辑代码，节省研发人天。

AI-Coding：基于团队内部代码规范生成代码，减少返工和代码理解成本，深度提高研发效率，节省研发人天。

AI-API：基于MCP Server打通接口文档，避免api文档/技术文档更新不及时，节省研发人天。

AI-CR：基于Rules，进行AI Code Review，节省研发人天。

AI-Develops：AI赋能测试、验证、监控环节，节省测试人天。

02 需求阶段

AI-CafeDocs

在原本的工作流中，在需求评审过后，研发同学通常需要至少0.5d的人力进行技术文档的落地，以及api接口的准备。

但是这一步中的大部分工作是重复的，可替代的，可节省的。

因此我们实现了了__需求文档 -> aisuda（百度的低代码平台）-> 大模型 -> 技术文档（markdown）__的工作流。

在微调好大模型之后，我们只需要以下两步就能完成技术文档+api接口准备的工作：

1. 投喂需求文档给大模型，得到初版技术文档。

2. 人工check技术文档。

在快速生成了技术文档后，后端再和前端进行沟通，根据细节进行修改具体实现。

AI-DocsCoding

在得到技术文档之后，我们下一步要做的则是落地。不得不承认，我们的工作中无可避免的会存在一些基础的CRUD环节，这是正常的，也是重复的，可替代的，可节省的。

因此，基于以上的 AI-CafeDocs环节，我们进行了进一步的延伸，实现了__技术文档 -> MCP Server -> AI IDE**_**_ 的工作流

我们通过MCP打通了内部的知识库，使得AI能够阅读到需求文档和技术文档，了解上下文，并进行对应的开发工作。

当然，AI全流程开发只是一种理想的状态，就当前而言，AI-DocsCoding写出来的代码并不是完全可用的，在涉及到的业务逻辑越复杂时，代码的正确性就越低。

但是不要紧，我们在设计这个流程的时候，就早有准备。

还记得我们强调的一点：让AI取代重复的，可替代的，可节省的工作，那么正确的流程为：

1. AI通过MCP阅读需求文档、技术文档，生成本次功能的基础代码——除却业务逻辑之外的参数处理、数据处理的CRUD代码。

2. 人工补全核心的业务逻辑处理，人也只需要关心真正的业务逻辑，这些事AI无法替代的。

可以看到，在以上的两个工作流里，人的角色从执行者，变成了驱动者/观察者，或者说产品经理。

我们通过**_向AI提出需求，监督AI工作，验收AI工作结果_**的方式进行工作。

03 开发阶段

AI-Coding

AI-Coding这一块主要围绕 AI IDE的使用，现在市面上有很多的产品，比如Cursor、Comate、Trae等。其实在许多人看来，AI IDE的核心在于底层能够接入的模型，但是我觉得这不尽然，大模型的边界效应很强。

有些时候，我们对AI IDE的使用，还没有达到需要区分模型效果的地步。或者说，如果我们使用了世界上最好的模型，那我们是否就高枕无忧了，可以让AI全程进行Coding而不需要人为Review了？

至少使用到今天为止，我们认为AI-Coding，还离不开人的关注，因此如何更好地使用AI进行Coding，是AI提效的必经之路。

合理使用Rule

在AI IDE内，Rule是一个非常重要的环节，它是连接开发者意图与 AI 代码生成行为之间的关键桥梁。

定义：Rule 的 核心目的是指导 AI 更准确地理解当前代码库的上下文、遵循特定的项目规范与编码标准、生成符合预期的代码，或辅助完成复杂的工作流程。Cursor 官方文档将其描述为“控制 Agent 模型行为的可复用、有作用域的指令”。

作用：大型语言模型（LLMs）本身在多次交互之间通常不具备持久记忆。Rule 通过在每次 AI 请求的提示词（prompt）层面提供持久化、可复用的上下文信息，有效解决了这一问题。当一个规则被应用时，其内容会被包含在模型上下文的起始部分，从而为 AI 的代码生成、编辑解释或工作流辅助提供稳定且一致的指导。

上面有一个非常重要的点，那就是所有的rule在使用的过程中，都会占用我们上下文的token，因此如何更好的使用Rule，是提升AICoding能力的关键。

基于我们的实践，我们建议将 AI IDE 的rule进行层级划分：

第一层：IDE全局层 (User Rules)

• 位置：User Rules

• 范围：所有项目通用

• 内容：个人编码风格偏好

• 限制：50行以内

第二层：项目基础层 (Always Rules)

• 位置：.xx/rules/always/

• 范围：整个项目强制遵循

• 内容：技术栈、核心原则、基础规范

• 限制：100行以内

第三层：自动匹配层 (Auto Rules)

• 位置：.xx/rules/auto/

• 范围：特定文件类型或目录

• 内容：模块专门的开发规范

• 限制：每个规则200行以内

第四层：智能推荐层 (Agent Rules)

• 位置：.xx/rules/agent/

• 范围：AI根据对话内容智能判断

• 内容：优化建议和最佳实践

• 限制：每个规则150行以内

第五层：手动调用层 (Manual Rules)

• 位置：.xx/rules/manual/

• 范围：手动调用的代码模板

• 内容：完整的项目或模块模板

• 限制：每个规则300行以内

基于以上的划分，我们再给出对 已有/未有 Rule规范的代码库的 Rule 创建规则（语言不重要，以Go为例）：

内容优化原则：

• 避免：

• 详细代码示例（每个100+行）

• 重复的概念解释

• 推荐：

• 简洁要点列表（每个20-30行）

• 具体的操作指令

globs精确匹配：

• 避免：

• 过于宽泛："**/*.go"（匹配所有Go文件）

• 推荐

• 精确匹配：

  "internal/handler/**/*.go"（只匹配处理器）

• 精确匹配：

  "internal/repository/**/*.go"（只匹配仓储层）

• 精确匹配："**/*_test.go"（只匹配测试文件）

优先级设置详解：

优先级数值范围：1-10，数值越高优先级越高

优先级使用策略：

1. 基础规范用10：项目必须遵循的核心规范

2. 核心模块用8-9：handler、service、repository等主要模块

3. 辅助模块用6-7：middleware、config、utils等辅助模块

4. 优化建议用5：性能优化、最佳实践等智能建议

5. 模板参考用3-4：代码模板、脚手架等参考资料

6. 实验功能用1-2：测试中的新规范，避免影响稳定功能

冲突解决机制：

• 当多个规则应用于同一文件时，高优先级规则会覆盖低优先级规则的冲突部分

• 相同优先级规则按文件名字母顺序加载

• Always规则始终优先于所有其他类型规则

Rule 的核心价值在于它 _为开发者提供了一种机制，用以精细化控制 AI 在代码理解、生成、重构等环节 _的行为。

通过预设规则，开发者可以将项目规范、编码标准、技术选型乃至特定业务逻辑“教授”给 AI，从而显著提升 AI 辅助编程的效率、保证代码质量的均一性，并确保项目整体的规范性。

它使得 AI 从一个泛用的助手，转变为一个深度理解特定项目需求的“领域专家”。

记忆库

基于Rule的运用，我们通过memory bank + rule生成专属业务研发助手

在AICoding的使用中，有一种常见的痛点场景，就是在复杂的项目中，AI无法感知到整个项目的历史上下文，即便是有Codebase的存在，也对业务逻辑是一知半解。

在我们实践的过程中，引入了记忆库的模式，深化AI对项目的理解和记忆，使得每一次需求迭代的上下文都被记录下来。

生成了memorybank后，我们可以随时通过对话查看项目大纲和内容，并且每一次重新进入开发，不会丢失之前的记忆。

这种模式，其实就是Rules的一种应用，它把上下文总结在代码库的制定位置，强制AI在每次进入时会阅读上下文，回到上一次Coding的状态，对于解决上下文丢失的问题有非常大的帮助。

这里可能有人会问，记忆库和IDE本身的长期记忆功能有什么区别？

答：记忆库是公共的项目记忆库，IDE长期记忆是私人的IDE使用记忆。

而记忆库的详细内容，这里不作详细分享，它只是一份提示词，感兴趣的同学只要简单搜索一下就能找到很多的资源。

MCP Server（重点）

MCP（Model Context Protocol），模型上下文协议，由Anthropic于24年11月提出，旨在为大语言模型和外部数据源、工具、服务提供统一的通信框架，标准化AI与真实世界的交互方式

MCP的核心架构包括三环：

• Host主机：用户与AI互动的应用环境，如Claude Desktop、Cursor；

• Client客户端：充当LLM和MCP server之间的桥梁，将用户查询指令、可用工具列表、工具调用结果发给LLM，将LLM需要使用的工具通过server执行调用；

• Server服务器：轻量级服务节点，给予AI访问特定资源、调用工具能力的权限；目前已有数据库类（如SQLite、supabase）、工具类（如飞书多维表格）、应用类（如高德地图）服务器。是MCP架构中最为关键的组件。

在开发中，我们可以接入以下几种MCPServer

1. 实时搜索，baidu/google/github/微博等

2. 存储，mysql/redis等

3. 工具，kubectl/yapi等

用法一：我们接入百度搜索的MCP

1. 搜索问题：在开发之余搜索一下 夜的命名术 是否完结。

2. 搜索知识点：在想知道Go1.24新特性时，通过MCP进行搜索，让AI进行总结。

3. 搜索用法：在想了解Linux的快捷命令时进行搜索。

以上这些场景，并非非MCP不可，非AI IDE不可，但是通过这样的方式，我们至少节省了切换到浏览器，搜索，自己总结结论，返回继续Coding这些步骤。

用法二：client里直接进行多client操作

1. Redis自然语言查询：

2. MySQL自然语言查询：

3. GCP自然语言查询：

其他的client（kubectl等）我就不一一列举了，但是可以看到，当我们在我们的IDE内集成了各种各样的client后，开发效率能极大地提升。

当然，这里有两个关键点：

1. 接入mcpserver并不需要我们研究，我们只要把mcp server的链接丢给AI，它自己就能开始接入

2. 禁止在开发环境使用线上client账号密码

AI-API

相信无论是前端还是后端开发，都或多或少地被接口文档折磨过。前端经常抱怨后端给的接口文档与实际情况不一致。后端又觉得编写及维护接口文档会耗费不少精力，经常来不及更新。

其实无论是前端调用后端，还是后端调用后端，都期望有一个好的接口文档。但是随着时间推移，版本迭代，接口文档往往很容易就跟不上代码了,更会出现之前的同学没有把接口文档交接清楚就离职，留下一个繁重复杂的项目，重新啃起来异常艰难，不亚于自己从头写一遍。

痛点

1. 重复劳动：每一个涉及到前后端的功能，研发都需要手动进行维护接口文档，在一些时候，接口最后和最开始的设定有可能大相径庭，每一次改动都是非常令人头疼的工作。

2. 低效沟通：前后端在沟通接口后，再进行对应的代码开发，其实是一件重复的，可替代的，可节省的工作。

为了解决这些痛点，通过引入 AI 自动化功能，搭建API MCP Server，帮我们解决这些冗杂的工作，让研发人力更多的集中在核心业务代码的开发上，提升代码开发效率、降低沟通成本。

这是我们一直畅想的场景，后端开发完代码 -> AI 推送接口文档 -> API文档自动更新 -> AI 拉取接口文档 -> 前端生成代码

也就是前后端的研发同学，只关注业务功能的实现，而不需要关注这些接口对接的繁琐工作。

Better Thinking

这是我想补充的两个使用AICoding的思想，也是我使用下来的一个感悟。

一：学会递归使用AI

场景：在IDE内布置MCP Server

通常的做法是：

1. 在MCP Server市场找到想用的MCP Server

2. 把配置部署好

3. 开始调试，完成后投入使用

递归式使用做法：

1. 在MCP Server市场找到想用的MCP Server

2. 把链接丢给AI，让它自己安装（递归）

3. 安装完后让它自己修改mcp.json的配置（递归）

4. 修改完成后让它自己调通（递归）

更进一步我们还可以：

1. @Web 让AI找一个可用的McpServer（递归）

2. ...（递归）

3. ...（递归）

4. ...（递归）

二：把AI当成一个真正的工具

场景：写某篇文档的时候，我突然想要做一个Gif格式的图片示例。

已知：电脑支持录屏，但是我缺少视频转Gif格式的工具。

麻烦点：

1. 如果通过百度/Google搜索网页在线工具，非常麻烦，还要付费。

2. 如果通过内部的视频裁剪服务，还需要起服务来处理。

3. 如果通过剪映这样的工具，那还要下载一个软件。

以上这些点，都不算困难，但都相对麻烦，属于能做但是又要浪费一点精力。

解决方案：

理论上让AI写和让GPT/Deepseek写没什么区别，但是我们的操作步骤得到了以下简化：

也就是说，我们在遇到很多**_自己能做，但是又觉得麻烦，浪费精力的场景_以及_大部分的杂活_**，都可以第一时间Ask Ourself，Can AI Do it？

包括但不限于：

1. 捞数据

2. 写文档

3. 找bug

4. ...

AI-Coding VS Original-Coding

04 集成阶段

AI-CR

问题

1. 时间压力：团队每周可能需要审查数十个CR，高T同学需要审查的居多，每个 CR 的细节往往耗费大量时间。

2. 沟通低效：CR评论描述不清晰，开发者需要来回沟通确认修改点。

3. 重复劳动：相似的代码改动需要重复审查，难以专注关键问题。

为了解决这些痛点，通过引入 AI 自动化功能，提前规避一些基础问题，让CR人力更多的集中在关键问题上，提升代码审查效率、降低沟通成本。

解决方案

工作流

05 运维阶段

AI-Develops

随着业务系统的复杂度不断增加，运维过程中产生的告警数量急剧增长，传统的人工处理方式已经无法满足快速响应的需求。

目前在我们来看，现有的运维体系存在了以下的弊端：

1. 告警存在非常厚的方向壁垒，不同方向的同学遇到另一个方向的告警时大都只能进行Case路由。

2. 告警存在非常厚的年限壁垒，团队不同年限的同学遇到Case的应对时间有可能天差地别。

一个点是否足够痛，决定了我们是都要优化。

在我们团队内，有丰富的case处理文档和记录，也有着应对问题经验非常丰富的同学，但是在值班同学遇到告警轰炸的时候，同样会焦头烂额。

回顾起告警处理的过程，其实大部分都是重复的，可替代的，可节省的工作，它们是有方法论的，并非遇到之后就手足无措。因此我们构建一个智能化的应急诊断系统，通过AI技术提升故障处理效率，减少平均故障修复时间(MTTR)。

在这种模式下，AI可以自动捕捉消息，在遇到告警信息的时候自动分析给出结论，如果有AI无法解决的问题，才会轮到人工进行介入。

这种模式最大的优点在于：所有出现过的Case/已有的文档都会沉淀为AI的记忆和知识库，从今往后只会有新增的Case需要人来解决，存量全都会被AI拦截，换而言之，团队内多出了一个永远不会离开，且能够同时接受所有方向培养的AI运维人员。

06 总结

以上就是我们百度国际化广告团队的AI提效实践，也希望这篇文章能作为一个锚点，带动所有看到这篇文章的同学review自己所在团队的工作流程，共建更多的AI加持工作流。

就如我上面说的，其实AI的用法很简单，它就是我们的助手，假如我们的工作中真的存在一些重复的，可替代的，可节省工作，那不妨把这些工作交给AI试试。

一. 前言

丨1. 行业背景

在现代播放器架构中，音频后处理已不仅是锦上添花的功能，而是构建差异化听觉体验的关键组件。尤其在多样化的播放场景（手机外放、耳机、电视音响等）下，通过定制化的音效增强手段，有效提升听感表现已成为基础能力之一。

丨2. 本文概览

本系列文章将系统介绍我们在播放器音频后处理模块中的技术方案与工程实现，主要面向音视频方向的开发者。我们主要基于 FFmpeg的音频滤镜框架，结合自定义模块，构建了一套可扩展、高性能、易适配的音效处理链路。

第一期内容聚焦在两项核心基础音效：

• 重低音：通过构建低通滤波器与动态增益控制逻辑，增强低频段表现，适配小型设备下的听感优化

• 清晰人声：结合频段增强、人声掩码与背景音抑制技术，有效提升对白清晰度，在嘈杂或背景音复杂的场景下保持语音主干突出

我们将分享上述音效的整体处理流程、关键滤镜链搭建方式、滤波器设计细节，以及如何在保证延迟与功耗可控的前提下，通过 FFmpeg 的 af（audio filter）机制灵活插拔各类处理节点。

希望本系列文章能为你提供实用的技术参考，也欢迎有 FFmpeg 或音效处理相关实践经验的开发者交流碰撞，共同推动播放器音频后处理技术的深入发展。

二. 走进音频后处理

丨1. 技术定义和核心目标

对于视听消费场景，音频后处理指在音频信号完成解码（PCM/DSD数据生成）后，通过数字信号处理技术对原始音频进行音质增强、效果添加或缺陷修正的过程。核心目标包括：

丨2. 关键技术分类

音频后处理技术主要可分为以下四大类，每类技术的特点和应用如下：

三. 播放内核音频后处理框架

丨1. 整体架构

音频后处理模块在播放pipeline中的位置如上图所示，位于音频解码模块和音频帧队列之间。模块是否被链接于pipeline中是业务可选的，出于性能考虑，只有真正需要用到音频后处理功能的播放任务才会去链接音频后处理模块。

---

丨2. 音效支持

目前，播放内核已开放了包括：音量增强、清晰人声、重低音、立体环绕、降噪等多种音效，支持业务在播放前以及播放中打开、关闭或变更任意音效。根据业务的设置，音频后处理模块承担了音效滤镜的初始化、滤镜链组装、滤镜链变更等任务。该模块目前不仅提供了FFmpeg原生滤镜的支持，而且新增了内核自研的热门音效滤镜。

四. 落地音效一：重低音

丨1. 重低音

• 重低音效果通常指的是音响系统或音频设备中低频段的增强效果，特别是那些频率在20Hz到250Hz之间的声音。这种效果使得声音中的低频成分（如鼓声、贝斯声）更加突出和有力，从而带来一种震撼和沉浸式的听觉体验

• 重低音效果通常应用在音乐、电影和游戏中，用以增强音效的冲击力。例如，在观看动作电影时，重低音效果能够使爆炸或撞击声更加震撼，而在听音乐时，它能让鼓点和贝斯的节奏感更强烈。一般来说，这种效果是通过音响设备中的低音炮或音频处理器来实现的，它们能够放大并优化低频声音，使得音效更加浑厚、深沉和有力量

• 音频的频率范围大致可以划分为:

• 次低音 (Sub-bass): 20 Hz - 60 Hz

     包括极低频率的声音，如低音炮的低频段，能够带来深沉的震撼感

• 低音 (Bass): 60 Hz - 250 Hz

     涵盖常规低音部分，如贝斯和低音鼓，带来厚重感和力量感

• 低中音 (Low midrange): 250 Hz - 500 Hz

     涉及一些低频乐器和男声的下半部分，增加声音的温暖感

• 中音 (Midrange): 500 Hz - 2 kHz

     包含大部分人声和主要乐器的频段，是声音的核心部分

• 高中音 (Upper midrange): 2 kHz - 4 kHz

     涵盖高频乐器、人声的高音部分，决定了声音的清晰度和穿透力

• 高音 (Treble): 4 kHz - 6 kHz

     提供声音的亮度和细节，涉及高频乐器和背景环境声

• 极高音 (Brilliance or Presence): 6 kHz - 20 kHz

     涉及非常高频的声音，如高频细节、空气感和一些环境声的尾音，影响声音的开放感和透明度

1.1 设备物理限制

手机或者耳机在体积功率等物理限制下，在中低压表现较弱。相比之下，电影院音响系统具备大尺寸扬声器和高功率输出，能够产生20Hz或更低的低频效果，并且其环境设计有助于低音的增强。

1. 扬声器尺寸小：手机和耳机的扬声器尺寸通常较小，限制了低频声波的产生

2. 功率输出低：这些设备的放大器功率有限，无法驱动强劲的低频振动

1.2 人耳听觉非线性特性

在不同响度下人耳的等响曲线

• 可以看到，不同响度下的“等响曲线”的走势都不是完全一致的。响度越小，曲线中各个频率之间的区别就越大，而响度越大，曲线就越趋于平缓，各个频率之间的区别就越小

• 人耳对于中频的敏感度要高于低频，而这种敏感度之间的差距会随着响度的增加而减小

丨2. 移动设备重低音方案选型

2.1 基于均衡器的低频调整

• 原理与实现：

     频段划分：通过提升均衡器（Equalizer, EQ）低频段（比如20Hz-200Hz）的增益值直接增强低频信号幅度，例如，将 50Hz-80Hz 频段提升 +3dB~+6dB 可显著增强低音冲击力

• 技术特点：

     线性处理，仅改变幅度，不产生谐波

     需结合音频压缩器，避免出现削波失真、爆音等case

文件1（原始）

1     bobo1

文件2（低音加强）

2     bobo2

2.2 谐波生成与心理声学效应

核心原理：

• 一般认为音调应该是由以最低频率为基波决定的，谐波成分则决定音色

• 通过非线性信号处理生成低频信号的谐波成分（如60Hz基频生成120Hz、180Hz谐波），利用人耳的塔替尼效应（Tartini Effect）

• 当多个高频谐波存在时，大脑会“脑补”出缺失的基频（如120Hz+180Hz谐波组合可让人感知到虚拟的60Hz）

音频文件示例：

下面是两首曲听起来只是音色不同，但音调是一致的

y2     y4

2.3 方案对比

丨3. 移动播放器重低音效果实现

3.1 现有技术局限

1. EQ直接提升

2. 在低频段直接增加增益，易引发共振，引发“嗡嗡声”或“轰鸣感”

3. 移动设备喇叭尺寸和功率限制，低频段增益效果一般

4. 动态控制缺失：缺乏压缩和限制机制，易造成信号削波

3.2 技术目标

开发一款基于FFmpeg的高性能低音增强滤镜，实现以下功能：

1. 分频处理：精准分离低频与高频信号，避免处理干扰

2. 谐波增强：通过可控谐波生成方案，提升低频感知

3. 动态均衡：结合前置/后置EQ与压缩器，优化频响与动态范围

4. 参数可调：支持分频点、激励强度、混合比等灵活配置

3.3 系统架构

3.4 核心模块详解

3.4.1 分频器模块

功能：将输入信号分割为低频和高频

技术实现：

• 滤波器类型：4阶Linkwitz-Riley分频器，由2个双二阶滤波器级联

• 相位对齐：低通与高通采用相同极点，保证分频点处相位连续

• 关键代码：

// 分频器系数计算（design_crossover函数）
const double w0 = 2.0 * M_PI * s->cutoff / s->sample_rate;
const double alpha = sin(w0) / (2.0 * sqrt(2.0)); // Butterworth Q值
// 低通与高通系数通过频谱反转生成

3.4.2 前置EQ模块

功能：对分频后的低频信号进行预增强

技术实现：

• 滤波器类型：低架滤波器（Low Shelf），截止频率为cutoff * 0.8

• 增益公式：半功率增益计算（pre_gain/40），避免过度提升

• 代码片段：

const double A = pow(10.0, s->pre_gain / 40.0);
const double omega = 2 * M_PI * s->cutoff * 0.8 / s->sample_rate;
// 低架滤波器系数计算（包含sqrt(A)项）

3.4.3 谐波生成器

功能：通过非线性失真生成奇次谐波，增强低频感知

算法设计：

• 三阶多项式软化：shaped = x - (x^3)/6，生成3次、5次谐波

• 抗混叠处理：shaped *= 1/(1 + |x|*2)，抑制高频噪声

• 直流偏移消除：return shaped - input*0.15

double generate_harmonics(double input, double drive) {
    double x = input * drive;
    // ...（非线性处理）
}

3.4.4 后置EQ模块

功能：补偿谐波生成后的频响失衡

技术实现：

• 滤波器类型：高架滤波器（High Shelf），截止频率为cutoff * 1.2

• 增益公式：全功率增益计算（post_gain/20），直接调整整体电平

• 代码片段：

const double A = pow(10.0, s->post_gain / 20.0);
const double omega = 2 * M_PI * s->cutoff * 1.2 / s->sample_rate;
// 高架滤波器系数计算（简化公式）

3.4.5 动态压缩器

功能：防止增强后的低频信号过载

算法设计：

• RMS检测：跟踪信号包络，计算动态增益

• 对数域压缩：阈值（COMP_THRESHOLD）设为-4dB，压缩比由drive参数动态调整

• 平滑过度：一阶IIR滤波器平滑增益变化，避免“抽吸效应”

代码逻辑：

double compressor_process(...) {
    // Attack/Release系数计算
    const double coeff = (input^2 > envelope) ? attack_coeff : release_coeff;
    // 增益平滑
    s->ch_state[ch].gain = 0.2 * old_gain + 0.8 * target_gain;
}

3.4.6 配置参数表

五. 落地音效二：清晰人声

清晰人声结合频段增强、人声掩码与背景音抑制技术，能有效提升对白清晰度，在嘈杂或背景音复杂的场景下保持语音主干突出。为了更好地了解清晰人声的实现，本节将从音效的整体处理流程、滤波器设计细节、关键滤镜链搭建方式以及实现效果进行详细的介绍。

丨1. 技术原理

为了增强音频中人声的清晰度，对音频的处理主要分为四步：

1. 识别并隔离主要说话者的声音，并进行语音放大

2. 识别并减少各种类型的背景噪音

3. 通过调整频率平衡来提高语音清晰度

4. 应用精细的压缩和均衡来提高整体音频质量

要调整音质以使人声更加清晰，通常需要在EQ中进行一些特定的频率调整。以下是一些常见的频率和增益设置及其效果，这些设置有助于提高人声（通常在300Hz~3kHz）的清晰度：

丨2. Dialoguenhance

FFmpeg中有一个可以用来增强立体声对话的音频滤镜，称为dialoguenhance。接下来，将对dialoguenhance滤镜进行一下整体的介绍，随后便详细地介绍一下该滤镜的设计细节，以及播放内核关键滤镜链的搭建方式。

2.1 滤镜介绍

Dialoguenhance滤镜接受立体声输入并生成环绕声（3.0声道）的输出。新生成的前置中置声道会强化原本在两个立体声声道中都存在的语音对话，同时前置左声道和右声道的输出则与原立体声输入相同。

该滤镜提供了3个选项，分别是original、enhance、voice。下列表格中展现了这三个参数的说明、取值范围以及其作用。

2.2 实现原理

filter_frame函数是FFmpeg大多数滤镜的核心处理函数，主要包含以下步骤：

1. 第一步，接收原音频帧输入，并进行参数初始化。

2. 第二步，对输入进行加窗处理，从而减少频谱泄露。

3. 第三步，执行傅里叶变换，将音频输入信号从时域转化成频域。

4. 第四步，对音频信号进行算法处理，这个是各个滤镜的核心部分。

5. 第五步，执行傅里叶逆变换，将处理后的音频信号从频域转化为时域。

6. 第六步，处理立体声信号，将其转换为处理后的信号，处理后的音频被组合并输出。协调整个滤镜过程，管理缓冲区并执行必要的变换和增强。

7. 第七步，根据输入的参数和属性配置滤镜。

8. 第八步，激活滤镜。

以dialoguenhance为例，以下展现了filter_frame函数的源代码。

static int filter_frame(AVFilterLink *inlink, AVFrame *in)
{
    AVFilterContext *ctx = inlink->dst;
    AVFilterLink *outlink = ctx->outputs[0];
    AudioDialogueEnhanceContext *s = ctx->priv;
    AVFrame *out;
    int ret;

    out = ff_get_audio_buffer(outlink, s->overlap);
    if (!out) {
        ret = AVERROR(ENOMEM);
        goto fail;
    }

    s->in = in;
    s->de_stereo(ctx, out);

    av_frame_copy_props(out, in);
    out->nb_samples = in->nb_samples;
    ret = ff_filter_frame(outlink, out);
fail:
    av_frame_free(&in);
    s->in = NULL;
    return ret < 0 ? ret : 0;
}

Dialoguenhance滤镜是通过处理立体声音频信号并提取通常包含在中心声道中的对话内容来增强音频对话的，其核心算法处理包括对音频数据进行中心声道处理、语音活动检测、语音增强等步骤。下图展现了dialoguenhance滤镜的工作原理及其对应的代码模块功能：

丨3. 工程实现

对于播放内核而言，为接入dialoguenhance滤镜，主要包含以下两个重要的工程实现：

1. 第一个是dialoguenhance滤镜的初始化以及获取滤镜的上下文。在播放内核的工程实现中，确定好了dialoguenhance各个选项的具体参数。

#include "dialoguenhance_filter.h"
PLAYER_CORE_NAMESPACE_BEGIN
        AVFilterContext* DialoguenhanceFilter::getAVFilterContext() {
            return _avFilterContext;
        }
        int DialoguenhanceFilter::initFilter(AVFilterGraph* graph, AudioBaseInfo* audioBaseInfo, const JsonUtils::Value* param) {
            AUDIOSCOPEDEBUG();
            _avFilter = (AVFilter*)avfilter_get_by_name("dialoguenhance");
            if (!_avFilter) {
                LOGD("dialoguenhance filter not found");
                return -1;
            }
            _avFilterContext = avfilter_graph_alloc_filter(graph, _avFilter, "dialoguenhance");
            if (!_avFilterContext) {
                LOGD("dialoguenhance filter context alloc failed");
                return -1;
            }
            // 参数设置
            av_opt_set_double(_avFilterContext, "original", 0, AV_OPT_SEARCH_CHILDREN);
            av_opt_set_double(_avFilterContext, "enhance", 2, AV_OPT_SEARCH_CHILDREN);
            av_opt_set_double(_avFilterContext, "voice", 16, AV_OPT_SEARCH_CHILDREN);
            int result = avfilter_init_str(_avFilterContext, nullptr);
            if (result < 0) {
                LOGD("dialoguenhance filter init failed");
                return -1;
            }
            return 0;
        }
PLAYER_CORE_NAMESPACE_END

2. 第二个是将dialoguenhance滤镜接入播放内核音频后处理模块的滤镜链中。

void AudioFrameProcessorElement2::init_filter_list(const std::string& filterType,const JsonUtils::Value* param){
    std::shared_ptr<IAudioFilter> filterPtr = nullptr;
    if (filterType == kAudioSrc){
        filterPtr = std::make_shared<SrcFilter>(kAudioSrc);
    }
    else if (filterType == kAudioSink){
        filterPtr = std::make_shared<SinkFilter>(kAudioSink);
    }
    else if (filterType == kAudioVolume){
        filterPtr = std::make_shared<VolumeFilter>(kAudioVolume);
    }
    else if (filterType == kAudioRaiseVoice){
        filterPtr = std::make_shared<DialoguenhanceFilter>(kAudioRaiseVoice);
    }

    if(filterPtr->initFilter(_filter_graph,_audio_base_info,param) == 0){
        _filter_list.push_back(filterPtr);
    }
}

丨4. 实现效果

处理前：

input1_1     input2_1

处理后：

res1_1     res2_1

大家可以对比感受上面处理前/后效果。

• 第一组效果

     处理前：背景音乐和人声音量差不多。

     处理后：人声相对于背景音乐更加突出，对话内容更加清晰。

• 第二组效果

     处理前：音乐和人声较平，音量差别不大。

     处理后：人声相对于处理前更加清晰和突出，明显增强。音乐沉浸感也比处理前效果更好。

六. 小结

本文围绕播放器音频后处理中的重低音与清晰人声两种典型音效处理，简要介绍了其实现逻辑、关键参数控制策略，以及在播放链路中的集成方式。这两种处理在实际应用中具备较强的通用性，适用于大多数通用内容场景。

后续文章将继续分享更多音频后处理技术实践，敬请关注。

7月26日，2025世界人工智能大会暨人工智能全球治理高级别会议（WAIC）在上海开幕。同期，由国家地方共建人形机器人创新中心（以下简称“国地中心”）与中国电子学会联合承办，百度智能云、中国联通上海分公司联合协办的“2025人形机器人与具身智能创新发展论坛”成功召开，多位院士及国际专家出席交流，百度集团副总裁袁佛玉受邀出席并发表演讲。

袁佛玉表示，具身智能正值产业发展关键窗口期，百度智能云将聚焦做好“技术赋能者”和“场景链接者”两大角色，依托自身强大的AI基础设施和行业解决方案，助力具身智能关键技术和产品研发，并携手行业共同发掘可规模化落地的高价值场景应用，加速技术成果转化步伐。

基于行业共性需求和面临的落地挑战，百度智能云围绕具身大脑、运控小脑、具身数据集建设、整机本体研发四大领域发力，助力企业具身智能关键技术及产品研发。

在具身大脑模型研发方面，依托百度百舸GPU云平台，百度智能云是第一家全面适配RDT、π0和GR00T N1.5三大主流开源具身VLA模型的云厂商，助力企业算法工程师快速开启VLA技术路线探索。同时，通过训推工程优化，显著提升视觉语音模型（VLM）和世界模型（WM）的训练和推理性能，为企业在行业发展关键阶段赢得领跑先机。

百度智能云AI基础设施已入选2025WAIC重点创新成果，将以算力、平台到应用的系统级能力，推动更多具身智能企业产品应用的深度落地与创新突破。

在具身数据集建设方面，针对行业面临的数据稀缺难题，百度智能云将自身在自动驾驶和互联网等领域沉淀的专业化、规模化的多类型数据采集和标注能力迁移至具身智能领域，全力支持包括国地中心在内的多家企业的大规模具身数据采标工作，为具身模型的研究工作提供燃料。在具身智能数据采标服务领域，百度智能云已成为国内市场份额第一的云厂商。

此次论坛也见证了创新中心训练场合作生态签约，国地中心、河南分训练场、常熟分训练场、中国联通、上海人工智能实验室、百度智能云等企业将共同助力人形机器人在多元实景中打磨迭代，更快从“实验室”走进真实生活。

在场景应用方面，百度智能云在多年实践中已积累了包括教科研、康养、制造、物流、能源、商业、生科等千行百业的人工智能落地和复制经验。以真实落地场景为基础，百度智能云正在与具身企业携手构建开放共赢的产业生态，助力具身企业跨越创新鸿沟。

人形机器人新品WAIC齐亮相，百度智能云愿与创新者携手同行，全方位支撑企业加速具身智能关键技术和产品研发，助力场景应用多样化落地。

今天，我们参加2025世界人工智能大会（WAIC），并带来两个好消息—— 萝卜快跑、飞桨深度学习平台、百度智算集群入选中国人工智能产业创新成果展。 同日，百度慧播星发布新一代数字人技术 NOVA，将于

近日，基于“百度百舸GPU云平台+昆仑芯P800”构建的国产万卡集群，以卓越表现，率先成为首家通过中国信息通信研究院《面向大规模智算服务集群的稳定运行能力要求》测评的国产万卡级别集群，且在基础设施、集群调度、模型训练保障等核心测评维度上，斩获最高等级“五星级”。这不仅是对百度智能云当前技术实力的权威认可，更标志着国产万卡集群在稳定性与成熟度上达到了全新高度，为产业智能化提供了坚实可靠的算力底座。

硬核底座：百舸+昆仑芯，打造“多快稳省”AI基础设施，让万卡集群持续稳跑

支撑超大规模智算集群的稳定高效运行，是全球科技企业面临的共同挑战。百度智能云基于“百度百舸GPU云平台+昆仑芯P800”构建的国产万卡集群通过最高等级测评，正是攻克这一难题的硬核答案。

昆仑芯P800是一款真正意义上为大模型而设计的芯片，它采用了完全由昆仑芯自研的XPU-P架构，显存远超同类芯片。而AI芯片非常敏感，随着集群规模扩展，故障率一定会快速增长，对于整个业务影响是指数级的。这就要求，在硬件之上，还必须有一层好的软件管理系统，保证集群的稳定运行。百度百舸GPU云平台，围绕落地大模型全旅程的算力需求，在集群创建、开发实验、模型训练、模型推理四大方面，能为企业提供“多快稳省”的AI基础设施，在万卡集群的建设中发挥了至关重要的作用。在万卡任务上，百舸平台可以保障有效训练时长占比达到99.5%。在推理加速的极致优化上，百舸平台基于大规模PD分离式推理系统以及多专家并行机制，支撑千帆平台为40万客户提供服务。上线以来，千帆的推理吞吐提升了20倍，推理速度提升了50%以上。这一独特的技术优势也助力百度智能云成功突破头部科技企业及中腰部客户市场，推动GenAI IaaS业务实现跨越式增长。

智算未来：加快推动大模型产业化发展，释放更多场景价值

今年2月，百度智能云已成功点亮昆仑芯P800万卡集群，这也是国内首个正式点亮的自研万卡集群；4月，再一次成功点亮国内首个全自研的3万卡集群，可同时承载多个千亿参数大模型的全量训练，支持1000个客户同时做百亿参数的大模型精调。该集群建设了超大规模的高性能网络，能够保证大规模集群执行训练任务时的稳定性，创新性地设计了显著降低能耗的散热方案。大模型赋能产业是一场长期接力，百度会坚定投入，打造更先进、高效的人工智能基础设施，服务更多的中国企业，加快推动大模型产业化发展，释放更多场景价值。

未来一年，将是各种AI原生应用爆发的黄金时期。自研芯片和万卡集群的建成带来了强大的算力支持，同时有效提升用户的资源整体利用率，降低大模型训练成本，推动模型降本，将为产业的全面繁荣乃至整个行业的长远发展提供了新思路和新方向。

在智能化转型浪潮中，企业如何构建具备深厚知识底蕴的AI应用？面对海量信息需求，开发者又该如何高效获取权威知识资源？百度智能云千帆应用开发平台AppBuilder持续强化高质量组件生态建设，现上线「百度百科系列组件」，提供2900万+权威词条、秒懂视频等独有知识服务能力，作为千帆平台组件生态的全新成员，首次深度释放百度核心知识服务能力。依托平台完善的组件服务体系，用户可一站式调用百科权威数据与视频能力，在政务、教育、医疗等场景中快速构建可信、专业的知识中枢，加速推动智能应用落地。

三大能力组件：让知识调用更智能

三大核心优势：定义知识服务新标准

核心能力一：权威背书，数据可信

百度百科作为百度旗下最具公信力的权威知识品牌之一，至今已运营19年，平台积累2900万+词条，拥有近800万贡献用户，产生超2.7亿次编辑；累计合作权威机构超过500家，合作权威专家上千位，致力于为用户提供更具权威性、时效性、全面性的知识内容。

核心能力二：全维知识形态，满足多元场景

文字+视频双引擎，除结构化词条内容外，独家集成秒懂百科短视频资源，轻松实现轻量化知识传递；支持百万级并发查询，响应速度毫秒级，适配实时问答、内容推荐等高并发需求。

核心能力三：开箱即用，无缝集成千帆生态

提供标准化组件及API接口能力，开发者可一键使用，大幅降低Agent构建成本。

最佳实践：三步打造知识学习助手

百度智能云千帆应用开发平台AppBuilder构建了完善的组件生态，不仅提供单点能力突破，更支持模块化自由组装。用户通过组合不同组件，可构建具备多重能力的智能体（Agent），解决单一工具无法覆盖的复杂场景需求。在知识助手场景下，百度百科系列组件+百度AI搜索系列组件，就是最标杆的使用案例，借助百科结构化的权威知识优势以及搜索实时获取全网最新资讯，权威验证+动态扩展让知识助手可以输出“可验证、有来源、实时更新”的知识服务。

以通过「百科组件+搜索组件」标杆搭建一个“十万个为什么”知识学习助手为例，以下为具体操作步骤：

**Step1 选择最适合的智能体配置方式：**本次配置选择最为基础便捷的「自主规划Agent」，如使用情况需严格配置agent回复逻辑，可选择「工作流Agent」

**Step2 应用配置及能力扩展设置：**完成应用的基本信息配置，在能力扩展部分选择百度AI搜索系列组件以及百度百科系列组件。

**Step3 应用调试：**在预览与调试部分输入相关query进行测试，根据返回的结果对角色指令、组件、记忆等相应板块进行调整，直至完成预期想要的agent效果。

“十万个为什么”知识学习助手具备借助搜索的检索及智能生成能力，同时覆盖词条、秒懂视频等扩展知识元素，真正成为了一个六边形知识学习助手。可以看到在效果上，当我们输入“牛顿力学”这个复杂名词后，Agent依次调用百科词条、智能搜索生成最终给到名词的解释，并配合引用百科词条进行知识理解。

与此同时，百度智能云千帆应用开发平台AppBuilder平台现提供百度百科系列组件每日100次的免费使用额度，助力开发者们亲身体验如何将2900万+权威词条与海量秒懂视频，快速、无缝地集成到您的智能应用中，释放知识驱动的无限潜能！

百度智能云千帆大模型平台始终致力于为用户提供全流程、一站式的AI服务，以开放性、易用性、低成本的平台理念，让企业用户和开发者能够更高效地探索大模型应用，提升创新效率，加速各类AI应用从概念到落地的转化。

在沈阳市皇姑区的北边，一片极具科技感的大楼拔地而起。

这是新建成的沈阳人工智能产业园，也是百度和沈阳“AI的结晶”。

从23年冬天掘开冻土的第一铲，到88天完成主体封顶，再到如今盛大开园，沈阳人工智能产业园，仅用20个月就完成了从蓝图到现实的跨越。

7月10日，沈阳人工智能产业园（一期）正式开园！

当天，辽宁省委副书记、省长王新伟在沈阳与百度创始人李彦宏一行座谈，共同出席沈阳人工智能产业园（一期）开园仪式。

百度将充分发挥技术优势，进一步加大在辽投资布局力度，深化人工智能大模型、企业数字化转型、数字政府建设等领域合作，带动更多同业伙伴走进辽宁、深耕辽宁，为辽宁产业转型升级、经济社会高质量发展贡献力量。

去年，辽宁省与百度签署战略合作框架协议，沈阳市皇姑区与百度智能云（沈阳）科技有限公司签署框架合作协议。

辽宁与百度合作，已结下累累硕果：

开园即满！40家企业入驻

作为皇姑区重点建设项目，沈阳人工智能产业园全国首创了“四个一”模式，即一个高性能AI基础设施底座、一个超亿产值数据标注基地、一套AI大模型和数据要素流通平台、一个产业应用场景展示中心，落地“1产业园+4中心+N场景”。该产业园依托AI计算集群和全栈基础设施，深度融合百度文心大模型、百度百舸AI异构计算平台等多项前沿技术，将为入驻企业提供从技术到数据、算法及模型的全方位服务。

开园仪式上，通算互联、信安世纪、浪潮信息等首批40家企业完成入驻，其中包含上市企业、细分行业头部企业、国家级战略性新兴产业企业，涵盖芯片研发、AI计算服务、数据标注、大模型应用等全产业链环节，实现开园即满园。

东北首家！相遇沈阳皇姑

2024年1月，百度智能云（沈阳）科技有限公司在沈阳市皇姑区正式落地。该子公司将依托百度智能云多年积累沉淀的人工智能应用技术、AI大模型能力，围绕人工智能、大数据等上下游产业链进行产业导入。未来基于沈阳人工智能产业园的发展，形成产业集聚，未来5年将形成百亿产业规模，支撑沈阳乃至整个东北地区的产业数字化转型和智能化升级。

“一网统管”，用AI感知城市

大连市“一网统管”项目由百度智能云全力打造，以AI为核心驱动，建设城市智能感知网和协同共治平台。例如在防台防汛期间，平台汇聚气象数据、隐患点位、应急资源等信息，构建“防台防汛一张图”，通过AI算法对重点区域分级预警，提升日常巡查效率；应急处置时，依托综合指挥系统实现跨部门资源统一调度，提升协同决策效率，筑牢城市安全防线。

AI上线，打造更懂工艺的机械臂

华晨宝马自主开发企业级大模型Agent服务平台，将本地开源解决方案与百度文心大模型、飞桨深度学习平台相关技术结合，同时结合多模态知识库与Agent技术，打造出能自主理解、规划和执行复杂任务的综合智能体系统。

过去，传统机械臂方案缺乏自适应能力，上线时需按照工艺位置逐个调节。当工艺变动或出问题时，还会再额外增加IT适配的时间与人力成本。现在，基于大模型Agent服务平台的车间机械臂解决方案，机械臂可以随时替补进任何工区作业，大大节省时间和培训成本。

校企合作，共育AI人才

辽宁是百度“1000万AI人才培养计划”的重要合作伙伴。依托深厚的校企合作基础，百度与辽宁高校构建了多元化的人才培养体系，在课程共建、技术竞赛、师资培训等方面取得了丰硕成果。

通过百度之星编程竞赛、国际大数据竞赛等，百度在大连理工大学等省内高校，为教师教学与学生工程能力实践，提供了良好技术学习与交流的平台；同时，双方通过共建松果人才实践基地，进一步培养了许多高质量的AI工程能力人才。

立足沈阳、辐射东三省

我们将与沈阳一起

共绘“辽”阔智能新图景

PaddleOCR 3.0自5月20日发布以来，受到业界的广泛关注，同时我们也收到了众多宝贵意见。我们积极响应、快速升级迭代，并在近日发布了 PaddleOCR 3.1，带来了3个新升级：

■ 三大升级

• 新增 PP-OCRv5多语种文本识别模型。支持法语、西班牙语、葡萄牙语、俄语、韩语等37种语言，平均识别精度提升超过30%。同时依托文心4.5多模态能力，实现了数据的自动高质量标注，有效解决了多语种数据稀缺和标注成本高的问题，进一步提升了模型在多语言、多场景下的识别能力。
• 新增文档翻译 PP-DocTranslation 产线。PP-DocTranslation 基于文档解析 PP-StructureV3和文心4.5大模型，支持对 Markdown、PDF 和图片三种格式的文档数据进行翻译，同时支持本地传入专业术语对照表，实现关键词汇的精细化多语言翻译。
• 支持 MCP 服务器。用户可通过简单的步骤搭建 MCP 服务器，将通过本地 Python 库、云服务、自托管服务等多种方式运行的 PaddleOCR 核心能力统一集成到下游 AI 应用中，实现更灵活高效的应用构建。

01

30+语种文字识别精度跃升30%

随着世界各地交流合作的加深，多语种文本识别正成为智能应用领域的重要需求。为提升多语种场景下的文字识别能力，我们通过融合文心大模型的视觉和文本理解能力，实现了高效、高质量的训练数据获取，升级 PP-OCRv5在37种语言文字的识别能力，包括韩文、西班牙文、法文、葡萄牙文、德文、意大利文、俄罗斯文等。与前代多语种文字识别模型相比，PP-OCRv5在多语言场景文字识别准确率提升超过30%。

▎ 关键步骤——文心4.5助力多语种文字高质量数据构建

• 自动文本行检测与裁剪：利用 PP-OCRv5检测模型，自动定位并裁剪图像中的每一行文本，快速、高效地获取标准化的文本行图片。
• 高置信度文本内容识别：依托文心4.5强大的视觉和文本理解能力，对每个文本行图像进行多次独立识别，筛选出识别结果一致的样本。不仅显著提升标注数据的准确性，还有效规避了人工标注的主观误差，确保数据高质量和高可靠性。

▎ 模型精度对比

注：

• 为更全面评估多语种模型能力，本次模型研发过程中重新收集了大量来自真实场景的高难度评估数据。
• 拉丁字母文字涵盖西班牙文、葡萄牙文、法文等33种语言文本。东斯拉夫语言涵盖俄文、乌克兰文、白俄罗斯文。

▎ PP-OCRv5多语种文字识别命令行使用方式

可以通过在命令行中使用--lang 参数，来进行指定语种的文本识别模型推理：

# 通过 `--lang` 参数指定使用法语的识别模型

paddleocrocr-ihttps://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_french01.png \

    --langfr \ # 此处为法语，刚多请参阅文档

    --use_doc_orientation_classifyFalse \

    --use_doc_unwarpingFalse \

    --use_textline_orientationFalse \

    --save_path ./output \

    --devicegpu:0

上述命令行的其他参数说明请参考通用 OCR 产线的命令行使用方式。

02

PP-StructureV3+文心大模型

复杂文档翻译更简单

在全球化和信息化加速发展的背景下，文档翻译在现代社会中已成为一种不可或缺的需求，企业和个人需要高效、准确地翻译各类复杂文档。为此，我们结合 PP-StructureV3和文心大模型，推出了复杂文档翻译工具 PP-DocTranslation。PP-StructureV3具备强大的复杂文档解析能力，能够轻松应对很多复杂布局的 PDF 文档及文档图片，并高效地将其转换为 Markdown 格式输出。我们在此基础上，融合了文心大模型强大的文本理解和语义分析能力，对生成的 Markdown 结果进行进一步处理，实现了对相关文档的高质量多语言翻译。 此外，为了更好地服务于各类专业领域对精准翻译的需求，该工具特别增加了用户自定义词表功能，用户可以根据自身业务或领域的专业术语，自定义词汇表，从而实现特定场景下更加准确、专业的翻译结果。

▎ 效果展示

▎ 文心4.5助力多语言翻译

• 精准翻译：依托文心4.5对多语言的理解，能够实现更为精准、地道的目标语言翻译效果。
• 多语言支持：借助文心4.5的多语言处理能力，满足多样化多语言的翻译需求。

▎ PP-DocTranslation 的 CLI 体验方式：

可以通过在命令行中使用--target_language 参数，来进行指定要翻译的目标语言：

paddleocr pp_doctranslation -i vehicle_certificate-1.png --target_language en --qianfan_api_key your_api_key

03

支持 MCP 服务器 轻松连接大模型

发挥 OCR 的无限想象空间

MCP 是一种开放协议，用于规范应用程序向大语言模型提供上下文信息的方式。可以将 MCP 类比为 AI 应用中的 USB 接口。正如 USB 为设备与各种外设和配件之间的连接提供了标准化方式，MCP 同样为 AI 模型与不同数据源和工具之间的连接提供了统一规范。通过支持实时调用数据或 API，MCP 能有效拓展应用场景、降低开发门槛，并提升系统安全性。如今，MCP 正逐渐成为推动 AI 生态落地的关键连接桥梁。

为了更便捷地将 PaddleOCR 能力集成至各类 AI 应用中，PaddleOCR 3.1版本支持用户通过几步简单操作，即可搭建 MCP 服务器。具体而言，根据 MCP 协议，AI 应用（作为 MCP 主机）通过 MCP 客户端与 PaddleOCR 的 MCP 服务器进行通信。PaddleOCR 的 MCP 服务器则通过 Python API 或服务请求等方式调用其核心能力，并将这些能力标准化后提供给下游的 AI 应用使用。下图展示了 PaddleOCR 核心功能、PaddleOCR MCP 服务器以及 AI 应用之间的关系：

当前，PaddleOCR MCP 服务器支持以下能力：

• 文字识别：对图像和 PDF 文件进行文本检测与识别，返包含文字坐标和文字内容的 JSON 文件。
• 文档解析：从图像或 PDF 中识别和提取文本块、标题、段落、图片、表格等版面元素，并将内容结构化输出为 Markdown 文档和 JSON 文件。

根据 PaddleOCR 的运行方式，MCP 服务器支持以下工作模式：

• 本地 Python 库：在本地直接运行 PaddleOCR 模型。
• 星河社区服务：调用托管在飞桨星河社区的服务。
• 自托管服务：连接用户自行部署的 PaddleOCR 服务。

同时，PaddleOCR MCP 服务器支持 stdio 和 Streamable HTTP 两种传输机制，用户既可以本地部署服务实现快速集成，也可以远程调用服务，满足不同场景的使用需求。

同时，PaddleOCR MCP 服务器支持 stdio 和 Streamable HTTP 两种传输机制，用户既可以本地部署服务实现快速集成，也可以远程调用服务，满足不同场景的使用需求。

搭建 MCP 服务器并集成到 AI 应用中，仅需几个简单步骤。下面以“星河社区服务”模式为例，介绍如何在 Claude for Desktop 中使用 PaddleOCR MCP 服务器提供的工具。

1.参考 PaddleOCR 官方文档，在星河社区部署推理服务

• PaddleOCR 官方文档：

paddlepaddle.github.io/PaddleOCR/v…

• 星河社区：

aistudio.baidu.com/pipeline/mi…

2.将 Claude for Desktop 配置文件 claude_desktop_config.json 修改如下（需安装 uv）：

{
  "mcpServers": {
    "paddleocr-ocr": {
      "command": "uvx",
      "args": [
        "--from",
        "paddleocr-mcp@https://paddle-model-ecology.bj.bcebos.com/paddlex/PaddleX3.0/mcp/paddleocr_mcp/releases/v0.1.0/paddleocr_mcp-0.1.0-py3-none-any.whl",
        "paddleocr_mcp"
      ],
      "env": {
        "PADDLEOCR_MCP_PIPELINE": "OCR",
        "PADDLEOCR_MCP_PPOCR_SOURCE": "aistudio",
        "PADDLEOCR_MCP_SERVER_URL": "<替换为服务基础 URL>", 
        "PADDLEOCR_MCP_AISTUDIO_ACCESS_TOKEN": "<替换为星河社区访问令牌>"
      }
    }
  }
}

3.重启 Claude for Desktop。新的 paddleocr-ocr 工具现在应该可以在应用中使用了，如下图所示：

如果希望使用 PP-StructureV3的文档解析能力，只需参考上述步骤，在星河社区部署文档版面解析 V3产线，并在配置文件中替换对应的服务基础 URL 即可。除了基本配置外，PaddleOCR MCP 服务器还提供丰富的可调参数，用户可根据需求灵活调整，例如替换为自训练的文本识别模型、关闭不需要的功能模块等。

关于更多详细用法，请参考官方文档：

paddlepaddle.github.io/PaddleOCR/v…

▎ 创新案例

以下展示了使用 PaddleOCR MCP 服务器结合其他工具搭建的创意案例：

Demo 1：在 Claude for Desktop 中，提取图像中的手写内容，并存到笔记软件 Notion。PaddleOCR MCP 服务器从图像中提取了文字、公式等信息，并保留了文档的结构。

• 除 PaddleOCR MCP 服务器外，此 demo 还使用 Notion MCP 服务器（developers.notion.com/docs/mcp）。

Demo 2：在 VSCode 中，根据手写思路或伪代码一键转换为可运行并符合项目代码风格规范的 Python 脚本，并将其上传到 GitHub 仓库中。PaddleOCR MCP 服务器从图像中高准确率地提取手写代码供后续步骤使用。

• 除 PaddleOCR MCP 服务器外，此 demo 还使用 filesystem MCP 服务器（github.com/modelcontex…）。

Demo 3：在 Claude for Desktop 中，将含有复杂表格、公式、手写文字等内容的 PDF 文档或图片转存为本地可编辑文件。

PDF 转为 Word 可编辑格式

图片转为 Excel 可编辑格式：

• PaddleOCR MCP 服务器外，此 demo 还使用 filesystem MCP 服务器（github.com/modelcontex…

■ 结语

自 PaddleOCR 3.0发布以来，我们收到了大量关于多语种识别和 MCP 支持的需求反馈。为此，我们近期推出了升级版 PaddleOCR 3.1。欢迎各位开发者、研究者和行业用户下载体验 PaddleOCR 3.1，并积极提出宝贵建议和反馈。大家的支持和参与将持续助力我们打造更加优质、开放和强大的 OCR 生态！

开源地址：github.com/PaddlePaddl…

7月3日，2025全球数字经济大会人工智能融合应用发展论坛在国家会议中心举办，论坛聚焦“AI应用落地”，以“大模型•深应用•强产业”为主题。

百度副总裁阮瑜受邀出席论坛，并发表《产业发展新动能—百度大模型应用赋能产业智变》主题演讲，分享了对大模型应用趋势变化的洞察——大模型使用成本降低、企业AI采用率提升，大模型应用形态在加速演进、应用边界在不断拓展。在此背景下，百度智能云持续推进大模型应用的创新，阮瑜现场讲解了“高拟人”数字员工的上线、视觉AI对降低企业生产成本的帮助、交通智能体的行业应用等，深入探讨人工智能如何赋能千行百业，推动数字经济高质量发展。

大模型应用所呈现出的新趋势

在过去一年，大模型应用的单价使用成本下降了将近60倍，企业AI端在使用大模型的应用比例也在大幅上升。大模型AI的应用已经开始变成企业的核心生产工具。

大模型应用本身，有三个趋势发生：

• 第一，从单智能体向多智能体演进，通过多个智能体分工协作，既能发挥各智能体的专业优势，又能通过交叉验证降低幻觉；

• 第二，单模态向多模态转型，伴随底模能力提升，跨模态技术在应用端快速落地，交互形式也从单一对话拓展至图片、视频等多元模式；

• 第三，应用形态从辅助决策向自动执行升级，随着MCP接口普及，多智能体协同自主执行能力增强，可通过流程串联完成复杂场景的产品体验。

同时，伴随着大模型应用边界持续拓展，企业开发门槛也显著降低。底模能力提升推动低代码/零代码应用产品涌现，开发者得以快速生成场景化应用。当大模型与场景知识深度结合后，应用场景从高容错的简单场景向低容错的复杂场景延伸。在付费模式上，效果驱动成为重要方向，国内外客户对按效果付费的接受度逐步提高，尤其在销售线索等领域已有诸多实践案例，预示着AI RaaS（Result as a Service）模式将成为大模型应用商业模式的关键形态。

AI生产力：数字员工真的走向现实

在通用应用领域，多智能体协作正推动数字员工从概念走向现实。百度智能云数字员工通过融合数字人真人级形象技术与大模型对复杂场景及行业SOP的深度理解，形成高度拟人化交互能力，可在真实业务场景中精准响应用户需求。**该产品上线15天内，官网访问量激增70%，线索收集量达传统模式的2倍，**其在复杂场景下支持多轮对话即时打断、实时捕捉客户需求并跟进的能力，目前已在多行业实现落地应用。

多模态重构视觉AI：让生产成本大幅下降

除了数字员工这类场景，大模型的多模态应用也解决了很多原来小模型没有办法解决的问题。在过去，小模型的成本非常高，并且95%的碎片化需求没有办法通过小模型解决。但是当大模型的算力成本逐步下降、生成应用的成本也在下降，这使得大模型在多模态这个领域里有非常大的市场潜力和空间。

百度智能云一见正是基于多模态大模型全面重构的全视觉管理数字化平台。目前，一见已在安全生产管理、服务合规管理及品质管控等领域实现大范围覆盖，成功帮助众多客户在降本增效方面取得显著成效。

公路上的AI：从通用赋能到行业深耕

大模型在通用应用里不断延伸的同时，也在逐步去往行业领域——聚焦解决行业 “深水区” 痛点。百度智能云基于大模型技术与深厚的行业Know-how积累，推出了一系列行业应用来帮助客户解决应用落地的问题。

在交通领域，百度智能云交通Agent产品改变了传统以“人工经验”为主的交通治理模式，通过大模型辅助交通管理者、参与者在复杂路况中做出科学决策和应对。在交通治理场景中，成功打造指挥专家、信控专家、智能问答等智能体。以京雄高速为例，在其作为“准全天候通行的智慧高速”示范路的建设过程中，河北高速通过与百度智能云合作，携手实现了交通事件一站式处置，做到准确发现危险事件-危险事件发现准确率达到95%，快速完成应急处置-处置时间从1小时缩短到30分钟左右。

在信控领域，百度智能云信控专家Agent能够基于信控方案自动识别、路口流量还原，以及信控策略优化等核心能力，短时间内输出一套完整的信控解决方案。在跟鄂尔多斯一个交警大队的合作中，凭借全新的大模型信控技术，实现了整个车均延误率达到21%的改善，同时干线平峰期间的停车达到0次，真正做到了让出行畅通无阻。

应用层的更多爆发：期待共同探索

大模型未来在多模态交互、跨领域知识融合等方向潜藏海量机遇。随着底模在算法效率、长文本理解、逻辑推理等能力上持续突破，应用层将在更多场景加速落地。百度智能云期待与行业伙伴共同探索大模型与垂直领域的深度结合，推动技术从通用能力向行业专属解决方案进化，以生态共建模式解锁更多创新可能，携手赋能千行百业数字化升级。

导读

主要概述百度搜索业务数据建设的创新实践，重点围绕宽表模型设计、计算引擎优化和新一代业务服务交付模式（图灵3.0开发模式）三大方向，解决了传统数仓在搜索场景下面临的诸多挑战，实现了搜索数据建设的高效、稳定、低成本；为百度搜索业务敏捷迭代奠定夯实基础。

名词解释

TDS（Turing Data Studio）： 是基于图灵（百度内部数据分析平台）的数据建设解决方案，提供 数据开发、数仓管理、监控运维、资源管理等一站式服务的数据开发平台。详情参见：百度MEG数据开发治理平台-TDS

TDA（Turing Data Analysis）：是一款可视化BI产品，旨在帮助用户轻松上手及使用，进行拖拽式可视化数据分析及仪表盘建设。产品模块包括仪表盘、数据集、可视化分析及智能分析模块。详情参见：百度一站式数据自助分析平台（TDA）建设

TDE（Turing Data Engine ）：是基于图灵生态的计算引擎，包含Spark计算引擎和ClickHouse。详情参见：揭秘百度数仓融合计算引擎ClickHouse在百度MEG数据中台的落地和优化

UPI（Udw-API）：百度内部编程访问接口；以Map/Reduce计算框架为主，适用于计算逻辑复杂，以及多种数据源混合计算的例行离线数据挖掘业务

数仓融合计算引擎：是百度自主研发，基于spark自研的adhoc服务。提供数据查询分析，具有简单易用、超大规模支持、成本极低等特点，能实现T级数据秒级查询，也适用于例行生产的 ETL 场景。

函谷：图灵核心模块，作为图灵查询的gateway，完成图灵查询的接收、分发、提交执行、查询进展轮询、结果获取等一系列功能。

01 背景与问题

1.1 背景

在当今互联网产品发展日新月异、业务迭代迅猛的时代；跨业务分析的需求日益增长，这种变化既为企业创造了敏捷决策、精准运营的新机遇，也带来数据割裂、价值释放滞后等严峻挑战。特别是大型互联网企业，往往构建有复杂的多业务、多模块、多线条体系，每日持续产出海量的数据信息。这些数据的服务对象正逐步从数据研发人员扩展至更为广泛的产品相关人员，如何高效开展数据获取工作，打破数据孤岛现象，充分挖掘并释放数据驱动业务的潜力，已成为业界广泛关注和讨论的焦点议题。针对该问题，业界传统数仓常采用的是经典分层模型的数仓架构，从ODS（Operational Data Store）>DWD（Data Warehouse Detail）>DWS（Data Warehouse Summary）>ADS（Application Data Store）逐层建模，但我们会发现，从传统固化开发的角度来看，传统经典数仓模型是比较有优势的。然而，面对当下数据需求灵活多变的时代，其局限性也日益凸显。如下图

1.2 搜索场景下的困境与挑战

搜索作为百度的核心支柱业务，涵盖通用搜索、智能搜索、阿拉丁与垂类等多元化、多模态的搜索产品，具有快速迭代、模块多元化且复杂的特性，搜索数据更是复杂多样，整体数仓规模达到数百PB以上。

随着搜索业务各个模块之间的联系日益紧密，交叉分析的需求也在不断增长。使用人员对数据获取的便捷性提出了更高的要求，其中涵盖了数据分析师、策略、业务产品经理、运营、评估等多类角色。他们的诉求期望能够跨越复杂的数据架构壁垒，以更加高效、直观、快速的方式获取到所需数据。

而传统的搜索数仓建设体系 无论从建模角度还是技术框架上，都与现阶段用户诉求背道而驰。

1. 建模角度：多层的传统分层建模。往往会出现（大表数据量大、查询慢、存储冗余、口径不统一）等问题，影响业务分析效率，从而达不到数据驱动业务的效果。数据开发侧作为需求的被动承接方，根据业务侧提出的数据需求进行数据开发与交付，存在需求交付周期长、人力成本高等问题。

2. 技术框架角度：搜索数仓过去大多是采用UPI框架（以C++ MR计算框架为主）进行ETL处理。由于该框架技术陈旧，往往会出现以下问题影响数仓整体时效、稳定。从而使业务部门感知需求支持迟缓、数据产出延迟及数据质量低等一系列问题。

• 容易出现服务不稳定。

• 处理能力薄弱：处理不了特殊字符，从而导致数据丢失或任务失败等。

• 只能通过物理机远程执行的方式提交，有单节点风险。

• 无法Writer将数据写到Parquet文件，需要进行特定脚本ETLServer框架进行转换。

思考：如何更好的满足用户角色需求，进一步降低数据获取的使用门槛？

破局：拥抱变化，以用户诉求为核心出发点。 探索更适合用户的 体系化建模 来进行实质、有效的数据管理。

**体系化建模：**以业务产品需求驱动模型设计，以模型设计驱动和约束开发实施，防止因模型设计与业务产品割裂、开发实施缺少约束带来的无序、“烟囱式”开发。在机制上形成模型设计与开发实施的有效协同。

切入点：以规范“基础数据建设”，消除因“烟囱式”开发给业务带来的困扰和技术上的浪费。

由此我们探索出一套新的建模体系：大宽表+数据集：其核心点就是基于宽表 将之前的"需求-交付"解耦为以数据集为中心的建设，从而提升搜索内业务数据分析效率与分析深度，更好助力业务决策。以下将从宽表建模、计算引擎架构优化、新型业务交付模式等方向为大家介绍搜索数据团队业务实践。

02 搜索建模思路与技术方案

2.1 建模模型

2.1.1 思路

基于搜索产品功能特性与差异化业务场景，我们对日志数据进行主题化的分类。在每个主题域内，结合业务运营的具体环节特征，构建具备高整合度的宽表模型。在模型构建过程中，保持 ODS（操作数据存储）层与 DWD（明细数据层）的表结构粒度一致，确保数据的一致性与连贯性。所构建的宽表不仅完整涵盖下游业务所需的全部字段，包括业务明细表中的基础数据，还整合了各层级的维度属性与计算指标。通过这种方式，形成一个全面、统一的数据底座，为上层业务的多维分析、指标监控及决策支持提供坚实的数据支撑，有效满足多样化的业务分析需求。

2.1.1.1 举例

以展点主题为例，从历史的模型表粒度和模型层级来分析：ODS与DWD、DWS表行为、检索、点击各个主题在同层模型或者跨模型之间都存在字段、口径的冗余，如下图

2.1.1.2 思路分析过程

核心思想过程：展点主题下明确粒度，丰富维度&指标 建设宽表模型。

将展点主题下各层之间的事实表复杂嵌套字段打平后与各个维度表、指标等进行join生成宽表，宽表的列最终分为公共属性、展点行为属性、业务属性和指标属性。

消除：

• 数仓层间：字段存储冗余问题

• 数仓层内：口径不一致问题

2.1.2 建模核心思想

基于思路分析过程，总结出一套核心建模理论，核心思想如下图

构建搜索系统性数据建模：根据产品功能和业务不同，按照不同主题构建宽表。从而达到节约存储、精简表数量、口径更清晰的目标。

2.1.3 整体模型架构

基于核心建模思想理论得到整体的模型架构，如下图

• 采用Parquet列式存储，可支持宽表数百、千列，超多字段，再经过按列的高效压缩（bucket sort后，压缩率更高），降低了数仓整体存储空间，提高了IO效率，起到了降低上层应用延迟的效果。

• 将各层之间的表复杂嵌套字段打平后与各个维度表、指标等进行join生成百列宽表，宽表的列最终分为公共属性、业务维度属性和指标属性，便于业务分析，实现快速迭代。

2.2 计算引擎

为了保证数据生产稳定、准确性。我们对计算引擎的选择做了升级，采用传统Spark结合数仓融合计算引擎对搜索数仓ETL进行重构。

2.2.1 从架构&处理流程上

• C++ MR ：多进程，每个任务独立运行，必须经过Map-Shuffle-Reduce，然后中间结果写磁盘。

• Spark ：多线程，任务在Executor内以线程执行。基于DAG，可以在内存中缓存数据，减少IO。

Spark 框架 相较于 MR框架优势在于

• 基于内存计算，处理速度快。

• 支持多种计算模式，功能丰富，适合迭代处理数据。

• 提供了高级的 API，开发效率高。

• 基于平台提交，有效避免单节点计算风险。

且在有shuffle情况下计算表现更好（MR在Shuffle时默认进行排序，spark对shuffle有优化，只有在部分场景才需要排序），在具体业务实践中：同耗时的情况下，Spark计算资源相较于MR节省20%左右。

2.2.2 ETLServer到数仓融合引擎转变

各主题宽表模型的计算通过数仓融合计算引擎（通过Spark Application Context常驻方式做到资源有效复用；省去了启动Driver的时间实现任务的快速启动，来提升任务执行时间）可直接Writer将数据写到Parquet文件，文件无需进行多次脚本server转换。

在具体业务实践中 各主题计算耗时由之前40min 缩短至 10min（减少了30min），实现数仓快速产出。

2.3 新数据模型及架构下的挑战与解决方案

任何数仓模型架构不会存在一个绝对完美的、涵盖所有方面的解决方案。宽表设计仅是当前环境数仓模型的最优解，它依然面临着诸多不容忽视的挑战。

2.3.1 挑战1解决方案

1. 列式存储&读取：

宽表采用了Parquet列式存储，以及ZSTD高效压缩算法。结合数仓融合引擎，达到Data Skipping（即读的越少、计算越快）的效果，仅需读取查询涉及的分区及列，减少了磁盘 I/O 和内存传输的数据量来提升查询效率，通过Sql分析服务发现热点复杂字段，主动引导业务建设物化列，命中后查询性能提升80%。

2. 复杂嵌套字段打平：

业务常用核心指标以及高频字段口径下沉宽表。虽然行数变多了，但是避免了explode，get_json_object、array、map等复杂字段获取的耗时操作，查询性能相较于之前提升了2.1倍。

2.3.2 挑战2解决方案

搜索数据升级到了湖仓一体架构，借助Iceberg Merge Into功能，实现高效回溯方式：对表数据进行行级别的更新或删除。相比insert overwrite 操作更加高效，减少了不必要的数据移动和存储浪费。

通过单一原子操作实现了复杂的数据整合需求。相比传统的先删除再插入的方式，Merge Into提供了更好的性能和一致性保证，其原理是通过重写包含需要删除和更新行数据所在的date files。Merge Into可以使用一个查询结果数据来更新目标表的数据，其语法类似join关联方式，根据指定的匹配条件对匹配的行数据进行相应的操作

Merge Into基本语法

回溯原理流程如下图

1. 关联匹配：

• 目标表和源表根据指定key进行join操作。

2. 条件判断：

• 若Key匹配：根据源表操作类型，对目标表中的记录执行相应的操作（更新或删除）。

• 若Key不匹配：执行Insert操作，将源表数据插入目标表。

3. 原子性操作：

• 整个流程是事务性的，确保数据一致性。

以下是特定回溯场景下 hive与iceberg不同方式的回溯耗时对比，可以看的出来用merge into代替insert overwrite进行回溯，回溯更新效率整体可提高54%左右。

2.3.3 挑战3解决方案

2.3.3.1 重排序、高效压缩

开发ATO优化器(通过任务依次执行重排序、压缩等一系列Rules，实现分区优化和数据重分布)，高效率压缩，解决存储成本，存储节约20%。

（1）压缩编码

数仓表字段元信息采集：通过任务对图灵宽表表进行字段元信息采集，分析数据分布情况，获取重排序字段。

具体做法：通过RLE、Delta等缩码方式来提升数据压缩效率；数据重复度越高、连续性越好（有序）的场景，压缩效率会越高，RLE、Delta编码原理如下。

（2） 压缩格式

使用ZSTD压缩格式和更大的压缩level，在不影响查询性能的情况下，更大的压缩level能进一步提高压缩率，level=9时在压缩效率和耗时上最为平衡，读写耗时和压缩率对比效果如下。

（3） Page Size

针对Parquet文件格式特性进行深入挖掘 ，对Parquet page size进行分页扩容，将Page Size从1MB增大至5MB，让更多相似的数据集中到同一个数据页中，充分利用编码的压缩特性，进一步减少各个数据页之间存在的相似数据。在ZSTD的基础上，能进一步提升压缩效果，效果如下

2.3.3.2 历史裁剪，管理有效字段

开发了一套半自动化的通用裁剪模式，通过采集日常任务代码，sql parser模块解析出无用字段信息（尤其是大json 大map类型扩展字段的无用字段）自动化实现了裁剪。减少了 50% 的回溯任务计算资源消耗，将人力投入从5人/天降低到0.5人/天。

• 字段频率统计模块：通过对函谷 SQL 数据库和 TDS 平台 No SQL 任务的物理执行计划进行解析，实现对宽表 SQL 任务和非 SQL 任务的字段访问频率的自动化统计。

• 裁剪字段抽取模块：基于字段访问频率，每月抽取冷温字段，形成可视化的字段访问频率报表，生成裁剪 SQL。

• **冷温字段告警模块：**通过对比前一个月和本月冷温字段列表，生成当月新增冷温字段列表，然后向产品研发团队和数据RD团队发出告警，确认需要动态调整的裁剪字段；引入冷温字段告警模块，成功实现了裁剪字段的动态调整。最后，通过滚动裁剪模块自动裁剪395天前的数据，进一步降低人力/资源的消耗。

• 滚动裁剪模块：自动化滚动裁剪，裁剪宽表中395天前的数据。

基于业务实践证明：宽表数仓模型与数仓融合计算引擎的结合 比传统数仓模型 更适合 面向服务于快速迭代的驱动型业务，主要体现在

1. 查询性能巨大提升带来快速响应支持业务需求：

简单查询场景 ：Adhoc查询场景，耗时在数十秒级别，相比于普通Spark性能提升5倍。

复杂场景：业务常用复杂字段拆分打平，避免数组、map等复杂字段耗时操作、查询性能提升2.1倍。

2.口径封装下沉：封装业务核心口径，解决业务长期数据源多、口径不一致带来的数据准确性问题，省去不必要的沟通，使用更加简便。

3.减少冗余存储：相较于经典传统数仓同主题模型下存储降低30%左右。

03 基于建模与技术框架初步整合 探讨图灵3.0生态新一代业务服务交付模式

随着搜索数仓模型&计算引擎架构的重构和技术栈统一，搜索数仓定义逐步清晰化、数仓个数大幅度降低，整体趋向更加紧凑、高效以及收敛的态势。在此基础上，为了助力数据迭代效率和分析效率进一步提升，在业务线基础数仓及应用层数据建设上，百度MEG内部开发了图灵3.0生态系统（即 数仓合理建设，数据分析需求尽可能收敛到TDA平台，配套数据集建设完善），包括Turing Data Engine(TDE)计算引擎、Turing Data Studio(TDS)数据开发治理平台和Turing Data Analysis(TDA)可视化BI产品。依托图灵3.0生态，我们进而形成了一套新的开发范式—— 图灵3.0新开发模式，用来提升搜索内业务数据分析效率与分析深度，如下图（阶段三）所示

3.1 阶段一到阶段二

如之前所述：由于搜索数仓早期查询性能不理想，为了提升业务分析效率建设了大量的业务表。从而导致数据冗余、数据链路稳定性差、效率低、指标口径不一致等一系列问题。搜索数据团队通过数仓模型（将多层数据模型控制在1-2层）以及计算引擎架构升级重构、湖仓一体、高效压缩、裁剪等一系列措施解决了这些问题。数据建设更加完善规范化，搜索数仓表的数量由过去的数百张减少至20张左右，时效性大幅提升，全数据链路全流程提速4H+，数据稳定性及运维成本降低30%。

3.2 阶段二到阶段三

随着图灵3.0生态系统（包括TDA、TDS、TDE）及搜索数仓模型的日益完善，内部提出了 以数据集为核心来构建数据应用层，将数据开发侧与业务侧的依赖关系从之前的"需求-交付"解耦为以数据集为中心的建设，实现数据集<->可视化分析<->仪表盘的数据分析闭环，解决业务常用维度、指标长周期的查询分析需求 ——> 图灵3.0新开发模式。

图灵3.0新开发模式核心思想在于数据集的建设，我们将不再仅仅只是根据业务需求来定制开发数据报表，而是构建一个灵活、可扩展的数据集。使业务侧能够自主地根据需求从中提取、分析和可视化数据，以满足不断变化的业务需求。

那么，在数据集建模实践中，如何才能合理构建一个灵活、可扩展且高质量的数据集？是数据研发对数据集建模关键核心，也是最大的挑战。

3.2.1 数据集建模合理度挑战

1. 为了满足业务需求的多样性与广泛性，并支持更多的维度和指标。我们往往会倾向于在单个数据集中不断叠加新的维度和指标，这种做法虽然表面上看起来方便快捷，但实际上却导致了数据集行数的急剧增加，进而对聚合查询的性能造成了不利影响

2. 为了确保查询的高效性，同时兼顾更多维度与指标的业务需求。我们往往的做法 就是建立更多的数据集，以空间换时间去满足查询性能。

显然，这些做法之间存在着明显的矛盾，具体如下图。

3.2.2 解决方案

为了更好地找到平衡点，搜索数据团队采取了以下解决措施：

1. 明确边界：分主题建设对应数据集，单主题内 数据集尽量做到合并统一，以达到更高的集成度与一致性。

2. 明确粒度：从业务场景需求出发，单主题内数据集建设前明确数据集最小粒度 ，确保数据最小粒度既能满足主题分析的精度要求，又避免因过度细化或粗放导致的分析效能损耗，为后续数据集的结构化构建与高效奠定基础。

3. 深度性能优化：充分利用了TDE-ClickHouse强大基础引擎，例如在处理高基数去重计数字段时 创新性地采用NoMerge技术来替代传统的COUNT(DISTINCT)方法，降低了聚合层的计算负担，实现了查询性能5至10倍的提升，极大地优化了数据处理速度。

3.3 新模式带来的改变

△ 图灵3.0的数据开发新模式

1. 强化主动能力，业务自助效率显著提升：相较于以往被动式的一对一需求定制化开发模式，数据研发工作已从单纯响应被动需求转变为主动规划构建数据集。图灵3.0新开发模式下，实现数据集<->可视化分析<->仪表盘的数据分析闭环（满足 90%查询；其余10%长尾交给Adhoc查询），业务人员对日常通用需求的分析工作转移到数据集自助查询与分析上（根据数据集自助创建可视化数据报表）。可视化分析占比、业务自助率提高至90%，数据研发日常需求量减少80%。

2. 非核心常用维度指标查询性能显著提升：非核心常用维度指标由以往业务提需 查表或单独建设报表来获取数据的方式 转变为通过数据集自助下钻、拖拉拽自由组合常用维度指标，实现可视化分析的方式。借助TDE-ClickHouse 强大基础引擎能力：可视化分析效率大幅提升，从小时、分钟级的数据分析效率 提升至秒级分析。单次查询数据周期由1周内 提升至1年内（秒级完成查询），真正做到即需即查即用。

3. 血缘管理规范化，运维效率显著提升：数据血缘更加完整流程化，数仓-数据集 血缘在TDS完成闭环，数据集内字段血缘在TDA完成闭环，以数据集为纽带串联整个数据流全过程，数据链路运维效率提升2-3倍。

目前，该模式已经广泛应用于搜索各业务数据运营人员早报、周报等多种业务汇报场景。得益于该模式，搜索产品线下仪表盘周均查询（PV）高达1.7W次左右，可视化分析周均0.93W次左右 ，每周超过400多名用户参与TDA搜索数据分析工作。更重要的是，需求的交付周期实现了显著缩短，由以往的单/双周缩短至按天交付；甚至在某些情况下，业务人员能够直接自助获取所需数据。在处理重点项目时，该模式也能确保业务团队在第一时间获取到P0级别的关键数据。这种方式的转变不仅能够减轻数据开发团队的工作负担——人力成本由原先的3人锐减至1人，还能提高业务侧的数据使用效率和自主性，使得团队得以从繁琐的“取数”与“跑数”任务中解放出来，将更多的精力投入到数仓模型的优化、技术框架的探索与治理等更具战略价值的工作中去。

04 总结与展望

数据建模领域正经历从“技术驱动”向“价值驱动”的深刻转型，更加强调的是敏捷性、可解释性和业务对齐。尽管当前的技术工具愈发强大，但成功的关键依旧在于跟业务的紧密协作与一个清晰明确的治理框架。

搜索业务，作为百度内部最核心且最为复杂的板块，涵盖了多个至关重要的产品线。近年来，搜索数据团队始终致力于运用前沿技术来不断优化和完善数仓体系的建设，以坚实的基础数仓架构支撑起数据质量飞跃提升，从而高效赋能业务，带来可量化、可感知的业务成效与用户体验升级。

展望未来，随着AI代理和边缘计算等技术的蓬勃发展，数据建模有望朝着自适应与嵌入式方向进一步进化。搜索数据侧还将在以下关键方向与大家进行深入探讨、交流和学习：

• 通用数据流解决方案：构建事件规则引擎等通用数据流处理工具，简化数据处理流程，提高数据处理效率与灵活性。

• 日志埋点技术（含无埋点）：探索高效的自动化埋点机制，提升数据采集的全面性与准确性，为业务洞察提供坚实的数据基础。

• 宽表模型框架抽象层：探索更为高效、灵活的模型统一抽象方法层。

• AI大模型时代下的高效开发模式：探索如何通过利用大模型技术 来优化代码质量、数据链路等，打造更加高效、可靠的数据开发与运维体系。

我们期待之后再次与大家见面探讨这些议题，共同推动数据领域的创新与发展。