自 ChatGPT 发布以来，大语言模型 (LLM) 已进入主流，促使各行各业和公司纷纷探索其在业务转型中的潜力。此后，许多技术应运而生，帮助团队构建更强大的 AI 系统：RAG、向量数据库、重排序器、推理模型、工具使用、MCP、代理框架等等。这些工具和技术显然很有用；然而，提升 AI 系统业务影响力的最有效方法依然是数据。
人工智能系统需要访问公司数据
在企业中，AI需要输入数据才能发挥作用。这催生了RAG（检索增强生成）架构。根据不同用例，输入数据可以是任何内容；可以是合同、采购订单、工程文档、制造流程等等。
现在假设我们想要实现一个在航空公司提供客户服务的人工智能聊天机器人，这是一个典型的用例。让我们从这个用例的基本 RAG 架构开始，并将其分解为主要步骤：
通过收集执行客户服务所需的文件（如公司退款政策、航班重新安排指南以及规则或客户忠诚度计划）来构建知识库。
- 索引和分块文档，生成嵌入并将其存储在向量数据库中
- 根据与用户查询的相似性，在推理时检索前 k 个文档块
- 使用这些文档块来增强提示并生成显示给用户的响应
你需要管理这些数据，以确保高质量的人工智能输出和数据保护
我们上面解释的 RAG 流水线非常简单。你可以添加许多花哨的功能来让它更加精美，这从 AI 工程的角度来看非常诱人。然而，从业务角度来看，在数据层工作更为合理和有效。以数据为先的方法构建企业级 AI，将打造一个对最终用户和整个企业都有用的系统。知识存储可能是许多 AI 响应质量低下的根本原因，如下图所示。
从该图中我们可以看到，知识库中提供的文档可能存在几个问题，即：
所提供的文档可能与用例/任务无关，对用户查询毫无价值，只会提供噪音。这种情况可能发生在文档批量提供且未经用例和数据部门业务团队细粒度审查的情况下。
相反，可能会缺少解决当前任务所需的文档，但这些文档并未包含在知识库中。这种情况通常发生在构建知识库的业务团队对公司或特定业务领域内可用/使用的文档缺乏详尽的了解时。
文档可能已经过时，这种情况经常发生在特定文档有版本控制，并且旧版本没有系统地从知识库中删除时。
由于版本控制或公司政策和规则不一致，文档可能会发生冲突。
文档可能包含敏感信息，这是迄今为止最糟糕的故障模式，因为它涉及数据保护问题。如果相同的知识存储用于不同的领域和用户角色，且缺乏适当的索引和权限管理，则可能会发生这种情况（例如，财务文档和制造文档存储在同一个知识存储中）。
数据治理角色正在不断发展壮大，以支持人工智能系统治理和非结构化数据治理
下面的例子说明了建立强有力的治理的重要性。
数据治理将确保企业内部开发的人工智能系统实用且真实，并确保公司数据得到保护。传统上，数据治理主要关注结构化数据、表格和数据库，而较少关注 PDF 文件、PPT 演示文稿和图像等非结构化数据。但 GenAI 的出现正在改变和扩展这一角色，使其涵盖非结构化数据和大规模人工智能系统治理。通过与用例的业务负责人、人工智能技术和数据团队协同工作，数据治理可以对构建安全、准确且可扩展的人工智能系统产生重大影响，从而真正实现业务运营的转型。
我们使用关系数据库已经很久了。您可能是关系数据库设计和建模方面的专家。我见过大多数设计师/开发人员在建模No SQL数据库时都使用关系型方法。甚至在为NoSQL数据库建模时，对我来说，改变关系型思维模式也有点困难。
是的，如果你用关系型数据库建模，那没什么坏处。但如果这样做，那就错了。据你所知，NoSQL 数据库有多种类型，每种类型都有各自的用途。在设计特定类型的数据库时，务必仔细考虑。
