导读

面对百度APP日均数千亿PV、超百PB数据规模带来的巨大挑战，我们完成了数据仓库的系统性升级。本文详细阐述了通过"两步走"策略解决资源压力、处理延迟和架构瓶颈的全过程：第一阶段聚焦日志清洗环节的稳定性与成本优化，第二阶段实现实时离线链路解耦、核心数据隔离及计算框架容错能力提升。此次升级显著提升了数据处理时效性、系统稳定性和成本效益，为业务发展提供了更坚实的数据支撑。

背景

百度APP及其产品矩阵作为百度体量最大的C端业务线，在数据处理全链路面临规模与架构的双重挑战。日志清洗环节因日均几千亿PV、超百PB的庞大数据规模，导致计算资源持续承压、处理延迟频发，加之历史遗留的复杂日志格式，清洗稳定性与时效性逐步下降，存储成本高昂。与此同时上游日志数据仍存在实时与离线链路耦合、核心与边缘数据未有效隔离、计算框架容错能力不足等结构性问题，影响关键数据产出的稳定与时效。整体系统切换与优化面临高额的历史负担和技术重构成本，下游业务的数据可用性、决策及时性及深度运营分析均受到显著制约。

基于以上问题，我们制定了“两步走”的升级策略：第一阶段优先解决日志清洗环节的稳定性和存储成本问题；第二阶段在此基础上，重点推进数仓上层架构优化，包括实时与离线链路解耦、核心数据隔离处理以及计算框架容错能力提升，逐步实现整体数据仓库的高效、稳定与可持续升级。

01 第一阶段：多日志源整合

1. 2023年之前架构

在百度APP及其产品矩阵的数据体系建设过程中，日志清洗作为整个数据流水线的起始环节，其处理稳定性和产出时效性始终处于关键地位，是保障下游业务数据可用性与决策及时性的重中之重。然而，随着业务规模持续扩大和用户体量快速增长，每日产生的日志量急剧上升，由此带来的巨大计算压力使得整个清洗链路频繁面临资源瓶颈与处理延迟，稳定性和时效性均逐步下滑，难以满足下游各业务方对数据交付时间和质量的要求。与此同时，数据入口的分散催生了大量烟囱式的开发与冗余的计算逻辑，不仅推高了运维成本，更在源头形成了数据孤岛。下游基于此类数据构建的数仓架构必然复杂化，多表的 JOIN 与理解成本高昂，使得整个数据建设环节背负着日趋沉重的成本与协作压力。

2. 问题分析

2.1 旧架构分析

2.1.1 数据孤岛化加剧，认知与使用成本高昂

现有架构对每类日志采用独立落表方式，导致数据存储呈现碎片化状态。这种设计造成同一业务实体的相关信息分散在不同表中，形成严重的数据割裂。下游用户在使用数据时，不得不通过多表关联才能获取完整信息，不仅大幅增加了技术实现难度，更带来了沉重的认知负担。用户需要理解多张表的结构和关联关系，极易产生理解偏差，进而影响数据分析的准确性和可靠性。

2.1.2 关联查询性能瓶颈，制约数据价值释放

与此同时，多表关联查询模式给系统带来了巨大的性能压力。随着数据量的持续增长，表连接操作的成本呈指数级上升，查询响应时间显著延长。特别是在需要跨多个表进行关联分析的场景下，系统往往需要耗费大量计算资源和时间，无法满足业务对高效数据分析和快速决策的需求，严重制约了数据价值的及时释放。

此外，原始日志结构中普遍存在的复杂嵌套格式（如多层JSON、数组结构等）大幅增加了数据清洗和解析的复杂度。大量业务自定义字段缺乏统一规范，导致解析逻辑冗余且低效，进一步降低了整体处理性能。这些因素共同加剧了数据处理的延迟与资源消耗，形成系统性瓶颈。

2.1.3 维护复杂度与脆弱性并存，系统稳定性堪忧

独立的数据处理流水线，导致系统维护点分散。任何逻辑变更或schema调整都需要在多处同步实施，极大地增加了维护工作量。这种架构的脆弱性也显著提高了出错风险，单个任务修改的错误可能引发连锁反应，影响整个数据链路的稳定性。

特别需要指出的是，当前采用的UDW数仓及配套ETL框架仍是2012年上线的技术方案，已明显落后于业界主流水平。该框架存在诸多局限性：首先，其兼容性差，难以与现有开源生态工具链高效集成；其次，基于C++的MR计算框架稳定性不足，日常运行中容易出现各种异常；最后，开发调试效率低下，严重制约了数据需求的迭代速度。这些技术债务不仅增加了系统的维护复杂度，更成为制约数据平台发展的关键瓶颈。

2.2 重构思路分析

理想状态：从数据架构的理想设计来看，基于通用宽表数据建模方法论，采用“一步到位”的方式直接产出高度整合、面向主题的Turing宽表，是最为高效和优雅的解决方案。它能够减少中间冗余加工环节，提升数据一致性和复用度。

升级成本：下游业务方因历史原因，数据应用架构高度依赖传统UDW模式的数据组织与服务方式，迁移至Turing宽表体系涉及大量脚本改造、逻辑核对与业务适配工作，技术切换和数据迁移成本极高，导致架构升级短期难以实施。

思考：为实现数据架构的平滑升级，本次重构方案采用渐进式过渡策略，在着力解决现有架构核心痛点的同时，必须充分考虑百度业务数据链路长、历史包袱重的现实情况，审慎平衡技术先进性与落地可行性。方案设计严格遵循"平滑过渡、风险可控、成本最优"三大原则。

需要特别指出的是，由于现有数据体系深度嵌入各业务线的策略计算与离线分析环节，其紧密的耦合关系导致配套升级难度极大、周期长。这不仅涉及底层数据表的更替、依赖路径修改，更要求对依赖原有数据模型的下游业务进行协同改造和全面适配，沟通和推进难度极大。所以在保障业务连续性的前提下，如何有序推进全链路的升级切换是本次升级的重中之重。

建模思路：

（1）降低迁移成本

在数据中间层设计上，方案延续使用刻钟级UDW表作为缓冲层，通过将多个离散的UDW表整合为统一的宽表模型，进一步降低下游的使用和理解成本。同时，对表schema实施精细化改造，包括消除冗余字段、统一数据标准、优化存储格式，并重构字段逻辑以提升数据一致性。这种设计既保持了与现有下游系统的兼容性，又显著降低了数据使用复杂度。

（2）双轨输出机制

为确保迁移过程的平稳性，方案采用双轨输出机制：一方面继续提供优化后的UDW宽表，保障现有作业的无缝运行；另一方面通过聚合加工生成小时级Turing表，作为统一对外输出的日志宽表。这种渐进式迁移路径使下游用户可根据自身情况灵活选择切换时机，最大限度降低升级成本。

（3）兼顾历史和未来

此次架构优化为后续全面升级奠定了坚实基础。通过UDW层的预处理和Turing表的逐步推广，最终将实现架构的完全过渡，在提升系统性能的同时确保业务连续性，达成技术演进与业务稳定之间的最佳平衡。

3. 解决方案

过渡方案设计与实施：稳时效、降成本、提效率的综合治理

面对日志清洗环节日益严峻的稳定性、时效性及成本压力，我们制定并实施了一套详尽的过渡性解决方案。该方案并未激进地推行一步到位的Turing宽表迁移，而是立足于现有技术生态，以快速解决下游业务最迫切的痛点为目标，重点攻坚“产出时效不稳定”、“存储计算成本高”及“明细数据查询效率低下”三大核心问题。

3.1 优化处理粒度与逻辑沉淀，保障时效与复用性

为彻底扭转小时级任务积压与延迟的局面，我们首先对调度周期进行了粒度细化，将日志清洗任务从小时级调度全面提升至刻钟级（15分钟）。这一调整显著降低了单次任务的处理数据量和计算压力，使数据产出的延迟大幅减少，稳定性和时效性得到了根本保障。在技术选型上，我们并未盲目更换计算框架，而是继续沿用成熟稳定的C++/MR框架，确保了迁移过程的平稳性与可靠性。

同时，我们致力于提升数据的易用性与标准化程度。针对下游业务方需要反复从复杂JSON、Map等嵌套字段中解析提取关键信息的痛点，我们进行了大规模的业务通用逻辑下沉工作。将超过100个高频访问的埋点属性进行预解析、扁平化处理，转化为单独的标准化字段。这不仅极大减轻了下游的数据预处理负担，更直接提升了基于这些字段的查询过滤与聚合分析效率，为下游开发节省了大量时间。

3.2 兼顾历史依赖与未来演进，提供平滑迁移路径

我们充分认识到下游业务对原有UDW数仓体系的强依赖性。为保障业务的连续性，我们并未强制要求所有方立即迁移，而是采取了双轨并行的支撑策略。在产出新一代数据模型的同时，我们继续提供UDW中间表，确保那些尚未准备好迁移至Turing宽表的业务方能够无缝对接，无需修改现有代码，极大降低了方案的落地门槛和风险。

3.3 深度优化存储与查询，实现性能跨越式提升

为进一步降低存储成本并提升Turing宽表的查询性能，我们对其存储结构进行了深度优化。

• 合并小文件与高效压缩：海量小文件是制约查询性能的首要元凶。我们通过按设备ID、点位ID、时间戳等关键字段进行精细排序，将数据写入为连续有序的大文件，从而将单天高达800万个小文件合并至60万左右，文件数量减少了近93%。在存储格式上，我们选用Parquet列式存储，并经过充分调研测试，采用了ZSTD压缩算法。ZSTD在压缩比、压缩/解压速度上取得了最佳平衡，且完美支持多线程，最终实现了每天节省超过420TB的巨大存储开销，成本效益极其显著。

4. 新的问题&解决策略

问题1：宽表数据量膨胀导致的查询性能下降

解决策略：为应对宽表数据量激增对查询性能带来的挑战，我们实施了体系化的查询加速方案，显著提升海量数据下的检索效率

• 强制分区限制策略：在查询引擎层上线了强制要求限制分区条件的规则，避免了全表扫描带来的巨额元数据开销，大幅提升元数据检索效率。

