使用 Snowflake Cortex Analyst 构建 — 我对 Semantic Layers 和 Guardrails 的收获

Source: Dev.to

当我开始使用 Snowflake Cortex Analyst 时，我以为最难的部分是让系统正确回答问题。
事实并非如此。真正难的在于决定哪些问题不该回答。

在本文中，我想分享两件比我预期更费脑筋的事——已验证查询（verified queries）和防护栏（guardrails）。

快速概览 Cortex Analyst

Snowflake Cortex Analyst 让用户可以用自然语言提问，并从结构化数据中获取答案。其内部使用在 YAML 中定义的语义模型来理解数据并生成 SQL 响应。

它有两种响应方式：

• 已验证查询 – 你预先定义的、经过验证的问答对。
• LLM 生成的 SQL – 当没有匹配的已验证查询时，模型自行生成 SQL。

构建良好的语义模型的目标是最大化已验证查询的命中率。命中已验证查询的次数越多，输出就越受控、越可靠。

已验证查询的取舍

我的第一反应是尽可能多地添加已验证查询的变体——覆盖用户可能提出的所有同义问法。结果适得其反。

最佳做法是提供足够的变体以捕获常见表述，同时避免用冗余模式淹没匹配器。

防护栏问题 — 定义系统不应做的事

这是大多数人会跳过的环节。数据工程师总是为边缘情况做好准备，这种思路同样适用于这里。用户会把工具当作任何 AI 来使用，提出任何问题。你不可能控制每一个用户请求，责任在于 YAML 模型本身。

Cortex Analyst 提供了 question_categorization 块，让你显式定义系统应拒绝的问答类别。下面是一个简化示例：

question_categorization:
  - category: unavailable_topics
    examples:
      - "What is the return rate by supplier?"
      - "Show me customer lifetime value"

  - category: greetings
    examples:
      - "Hey"
      - "Can you help me?"

  - category: forecast_or_prediction
    examples:
      - "What will sales look like next month?"
      - "Predict inventory needs for Q4"

  - category: ambiguous_queries
    examples:
      - "Show me something interesting"
      - "What should I look at?"

如果没有这个块，系统会尝试回答所有问题——包括那些它根本不该回答的问题。提前添加明确的防护栏可以从一开始就防止不期望的行为。

小结

• 构建语义模型时，以最大化已验证查询命中率为目标，而不仅仅是暴露数据。
• 已验证查询需要足够的变体以实用，但变体过多会产生噪声。
• 使用 question_categorization 明确定义系统应拒绝的内容。
• 从一开始就采取防御性思维——不要等到生产环境出现问题才去修补。

这些在构建初期做出的决定，为后期省下了大量的改造工作。