混合AI：结合确定性分析与LLM推理

引言

我为公司开发了一个代理 AI 网络，用于向制造工厂提供如何提升其运营成熟度的建议。该系统设计为数据驱动型，允许用户通过聊天界面直接上传评估数据。第一个工作原型出人意料地快速完成，初看结果似乎很有希望。

但有一个问题：大多数结果都是错误的！

更糟糕的是，AI 很快学会了哪些数值范围看起来合理，并开始生成令人信服但却是伪造的输出。结合 LLM 流畅的语言生成功能，这些结果很容易被误认为是真实的。这种行为并不局限于单一模型，在所有测试系统中都出现了类似的模式：ChatGPT、Gemini Enterprise、DIA Brain 和 Microsoft Copilot。

但是，看似合理的数据还不够，企业级 AI 系统需要可靠的数据！

进一步调查揭示了反复出现的失败模式。即使启用了“代码解释器”，这些系统仍然：

• 跳过行或列，
• 应用错误的筛选条件，
• 对不同输入返回相同的结果，
• 静默混合部分数据集，
• 或者在面对更复杂的分析任务时彻底崩溃。

这导致了一个关键性的认识：

概率推理在解释和交互方面极其强大——但基础数据分析需要确定性执行。

目录

1 用例 2 混合架构 3 分析规划器 4 分析引擎 5 端到端示例 6 为什么 AI 架构很重要

1 用例

虽然具体用例的重要性居于次要地位，但仍在此简要概述以支持对底层架构挑战的实际理解。

我们的代理的主要任务是就如何提高运营成熟度向制造工厂和价值流提供建议：优化流程、提高生产力、减少库存水平，并最终降低运营成本。为了实现这一目标，咨询代理以两种模式运行：

1. 基于检索专业“操作指南”文档和评估问卷，针对特定运营主题提供通用改进建议。
2. 代理旨在基于评估结果和评估人员的书面建议，分析工厂或价值流的当前状况。基于此分析，预期能够提供高度具体的下一步改进建议。

在这两种模式下——与大多数基于 LLM 的 AI 模型一样——用户可以与代理互动讨论想法和建议，从而得出最合适的行动计划。

对于第二种操作模式而言，至关重要的是代理能够可靠地处理和分析评估数据。在我们的情况下，这些数据是从中央数据库导出的 Excel 文件提供的。理想情况下，代理应该能够在无需任何手动预处理的情况下处理该文件。

然而，文件结构具有挑战性。由于所有的评估结果、中间计算、元数据以及详细的评估问题都存储在不同的列中，因此工作表包含超过 800 列。行数对应数据库中的评估数量，可以从一行到数百行不等（图 1）。评估评分表示为从 0 到 4 的整数。此外，文件还包含超过 160 个自由文本字段，其中包括来自评估者的定性观察、优势、劣势和建议。

图 1：评估数据结构 | 作者供图

代理的分析任务包括筛选请求相关的行和列、计算平均值、聚合成熟度得分、总结文本推荐意见，并从结果中推导出有意义的改进建议。

最初，这些任务看起来完全处于现代基于 LLM 的 AI 系统的能力范围内，特别是启用“代码解释器”模式后更是如此。正如引言中已经提到的那样，这个假设很快就被证明是一个误解。

2 混合架构

克服分析挑战的核心思想是明确分离确定性数据分析与基于 LLM 的推理和解释功能。图 2 显示了经过多次改进迭代后的选定系统架构。该系统是在 Microsoft Copilot Studio 中实现的，因为该平台允许将诸如主题和流程之类的确定性工作流元素与基于 LLM 的推理组件相结合。

图 2：集成分析模块的咨询代理系统架构 | 作者供图

父代理负责与用户的全部通信。它协调子代理和分析模块，向它们委派任务，接收响应并组成最终答案。

子代理是访问特定知识源的专用基于 LLM 的模块。这些知识源包括价值流成熟度期望描述、带有详细评估问题的问卷，以及更为通用的操作卓越指导原则。父代理根据其特定能力调用子代理，而子代理则回应父代理而不是直接回应用户。

