阅读视图

大模型在百度电商机审应用的落地实践

2025年10月31日 10:46

导读

本文聚焦百度电商风控场景，针对传统机审多模态识别弱、语义模糊难区分、审核体验差等痛点，推进原有机审流程向AI化流程改造，基于业界MultiAgent范式在审核场景落地应用，提出 “多模态大模型 + 规则 + 知识库” 协同的机审 Agent 方案。通过：1. 审核标准体系化、大模型化；2. 多模态大模型在领域典型问题上的抽象技术方案；3. 针对场景化问题精准优化。产出标杆式业务落地效果，为电商风控大模型落地提供可迁移能力强的技术方案。

01 背景与问题

1.1 背景

“百度优选”是百度旗下电商品牌，伴随着近年百度电商的快速成长，在 “人、货、场” 高速运转的背后，风控体系始终面临 “安全 - 效率 - 体验” 的三角挑战：

对平台：风控是 “生命线”若未能准确及时的管控风险，可能引发监管处罚、用户信任流失，甚至影响百度的商誉。
对商家：“快过审 + 明理由” 是核心诉求，在传统人工审核流程中，商家提交信息后需等待2-4 小时（峰值期甚至 1 天），若被拒审仅收到 “内容违规” 的模糊反馈（在历史的商家访谈中，部分不满意指向了 “审核慢、理由不清”）。
对用户：“看到靠谱内容” 是关键，若平台出现了不可靠或者低质的信息，用户可能会因 “被骗” 损失利益，从而进一步导致用户的流失。

作为百度电商风控技术团队，我们的目标很明确：用大模型重构机审体系，实现 “全机审覆盖 + 即时反馈 + 高可解释性”，让平台 “安全”、商家 “高效”、用户 “放心”。

1.2 面临的问题

在大模型落地前，我们的传统风控流程是 “商家提交→机审（规则+小模型过滤）→人审（人工判定）”，这种模式在业务快速增长下：

问题 1：人审瓶颈刚性，无法支撑业务增长
问题 2：机审能力薄弱，为保证风险不露出人审覆盖面大，审核时效长（小时级，极端情况下甚至长达1天）
传统机审依赖规则引擎（如关键词匹配 “最佳”“第一” 判定虚假宣传），但无法处理复杂场景：
多模态违规：主图显示 “Nike”品牌，详情页显示为”山寨品牌“—— 规则无法识别图文不一致；
模糊语义：“本品有助于睡眠”（合规）vs “本品治愈失眠”（违规）—— 规则无法区分 “程度差异”；
问题 3：审核体验差，商家申诉率高
传统机审拒审理由模糊，商家需反复猜测修改方向。

为了解决上述提到的问题，本文将详细介绍本次最佳实践

02 技术方案

针对传统流程的痛点，我们提出 “大模型 + 规则 + 知识库” 协同的机审 Agent 方案，核心逻辑是：让模型做 “语义理解”（擅长的事），规则做 “确定性判断”（稳定的事），知识库补 “外部信息”（精准的事）。

2.1 整体技术方案

流程上，我们重构了整个审核流程，实现了 “全机审覆盖 + 即时反馈 + 动态校准”：

原流程 vs 新流程对比

2.2 亮点

2.2.1 审核标准对齐

要实现全机审，“人审标准可量化” 是前提。我们通过 “风险梳理→标准优化→动态更新” 三步，将 700 余个零散风险点整合成 24 组核心风险，覆盖了95%+的线上违规问题。

步骤 1：风险点梳理 —— 做 “减法”

我们采集2025年Q1的全部人审记录，

相似风险合并：采用层次聚类将相似违规进行归类。
风险分层：对”风险严重程度“较低，且不直接影响商品价值和用户购买决策的风险暂时不纳入机审（人工巡查覆盖）。
长尾剪枝：对”发生频率“较低的风险暂时不纳入机审（人工巡查覆盖）。

步骤 2：审核标准优化 —— “规范化”

我们把人审识别的风险划分为三部分，明确违规/明确不违规/边界样本

步骤 3：动态更新 —— 做 “迭代”

我们每月例行巡查、回收商家申诉和人审处理数据，若发现新违规类型，则补充到风险组，及时更新线上机审agent。

2.2.2 基于多模态大模型的机审agent设计

大模型是机审 Agent 的 “大脑”，我们选择大语言模型+多模态大模型为基础，辅助知识库（品牌授权库、类目树、资质库），实现 “多模态理解 + 精准判定”。

