企业官网建设流程全解析

做教育类工具这几年，我最怕听到的一句话是“这个功能云端调个接口不就行了”。公考这种场景偏偏不吃这一套：用户在通勤地铁里刷题、在自习室断网环境下做套卷、在考前一周连续几小时高频问答，网络抖动一次、接口超时两秒，体验就崩了。所以当我第一次看到智蛙公考把“本地智能体”和“垂直大模型”并列写进架构说明时，我的第一反应不是营销话术，而是——这套东西如果真落地了，工程上要啃的骨头不少。这篇就按一个做过端侧推理、也调过题库检索系统的从业者视角，把这类公考软件的技术架构从头到尾拆一遍：它到底由哪几层组成、每一层为什么这么选、参数怎么算、哪里容易翻车、实测数据大概落在什么区间。不管你是刚接触端侧模型的新手，还是已经在做垂直领域微调的老手，都能从里面找到能直接抄走的部分。需要先说明的是，下面的模块划分、参数取值和评测数据，是基于同类产品的常见工程实践做的合理还原与推演，不是对某个具体产品的逆向工程，重点在于把“为什么这么设计”讲透。

1. 为什么公考类软件开始往“本地智能体+垂直大模型”这条路上挤

1.1 传统题库App的天花板到底卡在哪

早期题库类产品的技术栈其实非常朴素：题目存在关系型数据库里，做卷子就是按标签抽题，解析是人工写好的静态文本，错题本就是把答错的题号记下来再推一遍。这套架构在题库量五万道以内、用户规模十万级的时候跑得飞快，成本也低。但它有三个绕不过去的坎。

第一个坎是“解析不够用”。一道数量关系题，标准解析往往只给一种解法，用户卡住的地方恰恰是那一步跳跃。用户想问“为什么这里要设未知数而不是直接列方程”，静态解析回答不了，因为它压根不知道用户在问什么。

第二个坎是“追问成本高”。只要产品想做AI答疑，就得把题干、选项、用户问题一起打包发给云端大模型，一次请求动辄两三千 token。日活十万、人均问五次，光推理成本就够呛，更别提并发高峰期限流。

第三个坎是“离线即残废”。公考用户的使用场景高度集中在通勤、自习、考前冲刺，这些场景的网络质量都不稳定。一个在高铁上做套卷的人，遇到不会的题点开答疑转圈十秒，基本就放弃这个功能了。

这三个坎叠在一起，逼着产品方必须重新想架构：要么把成本压下来，要么把能力搬到端上，要么两者都做。本地智能体加垂直大模型，本质上是同时回应了成本、延迟、离线三个诉求。

1.2 本地智能体真正解决的三个痛点

很多人把“本地智能体”理解成“把大模型塞进手机”，这个理解太窄了。智能体（Agent）的核心不是模型本身，而是“模型+工具+状态机”的组合：模型负责判断意图，工具负责干具体的事，状态机负责记住上下文和进度。在公考场景里，这个组合能解决三件云端方案很难做好的事。

第一件是题目上下文的即时绑定。用户在错题本里点开一道题，本地智能体可以直接拿到这道题的题干、选项、正确答案、历史作答记录、同类题掌握度，全部是本地数据结构，不需要序列化上传，也不会因为网络问题丢字段。模型拿到的是结构化上下文，而不是一坨拼接的字符串，输出稳定性会好很多。

第二件是多轮追问的低延迟。端侧模型的推理延迟和网络无关，首 token 延迟可以压到几百毫秒量级。用户问“那如果题目里的条件改成……”这种追问，本地模型能立刻接住，体验接近真人助教。云端方案即使做了流式输出，网络 RTT 加上排队，也很难稳定在这个水平。

第三件是隐私与合规上的从容。做题记录、错题分布、模考成绩，这些数据对用户来说敏感度不低。本地处理意味着原始数据不出设备，只有脱敏后的统计特征需要上报，这在产品合规叙事上是实打实的优势。

注意：本地智能体不等于“所有事都在端上做”。真实工程里，端侧负责意图识别、上下文组装、简单问答和工具调度，重推理任务还是要走云端。把边界划清楚，比一味追求全本地更重要。

1.3 通用大模型和垂直大模型的分工边界

这里有一个常见的误区：觉得垂直大模型就是“拿通用模型在公考题上微调一下”。实际上两者的能力分布差别很大，用错了地方会两头不讨好。

通用大模型强在开放域理解和表达流畅度，弱在领域事实准确性。你问它一道具体的行测题，它能给你写出一段看起来很专业的解析，但里面的数字可能算错，选项可能对不上，甚至引用的“考点”根本不存在。这种错误在开放域聊天里无伤大雅，在备考场景里是致命的——用户会照着错的解析去记。

