Back to blog
    移动端微调 vs RAG: 为什么RAG仍然需要服务器
    fine-tuningRAGmobile AIarchitectureon-device AIsegment:mobile-builder

    移动端微调 vs RAG: 为什么RAG仍然需要服务器

    RAG是为AI提供领域知识的首选方案。但在移动端,RAG重新引入了你试图消除的服务器依赖。微调则将知识直接嵌入模型本身。

    EErtas Team·

    检索增强生成(RAG)是"如何让AI具备领域知识"这个问题的标准答案。检索相关文档,注入提示词,让模型基于上下文回答。这在有服务器基础设施的Web应用中运作良好。

    在移动端,RAG存在一个结构性问题。检索步骤需要向量数据库。这个数据库要么在服务器上(重新引入服务器依赖),要么在设备上(消耗大量存储和内存)。对于移动端来说,两种方案都不够理想。

    微调采用不同的方法。它不是在推理时查找知识,而是在训练期间将知识嵌入模型权重中。模型无需检索就能了解你的领域。

    RAG的工作原理(以及为什么它需要基础设施)

    标准的RAG流程:

    1. 索引阶段: 将文档分块,生成嵌入向量,存储在向量数据库中
    2. 查询阶段: 将用户的问题转换为嵌入,在向量数据库中搜索相似的块,检索前3-5个结果
    3. 生成阶段: 将检索到的块连同用户的问题一起注入提示词,发送给LLM

    服务器依赖

    第2步需要进行向量相似性搜索。在服务器端,这使用Pinecone、Weaviate或pgvector等数据库。这些是服务器端服务。

    对于移动端,你有两个选择:

    服务器端RAG: 用户的问题发送到你的服务器,服务器执行检索并调用LLM API。这是最常见的架构,但意味着每次查询都需要网络往返。你又回到了云依赖,伴随着所有问题: 延迟、离线失败、隐私顾虑和持续的基础设施成本。

    端侧RAG: 将向量数据库存储在手机本地。这消除了服务器但产生了新问题:

    • 向量数据库根据语料库大小额外消耗100MB-1GB+的存储
    • 查询的嵌入生成需要运行一个单独的模型(通常50-100MB)
    • 带向量扩展的SQLite是最实用的选项,但能力有限
    • 端侧总体积(LLM + 嵌入模型 + 向量数据库)可能超过3-4GB
    • 更新知识库需要下载新的向量,而不仅仅是替换模型

    微调的工作原理

    微调在训练期间教会模型你的领域知识:

    1. 数据准备: 将你的领域知识格式化为问答对、对话或指令-回复样本
    2. 训练: 使用你的数据在基础模型(1-3B参数)上运行LoRA微调
    3. 导出: 转换为GGUF,量化,端侧部署
    4. 推理: 模型从学到的知识中回答。无需检索步骤。

    模型权重文件是唯一的产物。没有向量数据库,没有嵌入模型,没有检索基础设施。

    对比

    因素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:

    1. 知识是否稳定(每月或更少频率更新)? 微调。
    2. 应用是否需要离线工作? 微调。
    3. 知识库是否少于10,000份文档? 微调。
    4. 知识是否每天变化? 考虑服务器端RAG加微调回退。
    5. 是否需要来源引用? 考虑在这些特定功能中使用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