• 查询结果缓存：对常见的热点查询结果进行缓存，对于重复性查询实现了秒级响应。

• 智能资源调度：根据查询的计算复杂度，系统自动将其调度到不同配置的资源池中执行，简单查询快速返回，复杂查询获得充足资源，实现了集群资源的高效利用。

问题2：分区数量增多导致点位所在的分区变得困难

解决策略：针对分区维度增加后，数据定位难度加大的问题，我们通过元数据管理与平台化集成提供解决方案：

• 新建分区元数据集，以天为粒度预先计算并存储所有点位与分区的映射关系，形成高效的点位分区定位查询，为点位所在分区快速检索提供基础支撑。

• 与现有点位管理平台深度集成，在其点位查询界面新增【查一查】功能。用户可通过界面化操作直接获取精准的数据分区信息及查询SQL模板，极大提升了用户使用的效率，降低了用户使用成本。

02 第二阶段：全面提速

1. 2023→2024年架构

随着业务发展，该数仓已完成由UDW（统一数据工作台）向Turing（新数据工作台）的改造，并初步建立起体系化的数据模型与分层数据集，显著提升了数据复用性和分析效率。基于这些宽表与数据集，大部分常规分析场景已能够快速响应。然而，在数据加工的最上游，即明细数据宽表的生产环节之前依旧包含缓冲的刻钟级udw表，因此仍存在若干架构性瓶颈。首先，实时数据处理链路与离线批处理链路相互耦合，资源竞争与依赖关系复杂，影响了整体任务的稳定性和时效性；其次，核心业务指标与非核心附属数据未被有效拆分处理，导致关键数据产出易受边缘数据波动或延迟的干扰；此外，当前的计算框架对于数据迟到、重复、异常值等复杂情况的处理灵活度不足，容错与自适应能力有待加强。

为彻底解决这些问题，进一步提升数据产出的时效性、准确性和稳定性，以更好地赋能百度APP及其产品矩阵及各下游业务的数据分析与决策，亟需结合各数据点位的实际使用情况和业务优先级，对最上游的日志ETL（抽取、转换、加载）处理流程进行系统性的优化与重构。

2. 问题分析

当前数据ETL处理流程面临以下几个核心挑战，这些问题不仅影响数据产出的效率与稳定性，也为下游业务数据的准确性和及时性带来风险。

2.1 开发框架灵活性不足，资源协调与弹性扩展能力受限

目前的ETL任务仍沿用原有UDW大表处理框架，通过单机Hadoop Client提交任务，并依赖QE（底层为mapreduce引擎）进行计算。该框架在资源调度和权限管理方面已逐渐暴露出瓶颈。同时udw是2012年提出的数仓建设方案，随着开源计算、存储技术的发展，udw性能逐步落后业界，部分功能不具备继续升级迭代可行性。一旦出现上游数据延迟、队列资源拥塞或系统异常，容易导致任务大规模积压。由于缺乏跨队列或跨资源的调度容灾能力，无法协调其他计算资源执行任务回溯与补偿，最终将直接影响整体数据产出时效，甚至波及下游多条业务线的核心数据应用。

2.2 核心与非核心数据处理耦合，异常影响范围扩散

在日志清洗ETL环节中，核心业务数据点位与非核心业务数据点位、以及实时与离线数据流目前尚未进行有效拆分处理。这种架构层面的耦合导致一旦上游数据源或计算过程中发生异常，其影响面会迅速扩大，不仅关键业务指标受到冲击，非核心业务数据的问题也可能反向干扰核心链路的稳定性。缺乏业务优先级识别和隔离机制，降低了计算链路的整体容错能力和故障隔离水平。

2.3 计算链路冗长复杂，维护困难且稳定性面临挑战

当前处理流程中包含UDW中间缓冲层，导致计算环节增多、链路层级深化。较长的依赖链不仅增加了数据产出的端到端延迟，也显著提高了运维监控和故障定位的复杂度。任何环节出现性能波动或失败都易引起连锁反应，威胁整体任务的稳定性和时效性，同时也带来较高的人力维护成本。

2.4 实时与离线数据源不一致，存在冗余计算与口径偏差

百度APP及其产品矩阵业务当前使用的实时计算链路和离线数据链路在核心指标上并未实现数据源统一，两条链路独立处理且并行存在。这导致相同指标需要在不同流程中重复计算，既造成资源浪费，也增加了数据口径对齐的难度。长期来看，此类架构问题会直接影响关键指标的一致性和可信度，对业务决策准确性构成潜在风险。

2.5 存储无序增长，数据冗余和存储成本与日俱增

随着业务规模的持续扩张和流量快速增长，支撑核心业务的明细数据宽表总量已达到百PB级别，存储与计算成本压力日益凸显。然而，不同业务域对数据的保留周期和使用频率存在显著差异，全部数据长期存储既不经济也无必要。

3. 解决方案

3.1 ETL框架升级

在完成由多张udw表到Turing表的优化工作完成后，数据处理的时效性与稳定性虽然取得了一定改善，但仍存在进一步提升的空间。具体而言，原有的C++ MR计算框架在任务运行过程中逐渐暴露出两类典型问题：一是容易发生计算长尾现象，个别任务实例处理缓慢，拖慢整个作业完成进度；二是基于单机调度的模式存在可靠性瓶颈，整体资源协调和任务容错能力有限。这些问题导致数据产出的延迟风险依然较高，难以完全满足业务对数据时效日益提升的要求。

为解决上述痛点，经过充分的技术调研与架构评估，我们决定将计算框架升级为TM+Spark的组合方案。其中，TM（Task Manager）作为厂内自研的高性能流式处理框架，在多个关键维度上显著优于原有的C++ MR架构。

TM（Task Manager）：更高的容错性和更强的稳定性

首先，在容错性方面，TM具备更为智能和敏捷的错误恢复机制。当某个计算实例发生故障或执行缓慢时，TM调度系统能够迅速感知并主动发起抢占操作，将当前Task动态迁移至新的实例继续处理，从而有效避免传统MR框架中由于个别长尾任务导致的整体作业延迟。这一机制极大提升了作业的稳健性和执行效率。

其次，在调度稳定性方面，TM基于Opera调度系统进行资源管理与任务分配，这一调度架构具有高度解耦和资源隔离的特点。每个任务实例独立运行，互不干扰，有效避免了在MR模式下由于同一队列中其他高负载或异常作业所带来的负面冲击，从而保障关键数据处理任务的稳定性和可预期性。

此外，TM框架也在输出存储效率方面做出了重要升级。它原生支持输出Parquet列式存储格式，并集成ZSTD压缩算法，在减少存储空间占用的同时大幅提升了后续查询操作的I/O效率。这一改进使得数据在写入阶段就具备更优的列组织结构和压缩特性，为下游分析提供了高性能的数据基础。

主流开源框架Flink和TM的对比如下：

Spark：通过构建DAG，计算更高效；利用RDD或者DataFrame减少IO耗时；多线程机制，执行速度更快。

Spark对比MR的核心优势：

• 速度：基于内存计算，无需反复做读写操作，更加高效

• 高度集成：spark丰富的API和高级抽象的函数可以轻松实现复杂的逻辑计算和处理，无需和MR一般需要编写复杂的处理逻辑

• 计算模型：内置的RDD数据结构可以提高数据计算的容错性；查询优化和执行优化可以适应复杂数据的处理和查询

结合Spark通用计算引擎强大的分布式内存计算能力和丰富的生态组件，新框架不仅解决了之前C++ MR模式中的长尾与调度瓶颈，还进一步实现了处理链路的统一与优化。Spark的高扩展性和TM的流式稳健性相结合，共同构建出一个容错能力强、资源利用高效、运维负担低的新一代数据处理架构，为业务提供更低延迟、更高可靠性的数据服务。

3.2 日志分类分级

3.2.1 埋点上线不规范，被动兼容推高处理成本

在当前百度APP及其产品矩阵业务高速发展的背景下，日均处理日志量已达3000亿PV的庞大规模，数据流的稳定、高效与成本可控变得至关重要。

原有的埋点分类和校验存在两个突出的问题：

• 上报不规范：存在大量不经过日志中台统一校验而直接上线的业务打点，这些“非规范”打点格式各异、质量参差不齐，极易引发解析异常。

• 处理成本高：下游的日志清洗ETL环节被迫陷入“被动兼容”的循环中，需要频繁地跟进制订适配规则以解析这些非标数据，不仅带来了极高的运维成本，更因计算资源的无效消耗而加剧了整体处理链路的负担，严重制约了数据产出的时效性与稳定性。

3.2.2 通过协同治理实现日志中台全流量覆盖

为从根本上破解这一难题，我们基于对百度APP及其产品矩阵数据全链路的深入洞察，发起了一项跨体系的协同治理工程。联合了日志中台团队、各业务研发团队、QA质量保障团队及PMO项目管理团队，形成了强有力的专项工作组。

第一阶段的核心任务是对所有日志模块进行全域梳理。我们共同制定了统一的《新增业务模块接入日志中台规范》与《日志埋点规范》，明确了从数据采集、上报到校验的完整标准流程，并强力推动百度APP及其产品矩阵（包括主客户端及相关创新业务）的全量需求空间、代码仓库及日志模块，完成向日志中台的标准化接入迁移。这一举措将日志中台的流量覆盖能力从治理前的约80%一举提升至100%****，实现了全流量管控。

更重要的是，我们在日志中台增强了多项主动校验能力：包括日志长度校验、关键公共参数完整性校验、以及精确到需求ID的粒度校验。这使得任何不合规的打点企图在测试和上线阶段就能被即时发现和拦截，实现了“问题早发现、早解决”的闭环管理，从而构筑起覆盖全场景的打点需求上线质量保障体系，从源头上杜绝了异常日志的产生。

3.2.3 打破“只上不下”僵局，建立埋点生命周期管理

在成功建立起“入口”管控机制后，我们将治理重心转向对历史存量埋点的“出口”梳理与优化。长期以来，由于缺乏有效的评估手段，点位数据存在着“只增不减”的痼疾，大量废弃或无效点位持续消耗着巨额的计算和存储资源。为此，我们创新性地从鉴权信息入手，通过对十几类不同下游使用场景（包括内部报表、算法模型、RDC数据转发服务等）的全面调研与信息收集，并对相关日志解析链路进行深度分析，首次精准地绘制出以百度APP及其产品矩阵全量15000多个点位为起点的、覆盖所有下游应用场景的“点位全链路使用地图”。

