生成式 AI 时代的数据：我们需要更多知识工程师

在生成式人工智能时代，数据相关话题经常成为关注的焦点。

以下是一个典型例子。风险管理公司 Riskonnect 最近对 300 多名风险和合规专业人士进行的 AI 调查显示，数据隐私和网络安全问题是首要担忧。其次是基于错误信息的员工决策，以及由此带来的员工滥用和伦理风险。此外还有版权和知识产权风险。KPMG、麻省理工学院、PricewaterhouseCoopers 等机构也得出了类似的结论。

这就是为什么我们预测今年 AI 将推动数据复兴。随着 AI 项目从概念验证阶段进入生产阶段，组织必须认真关注用于训练和推理的数据。我们最近在德克萨斯数据日 (Data Day Texas) 这个在奥斯汀举行的年度数据社区聚会上有机会验证这一前提，其中一个突出的话题是：需要理解数据的上下文。

理解数据上下文的关注源于确保 AI 模型运行在正确数据上的需求。由此产生了对专业人员的需求 - 即掌握上下文并能指导使用正确数据的知识工程师。这类人具备我们在过去时代重视的参考图书馆员的许多品质。

让我们记住这些观点。

理解上下文

在大数据鼎盛时期，普遍认为数据越多，画面就越完整。但从那以后我们学到了一些经验,可以概括为"更大并不总是更好"。

上周关于 DeepSeek 的头条新闻突显了这一点。无论你是否认同 DeepSeek 的基准测试结果，已经出现了一个趋势，即基于 80/20 法则的变体来提供更合适规模的模型：拥有恰到好处的数据和模型来实现"足够好"的结果。Databricks Inc.、IBM Corp. 和 Snowflake Inc. 等提供商已经在研究"专家混合"等方法，旨在调整模型规模。对内行人来说，像 DeepSeek 这样的公司在某个时候出现并打破 OpenAI 的泡沫并不令人意外。

合适规模的模型提高了对正确数据的要求。当你面对的是较小的空间时，大量撒网式的尝试就行不通了。要理解数据是否适合查询，你必须了解其上下文。这不仅仅是了解你的数据组合中有什么，还包括了解关于数据的所有相关信息：数据来源是什么？如何收集？如何使用？谁来使用？等等。

当然，我们一直都需要正确的数据。但对企业数据仓库或数据集市中已知数据集进行传统分析查询是一回事，而运行 AI 时风险面会扩大，因为模型往往是黑盒子，不容易解释。当涉及非结构化数据时，这个挑战会加剧，因为数据源可能不那么为人所知或未经审核。错误的 BI 查询可能会显示出客户需求统计分析的错误，但失控的 AI 响应可能会产生无法解释的幻觉，而错误可能并不总是显而易见。

简而言之，找到上下文就是要回答记者们长期以来称之为五个 W 问题的内容：Who (谁)、What (什么)、Where (在哪里)、When (什么时候) 和 Why (为什么)？此外，我们还要加上第六个"荣誉" W，即 How (如何)。

Ole Olesen-Bagneux 在会议主题演讲中清晰地传达了这一信息。他的观点是什么？组织中的数据很可能高度分散，而分散使得掌握这五个 W 变得更加困难。几年前，关于分布式数据的讨论让数据网格出现了 15 分钟的辉煌。但数据网格涉及的联邦治理proved 证明很棘手，数据网格的遗产是数据产品。

相反，Olesen-Bagneux 提出了一个更适度的建议：从底层开始，映射系统以及它们服务的人员或线路组织，更重要的是，上游和下游连接的系统。通过元数据流来追踪它。

Olesen-Bagneux 将他的概念称为元网格。他关注元数据而不是原始数据，因为这能洞察那五个 W。而很多上下文来自生成元数据的源类型。如果元数据来自数据库，它定义了模式；在业务应用程序中，元数据主要是关于业务逻辑；如果由云基础设施生成，则是关于如何处理数据。

例如，数据管道可能会产生大量上下文信息。它们绘制了组织内共享的数据图，重要的是，它如何转换和共享。理解数据如何转换很重要，因为这可能影响其含义 - 含义可能被增强或可能丢失。这就是五个 W 中荣誉 "how" 的由来。理解源和元数据如何流动以及流向何处是理解组织信息脉搏的重要一步。

有趣的是，Olesen-Bagneux 的概念如此新颖，以至于目前在 Google 搜索中都找不到。所以不要将元网格与追踪历史人物联系的项目或 App Store 上的 Mac 工作流应用程序混淆。

共享语义

Juan Sequeda 接续了 Olesen-Bagneux 的观点，谈到了共享语义的重要性；这对于组织能够有效重用数据至关重要。Best Buy Health 的数据科学家 Andrew Nguyen 用他所在领域的一个例子强调了这一点：当医生在病历上为特定病症勾选复选框时，需要问的是谁输入的？是医生做出诊断，还是医学生或书记员解释医生的预后，或是临床医生做出观察？

他们每个人对何时为该病症勾选复选框可能有不同的理解。沟通和理解人们的角色有助于洞察这些数据值的含义。