输入层：多模态数据整合

接收商家提交的全量商品数据，包括：

文本数据：商品标题、详情页描述、规格参数、商家资质名称；
图像数据：主图、详情图、资质图片（如《授权许可证》）；
结构化数据：商家资质库（如品牌授权记录、进口报关单）、平台类目树、风险规则库。

特征抽取层：多模态特征融合

特征抽取是机审的 “感知层”，我们采用 “规则抽取 + LLM 文本理解 + 多模态模型图像理解” 的组合方式，覆盖所有维度的商品信息：

规则抽取：用正则表达式提取标题中的品牌（如 “Nike”）、类目（如 “运动鞋”）、关键词（如 “进口”）；
LLM 文本理解：用文心大模型提取详情页中的模糊语义（如 “治愈失眠” 的违规表述）、逻辑矛盾（如 “进口商品” 但未提报关单）；
多模态大模型图像理解：使用多模态大模型模型识别主图中的品牌 logo（如 Nike 的 Swoosh 标志）、资质图片中的 OCR 信息（如《授权许可证》编号）。

风险判定层：大模型 + 规则 + 知识库协同

风险判定是机审的 “决策层”，核心逻辑是 “让专业的模块做专业的事”：

规则引擎处理确定性逻辑：针对 “绝对化用语”“资质必填项” 等确定性规则，直接用代码判断（如 “含‘进口’关键词必须提交《进口报关单》”）；
知识库查询外部信息：关联商家资质库、平台类目树等领域知识（如查询商家是否有 Nike 的授权记录）；
LLM 综合判定：融合多模态特征、规则结果、知识库信息，输出最终结论（如 “主图含 Nike logo + 无授权记录 → 品牌侵权违规”）。

输出层：精准反馈 + 可解释性

输出层是机审的 “交互层”，需满足商家的 “明理由、能整改” 需求：

审核结果：通过 / 拒绝；
拒审理由：自然语言描述（如 “您发布的商品主图含 Nike 品牌 logo，但未提交 Nike 品牌的《授权销售许可证》”）；
整改建议：输出给发品端前端，提供自动整改能力（如删掉对应违规位置违规信息）。

任务拆分：让模型 “专注擅长的事”

我们将机审任务拆分为三类，以同时保证审核结果的高召回，高准确，清晰可解释：

特征抽取：提取商品的关键信息（如从主图提取品牌 logo、从详情页提取材质等）；
风险判定：规则引擎结合知识库，判断特征是否违规（如 “logo 是 Nike，但无授权→侵权”）；
理由生成：模型生成自然语言拒审理由（如 “未提交xx品牌的授权许可证，请补充”）。

03 实践案例

在典型问题的文本问题判定，图片问题判定，图文融合问题判定上，经过我们的技术方案演进，均可达到几乎对标人审能力的效果。

3.1 资质缺失风险判定

场景描述

针对高危商品行业如三品一械行业，售卖相关商品时要求商家提供清晰可辨、且信息完整的对应资质（如《保健食品批准证书》、《国产特殊用途化妆品行政许可批件》、《医疗器械备案证明》、《委托进口协议》等）。

传统流程痛点

规则策略：仅能检查 “是否含‘进口’关键词”，无法关联商家资质库，漏检率高；
人审需人工查询和核对资质，耗时长，易因 “漏看” 导致误判。

机审方案：领域微调 + Prompt Engineering

对于此类复杂判定类问题，领域知识深度深，我们基于基座模型进行了模型微调，通过高质量样本收集 -> Prompt Engineering -> 数据增强 -> 模型微调得到了专注于电商风控场景的领域AI模型

高质量样本收集：我们将真实场景下经人工核验的高质量样本沉淀为模型训练语料。这一环节是模型训练的核心，保障了训练数据的真实性、多样性，以及对各类场景的覆盖丰富度。
Prompt Engineering：基于不同样本类别，设计场景化提示词，引导模型关注风控领域知识：
数据增强：我们采用SOTA思考模型，动态生成Cot并对生成内容进行精细化纠偏，提升模型的推理能力：
模型微调：对比百度自研文心基座模型和开源Qwen系列模型，我们分别对比和采用了全参数微调和指令微调方式，加速训练过程，进一步提升模型效果，获得风控领域专家模型。

3.2 品牌授权风险判别