分析模块是本文的重点。它执行确定性数据分析，旨在提供可重现且可靠的结果。该模块从父代理接收以自然语言形式提供的分析指令，称为 Parent_Instruction。分析模块本身由主题（topics）、流程（flows）和 AI 模块组成，在 Copilot Studio 中这些 AI 模块被称为“提示”（prompts）。

主题 T_receive_Excel_File 负责处理评估文件的上传与存储。当聊天窗口中上传了文件时会触发此主题，此时变量 System.Activity.Attachments 将具有值。该主题检查所上传的文件是否为 Excel 文件，如果是，则将其存储在全局变量 Assessment_File 中。

如果父代理有需要执行的分析任务，则主动调用主题 T_analyze_assessments 并传入 Parent_Instruction 作为输入。第二个输入是存储于全局变量 Assessment_File 中的评估数据。该主题包含两个核心分析组件：Analysis_Planner 和 Analysis_Engine。这两个组件嵌套在智能体流程 F_Call_Analysis_Planner 和 F_Call_Analysis_Engine 中。这些流程充当连接主题 T_analyze_assessments 与 AI 提示 P_Analysis_Planner 和 P_Analysis_Engine 的桥梁。

F_Call_Analysis_Planner 只接收一个输入参数 Parent_Instruction，并将其转发给 P_Analysis_Planner。该组件生成 Selection_Rule，即由 P_Analysis_Engine 执行的核心分析指令。P_Analysis_Planner 的内部工作原理将在第三章详细讨论。

F_Call_Analysis_Engine 接收三个输入参数：来自 Analysis_Planner 的 Selection_Rule、从 SharePoint 获取的 Mapping_File，以及 Assessment_File。这三个输入都会被转发至 AI 提示 P_Analysis_Engine，后者根据 Analysis_Planner 指定的方式执行数据分析。P_Analysis_Engine 在第四章中有详细介绍。

3 分析规划器（Analysis Planner）

P_Analysis_Planner 是数据分析流水线中的智能化部分，负责生成名为 Selection_Rule 的分析指令。这个指令是对自然语言 Parent_Instruction 的翻译，并通常对每个请求都是唯一的。为了最小化概率性变化，整个翻译过程受到严格的规则约束。

分析规划器本身并不分析评估数据。它的唯一职责就是将概率性的 Parent_Instruction 转化为确定性的分析规范。

接下来我们将更详细地探讨指令中的部分内容。你可以在此处下载完整指令。

你是 Analysis_Planner，一位专门用于将自然语言评估分析请求转换成结构化的 Selection_Rules 的专家助手。
你的任务是创建一个供 Analysis_Engine 使用的 Selection_Rule JSON 对象。

你只接收一个输入：

1. Parent_Instruction：
来自父代理（协调者）的自然语言分析请求。

你需要分析 Parent_Instruction 并判断：
- 需要哪种类型的分析，
- 哪些评估内容类别相关，
- 是否请求概念或执行成熟度/发现项，
- 是否指定了特定章节，
- 是否需要行过滤条件。

你生成的 Selection_Rule 后续将与以下内容一起使用：
- 实际的评估数据文件，
- 映射文件 Mapping_File，
以便以确定性方式执行分析。

上面这段代码框展示了 P_Analysis_Planner 的初始指令。其中明确定义了其目的和范围，并明确区分了计划阶段与执行阶段。规划器负责翻译请求，而实际执行则委托给了 P_Analysis_Engine。

随后是一段较长的内容，描述了评估数据的语义含义。当然，这部分高度依赖具体的用例和数据集。它定义了用于行筛选的语义类别，以及用于选择实际分析目标的类别（目标内容类别 TARGET CONTENT CATEGORIES 和目标选择属性 TARGET SELECTION ATTRIBUTES）。

评估数据可以通过以下语义类别进行访问。

行筛选类别（ROW FILTER CATEGORIES）

仅在 row_filters 中使用这些类别：

- VS_Nr:
    价值流的唯一标识符。
    当按价值流编号筛选时使用。

- Value Stream:
    价值流名称。
    当按价值流名称筛选时使用。

- ...

目标内容类别（TARGET CONTENT CATEGORIES）

仅在 target_selection_rules.data_category 中使用这些类别：

- chapter_score:
    数值型成熟度评分。
    适用于成熟度计算、分数分析及平均成熟度分析。

