工程实践 Grab Tech 2026/10/21
Grab 工程博客介绍其 Android/iOS 超级应用在每周发布和 AI 辅助编码导致变更量上升背景下维持稳定性的分层防御体系。文章按预防、发布门禁和响应三阶段组织：合并前用 Lint 自定义规则及单元、UI、E2E、QA 测试拦截；发布前通过 GEA 内测和自动崩溃工单形成一周质量门禁；上线时用分阶段放量和功能开关控制爆炸半径；生产后用实时监控、自动分诊、功能开关历史和 Crashlytics 导出 BigQuery 加自定义元数据诊断。结论强调 shift-left，越早发现崩溃成本越低，无法完全消除的崩溃应纳入监控与遏制基线。适用边界是大型移动应用、多团队周发布场景，具体工具和数据来自 Android，iOS 使用等价工具。
推荐收录，因为文章完整展示了从 Lint 规则、测试分层、GEA 内测、分阶段放量、功能开关到实时监控和自动分诊的稳定性工程闭环，并给出崩溃暂停发布、热修复后补 Lint 规则等可验证实践。适合移动端负责人、SRE/稳定性工程师和多团队发布管理者参考。其分层检查点设计和“越左越便宜”的取舍可迁移到其他大型客户端，但具体阈值和工具链依赖 Grab 规模，需结合自身发布节奏调整。
工程实践 Grab Tech 2026/10/13
文章提出一个利用 GrabMart 聚合交易数据进行疾病早期预警的早期概念，而非已部署系统。其思路是把符合规则的商品 SKU 映射到症状类别，按授权时间段和地理区域聚合购买量，再与季节/历史基线比较，生成 Early Outbreak Detection Index。候选统计方法包括季节时间序列模型和空间扫描统计，并建议用公共卫生数据回顾性评估敏感性、误报率、校准度、地理稳定性和季节性表现。隐私治理要求数据最小化、最小计数阈值、差分隐私、访问控制、留存限制和独立审查，且禁止个体健康推断、定向广告或保险决策。文章明确零售需求只是间接信号，受促销、天气、媒体、囤货和商品可得性影响，GrabMart 用户不具代表性，商品到症状映射也不确定，因此必须本地验证并保留专家解释权。
推荐收录，因为它把零售交易数据用于公共卫生异常检测的系统设计、统计验证和隐私治理边界讲得较完整，尤其是数据最小化、差分隐私、最小计数阈值、独立审查和验证指标，对数据工程、隐私工程和负责任数据应用的读者有参考价值。但文章仍处于早期概念阶段，无部署与实测结果，不能作为落地性能或有效性证据。
工程实践 Grab Tech 2026/10/05
Grab 介绍其自包含模拟器 sim-rs：它用历史订单和司机数据离线重放城市一天的调度，将订单、司机、行程和 tick 建成闭环，覆盖需求、供给、取消、批量分配与回收决策。模拟器支持可插拔阶段、可复现实验包和内置 A/B/n 实验，使策略比较更接近真实市场条件。作者再把 Agent 接入 autoresearch 循环，让模型提出、实现、测试并接受不可篡改的指标裁决，并用不可变核心数据、计算式判定、受限回滚和两级检查抑制 specification gaming。案例中循环发现批量订单回收规则，并在约 150 次实验里把两个调度热点分别加速约 10 倍和 24 倍，但四分之三尝试失败。边界是模拟器若偏离生产或行为模型过拟合，自动化只会更快产生错误答案。
推荐收录。文章给出真实工程系统的完整设计：自包含市场模拟器、可插拔调度组件、内置 A/B/n 实验，以及 Agent 驱动 autoresearch 的搜索、验证、回滚与防 specification gaming 机制，并以约 150 次实验、热点加速 10 倍/24 倍等数据佐证。适合做仿真平台、AI 工程化、调度优化或自动化科研的读者，可迁移其闭环实验与可信度维护思路；风险是模拟器保真度依赖行为模型，落地需持续校准。
工程实践 Grab Tech 2026/08/28
文章介绍 Grab 如何通过自动化数据生产问题（DPI）把数据可靠性变成可运营的工作流。DPI 生命周期分为分诊、诊断、解决三阶段：分诊用 Kinabalu 评估契约测试、去重并聚合告警；诊断借 Data Health API 把失败归因为上游、平台、作业或数据错误并路由负责人；解决由 Hugo 自动重试等恢复常规故障，高风险才升级人工。文中给出生产数据：86.9% 的 DPI 自动解决，95% 以上自动创建，自动处理 MTTR 比人工快 6 倍。架构强调诊断与执行解耦，并展望了数据可靠性对 AI Agent 的价值。
本文来自 Grab 工程团队，展示了数据可靠性运营的完整闭环：从契约测试、告警分类、根因定性到自动修复，并附有 86.9% 自动解决率、MTTR 6 倍改善等生产数据，证据充分。适合数据平台工程师、SRE 和数据架构师参考，其通过稳定 API 屏蔽平台差异、诊断与执行解耦的架构思路可迁移到其他数据基础设施。
工程实践 Grab Tech 2026/08/21
文章介绍Grab为账户经理构建AI助手Jarvis Pro的设计与评估实践。早期原型能生成流畅回答，但曾给出推销促销的错误建议，因为没发现商家暂停门店增多、履约下滑。为此团队确立'先路由，后回答'的核心原则：在生成前先对用户任务分类，将路由作为契约，决定上下文加载、指标目录、工具路径和护栏。内存被严格限制，先做内存检查再进入昂贵检索；指标冲突时先做来源与新鲜度核对，避免误归因于模型。离线评估中，351条提示词的路由匹配率为99.4%，501条答案质量用例中的聚焦子集得分从78.5升至91.0。作者强调这些只是离线发布就绪信号，不代表商业效果，并指出系统应先在每层证明理解，而非仅靠最终文本流畅。
推荐收录，因为它展示了一个真实的LLM应用工程案例：如何通过路由、内存检查和分层评估防止'流畅但有害'的AI回答。对构建对话式数据分析助手或企业AI产品的团队，文中的路由契约、指标核对和离线评估方法可直接迁移。风险在于离线指标高不代表业务结果好，读者需结合生产验证。
工程实践 Grab Tech 2026/08/12
文章介绍 Grab 内部构建的 AI 评估框架 Grab Bench，用于在 Grab 业务形态的生产任务上评估模型能力。作者首先指出公开榜单无法捕捉“看似合理实则错误”的失败模式，如 SQL 指标漂移、工具参数错误、证据引用过度和只通过表面测试的代码补丁。框架通过 YAML 配置、任务插件和行级记录，将 SQL 生成、工具调用、多模态判断、乘客画像推理和编码代理等任务纳入统一评估。设计上强调使用合成或脱敏数据保护生产隐私，采用确定性评分器与 LLM 评判结合，并设置反捷径基线、隐藏测试和认证集防止过拟合。文章最后总结失败分类比总分更重要，并指出合成评估不能直接证明生产收益，需结合线上证据。
推荐收录，因为文章展示了真实工程团队如何构建内部 AI 评估系统，从问题定义、任务契约设计、评分策略到数据安全和可复现性均有具体实现和边界讨论。对需要建立模型上线前评估、避免“看似正确”的失败模式或设计 eval harness 的工程师和团队具有直接参考价值，尤其是确定性评分、反作弊基线和失败分类的思路可迁移到多种 AI 产品场景。
工程实践 Grab Tech 2026/08/01
文章系统阐述了Grab如何将AI代理深度嵌入数据分析工作流，以实现智能民主化和分析师角色进化。作者提出五级自主性阶梯（L2 AI辅助到L5端到端自主），定义了执行、知识、控制、审查和学习五大核心能力，并展示了Spartan、Scarlet、ContextIQ、BriX等实际系统的架构与效果。通过Slack中的自然语言分析、自愈数据管道、上下文生命周期管理和分析师自建工具门户，Grab将机械性工单占比从44%降至30%，周期时间缩短约33%，自助分析率大幅提升。文章强调自治不消除问责，人类始终负责问题框架、指标定义和业务决策。该实践适用于具备可认证指标和持续上下文投入的大型数据工程环境，但对团队协作和执行力的要求较高，非轻量级方案。
推荐收录。本文不是简单工具介绍，而是一份完整的工程案例，包含明确的自主性分级、核心能力拆解和可度量的业务影响，展示了从实验到规模化落地的真实路径。对关注数据工程智能化、分析师角色转型或AI工程化的读者极具参考价值，所提出的阶梯框架和上下文治理模式可迁移至其他数据分析密集型组织。
工程实践 Grab Tech 2026/07/30
文章提出了一种基于用户反馈的知识图谱关系验证框架，用于在快速变化的领域（如外卖菜单）中检测和消除自动化构建所产生的错误关系。核心方法是将图谱边分为已验证和候选两类，通过搜索界面以探索与利用策略注入候选边，并采集点击、购买等加权交互信号，计算置信度分数来自动推广或剪枝边。该闭环系统无需人工干预，利用众包隐式反馈大规模纠正AI幻觉，并在食品配送场景中验证了其有效性。适用边界包括依赖充足用户流量的动态目录搜索，且需要精细控制注入以避免影响体验。
收录理由：文章详细描述了一个将搜索界面作为验证环境的工程方案，包含假设生成、候选注入、信号聚合和图更新等完整模块设计，并通过加权交互信号和置信度阈值实现自动图结构演化。对负责搜索系统、知识图谱构建或数据工程团队具有直接参考价值，其探索-利用设计和无人工干预的规模化验证思路具备可迁移性。
工程实践 Grab Tech 2026/07/24
本文是 Grab 工程团队分享的 AI 代理平台化实践系列第一部分。文章从内部技术基础设施支持机器人出发，详细复盘了从单体代理到框架 LLM-Kit 的演化过程。作者指出了早期代理在规模化时的典型痛点：缺乏可评估性、模型/供应商切换困难、可观测性不足、以及非核心的工程脚手架大量重复。为此，团队从机器人中提取出共享能力，构建了统一的应用模板，预置了认证、密钥、配置、gRPC通信、快速API、OpenTelemetry全链路追踪、评估端点等生产就绪部件，并通过统一的模型网关和远程MCP框架解耦工具与代理。文章强调框架而非平台的策略选择，允许团队在标准化的基础上自由迭代。当前方案已支撑500+代理、50+MCP服务器，每月处理数十亿token。内容适合负责AI代理基础设施、平台工程或需要将LLM原型落地生产的工程师研读，其问题驱动、层层抽象的思路对类似工作有直接迁移价值。
本文为真实的工程平台化案例，详细展示了从单点代理到可复用框架的演进逻辑、具体架构设计及生产落地要点，如统一模型网关、内建评估、全链路追踪和工具协议化。适合期望将AI代理从Demo推向企业级服务的工程团队借鉴，文中的问题分解、基础设施抽象和框架定位具有高可迁移性，能帮助读者减少从0到1的试错成本。
工程实践 Grab Tech 2026/07/10
文章详细介绍了 Grab 从 Hive Parquet 向 Apache Iceberg 迁移数据湖的完整工程实践。首先分析了原始架构在目录延迟、小文件碎片、运维负担和信息一致性上的瓶颈，然后说明了选择 Iceberg 的决策依据。迁移采用按表优先级逐步推进的策略，在导航数据集上通过 Z-ordering 获得约 10 倍查询性能提升，并在运营表上节省了 95% 的 S3 API 成本。为应对 Iceberg、Delta、Hudi 等多格式共存的开发体验问题，团队自研并开源了 UnifiedSparkCatalog，透明路由不同表格式操作。文中还分享了 Hive 锁竞争、时间戳兼容性、存储层级成本等实际坑位和解决方案。案例适合大型数据平台的可扩展存储架构改造，迁移策略和工具设计具有较高的可迁移性。
本文提供了从中型数据湖到现代表格式转型的完整路线图，包含明确的性能与成本量化证据、自研工具的架构取舍和开源发布，以及生产环境踩坑经验。适合数据平台工程师和架构师参考，尤其对计划从 Hive 迁往 Iceberg、需要多格式兼容的团队有直接借鉴价值。
工程实践 Grab Tech 2026/07/03
文章复盘了 Grab 将 Counter Service 从宽表数据库迁移到 Aerospike 的全过程，核心不是简单换存储，而是先重构读写分层，再按访问模式重新设计数据模型。读路径上，作者把存储访问从业务逻辑中抽出，采用带枚举分发的 facade，并通过 shadow read、split traffic 和配置切换实现无停机、可回滚迁移。写路径上，团队尝试了按桶存行、Secondary Index 和 BatchGet，最终选择“单 counter 单记录 + 有序 map”的结构，用原子 MapIncrement 和显式清理旧桶来降低索引和磁盘占用。文中还记录了 Rust 客户端不成熟、DNS 解析和 NVMe 索引实验带来的问题与回退原因。最终系统在读延迟、成本和存储 footprint 上都有明显收益，但这些收益主要来自 schema 与架构重构，而非数据库替换本身。
推荐收录，因为文章给出了迁移前后的存储分层、影子流量、逐步切流、数据建模和回退验证等完整证据，而不是泛泛谈“换数据库”。适合做存储迁移、在线系统无停机改造和性能/成本权衡的参考，尤其对需要处理高 QPS 计数服务的工程师有直接迁移价值。
工程实践 Grab Tech 2026/06/22
这篇文章讲的是 Grab 如何在大规模服务体系中推进 Distroless 镜像迁移，并把“先补齐可验证的 medium tests，再批量改 Dockerfile”的方法自动化。文章重点不是单纯介绍 Distroless，而是详细说明了为什么迁移会因运行时依赖缺失而失败、如何用分层测试建立安全网，以及如何借助 AI agent、MCP、脚本技能和人类审核把原本高度重复的迁移与修复工作规模化。
作者还给出了一个可执行的 patch-test-compare 流程：先基线化已有测试结果，再检测 Dockerfile 中的系统包依赖，按需生成多阶段构建或直接切换基础镜像，最后用同一套 medium tests 验证是否引入回归。它的结论是，AI 更适合承担“明确目标、可判定成功、但流程繁琐”的工程迁移任务，但前提是要有严格 guardrails、分批反馈和人工最终把关。
推荐收录，因为文章把一个真实的大规模安全迁移问题拆解成了可复用的测试、自动化和人机协作流程，而不是停留在“用了 AI 提效”的宣传层面。对于做平台工程、DevOps、安全基线治理或 AI 辅助工程化落地的读者，这篇文章提供了很强的可迁移经验和明确的边界条件。