场景描述

商家发布的商品信息，涉及限售品牌，但实际未获得品牌授权（易引发假货投诉等体验问题）

传统流程痛点

“山寨 logo”较难以识别（如 “Nlke” 冒充 “Nike”）；
授权书需人工手动核验，耗时久，漏检率较高；
管控品牌库变动升级较多

机审方案：多模态特征匹配 + 知识库关联

采用 “多模态模型图像识别 + LLM 字符相似度对比 + 知识库查询” 的方案：

多模态模型图像识别：采用多模态模型提取主图中的 logo 特征；
知识库查询：关联限售品牌库，确认品牌是否限售，是否有授权记录；
LLM 图文信息融合判断：确认提取品牌信息是否限售且无授权；

3.3 类目错放风险判定

场景描述

1）因电商商业流量推荐等场景中列类目特征权重极高，类目准确性严重影响流量变现效率；2）平台佣金政策和资质/定向准入等管控要求与类目强关联；因此要求商家发布商品必须选择到平台类目体系内最准确的类目；

传统流程痛点

图文特征融合困难：传统方案一般仅使用标题识别类目，商家对抗后容易绕过机审
平台类目庞杂：审核员需非常了解平台近5000个类目结构，极容易误审

方案演进

方案一：基础方案

图文特征融合推荐平台top相似度类目

方案二：解决类目推荐不准确问题

改为召回+rank 两阶段方案，提升精准选择类目可能性
升级相似度计算模型为bge-large-emb，解决部分情况下相似度召回精准不足问题

方案三：解决部分高风险商品在第一轮候选集召回不足问题

增加定向召回通路，提升高风险商品召回能力
升级风险判定方案，结合大模型判定和识别规则，进一步提升精准判别能力

04 总结与展望

4.1 落地效果

超预期的 “三升三降”

三升

机审覆盖率提升
审核时效提升
商家满意度提升

三降：

人审量减少
申诉率减少
用户投诉率减少

4.2 经验总结

大模型不是 “取代人”，而是 “解放人”—— 让审核人员从 “重复劳动” 转向 “标准制定、风险预判”。

本次落地实践较为成功的要点

多模态融合：电商数据 80% 是多模态的，单模态模型无法覆盖所有场景；
可解释性优先：大模型的自然语言生成能力是提升商家体验的关键 —— 传统规则的 “内容违规” 无法让商家整改，而 LLM 生成的 “未提交 Nike 授权许可证” 能直接指向问题，进一步的我们业务团队为商家提供了一键整改功能，大大提升商家使用平台工具的满意度；
闭环迭代：用巡查、申诉数据持续优化模型，形成 “数据→模型→效果提升” 的飞轮；

4.3 展望

agent的自我优化：利用大模型生成能力生成难样本，解决风控场景的大难题——小样本问题，辅助少量人工干预使得agent自我演进和优化。

05 结语

过去的1年里，大模型技术突飞猛进的发展，为电商风控带来了 “质的飞跃”—— 从 “被动堵风险” 转向 “主动防风险”。在百度电商风控技术的实践中，我们乘着时代的技术红利，落地 “多模态大模型 + 规则 + 知识库” 解决了传统机审的痛点，实现了 “平台安全、商家高效、用户放心” 的平衡。未来，我们将继续探索 “AI + 风控” 的边界，提供可快速迁移的大模型落地方案。

大规模微服务系统中的雪崩故障防治

掘金专栏-百度Geek说

百度Geek说

2025年10月29日 17:33

导读

在大规模微服务架构中，雪崩故障是极具破坏力却又难以预防的系统性威胁。本文基于百度搜索架构与运维团队的实战经验，深入解析雪崩从“非稳态”到“自强化崩溃”的微观演化机制，揭示重试风暴、容量退化等正反馈回路的形成过程。文章提出系统化的治理思路，并详细介绍百度落地的多项核心实践，包括重试预算、队列限流、全局TTL控制等自愈机制，以及秒级流量调度与降级预案。通过真实案例与生产数据，为行业提供了一套可借鉴的雪崩预防与治理框架。

说明：本文是由2025 SRECon会议的《Preventing Avalanche Failures in Large-Scale Microservice Systems》的演讲者翻译并整理而成。

01 摘要

大规模微服务系统在享受分布式架构带来的灵活性和扩展性的同时，也面临着雪崩故障的严重威胁。雪崩是一种系统性故障模式，破坏力极大，难以预防，会给企业带来巨大损失。

