工程实践 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 辅助工程化落地的读者，这篇文章提供了很强的可迁移经验和明确的边界条件。