300-500意图怎么召回?

30 秒回答

1. 层次化意图体系设计（意图聚类+二级路由）
2. 多路召回策略（粗排+精排+重排）
3. 上下文压缩与动态示例选择
4. Embedding模型微调与领域适配

回答与解析

答案要点

• 层次化意图体系设计（意图聚类+二级路由）
• 多路召回策略（粗排+精排+重排）
• 上下文压缩与动态示例选择
• Embedding模型微调与领域适配
• 实时性能与准确率的平衡方案

核心思路：三层架构解决"长上下文+多意图"困境

一、层次化意图体系（解决300+意图爆炸）

一级路由（10-20个意图簇）→ 二级分类器（每簇20-30个意图）

• 聚类策略：基于业务语义+历史query共现，用K-Means/Spectral聚类构建意图树
• 动态路由：先用轻量模型（TinyBERT级）做一级判断，缩小候选空间到30个以内

二、多路召回机制（替代全量Prompt）

• 精排层：用Cross-Encoder对Top-K候选重排序
• 动态示例选择：从该意图历史Query中选3-5个最难区分的作为Few-shot，而非全量意图说明

三、上下文压缩技术

• 意图摘要：每个意图用结构化描述替代长文本（意图名+核心槽位+典型说法）
• Query改写：用SLM先做指代消解和补全，减少历史轮次依赖
• 滑动窗口+记忆压缩：对多轮对话，用摘要模型压缩历史为关键状态

四、工程落地要点

• 索引分片：按意图簇分片存储，路由时只查对应分片
• 缓存策略：高频Query直接走规则缓存，P99延迟<50ms
• 增量更新：新意图只需更新对应簇的索引，无需全量重训Embedding

效果预期：从全量500意图Prompt（约8k tokens）压缩到单次检索Top-5意图+Few-shot（<1k tokens），准确率损失控制在2%以内。

口语版讲法(约4分钟)

• 一句话定位：意图多+上下文长=分层拆解
• 意图聚类+二级路由缩小范围
• 多路召回+精排替代全量Prompt
• 上下文压缩与工程平衡
• 风险与取舍

这道题问的是，当意图数量大到几百个、上下文又长的时候，怎么做到既准确又高效。本质上是在问，怎么把传统大模型那种一次塞进全部意图的笨办法，拆成一套能伸缩的工程架构。

我的核心思路是分层。先做意图聚类，把300到500个意图聚成十几个簇，每个簇里再分20到30个细意图。这样第一级路由只需要判断属于哪个簇，用个轻量模型比如TinyBERT就够了，候选空间一下子压到几十个。第二级再在簇内做细分类。你可以把一级路由理解成前台客服先问'您是要退货还是咨询政策'，二级才是具体处理。

但光有分层不够，真正的召回不能靠全量Prompt。我会走多路召回。一路是向量召回，用领域微调过的 Embedding 模型，比如在客服退款数据上 SFT 过的 Bi-Encoder，把用户Query和意图描述都转成向量，做 ANN 检索。另一路是关键词召回，给每个意图维护一个关键词倒排索引，像'退款''少发货'这种词直接命中。还有一路规则兜底，高频意图用正则硬匹配。三路结果合并后，用 Cross-Encoder 做精排，选Top-3到Top-5。这样实际送到大模型里的上下文，从原本几千token的意图列表，压缩到几百token的候选加几个 Few-shot 示例。

举个例子，在电商客服场景，用户说'我买的手机没收到，但物流显示签收'。向量召回会把'物流异常''签收未收到'之类的意图排前面，关键词召回靠'没收到''签收'命中，规则可能直接匹配'物流投诉'。精排后选最相关的两三个意图，再带上每个意图的历史相似Query做Few-shot，大模型就能准确判断。

上下文压缩还要做一件事。多轮对话里历史很长，我会用一个小模型先把用户当前Query做指代消解和补全，比如'它'指代上一轮的手机，再把历史轮次压缩成关键状态，比如'用户已确认收货'，而不是把整段对话原文塞进去。说白了，就是只保留决策需要的信息。

这里有个坑。分层和压缩虽然省资源，但会引入误差。如果一级路由分错了簇，后面的召回全白费。所以上线我会特别关注一级路由的准确率，低于95%就说明聚类粒度不对，需要调簇内相似度阈值或者补一些难分样本。另外，向量召回依赖Embedding质量，如果意图描述写得太宽泛，比如'售后'这种，召回就会把退货和投诉混一起。我的做法是给每个意图写结构化描述，包含意图名、核心槽位、典型说法，甚至一两个反例，这样Embedding能学到边界。

还有一个延伸点，就是当意图数量继续涨到上千时，单纯分层可能不够，我会考虑引入 Knowledge Graph 来组织意图之间的层次和关联关系，这样路由和召回都能更准确。

所以整体上，我更倾向把这道题看成一个系统工程问题，不是选一个模型就能搞定。核心是分治和压缩，同时给每层留好容错和监控。如果让我落地，我会先搭一个最小闭环：聚类加多路召回加精排，验证准确率损失在2%以内，再逐步加压缩和缓存。

关键一句:当意图数量超过一千时，可以考虑引入知识图谱来组织意图层次和关系，提升路由和召回准确率。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做电商客服的意图识别，用户说“我要退换货”，但退换货下面有几十种细分情况。如果系统要支持300多个意图，你不可能把所有描述都塞进prompt里吧？那你怎么处理这种长上下文和多意图的问题？

2. 问法 2 · 层层追问

   意图识别要支持几百个类别，你是怎么设计的？……prompt太长怎么办？……如果我用向量检索先召回一部分候选，那召回和精排怎么配合？……那最终你怎么保证实时性？

3. 问法 3 · 直球架构

   直接说方案：在大规模意图识别系统里，要处理300到500个意图，怎么克服上下文长度限制并做到有效召回？请讲清楚你的层次化设计、多路召回和压缩策略。