本文深入分析雪崩的形成机理和演进模式，建立理论模型，从微观层面推导灾变过程，并通过真实生产案例验证了雪崩的快速演化路径。接着，通过系统化的思辨，探讨可能的治理方法。然后，介绍了百度的系统性的雪崩治理框架及一系列的核心实践机制。最后总结了近几年的治理成果，为行业提供了可借鉴的实践经验。

02 背景

大规模微服务系统本质是一张由大量节点和依赖交织而成的网络。请求从入口gateway进入系统，再层层向下形成深度调用链，往往还伴随着交叉依赖与高扇出。这种特点虽然带来了灵活性与扩展性，但天然埋着三类稳定性风险：其一是“未知中的未知”，如冷门链路、冷门代码在突发场景被激活；其二是容量级联风险，任一节点变慢都会把反压沿链路放大回传；其三是重试风暴，自我强化的流量会指数级扩散。在这种架构中，任何局部抖动都会以毫秒级在系统中传播。理解这张网络，就为理解‘雪崩’发生的原因奠定了基础。

大规模微服务系统依靠多种高可用机制来提升性能，表现为：

分布式架构避免单点故障并带来弹性扩展能力；
缓存抵挡流量激增并降低延迟；
重试实现瞬时恢复并提高成功率；
请求队列平滑流量尖刺并维持稳定吞吐量。

然而，在雪崩条件下，同样的机制会翻转到另一面，表现为：

分布式架构引入复杂依赖和更大的爆炸半径；
缓存失效引发流量洪峰和延迟激增；
不受控的重试导致指数级流量风暴；
后端变慢导致队列超时和入队失败。

03 直观感受雪崩的威力

这里举一个真实的例子给大家直观感受雪崩的威力。在一个IDC中，少量实例出现轻微健康退化，引发中等程度的延迟上升和轻微的可用性下降——没什么令人担忧的，只是典型的小波动。几乎同时，随着上游重试机制启动指数退避策略，流量迅速激增，导致服务在几秒内变得不可用。

然后，根据预定义的SLA执行自动预案，将大量负载从受影响的IDC转移到其他健康的IDC。但这些"健康"的IDC，只能在正常容量范围内运行，此时突然遭受显著的放大了的流量冲击，也变得过载。

紧急扩容马上被触发，扩充并启动更多的实例，但级联过载的蔓延的速度仍然比我们扩容策略的响应速度更快。

紧接着，多项尝试止损的动作被并行执行——流量比例调整、缓存命中率优化、超时时间缩减——然而它们在呈指数级的故障放大效应面前仍然无效。此刻，系统处理的主要是重试流量，其数量远超设计容量，线程池完全耗尽，请求队列被已超过SLA阈值并且注定要失败的请求填满。

这进一步引发了所有IDC的级联故障，最终导致系统级的完全崩溃，影响了大量用户。

在这个案例中，起初只是一个影响了少量实例的小问题，最终演变成了完全的系统崩溃。整个过程在仅仅2分钟内发生——这是大规模微服务系统在雪崩场景下如何自我毁灭的可怕呈现。

04 雪崩的特点

以上，我们直观感受到了雪崩的威力。那么，什么是雪崩？让我们从4个雪崩的特点来介绍雪崩。雪崩发生前，系统都会首先进入“非稳定”状态，这种状态“貌似正常、实则脆弱”。各项指标也许还在阈值内，但可用余量极少，表现为：负载上升，延迟上涨……此时的系统对扰动极为敏感，任何轻微扰动都会使它偏离稳定状态。

第二个特点是需要小的触发源扭转状态。触发源可能是多种多样的，比如，流量尖刺、网络瞬时抖动、硬件故障、软件冷门逻辑被触发……。它们本身并不致命，但在不稳定状态边缘，哪怕微小的触发都足以把系统推过临界点。真正导致系统边界违规的不是触发的强度，而是系统自身余量不足。然而，微小触发仍然是必要条件。

一旦越过临界点，系统会迅速进入自强化阶段，这是雪崩最典型的一个特点。在这种情形下，高可用优化机制统统都站到了反面。系统每增加一点恶化，高可用机制就产生一些正向反馈，从而导致进一步恶化。这条恶化-反馈循环持续加强，复杂且迅速。图中展示了几个例子。回路一：请求失败导致重试，然后导致负载上升，进而导致更多失败，最终形成指数级的重试风暴；回路二：少量实例略不健康导致被摘除，然后导致剩余实例更忙，进而导致更多实例被判不健康，最终引起容量指数级退化；回路三：错误事件导致大量的日志和监控，然后导致I/O用量上升，进而导致更多错误，最终使性能进一步恶化。

