login
BSL应对业务规则能力研究
2025/09/05·StepFun can make mistakes, check important info.
我想深入研究bsl应对潜在业务规则的能力，举个例子，当采购提问“中类的销售怎么样？” 背后隐藏的业务规则是筛选业态类型为1 2 和4的值，同时排除已经闭店的门店。这类隐藏业务规则需要让AI记住吗，还是说，BSL及其背后的ibis可以隐藏这些规则，让AI专注于维度和指标的提取？

Requirement clarification

报告

BSL应对业务规则的能力研究：隐式规则处理策略

1. 引言：业务规则的复杂性与挑战

在企业数据分析场景中，业务规则往往隐藏在简单的查询表述背后。正如您提到的例子，当采购人员询问"中类的销售怎么样？"时，实际上隐含了多个业务规则：筛选业态类型为1、2和4的值，同时排除已经闭店的门店。这类隐式业务规则的处理是数据解读智能体面临的关键挑战之一。

本研究将深入探讨BSL(Boring Semantic Layer)应对这类潜在业务规则的能力，分析不同的处理策略，并提出最佳实践建议。

2. BSL与业务规则的关系分析

2.1 BSL的核心设计理念

BSL作为一个语义层框架，其核心设计理念是将业务概念映射到数据操作。在BSL中，业务概念通过维度(dimensions)和度量(measures)来表示，这些定义可以包含复杂的业务逻辑。

python

这种设计使得BSL能够在语义层面封装业务规则，而不需要在查询时显式指定这些规则。

2.2 Ibis的表达能力

BSL背后的Ibis提供了强大的表达能力，能够处理复杂的数据操作和业务规则。Ibis支持条件表达式、窗口函数、子查询等高级特性，这使得它能够表达几乎任何SQL可以表达的业务规则。

python

这种表达能力使得BSL能够在语义层面封装复杂的业务规则，而不需要在查询时显式指定这些规则。

3. 业务规则处理策略对比

针对"中类的销售怎么样？"这类包含隐式业务规则的查询，我们可以采取以下几种处理策略：

3.1 AI记忆策略

核心思想：让AI通过记忆机制记住这些业务规则，在解析用户查询时自动应用这些规则。

实现方式：

  • 在AI的提示(prompt)中包含常见业务规则
  • 使用Cognee等记忆组件存储和检索业务规则
  • 在查询解析阶段，AI自动添加这些隐式规则

优势：

  • 灵活性高，AI可以根据上下文决定是否应用特定规则
  • 可以处理复杂的条件逻辑和例外情况
  • 随着交互增多，AI可以学习新的业务规则

劣势：

  • 依赖AI的记忆能力和理解能力，可能不稳定
  • 规则可能随时间变化，需要定期更新AI的知识
  • 不同用户可能有不同的规则理解，导致混淆

3.2 BSL封装策略

核心思想：在BSL的语义层定义中直接封装业务规则，使其成为维度和度量定义的一部分。

实现方式：

  • 在维度定义中包含默认过滤条件
  • 创建"业务视图"，预先应用常见的过滤规则
  • 使用派生维度表示特定业务场景

优势：

  • 规则一致性高，所有查询都应用相同的规则
  • 维护简单，规则变更只需修改BSL定义
  • 减轻AI负担，AI只需关注维度和指标的提取

劣势：

  • 灵活性较低，难以处理需要临时覆盖规则的情况
  • 可能导致BSL定义复杂化
  • 用户可能不清楚默认应用了哪些规则

3.3 混合策略

核心思想：结合AI记忆和BSL封装的优势，根据规则的性质选择最合适的处理方式。

实现方式：

  • 核心业务规则在BSL中封装
  • 上下文相关规则由AI通过记忆机制处理
  • 使用元数据标记规则的来源和适用范围

优势：

  • 平衡了一致性和灵活性
  • 可以处理不同类型的业务规则
  • 系统可以随着使用逐渐优化规则处理

劣势：

  • 实现复杂度高
  • 需要明确规则的分类和处理策略
  • 可能存在规则冲突的情况

4. BSL封装业务规则的技术实现

4.1 基于维度定义的规则封装

在BSL中，我们可以通过维度定义直接封装业务规则。以"中类的销售"为例，我们可以创建一个特殊的"有效中类销售"维度，其中包含了业态类型和门店状态的过滤条件：

python

这样，当用户查询"中类的销售怎么样？"时，AI可以直接映射到valid_subcategory_sales维度，而不需要记住具体的过滤条件。

