Compare

搜索效率：用 MCP 组装可复用的检索 Skill

2026-01-29 21:01 · Zon · Issue → AI → Report

面向知识工作/Obsidian 的工具链与评测方法（含意图分支）

用 MCP 组装检索 Skill，提升个人搜索效率

TL;DR

  • 我这里将“搜索效率”定义为：在知识工作中更快、更准地找到可引用的信息/答案（降低总耗时、步骤数与返工率）。
  • 用 MCP（Model Context Protocol）把“搜→读→引用→写回”拆成标准工具：查询改写 → 多源检索 → 打开网页/抽正文 → 去重排序 → 产出带引用的总结 → 写回笔记/任务。
  • 最小可用组合：一个 Web 搜索入口（SearxNG 或任一搜索 API）+ 网页正文抽取（Playwright/Readability/Trafilatura）+ 本地笔记检索（ripgrep）+ 缓存与日志。
  • 先把“可复盘”做出来：对每次检索记录 query、候选结果、打开页面数、总耗时、最终是否产出可引用证据，再谈“指数提升”。

Key Insights

  • 先做“范围判定”再搜：同一问题优先查本地笔记/代码与内部资料，其次查权威官方文档，最后再上泛 Web；范围越窄，噪声越低。
  • LLM 负责“规划与写作”，检索工具负责“可验证证据”：把打开链接、抽正文、提取引用段落工具化，可显著降低幻觉与漏引。
  • 混合检索更稳：关键词/BM25（精确匹配）+ 向量/Embedding（同义召回）+ rerank（重排）通常比单一策略更接近“又快又准”。
  • “效率指数”最好可计算：Time-to-Answer（总分钟数）、Hops（检索轮次/打开页数）、Success（是否得到可引用证据）、Reuse（是否写回可复用笔记）。

Playbook

  • 1) 定义输入输出：输入是用户问题与约束（时间范围、地域、语言、可信来源偏好）；输出固定为“结论 + 证据链接/引用 + 反例/不确定性 + 下一步行动”。
  • 2) 建立数据源与索引：本地 Obsidian Vault 用 ripgrep/SQLite 索引；PDF/Office 用 Apache Tika 抽取文本；结构化资料可用 Meilisearch/Typesense 做全文检索。
  • 3) 设计 MCP 工具面（最小闭环）：web_search(query, recency, domain_allowlist) → open_url(url) → extract_text(html) → cite(snippet, url) → write_note(path, md)。再逐步加：dedupe、hybrid_rank、cache_get/put、rate_limit、error_retry。
  • 4) 评测与迭代：建 20–50 条“典型问题集”与预期证据来源；每次改动跑回归，输出成功率、平均耗时、平均打开页数，并把失败样例分类（检索不到/抓取失败/去重差/总结偏）。

Diagrams

Decision Map ↑ Control / Consistency Speed / Convenience → 1 意图假设 1：你想做“个人知识… 2 意图假设 2：你想复现/拆解你… 3 意图假设 3：你想先把“搜索效… 4 术语分支：本文采用“知识工作检…
Options · 速度 vs 可控性 的决策图（基于 Options 文本自动定位）
Execution Steps 1 定义输入输出 2 建立数据源与索引 3 设计 MCP 工具… 4 评测与迭代
Playbook · 执行步骤时间线（基于 Playbook 文本自动提取）

Options

  • 意图假设 1：你想做“个人知识工作检索”Skill（Web + 本地笔记/仓库），用 MCP 把流程工具化并写回 Obsidian，目标是减少搜资料时间与返工。
  • 意图假设 2：你想复现/拆解你给的小红书链接里的“搜索效率指数增”做法，并把它改造成可调用 MCP 的版本（但链接内容当前无法在线核验）。
  • 意图假设 3：你想先把“搜索效率指数”定义成一套指标与仪表盘，用来对 skill 的改动做量化验证（而不是主观体感）。
  • 术语分支：本文采用“知识工作检索效率”；若你说的其实是“内容平台/小红书 SEO 的搜索效率（曝光/点击/转化）”或“站内搜索相关性/零结果率”或“代码搜索效率”，指标、工具与优化路径会明显不同，需要先选定口径。