随着自强化阶段的持续，系统很快进入到失控和崩溃状态，这种状态最大的特点是无法靠自身恢复。线程池被耗尽，请求队列被已超时或必然失败的请求塞满，后端被无意义工作占满并拖慢，上游开始全面超时。

常见修复措施并不能奏效，甚至适得其反。比如，临时扩容往往慢于正反馈的加速导致资源就绪时系统早已熔毁，调cache难以解决重试反馈带来的流量放大，等等。需要专用的机制才能缓解，就像不能灭火器扑灭一颗正在爆炸中的核弹。唯有改变微观机制上的反馈结构，才能真正抑制雪崩。

让我们简要回顾雪崩的4个特征来理解雪崩的定义：

非稳态：系统看似正常但余量极少，对扰动高度敏感；
微小触发：流量尖刺或网络抖动等轻微扰动就能推动系统越过临界点；
自强化：高可用机制创建正反馈循环，通过重试风暴和容量损失放大恶化；
无法自我恢复：系统崩溃，资源耗尽。常见修复措施适得其反，需要专门干预。

05 理论模型

让我们从微观层面看一下雪崩。首先，我们看一个基本的模型。在这个模型中，流量以rps的吞吐流经一个服务的请求队列；然后，该服务的workers以concurrency的并发度处理队列中的请求，并发向后端进一步处理。在正常情况下，发向后端的吞吐也是rps。从请求到达本服务到本服务处理完成，所用的时间是latency。

基于Little's Law，我们有这样的公式：rps <= concurrency / latency。

真实的系统可以看做基础模型的管道似的级联连接。在这套连接系统中，需要保持任意位置的吞吐在实际流量之上，即在任意位置，都要维持这个rps <= concurrency / latency式子满足。

整个系统的吞吐受限于最薄弱的环节。需要精心地维持各环节脆弱的平衡。若任何位置的平衡哪怕短时间被打破，也会迅速触发级联反应，使系统雪崩。

06 微观灾变过程

接下来，让我带大家从微观层面看一下雪崩过程发生了什么。在这个抽象例子中，拓扑结构为 gateway → A → B → C，其中服务C变慢并成为触发点。

这张图使用“状态聚焦”的视角展示雪崩的快速微观演化过程。首先说明图中颜色的含义：红色代表恶化；灰色表示此阶段暂无新增变化。我们仅高亮当前需要重点关注的信号。

在健康状态下：系统延迟低，排队最少，吞吐量最优。
在触发阶段：C开始变慢，其延迟明显上升。
随着问题扩散，B和A的线程利用率和延迟几乎同时激增，而吞吐量和队列长度保持相对不变，显示出典型的’严重积压前的快速传播’行为。
随即来到堆积阶段：当并发达到上限后，B 和 A 的队列开始快速堆积，表明排队机制已被触发。
很快系统进入重试状态，B的超时触发上游重试。B接收到更多流量，而好吞吐比例下降，显示服务质量正在恶化。
接下来，流量开始放大，gateway级重试被触发，在A处造成流量激增，在B处造成第二次流量激增。对B产生的压力导致好吞吐进一步下降。
最终迅速坍塌到雪崩阶段：重试的重试形成正反馈循环，线程与队列被大量无效工作占满，系统彻底崩溃。

请注意三个关键点：线程利用率首先增加，队列长度快速跟进，吞吐量表现出两次或更多的快速跃升。

07 真实案例验证

让我们用真实的生产数据来验证前面的模型。由于这个故障发生在几年前，我们现在展示的这些指标是当时能够获取到的最完整的一组，尽管未能把前面模型里提到的所有指标都收集到。左边这个小图把B的总时间拆成了三部分：排队时间、本地处理时间、以及后端时间；右边的三张曲线的时间轴是对齐的。

这次故障仍然是C变慢了。首先，B的后端时间、整体延迟、线程使用量几乎同时抬升，与此同时，A的整体延迟也开始上涨。紧接着，B的排队时间开始上涨，很快，A的排队时间也跟着抬头——这正对应前一页的“扩散到堆积”的阶段转换。