4.2 基于度量定义的规则封装

另一种方法是在度量定义中封装业务规则。我们可以创建特定的度量，如"有效销售额"，其中包含了业务规则：

python

这种方法的优势是可以同时提供原始度量和应用了业务规则的度量，用户可以根据需要选择使用哪一个。

4.3 基于视图的规则封装

BSL还支持创建"视图"，这些视图可以预先应用一组业务规则，简化后续的查询：

python

这种方法的优势是使语义模型定义更加简洁，同时确保所有查询都应用了相同的业务规则。

4.4 参数化规则封装

对于可能需要灵活调整的业务规则，我们可以使用参数化的方式封装：

python

这种方法允许在特殊情况下覆盖默认的业务规则，提供更大的灵活性。

5. 案例分析：采购场景中的业务规则处理

让我们深入分析采购场景中"中类的销售怎么样？"这个查询的处理流程，比较不同策略的效果：

5.1 AI记忆策略处理流程

  1. 用户查询："中类的销售怎么样？"

  2. AI解析：

    • 识别出查询涉及"中类"维度和"销售"指标
    • 从记忆中检索相关业务规则：筛选业态类型为1、2和4，排除闭店门店

  3. 生成BSL查询：

    json

  4. 执行查询并返回结果

评估：这种方法依赖AI正确记忆和应用业务规则，可能存在不一致性风险。

5.2 BSL封装策略处理流程

  1. 用户查询："中类的销售怎么样？"

  2. AI解析：

    • 识别出查询涉及"中类"维度和"销售"指标
    • 映射到BSL中的valid_subcategory_sales维度和valid_sales度量

  3. 生成BSL查询：

    json

  4. 执行查询并返回结果

评估：这种方法确保了规则的一致性，但需要AI正确映射到封装了规则的维度和度量。

5.3 混合策略处理流程

  1. 用户查询："中类的销售怎么样？"

  2. AI解析：

    • 识别出查询涉及"中类"维度和"销售"指标
    • 检查是否有特殊上下文需要覆盖默认规则

  3. 生成BSL查询：

    • 如果没有特殊上下文，使用默认的封装了规则的模型：
      json
    • 如果有特殊上下文（如用户明确要查看所有门店），使用参数化模型：
      json

  4. 执行查询并返回结果

评估：这种方法平衡了一致性和灵活性，但实现复杂度较高。

6. 最佳实践建议

基于上述分析，我们提出以下最佳实践建议：

6.1 业务规则分类与处理策略

将业务规则分为以下几类，并采用不同的处理策略：

  1. 核心业务规则：几乎所有查询都需要应用的规则，如数据质量过滤、基本业务限制等。

    • 建议：在BSL的视图或基础模型中封装，确保一致性。

  2. 领域特定规则：特定业务领域（如采购、销售）适用的规则。

    • 建议：创建领域特定的语义模型，在模型中封装这些规则。

  3. 上下文相关规则：根据用户角色、查询上下文等动态变化的规则。

    • 建议：使用AI记忆和参数化模型结合的方式处理。

  4. 临时规则：用户在特定查询中明确指定的规则，可能覆盖默认规则。

    • 建议：由AI识别并生成适当的查询参数。

6.2 BSL设计原则

在设计BSL语义模型时，考虑以下原则：

  1. 默认安全原则：默认应用核心业务规则，确保数据质量和业务一致性。

  2. 命名透明原则：使用清晰的命名约定，区分原始维度/度量和应用了规则的维度/度量。

    • 例如：sales vs valid_sales，subcategory vs active_subcategory

  3. 分层模型原则：创建多层语义模型，从基础模型到领域特定模型，逐层应用业务规则。

  4. 元数据标记原则：使用元数据标记维度和度量上应用的业务规则，便于AI理解和解释。

6.3 AI与BSL协作模式

设计AI与BSL的协作模式，明确职责分工：

  1. BSL负责：

    • 封装核心业务规则和领域特定规则
    • 提供一致的数据视图和计算逻辑
    • 执行高效的数据操作

  2. AI负责：

    • 理解用户意图和查询上下文
    • 选择合适的语义模型和维度/度量
    • 处理临时规则和特殊请求
    • 解释查询结果，包括应用的业务规则

  3. 协作机制：

    • BSL提供模型元数据，帮助AI理解可用的维度、度量及其包含的规则
    • AI在生成查询时，明确指定使用哪个语义模型，以及是否需要覆盖默认规则
    • BSL执行查询后，返回应用的规则信息，便于AI解释结果

