用 Snowflake Cortex Search 做客户需求智能匹配

如果你的团队记录的每一个客户请求，在客户点击提交之前，就能立刻在你的产品路线图中找到匹配项，会怎样？我们实现了这一点。下面就是具体做法。

这种模式适用于任何这样的场景：有人用自由文本描述需求，而你需要将其与结构化目录进行匹配：支持工单匹配解决方案模板、客户目标匹配合作伙伴能力、技能差距匹配培训资源。我们是为客户功能请求构建的，但这个框架是可复用的。

手动匹配之痛

每个组织都有某种版本的这个难题：一边，人们用自己的话描述他们需要什么。另一边，有人维护着已知解决方案、产品或能力的目录。对我们来说，一边是现场团队记录客户需求，另一边是产品团队维护增强功能目录。

有时客户说：“我们希望 AI 在 Snowflake 内处理我们的支持工单路由和分类。”但产品目录说的是：“Cortex AI 函数：用于自动化文本处理的 AI_CLASSIFY 和 AI_COMPLETE。”同样的需求。不同的语言。

所以必须有人手动阅读每一个请求，扫描目录，找到匹配项。在低量时这还行得通。随着我们发展，这变成了一个瓶颈，因为同一个增强功能被不同团队反复记录，却无法知道它已经被记录过了。

连接客户需求与产品路线图之间的点

这两个数据资产都已经在 Snowflake 中可用。真正的突破在于将客户所要求的内容与产品工程路线图上已有的内容连接起来。Snowflake Cortex Search 服务理解客户请求背后的意图，并超越精确关键词去寻找最相关的产品增强功能，包括之前客户描述过的类似需求。

我们将这一能力直接带入 Salesforce 中的客户功能请求表单，使其成为销售工程师自然工作流程的一部分。当他们描述客户想要构建什么、他们面临的产品限制以及业务影响时，AI 驱动的建议会显示最相关的增强功能，以及产品领域、当前状态和简单摘要。只需快速点击一下，销售工程师就可以将请求连接到正确的增强功能、对其进行分类，并将其路由到合适的产品团队。正确的洞察，在正确的时刻，直接融入工作流程。

架构：它如何运作

该工作流可推广到任何需要将非结构化输入与结构化目录匹配的场景。在我们的案例中，它始于一件简单的事：客户有需求。

销售工程师记录客户想要构建什么、什么阻碍了他们以及为什么这很重要。从那里开始，Cortex AI理解请求背后的意图和上下文，而Cortex Search 会搜索产品增强功能目录以找到最接近的匹配项，不仅基于关键词，还基于含义。

几秒钟内，最相关的增强功能就会浮现到顶部，为销售工程师提供清晰的前进路径。如果已经有增强功能可以满足该需求，请求就可以被链接并路由到正确的产品团队以更快采取行动。如果没有现有匹配项，它就会进入专家分诊，作为潜在的新产品增强需求。简而言之，该工作流将客户对话转化为清晰的产品信号，并帮助该信号在正确的时间到达正确的团队。

第 1 步：捕获 — UI 组件 + Apex 控制器

销售工程师在 Salesforce 中打开一个新的客户功能请求。LWC（Lightning Web 组件）向导是一个两屏流程。

屏幕 1捕获客户、用例上下文和三个关键输入：

• 客户解决方案：客户想要构建什么？
• 产品限制：什么阻碍了他们？
• 业务影响：对他们业务的成本是什么？

点击下一步会将表单移动到屏幕 2。此时，建议组件会悄悄获取已填写的输入并将其交给 Apex 方法。该方法将它们格式化为带标签的问答查询，并通过 HTTP POST 发送到 Cortex Search 服务：

{
"query": "What is the solution the customer is trying to build? : Customer wants AI to automatically categorize and route incoming support tickets inside Snowflake ; What is the product limitation preventing them? : No native way to classify and route unstructured text at scale without external tools ; What is the business impact? : Support team spending 3+ hours daily on manual ticket triage, slowing response times",
"columns": [
"PRODUCT_ENHANCEMENT_ID",
"PRODUCT_ENHANCEMENT_NAME",
"PRODUCT_ENHANCEMENT_DESCRIPTION",
"PE_PRODUCT_AREA_C",
"PE_PRODUCT_LINE_C",
"SUMMARY",
"ACCOUNT_ENHANCEMENT_ID",
"ACC_ENHANCEMENT_DESCRIPTION"
],
"limit": 3
}

这种格式是刻意设计的。它镜像了 Cortex Search 中索引内容的结构，并发送带角色标签的上下文，而不是原始关键词。

第 2 步：激活 AI — Cortex AI 理解意图

Cortex AI 接收结构化查询并解释其背后的含义——而不仅仅是词语。它读取客户想要构建什么、什么阻碍了他们以及业务成本是什么，并将完整上下文映射为语义表示。

这就是弥合词汇差距的关键。客户说“我们希望 AI 在 Snowflake 内处理我们的支持工单路由和分类”，而产品目录条目说“Cortex AI 函数：用于自动化文本处理的 AI_CLASSIFY 和 AI_COMPLETE”，表面上看起来完全不同。Cortex AI 理解它们描述的是同一个需求。

