为什么人工智能项目从数据开始

熟悉的轨迹：试点在上传三个文件时显示出出色的结果，决定获得批准，开始连接真实来源 - 然后质量崩溃。原因几乎总是相同的。在试点中，数据是手动准备的：一个人选择当前文件，扔掉重复项，并更正日期格式。产品中没有这样的人，但有六个系统，每个系统都有自己的交易对手目录，以及对什么是“活跃合约”的自己的想法。

该模型并没有消除数据中的矛盾，而是强化了这些矛盾并使它们令人信服。 如果报告显示两个不一致的数字并提出问题，语言模型将选择一个数字并以连贯的文本进行解释。这比错误更糟糕：错误是显而易见的，但自信错误的答案则不然。

1. 可用性

数据应以编程方式检索，而不是由人员根据请求下载。如果实现数字化的唯一方法是要求同事上传，那么原则上自动化是不可能的。

2. 一致性

一种本质-一种定义。只要“收入”在报告和 CRM 中的计算方式不同，并且没有在任何地方明确说明其具体含义，则该模型的任何答案都将引起争议。你不应该从一本完整的字典开始，而应该从两打关键指标开始，围绕这些指标做出决策。

3. 起源

每个值都必须有一个可追踪的路径：来自哪个系统、通过什么转换、何时转换。如果没有这个，就不可能检查答案、分析事件或向监管机构解释该数字的来源。

4. 区别

权限应该是数据的属性，而不是特定于应用程序的设置。否则，每个新的人工智能场景都需要单独分析“谁可以做到这一点”，并且在某些时候会跳过分析。

5.新鲜度

每组都有一个可接受的延迟，用户必须理解它。基于一周前数据的答案并没有错——如果不这么说，那就很危险了。

大多数企业人工智能场景不是使用表格，而是使用文档：法规、合同、协议、信件。这有它自己的要求，通常的存储做法是不直接转移的。

• 切片。 该文档被分成多个片段。太小会失去上下文，太大会模糊搜索。按语义部分分区几乎总是比按字符数分区更好。
• 片段元数据。 来源、章节、日期、版本、所有者、印章。没有它们，就无法归因响应，也无法应用权利。
• 重复数据删除和相关性。 这种情况在企业存储库中很常见：法规有七个版本，其中之一已经生效。如果所有七个都包含在索引中，系统将自信地引用被取消的一个。
• 片段级定界。 文件可以公开，但其附件则不能公开。
• 索引更新。 我们需要一个过程：源的变化如何以及在什么时间到达索引。一次性下载几周后就会过时。
• 识别质量。 没有文本层的扫描件和 PDF 在输入时会产生垃圾；这是一部不容错过的独立作品。

这项工作的工程部分是 Enterprise RAG。在有限画像上检验假设的成本更低： RAG飞行员 它使用一个真实的知识库，显示答案的质量和文档的状态。

“让我们先构建存储，然后三年后我们将致力于人工智能”的结论与尝试完全不使用数据一样错误。工作订单是特定场景的狭窄画像，随着有用而扩展。

• 步骤1：选择具有可衡量价值的场景。 不是“实施人工智能”，而是“减少准备响应客户请求的时间”。盘点公司已经使用的场景和AI—— AI-discovery.
• 步骤2：仅解析此场景的数据。 什么来源、什么质量、什么权利、什么可接受的滞后。工作量变得可见。
• 步骤 3. 弥补发现的差距。 通常，这些是两到三本参考书、一本度量定义和一本更新过程。
• 步骤 4. 在真实数据上进行试验，而不是在上传数据上进行试验。 这是检查真正损坏的唯一方法。
• 步骤5.工业环境。 脚本传输到通用平台—— Restart AI Enterprise Platform，——下一个场景是在现成的基础上开始的。

另外：如果脚本不需要真实的个人数据， 掩饰和人格解体 取消了一半的审批并显着加快了试点速度。

• 与场景相关的源列表以及对每个源的编程访问方法是已知的。
• 对于关键指标，有书面记录的商定定义。
• 目录被合并：一个实体不存在于四个标识符下。
• 价值观的起源要追溯到源系统。
• 每组可接受的延迟都是已知的，并且对用户来说是可见的。
• 权限被描述为数据属性而不是单个应用程序设置。
• 对于文档：定义了切割规则、元数据的组成以及更新索引的过程。
• 无效的文档版本被排除在索引之外。
• 没有文本层的扫描件和 PDF 会被处理或故意排除。
• 它定义了哪些数据根本不能发送到模型，并且这种限制在技术上是强制执行的。
• 定期进行质量检查，而不是试点前的一次性清洁。