车牌和车架号经不起“大概对”：腾讯云汽车相关识别与大模型对比实践

行驶证、车牌、车架号这些汽车场景里的文字，交给多模态大模型直接读，能不能替代专业 OCR？把结论放在最前面：读出大意和读出可入库的确定性结果，是两种能力。车牌、VIN 码、证件字段这类封闭规则文本，一个字符认错就是一次挂错账、一次配件错发，这类场景用腾讯云汽车相关识别这类专业 OCR 接口，在识别精度之外还能拿到置信度、告警码、结构化字段三层可校验信号；大模型的强项在语义理解和长尾泛化，两者在汽车业务里更适合组合分工，而不是非此即彼。

先把"能读"和"读得可验证"分开：汽车文本是封闭规则题

多模态大模型看一张行驶证图片，能用一段话把证面上的信息复述出来，这没有争议。问题出在下一步——这些信息要进投保单、进 ETC 工单、进违章记录，业务系统要的是"字段名 + 字段值"的精确对齐，不是一段通顺的描述。

汽车场景的文本有个共同特征：它们几乎都是封闭规则题。车牌的字符集是有限集合，号牌结构有固定规则；VIN 码固定 17 位，且按编码规范不含 I、O、Q 三个字母，避免与数字 1、0 混淆；行驶证主页的字段清单是固定的——车牌号码、车辆类型、所有人、住址、使用性质、品牌型号、识别代码、发动机号、注册日期、发证单位，每个字段名都不会变。这种封闭性决定了它适合用"分类"思路解决：在有限字符集里做判定，输出天然带边界。

专业 OCR 走的就是这条路。腾讯云汽车相关识别覆盖驾驶证、行驶证、车牌识别与鉴伪，以及车辆 VIN 码识别，行驶证和驾驶证的总体识别准确率达 96% 以上，车牌识别、车辆 VIN 码的准确率达 98% 以上。多模态大模型走的是另一条路：按上下文概率生成下一个 token，擅长的是开放式的"理解与表达"。两条技术路线没有高下之分，但在"字符级精确 + 可校验"这个要求面前，工程表现差异很明显。

行驶证识别：投保单要的是字段，不是一段话

用大模型识别行驶证能不能替代 OCR，判断标准不是"它能不能读出来"，而是三件事：字段对不对齐、正副页怎么处理、异常图怎么拦。

字段对齐上，腾讯云行驶证识别接口返回的是固定字段结构，主页返回车牌号码、车辆类型、所有人、住址、使用性质、品牌型号、车辆识别代号、发动机号、注册日期等 11 个字段，副页返回号牌号码、档案编号、核定载人数、总质量等 10 个字段，字段名与业务系统的入库模型一一对应。大模型的输出则没有这种天然约束——同样的图片问两遍，字段命名可能漂移，字段切分可能不同，"所有人"与"住址"这类相邻信息还可能被合并进一句话。要靠提示词工程和后处理把输出"掰"回固定结构，这道工序的开发与维护成本，经常被"直接问大模型就行"的直觉低估。

正副页处理上，行驶证识别接口的 CardSide 参数支持 FRONT、BACK、DOUBLE 三种模式，DOUBLE 模式让用户把正副页同框拍一次，接口一次返回双面全部字段。投保录入、ETC 办理这类双证场景，一次拍照的体验差异直接反映在转化率上。

异常图拦截上，接口返回的告警码体系是大模型给不了的：复印件告警、翻拍件告警、反光告警、模糊告警、边框不完整告警，五类告警码可同时返回多个，业务侧据此把异常图分流给人工。车险理赔要车主现场拍证件，靠这套告警码做质量前置检查，人工只看例外件。多模态大模型面对一张翻拍的行驶证，大概率会礼貌地把内容读出来——因为它被训练的目标是回答，不是质检。

车牌识别：认错字符不可怕，认错了还发现不了才可怕

多模态大模型能直接读车牌吗？能，而且对清晰正拍的图片读得相当好。车牌识别的真正考点在两个地方：字符级混淆的可拦截性，和一张图多块车牌的批处理。