第 3 步：检索与排序 — Cortex Search

建议引擎的核心是 Snowflake Cortex Search，这是一个完全托管的语义搜索服务，基于含义而非关键词进行检索。Cortex Search 不是扫描精确文本匹配，而是使用 Snowflake 自己的嵌入模型将第 1 步中的结构化查询转换为向量表示，并将其与整个产品增强功能目录的预构建索引进行比较，然后返回最接近的语义匹配项，按相关性排序。

该服务在 3 秒内返回最多 3 个按相关性排序的结果。相关性顺序完全由检索模型决定，并在端到端过程中保持不变：Apex 控制器使用返回的排序 ID 从 Salesforce 重新获取匹配记录，而不会在下游重新排序或重新评分。

第 4 步：推荐 — Apex 返回结果，LWC 渲染卡片

响应按排名返回：

{
"results": [
{
"PRODUCT_ENHANCEMENT_ID": "PE-00731",
"PRODUCT_ENHANCEMENT_NAME": "Cortex AI Functions - AI_CLASSIFY for Automated Text Processing",
"PRODUCT_ENHANCEMENT_DESCRIPTION": "Native Cortex AI functions (AI_CLASSIFY, AI_COMPLETE) to categorize and route unstructured text inside Snowflake without external tooling.",
"PE_PRODUCT_AREA_C": "Cortex AI",
"PE_PRODUCT_LINE_C": "AI & ML Functions",
"SUMMARY": "Use AI_CLASSIFY and AI_COMPLETE to categorize and route unstructured text natively inside Snowflake - no external tools required.",
"ACCOUNT_ENHANCEMENT_ID": "AE-04412",
"ACC_ENHANCEMENT_DESCRIPTION": "Customer wants to classify and route support tickets automatically using AI, entirely within Snowflake."
}
// … 2 more ranked results
],
"request_id": "01b3f9a2–7c44–4e81-b012–8d5f3a6c0012"
}

Apex 控制器重新获取匹配的 Salesforce 记录，保持精确的相关性顺序，并将它们传递给 LWC。三张建议卡片出现，显示增强名称、产品领域、产品线、描述、通俗语言摘要，以及相似客户如何描述同一需求。

步骤 5：路由——关联或专家分诊

LWC 渲染三张建议卡片。每张卡片显示增强名称、产品领域、产品线、描述，以及相似客户此前如何描述同一需求的通俗语言摘要。

销售工程师审阅卡片并点击最佳匹配项。一个自定义事件触发：

this.dispatchEvent(new CustomEvent('suggestSelected', {
detail: { productEnhacementId, productEnhacementName },
bubbles: true, composed: true
}));

父向导保存该记录：已关联、已分类，并路由至合适的产品团队。如果没有卡片匹配，该记录会被标记为需要专家分诊。每次调用都会完整记录到我们用于监控 API 调用的自定义对象之一中。

它带来的改变

影响立竿见影且可衡量：

为什么它会随着时间推移变得更好

我们不仅仅索引产品团队写下的内容。我们还索引客户所说的内容：每一个曾经关联到产品增强的历史请求都是索引的一部分。因此，流经系统的请求越多，它学到的客户语言就越多，匹配也就越准确。

从想法到上线仅用三周

第 1 周——把数据做对

在编写任何 UI 代码之前，我们构建并训练了 Cortex Search 索引。我们对照专家分诊审阅者会选择的答案来验证建议。当 AI 的选择持续一致时，我们就知道它已经准备好了。

第 2 周——为信任而构建

建议面板必须快速且易于阅读。三秒或更短。销售工程师始终拥有最终决定权；AI 只是呈现选项。这种平衡对于让人们真正使用它很重要。

第 3 周——推广

测试边缘情况、设置生产环境和沙盒环境，并发布给整个 GTM 团队。到 2026 年初，它已在 Snowflake 面向用户上线。

为你的团队构建这个

我们在这里构建的模式并不特定于产品增强。它适用于任何有人用自己的话描述需求，而你有一个已知条目目录可供匹配的场景。

同样方法可以应用的一些示例：

• 支持路由 ——客服人员描述问题并匹配到现有的解决方案模板
• 合作伙伴匹配——客户描述一个用例并呈现最相关的合作伙伴能力
• 入门引导——新客户描述他们的目标并匹配到经过验证的实施模式
• 培训 ——员工描述技能差距并呈现合适的学习资源

从小处着手。索引一个聚焦的子集。将 AI 建议与你最优秀的专家会选择的内容进行比较。当一致率超过 70% 时，你就已经自动化了常规工作，并让团队腾出精力去做真正需要人类判断的工作。

团队：Rajani Karkhile，Siddharth Runwal，Komal Kulkarni，Ankit Dahiya、Angad Pathak、Amit Vashisth

标签：Snowflake Cortex AI · Cortex Search · 销售运营 · 客户智能 · GTM

AI 驱动的 GTM 分诊：使用 Cortex Search 的智能建议最初发表于 Snowflake Builders Blog: Data Engineers, App Developers, AI, & Data Science 于 Medium，人们在那里通过高亮和回应这个故事继续对话。