Obsidian Copilot V4 与 Miyo 架构解析：语义检索、向量模型配置与最佳实践

摘要：Obsidian Copilot 在 V4 版本中进行了底层架构重构，废弃了旧版内置向量索引系统，将语义检索全面移交至 Miyo 本地服务。这一变化导致大量基于 V3 版本的教程失效，用户在配置云端向量模型时常常遇到"验证通过但无消耗"的困惑。本文基于实际调试结果，重新梳理 V4 架构下的功能边界、配置逻辑与正确使用方式。

一、架构变更：从 V3 到 V4 的核心差异

Copilot V4 的更新并非简单的界面调整，而是检索链路的重新划分。

维度	V3 及更早版本	V4 版本
向量索引管理	插件内置，设置页可选手动 Embedding 模型	已彻底移除，移交 Miyo 接管
Embedding Model 下拉菜单	存在于 Basic/QA 设置页	已移除，界面中不再暴露
强制重建索引命令	`Copilot: Force reindex vault`	已移除，替换为 `Copilot: Refresh Miyo Index`
语义检索引擎	插件内置（可配置云端或本地嵌入模型）	Miyo 本地服务独占
Miyo 角色	可选增强组件	V4 中语义检索的事实标准承载者

这一重构意味着：任何基于 V3 界面撰写的"如何配置 Embedding 模型"教程，在 V4 环境中均不再适用。

二、V4 中的四层角色拆解

理解 Copilot V4 的工作方式，需要将以下四个层次明确区分：

1. 对话模型（Chat Model）

负责生成回答。配置入口为 Settings → Copilot → Basic 或 BYOK。支持云端 API（DeepSeek、OpenAI、Anthropic、Google 等）、本地 Ollama 模型，以及 Copilot Plus 托管模型。该层与检索无关，无论是否配置向量模型，对话功能始终可用。

2. 文件级/关键词检索（Lexical Search）

V4 内置的零配置能力。通过文件名匹配、[[笔记名]] 双链解析、@ 手动引用、当前活跃笔记自动注入等方式，将笔记内容送入上下文。该机制不依赖任何向量计算，也不需要 Miyo。

3. 语义检索（Semantic Search）

按"含义"而非"字面"查找笔记。V4 中该能力唯一正式实现为 Miyo 本地服务。Miyo 桌面端负责：

文本分块（chunking）
向量化（使用 Miyo 自带的嵌入模型，如 nomic-embed-text）
本地增量索引与文件监听
语义召回与结果排序

当 Settings → Copilot → Miyo 中显示 Connected · local 且 Semantic search for agents 开启时，Agent Chat 会调用 miyo-search 工具执行语义检索。

4. BYOK 中配置的向量模型

在 BYOK 标签页添加的自定义 Provider（如腾讯云 TokenHub 的 kinfra-text-embedding-4b），即使点击 Verify 显示绿色 Verified，在 V4 + Miyo 连接状态下不参与主检索链路。该配置仅证明接口连通性，实际检索请求不会路由至此处。因此，腾讯云控制台的"模型监控"和"用量统计"中不会出现来自 Copilot 的调用记录。

三、Miyo 是否必须？

结论：Miyo 不是强制依赖，但决定了语义检索能力的可用性。

无需 Miyo 即可正常工作的场景

对话仅围绕当前打开的笔记展开（活跃笔记自动注入上下文）
手动通过 @ 或 [[ ]] 指定引用笔记
笔记总量较少（数十篇），关键词搜索即可满足需求
使用场景为总结、改写、翻译、代码辅助等不依赖跨笔记检索的任务

在上述场景中，关闭 Miyo 后对话体验几乎无差异，因为模型所需上下文已由插件通过文件读取或用户显式引用提供。

Miyo 体现价值的场景

笔记库规模较大（数百篇以上），仅记得内容大意而不确定所在笔记标题
提问使用口语化表述或同义改写，与笔记原文用词不一致
需要跨多个文件夹进行隐性关联（例如"之前对方案 A 的思考和方案 B 的矛盾点"）
需要对 PDF、EPUB 文档进行本地解析与检索
编辑笔记时期望右侧实时出现"相关笔记推荐（Relevant Notes）"

简言之：Miyo 将 Copilot 从"只能处理你递给它的笔记"升级为"能自己翻遍整个档案柜"。

四、常见配置困惑与事实澄清

困惑 1：Basic 设置页找不到 Embedding Model 下拉菜单