7. 实施路径与技术架构

7.1 BSL业务规则封装架构

我们建议采用以下架构来实现业务规则的封装：

text

这个架构包含三个主要组件：

  1. 语义模型注册表：管理不同级别的语义模型，从基础模型到领域特定模型。

  2. 模型选择器：根据查询上下文和用户需求，选择合适的语义模型和配置。

  3. 查询执行器：生成和执行Ibis查询，处理查询结果。

7.2 实施路径

我们建议采用以下分阶段实施路径：

  1. 第一阶段（1-2个月）：

    • 识别和分类核心业务规则
    • 在BSL中实现基础语义模型，封装核心业务规则
    • 实现简单的模型选择机制

  2. 第二阶段（2-3个月）：

    • 实现领域特定模型，封装更多业务规则
    • 增强AI对模型选择的理解能力
    • 开发规则冲突解决机制

  3. 第三阶段（持续优化）：

    • 实现参数化模型和用户定制功能
    • 优化规则管理和更新流程
    • 增强结果解释能力，包括应用的业务规则

8. 结论与建议

8.1 总结发现

通过本研究，我们发现：

  1. BSL具有强大的业务规则封装能力，可以通过维度定义、度量定义、视图和参数化模型等多种方式封装规则。

  2. 业务规则可以分为核心规则、领域特定规则、上下文相关规则和临时规则，需要采用不同的处理策略。

  3. AI与BSL的协作模式对于处理业务规则至关重要，需要明确职责分工和协作机制。

8.2 最终建议

针对"中类的销售怎么样？"这类包含隐式业务规则的查询，我们建议采用BSL主导的混合策略：

  1. 在BSL中封装核心业务规则：

    • 创建包含业态类型和门店状态过滤的基础视图
    • 在视图基础上定义语义模型，确保规则的一致性

  2. 使用AI进行模型选择和参数配置：

    • AI理解查询上下文，选择合适的语义模型
    • 在特殊情况下，AI可以请求覆盖默认规则

  3. 提供清晰的结果解释：

    • 在查询结果中包含应用的业务规则信息
    • AI解释结果时，明确说明应用了哪些默认规则

这种方法既确保了业务规则的一致性，又保留了一定的灵活性，能够满足大多数数据解读场景的需求。

8.3 实施建议

在实施这一策略时，我们建议：

  1. 从核心规则开始：先识别和封装最重要、最常用的业务规则。

  2. 建立规则管理流程：创建业务规则的文档和更新流程，确保规则的准确性和时效性。

  3. 增强元数据管理：为维度和度量添加丰富的元数据，包括应用的业务规则信息。

  4. 用户反馈循环：收集用户对查询结果的反馈，持续优化规则封装和处理策略。

通过这些措施，您可以构建一个既能保证数据一致性，又能满足灵活分析需求的数据解读智能体系统。

好的，这是一个关于如何研究BSL（业务语义层）处理潜在业务规则能力的计划框架。

Research plan
  1. 明确业务语义层（BSL）和Ibis框架的核心概念，重点研究它们如何在数据查询中抽象和封装业务逻辑。可在Ibis官方网站、相关技术博客（如Medium、Towards Data Science）中查找其设计理念和应用案例。
  2. 深入研究Ibis框架封装复杂规则的能力，特别是在其维度和指标定义中嵌入过滤条件、排除逻辑或复杂计算的方法。可在Ibis官方文档、GitHub项目示例和Stack Overflow社区中查找相关技术实现。
  3. 研究让AI智能体自身“记住”并应用业务规则的实现方式，例如通过检索增强生成（RAG）从知识库调用规则，或通过长期记忆组件存储上下文。可在arXiv、Google Scholar及主流AI研究机构的博客中查找相关论文和技术文章。
  4. 对比分析两种策略的优劣势：将规则硬编码在BSL中，与让AI动态应用规则，重点评估它们在规则变更时的维护成本、查询透明度、可扩展性和准确性。
  5. 构思一种混合解决方案，即将稳定不变的核心业务规则（如门店状态）固化在BSL中，而将易变或特定于对话的临时规则交由AI的记忆组件管理。
  6. 综合所有研究信息，形成一份结构化的对比分析报告，为“AI应专注于维度指标提取，将规则隐藏于BSL”这一核心问题提供明确的、有数据支持的建议。
开始研究

