面向业务场景的大模型评估中会面临着什么样的问题，如何解决这些问题，在实际评估中又需要注意哪些问题呢？

本文重点介绍TDS在数据开发治理实践上的核心理念与技术落地，包括“流程标准化、质量可控化、运维智能化”三大方向。

本文介绍了百度网盘如何通过Flink构建实时计算引擎，以解决Spark Streaming存在的问题，提供高性能、低延迟、稳定的实时计算能力，并介绍了实时计算引擎的演进历程、选择Flink的原因及展望

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

当人工智能进入深度应用的黄金时代，单一模态的局限正被多模态交互彻底打破。文心 ERNIE-4.5-VL 视觉语言模型（ ERNIE-4.5-VL-28B-A3B；ERNIE-4.5-VL-424B-A

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

近日，国际数据公司（IDC）发布了《视觉大模型能力及应用评估报告，2025》，该报告对中国市场的视觉大模型厂商进行了全面且深入的评估，百度凭借卓越的综合实力，在众多竞争对手中脱颖而出，荣膺总分第一名的

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

扩散模型推理成本亟待优化 扩散模型（Diffusion Models）近年来在高保真图像和视频生成上取得了令人瞩目的成果。然而，这类模型在推理阶段需要经过数十步乃至上百步的迭代去噪，每一步都

导读

随着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大模型时代下的高效开发模式：探索如何通过利用大模型技术 来优化代码质量、数据链路等，打造更加高效、可靠的数据开发与运维体系。

我们期待之后再次与大家见面探讨这些议题，共同推动数据领域的创新与发展。