- strength:
    描述优势的评估人陈述。

- ...

目标选择属性（TARGET SELECTION ATTRIBUTES）

仅在 target_selection_rules 内部使用这些属性：

- data_category:
    定义所需的目标内容类别。

- aggregation_allowed:
    使用场景：
        - mean 表示数值型成熟度均值
        - summary 表示文本摘要

- ...

规划器不会直接操作物理数据列。相反，它运行在一个语义抽象层上，从而将自然语言与底层数据集结构解耦。

这种分离非常重要，因为评估数据集中包含了超过 800 列的数据，包括：

• 成熟度评级，
• 文本型评估人员发现，
• 元数据，
• 组织映射关系，
• 问卷变体，
• 以及概念/执行区别。

因此，正确选取目标列成为分析过程中至关重要的一环。

限制允许的分析类型同样重要。规划器有意被阻止发明任意的分析操作。因此，"分析类型"部分定义了唯一有效的分析类型——目前只有两种。这显著提高了下游执行的可预测性和稳健性。当然，这个列表可以轻松地针对个别用例进行扩展。

ANALYSIS TYPES

使用这些 analysis_type 值中的一个：

- numeric_mean
    用于：
    - 平均成熟度
    - 均值成熟度
    - ...

- text_summary
    用于：
    - 优势
    - 改进潜力
    - ...

下一节以抽象和确定的方式定义了规划器如何选择相关的目标列。规则区分了两个预定义的分析类型 numeric_mean 和 text_summary，并最终确定为特定请求选择了哪些数据集列。

RULES FOR target_selection_rules

NUMERIC MATURITY ANALYSIS

对于数值成熟度分析：
- analysis_type 必须是：
    "numeric_mean"
- data_category 必须是：
    ["chapter_score"]
- ...

TEXT SUMMARY ANALYSIS

对于文本摘要分析：
- analysis_type 必须是：
    "text_summary"
- data_category：
    仅包含请求的类别：
        - "strength"
        - "potential"
        - "recommendation"
        - "remark"
- ...

类似的逻辑适用于行过滤过程。

RULES FOR row_filters

仅使用 row_filters 来过滤评估数据集中的行。

允许的行过滤键是：
- VS_Nr
- Value Stream
- ...

不要对以下项目使用 row_filters：
- chapter_id
- ...

这些只属于 target_selection_rules。

最后，指令定义了所需的输出结构以及几个严格的"禁止规则"。这一部分特别重要，因为生成的输出会直接转发给 P_Analysis_Engine，因此必须遵循明确定义且机器可读的结构。

OUTPUT FORMAT

仅返回有效的 JSON。
不要返回 markdown。
不要返回 Python 代码。
...

使用完全相同的结构：

{
  "status": "success",
  "parent_instruction_summary": "",
  "selection_rule": {
    "analysis_type": "",
    "target_selection_rules": {
      "data_category": [],
      "aggregation_allowed": [],
      "concept_execution": null,
      "chapter_id": null
    },
    "row_filters": {}
  },
  "warnings": []
}

如果请求不清楚，规划器必须明确返回错误结构，而不是"猜测"可能错误的分析指令。

如果任务不清楚，返回：

{
  "status": "error",
  "parent_instruction_summary": "",
  "selection_rule": {
    "analysis_type": null,
    "target_selection_rules": {
      "data_category": [],
      "aggregation_allowed": [],
      "concept_execution": null,
      "chapter_id": null
    },
    "row_filters": {}
  },
  "warnings": [
    "分析任务未被清楚理解。"
  ]
}

至此，规划器已将模糊的自然语言转换为确定性的分析规范。然而，实际的数据执行仍未发生。

在第5章中，我们将跟随一个真实的用户请求通过完整的流程，并检查 P_Analysis_Planner 如何生成 Selection_Rule，以及 P_Analysis_Engine 如何在评估数据集上执行它。

4 分析引擎

与 P_Analysis_Planner 不同，P_Analysis_Engine 不会对任务进行推理。它只执行由 P_Analysis_Planner 生成的分析规范。

如同第3章一样，我们将只关注指令中最相关的部分。完整规范可以在此处下载这里。