Deep Research

BSL应对潜在业务规则的能力研究：封装复杂逻辑与智能体分工

1. 引言：业务规则的挑战

在构建数据解读智能体系统时，我们经常面临一个关键问题：如何处理那些隐藏在简单查询背后的复杂业务规则。例如，当采购人员询问"中类的销售怎么样？"时，这个看似简单的问题背后可能隐藏着复杂的业务规则，如需要筛选特定业态类型(1、2和4)，同时排除已闭店的门店。这类规则如果需要AI每次都"记住"并正确应用，将大大增加系统的复杂性和出错风险。

本研究将深入探讨BSL(Boring Semantic Layer)及其背后的Ibis框架在处理这类潜在业务规则方面的能力，并分析是将这些规则编码在BSL中还是让AI记住它们的优劣势。

2. BSL与Ibis框架的业务规则封装能力

2.1 BSL的核心设计理念

BSL(Boring Semantic Layer)是一个轻量级语义层工具，它的核心设计理念是将业务概念映射到数据操作，使得复杂的数据分析任务可以通过声明式API完成，而无需生成SQL。BSL通过定义维度和度量，将业务逻辑封装在预定义的函数中，从而简化数据查询和分析过程。

在BSL中，维度和度量的定义方式如下：

python

这种设计将复杂的数据分析逻辑封装在预定义的lambda函数中，使得查询变得简单而直观。

2.2 Ibis框架的表达能力

Ibis是BSL的底层支持框架，它提供了一个统一的Python API，能够自动转换为针对不同数据库后端的优化SQL。Ibis的表达能力非常强大，可以处理复杂的过滤条件、连接操作和聚合函数。

Ibis允许在表达式中嵌入复杂的业务规则，例如：

python

这种方式允许我们将业务规则直接编码到BSL的度量定义中，使得这些规则对用户和AI智能体都是透明的。

3. 业务规则处理策略对比

3.1 策略一：将业务规则编码在BSL中

将业务规则编码在BSL中意味着在语义层定义维度和度量时，直接嵌入相关的过滤条件和业务逻辑。

优势：

  1. 一致性保证：业务规则被统一定义在一处，确保所有查询都应用相同的规则，减少不一致性风险。

  2. 维护简化：当业务规则变更时，只需修改BSL定义，而不需要更新AI模型或知识库。

  3. 性能优化：业务规则直接转换为SQL的一部分，可以利用数据库优化器提高查询性能。

  4. 减轻AI负担：AI可以专注于理解用户意图和提取相关维度/指标，而不需要记住和应用复杂的业务规则。

劣势：

  1. 灵活性受限：难以处理需要动态变化或上下文相关的业务规则。

  2. 透明度降低：最终用户可能不清楚查询结果背后应用了哪些业务规则。

  3. 规则爆炸：随着业务规则增多，BSL定义可能变得复杂且难以维护。

3.2 策略二：让AI记住并应用业务规则

这种策略要求AI智能体通过某种形式的记忆机制(如Cognee)记住业务规则，并在处理用户查询时动态应用这些规则。

优势：

  1. 灵活性高：AI可以根据上下文和用户需求动态应用不同的业务规则。

  2. 透明度提高：AI可以向用户解释应用了哪些业务规则及其原因。

  3. 适应性强：可以更容易地适应新的业务规则或特例情况。

劣势：

  1. 一致性风险：不同会话或不同时间可能应用不同的规则，导致结果不一致。

  2. 复杂性增加：AI需要额外的记忆组件和推理能力来正确应用业务规则。

  3. 性能开销：动态应用规则可能增加处理时间和资源消耗。

  4. 错误风险：AI可能错误理解或应用业务规则，导致查询结果不准确。

4. 混合策略：分层业务规则管理

基于上述分析，我们提出一种混合策略，将业务规则分为不同层次，并采用不同的处理方式：

4.1 核心业务规则：编码在BSL中

核心业务规则是那些稳定、普遍适用且关键的规则，如：

  1. 数据质量规则：排除无效或错误的数据记录
  2. 业务实体定义：如活跃门店的定义(排除已关闭门店)
  3. 标准计算逻辑：如销售额、毛利率的标准计算公式

这些规则应该直接编码在BSL的维度和度量定义中，确保所有查询都一致地应用这些基础规则。

4.2 上下文相关规则：由AI动态应用

