目录
一、一个“附近”引发的面试翻车现场
二、本质变化：意图识别从关键词匹配走向语义依存
三、核心机制拆解：多槽位提取的工程架构
四、典型案例 / 对比：规则匹配 vs 序列标注 vs 依存分析
五、工程落地启示：你的测试用例需要补什么
六、趋势判断：槽位间的逻辑关系会成为新门槛
一、一个“附近”引发的面试翻车现场
去年美团招NLP算法测试工程师，我到第三面，面试官给了一道真实线上case。
用户原话：“帮我找附近的便宜餐厅”。
我的意图识别模型输出：意图=找餐厅，槽位={价格=便宜}。没有“附近”。
面试官没直接说错，而是反问：用户明确说了“附近”，你的模型为什么没提取？如果这个请求打到美团App，你觉得应该返回方圆三公里的店，还是全城的店？
我下意识解释：训练数据里“便宜”出现频率高，“附近”可能被当成语气词或未标注…
他打断我：别解释原因。告诉我，你打算怎么设计测试用例，确保这类问题在上线前被拦住？
我哑口无言。因为我知道，我平时测意图识别，用的都是单槽位用例——“便宜餐厅”“附近的咖啡厅”“带我去火车站”。我从来没测过“附近+便宜”这种复合约束。
这不是我一个人的问题。很多做对话系统和搜索测试的朋友，今天还在用“关键词命中率”和“准确率”评估模型。用户说“不辣的川菜”，模型只提取了“川菜”；说“适合约会的安静酒吧”，只提取了“酒吧”。这类错误在线上比比皆是，但测试报告里从来不体现。
面试最后，面试官说了一段话我记到现在：意图识别的下一场竞争，不再是准不准，而是全不全。用户同时提两个约束，你漏一个，体验就崩了。
二、本质变化：意图识别从关键词匹配走向语义依存
五年前做意图识别，核心任务是分类——用户说的是“查天气”还是“订机票”。槽位提取是辅助，用个CRF或者BERT序列标注，能抽到实体就算赢。
今年风向彻底变了。大模型普及后，意图分类的准确率在很多场景下已经超过95%。大家发现用户真正的痛点不是“模型认错意图”，而是“模型漏了约束”。
本质上是用户表达习惯在升级。早期语音助手只能接受“天气 北京”，用户会主动简化。现在用户已经习惯用自然语言一口气说多个条件：“帮我找海淀区评分4.5以上、人均100以下、有停车位、还不用排队的火锅店”。
这种句子里的槽位不是扁平列表，它们之间有逻辑关系：
“附近”和“便宜”是并列约束，必须同时满足
“海淀区”是“附近”的具体化，可能互相冲突
“不用排队”隐含时间敏感，优先级更高
传统的序列标注模型把句子当词串，抽取出一个个实体标签，但不知道这些标签之间是“且”还是“或”，也不知道哪个是主约束哪个是修饰。
所以面试官问“为什么没提取‘附近’”，本质是在问：你的模型有没有能力理解“附近”和“便宜”是同一个槽位类别（餐厅属性）下的两个并列约束？你的测试体系有没有覆盖多约束组合的case？
三、核心机制拆解：多槽位提取的工程架构
一个能处理“附近+便宜”这类复合约束的意图识别系统，需要从三层重构。用这张图来说明：
第一层：意图分类（略，不是本文重点）
第二层：槽位提取的进阶要求
传统做法是序列标注，给每个词打标签（B-price, I-price, B-distance, I-distance）。但对于“附近”这类词，它不是具体数值，而是一个相对范围。
工程上需要做两件事：
实体标准化：“附近”映射成“radius=3km”（城市POI密度中位数），“便宜”映射成“price_range=0-80元”
边界识别：确保“附近”修饰的是“餐厅”还是整个动作“找”。看依存关系——“附近”通常附着在地理名词或直接作状语。
第三层：槽位关系解析（核心难点）
这一步决定了最终查询是“AND”还是“OR”。实现方式有三种：
方式一：规则模板。预定义常见组合模式，例如“A的B”中A修饰B，“又A又B”中A和B并列。优点是可控，缺点是泛化差。
方式二：轻量依存解析。用一个小型BERT判别两个槽位之间的语义关系。输入[CLS]槽位A [SEP]槽位B [SEP]原句，输出关系类别（并列/修饰/冲突/无关系）。我们内部测试准确率能做到87%。
方式三：大模型直接生成结构化输出（GPT-3.5/4级别）。给定prompt，要求输出JSON，key为槽位类型，value为值，并增加relation字段列出约束组合逻辑。优点是准确率高，缺点是延迟和成本。
生产环境的成熟方案是方式二+方式三结合：离线用大模型生成高质量训练数据，在线用小模型推理。
有了关系解析层，系统才能输出类似这样的结构：
{
"intent": "search_restaurant",
"slots": [
{"type": "distance", "value": "nearby", "normalized": "radius_3km"},
{"type": "price", "value": "cheap", "normalized": "0-80"}
],
"constraints": {
"operator": "AND",
"relations": [["distance", "price"]]
}
}
面试官期待的答案，就是你能讲清楚这一层怎么设计和测试。
四、典型案例 / 对比：规则匹配 vs 序列标注 vs 依存解析
拿三句真实用户请求，横向对比三种方案。
Case 1：“找附近便宜的餐厅”Case 2：“找便宜餐厅，要附近的”Case 3：“找餐厅，便宜的和附近的都行”
方案A：基于规则的关键词匹配。
预定义词表{便宜, 附近, 餐厅}
三个case的输出完全一样：{价格=便宜, 距离=附近, 品类=餐厅}
问题：case3的语义是“便宜或附近”（二选一），但规则引擎输出成了“且”，会漏召回。
方案B：BERT序列标注（无关系层）。
标注结果：case1和case2都能正确标出所有实体，但不知道约束关系，默认全部“且”
case3同样出错，因为它无法区分“和…都行”表示的是OR
方案C：序列标注+依存解析（本文第三层）。
依存分析识别出case3中“便宜的和附近的”通过“都行”连接，关系为“OR”
输出约束改为OR，查询逻辑正确
对case1和case2，依存分析能发现“附近”和“便宜”共同修饰“餐厅”，关系为AND
这个对比说明：单纯把实体抽全只是第一步。没搞清楚关系的抽取，等于没抽。
美团内部的一个A/B测试显示，加上依存关系层后，多约束请求的满意度（用户点击率）提升了19%，因为系统不再输出一堆矛盾的结果。
五、工程落地启示：你的测试用例需要补什么
如果你是测试工程师或者算法工程师，以下三个方向立刻可以动手。
第一，构建“多槽位+关系”的测试集。 不要只写“价格=便宜”的单槽用例。写50条组合用例，覆盖以下关系类型：
并列且（and）：舒服且便宜的酒店
并列或（or）：川菜或者粤菜
修饰（attribute）：海淀附近的咖啡馆
冲突（conflict）：便宜的米其林（模型应该识别为不可能，走澄清流程）
每条用例标注期望的约束逻辑（AND/OR/优先级）。跑你的模型看准确率。很多号称95%准确率的系统，在这个测试集上会掉到70%以下。
第二，增加“槽位关系断言”到自动化测试。 传统测试只断言slots列表是否包含某实体。升级后，添加断言约束逻辑。例如：
assert model.constraints.operator == "AND"
assert model.constraints.relations == [["price","distance"]]
这样就能拦截case3那种“都行”被误判为AND的回归。
第三，用线上日志挖掘“漏召”模式。 定期抽样用户请求，对比模型输出的槽位和用户真实点击/后续对话。如果用户说“找附近便宜的餐厅”，模型只出了便宜，但用户最后点击了三公里内的店，说明他补了距离约束。这类样本应该回流训练。
我在一家OTA公司做咨询时，他们的意图识别漏召率高达22%，大部分是复合约束。加了上述三个动作，漏召率降到9%，且没有增加人工标注成本——用的是用户行为隐式反馈。
六、趋势判断：槽位间的关系理解会成为意图识别的标配
大模型的出现，让单槽位提取变得廉价。随便一个BERT微调就能做到90+% F1。但关系理解依然棘手，因为它需要逻辑推理，而不是模式匹配。
未来两年会看到两个变化：
一是测试标准升级。技术面试和内部考评会越来越多地出现类似“用户说X和Y，你的系统怎么处理关系”的问题。只会序列标注的简历会越来越难通过。
二是工程上会形成“小模型+轻量关系模块”的标配。大模型太贵太慢，不适合线上实时推理。但可以用大模型离线生成关系标注数据，训练一个小的关系分类器（参数量<100M）。我们团队用GPT-4生成了2万条复合约束样本，训练了一个DistilBERT，在线延迟仅3ms，关系分类准确率85%。
对三类读者的建议：
在校生：做意图识别项目时，别只满足于跑通ATIS数据集。自己手写20条含“和/或/但/不要”的复合约束用例，尝试用spaCy的依存解析或小模型做关系分类。能讲清楚这个，面试官会刮目相看。
初级工程师：拿你现在的对话系统或搜索接口，跑一遍多约束测试集。记录漏召和关系误判。把这个分析写成技术笔记，附上改进方案。这是晋升答辩里的硬通货。
中高级工程师：思考测试体系的升级。传统QA只验证“模型输出了什么”，未来需要验证“模型没输出什么”。设计端到端的约束覆盖度指标，比如“用户约束满足率”。这比单纯看准确率更能反映体验。
最后问一个你可以立刻去验证的问题：
你的意图识别系统，能正确区分“便宜的日本料理和意大利餐厅”与“日本料理和便宜的意大利餐厅”的约束范围吗？
拿这两句话去测一下。答案会让你吃惊。
