本地AI错题辅导小程序：端侧推理与离线优先架构实践

本地AI错题辅导小程序这个话题动手之前我犹豫了很久核心纠结就在端侧推理到底能不能扛住题目解析和错题归档。后来我干脆把这个顾虑放到架构里解决把端侧推理作为主链路把云端作为兜底第一条规则是可离线第二条规则才是要聪明。下面把架构选型、模型选型、功能实现到性能调优的完整落地思路写出来供想做教育类小程序、离线知识工具或者端侧模型应用的开发者参考。1. 项目起点为什么把错题辅导放进本地端侧做错题辅导的人大概都有过这种体验题目拍了一堆文件夹越建越多真到复习的时候却不知道从哪一题开始想让学生把题干输进在线工具又担心题目和个人信息上传后不好收场。错题这个场景天然有几个绕不开的需求随时随地能翻、讲解要足够快、学生数据不能随便往外送。端侧推理正好踩在这三个需求点上。1.1 错题场景到底痛在哪从最基础的操作看传统错题整理是典型的“高成本低回报”流程。学生拍下题目后先要裁掉白边、修正角度再手动输入题干和正确答案最后还要耐着性子写一两句错因分析。很多学生不是不会做题而是懒得整理错题本往往坚持不到一周就断更。用AI来代劳拍照识别和解题思路整理是顺理成章的想法但这里有一个容易忽略的前提题目数据里面往往夹着试卷上的姓名、学校、学号很多家长对“上传到某个在线题库”这件事天然有抵触。另一个痛点是复习缺乏节奏。难得把错题录入系统后续却只是静态保存。用户的真实需求不是“有一堆错题躺在相册里”而是“过一段时间之后系统能提醒我重做某道题并且告诉我为什么当时会错”。这个逻辑对网络依赖很敏感如果学生在教室、地铁或者地下室网络不稳定或接口限流讲解和复习就一起瘫痪了。本地AI方案能保证最核心的错题闭环在任何弱网环境下都能跑起来。1.2 端侧推理能解决什么也要知道代价端侧推理带来的第一收益是隐私。OCR识别和模型推理都在本机完成题目照片不出设备学生对数据流向的心理负担会小很多。第二收益是稳定离线可用意味着不再依赖云端接口的可用性也不会因为服务端响应慢而让用户干等。第三收益是成本结构简单个人开发者部署一个小程序不用为每次请求的云端推理费用发愁至少主流程的成本是可控的。不过端侧推理并不是万能药。本地模型的参数量级摆在那里数学逻辑、长文本理解能力天然弱于云端大模型。同一台设备上不同手机的推理速度差异也可能很大低端机跑3B模型就可能卡顿高端机跑7B模型也未必顺畅。所以我在设计时没有走“全离线”的极端路线而是给系统留了一个云端兜底通道常规题本地解决复杂题或者用户主动要求的时候才走云端。这样既保住了隐私和离线体验又不至于因为极端题目把用户体验拖垮。2. 架构选型一条离线优先的技术主线架构选型的核心不是选哪个模型最强而是要让“拍照—识别—讲解—归档—复习”这一整条链路在离线状态下尽量自洽。如果一开始就去折腾最新的大模型很容易陷入“模型能力很强但根本跑不动”的尴尬局面。2.1 先定框架OCR预处理加推理模型双段式我一开始考虑过集成多模态模型直接让一个模型既看图又做题。这个方向在云端很成熟但放到端侧就受制于显存和算力单次推理时间动辄十几秒用户根本等不住。真正跑下来更稳的方案是双段式链路先用OCR模块把题目图片转成结构化文本再把文本交给端侧语言模型去理解、讲解、出相似题。双段式的好处是好调试。OCR识别错了问题定位在识别环节推理结果不理想问题定位在模型和prompt环节不用整套端到端一起翻。处理链路大致是这样拍照原图进入预处理模块自动裁边、透视校正、增强对比然后做文本识别把题干、选项、公式尽量识别成可编辑文本再做结构化整理按题干、选项、答案、解析四段组织最后组装成prompt交给端侧推理模型。把一张大图变成纯文本后模型要处理的噪声大幅下降对参数量和上下文长度的要求也就降下来了。2.2 端侧推理模型选型的三个硬约束模型选型首先要看参数量。端侧设备的内存是固定预算系统、App、模型、图片缓存必须同时共存。就我的实测经验1B到3B参数的模型是甜点区3B模型配合INT8量化大概占用1.5到2GB内存中等配置的手机还能顺畅跑4B到7B在高端机上才比较稳低端机上容易出现加载后闪退。我建议先按3B设计跑通整个链路后再根据设备分级动态选择更小或更大的模型。第二个约束是量化格式。FP16、INT8、INT4各有取舍FP16精度高但体积太大INT8精度损失较小、体积减半INT4内存占用最省但数学推理类任务容易“飘”。错题场景里有大量公式计算和逻辑推导对精度比较敏感所以我的默认方案是INT8如果设备内存实在紧张再启用INT4并配合答案回验发现校验不过就走云端兜底。第三个约束是上下文长度。错题题干通常不会特别长但加上prompt模板、标准答案、用户作答内容以及生成结果整体token数量很快就会涨起来。3B模型不建议直接挑战8K以上上下文最好控制在4K附近。对于特别长的题干先在OCR后做摘要压缩不要硬塞给模型。2.3 存储与功能模块怎么切本地存储我直接用了成熟的关系型数据库没有自己造轮子。核心原则是三类数据分表保存OCR文本是“题干的原始形态”推理结果是“AI当时的理解”复习记录是“用户的实际掌握度”。这三类数据如果混在一张表里后面想回刷历史错题、重新生成解析会非常痛苦。模块切分也遵循单向调用采集模块负责拍照和OCR理解模块负责组装prompt和推理复习模块负责调度和提醒。采集模块不直接调用复习模块复习模块也不反向调用OCR。这样每条链路上的数据流向清晰某一个环节升级时不用推倒重来。功能模块大致可以分成四块错题采集与预处理、推理讲解与相似题生成、错题库与标签管理、复习计划与进度统计。四块之间的接口用简单结构体传递数据不搞过于复杂的中间层。小程序的体量不需要过度设计但接口形状要固定好。3. 核心功能拆解与实操要点功能拆解阶段最容易把目标做变形。错题辅导小程序不是聊天机器人它的核心动作只有一个丢进一道错题返回一个能让学生看懂、能纳入复习流程的讲解结果。所有功能都要围绕这个动作收敛。3.1 错题采集不是拍了照就能用拍照得到的是图片不是题干。采集这一步如果不做预处理后面OCR和推理的准确率都会很难看。实际操作中我会先做四件事裁掉多余区域、灰度化、自适应二值化、边缘增强。倾斜超过10度的图片还要先做透视校正否则识别器看到的是一堆歪斜的行断词断句问题会非常严重。OCR之后还有一个容易被忽略的后处理环节。识别出来的文本通常是一行一行的碎片需要把行合并成完整段落去掉页脚、页码和试卷水印。如果题目是选择题要把“A.”“B.”这种选项标记拆出来单独存如果是填空题要识别出下划线对应的空位。它可以让模型更清楚题目结构。公式识别是理科错题里最棘手的一块。普通OCR对纯文本识别不错遇到分数、根号、上下标就容易出错。我的做法是在OCR模块里单独跑一层公式检测识别不了公式时不要把半截公式硬塞给推理模型而是把对应区域截成小图附在记录里并提示用户手动输入或跳过。宁缺毋滥避免让模型基于错误公式去做无意义推理。3.2 提示词模板与稳定讲解端侧模型不是拿来直接聊天的它需要一套固定的、低自由度的提示词模板。我自己用的模板大致是这样请扮演错题辅导老师根据以下材料讲解题目 【题干】 题干文本 【用户作答】 用户填写的答案 【标准答案】 标准答案若有 【要求】 1. 先提炼考点不超过两个 2. 用不超过200字分步骤讲解 3. 出一道同类题只换数字或场景不增加难度。 注意如果题干信息不足请直接说明不要猜测答案。这里有两个关键参数。一是temperature要调到0.1左右太高的随机性会让每次讲解风格差异很大学生看着不像同一套逻辑链。二是要约定结构化输出格式最好让模型按固定字段输出方便程序解析。端侧小模型有时会输出残缺的JSON程序侧要做一个格式修正层用正则把考点、解析、同类题三段提取出来而不是让前端拿到裸文本去解析。我还专门在prompt里加了“信息不足请直接说明”这一句这在错题场景里非常有用。模型不至于为了显得聪明而强行编一个错答案至少能把不确认的信息用更保守的方式呈现出来。3.3 复习计划与错题归档错题辅导的核心不是讲一次会而是让用户在恰当的时间重复训练。复习计划我采用了一个简化的间隔复习策略当天复习第3天再看第7天再练第15天做一次综合检验。每次复习时用户选择“已掌握”“模糊”“还是不会”三个状态已掌握进入下一个间隔模糊则重置当天节点还是不会则退回第1天重新来过。这个策略不复杂但对端侧系统很友好不需要云端定时任务来调度。本地通知需要注意系统授权如果用户不愿意开通知权限也不要强求可以把提醒做成一个“今日待复习”列表等用户主动打开小程序时呈现。错题归档也要设计好标签体系。除了学科、章节、题型这些常规标签我叫“错因”标签计算失误、概念不清、审题错误、方法不会。这四类错因对应不同的复习策略前两类靠刷题巩固后两类需要重新讲解和梳理解题路径。把错因把握住之后复习计划的推荐顺序就会比单纯按时间排序合理得多。4. 端侧推理的落地与性能调优端侧推理是整个项目里最容易出问题的环节。模型选定了、功能写完了真正部署到用户的设备上往往会遇到加载慢、发热、闪退、生成速度不稳定等一连串状况。这一部分与其追求极限性能不如先让系统在大多数设备上都能稳定地跑起来。4.1 从模型导出到量化的完整流程模型落地的标准流程是先把训练好的或开源的中小模型导出成端侧推理格式然后准备一份校准数据用几十道真实错题样本做量化校准量化后到目标设备上跑真实推理记录内存占用和时间再回到量化前做几轮准确率复测。INT8和INT4的取舍需要格外谨慎。我实测下来一部分数学推理任务在INT4量化后准确率波动可能达到10%到15%这对错题辅导来说是难以接受的偏差。所以我默认保留INT8版本只有内存实在吃紧的设备才退回INT4。量化之后一定不要只在模拟环境验证要放到真实手机上跑因为不同设备对量化算子的支持程度不一样同样的模型换成硬件加速后端之后结果可能完全不同。4.2 推理性能优化的几个妙招我自己用下来的经验端侧推理优化有四个优先级很高的手段。第一是模型常驻内存。模型加载非常耗时最忌讳每次请求都重新加载。把模型加载到内存后常驻后续请求只需把输入塞进去生成时间才是真正的业务延迟。第二是限制最大生成长度。讲解类任务控制在200到300个token之内基本够用设定上限之后不要让模型无限写下去既节省时间也减少电量消耗。第三是请求串行。端侧并发模型推理在大多数设备上不仅不会更快还可能因为内存带宽竞争导致整体变慢。处理连续多道错题时用一个队列逐题处理比一次性并行请求更稳定。第四是控制功耗。不要让高性能核心长时间满载运行这会触发设备温度墙导致推理速度越跑越慢。代码里可以把推理线程绑到中小核或者分片处理长任务让设备温度维持在一个合理区间。4.3 端侧推理和云端辅助怎么共存我的实践结论是“端侧为主、云端兜底”是最稳妥的产品形态。端侧模型负责大多数常见题目的讲解和相似题生成云端大模型负责那些端侧明显吃力的、需要复杂多步推理的题目。判断规则不需要太复杂。OCR置信度低、模型自我校验失败、用户主动点击云端讲解、生成结果长度过短这四个条件任意触发其中一个就可以发起云端请求。云端请求只上传题干文本和必要的作答内容不上传姓名、学号等个人信息。这种混合模式既保住了日常使用的高频离线体验又给了系统一个处理疑难题的出口。5. 常见问题与排查技巧实录在落地过程中踩过不少坑这里整理几个出现频率最高的问题以及我当时是怎么定位和解决的。5.1 模型加载就闪退或者内存溢出这种问题十有八九不是模型太大而是内存状态不干净。排查三步法是我常用的套路第一步写一个最小化程序只加载模型和单个推理请求观察峰值内存第二步把UI页面和图片缓存一起加入再看内存曲线第三步检查系统里是否有其他后台服务占着内存。解决办法有几个方向图片压缩成缩略图后再加载推理完成后释放缓存关掉不必要的前台动画同一个时间内只允许一个推理实例存在。还需要注意模型常驻虽然快但如果用户设备有多少可用内存启动时必须做一次可用内存检测不够就先显示“轻量模式”而不是强行加载。5.2 识别和讲解不准先分清错误源头识别不准和讲解不准是两类问题排查方向完全不同。OCR环节出错推理模型再强也救不回来因为输入本身就是错的。这时要提供“重新识别”和“编辑题干”两个入口让用户可以手动修正。很多学生宁可自己改一句也不愿意从头再拍一张。推理环节不准问题多半在prompt和采样参数。温度太高会让输出随机性过强重复惩罚太高会让模型绕来绕去说不到重点。把temperature稳定在0.1附近关掉不必要的随机采样再检查是不是上下文长度不够导致题干被截断。数学题的答案校验也不能省最简单的办法是把模型给出的最终答案代回题干做数值一致性检查不一致就立刻提示用户“这条解析需要复核”。5.3 推理速度忽快忽慢多半是环境问题速度忽快忽慢用户感知最差。排查时先看电源策略很多设备在低电量模式下会限制大核频率。再看后台负载拍照、相册加载、录音等模块如果并行工作推理会明显变慢。还要看温度连续推理十几分钟后设备发热性能就会断崖式下降。我的应对策略是加入设备分级和“精简模式”。低端机上默认先输出考点和核心公式用户点击“展开完整解析”后再生成剩余内容。这样首屏反馈非常快用户等待感大大降低也不会给端侧带来持续的高负载。6. 实际项目里我留下的三个经验项目做得越久越清楚工具和方法可以学但真正指导方向的是那些踩出来的经验。最后分享三条我在这个项目里反复验证过的体会。6.1 最小闭环先于一切优化不要先追求完美模型和漂亮界面先把“拍照→OCR→组装prompt→端侧推理→生成解析→存入本地”这条最小闭环跑通。中间任何一个环节卡住后续所有优化都建立在流沙上。这就像先造一辆能跑的车再去想换引擎和座椅。6.2 一致性比单次正确更值钱错题系统是反复使用的系统学生今天和明天打开应用看到的是同一道题的不同讲解如果语气、步骤、考点提炼方式都不一致会给学习造成很大困扰。把prompt模板固定下来把temperature调低把输出字段固定哪怕偶尔牺牲一点惊艳感也要保证一致性。6.3 掌握度数据要能被系统迭代不要只记录“对或错”这种二元结果。每次复习的状态、作答时间、查看解析的次数都可以沉淀成本地数据。间隔上几周后系统能回看这些数据重新评估学生的薄弱点把“计算失误”和“概念不清”区分开推荐不同的复习策略。真正有价值的不是模型本身而是模型和复习数据一起形成的闭环。