接着我们发现一个有趣的现象：B的本地处理时间不增反降。其实原因很简单：线程更多时间在等后端返回，CPU空出来了，局部被处理到的请求就显得更快，这是常见的“局部变快错觉”。

再看吞吐曲线：A和B的RPS先出现一次阶跃，这是gateway的重试流量被激发；随后B的RPS再次跃升，这是A触发了二次重试。虽然我们没有直接画出“重试率”和“好吞吐占比”，但“排队时间增长”和“RPS两次阶跃”的组合，足以验证雪崩过程中由重试的驱动的故障放大路径。

整个过程大约发生在三分钟之内。

08 系统性思辨

既然我们理解了什么是雪崩以及它们在微观机制层面是如何工作的，让我们采用系统性方法来分析我们的选择。我想通过一个结构化的框架带着你来思考。在这个框架中，我们将检查雪崩的每个特征，并问：“我们能在这里干预吗？”通过这种系统性分析，我们能发现应该在哪些地方进行发力，以及哪些方法是现实的而非理想化的。

首先，是非稳态的避免。对于大规模分布式系统来说，完全避免非稳态是不现实的。系统本质上是面临无限触发源的复杂网络，其中HA机制更是一把双刃剑。它们从根本上是具有内在不稳定性的脆弱管道的级联。

尽管如此，我们仍然可以通过一些措施提升系统进入不稳定状态的阈值，使其更难进入不稳定状态，在面对更多触发源时能从容地运行。

接下来，我们思考能否消除所有触发源。实际上，这是完全不可行的。触发源对应的是一个无限的开放空间，不可枚举——包括网络抖动、流量尖刺、软件缺陷、硬件故障以及无数其他不可预测的因素。

虽然我们可以通过设计冗余机制来减轻干扰对系统稳定性的影响，但这种方法有两个主要局限性：首先是巨大的成本。例如，在网络基础设施层实施冗余链路聚合，在数据中心基础设施层面建设多套制冷系统，等等。而且，建设冗余机制往往涉及跨职能基础设施工程工作，实施困难且超出SRE的职责范畴。

接下来，我们能否消除自强化反馈回路呢？不可行！因为这些回路与HA机制内在相关，迫使我们必须做出权衡。

然而，将缓解机制嵌入到反馈回路内部，通过改变微观层面的反馈结构，可以将指数级放大转化为线性、可控的影响，大大降低其破坏力。就像用控制棒来阻止核反应中失控的中子放大。

最后，我们来探讨能否防止系统崩溃。这是可行的，主要通过两种互补的方法：最大化可用吞吐量与构建弹性恢复机制。即使系统超越临界阈值，我们仍可通过建立内部容错机制与外部干预预案，避免系统全面崩溃，并为系统创造多次恢复机会。

经过以上分析，我们发现可以在这些关键点实施雪崩治理工作，如右图所示。接下来，我们将详细介绍我们的核心实践。

09 我们的实践

前面说过，由于触发源众多，无法逐一验证系统在各种触发源下的行为，因此我们将所有触发源抽象为有限的几类场景，确保系统在这些场景下保持稳定——最大限度保持好吞吐。

这些场景分为两个维度：第一个维度是流量压力：包括流量逐步上升和瞬时激增。第二个维度是系统容量变化：包括绝对容量减少（如服务下线）和相对容量退化（如响应变慢）。

针对这四类场景，我们直接在生产环境中进行系统化验证：对于流量风险，我们在生产环境执行全链路压测，模拟流量的渐进式增长和瞬时尖刺。对于容量问题，我们在生产环境开展混沌工程，在真实环境下模拟服务容量缩减和延迟注入。

通过生产环境验证，我们提前发现潜在风险，确保系统在雪崩场景下保持最大可用吞吐的预期行为，结果可信且能代表实际系统性能。

早期检测对雪崩预防至关重要。我们建立了全面的监控系统，跟踪先导指标：

端到端失败数量
所有服务的通用指标，包括实例健康状态、实例CPU/内存/磁盘/IO利用率，以及coredump计数，等等
核心服务关键指标：包括请求队列长度、线程利用率、分位点延迟，等等
分片服务：分片丢失率

所有指标都是以秒级实时进行监控，并建立预警策略，使我们能第一时间感知到异常。