基于这张价值地图，我们清晰地识别出超过10000个点位已无任何下游业务使用或价值极低。通过严格的评估与协作流程，我们果断对这些埋点进行了下线处理，下线比例高达存量点位的71%。此次大规模治理行动，不仅直接释放了海量的计算和存储资源，有效缓解了系统瓶颈，更打破了长达多年的“埋点只上不敢下”的历史僵局，建立了点位的全生命周期管理模式，为后续数据的精细化管理与成本优化奠定了坚实基础。

3.3 AB实验数据扇出处理

3.3.1 现状与问题

在数据驱动的业务迭代中，A/B实验平台的指标建设和效果评估能力至关重要。然而，随着业务快速扩张和实验复杂度的提升，原有的实验数仓架构逐渐显露出严重瓶颈。平台最初是在通用数仓分层模型的基础上，采用“每个指标单独计算”的模式进行建设。这种设计在初期虽然灵活，但随着实验数量和指标数量的急剧增长，计算链路变得异常复杂、冗余且难以维护。由于缺少与公司数据中台团队的深度协同和标准化约束，每次新增实验指标都需要大量重复开发，导致实验数据需求的交付周期不断延长，严重拖慢了业务迭代速度，引发了业务团队的负反馈。

3.3.2 解决方案

（1）分析过程

理想的解决方案是直接复用百度APP及其产品矩阵已有的标准化大宽表进行实验指标配置。即基于一张集成所有关键维度与指标的大宽表，快速定义和产出实验分析所需的数据集。然而，现实情况却更为复杂：百度APP及其产品矩阵客户端同时线上进行的实验数量极多，平均每个cuid（用户唯一标识）对应的实验ID（sid）字符长度已超过2400字符。这个长度几乎相当于单条日志原始存储容量的40%，如果直接将实验ID维度接入宽表，将导致每条日志存储膨胀近一倍。这不仅会带来极高的存储成本，也会大幅增加下游所有数据应用的数据扫描量和传输开销，严重拖慢查询性能，进而影响整个数据链路的效率。

（2）设计思路

面对这一独特挑战，我们并未选择传统的宽表集成方案，而是从数据生成的源头实施了更根本的架构优化。我们重点对实验ID映射关系进行了拆分和重构：将sid与核心行为数据解耦，设计并建设了独立的sid维表。该维表直接从日志源头统一生成，整合了来自客户端的实验曝光及分组信息，并实现了对业务方、评估方各自独立建设的多套映射关系的全面统一。这一举措不仅从本质上避免了主宽表的存储膨胀，还彻底解决了因数据来源不一致而导致的实验效果评估diff问题，显著提高了实验数据的准确性和可信度。

（3）成果与收益

在此基础上，A/B实验平台的分析查询不再依赖于对超大宽表的直接扫描，而是通过sid维表与核心行为宽表进行动态拼接的方式实现指标计算。

在指标口径对齐方面，已完成实验类指标与OKR指标的口径统一工作，累计对齐上线指标2000余个，覆盖多个主题和维度。实验指标改由数据中心宽表统一生产，显著减少了以往在指标口径沟通与对齐方面的成本；在实验效率提升显著，指标开发环节通过复用宽表及数仓下沉逻辑，并升级计算框架，使常规需求开发周期从原先2周以上缩短至1周内，开发效率提升超50%。同时核心指标计算SLA由T+14小时提升至T+10小时，处理时效明显提高；在计算资源成本方面，通过整体数据流复用和抽样日志整合优化，实现了计算资源成本的有效降低。另外，联动产品及策略团队治理并下线无效实验指标超1800+，释放的资源进一步支撑了新场景的指标建设需求。

4. 分级存储治理

随着业务规模的持续扩张与产品矩阵的不断丰富，百度APP及其产品矩阵业务的日志数据量呈现指数级增长，单张核心Turing数据表的存储量已达到百PB级别，面临巨大的存储与成本压力。传统的统一存储周期策略难以适应当前复杂的使用场景：一方面，大量短期数据被无效保留，占用巨额存储资源；另一方面，部分核心业务场景仍需依赖长周期历史数据进行跨年指标对比、关键数据需求回溯与深度建模分析。

为解决这一矛盾，我们针对Turing表启动了多维度的精细化存储治理工作。通过深入分析业务使用特征与数据访问频率，我们建立了差异化的数据生命周期管理机制，实施**“热->温->冷”**三级数据分层存储策略。对高频访问的近期数据全部保留，对访问频率较低的长期历史数据自动进行转储、压缩或者裁剪等，并配套建立完备的数据取回与回溯流程。

该项治理在充分保障核心业务长周期数据使用需求的前提下，显著压缩了整体存储规模，实现了存储成本的大幅优化，为未来数据的可持续增长与高效管理奠定了坚实基础。

具体实施策略：

03 总结与展望

随着业务规模的持续扩张和产品矩阵的不断丰富，数据量呈现指数级增长，这一趋势持续驱动着数据处理架构与模型的演进与迭代，同时也对数据分析的敏捷性、易用性和可靠性提出了更高要求。在数仓系统全面升级的过程中，我们着力优化数据处理全链路，通过改进调度机制、减少计算环节、强化故障自动恢复能力，显著缩短了整个数据处理流程的时长，有效识别并排除多项潜在稳定性风险。此外，依托于对全端埋点体系的系统化梳理与标准化规范，构建了高质量、可复用的数据资产底座。

本次整体架构的升级为业务提供了坚实的数据支撑，在数据时效性、准确性和使用便捷性方面均实现显著提升。作为百度体系内最核心且数据规模最大的业务板块，百度APP仍面临数据持续激增带来的诸多挑战，包括埋点规范统一难度高、技术栈兼容与选型约束多、日志解析复杂度高、存储结构灵活多变以及成本控制压力增大等问题。

面向未来，我们将持续推进数仓架构的深度优化，重点围绕埋点治理、架构升级、效能提升、存储模型优化和资源精细化管理等方面展开工作。目标是构建一套具备更高时效性、更优数据模型、更低存储与计算成本的全新一代数仓链路，为业务创新与决策提供高效、可靠、低成本的数据服务能力。

导读

随着人工智能技术的迅猛发展，AIGC（AI-Generated Content，人工智能生成内容）正逐步重塑内容创作行业的格局。尤其在视频内容领域，传统制作流程周期长、成本高、依赖人工创作，已难以满足日益增长的内容消费需求。AIGC技术的引入，为视频创作带来了前所未有的效率与可能性。AIGC工具在短视频应用率从22 年不足5%跃升到25年35%。电商场景下，越来越多的平台帮助商家进行AIGC商品视频的创作，帮助其提高商品转化率。基于上述两点，电商搜索在今年开始探索AIGC视频自动化生产方案，尝试基于视频自动化混剪，来满足搜索场景下日益增长的内容需求。

01 早期项目演进与问题

项目早期我们整体视频创作中基于大模型完成分镜脚本生成 + 分镜图片素材检索，其他视频元素（脚本脉络/视频标题/布局/音效/特效等）全部通过规则进行选择和生成。但整体后验效果不佳，通过后验分析我们发现了两个很大的问题：

• 规则式方案导致视频整体模板化、同质性严重。

• 整体视频素材大部分由口播加静态图片素材组成，比较死板，吸引力弱。

为解决上述2类问题，我们进行了新一版迭代。主要升级点：

• 规则式视频生成方案升级成 MultiAgent协同视频生成系统，最大化视频先后验指标为目标，动态调度视频元素。

• 素材供给和类型更丰富（视频素材、泛图表），增加视频素材多维度优选能力，大幅提升高清视频素材的时长占比，显著增强视频吸引力。

02 MultiAgent视频生成系统

通过搭建MultiAgent协同视频生成系统，基于视频内容高效满足和视频画面丰富多样为优化目标，模拟人类视频制作流程，完成分镜脚本生成>多类型素材生成->大模型剪辑成片多轮推理。

2.1 分镜脚本生成Agent

分镜脚本生成在项目初期面临两大问题：

问题1：如何提升脚本准确率?

电商场景下品牌/品类/商品信息需要大量准确数据支撑 => 直接根据互联网语料生成准确率不到80%。

解法：脚本生成信息来源以电商高精知识图谱为主，第三方优质视频文案（B站视频等）为辅，保证核心主体信息准确的同时丰富故事细节，脚本可用率大大提升。如下是一个Case：

西门子是什么品牌

---

提到西门子，很多人第一反应是家里那台带液晶屏的冰箱，或是洗衣机上那个会发光的LOGO。

但你可能不知道，这个看似普通的家电品牌，背后藏着足以改变人类工业史的惊人故事。

1847年，当维尔纳·冯·西门子在柏林一间小作坊里敲打出第一台电报机时，没人能想到这家公司会成为工业界的隐形冠军。

最让人震撼的是西门子的重生能力。

二战期间80%工厂被炸毁，这个德国品牌却用短短五年就杀回巅峰。

就像他们1910年卖给中国石龙坝水电站的发电机——这台百岁高龄的工业活化石，至今还在云南吭哧吭哧运转。

这种近乎变态的耐久度，解释了为什么全球70%的高端燃气轮机市场都被西门子垄断。

但西门子真正的可怕之处在于无处不在。

你手机摄像头里的光学系统，医院CT机的核心部件，甚至造芯片用的UV光刻机，背后都是西门子的技术。

更夸张的是，历史上32位诺贝尔奖得主都依赖西门子显微镜做研究。

这种渗透到科技毛细血管的能力，让它在工业4.0时代依然稳坐神坛。

2024年最新财报暴露了这家老牌巨头的野心：单季度新订单223亿欧元，折合人民币超1700亿元。

更惊人的是研发投入——63亿欧元相当于每天烧掉1.7亿人民币搞创新。

从1872年进入中国交付首台电报机，到如今智能工厂解决方案遍布长三角，西门子用152年时间证明：真正的工业王者，从来都是闷声改变世界。

下次当你打开西门子冰箱取饮料时，不妨多看一眼那个蓝色LOGO。