垂直大模型强在领域分布内的一致性和格式稳定性，弱在泛化。它在见过题型上的表现可以非常稳，但遇到超纲问法就容易僵住。

所以合理的分工是：端侧小模型做路由和轻问答，云端垂直模型做深度解析和主观题批改，通用大模型只在兜底场景使用。路由判断本身也是一个分类任务，用 1.5B 到 3B 的小模型微调一个意图分类头就够，没必要上大模型。

我在实际项目里试过一个很土但有效的判断方法：把用户问题按“是否需要精确计算”“是否需要引用题库事实”“是否是开放性咨询”三个维度打标，前两类交给垂直模型，第三类才考虑通用模型。这个规则简单到可以用 if-else 写，但它把 80% 的请求挡在了正确的链路上。

2. 智蛙公考的四层架构：从端侧推理到服务端编排

2.1 端侧智能体层：把“能离线跑”当成硬指标

端侧这一层是整个架构里最难啃的部分，因为手机不是服务器，内存、算力、发热、电量四个约束同时压着你。智蛙公考这一层的设计思路是分级降配，不是一套模型打天下。

具体分成三档：旗舰机型（12GB 以上内存、有独立 NPU）跑 3B 到 7B 的 4bit 量化模型，承担完整的答疑和追问；中端机型（8GB 内存）跑 1.5B 到 2B 模型，只做意图分类和模板化回答；低端机型直接退化成规则引擎加云端兜底。这个分档不是拍脑袋，而是根据内存占用算出来的。

端侧运行时选型上，Android 侧常见的是 llama.cpp 的移动端移植、MLC-LLM 或者厂商自研的推理框架，iOS 侧走 Core ML 加 Metal。选 llama.cpp 系的理由是量化格式成熟、社区算子覆盖全、调试工具链顺手；选 MLC-LLM 的理由是编译期优化做得好，特定模型上吞吐更高。这两个没有绝对优劣，看团队更熟悉哪套工具链。

智能体框架本身反而不复杂，核心是一个状态机加一组工具函数。工具函数包括：查题、查解析、查同类题、算分、记错题、生成练习计划。模型输出的是工具调用意图和参数，真正的数据操作由原生代码完成。这样做的好处是模型再胡说，也不会把数据库写坏——所有写操作都有参数校验兜底。

2.2 检索增强层：题库不是塞进模型，而是挂在外面

我见过不少团队一开始想的是“把题库喂进模型做微调”，这条路在小规模上可行，上了百万题就彻底走不通：训练成本高、更新一次要重训、题目一改模型就记错。正确做法是检索增强，题库放在外面，模型只负责理解和组织语言。

智蛙公考的检索层大致是这样一条链路：题目先做结构化，拆成题干、选项、答案、考点标签、难度、题型、解析正文七个字段；题干和解析分别做向量化，用中文小参数嵌入模型（512 维就够，没必要上大维度）；索引走 HNSW 图索引，百万级题库单机内存占用可以控制在几个 GB；检索时先做向量召回 top-50，再用交叉编码器重排取 top-5，最后把这几条作为上下文喂给模型。

这里有个细节值得说：召回阶段和重排阶段用的不是同一个模型。召回要快，用双塔结构的嵌入模型，题目向量可以离线算好；重排要准，用交叉编码器，把 query 和文档拼在一起过一遍，精度高但慢，所以只对 top-50 做。这个两段式设计是检索系统的标准做法，能同时兼顾延迟和准确率。

还有一个容易被忽略的点：检索的 query 不是用户原话。用户问“这题为啥选C”，直接拿这句话去检索，召回质量会很差。正确做法是先用端侧小模型把问题改写成“题干关键信息 + 考点 + 疑问类型”的结构化 query，再去检索。这一步改写带来的召回提升，实测比换更大的嵌入模型还明显。

2.3 垂直模型层：小参数加领域数据比大参数更划算

垂直模型这一层的核心决策是“多大参数合适”。我的经验是：在领域分布高度收敛的任务上，7B 到 14B 的垂直模型可以打得过 70B 的通用模型，前提是数据质量和训练方式到位。

公考领域的任务特点很鲜明：输入是结构化的题干加选项，输出是固定格式的解析（考点定位、解题步骤、选项辨析、易错提醒），语言风格要求严谨、不废话。这种任务用指令微调加少量偏好对齐就能做得很好，不需要模型有很强的开放域知识。