P_Analysis_Engine 的指令从基本任务定义开始。本质上，AI 提示被用作受控的 Python 执行环境。代码在提示指令中预定义，只能执行，不能修改。

你是 Analysis_Engine，一个基于 pandas 的确定性分析执行器。

你的任务是使用代码解释器分析 Excel 评估数据集。

你接收三个输入：

1. document 
   包含评估数据的 Excel 文件。

2. Mapping_File 
   描述 document 列的 Excel 文件。

3. Selection_Rule 
   定义以下内容的 JSON 对象：
   - 从 Mapping_File 中选择哪些列
   - 对 document 应用哪些行过滤器
   - 执行哪种类型的分析

你不得重新解释原始用户请求。
你不得推断额外的列。
你不得更改 Selection_Rule。
你不得生成新的分析方法。
你只能执行下面的确定性 Python 脚本。

使用代码解释器执行 Python 脚本。
仅返回脚本打印的 JSON 结果。
不要返回 markdown。
不要解释代码。
不要在 JSON 结果前后添加文本。

P_Analysis_Engine 接收三个输入文件：

1. 用户在聊天界面上传的 Assessment_File。它存储在提示内部变量 document 中。
2. 一个 Mapping_File，流程 F_Call_Analysis_Engine 在执行准备期间从 SharePoint 加载。
3. 由 P_Analysis_Planner 生成的 Selection_Rule（见第3章）。

Mapping_File 在更高层次的抽象上定义 Assessment_File 中众多列的语义方面起着关键作用。有了这个抽象层，Selection_Rule 只需要指定所需的信息类型，而 P_Analysis_Engine 在执行期间选择相应的数据集列。

图3：Mapping_File 的结构 | 作者图片

图 3 展示了 Mapping_File 的结构。它包含了 Assessment_File 中每个可能与数据分析相关的列的一行记录。明显无关的数据列不会出现在 Mapping_File 中，因此对 P_Analysis_Engine 是不可见的。对于每一行，文件指定了选择标准：

• data_category：

该列的功能含义，例如成熟度评分、强度、工厂名称、地区或季节。

• chapter_id：

评估章节的唯一标识符。

• chapter_name：

人类可读的评估章节名称。

• concept_execution：

指示该列属于概念成熟度还是执行成熟度。

• aggregation_allowed：

定义对该列有效的聚合类型，例如数值型成熟度评分使用 mean，文本型发现结果使用 summary。

接下来，在 P_Analysis_Engine 的指令中有一段关于如何解释 Selection_Rule 的说明。

Selection_Rule 规则：

- analysis_type = "numeric_mean":
  对所有选中的数字目标列计算算术平均值。

- analysis_type = "text_summary":
  收集所有选中文本目标列中的非空条目。

- target_selection_rules:
  通过匹配 Mapping_File 属性来选择目标列。
  若规则值为 null 表示：不过滤此属性。
  列表表示：保留 Mapping_File 属性在此列表内的行。

- row_filters:
  应用于文档的行过滤器。
  键是来自 Mapping_File 的 data_category 值，如 "Plant"、"Region"、"Production Principle"、"Season"。
  值是允许值的列表。

这个选择指定：

• 必须执行哪种分析操作（analysis_type），
• 如何从 Mapping_File 中选取相关的目标列（target_selection_rules），
• 在执行分析之前如何筛选评估数据集（row_filters）。

这种指令是有意设计成确定性的。不允许 P_Analysis_Engine 重新解释原始用户请求或发明额外的分析操作。

在指令块之后，P_Analysis_Engine 接收到实际的 Python 脚本。完整脚本包含超过 300 行代码，并作为 AI 提示指令的一部分。它已在本章顶部链接并可供下载。许多代码行在架构上并不重要。它们处理实用健壮性问题：清理列名、规范化输入值、处理缺失列、转换 Copilot 包装对象以及返回结构化错误消息。

就本文而言，我只关注核心逻辑部分。

第一个重要的步骤是引擎加载上传的评估数据（现在可在 document 中获取）和 Mapping_File。从此刻起，LLM 不再解析用户的请求。它仅根据 Selection_Rule 执行确定性脚本。

mapping_df = pd.read_excel(Mapping_File)
data_df = pd.read_excel(document)