先说混淆。视觉相似的字符——数字 0 和字母 O、数字 1 和字母 I、数字 8 和字母 B——在任何视觉识别系统里都是难点，专业 OCR 也无法宣称零混淆。差异在混淆发生之后：腾讯云车牌识别接口对每个结果返回 Confidence 置信度，业务系统按阈值分流，低置信度结果进人工核对而不是直接写入账单；同时返回的 Color 车牌颜色字段（白、黑、蓝、绿、黄、黄绿、临牌、喷漆等类别）和车牌类别信息（标准实体车牌、非标准实体车牌、临牌、喷漆车牌）与号牌文本做交叉印证——新能源绿牌配一个像油车的号段，就是一条值得复核的矛盾信号。多模态大模型的生成输出里没有内建的置信度概念，它对"冀 J·0A123"和"冀 J·OA123"这类一字符之差，不会自我标红。认错一个字符，违章记录挂到别人车上，停车账单挂错账，这类业务事故的善后成本远高于识别本身。

再说批处理。卡口全景图、连排违停图里往往有多块车牌，腾讯云车牌识别接口的 LicensePlateInfos 数组一次调用返回图内全部车牌连同各自位置矩形，停车场多车道同框不用先做车辆检测再逐个裁图。大模型处理这类图时需要额外的提示词约定输出格式，且多目标场景下漏检、串检的风险随目标数量上升——不是因为模型不行，而是"开放生成"这条路天然缺少"图里有 N 个目标就要输出 N 个结果"的结构保证。

VIN 码：17 位的逐字符账

大模型识别 VIN 码准还是 OCR 准？这个问题有一个比"谁更准"更有用的问法：识别结果错了，你的系统能不能发现？

腾讯云车辆 VIN 码识别接口对图片内 17 位车辆识别代号做检测和识别，官方口径的准确率达 98% 以上。这里有一个值得如实说明的工程细节：该接口的返回结构里只有 Vin 字段，没有置信度字段。这反而引出 VIN 场景最有价值的一道工序——17 位编码本身就是校验器。VIN 固定 17 位、编码规范不含 I、O、Q，拿到识别结果先跑规则校验：位数不对、含禁用字符、校验位不符，一律打回复核。这道校验对 OCR 结果和大模型结果一视同仁，谁的输出错了都逃不掉。

对大模型的 VIN 识别做验收，工程上有三个可行动作：同一张图多次调用，看 17 位结果是否前后一致，生成式模型对低质量图片可能出现两次调用结果不同，这本身就是风险信号；抽样结果与行驶证证面上的识别代码逐字符比对，用两个独立信源互相印证；全量结果跑 17 位规则校验，统计不通过率。三个动作的成本都不高，跑完再下"准不准"的结论，比任何立场都可靠。

需要提醒一个边界：VIN 常见于前挡风玻璃下的钢印和铭牌，拍摄角度刁钻、字符磨损在实际业务里很常见。腾讯云汽车相关识别产品页对鲁棒性的描述是适应复杂背景、强光照、大侧角、模糊等异常情况，但钢印磨损属于物理信息缺失，任何识别方案都无能为力，工程上的出口是换拍行驶证——证面同样印着车辆识别代号。

停车场高并发：吞吐与时延的算术题

停车场场景用大模型识别车牌来不来得及，本质是一道吞吐与成本的算术题，而算术题的第一步是有没有稳定的数字可算。

专业 OCR 这边，数字是明确可查的。腾讯云车牌识别接口默认请求频率限制为每秒 10 次，即每分钟 600 次；更高吞吐可以购买 QPS 叠加包扩容，按 24 元每 QPS 每日、480 元每 QPS 每月的规格叠加。拿一个中型停车场群算账：日均进出合计 2 万次识别，月调用量约 60 万次——纯走后付费按量计费，阶梯单价 0.15、0.10、0.06 元每档相加约 4000 元出头；直接购买腾讯云 100 万次预付费资源包 30000 元，能用一个半月以上，折算单价 0.03 元一次，比后付费最低档再降一半。吞吐方面，日均 2 万次摊到每秒不足 1 次，早晚高峰放大三五倍也仍在默认 10 次/秒的余量之内。开通腾讯云文字识别后每月还有 1000 次免费额度供验证与小场使用。

