# 构建 Agentic 的可信查询链路 > **合规声明（生成式 AI 服务）**：前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。 > > **完整资料：如果想了解更多内容可以访问:https://events.amazoncloud.cn/china-summit-on-demand/ > > **免责声明**：本摘要仅为便于您了解峰会内容而提供，我们不对其完整性及准确性作出任何保证，且不构成任何建议或结论。相关内容仅供参考，实际内容以峰会回放视频为准。 ## 一、基础信息 - **会议类型**：专题演讲 - **Persona**：Agent 构建者 - **时间信息**：6月23日 | 14:00 - 14:30 - **标题**：构建 Agentic 的可信查询链路 - **PDF 资料**：有 - **视频回放**：有 ## 演讲人信息 ### 会议信息 - **地点**：上海世博中心（2026 亚马逊云科技中国峰会） - **日期**：2026年6月23日（Day 1） - **时间**：14:00 - 14:30 - **会议类型**：专题演讲 - **面向 Persona**：Agent 构建者 ### 亚马逊云科技演讲人 - **王维超**：解决方案架构师 ### 客户 / 合作伙伴演讲人 - **付德义**（斯堪尼亚制造（中国）有限公司）：基础架构与平台服务负责人 ## 二、会议资料 PDF 转录内容 --- Page 1 --- 2 0 2 6 6 2 3 - 2 4 · 年 月 日 日 上 海 世 博 中 心 --- Page 2 --- Agentic 构建 可信查询链路 付德义 王维超 Data & AI 基础架构与云平台赋能负责人（） 解决方案架构师 斯堪尼亚制造（中国）有限公司 亚马逊云科技 --- Page 3 --- Agenda ① 可信的起点：在亚马逊云科技上建好的数据底座 议程 Agent ② 结构化的可信查询：从数据湖仓到 数据查询的工程实践 RAG GraphRAG ③ 非结构化的可信查询：通用 与 的工程实践 ④ 可信查询链路：把结构化与非结构化收进同一范式 --- Page 4 --- Scania — 1891 2025 从瑞典 到 的如皋 Scania 1891 TRATON ， 年创立于瑞典， 集团旗下全球重型商用车头部品牌。 2025 2.0 —— 年如皋工业枢纽落成，中国战略 启动 今天的分享，发生在这个底色之上。 Scania （全球） 1891 · Sweden 100+ Heavy / Bus / Engines 国家 Södertälje · TRATON · · · / 总部 集团旗下 业务覆盖 全球商用车头部品牌 重型卡车 客车 工业 海事发动机 Scania 2.0 中国 （中国战略） Rugao 2025 Super Trucks Sustainable · + + · 如皋工业枢纽落成 制造 研发 供应 首批本地化生产 下线交付 面向中国市场的可持续运输方案 链 售后 --- Page 5 --- ① 可信的起点 在亚马逊云科技上建好的数据底座 --- Page 6 --- — 30+ 生产现场的数据 从订单到交付穿越 系统 ① 可信的起点 Scania 一辆 卡车从订单到下线，要穿越多套业务系统。 —— 数据湖建立之前，这些数据物理隔离 跨系统分析靠人工取数。 CRM DMS ERP MES MES SCADA QMS TMS Order Plan Procure Stamp/Weld Paint Assembly QA / Test Logistics Delivery Order DB APS SRM/PLM WMS Paint Sys. Andon LIMS Dealer Net · MES · SCADA · QA · ERP · SCRM · CRM · Dealer Net … —— 多系统 每一段都是数据，曾经也都是数据孤岛。 --- Page 7 --- —— 可信数据基座 亚马逊云科技中国区端到端架构 ① 可信的起点 / / / / / 六层云原生架构：摄取 存储 处理 治理 服务 可观测。 Governance · Lake Formation · Glue Data Catalog · IAM On-Prem Ingestion Storage (S3 + Iceberg) Processing (Spark on EKS) Serving Source DBs Database Migration Service Landing Zone Engine Snowflake (Consumer) (DMS) S3 · · Spark on EKS · Airflow on EKS External DB / Iceberg · · ME 短期落地 生命周期清理 只读 零拷贝 CDC + Full Load · Multi-AZ · Secrets S · ERP · SCADA · QMS · CRM · SCRM … Manager 30+ 系统 DBImport History Zone CDC Streaming / Batch Event-driven Refresh External Files Spark on EKS + MariaDB cfg · Airflow S3 + Iceberg · INSERT-only · + · Synch + Merge SNS → SQS → Lambda · ALTER DAG 全量血缘 近实时 小时级 ICEBERG TABLE REFRESH / (SMB) 供应商 合作伙伴文件 File Drop Raw Zone Full Load (DB / File) BI · Agent NiFi → IAM → Lambda S3 + Iceberg · MERGE / Upsert / / · MERGE / Replace Snowflake 跨账户 服务 天 周 月 下游统一从 消费数据底座 --- Page 8 --- — 可信数据基座 把「可信」作为底座的工程承诺 ① 可信的起点 Agent 在数据湖之上做 之前，先回答一个更早的问题：这个数据底座本身值不值得被业务、被 信任。 数据可追溯 凭证零泄漏 Iceberg Zone Landing · History INSERT- GitLab Secret Manager Repo + IAC Repo 三： 落地 全变更（双仓职责分离；秘密永 only · Raw Git Secrets Manager ） 业务可查询。任意指标都能时间旅行回放，异常 不入，仅写入。 能被复现。 - + SLA 元数据统一 细粒度治理 全链路可观测 多档 Glue Data Catalog Zone Lake Formation Spark / Airflow / Glue Observability 是所有 的唯一真相源； 任务全链路指标进入自研 / FGAC API SLA 提供列 行级 与跨账户授权。；近实时到天级多档 由四种处理模式覆盖。 —— Agent 这四件事都是「不做就没法上 」的工程前提。可信查询，从可信数据基座开始。 --- Page 9 --- ② Agent 为 提供结构化的可信查询 VQR 用语义层和 为模型划定边界 --- Page 10 --- Agent — AI 为 做好准备 我们在 问数场景里 看到了什么 ② 结构化的可信查询 Agent 底座建好之后，下一步是为 打好可靠的查询底座。 → SQL —— 系统化地验证了「自然语言 」 我们看到了三件事。 / ≠ 选错表 用错口径 业务黑话猜不对 答得对 答得快 POC BOMs —— POC PP4.1 —— ReAct + Agent 8-20 里的真实错误：业务问「 缺件」 真实错误：业务问「 的数据」 多轮反思的 单次 秒， BOM_V + EPO_STATUS = 'R' PP4.1 = '2023041' Token —— 模型选了 表； 模型完全不知道； 成本随调用量飙升 COMP_BOM_RESULT_V + BOM Agent 正确口径是 缺件」在用户的口径里是 对比的 但更重要的是：业务对 的第一印象只 COMPARE_*=Mismatch Mismatch 。 有一次。 Agent 这不是模型不行，是模型不知道业务口径。 不是模型不行，是模型缺一份业务字典。 准确度，是 能进生产的前提。 --- Page 11 --- NL2SQL 纯 错在哪，对的样子是什么 ② 结构化的可信查询 2026 BOMs 10 工程师真实问句：「 年一月份第三批 中，缺件多少，前 的缺件有哪些。」 —— —— 左边是模型自由生成 选错表、错口径；右边是语义层治理后 模型只填槽位。 NL2SQL ( ) （） 裸 错 语义层治理后 对 SELECT PART_NUMBER, SELECT PART_NUMBER, COUNT(*) AS BOM_COUNT COUNT(*) AS BOM_COUNT FROM SYS_PNL_P_MONA_CHA_BOM_V FROM SYS_PNL_P_MONA_CHA_COMP_BOM_RESULT_V WHERE PART_PERIOD = '202601' WHERE PART_PERIOD = '2026013' AND EPO_STATUS = 'R' AND ( COMPARE_SEU_SAS = 'Mismatch' GROUP BY PART_NUMBER OR COMPARE_MONA_SAS = 'Mismatch') ORDER BY BOM_COUNT DESC GROUP BY PART_NUMBER LIMIT 10; ORDER BY BOM_COUNT DESC LIMIT 10; ✗ —— BOM_V COMP_BOM_RESULT_V = COMPARE_* = 'Mismatch' 选错表 「缺件」不在，在 ✓「缺件」 （业务口径登记） ✗ EPO_STATUS = 'R' —— PART_PERIOD '2026013' 把「缺件」当成 业务口径错 ✓ 格式 （字段值口径治理） ✗ ≠ '202601' —— '2026013' BOMs / → COMP_BOM_RESULT_V 「一月第三批」 真实编码是 ✓表别名「 缺件」 （同义词） ✗ LLM 错得理直气壮，业务一眼看不出来 ✓ 只填槽位，剩下都是确定性的编译 --- Page 12 --- — SQL 语义层 把业务口径编译成确定性 模板 · ② 结构化的可信查询 语义层 SQL 语义层是可信度的真正来源。把业务口径显式登记成参数化 模板。 LLM —— POC 90% 只识别口径并填槽位 通过率 以上。 编译流程 语义层做了什么 —— missed PP4.1 · 业务术语字典 「 」「缺件」「 」 SQL 自然语言问题 槽位识别 口径登记表 最终 这种业务黑话被显式登记 zone=' ' in_production_ SELECT COUNT(*) / —— 「华南本月 华南 period=' ' count ... WHERE · 表 列同义词 把业务实体映射到 在产订单」 本月 status=in_prod (zone, period) zone_name=:zone 具体表与字段（不靠概率） → AND status IN —— PART_PERIOD 2026 1 参数化模板 （：codes） · 字段值口径 的「 年 月 = '2026013' 第三批」格式编码 —— · 模板与提示词规则 转义、输出语言、 多意图拆分等编译期规则 —— owner · 治理对象，不是一次建模 每条口径有、 有版本、有复核流程 --- Page 13 --- — 语义层是怎么炼成的 真实优化矩阵 · ② 结构化的可信查询 语义层是怎么炼成的 POC —— 是一个工程闭环 每个失败用例对应一次明确动作，立即跑回归。 20 8 —— 0 95% 下表是个用例归纳出的 种优化策略 语义层就是这样从 走到 的。 错误类型 优化策略 真实例子 · BOMs / → SYS_PNL_P_MONA_CHA_COMP_BOM_RESULT_V 表识别错 修改语义模型 增加表同义词 「 缺件」 · GROUP_ID vs POPID 列名识别错 修改语义模型 增加列同义词 （车标识列） · missed / = COMPARE_*='Mismatch' EPO_STATUS='R' 业务术语错 修改提示词 增加业务字典 「 缺件」，不是 · PART_PERIOD '2026 ' → '2026013' '202601' 字段值格式错 修改提示词 解释字段格式口径： 年一月第三批，不是 · SQL ''xxx'' vs 'xxx' 转义词错误 修改提示词 增加值约束 单引号转义（） · Insight / 输出语言错 修改提示词 增加语言约束 文字结论的输出语言（中 英） · PP4.1 PP4.1 = '2023041' 多意图理解错 修改提示词 增加问题拆分规则 「 的数据」需要先拆出 · → 功能性缺失 修改代码 增加文件下载等功能 「以表格形式返回」 生成下载链接 POC LLM+ 8 → 20 19 = 95% Agent_chat 92.3% · Insight 100% · 100% 结果： 种优化策略治理过的语义层 用例 通过 通过率（多轮对话） --- Page 14 --- VQR — 当语义层成熟，自然延伸出的工程问题 · VQR ② 结构化的可信查询 —— SQL 高频问题是有限的、重复的 每次都让模型重新生成，本质是浪费。 VQR SQL VQR 把已被业务验证的问答整条沉淀为资产：语义层管「对的 」， 管「确认过的问答」。 LLM 自由度的逐步收紧 NL2SQL — 100% 推进的方向 裸 自由 • question + + SQL + + 数据模型： 同义改写 参数化 命中口径 owner + 验证记录 • + - — 入库门槛：业务负责人复核 离线回归通过 语义层 模型只填槽位 • + Top-K → 运行时：语义检索（向量 关键词）召回 命中即直出 - VQR — 高频问题不再生成 • POC 2/2 = 100% 多轮对话已在 验证（）：上下文中的口径与槽 VQR ↓ 位一致性，是 的天然延伸 从「自由生成」逐步降级到「填槽位」再到「直接命中」 • → VQR 与语义层联动：模板更新 受影响的 资产自动失效 --- Page 15 --- ③ Agent 为 提供非结构化的可信查询 RAG GraphRAG 通用 与 的工程实践 --- Page 16 --- Scania — 中国的非结构化数据 跨业务域覆盖 ③ 非结构化的可信查询 Scania General IT HR 中国 横向赋能各业务部门，沉淀了制造、研发、供应链、法务等多类核心技术与业务文档。 让各部门员工用自然语言问到具体段落、表格或步骤，是一个跨业务域的真实生产需求。 · 文档类型 跨业务域覆盖 我们的目标 · SOP · 制造与质量 维修与服务手册 工艺 质量规范 · 各部门员工用自然语言提问 · / · 研发与产品 设计文档 标准 规范 测试报告 / / · · · 答复定位到具体段落 表格 步骤 供应链与采购 采购规则 合同模板 供应商规格书 · · 人力资源 员工手册 培训资料 流程指引 · 答复带可引用证据，不是一段总结 · · 法务与合规 政策文件 内控规范 合规手册 · IT · · 跨文档版本一致 跨部门复用 与信息安全 系统使用手册 信息安全规范 --- Page 17 --- RAG 通用 的工程深度 Agent ③ 非结构化的可信查询，为 提供确定性问答 我们把「日常问答能进生产」做成了五层工程化的能力。 高保真文档解析 切片策略优化 业务术语字典 ① / / ② / / / ③ AP / EOL / MP / 保留表格 公式 图 多粒度分块（段落 章节 表格行 图 「 —— —— SOP / NPI / FOB / 注的层级结构 注），元数据丰富 终端用户不用 MPN …… 维修手册的零部件位 懂分块，由平台默认治理。 」业务黑 BOM —— 号图、整车 表 话被显式登记 能完整召回。 模型不再靠概率猜 术语。 多源知识统一接入 工程化运营 ④ SharePoint + ⑤ · —— - Am （a 文 zo 档 n 库 S3 + 一 Stu 套 d 引 io 擎 3 多 0+ 个 应用 站点） Workflo 内 w / Ag 个 ent / 第 Dif 三 y 方系统 E 统 nt 一 ra 在 ID Chatbot Daily 知识库； Report / 在跑（/ Service 认证、自动化同步。 Chatbot / 翻 H 译 R … ）。 给各部门一个「统一的、可治理的文档智能入口」。 --- Page 18 --- Agent 把传统系统聚合到 时代的统一入口 ③ 非结构化的可信查询 SharePoint …… 工厂里的文档与系统是历史沉淀的：、文件服务器、各部门自建系统、共享盘 RAG —— 通用 把这些来源统一接到一个对话入口 用户不用再「先想去哪查」，直接用自然语言问。 IT Agent 这是把传统 资产，无侵入地升级到 时代的工程方式。 之前 之后 工程价值 · 用户要先记住「这个问题去哪个系统查」 · 一个对话入口，跨业务域、跨系统、跨格式 · 不替换传统系统，而是叠一层智能入口 SharePoint / S3 / IT Agent · 跨系统切换、跨格式复制粘贴 · 第三方系统 统一接入 · 传统 资产无侵入纳入 时代 Agent · 同一问题，不同人问出不同答案 · 答复带可引用证据，可一键回到原文 · 同一底座，未来支持更多 应用 General IT · 文档版本散落，无法追溯 · 各部门员工直接用自然语言问 · 的赋能能力可被复用、可治理 IT Agent 在 时代的新角色：把传统系统聚合起来，提供可信的、跨域的查询入口。 --- Page 19 --- GraphRAG — 非结构化数据的「确定性查询」 · GraphRAG ③ 非结构化的可信查询 —— Top-K 故障诊断是多跳问题 相似不等于相关，全库 反而稀释信号。 —— 把技术规范或用户手册抽成本体图谱，向量检索只在图谱框定的子集内进行 召回路径，被图谱约束。 本体图谱（示意） 召回链路 失效模式 1。 —— / 部件 实体识别 从问句中识别故障现象 部件 子系统 2. —— 2-3 hop 失效模式 图谱推理 在 内找出合理的故障路径 故障现象 部件 维修步骤 子系统 3. —— 路径绑定文档 路径上的节点关联到维修手册段落 失效模式 部件 4。 —— 子系统 向量检索 只在路径关联的文档子集内做相似检索 失效模式 5. LLM —— + 推理 仅在「图路径 命中段落」上回答 —— 2-3 hop 红色路径示意一次 的图谱召回路径 --- Page 20 --- ④ 可信查询链路 把结构化与非结构化收进同一范式 --- Page 21 --- — 可信查询链路 三步推进，一种工程哲学 ④ 可信查询链路 —— LLM 可信查询链路 通过工程资产，逐步收紧 的自由度。 - VQR —— 结构化用语义层；非结构化用图谱约束召回路径 三件事，同一范式。 P1 · P2 · VQR P3 · Graph 语义层 锁住业务口径 沉淀已验证问答 约束召回路径 把「在产订单」「关键件」等业务术语显式登记成参 把已被业务确认的问答整条沉淀为资产；运行时同义 构建本体图谱，向量检索只在图谱框定的子集内进行。 SQL SQL 数化 模板。 匹配命中即直出。 LLM 失去「全库自由联想」的自由度，只在确定子集内 LLM JOIN LLM —— 失去了写 与过滤逻辑的自由度，只识别口 在高频问题上失去「重新思考」的自由度 它 推理。 径并填槽位。 不再生成。 —— / LLM 共同范式 先把召回 编译路径变成确定性的，再让 在确定空间里完成最后一步。 --- Page 22 --- 可复用的工程经验 ④ 可信查询链路 三条可以复用的场景工程判断。 01 LLM 02 ≈ · 03 给 划边界 结构化 非结构化 跨域同构 可信链路从可信底座开始 LLM Text→SQL RAG Agent — 可信查询的本质，是把 从「生成」降级到 和 的工程哲学是同一个：先把 进生产的前提，是数据本身就是可信的 / — SLA 「在确定空间里推理」。 召回 编译路径变成确定性的， 可追溯、可治理、可观测、有。 VQR Graph —— Agent 语义层、 都不是新组件 它们是 再让模型在确定空间里完成最后一步。 没有可信的数据基座，再好的 工程也站不 LLM 给 划边界的三种工程方式。 住脚。 Mona + RND 已在 制造端 研发端两个业务域同时 —— 跑通 同一套范式，跨域复用。 LLM + 95% (19/20) —— 语义层治理，自然语言查询通过率 仍在共同推进可信查询链路的演进。 --- Page 23 --- Agent 「让 答得对， 一半靠模型， 一半靠工程把它收进确定空间。」 --- Page 24 --- Thank You · Q & A —— Agent 感谢倾听 期待与你们一起把 推进生产 --- Page 25 --- 扫描上方二维码 填写调查问卷 ## 三、会议回放视频转录内容 各位同学下午好 我是付德义 来自斯堪尼亚 然后今天是我们要带来的演讲课题 就是 构建 Agentic 的可信查询链路 OK 我知道在现在这个阶段 大家创建很多的 Agent 已经是非常的方便了 比如说可以通过各种的方式 高代码的方式 低代码的方式 或者是自然语言的方式 等等很快的 快速的创建一个 Agent 不知道各位同仁感觉 什么是一个你们的业务 比较喜欢的 Agent 但从我的角度来讲 创建 Agent 很容易 但是创建一个让大家信赖的 就具备可信度查询数据的 一个 Agent 是很难的 因此在过去的一到两年时间 我们就主要地进行了 这方面的探索 OK 抱歉说错了 OK 所以这个是今天我们的议程 我们总共分四点来进行分享 我们看一下 主要每一个点 我们都冠以可信 一是为可信的数据基础平台 和第二个是可信的 结构化数据的查询 第三个可信的 非结构化数据查询 第四个就是 可信的查询链路 把结构化和非结构化数据 进行统一的范式 然后将由我来进行前两 部分的分享 后两部分由 亚马逊云科技的王维超老师来进行 OK OK 在正式分享之前 请允许我介绍一下我们公司 我们叫斯堪尼亚 是一家北欧的 世界头部的 商用车卡车的制造公司 目前隶属于大众汽车集团 商用车集团 TRATON 英文名叫 TRATON 集团下面 OK 我们是1891年 创建于瑞典 北欧瑞典 目前我们于去年在中国正式建成 中国的正式生产基地 如皋工厂 已经开始投产 并正式的进入 SOP 阶段 然后我们的 我本人自身是负责 公司的很多的平台 包括 AI 平台 云计算平台 数据平台等等 OK 那么 AI 在这个时代 也是被我们的最高管理层 寄予了厚望 也就是期望有一天 我们能带着很多中国的 比较好的场景 把它带回到欧洲 能让他们甚至是 复用我们的场景和解决方案 OK 可信的起点 第一步 就是要建立一个 可信的数据的平台 我们经常讲 数据就是 AI 的最大 如果是一个垃圾数据 就是 Garbage In Garbage Out 所以这种数据不好 AI 一切都是白搭 那我们看以前的架构里 在我们一个生产制造的企业 从一辆卡车到 客户下单 到它的计划排产 再通过物流 Deliver 给最终的用户 总共是需要这么多的系统 在以前的工作方式中 每一个后置节点 如果想了解前置的很多信息 我们需要单独的去查询 每一个系统 然后去整合这些数据 OK 所以说每一段数据 都是一个数据孤岛 一个 Data Silo 那么我们一开始做 想把数据做好 整合成一个 Centralized 的数据 并不是因为想 把它应用于 AI 领域 其实我们最朴素的需求 就是要有一个 核心的数据管理平台 能够让所有的员工 能消费一个统一的数据接口 能够消费整体的数据 OK 那我们觉得 要做一个比较稳妥的 夯实的数据平台 我们看一下 我们在亚马逊云科技上 总共做了哪些工作 我们用了哪些工具 我们首先要把 各种不同的源数据 On-Premise 的也好 Data Center 的 还有运行在我们亚马逊云科技 中国区的数据 甚至于 Global 的数据 各种形式的数据 我们要想办法 把它统一的接管过来 用各种的技术 然后 把它注入到 亚马逊云科技的 以 Iceberg 的形式 注册到 S3 表里 然后用 EKS 的 Spark 来处理数据 最终处理完的数据 存储在数据仓 也是 Host 在 亚马逊云科技的 Snowflake 来进行用户的 统一的消费接口 我们看到 要想把一个 合理的数据平台做好 要做好三件事情 第一件事情 就是要把所有的源数据 无论它是什么样的形式 存储在哪里 都要能接得准 接得稳 稳定地运行在我们的 湖仓里 第二点就是数据要被治理 所有的可变更的数据 都要能被审计 这对于我们 一个制造业企业 是极其重要的 因为任何一个业务节点 它想查询到的 该节点的数据 都要被要求有追溯性 无论在质量上 在合规上 都是有这样的要求 最后一点 就是要有一个统一的 数据源接口 未来 无论你是用 Power BI 来消费这个数据 甚至于用 AI 来消费这个数据 我们都通过一个统一的数仓 来保证数据的一致性 OK 在技术上解决了 这个数据湖仓查询之后 我们仍然要保证 一些数据的安全性 合规性 在此之后 我们才能考虑正式的引入 AI Agent 那么 我们看到 我们做好了这 4 点 就是要我 第一点是我刚才提到的 数据要有可追溯性 我们在 在亚马逊云科技上分了三个区域 数据 Landing 区 History 区 History Zone 可以全变更被审计的区域 然后业务可以查询的区域 任意的指标 都能随着时间旅行回放 任何的异常都能被发现 在此之后 我们来看 凭证的管理 也就是说在 在我们的亚马逊云科技上的分层中 我们是用的 GitLab Repo 加 IaC Repo 的双仓隔离 所有的秘密 是永久不会写入到我们的仓库里的 只会写入到 Secrets Manager 第三点就是源数据的统一 我们用 Glue Data Catalog 是所有的 所有区域的唯一真相源 确保用户只能消费 或只能读到被分配的数据权限 我们是精准到每一个字段的 OK 这样也能保证在未来 Agent 它被引入之后 它也在一个最可控的权限范围内 去读取数据 不会发生让它越权去读取数据的问题 最后一点就是一个全链路的观测 加多档的 SLA 制定 我们通过 Spark Airflow、Glue 等这些工具 能保证任务是全链路的 接入到我们自研的 Observability 的 API 里面 然后可以近实时的分配权限 也可以天级的分配 各种 SLA 权限供用户去选择 OK 那做好了技术架构 做好了合规和安全架构之后 我们才正式的引入了 Agent 来消费我们的数据 那就是我们第二点 就是为 Agent 提供结构化的可信查询 这里面我会重点介绍两个 能让它查得准且提效的关键词 一个就是语义层 一个就是 VQR OK 所以在我们刚才提到的数据底座 搭建好之后 我们开始进行了自然语言 搜索的这样的一个操作 我们发现 如果自然语言搜索 我们经常会发现有最主要的三大难题 是在这里 第一个是会选错表 或用错口径 就是直接通过自然语言 去问一个数据库 一个数据仓 它数据直接 它连它给它的表都直接选错了 第二点就是 它对我们的业务黑话它不理解 比如说这里面 我们有真实的案例 就是业务会问 PP4.1 的数据 然后模型完全不知道 PP4.1 代表着什么 实际上这是我们内部管理的 一个周期性的语言 它对应的是2023041 OK 所以这也不是模型不行 是模型缺乏一份业务的内部的字典 OK 第三点就是一个业务的耐心 和业务配合程度的问题 我们 ReAct 加多轮反思的 Agent 单次回复的时间 大概是在8 到 20 秒 会有一定的 Token 的消耗 如果是在有具备一定的 Token 消耗的基础上 首先会有一定的 Cost 的 和消耗一定的用户的耐心 但是在这种情况下 如果我们给出的查数很不准 让业务觉得大模型是在胡说八道 那么可能一次两次之后 它就完全失去耐心了 OK 所以这是我们经常看到的三个问题 来 我们来分享一个真实的用户案例 这里面是我们的 我列举了一句话 大家可以看一下 这就是非常朴素的一个 生产制造的工程师 会经常问到的一个 问到的一句话 就是在2026 年 1 月份第三批 BOMs 中缺件多少 前 10 的缺件有哪些 我们看一下 没被工程化治理过的 和被工程化治理过的这种查数 会主要有哪些差异 首先看左边是一个错误的案例 首先它会选错表 然后它会把缺件当成一个错误的业务口径 第三点它把周期也选错了 那么在被语义层治理过后 我们发现 它选对了表 缺件是 COMPARE_* = 'Mismatch' 然后 PART_PERIOD 格式是 2026013 然后第三点 在同义词的选择上表别名 缺件等于 COMPARE_BOM_RESULT 最后我们把大模型限制在它只填槽位 而不去管其他的任务 这样剩下的都是确定性的可编译的 所以通过这个对比大家可以看出来 一个被工程化治理过的问数 明显是要准确的多 OK 我们来看一下语义层 通过上面的分析 我们可以下这样一个结论 就是语义层实际上是可信度的一个真正来源 我们再看这个案例 如果通过一个夯实的语义层治理 我们用户继续去问华南本月在产订单 那么首先大模型就直接经过我们的语义层来识别槽位 区域在华南 周期在本月 Status 是 in_production 口径登记表也选对了 最终形成的一个 SQL 就是一个对的准确的 SQL 能 target 到最根本的数据的 SQL 中去 OK 所以我们看 通过语义层的制定 能生成最准确的 SQL 是能找到最终 BI 问数准确的一个终极答案 OK 所以右边这个框 大家可以看一下 我就不再赘述 需要重点强调的是 语义层它是一个治理对象 而不是一次建模 每条口径都有 Owner 有版本 有复核流程 OK 好的 那么我们看一下语义层的真实产生过程 这也是我们这么多 这两年踩过的坑 我们总结出来的好多语义层 怎么被从零打磨到95% 的 这里要强调一下 语义层不是一个静态的一个组件 实际上是一套合理的工程闭环 就是我们想通过语义层这套方法论 无论我们有任何的失败用例 都能被语义层的持续治理给消化掉 OK 我们发现治理好一个语义层 主要围绕这八大部分去进行治理 首先包括表的识别错 然后包括列的列名识别错 业务术语错 字段值的格式错误 同义词的错误 输出的语言错误 多意图的理解错误和功能性的缺失 OK 最后 介绍刚才提到的 我还想再介绍一下 第二个概念叫 VQR 也就是我们在语义层 已经被合理的治理好之后 我们能达到了问数很准确了 但是我们为什么要加到 VQR 的概念呢 VQR 的全称叫 Validated Query Repository 一个已经被验证过的查询仓库 好 我们来看一下 下方左图是我们不断收缩大模型的发挥空间 来实现的优化过程 从最上面的 我们直接让一个大模型 去进行数据仓的问数 到我们中间加入了语义层治理 让问数变得准确 再到我们加了一个可验证的 VQR 之后 让语义层能够对已经 让大模型对已经验证准确的这些数据 进行一个归档和记忆 以后任何的相关的问题的验证 它首先去问 它去查询 VQR 这样能减少很多 Token 的消耗 并且增加问询的效率 OK 所以语义层总结下来是 管理是否能生成对的 SQL 能给你准确的查数 那么 VQR 是管的 确认过的答案的一个存储 能够提效 能够降本 OK 那么以上就是我分享的关于一个可信的 数据基座 一个可信的结构化 基础 下面后两部分 让我们邀请 欢迎亚马逊云科技的王维超老师进行 从工程方法论的角度 把整件事再拉出来 同时再给我们介绍一下 非结构化的语言是怎么做的 好 欢迎王维超 谢谢付德义 下面的话 就是由我来介绍一下 第三和第四部分 其实刚才 付德义介绍到一个非常好的一个故事 就是说在面向 Agent 的这样一个结构化数据上的 一个故事 就是说从 AI 问数 然后到最后落到语义层 然后加 VQR 的这样一个工程化的一个实践 但实际上就是大家知道 企业里边的数据 其实不光是有结构化数据 其实更重要的话 就是说 更多的一个数据的话是这个 不好意思 是非结构化数据的这样一个存在 然后包括这个企业的 SOP 然后一些文档等等 那么刚才 把付德义的比如说这样的一个思路 这样一个可信的思路搬到非结构化数据上 那他会变成一个什么样 那这里的话 我们实际上是两个工具 这两个工具 可能大家是比较清楚的 可能有一些这个概念 一个的话是 RAG 一个是 GraphRAG 那这两个的话 其实并不是一个替代关系 而是一个是基础底座 第二个的话是在基础底座之上 然后我们做的一个增强 我们先看一下我们这个 包括四点 我们面向的这样一些版图 这里边的话 其实因为 IT 的话是面向整个各项 去赋能各个部门的这样一个角色 所以其实我们面向的这样的数据 源是非常多的 整个数据的类型也是非常多的 尤其是对于像汽车制造行业来讲 那其实这里边有很多的这样一些业务领域 那可以看到像制造和质量这边 有一些维修手册 有 SOP 有质量规范 然后对于一些研发和产品这一块的话 有一些设计文档 有一些测试报告 对吧 然后对于一些 像 HR 包括供应链和采购等等 那所有的这样一些业务领域 其实都有自己的这样一些 核心的这样一些文档 那其实对于 Scania 或者对于可能在座的 大多数的一些企业来讲 其实我们的目标也很直接 那第一个的话 就是说让企业的任何一个部门的 这样一个员工 用 Agent 的方式 用自然语言的方式 能够获得所需要定位的 这样一些答案 并且它是要保证它是可信的 我们要去定位到 它具体的一个段落 具体的表格 具体的步骤 具体的图片 甚至我们要求这样一个可信的查询 我们需要去带来 这个引用的这样一些证据 而不是让大语言模型 简单的去做一些 简单的总结 那最后一个的一个需求的话 就是说 包括我们的目标 我们是希望去构建这样一种平台 然后一种平台去赋能 然后整个企业当中的 不同的业务单元 OK 那我们去看一下 就是我们在去实现这样的一个 RAG 和可信 RAG 的这样一个过程 大家可能以前做过 RAG 包括我们以前也走了一些弯路 就是 RAG 是不是就是一个向量 加上一个大语言模型 实际上我们经过这一年的 这样的一个实践 其实我们看到 实际上并不是那么简单 从一个生产环境 跑的通用的 RAG 其实背后的话 我们总结下来 实际上是多层的 这样一个工程上的一些能力 那第一个的话 就是说 是这个我们要做 高保真文档的这样一个解析 举个例子来讲的话 比如说维修手册里边 有大量的这样一些 零配件的这个位号图 然后整车的 BOM 然后传统的这样的一个检索 可能会有丢失的这样现象 那么用一些工具 实际上是把这些表格公式 整个层级的这样一些结构化 完全保存下来 也就是说做到信息的这样一个完整性 那在这里的话 其实我们做很多一些工作 第一个的话 就是说举个例子 像刚才说的整车的 BOM 表 然后包括跨页的这种嵌套表格 那如果直接去用 这种 OCR 的这种方式去去扫 那传统的一些工具 可能一切就碎 然后包括一些关键的一些信息 和关键的一些诊断信息 可能就会丢失 所以说我们在这里边 其实是叠加了一些能力 那第一个的话 就是说我们建议 可以把这种整个的一个版面分析 然后先用一些比如说视觉模型 然后把每一页拆成不同的这样一些区域 比如说像标题 像正文 像表格 图注 然后包括页眉页脚 然后表格识别的话 就是说我们保证它的这样的一个关系 然后能够立得住 然后包括这个 BOM 里边 其实有大量的合并单元格 包括一些多层的一些表头 然后跨页的续表 那我们识别到的 这个单元格之间的一些拓扑关系 那不是把表格简单 去给它扫成一串文字 而是通过这个 比如说一个零件号 对应了这个它的位号 它的这个规格 然后供应商 然后这样几个关系 其实不会错位的 所以另外还有一个事情的话 就是说我们从阅读顺序上的一个还原 比如说我们要做这个文档的这种 多栏排版 然后包括这个图文混排 然后包括这个脚注 去插入一些正文 实际上也就是说人眼 应该怎么去读这一页 而不是简单单去按照这个 PDF 的这种这个元素 去乱序的去给出来 那再一个话 我们对里边 比如说识别到的 像这种这个公式和符号的 这样一些识别 然后进行一些这个 可识别结构化的 这样的一些这个输出 不只是去丢一些这种乱码 我们保证比如说一张表去跨三页 那么一段话的话 如果被页码切断 那我们可以在解析这段 就把它这个缝回去 而不是让比如说下游切片去猜 这样的话底层其实实现的 就是说是一个这个多模态的 视觉的这样一个模型 然后同时能去看文字 能去看图像 那么这个的话是过去的一些 纯文本的这个 OCR 是很难做到的 所以一句话就是说 我们在做通用 RAG 的时候 不是去简单的去提取数字 而是在去重建整个文档的 这样的一个结构 那第二个的话 就是说也是我们在工程化角度上 做的一个比较多的一个工作 是做切片的这样的一个策略治理 那在这里边的话 同样是有几个这个实践的 第一个的话 比如说像做这个结构化的 结构感知去做分块 不是按照固定的这种字数去切 而是顺着文档自己的这个骨架 比如说他有自己的一个这个章 有自己的章节 然后有一些小标题 这个段落 然后表格 然后图注 那我们去切的时候 然后争取 这个尽量每一刀都切在 他的语义的这个 这个自然断点上 那一个 比如说 SOP 的一个操作步骤 那永远不会被切到 比如说两段里边 那对于语义分块的话 如果对于没有这种清晰 结构的这种长文本 比如说像这种会议纪要 包括一些这个 邮件的这种归档 然后用这个 Embedding 的这种模型 不是去切一半 那可以去用这种 多粒度的这种分层的这个 所以实际上也是现在比较流行的 一个技术 然后去做 那同一份文档的话 可以去建多个这个层级 比如说这个句子级 到段落级 然后到章节级 然后检索的时候 可以用这种 特别细小的这种颗粒 去做到这个精准的命中 然后返回出来 给到这样一个完整的一个上下文 那么也就是说 模型的话 这个既不会被淹没 也不会被断章取义 然后上下文增强切片 实际上也是我们做到的一个 非常重要的一点 比如说在每个切片 在入库之前 然后可以先让模型生成一句话 就是说 你这的话在整个的这个 整篇文档里 他讲的是什么 然后讲到切片 然后再到这个 Embedding 然后这个的话 其实就能把 这个检索的这样的一个召回率 其实能够拉高 30% 到 50% 那这同样的话 对于这个增强切片 同样是这个 Anthropic 在2024年公开的这样一个工程实践 其实也已经成为当前的一个 企业级 RAG 的这样一个标配 那么他所带来的一个优势的话 就是说所属的章节路径 然后包括文档的类型 包括其实同样能够去 带来相应的一些更多的一些细节 比如说文档的一些归属 它的一些元数据版本号 在检索的时候不是去全库捞 而是先去像图书馆检索一样 先去看数据在哪里 然后先去看元数据去过滤 然后再按照语义去做召回 这样的一个结果的话 其实它是又快又准的 那么底层的话其实还有一套 我们动态去做的 这个粒度的一个策略 比如说像系统 其实是可以用段落级的 这样方式去做的 比如说我们问 某一个整体流程是什么的时候 那么系统的话 它能自动切到这样的一个章节级 那么模型 它问什么样的颗粒 那么其实最后的这样一个结果 我们就给出什么样的一个 一个细节这样的一个颗粒 它的一个是统一的这样的一个方式 所以其实让用户的话 就是说我们不用去让用户去懂分块 那么整个的这样一个流程 实际上是可以做到这个按需 去做整个文档的这样一个注入的 那么用户的话 只需要去看到 得到这个比较简单的这样的一个入口就可以 那第三层的话 其实也是非常重要的一点 这一点其实跟刚刚付德义介绍到的 是非常相似 就是说 因为在非结构化数据里边 其实会有更多的一些业务术语的 这些业务术语 我们把这些业务术语 其实统一成 类似的一个语义层 然后它是一个约定俗成的 可能只有被某一个企业里边 知道的这样的一些术语 我们同时 实际上类似于去做一个业务字典的 这样的一个累积 然后这样做的一个好处的话 我们就不让这个模型去猜 我们到底是做到什么样的一个 业务的语义 然后第四 再往下的话 就是说 我们实际上是支持一个多源的 数据注入 比如说像 SharePoint 像 S3 等等 包括第三方的一些系统 所有的这样的系统在集成的时候 就是都是通过统一的这样一个 IdP 去做 SSO 然后去做增量的一个更新 第五层的话 实际上是一个工程化的运营 我们在应用的这个 Studio 里边 可以统一的面向不同的业务单元 然后给出相应的一个 AI 应用 让它有这样一个接口 去查询 它所 Owner 的这样一些数据 OK 所以其实我个人认为 就是说我们这样做的一个最大的优势 其实就是说把历史以来 企业里边 可能在不同的数据源里边 沉淀的这种历史的数据 比如前面提到的 像 SharePoint 像文件服务 然后包括各部门自建的系统 包括企业级的一些共享的 这种盘 对吧 然后纳入到统一的这样一个接口 那以前的话 可能用户需要去先记住 比如说某一个问题 要去哪个系统里查 会涉及到这种跨系统的这样一个切换 然后同一个问题 不同的人去问的时候 可能会有不同的答案 包括文档的这样一个散落 也是很难去追溯的 那现在的话 我们一个对话入口 那么可以实现这种跨业务域 跨系统 然后跨格式的这样的一个访问 然后对于这个多数据源的这样一个方式 并且我们能够去做到统一的这样一个集成 然后去答复 比如说可以引用的这样一个证据 这同样是对于今天这个主题 比如说可信 数据查询的一个非常重要的一个支撑 那从工程意义上来看的话 其实在整个项目上 其实它更多的 实际上是对于数据上层 我们做一个智能的接口 也就是说传统 IT 资产 可以现在被无侵入的 去纳入到 Agent 这样的一个时代 因为我们这个过程当中 实际上对传统的 对于原始的一些数据 并没有做更多的这样一些修改 再一个的话 就是说因为现在 IT 的能力 实际上是可复用的 那么并且是可被治理的 那这个的话是我们在进入 Agent 的 这样一个新角色的时候 就是把系统聚合起来 提供一个可信的 然后跨域的这样一个查询的入口 那么再往后的话 就是说我们看到 通用的 RAG 实际上解决了企业大部分 80% 以上的这样的一个企业的问答 但是有一个特殊的场景 可能它有一些挑战 那不是说它不够好 那么而是确实这个场景比较特殊 也就是说在多跳的这个场景里面 比如说像维修工程师可能会去问 比如说某一个设备启动失败的 这个原因是什么 那么通常来讲 通用的 RAG 可能要召回50 篇 相似的这种手册的这个段落 但是我们从工程上来看 相似其实并不相关 那召回更多的这样的一个信息 反而会稀释掉具体的这样一个信号 所以我们在这个场景的一个解法的话 就是说引入这个 基于 Graph 的 RAG 就是 GraphRAG 比如说我们把维修手册 可以抽成一个知识图谱 那运行的时候先做实体识别 然后在图谱上先去做两到三跳 这样一个推理 拿到一个合理的 确定的这样一个合理的路径 然后再通过向量检索 然后只在这个确定的路径 相关联的这个文档的子集当中去进行 所以说这样的一个召回路径 实际上是可以被这个图谱 做一个约束 那么大语言模型拿到的 不再是一个全量的这个 Top-K 的 这样的一个结果 而是这个图路径 然后加上命中的这样一个段落 所以结果的话是可以追溯的 并且是可以解释的 那这里我想强调的一点 就是说 GraphRAG 其实并不是替代通用 RAG 这样一个方案 它是在通用 RAG 技术之上的 这样一个增强 那通用 RAG 其实我们面向 Agent 或者面向现在的数据的话 是底座 那么 GraphRAG 的话 它是在之上的这样一个增强 通过这个比如说在 RAG 不擅长的 这种多跳的领域 我们给把准确度给它补足 所以说这是两条腿 其实互补而不会有这种替代的关系 那走到这里的话 其实你会发现 就是说在结构化 前面说的结构化数据 比如说这个语义 然后加 VQR 那非结构化数据的话 我们把这个图谱 做这样一个准确的约束和召回 那其实两者之间 其实是有一些共同的 这样一些思想的 就是说做可信的这样一个查询链路 那么我们可以再回顾一下 刚才的内容 就是说可信查询起来 其实通过刚才那三步 然后我们再做的一件事情 就是再做收紧这个大语言模型的 它的一个自由度 那第一个的话就是语义层 用用语义层去锁住业务口径 锁住业务口径 那大语言模型失去了去 不是失去 或者我们降低了 它去无限制的去写 JOIN 写过滤条件的这样一些自由度 而让它去做一些 槽位的这种填充 那第二个的话 就是刚才说到了这个 VQR 然后沉淀已验证过的问答 也就是说大语言模型在高频问题上 不再反复地去生成 而是去做同义匹配 然后命中 然后就回答 然后第三个的话就是做 graph 那么去约束它的整个召回的路径 然后大语言模型 我们不让它去无限制的去做自由的 这样的一些生成 那最后的 所以说我们看到一个同一个范式 就是说把召回的或者是编译 给它变成一个确定性的 然后再让大语言模型 在最后的确定性的空间当中 去走完最后一步 那这个的话 其实就是我们做可信查询 面向非结构化数据的这样的一个内涵 那么其实我们在工程上 如果做到位的话 实际上要花费很大的一些功夫的 那我们后边的话是总结这几条 那么第一条的话 就是说给大语言模型 我们要去划定一些边界 然后可信查询的本质 就是说 不是把大语言模型换成无限制的 去增强它的一个能力 而是把大语言模型从生成 然后降级到 在确定性的空间里 它的一个推理 然后当然前面介绍到的这个语义 然后包括这个 VQR 包括 graph 这些其实都不是一个新的概念 而是我们在工程角度上 可以给大语言模型去按照我们的需求 去划定它的边界的这个几种的 这样的一个工程化的方式 然后第二条的话 就是说 结构化和非结构化 其实有一定同构的 就是说从思想上 我们看 Text2SQL 或者 graph 可能是两件事 或者 RAG 那但是在实现的工程的 这样的一个哲学上来看 我们去 一般做的是先去召回 然后确定 它是确定之后 然后再让大语言模型去做最后一步的 这样的一个生成 然后所以说 我们跑通了这样一个同一套范式 并且这一套方法论的话 可以在企业部门的多个场景 或者其他企业里边去实现 那第三条的话 就是说 可信链路是从可信的数据的底座开始的 那 Agent 去进入到生产的前提 一定是本身就有数据的可信的底座的 它可治理 可追溯 可观测 并且是有 SLA 的 那没有一个可信的数据底座 其实对于 Agent 整个的这样一个 端到端的查询 是没有办法去获得这样一个保证的 对吧 所以整套过程 我们下来 就是说包括前面的一些介绍 然后包括刚才的这个语义的治理 然后加上这个 GraphRAG 的这样的一些能力 我们在自然语言面向数据查询 不管是结构化和非结构化的这样一个数据的时候 我们其实很容易就做到90% 以上的这样一个概率 那这个的话 其实就是我们跟 Scania 在包括亚马逊云科技 我们在共同推进的这样一个可信链路 当前的一个进度 所以最后一句话 我们去概括一下 就是说我们让 Agent 的未来去答得对 那一半的话是靠模型 那另一半的话 就是说我们要用工程的方式 把它收紧在确定性的空间 一部分的话 能够去降低我们的一个成本 那更主要的话 其实我们用工程化的这种方式 然后去获得这样的一个更高的准确率 OK 谢谢大家