GenAI时代，数据建模至关重要！传统数据仓库已无法满足AI实时需求，需将数据建模左移至运营层。多语言数据建模整合结构化与非结构化数据，通过知识图谱、GraphRAG等技术，提升LLM的准确性。Pydantic等工具保障数据质量，助力AI Agent实现可靠的工具调用和自动化，解锁实时智能。
译自：AI Won’t Save You From Your Data Modeling Problems
作者：Sean Falconer; Matthew O’Keefe
多年来，我们一直将数据质量视为一个分析问题，将脏数据抛给数据团队，以便稍后在数据仓库或数据湖中进行清理。
这种方法不适用于AI。GenAI应用程序是实时运行的，可以即时做出决策。如果你的数据错误、不完整或结构不良，AI不会修复它。它只会更快地做出错误的决定。
这就是为什么数据建模必须左移。
当AI代理需要在当下进行推理、计划和行动时，你不能等到分析层来强制执行数据质量。这就像开车时每五分钟才能看到一次路。你多久会撞车？
让我们探讨一下为什么AI属于运营层，为什么数据模型比以往任何时候都重要，以及桥接结构化和非结构化数据如何解锁实时智能。
多年来，AI遵循与分析相同的剧本：收集数据，将其聚合到仓库或湖中，清理数据，训练模型，然后使用该模型进行预测。当AI纯粹是关于回顾性分析时，这个过程是有意义的。
但是GenAI颠覆了这一点。
在仓库中进行数据聚合的传统模型训练管道
使用GenAI，AI模型已经构建完成。使其有用的方法不是通过聚合历史数据；而是在运行时向其提供新鲜的、特定于领域的上下文。而这种上下文存在于运营层，而不是在仓库中。
GenAI应用程序使用通用模型，但在提示组装期间使其特定于应用程序。
试图将AI强行塞入分析堆栈是行不通的。聚合太慢了。反向ETL（提取、转换、加载）无法用脆弱且缓慢的点对点管道来弥补差距。当数据从分析领域管道传输回运营领域时，数据已经过时。
例如，考虑下面与GenAI驱动的航班助手的聊天互动。助手需要知道最近的航班、即将到来的航班、飞机的布局以及客户的飞行偏好。为AI正确地提供提示上下文的最可靠的最新信息存在于应用程序堆栈的运营层中，例如航空公司预订系统。
AI驱动的重新预订航班的对话示例
这就是为什么AI属于应用程序堆栈，嵌入在工作流程中，与实时数据交互。
从历史上看，数据建模是商业智能（BI）和分析的关注点，专注于为仪表板和报告构建数据。但是，AI应用程序将此责任转移到运营层，在该层中做出实时决策。
虽然基础模型非常智能，但它们也可能非常愚蠢。它们拥有广泛的通用知识，但缺乏上下文和你的信息。它们需要结构化和非结构化数据来提供这种上下文，否则它们可能会产生幻觉并产生不可靠的输出。
以检索增强生成（RAG）为例。
常见的重点通常是基于非结构化的向量化数据进行语义搜索，检索相关文档以向大型语言模型（LLM）提供额外的上下文。但是，实际的RAG实现通常需要一种混合方法。这种方法涉及结构化搜索和从数据库、CRM或事务系统中检索的数据，以检索精确的信息，如客户记录、库存水平或财务数据。
RAG应用程序的混合搜索模型
仅使用语义搜索，你可能会检索到松散相关但不准确的信息，从而导致在上下文中看似合理但对于特定业务案例不正确的响应。 即使在纯粹的语义搜索应用中，拥有一个定义核心业务实体之间关系的结构化数据模型也有助于验证 LLM 生成的响应。知识图谱是一种特殊的概念模型，它通过捕获实体及其在域内的相互关系来提供这种结构化的理解。
例如，考虑一个管理高中田径运动会的应用程序。
关键实体可能包括运动员、赛事和参与者，以及运动员参加赛事和参与者观看赛事等关系。但是，如果没有标准化的数据模型，可能会出现不一致的情况；有些人可能会用跑步者代替运动员，从而排除非跑步的参与者，或者用观众代替参与者，从而引发关于是否包括赛事裁判的问题。
田径运动会的数据模型示例
实施知识图谱可确保对这些实体及其关系有一个共享的、精确的理解。这可以用图形或自然语言的形式表达，并直接用于提示中，以提高准确性或在后处理过程中验证模型输出。
GraphRAG，一种结构化和分层的 RAG 方法，使用知识图谱来增强 LLM 响应。通过在检索过程中将实体和关系建模为单元，GraphRAG 更准确地理解查询意图并提供精确的搜索结果。例如，Microsoft Research 证明，在 GraphRAG 中使用 LLM 生成的知识图谱可以显著提高分析复杂信息时的问答性能。
一个定义良好的数据模型可以对检索到的见解进行交叉检查，以结构化的表示形式进行验证，从而确保输出不仅总体上准确，而且与特定的业务定义和关系保持一致。虽然 RAG 应用程序侧重于检索，但 AI 代理通过对信息采取行动更进一步。一个强大的数据模型为代理提供了一个清晰的关于他们所处世界的理解，确保做出明智的决策，而不是貌似合理的猜测。
代理不仅仅是生成文本，他们还会查询、更新和对运营系统采取行动。为了可靠地做到这一点，他们需要定义其运营世界规则的结构化数据模型。
一个结构良好的数据模型使代理能够理解实时关系、执行计划并通过工具调用和 API 与企业系统交互。如果没有结构，代理将面临不可靠的问题，并且无法完全参与业务逻辑或执行复杂的工作流程。
数据模型是代理（和所有 AI 应用程序）的真实来源，使他们能够：
- 验证和优化输出——强大的数据模型可确保 AI 生成的响应与实际业务逻辑保持一致，从而减少错误和幻觉。
- 理解实时关系——代理需要业务实体的结构化表示，以便理解不断变化的数据。
- 实现与下游系统的互操作性——AI 应用程序和代理不是孤立运行的；它们的输出将被多个服务（如数据仓库和其他分析系统）使用。生成符合已知数据模型的数据有助于促进此过程。
- 提高编排和可靠性——明确定义的输入和输出有助于协调多个代理，确保他们有效地协同工作。
- 支持工具调用和自动化——无论是检索客户记录、管理库存还是执行工作流程，代理都依赖于结构化数据来以有意义的方式与企业应用程序交互。
数据建模已经远远超出了其严格的关系型、实体关系根源。
如今，多语言数据建模支持各种数据类型和来源，包括关系表、分层 JSON、图数据库、API 和文档存储。这种灵活性对于 AI 应用程序至关重要，因为它们实时地使用和处理来自多个结构化和非结构化来源的数据。它将这些不同的数据表示形式统一到一个 AI 应用程序可以使用的模型中。
通过集成来自不同数据库、API、查询引擎和文档存储的数据，这种方法简化了跨运营和分析数据源的模型提取、设计和演变。开发人员使用建模工具通过 REST API 或模式创建数据协定，确保 AI 访问实时运营数据。
传统的数据模型是为特定系统构建的，关系型数据库用于事务处理，文档数据库用于灵活性，图数据库用于关系。但人工智能需要同时使用所有这些模型，因为人工智能代理可能会首先与事务数据库通信，以获取企业应用程序数据，例如我们之前示例中的航班时刻表。然后，根据该响应，查询文档以构建一个提示，该提示使用语义网络表示来进行航班重新安排逻辑。在这种情况下，单一模型格式是不够的。
这就是多语言数据建模是关键的原因。它允许人工智能跨结构化和非结构化数据实时工作，确保知识检索和决策制定都基于业务数据的完整视图。
向量存储在表、文档或外部向量数据库中，充当将人工智能生成的知识与核心业务逻辑联系起来的属性。经典的数据建模原则，无论是实体关系还是领域驱动设计，都可以将向量作为另一个属性合并，确保人工智能输出保持结构化和上下文关联。
人工智能引入了高度的非确定性。
响应各不相同；模型可能会漂移，并且错误可能会以不可预测的方式传播。在可靠性和准确性至关重要的企业环境中，尽可能引入控制至关重要。当发生错误或生成错误数据时，必须有一种方法可以在问题影响运营之前捕获和处理它们。
像 Pydantic 这样的工具（一个 Python 库）使开发人员能够定义具有特定类型和约束的清晰数据模型。通过强制执行这些规则，Pydantic 确保传入数据符合预期格式，从而减少错误并提高数据质量。有关更多信息，请参见文章“Data Validation With Pydantic”。
数据模型为固有的随机过程提供结构和控制。它们强制执行关系、约束和验证，以使人工智能与业务规则保持一致。一个结构良好的多语言模型不仅可以组织数据，还可以添加护栏，减少不确定性并提高人工智能驱动决策的可靠性。
除了传统的数据验证之外，集成本体和知识图谱可以进一步提高人工智能驱动决策的准确性。
最近的研究表明，在问答系统中使用本体进行查询验证和修复可以显着提高响应准确性。例如，将基于本体的查询检查 (OBQC) 与 LLM 修复技术结合使用，将准确率从 16% 提高到 72% 以上，突显了结构化语义表示在人工智能应用中的价值。
通过将精确的数据模型与本体等语义结构相结合，组织可以建立全面的验证框架。这些框架不仅确保数据完整性，还为人工智能系统提供上下文基础，从而带来更准确和可靠的结果。
前面，我们概述了人工智能应用程序中数据建模的五个关键目标。下面，我们将探讨多语言数据建模如何应对这些挑战中的每一个。
人工智能可能会产生看似合理但不正确的响应。
多语言模型对结构化数据和向量数据应用约束。这些约束在物理模式中强制执行，确保所有数据源保持完整性。
域标准化跨 API 和数据库的关键数据类型。无论是处理客户 ID、订单号还是产品 SKU，域都可以确保一致的验证和强制执行，从而降低人工智能生成错误的风险。
人工智能代理需要推理动态的实时数据，而不仅仅是静态的、预先聚合的知识。
多语言模型支持语义网络结构和知识图谱，使人工智能能够映射结构化数据和非结构化数据之间的关系。这对于同时处理来自多个来源的信息的代理尤其有价值。
此外，一致性维度标准化了跨系统表示关键业务实体（例如客户、交易和产品）的方式。这确保了从 CRM 和支持数据库检索客户数据的人工智能代理理解它们指的是同一个人，从而防止碎片化或误导性的见解。
人工智能应用程序很少孤立运行；它们必须与多个系统、数据源和服务交互。
多语言模型建立了一个通用的模式框架，确保人工智能代理可以跨不同的应用程序一致地查询、转换和共享数据。一致性维度和域为人工智能系统创建了一种共享语言，从而更容易对齐结构化和非结构化数据源。 通过定义灵活、可演进的模式，多语言建模使 AI 能够动态地加入数据流，从而支持随着业务需求变化而进行的模式演变。AI 应用程序可以无缝地适应新的数据源，而无需进行大量的返工。
如果没有结构化的编排，AI 代理可能会面临不一致和重复的风险。
多语言数据模型通过标准化代理通信、交换数据和跟踪工作流程的方式来改进编排。通过定义实体之间清晰的关系，它们使代理能够在多次交互中保持共享的上下文，即使工作流程动态演变，也能确保一致性。
AI 不仅仅是生成响应，它还必须执行操作，无论是检索客户记录、处理订单还是触发工作流程。
多语言模型将企业数据与 AI 驱动的自动化连接起来，以实现实时函数调用。代理可以与 API 和事务数据库交互，同时保持对基于业务规则的有效操作的结构化理解。
随着 AI 应用程序的发展，多语言模型允许对模式和 API 进行改进和扩展，从而确保 AI 系统与运营需求保持一致。无论是与 ERP 系统、库存数据库还是消息传递平台集成，结构良好的数据模型都为 AI 提供了自信地采取行动所需的接口。
AI 的好坏取决于它所理解的数据。强大的数据模型使其保持基础，确保准确的输出、实时推理和无缝的系统集成。
通过多语言数据建模左移，弥合了结构化和非结构化数据之间的差距，增强了完整性，并使 AI 可靠。AI 不会取代数据建模；它运行在数据建模之上。