mapping_df = strip_column_names(mapping_df)
data_df = strip_column_names(data_df)

关键的架构元素是对目标列的选择。P_Analysis_Engine 绝不会猜测哪些 Excel 列可能是相关的。相反，它会按照 target_selection_rules 中定义的属性去过滤 Mapping_File。

target_mapping = mapping_df.copy()

for attr, rule_value in target_selection_rules.items():

    values = normalize_rule_value(rule_value)
    values = normalize_list_for_matching(values)

    if values is None:
        continue

    target_mapping = target_mapping[
        target_mapping[attr]
        .apply(normalize_for_matching)
        .isin(values)
    ]

selected_target_columns = (
    target_mapping["source_column_name"]
    .dropna()
    .tolist()
)

这是抽象分析指令变为具体实现的地方。例如，像 chapter_id = ["3.5"]、data_category = ["chapter_score"] 和 aggregation_allowed = ["mean"] 这样的规则会被转化为实际包含第 3.5 章节的概念和执行成熟度评分的 Excel 列。

同样的原则也适用于行过滤器。再次强调，引擎不会从自然语言中推断任何内容。它只会应用 Selection_Rule 中明确提供的过滤条件。

filtered_df = data_df.copy()

for filter_category, filter_values in row_filters.items():

    filter_mapping = mapping_df[
        mapping_df["data_category"]
        .apply(normalize_for_matching)
        == normalize_for_matching(filter_category)
    ]

    filter_col = filter_mapping["source_column_name"].iloc[0]

    filtered_df = filtered_df[
        filtered_df[filter_col]
        .apply(normalize_for_matching)
        .isin(values)
    ]

在完成列选择和行过滤后，真正的分析逻辑变得非常直观。对于数值型成熟度分析，引擎会对所有选定的数字目标列计算算术平均值。

if analysis_type == "numeric_mean":

    numeric_result = {}

    for col in available_target_columns:

        series = pd.to_numeric(filtered_df[col], errors="coerce")
        valid_count = int(series.notna().sum())

        numeric_result[col] = {
            "mean": float(series.mean()) if valid_count > 0 else None,
            "valid_count": valid_count
        }

    result["result"] = numeric_result

而对于文本分析，引擎收集的是非空的评估者陈述，而不是计算数值。

elif analysis_type == "text_summary":

    text_result = {}

    for col in available_target_columns:

        values = [
            clean_text_value(v)
            for v in filtered_df[col].tolist()
        ]

        values = [v for v in values if v is not None]

        text_result[col] = {
            "entries": values,
            "entry_count": len(values)
        }

    result["result"] = text_result

最后，结果以 JSON 格式返回。这一点非常重要，因为输出还不是最终面向用户的答案。它是下一个 LLM 步骤的可靠分析基础：由父代理进行解释。

print(json.dumps(result, indent=2, ensure_ascii=False))

这种设计有意让 P_Analysis_Engine 保持“枯燥”。它不进行推理，不进行解释，也不改进分析。它只执行命令。这正是关键所在。这一层越确定，后续由 LLM 生成的解释就越值得信赖。

5 面向全流程的示例

为了说明完整的工作流程，我们通过一个现实的例子来演示整个流水线。

当用户发起交互时，父代理可能会向分析模块发出如下 Parent_Instruction：

“总结工厂 AbcP 中章节 1.4 失效预防系统的改进潜力。”

对于人类读者来说这个请求看起来很简单，但它已经包含了多个语义任务：

• 识别所请求的评估章节，
• 检测所需的内容类型，
• 应用行筛选器，
• 获取正确的文本列，
• 聚合文本发现，
• 最后生成有意义的解释（→ 父代理）。

这正是纯基于 LLM 的分析变得不可靠的任务类型。因此系统将工作流划分为确定性执行步骤和概率性解释步骤。

5.1 来自分析规划器的转换

第一步由 P_Analysis_Planner 执行。

它将自然语言请求转化为一个确定性的 Selection_Rule。

