你手上有个知识库，想给 AI 客户端挂一个能检索的 MCP Server，结果一搜全是「支持 RAG」的列表页，看不出哪个能上生产。这篇不讲 MCP 概念，也不讲协议怎么配，只讲工程侧怎么验：延迟从哪来、并发扛不扛得住、检索挂了怎么降级、日志够不够复盘、上线前拿什么评测。挑完这五项，能筛掉大半只能跑 demo 的候选。
你手上有个知识库，想给 AI 客户端挂一个能检索的 MCP Server，结果一搜全是「支持 RAG」的列表页，翻半天看不出哪个能上生产。这篇不讲 MCP 协议怎么配，也不讲概念，只讲工程侧怎么验：延迟从哪来、并发扛不扛得住、检索挂了怎么降级、日志够不够复盘、上线前拿什么评测。这五项挑完，能筛掉大半只能跑 demo 的候选。
先说明一个容易踩的坑：「支持 RAG」这四个字本身说明不了任何事。有的只是把查询转给向量库再丢回来，有的自己顺手做了切分、重排、甚至直接生成答案。后者代码少写点，出问题时排查面却大得多。所以第一步不是挑产品，是先定你自己愿意交出去哪一段。
先定职责边界：它到底替你做哪一段
评估任何候选之前，先写清三件事：你的语料存在哪里、检索结果要以什么形式回到客户端、哪些环节你坚决自己控制。这三件事写不出来，后面所有对比都是凭感觉。职责清单越短，候选越好挑，失败面也越小。
- 区分「只做检索」和「顺带做切分、重排、生成」两类 Server，职责越多，超时和失败面越大；先想清楚哪些环节你愿意交给它
- 列出你的硬接口清单：一次检索能不能带元数据过滤、能不能返回原文片段加来源定位、分数是否可解释（用于自己再排一次序）
- 明确它跟你现有向量库的关系：是直连你的库，还是自带一套存储；自带存储的要问清数据怎么导出，否则退出成本很高
- 判断不适用：语料量很小、单机内存装得下、调用方只有一个客户端时，直接写个本地函数可能比挂一个 Server 更省事
| 职责类型 | 典型行为 | 你要额外盯的点 |
|---|---|---|
| 纯检索 | 收查询、返回片段与来源 | 超时档位、并发上限 |
| 检索+切分 | 自己决定文档怎么切 | 切分策略能否改、改了要不要重建 |
| 检索+重排 | 返回前再排一次序 | 重排模型跑在哪、加多少延迟 |
| 检索+生成 | 直接给答案 | 引用是否可追溯、失败怎么表达 |
延迟与超时：把一次检索拆开量
说「这个 Server 有点慢」没有意义，得拆开看慢在哪一段。一次检索至少分三段：入参处理与鉴权、向量检索或关键词召回、结果拼装与序列化。三段各自耗时不同，优化手段完全不一样。只报一个总耗时，你没法判断是网络问题还是索引没建对。
- 先量网络基线用 /tools/speed-test 记录你当前网络到目标服务的往返延迟，后面所有耗时都扣掉这段，避免把网络抖动算成 Server 慢
- 拆段计时在建索引量、查询量、过滤条件都固定的前提下，分别记录三段耗时，多跑几次取稳定值而不是首次值
- 单设超时档位给 MCP 调用单独配超时，别沿用普通 API 的默认值；检索类调用普遍比生成类短，超时设太长只会让上层一直挂着
- 按顺序排查先看是不是首次调用冷启动（模型加载、索引预热），再看是不是每次都在重跑 embedding，最后才怀疑向量库本身
并发、限流与降级：多个客户端一起来会怎样
本地一个人调试很流畅，不代表接进团队共用的客户端还能用。并发问题的典型表现是「所有人一起变慢」，而不是某个人报错。评估时要问的是它在并发下怎么管连接、被限流之后是拒绝还是排队，以及失败时上层会看到什么。
- 搞清它在并发下是共享一个连接池还是每请求新建连接；后者在几个客户端同时开工时很容易先把下游向量库打满
- 问清限流口径：是按请求数还是按 token 扣，是拒绝还是排队；拒绝类要配上重试节奏，排队类要留意排队时长是否计入你的整体超时
- 准备降级路径：检索失败或超时时，退回关键词检索、退回缓存结果、还是直接告诉模型「没查到资料」，三种行为对最终答案的诚实度差别很大
- 排查顺序：先看是不是所有请求一起变慢（下游被打满），再看是不是只有带过滤条件的请求慢（索引没建对），最后才看 Server 自身的进程状态
- 拒绝式限流
- 超出配额直接报错，需要你实现重试与退避，好处是不会拖长整体响应
- 排队式限流
- 请求进队列等资源，容易把单次调用拖到超时，要先确认排队时长算不算在超时里
- 硬降级
- 检索不可用时直接返回空结果并明确告知，答案更保守但不会编
- 软降级
- 退回关键词检索或缓存结果，命中率可能下降，需要日志区分是哪种路径返回的
日志与评测：怎么证明它真的比换个方案好
很多候选的日志只给一个成功或失败标记，出问题根本查不动。你需要的是一条能复盘的记录：查询原文是什么、召回了多少条、命中的片段标识、耗时、失败原因。没有这些字段，后面优化检索策略全靠猜。有了日志，再搭一条最小评测集就很快。
评测集不用大，几十条真实问题就够，关键是覆盖三类：答案明确在库里某一篇、答案分散在两三篇要拼起来、以及库里压根没有答案。第三类最能看出 Server 会不会硬凑。对比时固定其他变量——同一套语料、同一个模型、同一批问题，只换 MCP Server。
| 评测维度 | 怎么看 | 记录什么 |
|---|---|---|
| 命中情况 | 检索结果里有没有包含正确来源 | 命中片段标识与排名 |
| 引用准确性 | 最终答案是否引到正确来源 | 引用到的片段与真实出处是否一致 |
| 无答案表现 | 库里没有答案时它返回什么 | 是空结果、低分片段还是硬凑内容 |
| 稳定性 | 同一问题多次调用结果是否一致 | 多次调用的差异 |
上线前的检查清单与目录用法
五项都过一遍再决定接不接：超时是否单独配置、并发上限是否明确、失败是否有降级、日志是否可复盘、是否跑过一轮小评测。缺一项就先别接进正式客户端，尤其别在只有单人调试过的情况下就放开给团队用。
- 去 /mcp 按检索类筛一遍候选，先看职责边界和是否支持你用的向量库，再看别的
- 到 /stacks/vector-dbs 核对它支持的库是不是你正在用的那套，别选完才发现要迁移
- 涉及第三方托管检索服务时，到 /official-api/providers/cohere 这类页面核对它宣称的能力与实际计费口径是否对得上
- 检索链路里还要挂模型调用的话，成本和额度的当时数字去 /official-api 与 /tools/model-cost-calculator 现算，别用别人文章里的旧数字
- 只在本地个人环境试玩、数据不外发时，清单可以精简到「超时」和「日志」两项
最后提醒一句：判断标准是给自己用的，不是给候选打分的绝对表。语料还在频繁变动、问题集都没稳定下来的早期阶段，先别急着做严格评测，把日志打全更有价值；等语料稳定了再补评测，顺序反了会白忙。
下一步拿你正在看的那个候选，对照上面的清单逐项找它要答案，卡在哪一项就先去站内把对应资料补齐。→常见问题
MCP Server 和直接写个检索函数有什么区别，值得为它多一层吗？
看你有几个调用方。只有一个客户端、代码都在一个仓库里，直接写函数更省事，调试也直接。一旦有多个客户端、多种语言、或者别人也要用你的知识库，统一的 Server 接口才有价值：权限、日志、限流只需做一遍。判断标准是调用方数量和维护边界，不是技术先进程度。
怎么判断一个 RAG 型 MCP Server 适不适合上生产？
别只看它支持多少个向量库。按顺序问四个问题：一次检索的延迟能不能拆开量、并发上来是被限流还是排队、失败时有没有降级路径、日志能不能复盘到具体命中了哪几段。四个都答得上来再考虑接入，答不上来的先当 demo 用。
接入后答案质量没变好，先查哪一头？
先分清是召回没召到，还是召回到了但模型没用。把每次检索命中片段单独打印出来看一遍：命中里本来就没有答案，问题在切分和索引；命中里有答案但回答跑偏，问题在拼装和提示词。这一步不做，怎么换 Server 都是碰运气。