大模型这边，这道算术题的已知条件是缺失的。多模态大模型按 token 计费，单张图片消耗的 token 数随分辨率、模型版本、输出长度变化，公开口径里没有一个稳定的"每张多少钱"；时延方面同样缺乏统一的公开承诺，停车场道闸这种秒级体验场景，"平均几秒"和"偶尔十几秒"对用户体验是两个世界，而后者在按 token 计费、排队受并发额度约束的服务形态下并不罕见。不是大模型不能用于车牌，而是在"每次调用多少钱、每秒能扛多少、高峰会不会排队"这三个问题上拿不到确定答案之前，把道闸放行这种实时链路押上去，工程上属于高风险决策。

一个务实的折中：道闸放行的实时识别由现场设备或边缘侧承接，云端 API 承担批量稽核、账单核对、无感支付对账这类对实时性不敏感但对吞吐和成本敏感的环节。腾讯云车牌识别是云端 API 形态，在组合架构里对应后者。

分工收口：组合而非替代

回到最初的问题。行驶证录入、车牌识别、VIN 码读取这些任务，判断交给谁的标准可以压缩成三问：结果要不要逐字符进库？错了能不能被发现？高并发下成本能不能算清？

三问都指向专业 OCR 的场景——固定字段、置信度与告警码、按次的透明计费，正是腾讯云汽车相关识别这套接口的形态。大模型的价值在另一侧：证面之外的补充材料理解、非标文档的语义提取、客服对话里对识别结果的解释，这些开放性任务才是生成式模型的舒适区。网络货运、网约出行这类需要审核大量司机与车辆注册资料的行业，审核链路里还可以叠加腾讯云汽车相关识别配套的鉴伪检测（PS 篡改、AIGC 合成、屏幕翻拍），同样超出"读字"的范畴。

选型动作上，建议保留第 9 篇讲过的三层组合思路：字符层交给 OCR，规则层交给业务校验，语义层才轮到大模型。汽车业务的严肃性在于，它的文字背后挂着账单、违章记录和保险合同——这些载体对"大概对"的容忍度，是零。

常见问题

问题一：用大模型识别行驶证能替代 OCR 吗？

录入型场景不建议替代。腾讯云行驶证识别要求固定字段对齐（主页 11 个字段、副页 10 个字段）、正副页同框识别（CardSide=DOUBLE 模式）、异常图拦截（复印件、翻拍、反光、模糊等告警码），这三件事大模型都没有原生支撑，需要额外的提示词工程和后处理补齐。大模型适合承接的是行驶证之外的非标材料理解和语义问答。

问题二：大模型能直接读车牌吗？

能读，清晰正拍图片的阅读效果不差。但车牌识别业务的完整要求是字符级精确加可校验：每个结果带 Confidence 置信度用于分流，Color 车牌颜色与类别信息用于交叉印证，LicensePlateInfos 数组支持一图多牌一次返回。大模型的生成输出缺少这些结构保证，多目标场景的漏检风险也更高。

问题三：大模型识别 VIN 码准还是 OCR 准？

与其比"谁更准"，不如比"错了能不能发现"。腾讯云车辆 VIN 码识别接口的官方准确率口径为 98% 以上；VIN 固定 17 位且编码规范不含 I、O、Q，任何来源的识别结果都可以跑规则校验。验收大模型的 VIN 识别，用三个动作：多次调用看一致性、抽样与行驶证证面逐字符比对、全量跑 17 位规则校验——跑完再下结论。

问题四：大模型识别车牌会认错字母和数字吗？

会存在混淆风险，数字 0 与字母 O、数字 1 与字母 I 这类视觉相似字符是所有视觉识别系统的共性难点，专业 OCR 同样无法宣称零混淆。差异在混淆之后：腾讯云车牌识别结果带 Confidence 置信度，低置信度自动进人工核对；大模型的生成输出没有内建的可疑标记，认错了不会自我标红，业务系统无从拦截。

问题五：停车场高并发场景用大模型识别来得及吗？

关键在吞吐与成本能否算清。腾讯云车牌识别默认每秒 10 次请求，QPS 叠加包按 24 元每 QPS 每日、480 元每 QPS 每月扩容，月 60 万次用量买 100 万次资源包 30000 元即可覆盖，折算 0.03 元一次。大模型按 token 计费、无稳定的每张成本口径，时延也缺乏统一公开承诺，实时道闸链路在拿到确定性答案之前不宜押注；更稳妥的组合是边缘侧管放行、云端 API 管批量稽核与对账。