{
  "status": "success",
  "parent_instruction_summary": "Summarize improvement potentials for chapter 1.4 Failure Prevention System in plant AbcP.",
  "selection_rule": {
    "analysis_type": "text_summary",
    "target_selection_rules": {
      "data_category": ["potential"],
      "aggregation_allowed": ["summary"],
      "concept_execution": null,
      "chapter_id": ["1.4"]
    },
    "row_filters": {
      "Plant": ["AbcP"]
    }
  },
  "warnings": []
}

该 Selection_Rule 已经包含完整的确定性分析规范：

• analysis_type = "text_summary"

表示必须收集文本评估者的发现而不是数值计算。

• data_category = ["potential"]

限制分析仅针对改进建议。

• chapter_id = ["1.4"]

将分析限定到失效预防系统章节。

• row_filters = {"Plant": ["AbcP"]}

将数据集限制为指定工厂的数据。

在此阶段尚未发生数据分析。结果只是下一步执行指令。

5.2 来自分析引擎的执行

此 Selection_Rule 被传递给 P_Analysis_Engine 进行执行。首先，引擎从 Mapping_File 中选择所有匹配的目标列。

target_mapping = target_mapping[
    target_mapping[attr]
    .apply(normalize_for_matching)
    .isin(values)
]

这会把抽象的选择条件转换成实际的数据集列，例如：

selected_target_columns = [
    "1.4 CON L2 Improvement potentials",
    "1.4 CON L3 Improvement potentials",
    "1.4 EXE L2 Improvement potentials",
    "1.4 EXE L3 Improvement potentials"
]

接下来应用行过滤器：

filtered_df = filtered_df[
    filtered_df[filter_col]
    .apply(normalize_for_matching)
    .isin(values)
]

在这个例子中，数据集被缩减为属于工厂 AbcP 的评估记录。

最后，引擎从选定的列中收集所有非空文本条目。

values = [
    clean_text_value(v)
    for v in filtered_df[col].tolist()
]

values = [v for v in values if v is not None]

正如我们可以看到的那样，引擎并不对这些发现进行解释。它只是根据 Python 脚本检索并结构化它们。

引擎的输出是一个 JSON 对象，其中包含了评估者关于价值流改进建议的手写陈述集合。

{
  "entry_count": 6,
  "entries": [
    "Root causes are not systematically tracked.",
    "Escalation rules for recurring failures are unclear.",
    "Lessons learned are not transferred between shifts.",
    "Preventive maintenance findings are not integrated into CIP activities.",
    "Failure trends are visualized inconsistently.",
    "Problem-solving activities focus mainly on symptoms instead of root causes."
  ]
}

此时，系统仍未生成任何建议。它仅仅产生了一个可靠的、相关的评估发现集合。这个 JSON 对象会被返回给父代理用于解释，并生成最终响应给用户。

5.3 来自父代理的解释

在最后一步中，父代理收集所有的响应（可能还有来自子代理的其他响应），然后生成最终输出。

The collected findings indicate that the Failure Prevention System is
currently more reactive than preventive. Most gaps are related to missing
systematic root-cause management and weak organizational learning across
shifts and teams. The highest leverage improvements would likely come from
strengthening escalation routines, integrating preventive maintenance findings
into CIP activities, and establishing consistent cross-shift learning
mechanisms.

总结一下系统的中心架构思想：

LLM 不再自己创建分析基础。相反，它解释一组已验证过的确定性发现。

LLM 的概率推理能力被用于创造价值的地方：解释、优先级排序、说明和沟通——而不是数据处理本身。

6 为什么 AI 架构很重要

大型语言模型在解释、推理和语言生成方面天然具有强大能力，但在可靠的数值分析方面仍然较弱。它们的优化目标是合理性，而非确定性的可重现性。即使有“代码解释器”等扩展，这一弱点在更复杂的分析场景中依然明显。

好消息是，通过智能系统架构可以在很大程度上弥补这一局限性。关键在于明确的责任分离：确定性的数据处理层执行分析基础工作，而大型语言模型专注于解释、优先级排序、说明和沟通。

在所提出的方法中，最重要的设计决策因此不是向系统添加更多AI。而是非常仔细地定义概率推理应该在哪里结束，确定性执行应该在哪里开始。

可靠的代理系统很可能需要正是这种混合架构：将经典数据科学管道的稳健性与大型语言模型的推理能力相结合。