本文介绍在实习中接触到的 交通场景下大模型的意图评测

什么是意图

本质是讲用户输入的query 在进行规整化 改写等操作之后 高度抽象的 且具有强烈倾向性的问题

换句话来说 就是将用户输入的query改写为大模型更易接受的形式 这一过程需保证不修改用户的问题原意 且改写后询问的效果显著提升（不然改写就没有意义了） 这一效果可以体现在回答的内容倾向性、回答的格式、自然语言的风格等多个方面

那么

意图识别的难点在于？

  1. 输入不规范、输入形式多样化：使用自然语言查询，甚至非标准的自然语言。比如上面提到的“附近的特价酒店” 、“上海到扬州高速怎么走”都是自然语言查询的例子，又如 “披星 ( ) 月”、“吾尝终日而思矣, 下面“

  2. 查询词表现出多意图：单个词在不同领域有多个意思 此时意图无法准确识别到用户的需求 eg:mac是指macbook还是mac地址

  3. 意图强度：和上一点类似 同义词表现出多个意图 且在此基础上不同用户的需求不一样 此时需要根据上下文和所有搜索数据进行综合判断

  4. 存在时效性变化：随时间推移某些词的意图强度存在变化 这个需要知识库和搜索组件等综合判断

  5. 数据冷启动：上方说到上下文是在同义词时判断用户意图的工具 但是新会话或者会话较短的时候 此时判断依据不足 很难获取真实意图（识别不准确）

  6. 没有量化的评估指标：CTR、MAP、MRR、nDCG 这些可以量化的指标主要是针对NLP任务的整体效果的，具体到用户意图的预测上并没有标准的指标。

NLP任务 —— 自然语言处理任务 指让计算机能够理解分析生成使用人类语言的任务 上述指标分别指

  • CTR（Click-Through Rate）：点击率，衡量用户点击的可能性；
  • MAP（Mean Average Precision）：平均准确率，主要衡量排序结果的精准度；
  • MRR（Mean Reciprocal Rank）：平均倒数排名，强调正确答案出现在前列；
  • nDCG（normalized Discounted Cumulative Gain）：标准化的累计收益，强调结果排序的质量。
    可以看到 都是整个任务中的执行效果 而意图识别作为局部 没有标准的衡量指标

意图识别的方法？

意图识别本质上其实可以理解称为一个分类问题 将用户的倾向在多个情景中区分开来 所以她的方法和分类模型的方法差不多

基于词典模版规则分类

  • 分类效果好 有精确识别度要求 覆盖度低

  • 规则制定更新需人工维护

一种是基于规则模板的分类方法，这种方法比较适用于查询非常符合规则的类别，通过规则解析的方式来获取查询的意图。比如：今天天气怎么样， 可以转化为 [日期][实体: 天气][询问词: 怎么样]上海到曼谷的机票价格， 可以转化为 [地点] 到 [地点][机票 / 车票 / 火车票] 价格
如：236.2美金能换多少RMB？
[236.2][美金][今天]能换多少[人民币]?
[数字][货币单位][日期]能换多少[货币单位]?
★通过知识图表，来替换/对应/归一
解析：
数量：236.2
源货币：美元（不再是“美金”）
目的货币：人民币
★配合自己建立的一些语言模型，可以比较好的解决召回率比较低的问题
模型训练的比较好的话，相对召回也很不错
但是比如购物啊什么的，是无法做这种信息模型的

基于过往日志匹配

  • 穷举 类似于搜索引擎

有对应的词表（如 brand、product、attr 等），然后用户的查询通过切词 → 归一化 → 匹配这些词表分类，从而判断出意图。

通过词表直接匹配的方式来获取查询意图，同时，也可以加入比较简单并且查询模式较为集中的类别。
查询词：德国[addr] 爱他美[brand] 奶粉[product] 三段[attr]
查询模式：[brand]+[product];[product]+[attr];[brand]+[product]+[attr]
当然查询模式是可以做成无序的。这种意图识别的方式实现较为简单，能够较准确的解决高频词。由于query一般是满足20/80定律，20%的query占据搜索80%的流量。但是，80%得长尾query是无法通过这种方式来解决的，也就是说这种方式在识别意图的召回可能只占20%。同时，需要人工参与较多，很难自动化实现。
如：北京的天气怎么样啊
（停用词替换） –> [北京][天气][怎么样]
（查询词归一） –> {城市][关键词][疑问词]
（顺序无关） –> {[城市], [关键词], [疑问词]}