Expert Views

  • 开源数据工程师（paraphrase）：优先稳定与可观测；建议强制记录每次检索的参数、返回 TopN、抓取耗时与失败原因，配合缓存与重试，把“工具可靠性”当成第一优先级。
  • 信息检索研究者（paraphrase）：强调基线与评测；建议先用 BM25 做强基线，再加查询扩展（同义/实体）、字段加权、hybrid rerank，用 MRR/命中率衡量，而不是凭感觉说“指数增”。
  • 数据隐私/合规视角（paraphrase）：关注外发风险；建议默认本地优先与最小化外发，对第三方搜索 API 做脱敏/过滤（例如去掉人名、内部项目代号），并明确日志保留策略。
  • 产品经理视角（paraphrase）：关注闭环与复用；建议把结果一键写回（Obsidian/工单/Notion 均可），并用统一模板沉淀“可二次检索”的结构化笔记，避免每次从零开始搜。

Evidence & Confidence

  • MCP 用于把外部工具能力标准化并被客户端调用：high；理由是有官方规范与开源实现生态（具体以官方文档/仓库为准）。
  • “规划/总结交给 LLM，证据获取交给工具”能降低幻觉并提升可复盘性：medium；理由是常见工程实践有效，但收益高度依赖抓取质量、引用约束与失败兜底。
  • BM25 + Embedding 的混合检索通常优于单一检索：medium-high；理由是信息检索与 RAG 实践中普遍采用，但需要按语料与任务调参、并做离线评测验证。
  • 小红书链接内的具体实现、参数与“效率指数”口径：low；理由是当前无法在线核验其正文内容与上下文。

Next Steps

  • 请你在 3 个方向里选一个并给样例：A 个人检索闭环（Web+Obsidian）B 拆解小红书方案并迁移到 MCP C 先做指标体系与评测；每个方向给 3 条真实查询与“满意答案长什么样”。
  • 先落地最小闭环：只实现 web_search + open_url + extract_text + cite + write_note，把结果写回固定目录（例如 daily_research/），一周内就能看到是否省时。
  • 决定检索后端与抓取方式：自建 SearxNG（隐私更好但要运维）或第三方搜索 API（上线快但要控成本/合规）；抓取优先用无头浏览器以应对动态页面。
  • 建立“指数”计算表：每条任务记录耗时、检索轮次、打开页数、最终是否产出可引用证据、是否写回可复用笔记；用它对比“启用 skill 前 vs 后”。

Details (Optional)

Details

TL;DR

  • 我这里将“搜索效率”定义为：在知识工作中更快、更准地找到可引用的信息/答案（降低总耗时、步骤数与返工率）。
  • 用 MCP（Model Context Protocol）把“搜→读→引用→写回”拆成标准工具：查询改写 → 多源检索 → 打开网页/抽正文 → 去重排序 → 产出带引用的总结 → 写回笔记/任务。
  • 最小可用组合：一个 Web 搜索入口（SearxNG 或任一搜索 API）+ 网页正文抽取（Playwright/Readability/Trafilatura）+ 本地笔记检索（ripgrep）+ 缓存与日志。
  • 先把“可复盘”做出来：对每次检索记录 query、候选结果、打开页面数、总耗时、最终是否产出可引用证据，再谈“指数提升”。

Key Insights

  • 先做“范围判定”再搜：同一问题优先查本地笔记/代码与内部资料，其次查权威官方文档，最后再上泛 Web；范围越窄，噪声越低。
  • LLM 负责“规划与写作”，检索工具负责“可验证证据”：把打开链接、抽正文、提取引用段落工具化，可显著降低幻觉与漏引。
  • 混合检索更稳：关键词/BM25（精确匹配）+ 向量/Embedding（同义召回）+ rerank（重排）通常比单一策略更接近“又快又准”。
  • “效率指数”最好可计算：Time-to-Answer（总分钟数）、Hops（检索轮次/打开页数）、Success（是否得到可引用证据）、Reuse（是否写回可复用笔记）。

