问题不在于模型，也不在于数据，而在于你的人工智能根本不知道你的数据究竟意味着什么。

问问任何一家企业人工智能团队，他们遇到的阻碍是什么，你都会得到一个比较委婉的说法：“我们正在扩大试点规模。”“我们正在努力提高数据质量。”“我们需要更好的管理。”

他们的真实意思是：人工智能会根据提问者是谁、访问的是哪张桌子以及当天是星期几给出不同的答案。而且没有人足够信任它，让它去做任何重要的事情。

这不是模型问题，也不是数据问题，而是意义问题。数据就在那里，可以访问，也相互关联。但使用这些数据的AI却完全不明白，在企业实际运营的背景下，这些数据究竟意味着什么。

“收入”一词在三个不同的表格中以三种不同的方式定义。“活跃用户”对产品团队而言是指每日登录用户，对增长团队而言是指过去 30 天内的任意会话用户。“客户”包括 Salesforce 中的试用帐户，但不包括计费系统中的试用帐户。这一列rev_adj_v2_final只有四年前创建它的分析师才觉得有意义。她两年前就离职了。

人工智能对这些一无所知。它只是随便选一张表，然后自信满满地给出一个数字。还附带一张图表。

每个人都在解决错误的问题

过去两年，业界一直在努力构建更完善的基础设施，包括更强大的连接器、更高效的文本转SQL系统、更智能的代理和更优秀的模型。数十亿美元的投入旨在解决企业级人工智能面临的难题：如何让人工智能访问数据。

并非如此。难点在于如何让人工智能理解接收到的数据的含义。

现在，各大数据平台都提供“数据人工智能”服务。对于基于清晰星型模式的演示级问题，这项服务确实有效。“我们昨天处理了多少订单？” 当然可以。

但企业并非基于清晰的模式运行。（如果你的企业确实如此，恭喜你，你可以不用往下看了。）

他们的运作方式自相矛盾。季度中途更改收入确认规则。三个部门对“客户流失”的定义各不相同。数据团队早已不复存在，而列名却成了内部笑话。业务逻辑存在于Slack聊天记录、无人维护的Confluence页面中，而分析师主管们随时可能辞职，带走公司的全部机构知识。

一旦你完成了演示问题，那种“直接连接数据”的方法并不会报错，而是会给你一个看似合理却错误的答案。而这一点却鲜为人知：每一个错误的答案不仅仅浪费时间，它还会让你的组织认为人工智能行不通。这种信任的丧失比任何技术问题都更难挽回。

三个用例，一个缺失的层

目前，所有企业都在追求相同的三个人工智能应用场景。每一个场景都需要比前一个场景更深入的数据理解。而一旦缺乏这种理解，每一个场景都会遭遇更大的失败。

使用案例 1：与您的数据聊天

业务用户希望用自然语言提问，而不是向分析团队提交工单。“上个月有多少患者被确诊并接受了这种药物治疗？”“我们第四季度企业客户的留存率是多少？”

大多数公司都从这里起步，问题也最先出现在这里。人工智能不知道该用哪个“留存率”的定义，哪个表才是规范表，也不知道“第四季度”指的是日历季度还是财政季度。缺乏这些上下文信息，人工智能结合数据查询的准确率徘徊在20%到30%左右。模型本身并不差，它只是在猜测哪些数据代表什么，而且大多数时候都是错误的。

用例 2：AI 驱动的工作流程

企业希望实现实际流程的自动化：审核表单、路由请求、验证信息、基于数据做出决策。而在这里，错误的答案不再仅仅是尴尬，而是代价高昂。

如果一个工作流程因为上个月业务规则的变更而触发了错误的操作，它不会生成错误的图表。它会错误地处理索赔，将审批发送给错误的人，并标记错误的账户进行审核。而且没有人发现这个问题，因为自动化的意义就在于无需人工监控每个步骤。（这 相当于企业人工智能版的“在我的机器上运行正常”。）三周后，数据团队才在Slack上收到一条惊慌失措的消息，有人发现数据对不上。