Nguyen 的例子是关于为什么连接数据上下文将改善 AI 模型效果的更广泛讨论的一部分。他将上下文工程描述为一个系统性捕获上下文并使其明确的新兴学科。这个学科尚未得到很好的定义，几乎没有当前已发表的参考文献；最接近的参考是 Data.world 的一篇技术博客文章，描述了一个以增强知识图形式持久化这些内容的系统。这进一步暗示了对知识工程的需求。

被 (不) 通用语言分隔

你以前听说过：在共享数据时，我们需要说同一种语言。

对于结构化数据，这就是关于模式。Sequeda 指出了 Schema.org 的成功，这是由 Google、Microsoft、Yahoo 和 Yandex 共同创立的开源项目。如果它能够标准化全球网站如何构建数据，那么协调企业内部的模式设计实践就不应该成为难以实现的目标。

但在企业内部，现实往往是常见实体从一个业务线组织或系统到另一个系统经常有多个定义。我们听说过一些企业对客户或产品有数十种定义的故事。

还有 NULL 值的问题，不同系统经常以不同方式使用 NULL 值。例如，它是表示缺失的数据值、超出正常范围的值，还是未定义的值？虽然 NULL 可能不用于回答查询，但理解它们的使用方式突显了数据质量和可靠性，或缺乏这些特性。

当然，到目前为止这些都是关于结构化数据。当涉及语言模型时，我们处理的是来自各种来源的书面文本或语音，其中源类型对上下文有重大影响。电子邮件中写的词或短语具有不同的目的，可能需要与从图像或参考文档中提取的文本进行不同的解释。例如，电子邮件或消息更可能包含传闻，而经过审核的参考手册则不同，而从图像中提取的文本可能很容易脱离上下文。

非结构化数据是数据治理和知识工程的前沿。目前的技术水平相当基础：在文件层面评估来源并追踪血统。最终，我们可以使用语言模型的实体提取能力来获取元数据，如果我们组合足够的工具，我们可以收集元数据来帮助发现(和管理)这些资产。

今天的技术过程仍然相当复杂，而且不能直接解决上下文问题：你会信任语言模型来推断来自消息或法律合同的相同术语或短语的含义吗？你会相信语言模型能够确定源是否包含回答问题的正确数据吗？

让知识工程师来拯救

直截了当地说：这个问题的答案涉及一个"谁"。AI 可以爬取信息、提取元数据并生成数据景观布局，但人类仍然必须参与其中。

这一点在由 Joe Reis 和 Matthew Housley 主持的当天最后的"市政厅"会议中得到了清晰的体现。听众的第一个声明就是关于对知识工程师的迫切需求。

旧的又变成新的。知识工程不仅植根于企业架构和数据管理，也植根于图书馆科学。传统上，企业架构师和数据管理员关注结构化数据。但随着语言模型引入各种形式的非结构化文本，它从我们过去依赖的参考图书馆员那里获得重要启示，他们在卡片目录之外继续工作。

在这里透露我们的年龄，我们记得研究项目通常需要去图书馆查找印刷文档和缩微胶片的日子。卡片目录指向作者和主题，但当涉及到找出哪些书籍、期刊或技术期刊包含最相关信息时，参考图书馆员在那里指明方向。他们能够这样做是因为他们专业的一个关键技能是理解各类源的上下文。

快进到现在，知识工程需要许多这些技能。它用与数据科学相关的软件工程技能更新了参考图书馆员，比如对语言(如 Python)、框架(如 TensorFlow)的深入了解，以及理解如何使用机器学习进行知识提取。它也大量借鉴了语义学科，如本体开发、知识表示和通过图(属性或 RDF)表示它的相关技能。

现代爬虫和 AI 技术通过扩展知识工程师理解现有内容上下文的能力来发挥支持作用。随着代理 AI 技术的成熟，它也可能自动化一些实体提取和总结的协调工作。

但人类判断必须接管以确定信息是否合适和相关。知识工程师几乎不能在他们的象牙塔中单独工作；他们需要与一线的主题和领域专家合作。需要人而不是机器来确定 NULL 值的真正含义，或者源材料是否适合训练或运行 AI 推理。

知识工程师需求的增加与知识图谱日益突出的地位同时出现并不令人惊讶。就像机器学习一直存在于预测分析和预测解决方案的幕后一样，知识图谱已经变得无处不在。现成的企业业务解决方案包括支持协作的 Microsoft 365 (前身为 Office) 底层的 Microsoft Graph、作为客户联系关系物化视图的 Salesforce Data Graph，以及从其语义层体现业务流程元数据相互关系的 SAP Datasphere Knowledge Graph。

正如 Sequeda 在他的活动后记中指出，我们感到欣慰的是，知识图谱不再被视为"新"概念。虽然构建知识图谱仍然需要艺术和科学的结合，但最终我们期望知识图谱将成为基于检索增强生成(RAG)实现的杀手级应用。

随着 AI 创造了对知识工程的需求，信息科学(正如我们过去称呼的那样)已经完成了一个循环。这是因为企业要求将价值工程的原则应用于 AI，以便训练和运行模型不会产生数百万美元的云计算账单，并确保 AI 模型保持适当的基础。

企业必须确信他们正在用恰当的数据运行模型，这就是理解数据上下文的重要性所在。虽然 AI 可以协助收集数据的基础工作，但最终需要知识工程师的技能来做出最终决定。