
移动端微调 vs RAG: 为什么RAG仍然需要服务器
RAG是为AI提供领域知识的首选方案。但在移动端,RAG重新引入了你试图消除的服务器依赖。微调则将知识直接嵌入模型本身。
检索增强生成(RAG)是"如何让AI具备领域知识"这个问题的标准答案。检索相关文档,注入提示词,让模型基于上下文回答。这在有服务器基础设施的Web应用中运作良好。
在移动端,RAG存在一个结构性问题。检索步骤需要向量数据库。这个数据库要么在服务器上(重新引入服务器依赖),要么在设备上(消耗大量存储和内存)。对于移动端来说,两种方案都不够理想。
微调采用不同的方法。它不是在推理时查找知识,而是在训练期间将知识嵌入模型权重中。模型无需检索就能了解你的领域。
RAG的工作原理(以及为什么它需要基础设施)
标准的RAG流程:
- 索引阶段: 将文档分块,生成嵌入向量,存储在向量数据库中
- 查询阶段: 将用户的问题转换为嵌入,在向量数据库中搜索相似的块,检索前3-5个结果
- 生成阶段: 将检索到的块连同用户的问题一起注入提示词,发送给LLM
服务器依赖
第2步需要进行向量相似性搜索。在服务器端,这使用Pinecone、Weaviate或pgvector等数据库。这些是服务器端服务。
对于移动端,你有两个选择:
服务器端RAG: 用户的问题发送到你的服务器, 服务器执行检索并调用LLM API。这是最常见的架构,但意味着每次查询都需要网络往返。你又回到了云依赖,伴随着所有问题: 延迟、离线失败、隐私顾虑和持续的基础设施成本。
端侧RAG: 将向量数据库存储在手机本地。这消除了服务器但产生了新问题:
- 向量数据库根据语料库大小额外消耗100MB-1GB+的存储
- 查询的嵌入生成需要运行一个单独的模型(通常50-100MB)
- 带向量扩展的SQLite是最实用的选项,但能力有限
- 端侧总体积(LLM + 嵌入模型 + 向量数据库)可能超过3-4GB
- 更新知识库需要下载新的向量,而不仅仅是替换模型
微调的工作原理
微调在训练期间教会模型你的领域知识:
- 数据准备: 将你的领域知识格式化为问答对、对话或指令-回复样本
- 训练: 使用你的数据在基础模型(1-3B参数)上运行LoRA微调
- 导出: 转换为GGUF,量化,端侧部署
- 推 理: 模型从学到的知识中回答。无需检索步骤。
模型权重文件是唯一的产物。没有向量数据库,没有嵌入模型,没有检索基础设施。
对比
| 因素 | RAG (服务器) | RAG (端侧) | 微调 |
|---|---|---|---|
| 需要服务器 | 是 | 否 | 否 |
| 离线支持 | 否 | 是 | 是 |
| 端侧存储 | 不适用 | 1-4GB (LLM + 向量 + 嵌入) | 600MB-1.7GB (仅LLM) |
| 知识更新 | 更新向量数据库 | 重新下载向量 | 重新下载模型 |
| 每次查询延迟 | 500-3,000ms (网络) | 200-500ms (检索 + 生成) | 50-200ms (仅生成) |
| 基础设施成本 | 向量数据库 + API费用 | 无 | 无 |
| 隐私 | 数据发送到服务器 | 端侧处理 | 端侧处理 |
| 知识时效性 | 实时 | 定期更新 | 定期更新 |
什么时候RAG更好
RAG在特定场景中确实有优势:
快速变化的知识库。 如果你的内容每天都在变化(新闻、库存、定价),微调无法跟上。RAG检索最新的文档。但请思考: 有多少移动AI功能真正需要实时知识更新?
非常大的知识库。 如果你的领域知识涵盖数百万文档,微调1-3B模型无法吸收全部内容。RAG检索相关的子集。但同样: 有多少移动应用需要在本地搜索数百万文档?
来源标注。 RAG可以指向提供答案的具体文档。微调的模型无法轻松引用其来源。如果你的功能需要在答案旁边显示"来源",RAG有优势。
什么时候微调更好
对于大多数移动AI用例,微调获胜:
你的知识是稳定的。 产品文档、公司政策、领域术语、行业规则。这些每月或每季度更新,而非每天。微调可以干净地吸收这些知识。
你的任务是特定的。 分类、摘要、关于有界领域的问答、特定风格的内容生成。这些任务受益于深度嵌入模型的领域知识,而非文档检索。
你需要离线支持。 微调后的模型在离线时运作完全一致。RAG(即使是端侧的)在离线时更慢且更复杂。
你想要简洁性。 一个文件(GGUF模型) vs 三个组件(LLM + 嵌入模型 + 向量数据库)。更少的复杂性意味着更少可能出问题的地方。
你在意速度。 微调后的推理没有检索步骤。首token延迟为50-200ms,而端侧RAG为200-500ms。
混合方案
一些移动应用受益于混合方案:
- 微调模型 用于领域知识、风格和任务执行
- 本地搜索 (关键词或简单的SQLite FTS5) 用于用户特定的内容(笔记、消息、文档)
- 服务器端RAG 作为联网时的可选增强,用于超出端侧模型知识范围的任务
微调模型处理90%的查询。本地搜索处理用户特定的内容。服务器端RAG处理需要更广泛知识的罕见边缘情况,但仅在有网络时可用。
实际案例
场景: 一个移动应用的客服聊天机器人。
RAG方案: 将你的500篇支持文章存储在向量数据库中。每次用户提问时,检索3篇最相关的文章,注入提示词,生成回复。需要服务器基础设施或设备上500MB+的向量。
微调方案: 将你的500篇支持文章转换为2,000个问答训练样本。微调一个3B模型。模型学习你的产品、你的术语和你的支持风格。部署1.7GB的GGUF文件。无需检索。
结果: 微调后的模型从内化的知识中回答。响应延迟: 100-200ms。存储: 1.7GB(仅模型)。离线: 可用。基础设施成本: 部署后$0/月。
Ertas等平台简化了微调路径: 上传你的支持文章或问答对,使用LoRA训练,导出GGUF,部署。领域知识在模型中,而非在数据库中。
决策指南
如果你的移动应用需要具备领域知识的AI:
- 知识是否稳定(每月或更少频率更新)? 微调。
- 应用是否需要离线工作? 微调。
- 知识库是否少于10,000份文档? 微调。
- 知识是否每天变化? 考虑服务器端RAG加微调回退。
- 是否需要来源引用? 考虑在这些特定功能中使用RAG。
对于大多数移动AI用例,微调比RAG更简单、更快、更便宜、也更可靠。
Ship AI that runs on your users' devices.
Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Ship AI that runs on your users' devices.
Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Keep reading

Why Your AI App Feels Slow: Network Latency Is the Bottleneck
AI API calls add 500-3,000ms of latency to every interaction. On mobile, that is the difference between a feature users love and one they abandon. Here is where the time goes and how to fix it.

Fine-Tuning vs Prompt Engineering for Mobile Apps
Prompt engineering is fast and flexible. Fine-tuning is accurate and cheap at scale. Here is the practical comparison for mobile developers deciding between the two approaches.

On-Device AI Unit Economics: The Math That Makes Mobile AI Profitable
The complete unit economics breakdown for on-device AI vs cloud APIs. Fixed costs, variable costs, break-even analysis, and the financial model for scaling mobile AI features profitably.