事实：V4 已将该选项从界面中彻底移除。寻找该菜单的操作本身基于过时的 V3 认知。

困惑 2：命令面板中没有 `Force reindex vault`

事实：该命令随旧架构一同退役。V4 中对应的索引刷新命令为 Copilot: Refresh Miyo Index，且索引的创建与维护由 Miyo 桌面端自主管理。

困惑 3：BYOK 向量模型验证通过，但云端无消耗记录

事实：Verified 状态仅代表网络连通与密钥有效，不代表该模型被纳入检索流水线。在 Miyo 处于 Connected 状态时，语义检索请求全部由 Miyo 本地处理，不会向外发送向量化请求。

困惑 4：关闭 Miyo 后回答依然全面

事实：关闭 Miyo 后模型仍可回答，是因为活跃笔记自动注入、手动引用、关键词搜索三条路径仍在工作。这并不证明向量检索"没用"，只证明当前测试的问题未触及语义检索的专属场景。

五、推荐配置方案

方案 A：Miyo 本地方案（推荐）

适用于绝大多数个人知识库场景，零额外成本，数据不出本机。

配置步骤：

安装并启动 Miyo 桌面端，添加 Obsidian Vault 文件夹，等待首次扫描完成（状态显示 scan complete + Watching）
Obsidian 中进入 Settings → Copilot → Miyo，点击 Connect
确认连接状态为 Connected · local
开启 Semantic search for agents
将 Search scope 设为 Current vault
BYOK 中配置的云端向量模型可保留（不影响功能）或直接删除（避免混淆）

验证方式：在 Agent Chat 中提问，要求模型先列出命中的笔记再总结。若回答中出现 Miyo 图标标记且引用笔记标题与提问用词"意思匹配但字面不匹配"，则语义检索已生效。

方案 B：降级至 V3 以使用云端向量模型

适用于必须使用特定云端嵌入模型（如企业合规要求）的场景。

操作步骤：

在 Settings → Copilot → Miyo 中点击 Disconnect
关闭 Obsidian 社区插件的自动更新
手动安装 Copilot V3 最新版本（需从插件仓库获取对应 release）
在 V3 的 Basic 或 QA 设置页中找到 Embedding Model 下拉菜单，选中已配置的云端向量模型
开启语义搜索开关
执行 Copilot: Force reindex vault 触发全库向量化
观察云端用量统计是否产生 Token 消耗

该方案的代价是失去 V4 引入的 Agent Chat、Miyo 文档解析、多智能体等能力，需根据实际需求权衡。

六、Miyo 工作状态自检清单

检查项	正常状态
Miyo 桌面端	Vault 文件夹显示 `Watching`，文件数正确
Copilot Miyo 设置页	状态为 `Connected · local`，非 `Offline` 或 `Checking...`
语义搜索开关	`Semantic search for agents` = ON
Agent Chat 工具调用	可见 `miyo search` 调用记录
回答来源引用	引用链接旁有 Miyo 图标，且标题与提问用词非字面一致
Relevant Notes 面板	编辑笔记时实时显示带相似度百分比的建议

若前两项不满足，检索请求不会路由至 Miyo；若后四项缺失，即使连接正常也可能未触发语义搜索。

七、最佳实践

知识库目录结构建议

复制代码

vault/
├── 00_Inbox/          # 临时速记，可索引但非核心知识
├── 10_Notes/          # 核心知识库，全量索引
├── 20_Projects/       # 项目资料，按项目检索
├── 90_Attachments/    # 图片、缓存，建议排除索引
├── 95_Templates/      # 模板，排除或低权重
├── AGENTS.md          # 全局人设与输出规范
└── system-prompts/    # 多场景人设文件

在 Miyo 桌面端中将 90_Attachments 和 95_Templates 加入排除列表，避免噪声干扰检索质量。

人设固化

在 Vault 根目录创建 AGENTS.md，定义角色身份、引用规范、输出格式等。该文件在每次新对话时自动生效，无需反复手动输入系统提示。

对话习惯

精准引用：使用 @笔记名 或 [[笔记名]]
模糊检索：在 Agent Chat 中显式提及"使用 Miyo 查找"
长文档处理：直接将 PDF/EPUB 拖入对话，由 Miyo 本地解析
写作辅助：开启 Relevant Notes 的 Live 模式，让关联笔记主动浮现

本地开发复用

Miyo 提供 CLI 与 MCP 接口，可作为独立检索后端供外部程序调用：