它不仅是德国制造的品质象征，更是一台持续运转178年的超级印钞机——平均每1.5小时就能创造1个诺贝尔奖级别的技术突破，这样的品牌基因，恐怕连特斯拉都要喊声老师。

---

问题2：如何提升脚本吸引力？

通用大模型生成脚本冗长拖沓且AI感强 => 无法快速满足用户需求以及脚本吸引力不足。

问题2解法：构建优秀脚本脉络及风格集合，针对不同Query动态选择脚本脉络、风格，提高脚本吸引力。

风格2：历史叙事类风格

---

开头：

1.通过悬念钩子式开场，把观众带入好奇与期待的情绪，通过颠覆认知的事实陈述，带给观众强烈的入门吸引力。

主体文案

1．通过时间锚点与关键事件叙事，把观众带入到故事中，通过细节化描述，带给观众身临其境的代入感。

2. 通过数据具象化与生活类比，把观众带入真实可感的认知场景，通过技术术语降维解读，带给观众易懂的专业洞察。

3. 通过对比与隐喻强化冲突，把观众带入情感共鸣的高潮，通过辉煌与危机并行的结构，带给观众深度反思的平衡视角。

4．通过转折点戏剧化呈现，把观众带入叙事节奏的起伏中，通过第三方视角引用，带给观众客观可信的品牌背书。

5．通过金句收尾与主题升华，把观众带入余韵悠长的结尾氛围，通过历史寓言或隐喻，带给观众启发性的价值总结。

6. 通过语言节奏控制，把观众带入流畅紧凑的阅读体验，通过文化元素融合，带给观众多元化的审美共鸣。

结尾：添加和用户的互动

---

效果示例如下：

谁能想到，如今遍布全球的西门子帝国，最初竟诞生在德国柏林一家熟肉店的后院！（开头直接回答用户问题）

1847年，当维尔纳·冯·西门子脱下普鲁士军装，租下那间飘着烤猪肘香味的作坊时，连隔壁面包师傅都嘲笑这个整天摆弄电线的年轻人。

可就是这个被当作怪人的前炮兵军官，用一根电报线撬动了整个工业革命。

故事要从德国北部的小村庄伦特说起。1816年出生的维尔纳从小就有种特殊天赋——他能把拆散的怀表重新组装成会转动的钟，还能用勺子电解出银层给朋友做生日礼物。（通过细节化描述，带给观众身临其境的代入感）

这种对电的痴迷，最终让他在1847年创立了西门子-哈尔斯克公司。

注意，这家公司的第一个爆款产品不是冰箱也不是发电机，而是指针式电报机！

当时的欧洲正处在通信革命前夜。柏林至法兰克福的电报线路项目，让西门子赚到第一桶金。

但真正让公司腾飞的，是维尔纳三兄弟的全球布局战略：大哥坐镇柏林搞研发，二弟威廉攻克英国市场，三弟卡尔甚至把电线铺到了沙皇的冬宫。

到1879年柏林工业博览会上，西门子已经能骄傲地展示世界首辆电力列车——比爱迪生发明电灯还早两年！

如今178年过去，这个德国品牌早已超越国界。2024财年第一季度，西门子新订单额飙升至223亿欧元，在190个国家拥有32万员工。

从你家冰箱里的PT净味技术，到医院的核磁共振设备，甚至太空站的供电系统，那个曾在肉店后院闻着香味饿肚子的发明家，真的让全人类都通上了他的电。

不过最讽刺的是，当年维尔纳为省钱发明的电镀术，如今却成了西门子高端家电的标配工艺。

下次当你打开那台标着SIEMENS的冰箱时，别忘了里面藏着个德国工业史上最美味的创业故事——毕竟没有哪家世界500强，是从闻着烤猪肘香味开始的。

2.2 多类型素材生成

目前AIGC视频中，电商视频素材相比于通用场景素材，存在两点挑战：

• 视频素材少

     原始视频少：业界通用视频素材对于电商信息，特别是长尾商品信息覆盖较少。

     可用视频少：在电商类视频中，对品牌商品等实体一致性要求极高，进一步加剧视频供给问题。

• 传统视频检索准确率低：电商场景下对于品牌/商品实体一致性要求极高，传统通用视频检索系统在电商场域下实体理解效果差，检索准确率低，导致视频不可用。

针对上述两个挑战，我们提出了两步解决方案：

• 泛图表生成，进一步增加差异化供给： 基于大模型代码生成能力，自动化构建30+个泛图表模板，并通过MCP形式对外开放；通过大模型规划能力，根据脚本选择最优图表模板并生成泛图表内容，端到端图表生成可用率达92%。

图表效果如下：

整体流程如下：

• 素材多维度优选：基于多模态视频理解大模型，从电商实体一致性，视频清晰度等多维度构建端到端优选能力，提升视频素材质量，视频粒度准确率大大提升。

  实体一致：基于Qwen2.5-VL-32B模型，对视频中实体细节进行多维度理解推理，尤其注重商品实体一致性。

清晰度高：通过自研模型对视频清晰度划分清晰/普通/模糊三档，对模糊类视频进行过滤。

2.3 大模型剪辑成片

通过大模型多轮规划推理，进行素材/布局/动效/音效等多视频元素全局优选，完成最终视频剪辑并成片。整体流程如下：

03 后续方向演进

• 端到端剧本生成：

     现有问题：现有的2.0框架本质上与传统检索系统类似，存在多个子Agent模块前后依赖，这导致了不同链路目标不一致等问题，制约了视频效果的增长。

     解决方案：构建剧本生成Agent，基于大模型进行端到端的完整剧本生成。通过端到端的剧本撰写，视频的画面，脚本，BGM可以实现优化目标的统一化。

• AIGC生成式视频：

     现有问题：目前视频是基于现有的视频素材打碎重组（混剪）而成的，在很多时候都面临供给不足的问题，而AIGC生成（文生图/视频）的方式能较好的解决这样的问题。

     目前困难：AIGC生成目前的可用率仍不足，会出现文字乱码，人物/实体错误，物理规律不遵循等问题，在电商商品场景下尤为明显，这些仍需要进一步去探索和尝试。

导读

本文主要介绍基于流批一体建设的Feed实时数仓在业务高速发展和降本增效的大环境下，所面临的问题和挑战，以及对应的解决方案。文章分为四个部分，首先介绍下旧的Feed实时数仓的整体架构设计；然后介绍随着业务的不断发展，旧的架构所面临的问题；第三部分是文章的重点，着重介绍重构升级后的Feed实时数仓架构设计，以及在重构升级过程中所遇到的关键性问题和解决方案；第四部分是总结和规划，Feed实时数仓重构升级后，带来了什么样的收益和业务效果，以及对实时数仓未来发展的一个思路探讨。

01 简介

Feed实时数仓是一个基于 feed 日志产出 15 分钟的流批日志表，主要用于对日志原始字段的解析，并下沉简单业务逻辑。该表保留最细粒度的用户明细数据，是Feed数据的最底层数仓宽表。其整体架构设计如下图所示

数据源：Feed实时数仓的数据源主要是各种日志打点数据，主要包括手百端打点和服务端打点。通过使用MEG日志中台提供的一站式打点方案，对用户的行为明细打点数据进行收集管理。

数据采集：数据采集过程，首先通过minos（百度自研的新一代的流式日志传输系统）的agent服务将打点服务的日志进行采集传输到实时流中，然后由日志中台的清源系统进行统一的清洗，对所有的日志打点数据进行格式化，统一schema。清源系统会将统一处理后的数据，传输到厂内消息队列bigpipe中（百度自研的分布式中间件系统）。

数据清洗：数据清洗分为两阶段。

第一阶段为基于TM流式框架搭建的Feed流式计算作业，该作业订阅消息队列bigpipe中的数据，对日志的原始字段进行解析，并下沉一些简单的Feed业务逻辑。流式计算处理结束之后，根据打点数据的生成时间进行落盘，生成刻钟级目录的数据。

第二阶段为基于StreamCompute框架搭建的批处理作业，该作业的任务是对第一阶段产出的刻钟级目录数据进行字段结构统一，并生成hive、spark等查询引擎能够直接查询的orc格式文件，最后将数据导入到实时数仓中。

数据仓库：

Feed实时数仓作为底层明细数据，虽然是DWD表，但保留着ods层数据的特点，存储着Feed日志打点的基础数据。

Feed业务基于实时数仓的数据，对复杂的业务逻辑进行下沉，产出小时级的离线DWD表，作为 feed 主要对外服务的数据表。并在DWD表的基础上，拼接其他主题数据，进行数据聚合，产出ads 层的主题宽表、中间表。

Feed评估业务基于Feed实时数仓，对cuid进行聚合，产出cuid粒度的评估中间数仓宽表。

数据应用：Feed实时数仓下游的数据应用，主要包括策略信号、实时应用、实时报表等高时效性的应用，主要用来检测数据趋势，观察实验策略、热点活动等带来的数据变化，主要是对Feed的分发、时长、au等指标的影响。

02 实时数仓面临的核心问题

随着业务的不断发展，越来越多的下游业务开始接入Feed实时数仓，比如商业、电商、直播等业务。Feed实时数仓急需解决以下几个问题

1. 计算过程繁琐，成本高时效慢

Feed实时数仓的整体架构为流处理+批处理的架构。其中流处理主要进行日志的ETL处理，订阅消息队列bigpipe中的实时流数据，进行清洗加工，产出统一的proto格式数据；批处理过程是对ETL后的proto格式数据进行格式转换，生成可供hive查询引擎直接查询的orc格式数据。

时效慢：流+批的数据处理架构，使得实时数仓数据的产出时间达到了45分钟，端到端数据应用的产出时间更是达到了50分钟以上。

随着手百业务的不断发展，实验评估、直播、电商等业务对数据的时效性提出了更高的要求。比如Feed实验对照组需要更快的实时监控来观测不同的实验策略对Feed的分发时长带来的收益，电商直播需要更快的实时监控来观察不同的分发策略对于直播间观看情况的影响。50分钟的实时监控已经无法满足这类高时效性的业务场景，尤其是重要时事热点、重大直播活动等热点项目。