基于分类模型

直接使用分类模型来进行意图的识别

这种方法在普遍情况下：

  • 效果更好 效率更差

但是具体效果之间的差异取决于所使用的模型规模 场景中query的具体情况

因为意图识别的效果 就依赖分类模型的质量

这里给出ai所分析该方案下的设计差异

阶段 分类模型的耗时来源 对比说明
推理阶段 需要将文本转成向量（如BERT嵌入）再输入模型 比对词表或匹配正则的速度慢得多
模型复杂度 若使用的是深层模型如BERT或RoBERTa，模型推理耗时更明显 特别是在对话系统中要求毫秒级响应时
部署代价 模型服务需要GPU/加速器，推理时占内存大 匹配规则用 Trie 树/O(1) 查表即可
并发处理能力 模型可能成为性能瓶颈，特别是在大规模用户同时请求时 简单匹配几乎无性能瓶颈
因素 影响说明
标注数据质量 如果训练集中的语料分类不清晰，模型就学不会边界
数据规模 小样本下，容易过拟合或泛化差
意图设计合理性 类别之间如果重叠度高，模型难区分（比如“查天气” vs “查空气质量”）
模型结构选择 简单模型（TextCNN）可能不如上下文建模强的模型（BERT）表现好
上下文支持 若有对话上下文信息可用，模型能更好 disambiguate（消歧义）

如果有一点设计的基础的话 此处很容易就会想到普遍的设计方案有：

“主模型 + 规则兜底” 的混合式意图识别框架

用规则兜住“已知的确定性”，用分类模型理解“未知的可能性”，是当前意图识别系统最通用且稳妥的架构。

评测方案

分类评测

构建评测集 单条目中应该包含一个前提句子 假设句子 任务需要判断这两个句子间是否是逻辑相融的

蕴含(entailment)， 矛盾(contradiction), 中立(neutral)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[ 
    {
        "query": "车辆年检新多少钱",
        "assume": "车辆年检怎么收费",
        "result": "entailment"
    },
    {
        "query": "如何在12123上查看车辆年检标志",
        "assume": "如何在12123上查看违章信息",
        "result": "contradiction"
    },
    {
        "query": "这条路是单行道，只允许从南向北行驶。",
        "assume": "今天早上这条路发生了一起交通事故。",
        "result": "neutral"
    }
]

同义词语义消岐

意图中可以分为

同义词 近义词 上位词 反义词（此处先不做说明）

对于英语 还需要做词干提取等

但是在某些场景下有的词可以互相替换，有些词是只能单向替换

换一个方向就不对了，例如周杰伦可以替换为周董，但是周董只能在一定情况下替换为周董

如何挖掘这一些同义词？

电商场景下：
我们可以从用户搜索词、商品标题、搜索和点击来获取。最根本的来源还是商家对商品标题的优化，聪明的商家会把同义词堆叠在标题中，以期望获取到更多的流量。

本质上就是对日志的查询抓取
在同一场景下 假如w1和w2是同义词 那么搜索所出现的商品重合度会比较高 我们可以在调研后 设置一个阈值 超过这个阈值就可以判断是同义词

抛开场景 抽象一点说就是：
通过统计或者word2vec训练词的相关性，找到高相关度的词。统计这些词在标题中共同出现次数，即w1和w2的共现次数。

通过word2vec，我们可以找出原始词和最相似的10个单词，然后我们统计origin 和substitute（原始词和替代词）在标题中的共现次数，通过这种挖掘，我们找到大量的候选词对，这种词通过人工review可以作为同义词的候选。

对这种情况稍微做一些扩展，我们就能得到同义query到同义query之间的对应关系。

纠错语义消岐

这个实际上是属于下方Query的一部分内容 但是为了和上方的同义词消岐就先并列

纠错最高频的方法就是根据单Session内前后的点击情况 将用户手动输入的纠错前和纠错后的query 挖掘出来 即可构建类似遮掩的纠错pair对

