为 AI 就绪设计语义模型
设计良好的语义模型是通过 Tableau Next 中的客服人员分析获得准确和相关见解的关键。它有助于您的 Analytics 客服人员了解数据并自信地回答问题。在设计语义模型时，请构建在 AI 就绪标准和公认的数据建模和数据质量行业最佳实践的基础上。
所需的 Edition
| 查看支持的版本。 |
语义模型功能
为支持 Tableau Next 和 Salesforce 360 之间的代理分析，语义模型必须包含数据模型对象 (DMO)，并可以包含数据湖对象 (DLO)。语义模型可以基于 Tableau Cloud PDS。
语义模型必须包含完整和准确的数据关系图。目前不支持计算见解 (CI)。
语义模型 AI 就绪
构建 AI 就绪的语义模型对于用户 Trust、客服人员绩效和业务灵活性至关重要。通过遵循这些最佳实践，您不仅可以前瞻性地构建数据模型，还可以加快实现可扩展的客服人员驱动的分析。
定义明确的对象和字段名称
客服人员在字段所属的对象的上下文中解释字段。对象和字段名称及标签的清晰性和特异性在 AI 可解释性中起着至关重要的作用。
AI 客服人员使用对象和字段的 API 名称（系统名称，在 Data Cloud 中创建时定义）和标签（显示名称）。
对象上下文和字段属性的组合提高了语义清晰度。虽然像“ID”或“名称”这样的通用标签在孤立的情况下似乎不明确，但是如果它们所属的对象名称正确并且描述清楚，它们是可以接受的。
API 名称在语义模型中创建后无法编辑，因此创建时应谨慎小心。标签可以而且应该根据业务清晰度进行定制。
唯一名称组合
确保对象名称、描述和字段标签的组合足以唯一标识字段的角色和目的。避免缩写。
有意义的相关标签
使用有意义的、与业务相关的显示名称，特别是对于自定义字段。例如，将名为“Customer”的对象与标记为“ID”的字段配对 — 这比“Entity”与“ID”这样的模糊配对更容易解释。
描述性 API 名称
在 Data Cloud 中创建新字段时，选择尽可能具有描述性的 API 名称，以改善下游可解释性。
提供内容丰富、平衡的描述
描述在帮助客服人员准确解释字段和对象方面起着至关重要的作用。
标准对象和字段
对于 Salesforce 标准对象，保留默认描述是可以接受的，因为这些描述在客服人员接受培训的公共 Knowledge 源中广为人知并受到引用。如果用户修改标准对象或字段的描述，它必须是可添加的，并且不与现有 Knowledge 冲突。
使用 Salesforce 标准对象和字段
在设计数据模型时使用 Salesforce 标准对象和字段。客服人员更有可能正确理解和解释标准组件，因为它们更有文档记录，并且在公共培训数据中使用。
自定义对象和字段
对于自定义对象和字段，清晰、信息丰富的描述至关重要。它应反映数据代表的内容，尽可能与行业标准保持一致，并在必要时解释任何独特的内部含义。
清晰描述
提供简洁的 1-2 句话描述，说明：
- 传达业务上下文。例如，购买日期表示发票打印或发送给用户的日期字段。在某些情况下，由于此原因，交易日期和购买日期不同。
- 描述如何在业务中使用。例如，在大多数采购和成本计算相关分析中，采购日期是默认日期筛选器和切片器。
- 很好地代表了数据。查看数据，并确保描述不仅仅描述字段的一般用途。它应该详细说明是否有特定目的的特定数据值。例如 , " NA" 表示尚未确认购买的交易,并与交易状态 = ""待处理""保持一致。
通过询问您最喜欢的聊天工具“如何解释字段字段名称的此描述内容？”，根据客服人员的理解测试新描述。
语义模型
客服人员包含语义模型的描述。包含模型用例和目标的描述至关重要。
描述模型上下文
提供表达目标和用例的语义模型的清晰描述。它提供了关于模型的目的和范围的基本上下文，并提高了客服人员对其内容进行推理的能力。
构建客服人员置信度的模型
连接良好且组织良好的语义模型有助于客服人员正确解释查询并准确回答问题。
岛表或孤立对象（与其他表和对象关系有限或没有关系的表和对象）有时有意在语义模型中为不同的用例创建。这些断开的结构会造成混乱。客服人员和用户可能会误解这些结构，或者尝试将它们当作是连接的一样进行查询，即使没有定义关系。
连接模型内容
确保所有对象都是单个连接的群集的一部分。避免可能触发客服人员无效响应的不明确或未连接的对象。
检测并解决歧义
客服人员通常在解释语义模型时分析完整的组件属性。但是，必须确保任何模糊性都可以仅仅基于标签和描述级别来解决。存在类似的实体或对象、类似的字段、计算字段和度量，有时甚至在计算字段和常规字段之间，都会导致歧义。
Agentforce for Analytics 评估完整的对象属性集，包括对象名称、对象描述、字段显示名称、字段描述、字段数据类型、字段角色、示例值和对象/字段关系，以减少歧义。然而，由于多个字段通常携带类似的数据或服务于重叠的目的，语义模型必须通过精确和有意的元数据清楚地区分它们。
定期运行相似性和模糊性检查
确保创建并添加到语义模型中的每个组件都服务于唯一的目的，并且标签和描述都清楚地反映了这个目的。
语义模型 AI 优化工具包含相似性扫描，可以解决此处描述的大多数情况。在语义模型生成器中使用此工具快速扫描模型并减少相似性。
模糊的常见来源
- 重叠描述 – 模糊或相同的字段描述，无法澄清不同的角色或用法。由于复制和粘贴描述很常见，这通常会导致歧义。
- 类似业务上下文 – 代表相同概念但显示在不同表中的字段（例如订单标题与订单行的“客户区域”）。备注
您可以使用业务首选项在语义模型中定义特定于业务的 Knowledge。这有助于客服人员在业务的独特上下文和逻辑中回答分析问题。
- 同义词或同义词 – 不同名称代表相同概念的字段（同义词），或相同名称代表不同概念的字段（同义词）。
- 出于不同目的和用途而存在两次的对象，但从其语义中看不出有什么不同。以下是一些常见示例：
- 相同对象，不同目的 – 模型中的通用日期字段，用于购买日期和交易日期。
- 相同对象、不同粒度 – 用于在需要时向下搜索到订单级别的详细订单行对象，以及为性能优化创建的订单行的聚合版本。
- 约束解决方法 – 对象在模型中存在多次，具有不同的内容，以规避源模型的限制或约束。例如，用户扩展了一个包含客户对象的基模型，其中只有五个他们需要的字段。因为他们不能调整基本模型，所以添加了额外的客户对象与所有列（现有列和新列）。在具有已发布数据源或逻辑视图的模型中也会遇到这种情况。
管理类似的计算字段和度量
客服人员经常直接分析公式定义，即使标签和描述清楚，也会引入混乱。具有相似或重叠逻辑的计算字段会导致语义模型的误解。相似地，仅通过少量筛选器变化而不同的度量会产生类似的混淆。这些个案应以适用于计算字段的相同严格程度进行管理。
避免进行类似的计算
隐藏或删除无法提供清晰、明确分析目的的计算字段和度量。如果删除不可行，请明确定义它们的角色，并在标签和描述中明确区分它们，以避免公式级别的模糊性。
使用重点语义组件丰富语义模型
语义层应准确地表示业务逻辑，并预测客服人员将如何消费和推理。客服人员了解不同模型组件的相对语义强度。策划的度量和计算逻辑包含更高的意图和清晰度。因此，客服人员优先解释和使用度量，然后是计算字段，最后是原始字段。
作为语义锚的度量
度量是一个高价值的语义对象，旨在清晰地回答特定的业务问题。
度量包含
- 目标计算
- 时间范围逻辑
- 上下文筛选
- 业务一致性格式
定义重要计算的度量
为每个高影响和高度使用的计算字段或字段评测定义度量。这将指导客服人员了解应用特定逻辑的位置和时间。
预定义的计算字段
计算字段应封装客服人员否则需要推断的业务逻辑。提前定义它们可以提高答案质量、减少歧义并提高 Trust。
谨慎使用计算字段
仅包含具有明确分析目的的计算字段。避免用很少使用或过于利基的计算使模型过载。
显式字段类型
在元数据级别将字段分类为评测或维度会增强客服人员推理。它指示数据在分析工作流中的行为方式，例如，作为聚合而不是筛选器。
分配语义角色
将语义角色作为字段类型添加到每个字段。这些提示有助于客服人员在查询中正确应用它们。
验证字段映射
验证字段是否映射到正确类型，以获得优化的客服人员体验。例如，对于日期字段，使用日期的字段类型，而不是文本。这有助于客服人员正确解释日期字段。
AI 就绪列表
在构建语义模型时使用此列表。
标签和描述
- 语义模型描述是特定的，有目的的。
- 所有字段标签都是特定的和上下文相关的（没有“ID”、“名称”或没有限定符）。
- 为所有自定义对象和字段提供描述。
- 标准 Salesforce 字段的描述保持不变或增强，而不会与已知含义产生冲突。
歧义管理
- 确保类似的字段/度量在名称、描述和用途上有所区别。
- 查看逻辑相似的计算字段和常规字段是否存在重叠。
计算字段和度量
- 仅包含必要和可解释的计算字段。
- 澄清或合并仅因筛选器而异的度量。
- 确保每个度量和字段都有明确界定的分析目的。
语义丰富
- 定义度量适用于高影响力的 KPI。
- 使用度量封装时间和上下文逻辑及格式化。
- 为每个字段明确设置字段类型（评测和维度）。
- 验证字段是否映射到正确类型。
模型结构
- 请确保所有对象都是单个连接群集的一部分，以避免误解。避免“孤岛表”或断开连接的数据集群。
