Anthropic 数据 Agent 95% 准确率背后③ Anthropic 数据 Agent 95% 准确率背后③：普通公司怎么最小成本开始？ Anthropic 近期披露了他们内部数据 Agent 实现约 95% 准确率的背后机制。前两期，我们讲了数据 Agent 的难点，以及 Anthropic 如何通过四层架构解决这个问题。但他们的方案比较复杂，那如果企业要落地，该怎么做呢？本期只讨论起步问题：少量官方标准数据集、几十道离线测试题、一份很薄的 Knowledge Skill。先把少数高频问题做成有标准答案、能测试、能纠错的小闭环，再决定要不要加更复杂的工程化。#dataagent #数据agent #企业AI落地 #AI转型 #企业agent

Anthropic近期披露了他们内部数据Agent实现约90%准确率的背后机制。前两期我们讲了数据Agent的难点，以及Anthropic如何通过四层架构解决这个问题，但他们的方案比较复杂。那如果企业要落地，该怎么做呢？ 先说结论，Anthropic建议普通公司不要一上来复制他们的完整系统，因为那套系统投入太高，先做三个小动作就能拿到大部分收益。一是少量官方标准数据集，二是几十道离线测试题，三是一份公认的Knowledge Skill。 先说第一件事。少量官方标准数据集就是公司承认的标准答案入口。比如业务同事问“本月收入是多少？”，系统里不能有十几张表都看起来能算收入：一张按支付时间算，一张按确认收入算，一张扣了退款，一张没扣退款，还有一张是某个团队临时做看板时留下来的。这些东西都摆在Agent面前，它就只能猜，而数据Agent最怕的不是不会写SQL，是它在很多个看起来都对的答案里自信地选错。所以起步阶段先做的，不是让Agent能看更多数据，而是先把几个核心概念收拢成公司承认的标准答案：本月收入到底对应哪张表，活跃用户到底按什么口径，留存要不要排除测试账号。这一步的白话就是，先别让Agents自己在一堆相似答案里找真相，先把最常问、最容易错的几个指标整理成标准答案。 第二件事是几十道离线测试题。等上线以后才知道Agent会不会答错，不如先给它考试。比如围绕收入这个小领域，你先准备30到50道题：上月收入是多少？本月收入环比多少？企业客户收入占比是多少？退款要不要扣？是用转付费算在哪一天？每道题要么有标准答案，要么有标准查询方式。这样你才知道它什么时候答对，什么时候答错。这里有一个关键点，测试题要稳定，不问“今天收入多少”这种每天都会变的问题，因为明天再测，答案本来就变了。更好的做法是固定日期，或者检查它的查询逻辑有没有走官方口径。说白话，考试题不能自己飘，题目自己每天变，你就分不清到底是Agent的错，还是数据变了。 第三件事是一份很薄的Knowledge Skill，它不是一本巨大的百科全书，也不是一段更长的万能提示词，它更像新人分析师桌上的一张简洁地图：如果问收入先看哪里，如果问活跃先看哪里，如果语义层里有官方指标，就先用官方指标，如果没有覆盖，再看哪份参考说明文档，哪些旧表不能用，遇到退款、欺诈、过滤、试用、转付费这些口径要不要先问清楚。这份Skill的价值，不是把所有知识都塞进去，而是让Agent不要乱找，给它一张清楚的路标：先查官方路径，查不到再看少量指定文档，还不确定就问人。这就是“薄”的意思：少，但能导航。 这三个东西合在一起，才是普通公司最小的起步版本：一个小范围的标准答案，一批稳定测试题，一张简洁路由地图。先跑起来，看用户是不是真的会问，看Agent主要错在哪里，看测试题能不能抓住这些错误。有了这些，再考虑要不要加更复杂的东西，比如更完整的语义层、更多Skill、线上监控、对抗审查、自动同步、自动开修复任务，这些都不是第一天必须做完的事。 所有的架构选型都要从判断自己的约束开始。第一个约束：今天必须答对吗？还是可以等模型继续进步？AI模型进步很快，有些今天需要很多工程手段补的短板，半年后可能会变轻。如果只是低风险的内部探索，没必要第一天就造很重的系统。但如果这是财务数据、合规数据、董事会要看的核心指标，那就不能等，这种场景今天就必须尽量答对。 第二个约束：你的业务会不会越来越复杂？如果公司数据很简单，产品少，用户少，只有几个人用，数据模型也长期稳定，那全套流程可能太重。但如果产品线越来越多，团队越来越多，指标口径越来越多，旧看板越来越多，那就不能靠Agent自己猜，业务越复杂，越要提前把标准答案和路由规则整理出来。 第三个约束：谁在用这个答案？如果使用者是数据科学家，他看到一个数字可能会自己检查表对不对，过滤条件对不对，SQL有没有问题，系统可以稍微宽松一点。但如果使用者是销售、运营、业务负责人，甚至管理层，他们可能只看结论，这时Agent一旦错就更危险，用户越不会验算，系统越要替他验算。 第四个约束：你愿意为准确率付出多少成本？更严格的验证通常更贵，也更慢。比如让另一个Agent专门挑错，可能提高准确率，但会增加模型调用，也会增加等待时间。所以不是所有问题都值得开最高的流程。“昨天访问量大概多少？”这种低风险问题可以轻一点，“这个数字要发给老板或董事会”这种高风险问题就应该重一点。准确率不是免费的，你要决定哪些场景值得贵一点、慢一点。 第五个约束：权限和隐私能不能承受？Agent拿到的上下文越多，通常越容易答对。它能看到数据库文档、路线图、组织结构，当然更懂公司，但看的越多，权限风险也越大。谁能看财务数据？不同部门的数据能不能混在一起？敏感信息会不会被不该看到的人看到？所以很多公司不能默认做一个全能Agent，更现实的做法可能是多个限定范围的Agent：销售Agent只看销售相关数据，产品Agent只看产品行为数据，财务Agent权限更高，但审计也更严。它越懂公司，越要管好它能看什么。 所以，公司落地Data Agent的真正起步问题，不是先追95%的准确率，而是先回答一个更小的问题：我能不能先让一个高频小领域变得可定义、可找到、可验证、可更新。可定义，就是把歧义压缩成一个公司承认的答案，比如收入不要有40个候选口径，先有一个官方收入定义。可找到，就是别把正确答案藏在角落里，要让Agent知道先看哪里、后看哪里、哪些地方不要看。可验证，就是先有几十道稳定测试题，别等用户用了才知道它错。可更新，就是发现错了，以后能补文档、补测试、补流程，不能错误只停在一句抱歉里。 最小可落地版本其实可以非常具体：先选5个核心指标，给每个指标写清楚官方口径，准备30道常见问题测试Agent，写一份很薄的Knowledge Skill，告诉它先查哪里，查不到再看哪里，什么情况必须先问清楚，跑起来看它错在哪儿，迭代文档、补测试、补流程，才是普通公司更稳的起步方式。如果连一个指标的官方来源、测试题和路由规则都没有，就把整个数仓接给Agent，那不是在做数据智能，那是在让AI更快地放大组织里原本就没整理清楚的混乱。 好了，本期内容就到这里，这里是慢学AI，下期再见。抖音。