很多人准备做 RAG 时，第一张待办清单总是很长：数据库、向量库、Redis、对象存储、解析服务、一个能看的管理界面。还没导入第一份文档，环境已经要维护好几套。
这不一定错。生产系统本来就该认真对待。但如果眼下的问题只是“我们的文档能不能搜准”“Agent 能不能拿到可用证据”，先搭一套完整生产栈，常常会把验证拖得很久。你最后很难分清：效果不好，是检索本身的问题，还是环境还没配齐。
本地 RAG 知识库的价值在这里。它不是生产部署的缩水版，而是把第一个要验证的问题缩到足够小：给它一批真实文档，问几个真实问题，看检索结果和出处，再决定下一步。
本地跑起来，先看三件事
第一件是文档进来之后有没有被正确处理。合同、产品手册和项目资料不是纯文本，PDF 里的页码、表格和标题层级都会影响后来怎么找。琅嬛目前支持 PDF、DOCX、Markdown、TXT、CSV 和 XLSX；导入后会经过解析、分块和索引，而不是把原文件直接塞进模型。
第二件是查询能不能命中你真正关心的词。中文尤其容易暴露问题。有人搜一个合同编号、产品名或部门简称，纯向量检索可能觉得它语义不够“像一句话”，结果把最该命中的段落排到后面。单机模式用 gse 做中文分词，再配合 sqlite-vec 和 FTS5；生产的 PostgreSQL 模式对应的是 pgvector、全文检索和 zhparser。两边不是同一套实现，但都保留了向量与关键词两路召回的思路。想把这个取舍讲清楚，可以接着看混合检索到底补了什么。
第三件是结果能不能核对。一个能跑的 demo 不该只显示“回答正确了”。你至少要看到命中的段落来自哪份文件、哪个版本和什么位置。否则一旦结果看起来不对，还是会回到猜模型、猜提示词的老路。
为什么单二进制适合这个阶段
琅嬛的 standalone 模式把 REST、MCP、异步任务和 Web Console 放进一个二进制里。第一次启动时，它会建立 SQLite 数据库、生成必要的配置和密钥。没有 PostgreSQL、Redis 或 Docker 也可以导入文档、建立检索、从 Web 或 API 查询。
这不是说 SQLite 可以替代所有生产组件。它解决的是更窄的问题：让一台开发机或一台演示机器不必因为外部依赖而卡在起点。数据留在一个 .db 文件中，删库、重新导入、比较不同分块方式都更直接。
实际开始时，我建议不要拿十个“看起来不错”的问题验收。找三五个平时真的会问的问题，其中至少放一个专有名词、一个需要跨段理解的问题，再放一个故意没有答案的问题。前两个看召回，最后一个看系统会不会把空结果说成有内容。这个小测试比一上来问“整体准确率如何”有用得多。
什么时候该从本地模式换出去
本地模式适合试验、个人使用和演示，也适合在接入第一个 Agent 前先摸清文档特征。下面这些信号出现后，就该认真考虑 PostgreSQL + Redis 的部署：
- 多个工作区和成员开始同时使用；
- 导入量变大，任务需要可靠排队和重试；
- 你开始关心备份、监控和独立的数据库运维；
- 业务已经依赖检索结果，不能接受“开发机顺手跑一下”的可用性。
这不是一次迁移失败，而是验证完成后的正常升级。底层换成 PostgreSQL 和 Redis 后，文档处理、工作区隔离和 MCP/REST 接入的边界不需要重新发明。项目提供的两种模式和差异在 SQLite 支持说明 里写得更细。
从本地知识库接到 Agent
本地检索验证通过，下一步不一定要先做聊天界面。你可以直接用 REST 查，也可以把 /mcp 接给支持 MCP over HTTP 的客户端。这样更容易看清一个事实：知识库负责的是取证，不是替应用回答。
如果接入后有两个 Agent 都想读同一批资料，就别急着再复制一个本地库。先看看能否让它们共享一个检索服务。MCP 知识库该共享什么讲的是这条边界；要直接试运行，可以从下载页拿到对应平台的二进制。
本地 RAG 的第一步不该是搭出最复杂的架构。先把一份真实资料搜明白，看到出处，再往上加需要的东西。