训练数据的构造成本才是大头。一道题的高质量解析，需要拆成“考点是什么、为什么这么考、每一步怎么推、错误选项错在哪”四个部分，人工标注一道题的成本在十几分钟量级。所以真正可行的路径是：先用强模型批量生成初稿，人工只做审核和修正，把单题成本压到两三分钟。审核环节不能省，因为生成初稿里的计算错误率不低，尤其是数量关系和资料分析。

微调方式上，全参数微调在小团队里不现实，LoRA 或者 QLoRA 是更实际的选择。秩取 16 到 32，学习率在 1e-4 到 2e-4 之间，训练轮数控制在 3 轮以内，多了就过拟合。这些参数不是玄学，背后逻辑是：领域微调要的是“格式对齐”和“术语对齐”，不是让模型重新学知识，所以低秩扰动足够，训太多轮反而会把通用能力洗掉。

2.4 编排与评测层：路由、缓存、降级三件套

最上面这一层是服务端编排，看起来最不起眼，实际上决定了整套系统的稳定性和成本。

路由负责判断一个请求该走端侧、走垂直模型还是走通用模型。判断依据包括：问题类型、端侧模型置信度、用户设备档位、当前服务端负载。置信度低于阈值的请求自动上抛，这个阈值需要在评测集上调，太低会导致端侧乱答，太高会让云端压力暴增。

缓存是省钱的关键。公考题目有很强的重复性，同一道题每天被问几百次很正常。语义缓存的做法是把 query 向量化后做近邻查找，命中相似度阈值就直接返回缓存答案。命中率做到 30% 到 40% 是常见水平，对成本的影响很直接。

降级是保命的。云端模型超时、限流、返回格式错误，都必须有兜底路径：降级到端侧模型、降级到静态解析、降级到提示用户稍后重试。降级策略要提前设计好触发条件和恢复条件，不能在故障发生时才临时想。

3. 关键模块的实现细节与参数取舍

3.1 本地模型的选型与显存/内存核算

选端侧模型，第一件事是把内存账算清楚，不然后面全是白费功夫。

模型权重的内存占用可以用一个很简单的公式估算：参数量 × 每参数字节数。4bit 量化下每参数约 0.55 字节（含量化元数据开销），所以 7B 模型大约 3.9GB，3B 模型约 1.7GB，1.5B 模型约 0.85GB。这只是权重。

真正吃内存的是 KV Cache，公式是：2 × 层数 × KV 头数 × 头维度 × 序列长度 × 批大小 × 每元素字节数。以 7B 模型（32 层、32 个 KV 头、头维度 128）为例，序列长度 2048、批大小 1、FP16 存储，KV Cache 约 2 × 32 × 32 × 128 × 2048 × 1 × 2 字节 ≈ 1.07GB。如果开 4bit 量化 KV Cache，可以压到 0.27GB 左右，但精度会有轻微损失。

把权重和 KV Cache 加起来，再留 1.5GB 给运行时和系统，7B 4bit 的实际内存需求在 6.5GB 到 7GB。这意味着 8GB 内存的手机跑起来会非常勉强，系统随时可能杀进程。所以智蛙公考在 8GB 档位只上 1.5B 到 2B 模型，是算过账的，不是保守。

提示：别用“实验室里能跑起来”当验收标准。真机验收要看连续使用 20 分钟后的内存峰值和机身温度，很多模型跑单轮没问题，连续跑十轮就因为内存碎片或热降频崩了。

3.2 题目结构化：从图片到可检索字段

公考的题目来源很杂：有扫描的真题册、有用户拍照上传的错题、有机构自己整理的电子版。要把这些东西变成可检索的结构化数据，得先过一道 OCR 加版面分析的流水线。

版面分析要解决的是“哪里是题干、哪里是选项、哪里是图形、哪里是解析”。图形题的识别是难点，尤其是资料分析的图表和数量关系的几何图。常见做法是把图形区域裁出来单独存，在文本里放占位符，检索时只用文本部分，展示时再把图拼回去。这样既保证了文本检索的准确性，也不会因为图形识别失败拖垮整条链路。

公式识别是另一个坑。行测里的数量关系题经常带分式、根号、上下标，直接 OCR 出来会变成一堆乱码。可行的方案是接一个公式识别模块，把公式转成 LaTeX 再拼回题干。这一步不做，检索召回会明显掉，因为公式部分全是噪声。

结构化之后的字段设计要服务于检索和生成两个用途。给检索用的字段是题干、考点标签、题型、难度；给生成用的字段是完整题干、选项、正确答案、解析、易错点。两套字段分开存，避免互相干扰。

3.3 主观题批改链路：分档打分而不是给一个总分

