“本地大模型”不等于“本地 RAG”。生成、向量化、重排和知识库服务只要有一个环节调用云端，文档或查询就可能离开设备。真正的全本地方案，需要逐段确认数据流。
最终链路：
- LM Studio 托管对话与嵌入模型
- Dify 负责切分、索引、召回和应用编排
- 用固定问题集验证检索，而不是只看“能回答”
01. 先画清数据流
最小链路是：文档 → 解析与切分 → Embedding → 向量库 → 召回 → 本地 LLM 生成。如果资料里有大量表格或扫描页，应先经过文档解析；如果召回候选较多，再增加重排模型。
不要让一个模型承担所有角色。对话模型负责理解和生成；Embedding 模型把文本映射成向量；Reranker 对候选片段重新排序。三者的输入输出完全不同。
02. 启动 LM Studio 服务
安装模型后，在 Developer 页面启动本地 API，也可以使用 CLI：
lms server start
curl http://localhost:1234/v1/models第二条命令应返回已加载模型列表。LM Studio 提供 OpenAI 兼容接口，因此 Dify 中可将基础地址指向 http://localhost:1234/v1。具体启动方式和接口以 LM Studio Local Server 文档为准。
选择模型时先服从硬件，而不是排行榜：
- 16 GB 统一内存：优先 7B–9B 量化对话模型和小型嵌入模型。
- 32 GB 以上：可尝试更大上下文或更高精度量化。
- 中文资料：先用自己的术语和长句测检索，不要只看英文基准。
03. 让 Dify 找到宿主机
如果 Dify 直接运行在宿主机，地址通常是 127.0.0.1:1234。如果 Dify 在 Docker 中，容器里的 localhost 指向容器自身，应改用：
http://host.docker.internal:1234/v1Linux 环境还可能需要为容器显式增加宿主机映射。排查顺序固定为：端口是否监听、容器能否访问、模型 ID 是否一致、最后才检查 Dify 表单。
先添加对话模型，再添加 Embedding 模型。保存前分别做一次最小调用；不要等知识库创建失败后才回头猜是哪一层断了。
04. 建知识库时控制切分
切分参数没有通用最优值。说明书和教程可以从 500–800 中文字符、10%–15% 重叠开始；表格、法规和 API 文档更适合按标题或语义边界切分。每个片段都应保留文档名、章节和页码等元数据。
建立索引后，先在知识库检索测试里检查 Top K 结果：
- 正确片段是否进入前 3–5 条？
- 片段是否包含回答所需的完整上下文？
- 相邻片段是否大量重复？
- 无答案问题是否仍被错误召回？
只有检索通过，再接 Chatflow。提示词中要求模型“仅根据检索上下文回答；证据不足时明确说明”，并在界面展示来源。
05. 用问题集做验收
准备至少 20 个问题，覆盖精确事实、跨段关系、术语别名、表格数据和无答案问题。记录检索命中、引用是否正确、回答是否忠实以及首字延迟。
| 症状 | 优先检查 |
|---|---|
| 完全搜不到 | Embedding 模型、索引状态、查询语言 |
| 结果相关但答案错 | 提示词、上下文长度、生成模型 |
| Top K 充满近似段落 | 切分重叠、去重、Reranker |
| 容器无法连接 | host.docker.internal、防火墙、监听地址 |
最后关闭匿名遥测和未使用的外部模型供应商，并确认服务只监听可信网络。所谓“全本地”应由网络连接和日志证明，而不是由界面标签证明。
先验证检索，再评价生成。RAG 回答错误时，最先问的不是“模型够不够大”，而是“正确证据有没有被送进去”。