用例 3：人工智能代理

前沿领域。能够推理、决策和行动的智能体：触发系统、调用工具、执行多步骤工作流程。在这里，数据理解问题演变成了安全问题。

设想一个简单的客服工作流程：“标记续约风险高的客户”。客服人员需要了解“高风险”的定义（该定义六周前已更改）。他们需要知道哪些客户关系管理 (CRM) 字段是最新的，哪些是过时的。他们还需要知道，流失模型ml_predictions仅涵盖企业客户，不涵盖中小企业客户。任何一个环节出错，都可能导致客服团队被大量误报淹没，或者错过真正需要关注的客户。

如果一个智能体不知道该信任哪些数据，也不知道该遵循哪些规则，那么它要么事事都向人类寻求帮助（这违背了智能体的初衷），要么基于错误的假设行事，造成实际损害。没有安全的中间路线。

聊天需要人工验证答案。工作流要求答案无需人工检查即可正确无误。智能代理则要求人工智能知道它不知道什么。每个层级都对数据理解提出了更高的要求，而当前的基础设施几乎无法提供这种能力。

在这三者中，企业都遇到了同样的瓶颈。数据团队成了所有人工智能项目的瓶颈，他们手动将业务问题转化为正确的查询，维护着其他人无法维护的定义，并且不断收到高管们同样的沮丧反馈：“为什么就是不行？”

堆栈中缺失的层

现代数据栈中存在一个尚未被填补的空白。

数据如下：存储和计算问题已解决。Snowflake、Databricks、BigQuery。数万亿行数据，亚秒级查询。完成。

以上是数据：人工智能模型已完成。GPT-4、Claude、Gemini 以及其他开源替代方案。它们可以编写 SQL、分析结果并生成摘要。完成。

数据与人工智能之间：没有关系。

这才是业务意义的所在。它包含了定义、关系、规则和上下文，这些要素将原始表格转化为人工智能系统能够可靠推理的内容。

像Solid这样的公司称之为上下文层，无论你使用什么工具，这种框架都很有用。它不是仪表盘，也不是数据目录（你的公司肯定有数据目录，但上次更新是什么时候？）。它也不是传统意义上的BI语义层，尽管两者有相似之处。

传统的语义层是为仪表盘服务的。它将业务术语映射到 SQL 查询，以便 Looker 或 Tableau 能够生成正确的图表。虽然有用，但它是静态的，需要人工维护，并且是为人类消费数据的时代而设计的。上下文层则是为人工智能消费数据的时代而构建的。它需要具备机器可读性，持续维护，并且足够智能，能够理解首席财务官和产品团队提出的“收入”概念的含义不同。

人们已经尝试构建这方面的部分功能。dbt 的语义层和 Cube 之类的工具允许你将指标定义为代码，对其进行版本控制，并将其提供给下游使用。这确实是进步，如果你已经拥有完善的数据工程实践，那么这些工具值得使用。但它们解决了定义问题，却没有解决发现和维护问题。你仍然需要有人了解哪些指标存在、它们之间有何关联以及它们何时发生了偏差。在一个拥有数百个表和数十个模型的公司里，这样的人并不存在。

手动方法（雇佣分析师、编写文档、维护维基）在小规模下行得通。但在企业级规模下，文档编写工作量会随着数据复杂性的增加而线性增长，而维护团队的人员却保持不变。几周之内，定义就开始出现偏差。新员工查阅维基，发现其中的矛盾之处，于是开始维护他们自己的“影子定义”。一年之内，你就会面临与最初相同的碎片化问题，只不过现在还多了一个过时的维基，而每个人都把责任推卸给它。

一直以来，我们所缺少的是一个不仅定义语义，而且还能随着业务变化主动发现、生成、测试和维护语义的平台。