Query改写

上方的语义消岐是指将一些相同意思的词组合归在一类 这里则是指将语义已知相近的词归一化 改写为类似对应的模版语句

上方所说的纠错其实也能算是这里比较重要的模块之一 除此之外还有扩展、删除无效词、转换

扩展

将现有的数据拓展成更多的描述 例如说“宇智波佐助”的召回数据比“佐助”高 所以在改写的时候 就会改写成前者

删除无效词

从上方的一些描述可以猜到 在意图之中 类似语气词、助词这些东西是没有价值的 所以在改写这一步会给他丢掉

转换

这个就是最普遍的改写 由于不同人对同一个事物的形容可能有偏差 所以使用同义词连接的方式将所有的同义词都映射为一个词语 归一化

模型相关特征

词性&主体识别&属性/标签识别

在搜索过程中，不同的term对于搜索的意义也不同，例如“桃子味的牙膏”，这里的桃子是修饰牙膏的，核心词为“牙膏”，核心词应该就有更高的查询分值。在意图类目识别时也应该根据核心词来确认。所以提前对query做词性分析，NER，以及对待搜索物品或类目做tag将会帮助检索。常见的序列词性标注有基于规则和基于统计以及CRF，Bi-LSTM+CRF或者带上预训练BERT的方法。标注的目的在于找到合适的query重心。目标在于识别出核心产品词语 即核心词语权重

词语画像&词语用户画像

有些词语在query中分数较低，可以根据query的词语打分来选出高分值词语。词语画像是指词语具有一定指向意义，例如“大嘴猴”、“古奇”等词语是特定品牌词，提前确定好品牌词的映射关系；词语的用户画像是指在query中能够对用户的身份做联想理解，例如“高档酒店”能够一定程度映射出用户身份，“洛丽塔”/“少女连衣裙”能够一定程度反映query指向的年龄，图片说明了能够根据query的个性化标注来完成浏览型query与转化型query的处理。所以对词语的画像能够帮助query更好的理解用户。

实体识别

本质意思就是将用户的搜索query拆解成为结构化的实体信息 防止被目前实体以外的语义造成误导影响 例如“火鸡面” 应该本身是一个主体 而并不是 “火鸡 + 面”

而实现实体识别的方法主要是采用序列标注的方法

序列标注是NLP中一种任务形式：

给一个词序列（句子），对其中每一个词打标签（即分类），标签可能是实体类型或其他语义信息。

eg:
输入句子：

1
我 想 买 火 鸡 面

目标输出标签（BIO 标注法）：

1
O  O  O  B-attr  I-attr  B-product

含义是：

“火鸡” 是一个属性词（如口味）

“面” 是产品类实体

所以整体意图可能是搜索一个“辣鸡口味的面”

这种逐词标注方式，就是序列标注（Sequence Labeling）。

词权重

在将query分词的时候 同时关注每一个词语的权重 这个权重本质上就是通过上方所说的上下文信息 + 大数据统计信息得到的 同时也可以规定阈值 根据具体情况规定丢到权重过低信息 捕捉有效信息改写召回等

又或者可以直接召回高权重信息改写 将召回结果与低相关度做一个排序展示 等等等技术方案

eg

背景

以上是问题所出现的背景 根据这个背景 我们可以整理得到意图有类似查询事件等

思路

