通过可观测性确保数据与AI的可靠性

第 3 章. 数据+人工智能可观察性的支柱

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在本章中，我们将参考常见的技术和架构，为确保可靠的数据+人工智能产品提供可行的见解。这些技术会随着时间的推移而变化。然而，更大的支柱，特别是异常类型及其根本原因，将更加持久。这是因为它们与数据+人工智能的生命周期息息相关。引用 O'Reilly 的经典著作，即 Joe Reis 和 Matt Housley 所著的《数据工程基础》（Fundamentals of Data Engineering），"自数据诞生以来，我们看到了无数具体技术和供应商产品的兴衰，但数据工程生命周期的各个阶段却基本保持不变"。

监测异常包括了解要测量的输出属性或指标，然后识别传统行为的异常值。根本原因分析包括审查整个生产流程的遥测数据，以确定最有可能导致异常的变化或错误。

关键是要明确定义要测量的指标，以及在非结构化数据、结构化数据和人工智能系统生命周期的每个阶段要收集的遥测数据。让我们一起来看看。

非结构化数据

当人工智能检索参考数据时，数据必须是可用的、可发现的、最新的、无偏见的和有用的。这与数据质量的许多传统维度非常吻合，包括完整性、新鲜度、唯一性和有效性/一致性。

具有讽刺意味的是，对非结构化数据进行这种级别的监控所面临的主要挑战之一就是缺乏结构。过去五年来，随着我们在湖泊上建造房屋，非结构化数据管理已成为主流趋势，而解决这一质量难题的最佳实践就是增加结构。

让我们倒退一下。企业 80% 以上的数据都是以非结构化文本、视频或音频的形式存在于列式表格之外。这些数据散落在整个企业成千上万个源系统中的数千万个文件中。对每个源进行监控成本高、效率低，而且不切实际。

数据+人工智能团队通常会将关键的非结构化数据文件整合到云对象存储中（有时也会直接整合到仓库或湖泊中），然后再将文本分解成较小的块，再将其转化为可由人工智能检索和引用的向量嵌入。

其中许多流程都围绕着半结构化 JSON 文件、向量数据库，或作为仓库/湖库中的块和嵌入表。不同的团队会根据自己的用例和成熟度使用不同的架构。

利用专门构建的向量数据库通常是最简单、最具成本效益的途径，尤其是在支持单一用例时。在交谈中，我们发现规模较小的组织更倾向于使用 Pinecone、Qdrant 和 PostgreSQL 等向量数据库，而规模较大的企业则会更多地使用 Azure AI Search 和 MongoDB。

一个越来越流行的趋势是，数据+人工智能团队会创建多用途嵌入式数据库，或可支持多种用例的嵌入式数据库。结构化数据工程中从ETL 到 ELT的转变就是一个类比。ETL 管道是为单一用例（通常是报告或仪表板）而建立的，用于摄取和转换数据。如今，更现代化的 ELT（提取、加载、转换）管道从各种来源收集数据，并创建一套标准的指标，嵌入式分析师和其他人员可以根据业务需求的发展进行自助服务。

与 ETL 到 ELT 的转变一样，多用途嵌入管道更加复杂，但最终更加模块化、可扩展性和敏捷性。处于这种成熟度的数据+人工智能团队通常会使用仓库或湖泊作为嵌入存储和中央真相源。这就需要加强管理。

正如一家大型企业的数据科学家向我们解释的那样："我们使用[数据仓库]是为了方便内部服务。我们正在尝试如何最大限度地利用我们的嵌入式数据，这样我们就不会有团队试图重建和重复工作，即使将它们存储在仓库中会更昂贵一些。每个人都可以访问"。

在这些基于仓库或湖泊的架构中，库存表通常充当云存储中所有文件的目录，并在整理过程中加以利用。分块表和嵌入表用于捕获相关的元数据，以帮助检索，并提供对编码到特定嵌入中的数据的可见性（因为向量是人类无法理解的）。 ...