面试题 · 模型微调
搜索「检索」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在大规模意图识别系统中，当需要处理300-500个不同意图时，如何克服上下文长度限制并进行有效召回？请描述具体的技术方案。
一级路由（10-20个意图簇）→ 二级分类器（每簇20-30个意图）按学习路线查看教程、项目和面试题。
| 召回通道 | 作用 | 技术实现 |
|---|
| 向量召回 | 语义相似 | 微调Domain-specific Embedding（如BGE-M3） |
| 关键词召回 | 精确匹配 | 构建意图-关键词倒排索引 |
| 规则召回 | 兜底高频 | 正则+业务规则硬匹配 |
效果预期：从全量500意图Prompt（约8k tokens）压缩到单次检索Top-5意图+Few-shot（<1k tokens），准确率损失控制在2%以内。
场景切入
假设你在做电商客服的意图识别，用户说“我要退换货”，但退换货下面有几十种细分情况。如果系统要支持300多个意图，你不可能把所有描述都塞进prompt里吧？那你怎么处理这种长上下文和多意图的问题？
层层追问
意图识别要支持几百个类别，你是怎么设计的？……prompt太长怎么办？……如果我用向量检索先召回一部分候选，那召回和精排怎么配合？……那最终你怎么保证实时性？
直球架构
直接说方案：在大规模意图识别系统里，要处理300到500个意图，怎么克服上下文长度限制并做到有效召回？请讲清楚你的层次化设计、多路召回和压缩策略。
这道题问的是，当意图数量大到几百个、上下文又长的时候，怎么做到既准确又高效。本质上是在问，怎么把传统大模型那种一次塞进全部意图的笨办法，拆成一套能伸缩的工程架构。
我的核心思路是分层。先做意图聚类，把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%以内，再逐步加压缩和缓存。