刚把一个AI辅助的AFC试点项目从需求梳理推到上线趁热把方案里那些踩过、绕过、填过的坑都写出来。这篇文章不聊概念只聊怎么落地哪些场景用AI是真解决问题哪些是硬凑KPI在国产化工控平台上跑AI模型怎么选、怎么改、怎么部署还有就是从项目验收的角度哪些验收项是必须提前卡死的。如果你是做AFC集成、轨道交通信息化或者智慧城轨规划的朋友应该能从这里拿到一些直接能用的思路。1. 为什么说AFC到了必须拥抱AI的阶段AFCAutomatic Fare Collection自动售检票系统在国内轨道交通里已经非常成熟闸机、售票机、读写器、票务中心这一套体系几十年跑下来稳定性是有的。但稳定归稳定老系统的脑子确实不够用了——它只能按预设规则运行遇到规则覆盖不到的情况就只能靠人工兜底。1.1 传统AFC系统的三个老毛病第一个老毛病是客流响应滞后。AFC系统每天产生海量交易数据但这些数据主要用于事后清分、结算和对账没有真正用来预测和引导客流。早高峰某个站突然涌入大客流闸机开再多也可能堵成瓶颈等调度发现再调整运力高峰期已经快结束了。第二个老毛病是设备运维被动。传统模式下闸机、售票机、检票机大多是坏了再修。设备每天运行十几个小时机械磨损、传感器漂移、通信异常都属于渐进式故障早期完全没有信号等到报警出来往往已经影响乘客通行了。第三个老毛病是稽核靠人工。票务稽核主要靠事后抽查交易流水、比对监控视频人力成本高而且漏检率不低。逃票、尾随、异常进出站这些行为在大量交易数据里找异常用传统规则查询的方式很难覆盖全量。1.2 AI能解决的不只是少排队AI的价值在于把AFC从被动响应转成主动感知。单看少排队其实是最表层的价值。往深了说AI解决的是三个核心问题第一把交易数据变成运营决策依据比如通过历史客流实时进站数据预测未来15至30分钟的客流峰值提前调闸机模式、增开双向通道第二把设备维护从计划修变成状态修通过震动、电流、通信时延等数据预测设备剩余寿命在故障发生前更换部件第三把票务风控从抽查变成全量监测用无监督算法实时筛查每一笔交易的异常特征。所以说AI不是给AFC锦上添花而是补上老系统在感知、预测、决策三个层面的短板。这也是为什么近两年智慧城轨、智慧车站的规划里AFCAI几乎成了标配方向。但标配归标配落地时具体怎么结合、用什么架构、跑什么模型这里面的门道才是本文想展开说的。2. 五个真正落地的高价值场景2.1 客流预测让机器提前半小时知道人来了客流预测是AFCAI里最容易被低估、但实际收益最明显的场景。核心思路不复杂把AFC的交易数据进出站记录、闸机通道使用率、售票数据、外部数据天气、节假日、周边大型活动和历史客流规律喂给模型预测未来15到30分钟甚至更长时间段的客流趋势。技术上常用的是时间序列模型加特征工程比如LightGBM、Prophet条件允许也可以上LSTM这类时序模型。我实际做过的方案里最有效的组合是分站点训练轻量级梯度提升树。每个车站单独建模因为不同站的客流特征差异太大换乘站早高峰是潮汐流景区站周末是脉冲流办公区站平峰期几乎没波动。全局一个模型很难兼顾。特征上除了时间片星期几、几点、是否节假日最重要的特征是前15分钟实际客流这个实时特征对短期预测的贡献极大。模型输出的不是单点值而是客流等级低/中/高/极高因为运营端需要的是要不要加开通道的决策而不是一个精确到个位数的预测值。这个场景落地的关键不在于模型多高级而在于把预测结果接到AFC的业务系统里。预测出来客流要涨闸机要自动切换成常开模式、客服中心要提前增派人手、广播系统要提前播放疏导提示这些联动才是真正产生价值的地方。2.2 闸机通行从刷一下到看一眼闸机是乘客感知最强、也是AI最容易被吐槽过度设计的地方。目前主流方案有两类一类是人脸识别过闸这个方向很多城市已经在试点。它的核心价值不在少掏一次卡而在于与安检、无感支付结合后的通行效率提升。真正的难题不是识别模型本身而是活体检测和防伪——用照片、视频、3D面具绕过识别的攻击手段已经非常成熟上线前必须做针对性测试。另一类是通行行为识别用闸机附近的摄像头判断乘客通行状态比如有没有尾随、逆行、滞留。这是传统红外对射方案做不到的红外只能判断有没有人通过识别不了是不是同一个人过了两次。用目标检测多目标跟踪可以实时分析通行行为异常时自动触发拦截或报警。我在项目里比较推荐的做法是两步走第一阶段先上通行行为识别因为它是纯增量能力不需要改票务逻辑第二阶段再根据运营方意愿和合规评估考虑人脸识别过闸。直接上来就全面推行刷脸过闸容易在合规和用户体验上翻车。2.3 设备运维从坏了再修到提前换AFC设备的故障模式其实非常有规律很适合做预测性维护。以闸机为例常见的渐进式故障包括通行传感器红外衰减导致误判、扇门电机电流异常导致动作卡顿、读卡器线圈老化导致识别率下降。这些故障在彻底失效前都会有一些细微的信号变化。预测性维护的核心是采集设备运行状态数据建立健康度模型。数据源主要有三类设备自检数据AFC设备本身有自诊断功能能上报传感器状态、电机电流、通信质量等参数。这些数据量不大但都是高价值的结构化信号。日志数据设备运行日志里藏着很多隐性信号比如读卡失败率持续上升、闸机开关门超时次数增加都是老化前兆。人工巡检记录维修人员的纸质记录如果能数字化就是很好的标注数据源但现实中普遍缺这一步这也是很多预测性维护项目卡壳的原因之一。模型层面多数场景不需要深度学习。用XGBoost对结构化状态数据做异常分或者对关键参数做趋势回归效果已经足够。我见过最有价值的落地是备件库存联动预测到某站点设备的某类部件未来两周内故障概率超过阈值系统自动提示库房预调配件同时生成本周巡检重点任务单。这才是从预测到决策的闭环。2.4 票务稽核盯住每一笔异常交易AFC的票务稽核属于典型的数据很多、规则不全、异常难找场景。传统规则稽核能覆盖的场景有限比如短时间内在不同站点重复进出站、进出站时间异常短、票价计算与距离明显不匹配等这些用SQL就能查。但更隐蔽的异常行为比如团伙式分段逃票、利用设备故障逃票、尾随出站规则就无能为力了。我的方案是规则引擎无监督异常检测并行规则引擎保留传统稽核逻辑负责处理明确已知的异常模式这部分的优势是完全可解释稽核人员能理解每一笔告警的理由。无监督模型孤立森林或自编码器负责发现未知异常对全量交易数据做分布建模找出偏离正常模式的数据点作为待核查名单推送给稽核人员。这套组合的实际效果是规则引擎保住基础覆盖率无监督模型抓出规则覆盖不到的漏网之鱼。不过要注意无监督模型的误报率较高所以它输出的应该是一份按照异常分数排序的待核查名单而不是直接判定为逃票。人工核查仍然是必要环节AI在这里的角色是缩小范围而不是直接定罪。2.5 智能客服把人工坐席留给真正难的事票务客服场景是AI应用里用户感知最直接、落地门槛相对较低的一个。尤其在AFC领域大量客服咨询集中在几个重复性问题上票卡怎么退、超时怎么算、闸机吞卡了找谁、手机扫码失败怎么办。智能客服落地的关键不是能回答多少问题而是能不能在回答完问题后直接办事。比如乘客反馈闸机吞卡传统人工客服需要先记录、转交、等待运维人员处理流程很长。如果智-能客服系统能直接联动AFC后台查询设备状态、核对交易记录、自动生成工单甚至评估后直接发起退款流程这才是真正的效率提升。技术实现上基于知识库的检索式问答RAG架构目前是性价比最高的方案不需要训练行业大模型只需做好知识库切片、检索策略和复核兜底机制就能覆盖大多数高频问题。3. 国产化平台上的AI部署实战聊完场景来说说部署。这两年轨道交通项目对国产化有硬性要求很多朋友一听到国产化平台上跑AI第一反应是性能够不够。我的经验是够不够取决于你选什么模型、怎么优化以及你的预期是否合理。3.1 为什么一定要强调国产化主控这里多说一句背景。AFC系统属于轨道交通核心系统对供应链安全、自主可控的要求非常高。以往主控基于国外芯片架构和生态在长周期运营中存在断供、后门、授权等隐患。国产化替代不仅是政策要求也是行业长期稳定运行的保障。国产化替代在AFC上有几个层面主控芯片、操作系统、中间件、应用软件。芯片层面龙芯在工控领域的应用是一个代表性趋势它采用自主指令集架构不依赖国外授权这一点在供应链安全上是很关键的。我所在的几个项目在评估国产化方案时优先考量的就是架构自主性、生态成熟度和工控场景适配能力。3.2 龙芯2K3000平台适合干什么龙芯2K3000是面向工控场景的处理器平台适合承载AFC设备的主控和边缘AI推理任务。它让我印象最深的地方不是单点算力而是工控场景的系统级适配宽温、抗震动、长时间稳定运行这些对于每天运行十几个小时、环境条件不友好的车站设备来说远比峰值性能重要。在实际部署里我会这样规划它的角色作为闸机/售票机主控承担业务逻辑、通信协议、外设管理这部分工作负载是确定的2K3000完全能胜任。作为边缘AI推理节点运行轻量化的AI模型完成客流统计、设备健康度预测、通行行为识别等任务。它的设计目标不是跑大模型而是跑够用且高效的小模型。这两类任务的共性是实时性要求高、负载可预测、需要长期稳定运行恰好是工控平台的优势区。相反如果非要在边缘端跑百亿参数级别的大模型那不是平台的问题是方案设计的问题。3.3 边缘端的模型怎么选、怎么改在国产化工控平台上部署AI模型选型是决定成败的关键。我总结了一套三个优先的选型原则优先选轻量级网络目标检测用YOLOv5s/YOLOv8s这类轻量版而不是YOLOv5l或YOLOv8l分类/回归任务优先推荐轻量级梯度提升树或者1D-CNN只有必要时才上Transformer类模型。优先做量化压缩把FP32模型量化到INT8推理速度通常能提升2到4倍内存占用减少到原来的四分之一左右。量化必然带来精度损失所以要提前在测试集上量化前、量化后的精度指标确保损失在可接受范围内。优先优化推理框架先跑ONNX Runtime再考虑是否引入更底层的加速库。不要一上来就上最高级的方案先用最简单的方式跑通流程再逐步优化。3.4 一套轻量化部署的参考做法分享一套可以参考的部署流程基于龙芯2K3000平台适用于客流预测、设备健康度分析这类结构化数据场景第一步模型训练在x86服务器上完成。用常规的Python环境训练模型导出为ONNX或者直接保存为树模型的二进制格式。这个阶段不用考虑嵌入式优化保证模型的精度优先。第二步针对目标平台做模型适配。如果是神经网络模型把算子版本对齐到ONNX Runtime支持的算子集如果是树模型确认推理库在目标平台上的兼容性。我的经验是树模型在国产平台上的兼容性普遍比神经网络好很多能选树模型就尽量选树模型。第三步量化与压缩。在x86上做量化校准生成INT8模型然后在目标平台上跑一个完整的测试集对比量化前后的精度指标。如果精度下降超过1到2个百分点需要回退到FP16或者混合精度。第四步在目标平台上做性能压测。实测推理时延、CPU占用率、内存占用、长时间运行稳定性。这一步最容易被忽略但恰恰是最关键的。AFC设备是长周期运行一个内存泄漏可能运行两周才暴露而两周已经过了验收期。如果实测发现性能不够优先调整思路不是换更强的平台而是换更小的模型剪枝或换backbone、降低输入分辨率、减少推理频率。比如通行行为识别从每帧检测改成每3帧检测精度损失很小CPU开销可以直接减半。4. 我在项目里踩过的那些坑4.1 数据问题脏数据比算法烂更致命做AI项目大部分时间不是在调模型而是在洗数据。AFC数据虽然质量在工业数据里算不错的但仍然有大量细节问题交易流水里的站点编码不统一有些设备上报的编码是旧版本不洗直接用模型学到的规律就是错的。时间戳精度不一致有的设备精确到秒有的只精确到分钟做时间窗口特征时差别很大。客流数据里大量重复值尤其夜间低峰时段因为客流计数器在无人的情况下会重复上报状态。一个教训做数据清洗的人口径必须在项目第一天就定下来。谁的客流定义是过闸次数、谁的定义是实际进站人数两者差一个换乘客流的计算口径。团队里如果这个不统一后面每个环节都在埋雷。4.2 闸机误判宁可松不要严通行行为识别模型最容易出问题的不是漏报而是误报。想象一下乘客正常出站AI误判为尾随闸机突然关闭乘客被夹一下这事的严重性比有个尾随没拦住大得多。所以这个场景的阈值设置原则是宁可漏报不可误报。在模型层面做置信度连续帧确认双保险只有连续多帧都判定为异常且置信度超过较高阈值才会触发拦截。单帧的异常判定只记录不动作留给后台做人工复核。这个原则在项目汇报时一定要跟运营方讲清楚否则他们会觉得AI怎么这么多漏报实际上是在安全边界做了取舍。4.3 兼容性国产化不等于换上就完事国产化替换一个很大的隐性成本是生态兼容性。芯片和操作系统换了底层的驱动、编译工具链、第三方库版本全都要重新适配。很多团队遇到的坑是在x86上代码编译得好好的交叉编译到国产平台各种报错然后发现是某个底层的数学库版本不兼容。我的经验是项目启动第一天就把开发环境拉到目标平台上跑一遍先跑最小可运行程序比如一个Hello World加一个矩阵乘法确认工具链、库文件、调试手段全部就绪再开始写业务逻辑。这个先通环境、再写代码的顺序能省掉后面大量的返工时间。另外一个值得特别注意的点是操作系统版本和内核。国产化平台上的操作系统版本、内核功能与通用发行版可能有差异尤其是涉及实时调度、网络性能调优的场景差异往往藏在系统调用层。所以性能测试不能只看基准测试分数必须用真实的业务负载去压。4.4 安全与合规AI上线前的底线检查AFC系统涉及交易和乘客数据安全合规是不可跨越的红线。人脸识别相关的场景必须提前做好个人信息保护影响评估明确数据采集范围、存储期限、使用目的。这一点不仅仅是合规问题在项目验收时如果隐私保护方案讲不清楚评委一票就能否决。模型安全也容易被忽略。AI模型本身可能成为攻击面对抗样本攻击可以让目标检测模型失效数据投毒可以让稽核模型学习到错误的异常模式。AFC是生产系统建议至少做到三点模型输入做合法性校验、模型推理结果做风险分级、关键模型的更新走审批流程并留痕。最后一个经常被问到的合规风险点AI判定的结果能不能作为处罚依据。我的答案很明确不能。AI的稽核结果只能作为待核查线索任何涉及乘客权益的判定都必须有人工复核环节并且给乘客提供申诉渠道。这既是合规要求也是技术边界。5. 从试点到上线的一些实话很多同行会问这套东西到底能做到什么程度我的真实感受是能跑、有用、但别神化。AI在AFC里的角色更像一个敏锐的辅助员它能在海量数据和实时场景里帮运营人员发现肉眼看不到的规律和风险但最终的决策和处置还是需要人来把关。从试点到上线我有几个实在的建议先选单点场景验证价值不要一上来就做大而全的智慧AFC平台。客流预测或者设备健康度选一个切口两三个月见到效果后面再推广就顺理成章了。把可解释性放在模型精度之前AFC的运营人员不会相信一个只说有异常、不说为什么的模型。所以方案设计时就要考虑特征重要性分析、告警原因回溯这些能力。关注长周期稳定性AFC设备7×16小时不间断运行AI模块必须考虑长时间运行的资源泄漏、精度漂移问题。上线后的第一个月每周都要检查模型的实际推理效果和资源占用。在我看来AFCAI在短期内的主线不会是彻底无人化而是人机协同AI帮人看数据、找风险、提效率人做决策、做处置、做复核。这套组合真正跑顺了比单纯追求全自动要务实得多也给后续智能化演进留出了扎实的土壤。