背景#

意图识别在agent中是一个比较常用到的处理方式。目的识别出不同的意图之后，组织后续的上下文，从而避免一次性吧海量的工具、大量的不同方向的提示词全都塞给大模型。

在前期的学习中，认为的 #意图识别。就是调用一个大模型，来判断用户的意图。

但是意图识别的关键性，让大家不得不开始思考一下问题：

意图识别#

意图识别可以放在loop循环之前，也可以在loop循环中，以tools+系统提示词的方式，被大模型调用。

但更好的方式是放在loop之前。因为意图识别最主要的目的，就是用来帮助agent组织上下文。只有在进入loop之前，识别出意图，才能在进入loop之前，加载对应的：system prompt、tools、上下文。

定义清除候选意图，并提示大模型，不能无中生有。我们还可以再意图识别之后，结合代码校验的方式，来确定这个意图是否真实存在。

定义清除意图的边界 意图就和tools一样，只用意图的名字来让大模型区分很不靠谱，需要每个意图添加对应的描述。如果两个意图比较相似，通过举例子的方式，来让边界清晰。举例：商品推荐：3000元以内推荐什么手机；商品比较：iPhone15和小米15哪个更适合拍视频

加入few-shot 如果几个意图容易被搞混，我们可以加入few-shot。包括正面例子和反面例子

拒识，现实中容易存在一种情况：用户描述了一些不完整、不清楚、不想管的问题，大模型还是会强制识别到某一个意图上。所以需要引入更复杂的解决方案，目前最热门的是三层意图识别。

页面引导：通过前端引导用户点击某个按钮，某个选项，直接确认用户的意图
关键字提取/正则匹配：用户输入了“继续”，就要明白继续上一个意图；或者给不容意图指定出规则，识别到具体规则后，直接确认意图。代码层优势：快、便宜、准；缺点：死板，容易出现意外情况

通过使用一个轻量的模型，结合用户的输入和候选意图，让大模型判断。结合置信度，告诉大模型给出意图的同时给出置信度。用来确认需不需要启动第三层

如果场景复杂，容易识别出错，当前两层无法识别时，调用深度推理大模型进行识别

评估置信度的指标采用 Top-k accuracy。当取top-3时，让大模型返回三个候选意图，只要真实意图在候选意图中，就算命中。真实场景中往往采用 top-1.

评估要考虑一下几点：

分意图准确率：如果一个系统大部分都是商品推荐，极少需要订单处理。那么全猜商品推荐的准确率也很好

拒识：应该拒识的时候，系统是否拒识，而不是强加到某一个意图上

解决办法：

意图树：通过意图分层，一层一层把子意图归纳下去，在通过循环迭代的方式，来逐步加载子意图，直至最小意图。优点：结构清晰；准确率高。缺点：性能差
结合检索，先缩小候选意图：在意图识别之前，结合用户问题，先加上一个意图检索，缩小候选意图范围
意图正交，边界重叠：针对意图边界重叠的情况，我们可以采取两种策略，分：把重叠的部分拆分为一个单独的意图；合：两个相似的意图合为一个一样
多意图：首先要是被到底是不是多意图，可能存在用户的一些过程性描述；如果是多意图，就输出多个意图，后续通过plan模式来编排；或者多线程并发执行
向量匹配，沉淀业务经验映射意图
1. 把业务中遇到的意图识别都积累下来，进行向量存储，每一个积累下来的意图都对应一个真正的意图，通过向量检索，检索出已经存在映射的意图。
2. 优点：成本低，把行业黑话、专业用语等结合起来