实际运作是什么样的

这就引出了Solid。

Solid 位于人工智能系统和企业数据之间的执行路径上。它无需数据团队手动构建和维护语义模型，而是分析数据在整个组织中的实际使用情况：查询模式、BI 定义、数据库模型、文档、Slack 对话等。基于这些信号，它生成语义模型，捕捉数据的含义及其关联方式。

假设一家公司的数据仓库中有 200 个表和 40 个语义模型。如果采用人工维护，这些模型大约只能维持三个月的准确性，之后就会出现偏差：表名更改、业务逻辑变更、新增字段，而且没有人更新文档。Solid 会监控底层数据和使用模式，并在情况发生变化时自动更新模型。

它还处理了一个比大多数人意识到的更重要的功能：上下文管理。当人工智能系统查询“收入”时，上下文层会根据提问者的不同而知道应该应用哪个定义。财务部门会得到GAAP收入，产品部门会得到MRR（月度经常性收入），董事会会得到董事会批准的数字。同样的词语，不同的正确答案。而且，它还能与现有工具（Snowflake Cortex、Databricks Genie、ChatGPT、dbt）集成，而无需您彻底改造现有技术栈。

它无法解决的问题：那20%的业务逻辑过于复杂、过于依赖上下文，或者过于特殊， 无法实现自动化。（比如“我们之所以这样计算，是因为2019年的那次收购”之类的。）Solid 的平台结合了实践经验，弥补了这一缺口。我欣赏他们坦诚面对自动化的局限性，而不是假装完全自动化是可能的。

SurveyMonkey 是 Solid 的一家生产客户，它从数据团队中数十个独立的业务逻辑定义，转变为一个经过验证的单一数据源，AI 查询可以基于该数据源运行。

Solid 报告的数据显示：人工智能加数据查询的准确率从 20-30% 提升至 85% 以上；人工语义维护工作量减少 50-70%；部署周期从 1-2 年缩短至 3-6 个月。这些数据未经独立验证。但其发展趋势与我从投资于各种形式结构化业务上下文的数据团队那里了解到的情况相符。

等待的真正代价

我认为大多数公司在这个问题上犯的错误是：他们把这个问题当作优化问题，认为应该在人工智能运行正常后再解决。但如果没有这个问题，人工智能根本无法运行。每个月你都花费大量时间在模糊不清的数据上开发人工智能功能，这不仅仅是在积累技术债务，更是在让你的组织相信人工智能是不可靠的。

这种想法是毒药。一旦首席财务官从人工智能助手那里得到错误的数字，他们就会停止使用它。一旦工作流程产生了不良结果，团队就会转而采用人工操作。一旦高管得出结论“人工智能还无法处理我们的数据”，那么想要获得修复预算就难上加难了。我在多家公司都亲眼目睹过这种情况。技术问题是可以解决的，但组织信任问题却无法解决，至少在合理的时间范围内无法解决。

看看这个模式。每一次企业技术的重大变革都需要一个基础层，而这个基础层往往因为不够吸引人而无人问津。数据库需要模式，API 需要文档，云服务需要身份和访问管理 (IAM)。每一次，炫酷的应用层都吸引了所有人的目光，而那些忽略基础层的团队却为此付出了多年的代价。

上下文层是企业级人工智能的基础。现在构建上下文层的公司将积累优势，因为随着底层数据的理解加深，每一个新的模型、代理框架和工作流自动化都将运行得更好。

那些跳过这一步的人会不断询问他们的数据团队，为什么人工智能对同一个问题会给出不同的答案。

Solid 的创始人将“语义工程师”视为一个新兴角色：负责机器如何解读业务数据的人员。无论这最终会成为一个正式的职位，还是仅仅成为数据分析师本已繁重工作职责中的又一项内容，这项职能都不可或缺。必须有人负责语义层面。而目前，在大多数公司里，没有人承担这项工作。