申论和综合写作的批改是公考软件里技术含量最高的模块之一。直接让模型给一个总分，结果基本没法用——同一篇文章两次运行给的分数能差十分，用户会觉得你在瞎猜。

可行的做法是拆维度、给证据、再合成。维度按评分标准拆成立意、结构、论证、语言四个，每个维度让模型输出 0 到 5 的档位、打分理由、以及原文中的证据句。最后按权重合成总分。这样做的好处是分数有据可查，用户看到的是“你的论证维度只有 2 档，因为第二段和第三段举例重复了”，而不是一个孤零零的数字。

证据句的抽取是让这套方案可信的关键。做法是在 prompt 里明确要求模型引用原文片段，然后做一次字符串匹配校验，匹配不上的证据句直接丢弃。这个校验步骤很土，但能挡掉大量模型编造的引用。

批改结果的一致性需要用人工评分来校准。常见做法是找两位老师独立打分，取平均作为参考，然后算模型分和人工分的二次加权 kappa 系数。这个系数做到 0.6 以上，产品层面才敢说是“可用”。做到 0.75 以上需要大量的标注数据和多轮迭代，不是一两个月能搞定的事。

3.4 错题调度：间隔重复算法的工程化改造

错题本如果只是“错了就记下来、下次再推给你”，用户体验会很差——推的题要么太简单浪费时间，要么太难让人挫败。真正有效的是间隔重复调度。

经典算法是 SM-2，核心是一个难度因子 EF 的更新公式：EF' = EF + (0.1 - (5 - q) × (0.08 + (5 - q) × 0.02))，其中 q 是用户这次的作答质量评分（0 到 5），EF 初始值取 2.5，下限卡在 1.3。这个公式的直觉是：答得好，间隔拉长；答得差，间隔缩短，但缩短有下限，避免一天内反复轰炸。

工程化改造有几个点。一是把 q 从“用户主观评分”改成“客观作答结果自动推断”，答对且用时短给高分，答对但用时长给中分，答错给低分，这样不需要用户额外操作。二是把 EF 从单题扩展到考点维度，同一个考点下的题共享一个掌握度，避免“这题会了但那题不会”的割裂感。三是加一个上限，单题间隔不超过 60 天，否则用户考完试都刷不到第二遍。

4. 评测怎么设计才不糊弄自己

4.1 评测集怎么攒

很多团队的评测集是“随便找了 200 道题”，这种评测集只能验证功能通不通，验证不了能力好不好。合格的评测集要满足三个条件：覆盖全题型、难度分布接近真实考试、有明确的参考答案和评分标准。

客观题部分，我会按模块分层抽样：言语理解、数量关系、判断推理、资料分析、常识判断各按真实考试比例取题，总数控制在 2000 到 3000 道，其中至少 20% 是“易错题”和“高难度题”，专门用来压模型的下限。主观题部分，200 篇左右，每篇两位老师独立评分，分差超过两档的拿出来重新裁定。

还要单独建一个“对抗集”，专门收集模型容易翻车的样本：带干扰条件的数量关系题、选项表述高度相似的言语题、需要跨段落整合信息的资料分析题。这个集合不追求覆盖面，只追求“能暴露问题”。

4.2 指标怎么定

指标设计上，我一般分三组看。

准确率组：客观题答案准确率、解析中计算步骤的正确率、考点的标注准确率。第三个指标容易被忽略，但对学习产品很重要——考点标错了，后面的推荐和错题归类全跟着错。

稳定性组：同一道题跑五遍，答案一致的比例；引用题库内容时，引用内容真实存在的比例（这个指标反映幻觉程度）；输出格式符合约定的比例。

性能组：首 token 延迟的 P50 和 P95、每秒生成 token 数、内存峰值、连续运行 30 分钟的崩溃率。

这三组指标要一起看。只看准确率会做出一个慢得没法用的系统，只看性能会做出一个答得飞快但全是错的系统。

4.3 实测数据与横向对比

下面这组数据是基于同类方案的常见实测区间做的还原，不同硬件和不同模型版本会有浮动，看趋势比看绝对值更有意义。

这张表里最有意思的一行是最后一行：通用大模型的参数规模远大于垂直 14B，但准确率和幻觉率都不占优。原因不复杂——它不知道你的题库里有什么，也不知道你的评分标准长什么样，全靠上下文硬猜。这就是垂直模型存在的价值。

另一个观察是端侧 3B 和 7B 之间的断层。7B 的准确率比 3B 高 6 个百分点，但延迟翻了一倍多，内存翻了一倍。这个 trade-off 在实际产品里通常的解法是：默认用 3B，遇到高难度题或者用户主动点“深度解析”时再升到 7B。这种按需升级的策略，比一刀切上 7B 更划算。