成本高：实时计算处理过程使用了TM+SC两套流式架构，其中TM部分承担流式数据的清洗和简单的指标计算，SC部分主要是负责批处理的字段结构统一工作。流+批的处理架构成本偏高，其中TM部分需要240w/年，而SC部分需要360w/年，其负责的字段结构统一工作和消耗的成本明显不成正比。SC架构本是百度自研的一站式流式计算服务，在此项目中用来进行批处理的工作，造成了严重的资源浪费。

2. 下游业务多，指标对不齐

随着电商、直播等业务的发展，越来越多的业务开始接入Feed数据，原本只是为单一Feed业务提供的实时数仓宽表，其下游不断增加，包括且不限于评估实验、分润、商业、电商、直播、百家号等业务。由于Feed实时数仓只是数据清洗之后的用户明细数据，并不包括指标和维度相关的信息，比如点击、展现、播放时长、互动等指标，入口来源、视频类型、干预类型等维度信息。各下游在使用这些指标、维度时都需要根据宽表中的基础数据进行计算。由于下游使用方比较多，且分属不同的部门，计算口径往往无法统一。

以Feed实验评估业务为例，随着Feed业务的发展，核心指标口径也不断变化，导致实验指标和Feed大盘指标无法完全对齐，已经严重影响Feed业务迭代。对于口径对不齐问题，评估中心，数据中心做过专项治理，对齐Feed大盘+视频口径，解决了部分问题；但随着业务持续迭代，数据对不齐问题再次加剧，所以急需从根本上解决指标对不齐的问题。

3. 系统架构冗杂，稳定性差

Feed实时数仓整体架构从日志采集端到应用端，每个阶段的作业都未区分核心和非核心数据。尤其是数据采集部分和数据清洗部分，都是漏斗形架构。这样的架构就会出现，若非核心数据流量暴涨，会引起整体链路上的水位延迟，甚至会阻塞核心数据的处理，最终影响核心数据的使用。

03 实时数仓重构方案

3.1 整体架构

新的实时数仓架构，从数据采集到数仓阶段全部进行了重构升级。

数据采集：

对日志打点从业务、点位重要度 两个维度进行拆分。下图以Feed、手百业务为例，日志中台的清源系统拆分出Feed核心作业、Feed非核心作业，分别处理Feed的核心和非核心数据，核心和非核心日志打点输出到不同的消息队列中，从源头实现核心和非核心数据的解耦。

**数据清洗：**对应核心和非核心消息队列，建立两个独立的数据清洗作业（核心作业和非核心作业）。

1). 字段抽取逻辑保持不变，依旧只是对数据进行简单的清洗。

2). 增加指标计算环节，该指标计算环节对应原架构中Feed离线数仓的小时级明细宽表的逻辑，将离线的复杂业务逻辑下沉到流式计算环节。最终产出的的实时数仓中包含了计算好的指标结果，由于Feed实时数仓为Feed数据的唯一出口，下游在使用时候可以忽略Feed业务逻辑的计算，直接使用Feed实时数仓产出的指标字段，从而解决下游指标对不齐的问题。

3). 删除流转批的处理环节，将字段格式统一的工作集成到流式计算环节中。基于TM流式框架实现了包括字段抽取+指标计算+字段格式统一的全部流式计算处理，减少了流转批的过程，节省大量计算资源，同时还提高数据产出时效性。

数据仓库：新版的Feed实时数据的字段结构与原架构中的Feed离线DWD数仓宽表保持一致，对Feed离线DWD数仓宽表中所有的复杂业务逻辑进行了下沉，新版Feed实时数仓=Feed离线DWD数仓宽表的实时化。下游应用直接通过简单的count/sum操作就能得到feed的各种指标结果，指标查询效率提升90%。

3.2 关键问题解决方案

3.2.1 离线复杂业务逻辑实时化解决方案

由于Feed实时数仓是Feed所有数据的唯一出口，将Feed离线DWD数仓宽表中的复杂业务逻辑下沉到实时数仓中，将从根本上解决下游各业务指标口径对不齐的问题。离线复杂业务逻辑下沉到流式，主要存在以下两个问题。

3.2.1.1 离线和实时数据计算维度不一致

实时数仓和离线数仓建模维度不一样，业务逻辑无法直接下沉。旧的实时数仓是面向数据源建模，所有的字段抽取逻辑是基于不同的日志源进行抽取，比如端打点日志、PC打点日志、服务端日志等；而Feed离线数仓是基于业务建模，分成了点击、展现、时长、互动等业务分区，业务逻辑、指标计算也是在这些业务维度基础上进行处理。

解决方案：

在流式计算环节中，业务逻辑处理分为三层进行。如下图所示，第一层依旧进行字段抽取的数据清洗处理；第二部分根据根据关键字段信息，对所有日志数据进行业务逻辑分区；第三部分，该部分处理逻辑对齐离线的复杂业务逻辑，不同的业务分区，执行不同的业务逻辑计算。最终生成业务维度的实时数仓底层数据。

3.2.1.2 下游用户无法直接进行切换

原Feed实时数仓和Feed离线DWD数仓宽表，数仓建模维度不一样。原Feed实时数仓是简单清洗的日志明细表，只是对日志的字段进行简单的裁剪；Feed离线DWD数仓是对Feed实时数仓宽表进一步加工之后的表（包括删除无用日志字段信息（比如实验sid信息等）、删除无用打点日志、 通过日志明细计算出维度/指标字段）。如果新的实时数仓宽表字段要和离线DWD数仓宽表建模保持一致，原实时数仓下游使用方无法直接迁移到新的Feed实时数仓。

解决方案：

1. 功能单一的大字段单独抽出，建立一个新的明细表。如sid字段，建立sid明细表，下游用户使用时通过cuid等字段进行关联。

2. 无用打点日志：对于Feed业务来说无用的打点日志，单独保留到非核心分区。

3. 新的实时数仓宽表，在离线数仓宽表字段基础上，增加字段用以表示旧实时数仓宽表中分区信息，兼容历史分区逻辑，以供下游切换时使用。

3.2.2 字段格式统一实时化解决方案

字段格式统一，主要是将清洗之后的数据，按照实时数仓的schema进行字段的格式进行统一，同时将最终数据文件(行存)转为ORC列式存储格式，以供hive、spark等查询引擎进行高效的查询。

在原来的数据架构中，字段格式统一只能由sc或者spark进行处理，所以只能使用流+批的方式进行实时数仓的生产，这造成了严重的资源浪费。将该部分处理工作集成到流式计算TM任务中，数据生产成本至少降低200万/年；同时缩短数据生产链路，提升数据产出时效。详细解决方案如下。

3.2.2.1 数据存储格式选定Parquet格式代替之前ORC格式作为最终数据的存储格式

Parquet是一种专为大数据处理系统优化的列式存储文件格式。目标是开发一种高效，高性能的列式存储格式，并且能够与各种数据处理系统兼容。Parquet 在2013年作为开源项目被创建，在2013年6月被 Apache 软件基金会采纳为顶级项目。它的开发受到 Apache Parquet 社区的积极推动。自推出以来，Parquet 在大数据社区中广受欢迎。如今，Parquet 已经被诸如 Apache Spark、Apache Hive、Apache Flink 和 Presto 等各种大数据处理框架广泛采用，甚至作为默认的文件格式，并在数据湖架构中被广泛使用。

Parquet具有以下优势

列式存储：

• Parquet 是一种列式存储格式，有多种文件压缩方式，并且有着很高的压缩比。

文件是可切分（Split）的：

• 在Spark中使用parquet作为表的文件存储格式，不仅节省AFS存储资源，查询任务的输入数据量减少，使用的MapTask也就减少了。

支持谓词下推和基于统计信息优化：

• Parquet 支持谓词下推和统计信息(例如最小值、最大值、空值等)，这使得在执行查询时可以更有效地过滤和优化数据访问。这对于加速查询是非常有帮助的。

支持多种数据类型和模式演进：

• Parquet 支持多种数据类型，包括复杂数据结构，这使得它适用于各种类型的数据。此外，Parquet 允许模式演进，即在不破坏现有数据的前提下修改表结构，提供了更大的灵活性。

3.2.2.2 在TM框架中引入Apache Arrow开源库实现输出parquet格式文件

Apache Arrow 定义了一个与语言无关的列式存储内存格式，可以理解为parquet文件加载到内存中的表现。

上图为Proto格式数据通过Arrow 转为Parquet格式数据的详细过程。

1. TMSinker算子（TM流式处理框架中输出算子）收到上游产出的proto数据后，首先将数据分成4份，每一份对应一个线程，

2. 每个线程将自己负责的数据转成一个RecordBatch; 具体操作是解析Protobuf数据，将数据进行格式映射，构建一个Arrow Schema，填充到RecordBatch中，然后将4个RecordBatch合成一张Table。

3. 使用Arrow提供的API，将Arrow Table写入到Parquet Writer，Parquet Writer负责把数据刷新到磁盘上。

部分组件概念如下：

RecordBatch，可以理解为一张子表，有schema信息和每一列数据，常作为并行计算的子数据单元。

Table可以理解为一张列式存储的表在内存中的表现形式，可以由多个RecordBatch合并而成。

3.2.2.3 实现过程中出现的其他问题及解决方案

小文件变多问题

原架构中，字段结构统一是批处理，会等15分钟的数据都产出之后，集中进行处理；而新的架构中，将字段结构统一的处理集成到流式计算中，导致小文件数过多。太多小文件会导致查询引擎增加对元数据读取开销等问题，影响查询稳定性，甚至会出现占满slot情况 影响其他任务。

小文件产出原因：正常TMsinker算子是通过攒task(数据大小+超时时间)减少小文件产生，但会存在跨时间窗口的数据，从而产出小文件问题。平均每15分钟会产生5234个文件，其中小文件951个，小文件占比18%(略早到的文件占比10%；略晚到的占比8%)，平均文件大小258MB -- 未压缩）。

解决方案：

1. TMsinker 算子每次请求tm server获取task数由1个变为多个（可配置），避免出现sinker获取1个task就处理的情况，同时降低tm server的压力。

2. 优化时间等待策略和攒数据策略

a. 默认配置

