本地 RAG 听起来复杂，但 2026 年的开源生态已经把它压缩到三个文件：一个模型、一个向量库、一个检索回补脚本。本文以 Ollama + Qwen2.5:14B + SQLite-Vec 为例，给出可复现的完整链路。

一、为什么选本地而不是调云端 API

  • 隐私：文档不出机器，适合合同、病历、内部手册。
  • 成本：高频检索 + 长上下文时，本地一次性 GPU 投入更省。
  • 离线：断网不宕机，Agent 的保底能力。

代价是你要自己处理 GPU 显存、量化等级和并发。对大多数单人/小团队，14B 的 Q4 量化是性能和耗电的最佳平衡点，约需 10GB 显存。

二、向量库选型：别一上来就上 Milvus

数据量 100 万条 以内的本地场景，SQLite-Vec 和 ChromaDB 完全够用，且零运维。数据量再大，再考虑 pgvector 集群。选型的核心指标是检索延迟 + 召回率，而不是「能否分布式」。

三、核心三步：切分、向量化、检索

  1. 切分：按段落切分，而不是固定 token。保留标题作为 chunk 前缀，检索命中率显著提升。
  2. 向量化：Ollama 本地 embedding 模型（如 nomic-embed-text），2048 维。
  3. 检索：Top-K 取 8，再叠加关键词 BM25 混合召回。

四、重排（Rerank）是本地 RAG 的隐藏王牌

单纯向量检索常常把「语义相近但答非所问」的 chunk 顶上来。加一道 Cross-Encoder 重排，把 Top-8 精排成 Top-3 再喂给大模型，准确率能提升一大截。实现只有十几行，强烈建议加上。

五、PowerShell 一键启动脚本

# start-rag.ps1
ollama pull qwen2.5:14b
ollama pull nomic-embed-text
python server.py --model qwen2.5:14b --embed nomic-embed-text --db local.db
# 浏览器打开 http://127.0.0.1:8081 即可问答

提示：首次启动会自动建索引，几万条文档大约需要几分钟，之后增量更新近乎实时。

六、踩坑记录

  • 显存 OOM：把上下文从 8k 降到 4k，或换 Q3 量化。
  • 检索空：多半是切分粒度过大，改成按段切。
  • 答非所问：增加重排，并把系统提示词明确「只能基于给定资料回答」。

整套方案完全开源，实验过程 10 分钟可复现。后续我们会在 1718M.CN 放出完整源码工程，欢迎跟着实操。