5. 踩过的坑与排查速查表

5.1 典型故障与定位路径

端侧加云端的混合架构，故障面比纯云端宽得多，因为出问题的环节从“服务端一个”变成了“端侧、网络、服务端三个”。下面这张表是我在实际排查中整理出来的高频问题。

这张表里，我个人踩得最惨的是第二条。早期版本没做 KV Cache 的显式释放，单轮测试一切正常，用户连续追问四五轮之后直接卡死。后来在每轮结束的回调里加上清理逻辑，问题才消失。这类问题的麻烦之处在于它只在长会话下复现，短测试根本发现不了。

5.2 几条不上文档的调优经验

第一条，prompt 里别放大段规则，改成结构化字段。早期我写的 prompt 是“你必须先分析考点，再逐步推导，最后给出答案，注意不要……”这种自然语言规则，模型执行得时好时坏。后来改成类似 JSON 的字段约定：考点、步骤、答案、易错点，每项单独一行，输出稳定性明显提升。模型对格式的敏感度远高于对自然语言指令的敏感度。

第二条，温度参数按模块分开设。答疑场景可以给 0.3 到 0.5，让表达自然一点；批改场景必须压到 0.2 以下甚至 0，否则同一篇文章两次打分能差出一个档。很多团队一个全局温度打天下，结果就是某个模块总是飘。

第三条，评测集要定期“投毒”。每上线一个新版本，把线上收集到的badcase补充进评测集，三个月后这个集合会变得非常有杀伤力。我见过最有效的质量提升手段不是换模型，而是把评测集从 200 条养到 2000 条。

注意：不要用训练集里的样本做评测。这个错误听起来很低级，但实际项目里非常常见——尤其是数据量紧张的时候，同一个标注批次既拿去训练又拿去评测，跑出来的指标好看得离谱，上线就原形毕露。

6. 成本、部署与可持续演进

6.1 三档部署方案的成本账

部署方案的选择，本质是在“端侧投入”和“云端投入”之间找平衡点。下面三档是常见的选择。

纯云端方案：开发最快，端侧只做展示。缺点是推理成本随日活线性增长，日活十万、人均五次请求、每次两千 token，按常见定价算每月推理开销是一笔不小的数字，而且高并发时段必须限流。

端云混合方案：端侧承担 50% 到 70% 的简单请求，云端只处理复杂请求。开发成本高，需要维护两套模型和一套路由逻辑，但推理成本能砍掉一半以上，延迟体验也更好。这是目前主流产品普遍走的路。

全端侧方案：理论上成本最低，但实际上做不到。端侧模型的能力上限摆在那里，主观题批改、长文本分析这类任务在手机上跑不动。强行做只会把体验做烂。

我个人的判断是，混合方案里的关键指标是“端侧承接率”。这个数字做到 60% 左右，成本和体验的平衡点基本就找到了。做到 80% 以上通常意味着路由阈值设得太高，把该上云的请求也拦在了端侧，准确率会掉。

6.2 模型迭代的节奏控制

垂直模型的迭代最忌讳“想到什么改什么”。合理的节奏是：每月一次小版本数据补充，每季度一次完整重训，每次重训都要跑全量评测集并和上一版做逐项对比。

对比的时候要看“退化项”，不能只看总分。总分涨了两个点，但资料分析模块掉了五个点，这种版本上线就是灾难。我的做法是给每个模块设一个下限阈值，任何模块跌破阈值就不允许发布，哪怕总分再高。

还有一个工程上的经验：模型版本要和端侧包版本解耦。云端模型可以随时更新，端侧模型受应用商店审核和用户升级意愿限制，更新周期长得多。所以端侧模型的接口要做成可配置的，允许云端下发 prompt 模板和小样本示例，在不换模型的前提下做能力微调。这一招在紧急修复某些 badcase 时非常管用。

最后分享一个小技巧：把用户对解析的“有用/没用”反馈和具体的模型版本、prompt 版本绑定记录。积累两三个月之后，你会得到一张非常清晰的“哪个版本在哪个题型上表现差”的地图，比任何离线评测都真实。

这个领域接下来能扩展的方向其实不少，比如把错题调度和模考成绩预测结合起来做更细的节奏控制，或者把图形题的解析做成图文对齐的多模态输出。但这些都是后话，眼下更值得投入的还是把评测集养厚、把降级路径做扎实——这两件事看起来不性感，却决定了产品能不能在真实用户手里稳住。