• 默认每次获取task数200个；(默认值200；用户可通过配置项覆盖)

• 最大等待时间20S；（默认20秒；时效和文件size的平衡；用户可通过配置项覆盖

• 最少积攒数据800MB； (默认800mb；用户可通过配置项覆盖)

b. 详细策略

• max_num: 一次性可获取并锁定的最多task数量

• last_num: 上一次获取并锁定的的task数量

• num: 当前获取并锁定的task数量

大文件转parquet失败问题

在使用arrow库把proto格式数据转为parquet格式数据过程中，当某一列 string 类型的数据超过 2G 时格式转换会失败。

首先我们从string在内存中的表现形式来进行分析

Length：表示这一列一共有多少条数据

Null Count：表示这一列一共有多少条数据是Null

Validity Bitmap：位图，1代表非Null，0代表null，用于快读判断某条数据是否是null

Value Buffer： 存储 string 数据 list;

**Offsets Buffer：**存储每条数据在ValueBuffer中的位置

如上图，string的offsets buffer是list，因此string类型最大只能支持2^31字节=2G的数，如果在这条数据之前所有的数据已经超过2G了，那么因为Offset是int32无法表示大于2G的整数，导致这条数据无法转换。

问题原因找到，解决方案就很简单了，将string替换成large_string类型即可，其offsets buffer是list。

压缩耗时高问题

通过查看arrow库的源码，我们发现Arrow库当前使用的ZSTD压缩方法的Simple API，而Zstd库提供了 Simpler/Advanced API。这两个API的区别是Simple API只能设置压缩级别，而Advanced API可以设置压缩级别和压缩线程等。

解决方案：修改源码中ZSTD压缩方法的API，改为Advanced API，并通过环境变量暴漏多线程相关的参数。

以配置6核CPU为例，单线程时最多整使用1个核，多线程时可以使用到5.5个核

字段结构统一实时化最终整体解决方案如下：

04 总结与规划

Feed实时数仓重构升级完成后，流批一体架构升级为纯流式架构，整体计算成本节省50%，实时数仓数据产出实效缩短30分钟，提速80%。离线复杂业务逻辑下沉，指标查询效率提升90%，DWD明细宽表产出时效提升3小时；Feed宽表统一指标出口，其他下游和Feed业务线完成口径对齐，从根本上解决了指标对不齐的问题；流式计算整体架构统一到流式TM框架，维护成本降低50%，端到端核心非核心数据完成拆分，服务&数据双隔离，互不影响，服务稳定性大幅提升。

针对Feed实时数仓的后续规划，我们计划从计算引擎上进行优化升级，对标业界主流实时计算引擎，改变现有的C++代码开发模式，提高流式计算服务的开发效率，降低开发成本，以应对快速发展手百和Feed业务，满足越来越多的数仓需求。同时未来我们将把Feed实时数仓建设成厂内实时数仓标杆，为更多的业务提供实时数据服务。

导读

BaikalDB作为服务百度商业产品的分布式存储系统，支撑了整个广告库海量物料的存储。在大语言模型LLM蓬勃发展的现在，想在大模型里使用BaikalDB里的数据进行分析，都需要复杂的定制开发。看BaikalDB如何借助模型上下文协议(MCP)，让数据库对话像聊天一样简单——无需编写代码，大语言模型即可完成复杂数据分析。

01 引言

在2025年以前，大语言模型（Large Language Model‌，LLM）想要使用数据库的数据，都需要开发人员设计接口、开发Agent插件、构建Prompt等费时费力的一系列定制开发；同时面对不同大模型的差异，还需要额外的重复性工作进行适配。

随着模型上下文协议（Model Context Protocol，MCP）的标准化普及，这一局面被彻底重构。MCP通过定义统一的上下文交互规范，为应用程序与AI模型建立了 “通用通信协议”。

基于此，BaikalDB团队创新推出‌BaikalDB MCP Server‌，将其打造为连接LLM与分布式存储系统的 “智能USB接口” ——该方案具备三大核心价值：

1. 零开发集成‌：支持主流LLM通过标准化协议直接访问BaikalDB，无需编写任何适配代码。

2. 全链路自动化‌：从自然语言意图理解、SQL智能生成到查询执行与数据分析，实现端到端闭环。

3. 多模型兼容性‌：屏蔽底层技术差异，一套接口适配GPT、Claude、文心一言等各类大模型。

02 MCP: AI USB接口

2024年11月由Anthropic公司提出的模型上下文协议MCP，是一种标准化的大模型与外部数据源、工具交互的开放协议。来源于USB接口范式的设计灵感，MCP的核心思想在于：通过创建一个通用的标准（如USB接口设计），解决大语言模型与外部系统间的“信息孤岛” 问题，该协议通过三大核心原则重构AI开发生态：

1. 即插即用标准化：定义统一的上下文交换格式，使大模型与数据源/工具的对接效率提升80%以上。

2. 组件解耦化：支持不同AI模块的热插拔组合，开发者可像搭积木般构建复杂AI系统。

3. 语义透明化：通过标准化上下文标记，实现跨组件意图传递的零损耗。

△MCP设计理念

2.1 MCP 组成

如上图所示，MCP 由三个核心组件构成：MCP Host、MCP Client 和 MCP Server：

官方文档链接：

modelcontextprotocol.io/clients

modelcontextprotocol.io/quickstart/…

modelcontextprotocol.io/quickstart/…

github.com/modelcontex…

MCP Server的三类能力：

• 工具类（Tools）——  模型的「智能外设」

     供模型调用的函数或服务，用于执行特定任务。如一个天气查询工具，获取指定城市的天气信息。

• 资源类（Resources）——模型的「知识库」

     供模型读取的数据源，如文件数据或 API 响应内容，为模型提供了丰富的上下文信息，增强了模型的理解能力。

• 提示词（Prompts）——模型的「操作指南」

     预先编写的模板，旨在帮助用户完成特定的任务，通常是为了优化工具或资源的使用，提供一种更高效、更准确的交互方式。

MCP Client和Server之间的三种通讯方式：

• STDIO 传输

     MCP Server运行在本地。

     通过标准输入（stdin）和标准输出（stdout）建立双向通信，1对1服务。

• SSE 传输

     MCP Server运行在本地或远程运行。

     通过服务器发送事件协议（SSE）进行通信，支持N对1服务。

     在 2024-11-05 版本废弃，被 Streamable HTTP 替代，后者将 SSE 作为可选的流式传输机制纳入其中。

• Streamable HTTP 传输

     MCP Server运行在本地或远程运行。

     通过可流式HTTP传输协议通信，支持N对1服务。

     支持流式传输，适合大数据量场景，提供更灵活的传输能力

2.2 MCP 流程

文心快码Comate是百度基于文心大模型开发的智能代码助手，旨在通过AI技术重构编程流程，提升开发效率与代码质量。目前Comate不仅支持‌‌智能代码生成‌、单元测试生成等功能，还支持接入外部MCP Server与大模型进行交互。

以在文心快码Comate里通过BaikalDB MCP Server对BaikalDB数据进行查询分析举例：

1. MCP Host：Comate Desktop 作为 Host，负责接收提问【分析42601969用户在 2023-3月每天的转化总数，按照时间升序排序，用折线图展示，并分析趋势走向 】并与大模型交互。大模型解析提问，并生成对应的SQL。

2. MCP Client：当大模型决定需要baikaldb_mcp/read_query Tool，Comate 中内置的 MCP Client 会被激活。这个Client负责与BaikalDB MCP Server建立链接并调用read_query工具。

3. MCP Server：BaikalDB MCP Server被调用，接收、执行查询语句，最终返回SQL执行结果。

完整执行流程：你的问题 → Comate Desktop → 大模型 → 需要查询BaikalDB表，并生成对应SQL → MCP Client 连接 → BaikalDB MCP Server → 执行SQL并返回结果 → Comate生成回答 → 生成折线图。

MCP架构设计使得如Comate等LLM应用，可以在不同场景下灵活调用各种工具和数据源，而开发者只需专注于开发对应的 MCP Server，无需关心 Host 和 Client 的实现细节。

03 BaikalDB MCP Server

3.1 BaikalDB MCP Server主要功能

BaikalDB MCP Server提供了以下功能，支持大模型直接和BaikalDB数据库进行交互：

1. 工具类（Tools）：大模型可以根据上下文按需调取的直接和BaikalDB交互的工具。

• 链接操作：链接到指定的BaikalDB库

     connect_baikaldb：给定链接信息（包括host，port，username，password，database），连接到对应的BaikalDB数据库，使用过程中支持动态切换不同的BaikalDB集群。

• 查询操作：包括获取库表信息，执行SELECT/DML SQL，分析SQL索引使用扫描量等。

     show_all_databases：获取所有的数据库列表信息。

     db_overview：获取指定数据库中所有表的概览信息。

     table_overview：获取指定表的概览信息，包括：表结构（show create table）、表示例数据（select * from table limit 3）。

     read_query：执行select sql并返回csv结果数据，大模型拿到结果可以进行智能分析、智能绘图等等。

     write_query：执行建删表、插入删除变更等dml sql并返回操作结果。

     analyze_select_query：分析查询SQL执行情况：使用的索引，索引扫描/过滤/反查行数等，支持大模型进行索引分析推荐。

• 模板操作（优化复杂场景使用）：支持预先导入模板SQL（如百度智能云推出的Sugar BI SQL模板），帮助大模型理解业务逻辑，后续大模型可在模板SQL基础上改写查询分析，并支持基于模板进行二次查询（如再次聚合），不同BaikalDB用户之间模板不共享。

     get_all_bi_sql_template_list：查询当前BaikalDB用户已导入的SQL模板列表。

     get_bi_sql_template_detail：获取SQL模板详细信息，包括SQL模板，相关表Schema等。

     add_bi_sql_template：指定模板说明，模板SQL等，添加新的SQL模板。

     delete_bi_sql_template：删除指定的SQL模板。

2. 资源类 (Resources) 和 提示词 (Prompts)：

• 目前BaikalDB MCP Server暂未定义资源和提示词，未来会根据使用场景灵活添加，以更好的引导大模型和BaikalDB进行交互。

