一通销售电话打完，录音躺在那里，CRM里却什么都没发生。想让通话内容自动变成续约风险、新库存、测量问题、法务审核这样的标签，很多人第一反应是堆提示词规则——字符串越积越多，规则链越拉越长，最后没人敢动。

换条路：用嵌入（embedding）做分类。给一小批已标注的样例生成向量，再给每段新转录文本或文本块生成向量，取余弦相似度最高的那个标签。分类器的决策和模型供应商的客户端分开，这条边界才是真正有用的地方。

把流水线想成一排货架

每个货架贴一个标签，上面放几条示例通话笔记。新笔记来了，放到示例离它最近的那个货架上。改造前是一堆字符串加一条不断变长的提示词规则链；改造后是一份带版本的示例集、一次向量运算、一个可以被检查的决策。

媒体团队的销售通话，标签可以是 renewal_risk（续约风险）、new_inventory（新库存）、measurement_question（测量问题）、legal_review（法务审核）。示例要描述你希望在CRM里触发的动作，而不是复述通话里的词。“他们签约前需要受众报告”比一条只含“报告”二字的示例有用得多。

余弦相似度是实用的第一版打分方式。两个向量维度必须一致且不能为空，逐位相乘求和，再除以各自模长的乘积。分数最高的标签胜出，同时把第一名和第二名都留下来供人工复核。

两个实现细节别踩坑

第一，供应商允许批量请求时，把输入文本和标注示例打包成一次请求，并按返回的索引还原顺序。第二，示例要和嵌入模型一起做版本管理。换了模型却只重新嵌入新文本，新旧分数就不可比了，标注向量必须作为一次迁移整体重建。

标签集大了以后，别每次调用都把全部示例重新嵌入一遍，改成和已存储的向量比对。k-means 索引可以缩小搜索范围；向量集合大到需要高效最近邻检索时，FAISS 是常见选择。分类策略仍然归应用层：返回几个候选、什么时候弃权、每个标签触发哪个CRM动作，都得自己定。

供应商边界靠什么撑住

可移植性是设计约束，不是一个勾选项。嵌入向量本身在关键意义上并不跨模型可移植——换新模型通常就要新向量和一轮新评估。可移植的是它外面那层契约：文本进、向量出，标签、分数、复核元数据都显式记录。

所以起步别盯着厂商排行榜，先建一个小型标注语料：取 50 到 100 条有代表性的通话片段，按应该触发的CRM动作打标，再按类别检查误报。这个数量是起步实验，不是基准结论。两个方案分数接近时，供应商可移植性可能比那点相似度差距更值钱。

Anthropic、Google Gemini、OpenRouter、Together 在更广的模型生态里也是现实选项，但在核实其当前的嵌入接口和模型行为之前，不该假定一个聊天或路由产品能替代嵌入服务。

已经在跑多个后端服务的团队，统一网关能让这层边界在运维上更简单：一个密钥、一张账单。这对凭证管理有用，但它不消除验证模型就绪度的必要，也不替代对源文本、模型、向量版本和决策的中立记录。如果组织已有深度集成的直连供应商栈，迁移和重新嵌入的成本可能盖过这点运维便利。

输入换成整通电话，什么变了

嵌入分类的是你手上已有的文本，转录是另一个阶段。把转录生产者放在同一个接口后面，并记录文本是全通话、单个说话人轮次还是摘要。按说话人轮次切块能保留局部意图；只按字符数切，可能正好把解释动作的那句话劈成两半。

还有两条边界值得说清。嵌入接口不是专用的审核接口，安全判断应该用供应商有文档的审核能力，或在支持的设计下用带结构化 JSON 兜底的聊天模型。实时语音会话和图像放大也是独立能力，塞进这个分类器只会让CRM决策更难推理。

批量导入前先审运营成本。这个工作流里有成本估算接口，批量就该在那里估，而不是拿几次交互调用的经验去猜。估算结果和任务一起存下来，再和实际返回的每次调用元数据对照。

决策规则

标签描述的是语义、你又能凑出有代表性的示例时，选嵌入。第一版用余弦相似度，保留最高分和次高分供复核，每次模型迁移后重新评估。

选供应商要测完整工作流：转录形态、向量维度、重试行为、索引、CRM动作映射、审计数据。同一句话，三家供应商可能给出三个都说得通的分数；只有你自己的标注通话集能告诉你哪种错误可以接受。

胜出的设计很小：一个供应商中立的嵌入接口、带版本的示例、可见的相似度分数、给不确定标签留一条人工通道。这样即使背后的模型换了，分类依然有用。