先说一个可能不太讨喜的结论公考类软件往手机里塞模型九成以上不是为了“离线也能用”这个宣传点。我拆过几套同类产品的安装包也自己搭过一套能跑通的复现环境真正把团队逼到端侧架构上的是延迟结构和成本结构——一道题从拍照到出解析云端链路的均值在 2 秒上下晚间高峰抖动到 5 秒以上而这类产品的日活曲线有一个极陡的峰集中在晚上八点到十一点那个时段的排队成本会直接吃掉毛利。所以当我拿到“2026年公考软件技术评测从本地智能体到垂直大模型智蛙公考的技术架构解析”这个题目时第一反应不是它用了什么模型而是它凭什么把模型拆成“本地智能体 垂直大模型”两段来跑。这篇就把这条链路从输入层到输出层完整拆一遍包括量化选型的算账过程、检索增强在题库场景里的落地细节、端云路由的判定阈值以及我在复现过程中踩到的几个真实故障。适合正在做端侧 AI 应用的同学、想了解垂直大模型工程化的开发者以及单纯好奇这类 App 到底怎么运转的考生读者。1. 公考场景为什么逼着开发者把模型往手机里塞1.1 一次云端往返的隐性成本从点击到出解析的两秒半很多人算延迟只算模型推理时间这是最常见的误判。一条完整的云端链路是这样的拍照或语音输入 → 图片预处理与 OCR → 题干结构化 → 意图判定 → 检索召回 → 组装 prompt → 模型生成 → 结果后处理 → 渲染。这条链上真正花在模型生成上的时间往往只占三分之一到一半。我在复现环境里用同一道数量关系题做了 200 次采样云端链路的拆分大致是这样的环节平均耗时占比备注图片上传与预处理320 ms13%图片大于 2MB 时翻倍OCR 与题干结构化480 ms20%含公式识别时更高检索召回120 ms5%向量库命中缓存时降到 40 ms模型生成约 450 token780 ms 首包 8.5 s 完整57%流式输出用户感知到首字后处理与渲染60 ms5%公式排版最耗时真正让用户难受的不是总时长而是首字时间。流式输出把这个体验问题掩盖了大半但用户点完拍照、盯着转圈的那 1 到 1.5 秒是实打实的流失点。公考用户的使用习惯很特殊他们往往是一次性连拍五六道题然后逐题看解析。这意味着请求是突发的、成簇的云端每秒并发在几秒内能涨到平时的四五倍。端侧架构在这里的价值就出来了图片预处理、OCR 结果清洗、题干关键词抽取、意图判定这几步在本地做完只需要把一段几百字节的结构化文本发上去首包时间能压到 400 ms 以内用户的感知就是“点完就有反应”。这是我理解的这套架构最核心的动机跟“离线可用”关系不大。1.2 使用场景的物理约束地铁、自习室和熄灯后的宿舍宣传里说的“弱网可用”听着像噱头但把用户场景摊开看会发现它确实是个真需求。公考备考人群的使用时段高度集中在通勤、午休和睡前通勤场景在地铁里信号断断续续这不是极端情况是日常。我在复现环境里做过一个粗糙的网络质量采样早晚高峰的地铁线路移动网络可用率大约在 70% 到 85% 之间波动切换基站时会有一到三秒的完全断流。对于一个把“拍照搜题”做成核心功能的 App 来说这三秒的失败率会直接反映在次日留存上。更关键的是流量成本感知。一道题的图片如果原图上传2MB 起步一天刷 50 道题就是 100MB。虽然现在套餐普遍不小但用户心里那本账是会算的。端侧做 OCR 之后上传的只是文本一次请求几 KB这个差距在用户侧的体感是明显的。还有一个容易被忽略的点宿舍熄灯后的场景。这个时段很多学校的无线网络会限速或者不稳定而它恰好是备考人群刷题最集中的时间。本地智能体在这类环境下的价值不是“更快”而是“不断”。1.3 数据不出端的现实考量错题本比聊天记录更敏感这一条在宣传材料里通常一笔带过但在技术评审会上它是实打实的加分项。公考 App 里最敏感的数据不是聊天记录而是错题本和学习行为轨迹——它几乎完整刻画了一个人的知识短板、复习节奏和目标岗位倾向。从工程角度讲做端侧处理能减少很多麻烦错题归因、薄弱点聚类、复习计划生成这几类任务全部可以在本地完成服务端只接收匿名的聚合统计。这对数据合规的压力是实质性的降低不是公关话术。当然这里有个必须说清楚的边界本地智能体能处理的是“判断”和“归类”处理不了“生成”。让一个 3B 级别的模型在手机上写一篇 800 字的申论范文体验会是灾难级的。这个边界后面会详细算账它也是端云协同策略的根本依据。2. 端侧智能体的实际骨架一条从输入到作答的完整链路2.1 输入层拍照识题、语音提问与文本粘贴的三条入口三条入口的处理逻辑完全不同共用一套模型是行不通的。拍照识题走的是视觉链路图像矫正 → 版面分析区分题干、选项、图形→ 文字识别 → 公式与符号还原。这里最麻烦的不是通用文字而是数学符号和几何图形。一道数量关系题里出现分式、根号、上下标OCR 出来经常是乱的模型拿到的题干本身就是错的后面再怎么推理都是白费。我的做法是给 OCR 结果加一个置信度回显机制识别完成后先把题干文本渲染出来给用户看一眼识别置信度低于阈值的字符用浅色底纹标出来用户点一下就能改。这个设计看起来原始但实测下来比任何后处理纠错都有效——用户改一个字的成本远低于模型答错后重新输入的怨气。语音入口走的是另一条路。端侧做语音转文字在小模型上已经能用了但公考场景有个坑用户说话时会夹带大量口语和指代比如“这道题为啥选 C 啊B 看着也对”。这类输入直接丢给模型它会去解释为什么选 C而用户其实想问的是 B 错在哪。所以语音链路后面必须挂一层指代消解把“这道题”绑定到当前上下文的题号上把“B 看着也对”转成明确的对比请求。文本粘贴入口最简单但也最容易出事用户从别处粘贴的题干经常带一堆格式垃圾甚至带着上一道题的解析。输入端要做一次清洗把“答案”“解析”这类标记之后的内容截断否则模型会把答案当成题干的一部分直接抄出来。2.2 意图路由先判断这是“查题”还是“讲解”这是整个端侧智能体里最容易被低估的模块。用户输入一句话可能是在问题目答案、可能是在问知识点、可能是在问复习规划、也可能只是随手打了一句吐槽。如果所有请求都走同一条链路模型的表现会非常不稳定。我在复现环境里用的是一个三层判定全部跑在本地小模型上关键词硬规则层命中“答案”“选什么”“对不对”这类词直接判定为查题命中“怎么复习”“还剩多少天”判定为规划类。这一层覆盖大约 40% 的请求耗时接近零。小模型分类层用一个 0.5B 级别的分类头处理边界情况输出四类之一查题、讲解、规划、闲聊。这一层耗时在 80 到 150 ms。置信度兜底分类置信度低于 0.6 时不猜直接把三种可能的意图作为按钮抛给用户选。实测这一步虽然多了一次点击但把整体满意度拉回来了因为用户最烦的是“它答的不是我问的”。路由判定出来之后走的链路就完全不一样了。查题走“检索 短答案”讲解走“知识点图谱 云端生成”规划走“本地规则引擎 模板”闲聊直接本地小模型应付两句。这个分流的设计意图很明确把确定性强、输出短的任务留在端上把需要长文本生成的任务推上云。2.3 推理层量化模型的选型与内存预算实测这里是硬核部分也是最多人问的。选多大的模型不是看榜单是看你手上那台设备还剩多少内存。先算权重。4bit 量化下模型权重的内存占用大约是参数量的 0.55 到 0.6 倍。一个 3B 模型大概是 1.7GB一个 7B 模型大概是 4GB一个 1.5B 模型大概 0.9GB。再算 KV Cache这部分经常被漏掉。每个 token 的 KV 占用按这个公式算per_token_bytes 2 × num_layers × num_kv_heads × head_dim × bytes_per_element以一个 24 层、8 个 KV 头、head_dim 为 128、半精度存储的 3B 模型为例2 × 24 × 8 × 128 × 2 98,304 字节 ≈ 96 KB/token2048 的上下文窗口就是 96KB × 2048 ≈ 196MB。如果把上下文拉到 4096就是近 400MB这部分是很多人在真机上第一次跑就闪退的原因。加上 tokenizer、运行时开销、图像编码器如果走多模态、以及框架自己的内存池实际峰值要再往上留 300 到 500MB 的余量。所以一台标称 8GB 内存的手机系统和其他应用吃掉一部分后留给单个 App 的可用内存通常在 2.5 到 3.5GB 之间。结论很清楚3B 是这个档位的上限7B 在这个价位段跑不动。我在复现环境里用的配置大致是这样{ model_path: ./models/base-3b-instruct-q4.gguf, n_ctx: 2048, n_batch: 256, n_threads: 4, n_gpu_layers: 99, use_mmap: true, flash_attn: true, repeat_penalty: 1.1, temperature: 0.3, top_p: 0.85 }几个参数的选择理由值得说一下。n_ctx定在 2048 是权衡的结果再大内存扛不住再小检索回来的题干加解析就不够塞。temperature压到 0.3是因为公考场景要的是确定性同一个问题两次回答不一致用户会直接失去信任。use_mmap打开能让权重按需加载冷启动快不少但要注意它和后台内存回收的关系处理不好会被系统判定为内存大户然后被杀掉。还需要说明一个现实n_gpu_layers设满不代表一定能全量卸载到加速单元不同芯片平台的算子覆盖度不一样有些层会静默回退到 CPU速度直接腰斩。这个要逐平台实测不能看配置文件。2.4 输出层结构化解析的约束解码端侧模型最大的毛病不是笨是“话多”。让它解释一道题它可能先复述题干再分析选项最后才给答案一篇下来四百字用户在等一个选项字母。解决办法是约束解码加模板化输出。在 prompt 里明确给出输出结构并且在后处理层做严格校验不符合结构的直接重试或者降级。我用的输出契约是这样的{ answer: C, reason_short: 不超过60字的核心理由, steps: [步骤1, 步骤2], confidence: 0.0 }这个契约有几个好处短答案可以在 2 秒内出来用户立刻有反馈步骤列表可以展开再看confidence字段让客户端能做降级决策置信度低于 0.5 的时候不直接抛答案而是提示“这题我不太确定要不要看详细解析”把请求转到云端。实测下来加了输出契约之后端侧平均生成长度从 380 字压到 90 字以内出字时间从 25 秒压到 6 秒出头。这个差距不是模型变快了是废话变少了。这也是我一直强调的观点端侧体验优化的主战场在输出形态不在模型能力。3. 垂直大模型的训练账题库不是语料语料不是数据3.1 领域语料清洗题干、选项、解析三种文本的不同处理很多人以为“垂直大模型”就是把题库喂进去微调这个理解偏差会浪费掉几个月时间。题库里的三类文本处理方式完全不同。题干的问题在于信息不完整。大量题目依赖图表、公式、上下文单独抽出来一段文本是有歧义的。清洗的时候要给每道题补上元信息科目、题型、难度、知识点标签、是否含图。含图的题在训练时要特殊标记不然模型会学着在缺图的情况下强行推理养成瞎猜的坏毛病。选项的问题在于格式污染。选项里混着“A.”“A、”“A ”“A”各种写法还有的题是“以上都对”这种不可解析的选项。清洗要做的是统一格式并且把“以上都对”“以上都不对”这类特殊选项单独打标训练时让模型学会识别。解析的问题最大。题库解析的质量参差不齐有的是标准答案附带的官方解析有的是用户上传的里面充满“显然”“易知”“略”这种跳步表述。直接拿去训练模型会学到跳步生成出来的解析用户根本看不懂。我的做法是做一轮跳步检测解析里出现“显然”“易知”且前后文长度差超过阈值的标记为低质量训练时降权或者直接剔除。还有一个必须提的去重。题库里有大量变形题题干改两个数字就是新题。用简单的文本相似度去重会漏掉很多我用的是“题干骨架 数值分离”的方式把数字和单位抽出来单独比对效果好很多。3.2 微调策略全参、LoRA 与“只调输出格式”的取舍这里我要说一个不太符合主流叙事的观点在公考这个场景里微调模型学知识性价比极低。原因是知识更新太快。每年的考试大纲、题型分布、热点材料都在变你把 2025 年的知识微调进模型权重里2026 年就得重来一遍。而且模型对知识的记忆是不可控的它可能记住了某道题的答案但换个问法就答错这种“假学会”比不会更危险。我的实际方案是分层处理目标手段理由输出格式与语气LoRA 微调小数据量这部分稳定不需要频繁更新领域知识检索增强知识库存外部更新成本低可溯源解题推理能力基础模型自带 少样本示例微调很难真正提升推理反而容易过拟合术语与缩写理解词表扩充 少量微调公考有大量固定表述不处理会分词错乱LoRA 的配置上我一般在注意力层的 q、k、v、o 上加秩取 8 到 16alpha 取秩的两倍。数据量控制在几千条量级主要教模型“用什么样的口吻和结构回答”不教它“知道什么”。训练轮数严格控制在 3 轮以内多了就开始背题验证集上的格式合规率反而下降。这里有个经验验证集一定要包含“模型没见过的新题型”。如果验证集全是从训练集同分布里抽的指标会好得离谱但上线就崩。我吃过这个亏第一版模型在验证集上格式合规率 96%上线后用户投诉“答非所问”的比例超过 15%原因就是验证集没有覆盖新题型和口语化提问。3.3 评测集构建从困惑度到“人能不能直接用”困惑度这个指标在垂直场景里基本没有参考价值。一个困惑度很低的模型可能只是把题库背下来了遇到新题照样胡说。我用的评测集分三个层次第一层是格式合规率。把模型输出丢给一个解析器能不能解析成约定的 JSON 结构字段是否齐全answer是否在 A 到 E 的合法取值内。这一层是硬门槛低于 95% 就不配上生产。第二层是检索命中率。给一批真实用户提问看检索模块能不能召回正确的题目或知识点。这一层测的是 RAG 链路不是模型本身。命中率低于 80% 的话后面模型再强也没用因为它拿到的是错的材料。第三层是人评可用性。这一层最贵也最重要。我组织了小规模的盲评让有备考经验的人看模型输出打三个标签可直接用、需要修改、完全没用。这个指标和困惑度的相关性接近于零和“解析是否分步”“是否指认依据”的相关性却很高。实测下来一个 3B 模型配上好的检索在“可直接用”这个标签上的表现能追平甚至超过一个 14B 模型裸跑。这个结论直接决定了架构选择把钱花在检索和数据结构上比花在模型参数上划算得多。4. 检索增强在公考题库里的落地细节4.1 题库结构化把一道题拆成可检索的六个字段向量检索效果差八成是因为切分方式不对。把一整道题题干 五个选项 解析当成一个块去嵌入向量会被稀释得面目全非语义信息全糊在一起。我的做法是拆成六个字段分别建索引字段内容用途题干主干去掉数字和单位的题干骨架相似题召回完整题干原始题干精确匹配知识点标签人工或半自动标注知识点检索题型数量关系、逻辑判断等过滤条件解析要点解析的前两句讲解类请求易错提示用户高频错因个性化推荐这个拆分的关键在于题干主干。一道题改成数字就是新题但骨架是一样的。用骨架做嵌入召回相似题型的效果比用完整题干好一大截。我实测过同一批查询下骨架召回的相关题数量是完整题干召回的 2.3 倍。粒度上也有讲究。太细一句话一个块会丢上下文模型拿到半截题干根本没法解太粗整章一个块会引入大量噪声。一道题一个块解析单独成块是我试下来最平衡的方案。4.2 混合检索向量召回为什么单独用不够纯向量检索在公考题库上有个致命伤它对数字和符号不敏感。用户问“甲乙两人合作 12 天完成甲单独做 20 天乙单独做几天”向量检索很可能召回一堆“工程问题”的题但就是召不回那道数字完全匹配的题。因为嵌入模型把数字当成了噪声。所以必须做混合检索。我的组合是三路向量召回负责语义相近的题取 top 20。关键词召回用 BM25 或者简单的倒排负责数字、专有名词、公式符号的精确匹配取 top 20。标签过滤根据路由层判定的题型和科目做硬过滤把不相关的科目直接排除。三路结果用 RRF倒数排名融合合并公式很简单score(d) Σ 1 / (k rank_i(d))k一般取 60。这个方法的好处是不需要调权重各路结果自然融合比手工加权稳定得多。融合之后取 top 5 送进 prompt。这里有个坑送太多反而变差。我试过 top 10模型的答案准确率反而下降了因为它会在多个相似题之间摇摆把 A 题的解析套到 B 题上。top 3 到 top 5 是比较稳的区间。4.3 引用与防幻觉让模型必须指认依据公考场景对幻觉的容忍度极低。用户问一道题选什么模型答“选 C因为根据相关规定”这种回答比不答更糟糕。我的处理是强制引用。在 prompt 里明确规定所有结论必须指向给定的材料编号材料里没有的内容不许编。输出结构里加一个citation字段值必须是材料编号或者null。后处理层做校验citation为null且answer不为空的直接判定为不合规降级处理。光靠 prompt 约束还不够模型有时候会硬编一个编号。所以还要做引用一致性校验把模型引用的那句话拿出来和原始材料做字符串相似度比对相似度低于阈值的判定为伪造引用。这套机制上线后我统计到的“无依据作答”比例从 8% 左右降到了 1% 以内。剩下那 1% 主要集中在图形题和跨材料综合题上这两类本来就是难点我的做法是直接不生成转人工或者提示用户查看详细解析。还有一个细节不知道就说不知道。这个在 prompt 里要非常明确地写而且要给它一个合法的输出形态比如answer填unknown。如果不给合法出口模型就会硬猜。5. 端云协同的路由与降级不是所有请求都值得上云5.1 分流规则表与判定阈值端云协同的核心不是“能不能”是“值不值”。同样一道题本地跑 8 秒出 90 字云端跑 2 秒出 400 字选哪个取决于用户当下在干什么。我的分流规则大致是这样一张表请求类型首选判定条件理由短答案查询本地输出预期 100 字延迟敏感答案确定性高详细解析云端输出预期 200 字端侧生成太慢体验差意图分类本地全部耗时极短无隐私风险题干清洗本地全部只做文本处理不需要大模型学习规划本地规则引擎可覆盖逻辑确定不需要生成申论批改云端全部长文本生成端侧不可能离线兜底本地网络不可用有总比没有强判定逻辑用代码表达大概是这个意思def route(req): if not network_available(): return local_fallback if req.intent in (classify, clean, plan): return local if req.expected_output_tokens 100: return local if req.device_tier low and req.priority ! high: return cloud if req.intent essay_review: return cloud return cloud if req.latency_budget 3000 else local几个阈值的来历值得说一下。expected_output_tokens 100这条线是实测出来的拐点低于 100 token 时端侧的总耗时含模型加载后的首次推理和云端的往返时间打平超过 100 token端侧就明显落后。latency_budget 3000是用户耐心线超过三秒的等待必须有明确的进度反馈否则流失率陡增。还有一条没写进表里的规则连续请求的合并。用户连拍五道题本地先全部做完 OCR 和意图分类然后打包成一个批量请求发上去比发五次省了四次握手。这个优化在弱网下效果特别明显。5.2 本地失败后的三级兜底端侧推理失败的概率比很多人想象的高。内存不足被杀、模型文件损坏、算子不支持导致崩溃、系统温控降频导致超时这些都是日常。我设计了三级兜底第一级是重试。失败后立刻用一个更小的配置重试一次把n_ctx从 2048 降到 1024把生成长度砍半。这一级能救回大部分超时和内存不足的情况。第二级是降级。重试还失败就切换到规则引擎。查题降级成“关键词匹配 题库直出答案”讲解降级成“知识点卡片 模板化描述”。体验会明显变差但不至于白屏。第三级是上云。前两级都不行或者用户主动点了“获取详细解析”就直接走云端。这一级的关键是要有明确的加载状态不能静默等待。这里有个血泪教训降级路径必须定期演练。我第一版上线后本地模型因为一次模型文件更新失败全线崩溃结果发现降级路径里有个字段名拼错了整个功能直接白屏了三天才发现。后来我把降级路径做成了可以强制触发的开关每次发版前手动跑一遍。5.3 版本更新与模型热替换的工程细节模型更新看着简单实际坑很多。一个 3B 的 4bit 模型文件 1.7GB 左右用户不可能每次发版都重新下。我的方案是增量分发 双槽位热替换。本地保留两个模型槽位新模型下载到备用槽位校验通过后原子切换旧模型延迟删除。这样更新期间用户是可以继续用的不会出现“更新中请稍候”的空白期也不会因为下载中断导致模型彻底不可用。下载本身要注意几件事必须支持断点续传必须做分片校验必须在 Wi-Fi 环境下才自动下载。移动网络下静默下载 1.7GB用户看到流量账单会直接卸载。还有个容易忽略的模型文件要和 App 版本绑定。prompt 模板改了但模型没更新或者模型更新了但后处理逻辑还是旧的都会出诡异的问题。我在配置文件里加了一个版本三元组三个版本号必须匹配才允许启用不匹配就回退到上一套完整配置。6. 实测数据与踩坑排查实录6.1 三个平台上的延迟、内存、耗电实测以下数据来自我的复现环境不是任何厂商的标称值不同实现方式差异会很大仅供参考。测试条件是 3B 模型 4bit 量化、2048 上下文、输出 90 字左右的结构化结果。设备档位可用内存首 token完整输出内存峰值连续 10 分钟耗电旗舰平台6 GB380 ms4.2 s2.6 GB6%中端平台3.5 GB720 ms7.8 s2.4 GB9%老机型2.2 GB1.4 s14 s2.3 GB13%且有降频老机型那一栏的“降频”是重点。连续推理五分钟后机身明显发热系统触发温控解码速度从 12 token/s 掉到 6 token/s完整输出时间直接翻倍。这个现象在中端机上也有只是触发得晚一些。所以我的建议是给不同档位设不同的输出上限。旗舰机可以放开到 150 字中端机压到 100 字老机型压到 60 字并且只做答案不做解析。一刀切的配置在低端机上一定是灾难。6.2 一次“答非所问”的完整排查链路这个故障值得完整讲一遍因为它暴露了链路上几乎每一个环节的问题。现象用户反馈问一道数量关系题App 给出的解析是针对一道逻辑判断题的答案还完全对得上那道逻辑题。第一步看日志。端侧日志显示意图分类是“查题”置信度 0.91没问题。检索返回了 5 条结果第一条的相似度得分 0.83看着也正常。第二步回看检索命中的内容。问题出现了命中的那条记录题干和用户问的题完全不是一回事。但相似度为什么这么高把两条题干并排一看就明白了——OCR 把“问”识别成了“间”用户问的是“甲乙合作完成一项工程问乙单独需要多少天”OCR 出来是“间乙单独需要多少天”。这个错字导致题干骨架匹配到了另一道含“间”字的题。第三步看为什么没被发现。OCR 的置信度其实不高0.62但当时的逻辑是“置信度低于 0.4 才提示用户确认”0.62 被放行了。这是个阈值设置问题。第四步看为什么模型照着错题答。因为 RAG 把错题当成材料喂进去了prompt 里写着“根据以下材料作答”模型非常听话地照做了。这说明模型的指令遵循是好的问题在数据侧。修复方案有四条把 OCR 确认阈值从 0.4 提到 0.65检索得分加一个绝对阈值低于 0.75 的不进 prompt在 prompt 里加一句“如果材料与问题不匹配请直接说明不匹配”前端加一个题干回显让用户能一眼看出识别错了。这四条上线后同类问题的反馈量下降了九成以上。这个案例我一直拿来当教材因为它说明了一件事端侧 AI 应用的故障八成不在模型在数据和链路。6.3 几个容易忽略的工程细节最后分享几个踩过之后才记住的细节都是那种文档里不会写、但会实实在在咬你一口的东西。第一冷启动的第一个请求特别慢。模型文件通过内存映射加载第一次推理要把权重从存储读进内存这个时间在低速存储上可能长达三四秒。解决办法是在 App 启动后空闲时做一次预热推理用一句“你好”把模型热起来用户真正提问时就不冷了。第二后台被回收是常态不是异常。系统内存紧张时后台的 App 会被杀掉模型要重新加载。所以状态管理必须做持久化用户切回来的时候不能从头开始。我的做法是把会话状态和模型状态分开存模型重新加载但会话继续。第三多线程数不是越多越好。n_threads设成核心数看起来合理实测反而不如设成大核数量。因为小核参与计算会拖慢整体同步尤其是解码这种逐 token 的串行任务。中端机上我一般设 3 到 4。第四温度参数在端侧要更保守。云端可以设 0.7 让输出更自然端侧设 0.7 会让同一个问题两次答案不一样用户会截图对比然后来投诉。0.2 到 0.3 是安全区。第五日志要脱敏但要有用。端侧日志不能记录完整题干隐私但排查问题又需要。我的做法是记录题干哈希和长度加上 OCR 置信度、检索得分、路由结果这几个关键指标。这些信息足够定位大部分问题又不涉及内容本身。这套架构我前后调了大半年最大的体会是本地智能体和垂直大模型不是两个并列的技术选型而是一条流水线上的两段工序。端侧负责“快”和“守”云端负责“深”和“广”中间那条路由线画在哪里取决于你的用户在什么场景下、愿意等多久、以及你对答错一件事的容忍度有多高。公考这个场景的特殊性在于用户对“答错”的容忍度极低所以所有的优化最终都要给准确性让路——宁可说不知道也别编一个看起来很像的答案。
