销售合规不是“事后补救”，而是“机制前置”的系统工程。本文以一款销售会话质检系统的0-1成长路径为例，系统梳理从数据采集、模型训练到规则治理的产品化过程，帮助产品人理解如何在“高噪声场景”中构建“可落地”的合规能力。

在AI商业化起风时，我有幸与某金融集团下的2C销售部门共创了一套“销售会话质检与客户画像系统”。我们接手时，客户的销售违规率已处于监管红线边缘。 每天都有数千通电话在暗示返利，导致巨额退单和投诉。更可怕的是：他们的 500 万条历史对话数据，几乎 90% 都是无用的噪音。模型第一版准确率只有 20%，几乎是随机的！ 我们意识到瓶颈不在算法，而在于对业务场景的拆解不够细致。必须回到第一章，重新定义 ‘隐晦返利’ 的上百种语料，作为产品经理，你就是算法与业务之间唯一能听懂彼此的翻译者。

这是一个跨越业务、数据与算法的项目：从最初的一纸需求，到落地成型，再到一次次磨合、调试。这一路上，我最深刻的体会是：在AI产品中，产品经理的价值，不是写文档，而是成为业务和技术之间的翻译者与桥梁。

01 项目的诞生

这个项目提案时正是大语言模型的风口，很多公司都在想借LLM做销售转型，但我们的甲方客户最终还是选择了从“质检”入手，为什么弃更直观的销售转变先做合规方面？

这种金融类公司面临的困境很典型：

• 销售违规率高，返利、误导说辞屡禁不止；
• 客户投诉、退单频发，合规风险巨大；
• 监管压力要求他们必须找到新的能快速实现的风控方式。
• （我们报价真的很便宜）

投入高昂成本重新组建团队自研，不如选择与我们合作。客户提供合规知识库和敏感词清单，我们负责算法模型训练与系统平台研发。

目标分三步

1.敏感词实时拦截，避免明显违规；

2.规避说辞识别，抓住用同音词暗示返利、规避监控的行为；

3. 结合CRM生成客户画像，为精准营销提供支撑。

02 数据与训练

我们拿到的原始数据，是该集团某分公司将近1000万条对话，噪音极大。

第一步工作，要把业务需求转化为可供算法使用的数据规则：

• 组织20名兼职标注员，依据客户提供的敏感词和多个典型违规案例，形成《标注指南》；
• 明确区分：“确定违规”（直接出现返利等敏感词）、“规避说辞”（暗示或绕过监察，比如“电话聊更方便”）；
• 清洗数据并与客户共同抽查，确保标注一致性。

算法团队基于人工清洗后的数据训练模型，结果迭代如下：

第一版：准确率仅20%，模型没学到语境特征，几乎不可用；

第二版：通过优化特征提取与样本清洗，准确率提升至50%，具备试用价值；

第三版：实装后依靠新数据反哺，准确率稳定在70%。

70%不是终点，但已能显著降低合规风险（至少客户愿意接受）。

03 产经的核心作用

与算法团队的磨合

很多人以为模型调试完全是算法的事，但实际上，产品经理要为算法找到“合适的训练方法”：

• 对接的客户一般是业务人员，他们的表达是“有xxx这类的绕过监管说辞，也需要找出来”，产品要理解其中的含义，把模糊不清的要求拆解成可标注的语料类别。
• 算法团队在第一版输出“准确率只有20%”这种完全不可用的东西时，要一起参与复盘：是标注样本不足？噪音太多？还是分类标准模糊？

通过增加典型语境样本、优化正负例比例，我们逐步把模型效果提升到70%。

在这个过程中，产品不是真正动手优化模型的人，但必须是那个推动“业务 → 数据 → 模型 → 结果”闭环的人。

技术与业务间的翻译

AI产品经常卡在「客户听不懂技术」「算法团队听不懂业务」之间。

• 算法团队说：“模型在长尾场景下的召回率不足。”要对客户解释：“当销售用特别隐晦的方式暗示返利，系统可能会漏报，但绝大多数常见违规能识别。”
• 客户问：“为什么不做到95%准确？”回应：“语言的变形空间太大，就像监管也需要人工抽查一样，AI可以帮你过滤掉70%的高风险对话，让人力集中在最难的30%上。”

这种“技术翻译”工作，一方面是管理客户建立正确预期，另一方面就是在这种保护下，让算法团队能专注于真正的优化点。

从质检到画像的延伸

在基础质检功能稳定后，我们拓展到客户画像：

• 标签维度：客户偏好、风险等级、生命周期、价值等；
• 数据来源：CRM+会话记录+行为特征；
• 应用场景：例如识别出“理财关注+高价值客户”，系统就能推荐对应产品，并提供安抚或劝导话术。

这里的挑战同样在于翻译：客户经理希望“帮我知道客户到底想要什么”，产品需要把这种朴素诉求转化为可计算的因子与标签体系，并与算法团队一起确定哪些因子是固定的（如时间、频次）、哪些是动态的（可配置规则）。

04 系统功能与架构

这就是产品经历要主导设计和梳理的部分了，我们和客户一起大致确定了以下模块：

• 质检功能：实时查询、违规检测、申诉与审批；
• 关键词与知识库：敏感词、安抚话术、知识库关键词管理，支持批量导入；
• 因子管理：固定因子、动态因子，用于训练和规则配置；
• 客户画像：标签管理、画像生成、营销场景应用；
• 核验与报表：人工核验模型结果，报表回溯违规率与业务效果。
• 技术架构方面（协助项目经理确定）：前端React、后端SpringBoot、数据库MySQL，容器化部署（Docker+Kubernetes），模型支持异步训练与自动化部署。

一款产品从出生到落地，从来不是一蹴而就的。它需要一次次磨合：数据的磨合、算法的调试、功能的迭代，以及人与人之间的沟通。

作为产品，瓶颈往往不在算法，而在数据与业务转化：

1. 产品经理必须敢于“下场”，参与数据标注规范制定、样本质量把关、效果验收。
2. 把算法团队的“技术成果”翻译成客户能接受的“业务价值”，让技术懂业务，让业务信任技术。

如果说还有什么改进空间，那应该是需要更早建立标准SOP，包括需求调研模板、数据清洗规范、模型验收标准和客户复盘机制，这样前期就不会晕头转向加很多不必要的班了。