我们对系统自身的改进是建设一系列的"自愈"能力。首先是"重试预算"，用于在client侧就地收敛重试风暴。每个请求携带"全链路重试状态"信息，RPC组件据此识别两类重试：直接重试（本服务对下游）与间接重试（上游祖先节点发起）。RPC组件维护一个"预算池"，对两类重试流量配置不同的预算阈值，超过预算即快速失败。预算策略会随后端服务容量自适应调整，以充分使用后端容量。该机制把自增负载限制在可控范围内，避免指数级扩散。

在服务器端，我们还构建了一个称为“队列限流”的吞吐保护机制。我们将服务侧的请求队列做成多级优先级队列，并设置限流器。请求入队前先经过优先级过滤，在拥塞时，高优先级的请求允许通过，低优先级的请求被丢弃；限流器则根据实际处理速率自适应放行，同时，对于队列中超时的请求也会及时排出。在server侧容量到达瓶颈时，这套机制让有限的算力用于处理“好吞吐”。

我们也在系统中建设了更精细化的减少无谓的算力浪费的机制，即，全局TTL控制。每个请求在入口获得初始TTL，并随着请求在全链路传递；在各处理阶段结束后，按实际消耗的时间扣减TTL，并判断剩余值。若剩余TTL仍然大于0，则将这个新TTL作为后续阶段的TTL继续传递；否则，立即在此位置结束并返回。

虽然自愈机制已经将雪崩风险降至非常低的水平，但我们仍然为极其罕见的雪崩场景设计了多维度的秒级干预系统。

第一个维度是跨数据中心流量切换。我们实时监控多个敏感指标，当发生异常时，全局流量控制器在一秒内将流量从受影响的IDC迁移到其他IDC。

第二个维度是系统流量降级。流量分为不同等级，非用户流量（缓存刷新、预取等）按层级逐步减少直至关闭，为更高价值的用户请求让路。

第三个维度是架构裁剪。服务被分为不同级别（L2：低价值召回，L1：精确排序，L0：核心召回）。当损失发生时，我们做出秒级决策并按优先级逐步关闭服务级别。

第四个维度是超时套餐切换。多套系统级超时套餐根据损害程度自动适配，在吞吐和质量之间精妙地平衡。

10 治理结果

最后总结一下我们在治理雪崩上的成果。几年前，雪崩给我们的系统带来了比较多的PV损失，经过以上深入分析和系统治理，近几年完全没发生过雪崩，并且也几乎没有雪崩引起的PV损失。

数据平台数据智能化入库

掘金专栏-百度Geek说

百度Geek说

2025年10月22日 09:55

本文系统阐述了以大语言模型为核心驱动力的“数据平台智能化入库”方案，构建了从模式识别到自动部署的智能代码闭环，实现数据接入效率与质量的双重飞跃。

百度APP日志处理框架升级之路

掘金专栏-百度Geek说

百度Geek说

2025年10月14日 15:20

面对百度APP日均数千亿PV、超百PB数据规模带来的巨大挑战，我们完成了数据仓库的系统性升级。本文详细阐述了通过"两步走"策略解决资源压力、处理延迟和架构瓶颈的全过程。

百度电商MultiAgent视频生成系统

掘金专栏-百度Geek说

百度Geek说

2025年9月30日 16:57

导读

随着人工智能技术的迅猛发展，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实时数仓架构升级

掘金专栏-百度Geek说

百度Geek说

2025年9月26日 15:53

导读

本文主要介绍基于流批一体建设的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格式数据的详细过程。

TMSinker算子（TM流式处理框架中输出算子）收到上游产出的proto数据后，首先将数据分成4份，每一份对应一个线程，
每个线程将自己负责的数据转成一个RecordBatch; 具体操作是解析Protobuf数据，将数据进行格式映射，构建一个Arrow Schema，填充到RecordBatch中，然后将4个RecordBatch合成一张Table。
使用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 MCP Server ：链接数据库和AI的直通桥

掘金专栏-百度Geek说

百度Geek说

2025年9月23日 14:32

导读

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/…

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协议生态的完善，这种数据智能范式将在金融风控、供应链优化、智能客服等复杂业务场景中展现出更大的价值潜力。

一文解码百度地图ETA

掘金专栏-百度Geek说

百度Geek说

2025年9月19日 11:54

你有没有这样的体验？导航说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%。同时，该模型还具备持续学习优化能力，每天都会结合最新观察到的真实拥堵情况自动更新模型参数。