Appearance
📰 概要
2026年4月29日，Vanguard在AWS官方博客上分享了"Virtual Analyst"项目完整经验。 Vanguard是全球最大的投资管理公司之一，管理资产超过8万亿美元。
它的分析师要查数据时，得写复杂的SQL查询语句，等待数据团队回复——一个请求要几天才能走完。
于是他们做了个"Virtual Analyst"项目，让分析师用自然语言直接查数据。
项目做下来，团队发现了一个反直觉的结论： 「构建对话式AI的最大挑战不是机器学习问题，而是数据架构问题。」
🔍 解读
Vanguard这个结论，其实是很多企业做AI时踩过的坑。
你选个最强的模型，搭个对话界面，丢到公司内部用——用户一问细节，模型就开始胡说。 不是模型不行，是你的数据基础设施还没准备好给模型用。
Vanguard团队总结了8条AI就绪数据原则，核心就两件事： 第一，你得有一个语义层，把业务术语翻译成数据库能理解的字段。 第二，你得有元数据目录和质量标准，让模型知道自己面对的是什么数据。
没有这两个东西，再强的模型也是在迷雾里开车。
💎 深挖
Vanguard的实现路径，可以给所有做企业级AI的团队当参考。
他们第一步做的是把组织对齐。数据工程师、业务分析师、合规官、安全团队、业务负责人，全拉到一起。 以前各管各的，每家造自己的数据定义。同一个"客户价值"在不同部门里有三个不同算法。 Virtual Analyst项目要求统一语义，这就是跨部门博弈的开始。
第二步是建数据产品。每个数据集都被注册为"数据产品"，有自己的所有者、质量等级、更新频率、Schema。 机器学习平台可以直接通过目录发现和接入这些数据，不需要每次都沟通。
第三步是搭语义层。Vanguard用Amazon Bedrock做模型推理，Glue做数据目录，Redshift做数据仓库。 业务术语到SQL的映射关系全部定义在语义层里，模型不需要猜"年化收益率"对应的数据库字段叫什么。
第四步是建Ground Truth库。团队积累了一批经过验证的问题-答案对，作为评估基准。 每次模型更新，先在这批基准上跑一遍，看有没有退化。 同时设置3到5个核心业务指标持续监控：分析师节省了多少时间、查询成功率、用户满意度。
这套系统跑下来，Vanguard计划下一步做知识图谱加RAG。 图谱可以提供显式的实体关系，提升复杂的关联查询准确率，比如"过去五年中，哪些投资组合在通胀环境下的表现优于基准"。
什么情况不建议用？ 如果你的组织数据治理成熟度不够，数据产品化的底子还没建起来，直接上语义层会放大混乱。 另外这套方案依赖AWS的Bedrock、Glue、Redshift生态，如果你用其他云，需要重新设计架构。
对开发者的启发：Vanguard案例说明了一个问题——企业AI的瓶颈不在算法层，在数据层。 如果你的AI应用在生产环境表现不稳定，首先查数据而不是换模型。 一个干净、有语义、有质量标注的数据集，比模型本身的优化优先级更高。
