software

确定性问题与概率 AI 分析

发布: (2025年12月7日 GMT+8 13:32)
9 min read
原文: Dev.to

Source: Dev.to

简要概述

AI 驱动的分析工具依赖于概率系统（LLM、语义搜索、RAG）来回答需要确定性准确性的业务问题。细微的措辞变化可能产生不同的 SQL 查询和不同的答案。这不是小错误——而是架构不匹配。解决方案不是“更好的 AI”，而是重新思考如何将业务问题与数据匹配，对核心概念使用精确匹配而非模糊语义搜索。

概率 AI 分析的问题

想象向你的 CFO 询问：“我们在第三季度拒绝了多少索赔？”
他们打开一个仪表盘并说：“大约 1,247，误差不大。”
当审计要求精确数字时，“大约”是不可接受的——必须是 1,247，否则就不算。

第二天用稍微不同的表述再次询问同一位 CFO：“上个季度被拒的索赔数量是多少？”
如果答案变成了 1,189，系统的可信度就会下降。

这正是大多数 AI 驱动的分析工具今天的工作方式。

现代 AI 分析技术栈

  1. 用户 用自然语言提出问题。
  2. 语义搜索 从元数据中找到相关的表和列。
  3. RAG（检索增强生成）获取这些数据元素的额外上下文。
  4. LLM 基于检索到的信息生成 SQL 查询。
  5. 执行查询并返回结果。

管道中的每一步都是概率性的：

  • 语义搜索 使用嵌入；不同的表述会产生不同的向量表示，检索到不同的元数据块。
  • RAG 按相关性得分对结果排序；细微的查询变化会重新排序，从而改变传递给 LLM 的上下文。
  • LLM 生成 本质上是非确定性的。即使 temperature = 0，相同的提示也可能在 SQL 结构、连接或过滤条件上出现差异。

概率管道适用于创意任务——营销文案、头脑风暴、邮件草稿——因为多种有效输出都是可以接受的。而业务分析则要求精确。

真实案例

问题： “上个季度高级客户的平均订单价值是多少？”

第一次尝试

语义搜索返回：

项目相关度
fact_orders 表0.89
customer_tier 列0.87
order_total 列0.85

LLM 生成：

SELECT AVG(order_total) 
FROM fact_orders 
WHERE customer_tier = 'premium' 
  AND order_date >= '2024-07-01';

结果：$247.83

第二次尝试（重新表述）

用户询问：“我们在 Q3 对顶级客户的平均订单金额是多少？”

语义搜索此时返回：

项目相关度
fact_orders 表0.88
customer_segment 列0.86
order_value 列0.84

LLM 生成：

SELECT AVG(order_value)
FROM fact_orders
WHERE customer_segment = 'gold'
  AND order_date >= '2024-07-01';

结果：$231.56

问题本身没有变化，却因为系统选择了不同的列而得到不同的答案。根本原因不是“错误的 AI”，而是缺少真实数据的强制机制。系统在猜测哪种语义映射是正确的，而细微的措辞变化会倾斜平衡。

人类分析师如何处理同一问题

面对如下复杂请求：

“上个季度在高峰时段的高销量门店中，购买次数不少于 3 次的高级客户的平均订单价值和客户满意度评分是多少？请按产品和地区拆分。”

分析师会将请求拆解为 结构化组件：

  • 指标：平均订单价值、客户满意度评分
  • 过滤条件：高级客户、至少 3 次购买、高销量门店、峰值时段、上个季度
  • 维度：产品、地区

随后进行 精确查找：

  1. 在指标目录中搜索 “average order value” → 精确匹配或无匹配。
  2. 在业务词汇表中检查 “premium customers” → 精确定义。
  3. 查找 “high‑volume stores” → 精确标准。

如果任何概念缺乏定义，分析师会暂停并请求澄清。这个确定性工作流确保相同的问题始终得到相同的底层元数据，从而产生相同的 SQL 查询。

提议的确定性架构

  1. 提取业务概念（概率步骤）
    使用 LLM 将自然语言问题解析为结构化的 JSON 负载：

    {
  "metrics": ["average order value", "customer satisfaction rating"],
  "filters": [
    "premium customers",
    "at least 3 purchases",
    "high volume stores",
    "peak hours",
    "last quarter"
  ],
  "dimensions": ["product", "region"]
}

    该提取可能是非确定性的；目标仅是识别用户意图中的概念。

  2. 对目录进行精确匹配（确定性步骤）

    • 指标目录 → 将 “average order value” 映射为 metrics.avg_order_value（已找到）。
    • 业务词汇表 → 将每个过滤条件映射为精确定义（例如 customer_tier = 'premium'）。
    • 维度映射 → 将 “product” 解析为 dim_product.product_name 等。

    若发现缺失概念，则中止并请求澄清。

  3. 组装具体元数据
    为每个组件检索完整定义（表、列、计算逻辑、所需连接）。

  4. 使用预定义构件生成 SQL（确定性）
    仅使用 LLM 将已知块拼接成最终查询：

    SELECT 
  p.product_name,
  g.region_name,
  AVG(o.order_total) AS avg_order_value,
  AVG(o.satisfaction_score) AS avg_csat
FROM fact_orders o
JOIN dim_customer c ON o.customer_id = c.customer_id
JOIN dim_product p ON o.product_id = p.product_id
JOIN dim_geography g ON o.store_id = g.store_id
WHERE c.customer_tier = 'premium'
  AND o.order_date >= DATE_TRUNC('quarter', CURRENT_DATE - INTERVAL '3 months')
  AND o.store_id IN (
    SELECT store_id 
    FROM dim_stores 
    WHERE annual_revenue > 5000000
  )
  AND EXTRACT(HOUR FROM o.order_time) IN (10,11,12,13,17,18,19,20)
GROUP BY p.product_name, g.region_name;

    因为每次检索到的元数据相同，生成的查询对相同的问题也是相同的——确定性。

确定性方法的前提条件

  • 指标目录 – 为每个 KPI、度量和指标提供精确的计算逻辑和数据血缘。
  • 业务词汇表 – 为所有业务术语、细分和过滤条件提供明确的定义，包括对应的 SQL 片段。
  • 维度映射 – 明确业务概念与数据模型实体（表、列）之间的关系。

这些资产构成了“已解决 80 %”的基础（参见前一篇文章）。一旦就位，确定性管道就能可靠地将自然语言问题转化为准确、可重复的 SQL。

处理同义词和歧义

精确匹配本身比较僵硬，用户可能使用同义词（例如 “VIP customers” 与 “premium customers”）。可采用的策略包括：

  • 在业务词汇表中建立 同义词表，将替代词映射到规范定义。
  • 当术语缺乏直接匹配时，向用户发出 澄清提示。

通过显式管理同义词，系统在保持确定性的同时仍能提供友好的用户体验。

Back to Blog

相关文章

阅读更多 »