通过以上工具，BaikalDB MCP Server使得大模型能自主的查询/操作数据库，进行多轮数据智能分析，并且可以结合大模型和其他MCP能力，并高效的通过多种形式呈现分析结果（如Excel文本，绘制图表等）。

3.2 BaikalDB MCP Server应用场景

BaikalDB MCP Server拥有以上能力后，就可以在以下场景中进行使用：

1. 实时数据分析和智能报表

• 大模型可以实时查询BaikalDB的业务数据，生成可视化报表，并可结合历史上下文生成分析报告或者建议。

2. 多数据源联邦查询分析

• 通过MCP支持大模型同时访问BaikalDB和其他数据源（如知识库、Mysql等），实现联邦分析。

3. 开发测试提效

• 在开发测试过程中，通过自然语言交互，建删改表、增删改查、构造测试数据、分析SQL执行情况等，不用额外切多个窗口执行SQL操作。

04 BaikalDB MCP Server使用

BaikalDB MCP Server使得BaikalDB不单是个高性能的分布式数据库，还是大模型的分析执行插件，使得用户不再需要任何开发，即可对BaikalDB存储的数据进行智能分析。

4.1 Comate 配置

以Comate举例：按照以下图示步骤，将BaikalDB MCP Server json配置添加到Comate MCP配置文件中，即可以在Comate中使用大模型操作BaikalDB数据库。当然后续我们会尝试将BaikalDB MCP Server发布到MCP仓库，使得配置更简单！

BaikalDB MCP Server Json配置如下：

{  
    "mcpServers":  {
        "baikaldb_mcp": {
            "transport": "sse/streamableHttp",
            "url": "BaikalDB MCP Server URL",
            "headers": {},
            "timeout": 50
          }
     }
}

4.2 Demo 演示

示例1：智能分析

下方视频展示了，在Comate中用自然语言对数据库数据进行智能分析和图表展示。 mpvideo.qpic.cn/0bc34mc4gaa…

示例2：开发测试提效

下方视频展示了，开发测试过程中的智能建表、导数、SQL执行分析、索引推荐等。 mpvideo.qpic.cn/0b2eiaadqaa…

示例3：基于模板智能分析

下方视频展示了，在复杂业务场景中，通过预先导入的BI SQL模板进行更高效准确的智能分析。 mpvideo.qpic.cn/0bc3omc24aa…

05 总结

BaikalDB MCP Server的核心价值在于打破了数据库数据的信息壁垒，构建了一条完整的智能数据处理链路，实现了从自然语言解析到业务建议输出的端到端能力：‌

• 自然语言理解：将非结构化查询转化为结构化意图。

• 数据库操作：自动生成并执行SQL语句。

• 数据分析：对查询结果进行多维解读并生成可执行建议。

但是也存在一些问题：‌

• SQL生成准确性高度依赖元数据质量（如表结构、字段注释）。

• 复杂业务逻辑描述困难。

• 大模型在长上下文中的注意力分配问题。

当然，随着大模型推理能力的持续提升和MCP协议生态的完善，这种数据智能范式将在金融风控、供应链优化、智能客服等复杂业务场景中展现出更大的价值潜力。

你有没有这样的体验？导航说30分钟能到，结果真的一分不差？

有时候导航告诉你要绕行5分钟的路，其实省下了20分钟的堵车。

这些神奇的“预知能力”，就是我们常听到的 ETA（Estimated Time of Arrival，预计到达时间），别看它们只是一个个数字，其实背后藏着一整套复杂又高效的技术体系。

百度地图 ETA

到底是怎么精准计算出来的呢？

【AI地图 Tech 说】第二期将为你揭开奥秘！

01 基础介绍

ETA 预测的本质，就是给定出发地、目的地和出发时间后，预测驾车所需的时间。例如，当你在某个时间 T 请求路线（如 Route = a→b→c→d→e）时，ETA 系统便开始计算驾车预计行驶的时长。

百度地图 ETA（未来出行）是地图导航的基础功能，其技术演进共经历了四个发展阶段。

▎ 1.0时代：静态 ETA（2010年前）

最初，百度地图 ETA 功能的计算方式极为简单，仅通过距离除以限速得出。然而，这种方式计算出的结果误差常常超过30%，一旦遭遇交通拥堵状况，更是完全无法应对，由此引发了用户的诸多吐槽。

▎ 2.0时代：动态 ETA（2010-2015年）

百度地图首次接入实时交通数据，能够识别实时拥堵路段并提供基本绕行建议。然而，这种方法仍无法预测拥堵的进一步变化趋势。

▎ 3.0时代：个性化 ETA（2015-2021年）

通过引入机器学习与用户画像，百度地图开始分析驾驶习惯（如激进型或保守型司机）、车辆类型（如货车或新能源车），实现了针对不同人群的个性化路线推荐。

▎ 4.0时代：预见性 ETA（2021年至今）

百度地图融入 AI 技术，如预训练大模型和时空预测技术，开始实现未来30-60分钟的精准路况预测，甚至能准确量化天气对行车速度的影响。

02 技术优势

百度地图 ETA 为何如此精准？背后的核心在于预训练交通大模型与端到端路线通行时间预测两大技术。

▎ 预训练交通大模型：海量 AI 知识集成体

预训练交通大模型通过地图脱敏轨迹数据，建模城市交通规律，为智能交通提供底座能力。预训练交通大模型基于千亿公里驾驶数据，能够精准捕捉不同城市在时段、天气、区域上的交通规律，如北京周一比周五早高峰堵12%、上海雨天车速下降22%、深圳科技园晚高峰比早高峰堵35%。同时，该模型还具备持续学习优化能力，每天都会结合最新观察到的真实拥堵情况自动更新模型参数。

预训练交通大模型整体框架

预训练交通大模型的框架主要分为3个部分：

交通大模型以及下游应用

■ Large-Scale Traffic Corpus（大型交通语料数据）

将原始的脱敏 GPS 轨迹点处理成路段粒度的交通时序信息和路线粒度的个性化导航行为。

■ Pre-Train Model（预训练模型）

基于历史交通大数据充分训练预训练模型，表征普适性的交通规律信息。

■ Downstream Task（下游任务）

基于预训练的交通图嵌入，通过 Zero-Shot 或者 Fine-tune 应用于通行时间预估、交通流量预估、路线排序、智能信控等场景。

▎ 端到端路线通行时间预测：基于交通大模型 FineTune 的 ETA-GNN AI 仿真推演路线模型

在预训练交通大模型基础上，百度地图进一步应用端到端路线通行时间预测，进行更细致的 AI 仿真推演，不再局限于逐路段的简单计算，而是精确模拟红绿灯等待时间、前方车辆汇入情况及施工路段的实际通行效率。同时通过动态概率模型实时评估，决策绕行还是等待，以达到最佳出行策略，预测准确率高达92%。

SFT-ETA 路线模型

ETA 路线模型预测 Pipeline

端到端路线预测体系涵盖以下核心能力：

■ 长时流量预测能力（Supervised FineTune）

全天候预测能力：通过对历史流量数据的监督微调，模型可实现对未来 24小时路段流量变化趋势的精准预测，适用于节假日、景区周边等高动态场景。

零样本迁移泛化：预训练模型内置“早晚高峰模式库”，可直接迁移至新城市路网，实现冷启动场景下的预测精度显著提升。

■ 动态交通关系图谱建模

时空图表示学习：捕捉交通流随时间与空间变化的普适规律。

路网级传播效应建模：通过图神经网络（GNN）结构，量化不同路段之间的流量传导影响，实现更高精度的区域级拥堵预测与调度模拟。

■ 地理语义位置编码（GeoEmbedding）

多维地理语义融合：将传统经纬度转换为包含道路等级、POI 密度、地形坡度等语义信息的向量表示。

跨模态建模能力：融合天气、热度等环境信息，实现对不同条件下相同路段的动态编码与差异化建模，例如“暴雨下立交桥”和“晴天立交桥”的通行效率差异。

■ 轨迹表示学习与个性化 ETA

行为建模：通过车辆历史脱敏的轨迹聚类，区分不同驾驶风格（如保守型 vs 效率型），提供分群精准 ETA 预测。

实时风格感知与动态修正：感知车辆当前驾驶状态（如频繁变道、急加速等），动态调整 ETA 和路径建议，实现个性化自适应路线仿真与推荐。

03 应用场景

百度地图 ETA 广泛应用于各类场景中：

日常通勤：准确预测早晚高峰路况，帮助通勤族合理安排出行。

机场接送：精准判断当前出发是否能赶上航班，解决旅途焦虑。

重大活动预警：如演唱会结束前提前提醒车主提前离场，避免拥堵。

节假日旅游：提前预测旅游景区附近的拥堵趋势，提供更舒适的出游体验。

通过持续的技术进化和 AI 驱动的全面赋能，百度地图的 ETA 精准度在短途、长途、拥堵、节假日等多个场景均已显著领先行业水平，在用户感知层面更显稳健和准确。更值得一提的是，在节假日（尤其“五一”这类与日常规律差异显著的场景下），其表现尤为突出。

出行从此告别盲目与焦虑

百度地图将每一次的未知变成清晰的规划

让用户安心出发，自信抵达！

你有没有过这样的体验？在高速上对着导航喊“小度小度”，它就神奇地回应道“来了”；在地下车库问“最近的充电桩”，屏幕立刻跳出相关的充电桩指引；甚至对车载语音助手说“有点冷”，空调的温度就会悄悄调高。这些看似“读心术”的交互背后，藏着一个能听懂人话、能感知环境、能精准应答的“数字领航员”。

当你说“查找故宫附近的粤菜馆”时，系统不仅要从3亿多条 POI 数据中精准定位，还要理解“附近”是500米还是3公里；当你追问“有包厢吗”，它甚至能调用餐厅实时预订系统。这些看似简单的对话，需要跨越语音识别、语义理解、内容获取、答案生成等多重技术关卡。

百度地图 AI 导航小度想想

如何将自然语言转化为精准指令？

那些“秒回”的答案又是怎样炼成的？

【AI 地图 Tech 说】第三期将带你拆解这座“数字领航员”的魔法工厂，看看从“听清”到“听懂”方面，究竟藏着多少黑科技。

