十万个 why：大模型做意图识别和 NER，为什么别再用 Prompt 提取 JSON？

最近在弄个智能售后客服的 AI 改造项目业务逻辑的第一步非常明确就是要把用户口语化的发问转成后端系统能看懂的结构化参数。用专业的 AI 术语来说这叫 意图识别Intent Recognition 和 命名实体识别NER, Named Entity Recognition。1. 意图识别与 NER 到底是个啥没做过 AI 的同学听到这两个词觉得很高大上其实用大白话解释就是找动词和找名词。举个例子用户在客服框里发了一句“我昨天买的 iPhone 15 发货没订单号 8848赶紧的。”如果我们直接把这句话扔给后端的 Java 代码Java 根本不知道该调哪个接口。这时候就需要做两件事意图识别找动词 判断这个用户到底想干嘛是想退款、催发货还是开发票在这句话里意图显然是 Query_Logistics 查物流。NER找名词/实体 既然要查物流后端接口肯定需要参数。从这句话里我们要提取出关键实体{product: iPhone 15, order_id: 8848, time: 昨天}。以前没有大模型的时候算法工程师为了干这事儿得用 BERT 这类传统 NLP 模型标几万条语料辛辛苦苦训练几个月而且如果遇到生僻商品名还经常识别不出来。现在有了 LLM 大语言模型很多同学觉得这简直是白给的送分题连模型都不用训直接写了一段 Prompt“你是一个数据提取专家。请提取用户输入中的意图intent、商品名product和订单号order_id。必须且只能以 JSON 格式输出绝对不允许包含任何多余的汉字”在测试环境跑了几十条数据完美输出 JSON开开心心上线了。结果一上生产环境就报错下游的后端节点疯狂抛出 JSONParseException。2. 奇怪的问题拉出线上日志看到大模型的返回结果可以说是防不胜防明明千叮咛万嘱咐只准输出 JSON但大模型就是给你自由发挥一下(1) 现场一自带排版的废话它确实输出了 JSON但非要在前后加上礼貌的废话和 Markdown 标记好的根据您提供的信息提取结果如下{ intent: Query_Logistics, order_id: 8848 }希望对您有帮助后端的 JSON.parse() 碰到这些汉字和反引号解析失败报错。(2) 现场二随意重命名昨天说好的字段名叫 order_id今天它觉得 order_number 更地道自作主张把 JSON 的 Key 给换了。后端的反序列化对象拿到的值全是 Null。(3) 现场三无中生有最致命用户明明只发了一句“查一下我的快递”压根没提订单号。但大模型为了保持 JSON 结构的完整自己瞎编了一个 order_id: 123456这导致系统直接去查了别人的订单引发了严重的越权 Bug(4) 为什么会这样因为我们在潜意识里把大模型当成了一个听指令的函数但大模型的物理底层本质还是一个概率输出的机器。在经历了强化学习RLHF后大模型被刻意训练得“礼貌、热情”。你让它提取数据它顺手在开头加一句“好的”在它的概率模型里是一件极其“合理且正确”的事。指望用 Prompt 去约束它生成严格的机器语言就像是用道德规范去约束交通事故必然会有防不住的时候。3. 意图提取方案真正的 AI 工程化落地中想要让大模型 100% 稳定地做意图识别和 NER我接触过的几种做法。(1) 解法一给占位符首先解决瞎编数据的问题提供提取规则绝对不要要求大模型强制填满每个字段。必须在字段的描述里提供显式的找不到处理策略。例如order_id: 用户的订单编号。如果用户输入中未提供必须填充固定字符串 NOT_FOUND绝对禁止自己推测或编造。有了这个规则后端拿到 NOT_FOUND 就可以直接过滤或者触发客服的反问逻辑“请问您的订单号是多少呢”。(2) 解法二Function Calling不想写正则去扣字符串可以用 Function Calling 函数调用。不要强迫大模型输出纯文本 JSON而是告诉大模型后端有一个现成的函数叫 query_order(order_id, product_name)请你根据用户的输入去调用这个函数。”主流大模型在训练时都进行过专门的工具调用微调。当它发现需要调函数它会意识到自己现在是在填写参数表而不是在跟人聊天。这样一来后端收到的就不再是一段带有 Markdown 的文本是个标准的函数调用 Payload 对象直接用 Java 或 Go 就能序列化。(3) 约束解码技术在金融、医疗这种对容错率为零的严苛场景哪怕 Function Calling 偶尔改变字段类型也是不可接受的。这时候就得用约束解码Constrained Decoding。如果用的是 OpenAI 的新接口或者用 vLLM 等框架在本地部署大模型就可以开启这个功能。它的工作原理是大模型在生成每一个词前都会在几万个词库里算一遍概率。约束解码机制会拿着你定义好的 JSON 格式规则直接拦截在推理引擎的最底层。比如按照规则这个位置只能填双引号 那底层状态机就会把词库里其他 99990 个词汇比如“好的”、“抱歉”的生成概率强行修改为 0模型想胡说直接在物理层面上拦截只能吐出绝对符合格式的 JSON 字符串。4. 说在最后把大模型当做纯粹的黑盒让它直接吐出文本去怼后端的解析层是系统设计上最脆弱的一环。日常的业务代码是确定性的但 AI 业务很多开发最大的痛苦就是总是试图用传统的“输入-输出”思维去驾驭一个充满概率性的大模型。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。