此处的评测思路是 利用日志中出现的真实query 通过prompt构建一个预测的意图（实际情况可根据上方所述三种方法来进行构建） 本质目的是构建一个评测集

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
你是一个问题工具分配专家，请认真理解【问题】和【工具描述】，根据【工具描述】找到解决【问题】适合的工具。
【工具描述】
event_tool: 查询事件，根据时间、方向、桩号、路段、事件类型查询事件数据/记录/同环比，事件类型包括了：占用应急车道、行人闯入、异常停车、施工区域等
flow_tool: 查询车辆通过情况、车流量和车速的数据和同环比数据
jam_tool: 查询拥堵相关数据(如:拥堵事件、拥堵指数、拥堵次数、拥堵时长、拥堵时间、拥堵长度、排队长度、拥堵距离等拥堵信息)
speed_tool: 运行情况，京哈高速的整体情况，指挥大厅的整体运行情况和指挥大厅的建设情况
introduction_tool: 介绍大屏孪生系统
situation_tool: 提供路网运行态势、不包括态势报告
feature_congestion_tool: 查询未来、预测时间点、时间段、未来一周的拥堵指数
car_traj_tool: 根据车牌号查询车辆轨迹，车牌号例如“冀C22345”，可查询车辆的实时或历史轨迹，或对车辆启动视频追踪
event_type_filter_tool: 筛选事件类型的展示，对播报事件类型筛选，比如查看交通事故类型事件、不查看交通事故类型事件等
car_data_tool: 根据日期时间、驾驶方向、车辆的颜色、车辆的类型，查询车辆（图片、车牌）数据
event_handling_tool: 事件普通处置、忽略事件、标记为误报事件、生成事件处置预案、生成事件应急处置预案、查看未处置的事件、查看事件处置报告
percetion_tool: 检测插件列表，有车辆检测插件、车牌识别插件、行人检测插件、烟火检测插件、开集检测插件、路面病害识别插件，具备识别和检测图片中车辆、行人、烟火、路面病害、开集信息能力
report_tool: 生成/查看日报/周报/月报/年报/态势报告
control_device: 定位/查找/查看/打开/看看设备，包括摄像头/视频/监控、收费站、情报板、服务区、分合流设备、雾天诱导设备、ETC门架、气象检测设备、可变限速标识
veh_passing_tool: 根据路段/桩号查询过车清单/过车记录
event_video_tool: 查看事件详情或者根据事件序号查看事件附近的视频
dataquery_assets_tool: 高速设备设问数。可提问、检索内容包含设备名称、桩号、设备位置、设备状态、设备类型、设备所属系统类型、设备所属路段等属性或分布、趋势情况。返回内容包括设备信息、设备列表、设备数量等数据。设备类型包括摄像头、情报版等，设备状态包括运行中、故障中、维修中等。可以使用柱状图、折线图、表格展示
dataquery_weather_tool: 高速气象信息问询。包括桩号、能见度、风速、风向、温度、湿度、气压、雨量、降水强度、路面积雪、气象设备的问询，能在指定的桩号、路段上查询这些气象信息或分布、趋势情况。可以使用柱状图、折线图、表格展示
chat_tool: 闲聊，非专业问答，例如新闻、常识问题，在其他工具匹配不到时选用
rag_tool: 专业知识问答、介绍，包括但不限于：标准规范，招标文件，设计文件，规划文档，法律法规，政策公告，企业规章制度，运行条例，操作手册，用户规范，河北高速集团，京哈高速，广东高速集团，利通等
【格式要求】
1.必须是JSON格式
2.答案有且仅有参数：
tool_code:str 工具代码，既每行开头的工具代码，在这些代码中选择 [event_tool,flow_tool,jam_tool,speed_tool,introduction_tool,situation_tool,feature_congestion_tool,car_traj_tool,event_type_filter_tool,car_data_tool,event_handling_tool,percetion_tool,report_tool,control_device,veh_passing_tool,event_video_tool,dataquery_assets_tool,dataquery_weather_tool,chat_tool,rag_tool]

【问题】
对冀C12345启动视频追踪。

【答案】

然后将日志文件中用户的操作抽取出来 加以脚本抽取 再次结合大模型做一个归一 即可获取到对应的query 用户的真实意图

之后的评测流程即可根据该图设计

即接上 构建了意图的评测集后 需要再次通过prompt对意图的准确性打分（根据打分的结果偏差决定是否需要人工review）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
你是自然语言意图识别评测人员，根据【问题】、【标准意图】对【预测意图】的准确性进行打分：
分档0、2，具体的打分标准请参照分档描述，此外你还需要提供打分和对应的评分依据，参考答案中为json格式，key为指标，值为指标对应的值。

【分档描述】
0分：标准意图和预测不一致。
2分：标准意图和预测一致。

【特别注意】：
-不需要对query进行二次意图判断，只需要关注标准意图和预测意图是否完全匹配。

现在你可以开始回答了：
【问题】查询桩号K76+791处的路面结冰告警详情，不排序。
【标准意图】dataquery_weather_tool
【预测意图】 dataquery_weather_tool