Playbook

  • 1) 定义输入输出：输入是用户问题与约束（时间范围、地域、语言、可信来源偏好）；输出固定为“结论 + 证据链接/引用 + 反例/不确定性 + 下一步行动”。
  • 2) 建立数据源与索引：本地 Obsidian Vault 用 ripgrep/SQLite 索引；PDF/Office 用 Apache Tika 抽取文本；结构化资料可用 Meilisearch/Typesense 做全文检索。
  • 3) 设计 MCP 工具面（最小闭环）：web_search(query, recency, domain_allowlist) → open_url(url) → extract_text(html) → cite(snippet, url) → write_note(path, md)。再逐步加：dedupe、hybrid_rank、cache_get/put、rate_limit、error_retry。
  • 4) 评测与迭代：建 20–50 条“典型问题集”与预期证据来源；每次改动跑回归，输出成功率、平均耗时、平均打开页数，并把失败样例分类（检索不到/抓取失败/去重差/总结偏）。

Expert Views

  • 开源数据工程师（paraphrase）：优先稳定与可观测；建议强制记录每次检索的参数、返回 TopN、抓取耗时与失败原因，配合缓存与重试，把“工具可靠性”当成第一优先级。
  • 信息检索研究者（paraphrase）：强调基线与评测；建议先用 BM25 做强基线，再加查询扩展（同义/实体）、字段加权、hybrid rerank，用 MRR/命中率衡量，而不是凭感觉说“指数增”。
  • 数据隐私/合规视角（paraphrase）：关注外发风险；建议默认本地优先与最小化外发，对第三方搜索 API 做脱敏/过滤（例如去掉人名、内部项目代号），并明确日志保留策略。
  • 产品经理视角（paraphrase）：关注闭环与复用；建议把结果一键写回（Obsidian/工单/Notion 均可），并用统一模板沉淀“可二次检索”的结构化笔记，避免每次从零开始搜。

Options

  • 意图假设 1：你想做“个人知识工作检索”Skill（Web + 本地笔记/仓库），用 MCP 把流程工具化并写回 Obsidian，目标是减少搜资料时间与返工。
  • 意图假设 2：你想复现/拆解你给的小红书链接里的“搜索效率指数增”做法，并把它改造成可调用 MCP 的版本（但链接内容当前无法在线核验）。
  • 意图假设 3：你想先把“搜索效率指数”定义成一套指标与仪表盘，用来对 skill 的改动做量化验证（而不是主观体感）。
  • 术语分支：本文采用“知识工作检索效率”；若你说的其实是“内容平台/小红书 SEO 的搜索效率（曝光/点击/转化）”或“站内搜索相关性/零结果率”或“代码搜索效率”，指标、工具与优化路径会明显不同，需要先选定口径。

Evidence & Confidence

  • MCP 用于把外部工具能力标准化并被客户端调用：high；理由是有官方规范与开源实现生态（具体以官方文档/仓库为准）。
  • “规划/总结交给 LLM，证据获取交给工具”能降低幻觉并提升可复盘性：medium；理由是常见工程实践有效，但收益高度依赖抓取质量、引用约束与失败兜底。
  • BM25 + Embedding 的混合检索通常优于单一检索：medium-high；理由是信息检索与 RAG 实践中普遍采用，但需要按语料与任务调参、并做离线评测验证。
  • 小红书链接内的具体实现、参数与“效率指数”口径：low；理由是当前无法在线核验其正文内容与上下文。

Next Steps

  • 请你在 3 个方向里选一个并给样例：A 个人检索闭环（Web+Obsidian）B 拆解小红书方案并迁移到 MCP C 先做指标体系与评测；每个方向给 3 条真实查询与“满意答案长什么样”。
  • 先落地最小闭环：只实现 web_search + open_url + extract_text + cite + write_note，把结果写回固定目录（例如 daily_research/），一周内就能看到是否省时。
  • 决定检索后端与抓取方式：自建 SearxNG（隐私更好但要运维）或第三方搜索 API（上线快但要控成本/合规）；抓取优先用无头浏览器以应对动态页面。
  • 建立“指数”计算表：每条任务记录耗时、检索轮次、打开页数、最终是否产出可引用证据、是否写回可复用笔记；用它对比“启用 skill 前 vs 后”。

Sources

Sources

Closing Summary

  • 结论：用 MCP 组装检索 Skill，提升个人搜索效率
  • 下一步：把你的 skill 运行环境与 3 条典型查询发我，我按场景给最小 MCP 工具链配置。

One next action

把你的 skill 运行环境与 3 条典型查询发我，我按场景给最小 MCP 工具链配置。

先闭环，再上强度。
— AI pipeline