# 小米 15 RAG 知识库搭建：这些坑劝退了我
## 为什么做这个选题
年初给小米 15 搭建本地 RAG 知识库，前后折腾了两周，最终放弃。本文不讨论小米 15 本身硬件，只聚焦 RAG 知识库搭建过程中遇到的实际问题。若你正考虑在小米 15 上部署类似系统，建议先读完再做决定。
—
## 什么是 RAG 知识库？先搞懂基本概念
RAG（Retrieval-Augmented Generation，检索增强生成）是一种将大语言模型与外部知识库结合的技术架构。简单来说，它的工作流程是：用户提问 → 系统从知识库中检索相关资料 → 将资料连同问题一起发送给大模型 → 生成最终回答。
搭建一个可用的 RAG 系统，通常需要以下核心组件：
– 向量数据库：存储经过 embedding 处理的文本向量，负责相似度检索
– Embedding 模型：将文本转换为向量表示的工具
– 大语言模型：基于检索结果生成回答
– 文本分割工具：将长文档拆分成适合检索的小段落
– API 服务：连接各组件，提供查询接口
在电脑上部署这些组件已经需要一定的技术能力，而将其塞进一部手机里，挑战才刚刚开始。
—
## 性能瓶颈：手机端推理的硬伤
小米 15 搭载骁龙 8 Gen 3，理论算力尚可，但运行本地大模型存在几个致命问题：
### 内存占用过高
实测加载 7B 参数模型进行向量检索时，内存占用直接飙到 6GB 以上。此时系统频繁杀后台，微信、导航等常用应用会被强制关闭。更棘手的是，Android 系统的内存管理机制会优先清理非前台应用，导致 RAG 服务在后台运行时极不稳定。
> 科普：什么是向量检索？
> 向量检索是 RAG 系统的核心环节。系统先将文本转换为一段数学向量（称为 embedding），存储在向量数据库中。当用户提问时，问题和知识库中的向量进行”相似度计算”，找到最匹配的内容。计算过程涉及大量矩阵运算，对内存和 CPU 要求较高。
### 发热与续航崩溃
持续进行向量计算时，机身温度轻松突破 42℃，掉电速度达到每小时 25% 以上。这意味着满电状态下，RAG 服务仅能支撑约 4 小时。若需要 24 小时随时响应的知识库服务，必须外接电源或频繁充电。
| 场景 | 续航影响 |
|——|———-|
| 待机（无服务） | 每小时 1-2% |
| 正常使用 | 每小时 8-12% |
| 向量计算（7B模型） | 每小时 25%+ |
| 边充电边计算 | 电池温度 45℃+，损伤寿命 |
### 检索速度不达预期
单次向量检索（百万级向量库）耗时 800ms-1.2s，在手机上打开应用等待检索结果的过程，体验远不如云端方案。对比云端 API 响应时间（通常 200-500ms），本地方案在响应速度上反而处于劣势。
—
## 存储困境：向量数据库的尴尬
RAG 知识库的核心是向量数据库，而在小米 15 上存储向量数据面临双重压力：
### 存储空间紧张
以常见的 768 维向量为例，100 万条数据需要约 2.8GB 存储空间。若要构建覆盖数码评测、产品参数、对比数据等内容的知识库， 500 万向量是起步门槛，对应存储约 14GB。小米 15 本身系统占用已达 30GB+，加上应用和照片，128GB 版本剩余空间捉襟见肘。
| 向量维度 | 100万条 | 500万条 | 1000万条 |
|———-|———|———|———-|
| 384维 | 1.4GB | 7GB | 14GB |
| 768维 | 2.8GB | 14GB | 28GB |
| 1024维 | 3.7GB | 18.5GB | 37GB |
### 读写速度受限
手机闪存（UFS 4.0）的随机读写性能虽然不错，但持续大量向量数据的读写会加速闪存寿命损耗。实测写入 10 万条向量数据时，出现过两次数据库锁定导致写入失败的情况。
—
## Android 沙箱限制：后台服务的噩梦
在 Android 上运行长期服务会遇到系统级限制：
### 后台被杀是常态
小米 15 的 MIUI 后台管理策略极为激进。即使将 RAG 服务添加到白名单，系统仍会在锁屏后 15-30 分钟内强制终止进程。这意味着知识库服务无法真正实现”随时唤醒”，需要每次使用时手动启动。
> 科普：Android 后台限制机制
> 为了省电和流畅度，Android 从 8.0 开始限制后台应用活动。MIUI 进一步强化了这一机制，后台应用不仅会被”冻结”，部分进程还会被彻底杀死以释放内存。即使用户手动授予了自启动权限，系统仍可能根据电量、温度、内存压力等因素动态调整策略。
### 通知权限与常驻服务冲突
要实现后台服务存活，需要授予自启动、锁屏唤醒等权限，这会与系统安全策略冲突。 MIUI 会反复弹窗提醒，用户体验极差。
### 无法实现真正的 Serverless
与服务器 24 小时运行不同，手机端 RAG 服务只能作为”按需启动”的工具，无法替代云端或桌面端方案。
—
## 软件生态：移动端工具链缺失
构建 RAG 知识库需要完整的工具链，而移动端生态几乎空白：
### 向量数据库移动端适配差
主流向量数据库（Milvus、Qdrant、Chroma）均无官方 Android 支持。社区移植版本要么功能残缺（不支持 HNSW 索引），要么稳定性堪忧（频繁崩溃）。
| 数据库 | 官方 Android 支持 | 社区移植 | 功能完整性 |
|——–|——————-|———-|————|
| Milvus | ❌ | 部分 | 中 |
| Qdrant | ❌ | 少 | 低 |
| Chroma | ❌ | 有 | 中 |
| FAISS | ⚠️ 实验性 | 有 | 高（但难用） |
### Python 运行环境受限
虽然可以通过 Termux 安装 Python，但依赖库编译安装困难，很多 RAG 相关库（如 Sentence-Transformers）在 ARM 架构上存在兼容性问题。最终被迫使用简化版方案，牺牲了检索精度。
> 科普：为什么 Python 库在手机上难安装？
> 大部分数据科学和 AI 库（如 NumPy、TensorFlow、Transformers）在发布时只提供了预编译的 x86/x64 版本。ARM 架构（如手机处理器）需要从源码编译，这个过程需要大量系统依赖（如 gcc、cmake），配置复杂且容易失败。
### 缺乏成熟的移动端 UI 框架
构建可用的知识库查询界面需要前端开发能力，而 Android 原生开发与 Web 开发差异大，调试周期长。
—
## 真实使用场景下的体验落差
即便克服了上述技术问题，实际使用中仍有明显落差：
– 离线场景收益有限。 搭建本地 RAG 的主要目的是离线可用，但手机本身就需要网络。查资料、修手机等技术场景下，有网络时直接搜索更高效。
– 多设备同步困难。 手机端数据无法直接同步到电脑或其他设备，割裂了使用场景。
– 维护成本高于预期。 模型更新、向量化脚本调试、数据库备份等维护工作，在手机上操作效率极低。
—
## 替代方案建议
经过这番折腾，我总结了几条更务实的路径：
1. 手机作为查询终端：数据和计算交给云服务器，本地只运行客户端
2. 桌面端部署：性能释放更充分，24 小时运行无忧
3. Mini PC / NAS：功耗低、可离线、存储大，是折中方案
4. 云端 API：成本可控，免维护，但需要网络
—
## 结论：手机端 RAG 目前不具实用性
小米 15 的硬件素质毋庸置疑，但用手机搭建 RAG 知识库，目前来看是投入产出比极低的选择。性能、存储、系统限制三重 debuff 下，实际体验远差于云端 API 或桌面端部署。
更务实的做法是：手机端仅作为查询入口，数据和计算交给云服务器或本地电脑。若确实需要纯离线方案，建议考虑 Mini PC 或 NAS。
—
评论区聊聊：你在移动端部署过类似的本地 AI 服务吗？踩过哪些坑？
如需选购手机或查看最新报价，可参考 手机报价。
相关阅读：手机报价