上图说明了从用户请求到最终执行的整个过程，可以看到其中经过了语音识别、意图解析、技能承接等主要的环节！

01 语音指令的解码之旅：从声波到文本

当用户说出"导航到故宫博物院"时，系统首先启动声学模型将声波转化为文字。这个看似简单的步骤，其实也不容易，蕴含三层技术环节：

▎ 基础识别

其实就是我们大家常说的语音识别技术，它利用深度学习模型将声波信号转化为二进制序列，结合声学模型与发音词典生成初步文本。语音识别技术近年来经历了白盒化到黑盒化的演进，其性能、效果都有很大的提升，大家应该都已经比较熟悉。但相对于安静室内环境，用户在户外使用小度想想的时候，还有一类常见的问题是拒识。根据统计，至少有15%左右的语音请求是由于误唤醒/误收音引入的（非用户主观需求）。小度想想，需要考虑到行驶过程中的风噪、聊天、多媒体播放等复杂噪音场景，百度地图引入了双重拒识判断模型（声学拒识、语义拒识），提前对问题请求进行甄别和提前拦截，最大限度降低用户干扰，大幅提升用户体验。

▎ 纠错

通过语言模型（如BERT、N-Gram）对识别结果进行上下文纠错，例如将“北经”修正为“北京”。这是小度想想相对于通用的语音助手的优势所在，在纠错的过程中，会使用包括地图 POI 数据、路名数据等专业字典进行参考。百度地图建设了超亿条 POI 数据的本名、别名、关联名的地理知识图谱，将 POI 的各种表达方式建立标准化映射。在此过程中，还需要构建错误拼音-标准名称的双向索引表，支持"西单大悦成"→"西单大悦城"这样的智能纠错。

▎ 排序

在实际工程中，纠错手段不可能只有一个，因此就需要在上述流程完成后，基于多个逻辑，会输出多个可能的识别结果。这里就会基于用户之前的对话习惯，以及一些其他基于先验知识和统计学习的置信度评分算法，从多个候选文本中选取最优结果（比如“横屏模式”，在排序中会优于“红屏模式”）。

02 意图解析的"翻译官"：把自然语言转化为机器指令

当从语音的音频识别为自然语言之后，下一步就是将其转化为机器指令。这里包括几个关键技术：

技术亮点一：『意图模板匹配』

基于自然语言处理（NLP）技术，完成实体识别（如时间“明天”、地点“北京”）、意图分类（如“天气查询”）、情感分析（如用户是否急躁）。过去的语义理解，更多使用模板类技术，如下图所示，针对用户问询的内容抽取出关键要素后，再看匹配了哪种需求表达方式，这称之为一个“意图模板”，基于大量预置的模板就可以实现大部分指令的识别。

技术亮点二： 『生成式意图理解』

模板化语义理解能解决很多问题，但是存在的关键短板在于泛化理解能力不足，同时高度依赖领域知识积累，需要提前做大量的模板标注，还要解决相近表达方式的模板冲突问题，当模板数量达到一定程度后维护成本就会增加。LLM 的出现，另辟蹊径地解决了这个问题。其核心优点是端到端利用 LLM 的上下文理解能力，直接解析用户自然语言中的隐含需求，形成对“口语表达中蕴含的本质意图”的理解，这个过程中无需构造模板，而是提前将全量承接 API 的参数规范作为“知识”以Prompt的方式注入 LLM，使其自主选择 API 并填充参数。举例来说，我们可以给大模型这样的 Prompt：

角色：你是一个语音助手语义解析器，目标是将用户指令转换为API调用
参考资料：可用的API及参数如下：
{API参数规范库}
用户指令：{user_query}
任务：请按以下步骤执行：
1. 选择最匹配的API；
2. 从指令中提取参数值，若未明确提及则设为null；
3. 输出JSON格式，包含api_name和parameters。
预期输出：{"api_name":
"search_flight", "parameters": {"departure_city":
"北京", ...}} 

大模型就能输出针对 user_query 最合适的工具调用参数，跳过了映射的环节，减少了折损，同时因为 LLM 对世界的强刻画能力，使泛化能力也大幅增强，这种模式已经在业内广泛使用，成为提升语义理解能力的主流方法。当然，大模型的应用中，少不了有成本、响应时间上的难题，所以实际工程中还是会大小模型混用，或者用小模型做定向的精调，来实现成本、性能和效果的兼顾。

技术亮点三：『工具调用』

工具调用是小度想想的下半身，是能够准确承接用户需求的关键支撑。其本质上可以理解为一系列 API 接口的调用。当调用序列复杂了之后，调用状态的维护就会成为问题，小度想想针对多轮复杂工具调用，提出了基于技能的状态机架构，任意复杂的操作，都可以基于这套架构来统一表达。

技术亮点四：『生成式 AI 时代的工具调用进阶』

在大模型的时代，为了提升工程化的效果，在 API 接口的基础上又诞生了两个公认的技术范式：

• MCP：聚焦模型与外部工具的连接，提供统一接口（如数据库、API调用），类似“AI 的 USB 接口”，降低跨模型开发成本。只要所有工具都以 MCP 的协议接入，那么大模型就可以知道这个工具能力的存在，从而能做到在合适的时候调用它。

欢迎使用百度地图 MCP 服务

• RAG：RAG 本质上是对问答能力的数据增强，如果小度想想仅仅基于老旧的 LLM 底座来回答问题，会有很严重的幻觉发生。为了解决这个问题，往往使用检索增强生成（Retrieval Augmented Generation，简称 RAG），百度地图将所有的地图领域数据以结构化来存储，然后在用户提问后，以向量相似性找到对应参考数据，并取出再用 LLM 做汇总，就相当于从“闭卷考试”变成了“开卷考试”，从而保证了答案的精准性。

03 持续提升生产力：从语音助手到智能体

随着 LLM 的能力越来强，我们发现，它的强大理解能力，对于一个一般化的常识问题，能给出相当接近人类的回答。那么是否它能模拟很多团队协作的真人，甚至以硅基生命来承接现实世界的生产力？这就是智能体（Agent）要考虑的问题了。智能体是这两年 AI 领域最火的词之一，它是基于人工智能技术在某个领域体现高度智能，显著提升人类工作效率的信息系统，相对于“语音助手”，更偏重于“通过观察、思考、权衡利弊，动态自主调用基础能力、高准确地解决复杂业务问题”的特性。

以自动驾驶场景为例，智能体可以实时感知车辆周围的路况、其他车辆的行驶状态、交通信号灯的变化等关键信息，为后续决策提供坚实的数据基础。自主决策能力堪称智能体的 “大脑”，它依据感知到的环境信息，结合内部预设的规则和先进算法，迅速、准确地做出决策。在面对复杂路况时，自动驾驶智能体能够综合分析各种因素，精准判断是加速、减速还是转弯，以确保车辆行驶的安全与高效。又如在智能物流配送中，智能体的核心目标是按时将货物准确送达目的地，为此它会综合考量实时路况、车辆载重等信息，动态规划最优配送路线，克服重重困难以达成目标。

回到语音助手这个场景，结合地图智能体的任务，首先要针对地图场景深入精调大模型，百度地图通过文心一言基座大模型进行二次预训练、SFT、强化学习等手段，使地图大模型能够精确理解用户在地图中的各种常见表达，理解准确率高达95%以上。

此外，针对复杂任务的执行，还要引入的两个特性是记忆和反思：

• 记忆能力：当用户表达不完整的需求时，能够基于之前的问答和用户行为，自动补全对话内容（如用户问“今天限行吗？”默认补充用户所在城市），因此需要构建记忆能力，用于存储历史交互数据、用户偏好与领域知识（如常用地址、路线选择习惯、节假日出行规律），为意图理解与决策提供背景支持，减少重复询问并提升个性化水平。这里面的短期记忆一般是指从启动会话至今的内容，往往持续数分钟，而长期记忆则是用户相对稳定固化的特征，就地图智能体来说，用户的搜索、导航记录等都是长期记忆的范畴。

• 反思能力：一个初始状态的智能体，在应对用户复杂需求以及实时环境快速变化时，往往会出现理解偏差、输出内容不完备与知识更新滞后等问题。引入反思（Reflection）能力，能显著提升服务的精准性与智能化水平。基于上述记忆-反思流程图，可以看到反思能力能不断地自我判断当前的答案是否满意。当然，客观来说，在大部分领域很难实现完美的反思能力，因为反思的本质是要在将答案呈现给人之前就能判断其质量，这里面存在大量主观因素和模棱两可的问题，在这个过程中，LLM 是第一大功臣，可以说针对语音对话类场景，没有 LLM 纯靠规则就不可能实现普遍有效的反思。除此之外，长短期记忆也起到了重要的作用，它能够结合用户之前的习惯，猜测当前的结果是否符合用户预期，如果不符合，会主动打回进行重新理解和执行。

04 案例解析：天气查询的完整技术链路

以一个简单的“明天北京会下雨吗”为例，系统执行以下操作：

• 语音识别：ASR 引擎输出“明天北京会下雨吗”文本；

• 语义理解：通过注册到小度想想的工具，结合这段文本，输出应当调用天气 API，获取相关数据；

• 服务调用：调用天气 API 获取预测天气数据；

• 答案生成：输出“明天北京阴有雨，15-25℃”；

• 反思与重新生成: LLM 审视这个答案，认为还不够详细，反思后认为应该按时间段细化降水概率，因此重新请求天气 API，获取更详细的降雨预测数据，并呈现给用户。

随着多模态大模型以及自动驾驶技术的发展，未来的小度想想会有更多的可能性。从大的趋势来说，语音语义一体化大模型正在逐渐成熟，2025年3月31日，百度在 AI DAY 上发布了业界首个基于全新互相关注意力（Cross - Attention）的端到端语音语言大模型，该模型实现了超低时延与超低成本。另外，多模态的对话（比如视频 AI 对话）和自动驾驶的结合也值得重视，比如通过车载摄像头识别"前方学校区域"并自动减速；通过声纹、视频和车辆传感器识别人、车的异常，主动采取应对措施；而在导航行中播报的时候，所有内容都是基于实时动态数据进行人格化生成，再也不像机器人那样的生硬，而是像真人一样地交流，让我们的出行更舒适高效。