上下文相关规则是那些依赖于特定分析场景或用户偏好的规则，如：

  1. 特定分析视角：如某用户总是关注高端产品线
  2. 临时过滤条件：如"仅考虑节假日销售"
  3. 特殊比较基准：如"与去年同期相比"

这些规则可以由AI通过记忆组件(如Cognee)记住并动态应用，提供更个性化的分析体验。

5. 实现方案：BSL中的业务规则封装

5.1 维度定义中的规则封装

在BSL中，我们可以在维度定义中封装业务规则，例如：

python

5.2 度量定义中的规则封装

更常见的是在度量定义中封装业务规则：

python

5.3 复合过滤器的定义与复用

对于需要在多个地方使用的复杂业务规则，我们可以定义可复用的过滤器函数：

python

6. 案例分析：采购询问"中类的销售怎么样？"

让我们以用户提出的案例为例，分析如何处理"中类的销售怎么样？"这一查询背后的业务规则。

6.1 业务规则分析

这个查询背后的业务规则包括：

  1. 筛选业态类型为1、2和4的值
  2. 排除已经闭店的门店

这些规则属于核心业务规则，因为它们定义了"有效销售数据"的基本范围，应该在所有相关查询中一致应用。

6.2 BSL实现方案

python

6.3 AI与BSL的交互流程

当采购人员询问"中类的销售怎么样？"时，系统的处理流程如下：

  1. AI理解查询意图：识别用户想要查看按中类(category)维度的销售情况。

  2. AI提取维度和指标：

    • 维度：category(中类)
    • 指标：sales(销售额)

  3. AI生成BSL查询指令：

    json

  4. BSL执行查询：BSL接收查询指令，自动应用预定义的业务规则(筛选特定业态类型和排除闭店)，生成并执行SQL查询。

  5. 返回结果：查询结果返回给AI，AI生成自然语言解释并呈现给用户。

在这个流程中，AI只需要专注于理解用户意图和提取相关维度/指标，而不需要记住和应用复杂的业务规则。业务规则被透明地封装在BSL的度量定义中，确保查询结果的一致性和准确性。

7. 结论与建议

7.1 核心结论

基于我们的研究，我们得出以下核心结论：

  1. BSL非常适合封装稳定的业务规则：BSL及其背后的Ibis框架提供了强大的表达能力，能够在维度和度量定义中封装复杂的业务规则，使这些规则对用户和AI透明。

  2. AI应专注于意图理解和维度/指标提取：让AI记住和应用复杂的业务规则会增加系统的复杂性和出错风险。相比之下，让AI专注于理解用户意图和提取相关维度/指标，将业务规则封装在BSL中，能够提供更一致、更可靠的查询结果。

  3. 分层业务规则管理是最佳实践：将稳定的核心业务规则编码在BSL中，而将上下文相关的临时规则交由AI通过记忆组件管理，能够平衡一致性和灵活性的需求。

7.2 实施建议

基于上述结论，我们提出以下实施建议：

  1. 识别并分类业务规则：

    • 核心业务规则：稳定、普遍适用且关键的规则
    • 上下文相关规则：依赖于特定分析场景或用户偏好的规则

  2. 在BSL中封装核心业务规则：

    • 使用可复用的过滤器函数定义常用业务规则
    • 在维度和度量定义中应用这些过滤器
    • 为常用的过滤后度量提供默认别名(如sales默认指valid_sales)

  3. 利用AI记忆组件处理上下文相关规则：

    • 使用Cognee等记忆框架记住用户偏好和分析习惯
    • 在适当的情况下，让AI提示用户确认是否应用特定的上下文规则

  4. 提供规则透明度：

    • 在查询结果中标注应用了哪些业务规则
    • 允许用户查询和修改当前应用的规则

通过这种方式，我们可以构建一个既能保证数据一致性，又能提供个性化分析体验的数据解读智能体系统。

7.3 未来展望

随着业务需求的不断变化和技术的不断发展，业务规则的管理也将面临新的挑战和机遇。未来的研究方向包括：

  1. 自适应业务规则：开发能够根据数据特征和用户行为自动调整的业务规则

  2. 规则学习机制：使AI能够从用户交互中学习新的业务规则并提出建议

  3. 规则冲突解决：开发智能机制处理不同层次或来源的业务规则之间的冲突

  4. 规则解释能力：增强AI解释应用了哪些业务规则及其影响的能力

通过持续的研究和创新，我们可以不断提升BSL和AI在处理复杂业务规则方面的能力，为用户提供更智能、更可靠的数据解读服务。