DeepSeek 开放自研搜索 API 并更新 V4.1-Flash-1017，RAG 检索层该怎么重画

DeepSeek API 的更新日志又动了。

第一条，DeepSeek-V4.1-Flash-1017 发布。第二条，开放自研搜索 API。

第二条的措辞很克制："DeepSeek 网页端与 API 端的搜索能力均由自研 DeepSeek 搜索引擎提供底层支持。"往下看，几个数字足以让任何做过 RAG 的人睡不着：每天稳定处理来自全球各地的数亿次搜索请求，索引了全球千亿级网页，支持多语言，并且针对 SEO 作弊、GEO 操纵和低质 AIGC 设有识别过滤机制。

一句话概括这件事的分量：一个模型厂商，把一整套在生产里跑了很久的搜索引擎，以 API 原语的形式摆到了你面前。它直接触碰了过去三年 RAG 架构中最脏、最累、最不可控的那一层，检索层。我们花三年时间用向量库、重排模型、联网搜索拼装出来的那条链路，很可能要重新画一次。

这篇文章回答三个问题。这条更新到底改了什么，改到了接口字段这一级？你的 RAG 架构还剩几层是必须自己做的？以及最实际的，你今晚应该动手做什么实验，才能在三个月后的架构评审上拿出自己的数据而非厂商的口径。

--- 同一天的两条更新：模型变便宜了，检索变成了接口

先把事实钉在桌面上。

2026 年 10 月 17 日，DeepSeek API 更新日志出现两条记录。

第一条是 DeepSeek-V4.1-Flash-1017 更新。官方网页端与 APP 的模型同步切到新版本；API 调用方式与价格保持不变，仍用 deepseek-flash 这个模型名即可访问最新模型。官方给这一段起的小标题是"性能–费用的帕累托改进"，正文里的原话是：在提升性能的同时，缩短了模型的任务运行时间与输出长度，让用户以更低成本、更快速度完成任务，在多个 Harness 下达到新的性能–费用帕累托最优。

价格不变，模型换了，连模型名都没换。这在 SaaS 行业相当于"加量不加价"的极端版本，你的代码一行不动，第二天醒来模型已经是新的了。

第二条是开放自研搜索 API。官方对它的定义是"AI 原生的通用搜索引擎"，索引全球千亿级网页，支持多语言搜索，实时返回高相关、高权威、高时效的结果，并对 SEO 作弊、GEO 操纵、低质 AIGC 做识别过滤，"确保向用户与 LLM 呈现权威可信的信息"。注意最后半句的措辞，"用户与 LLM"并列，这个引擎从设计目标上就把模型当作一等读者。

为什么这两条值得一个架构师熬夜？因为它们互相咬合，而非简单并列。

模型侧的变化意味着 Agent 的单位任务成本在下降。检索侧的变化意味着 Agent 获取外部信息的方式被平台化了，你不再需要自己拼一套"搜索、抓取、清洗、塞上下文"的杂牌军，一次调用就能拿到带相关性分、带权威分、带发布时间的结构化结果。一降一升之间，夹着的是你过去两年在 RAG 检索层上的全部工程投入。

还有一处容易被略过的细节藏在模型更新的末尾：官方明确说这次升级特别针对 DeepSeek Harness、腾讯 CodeBuddy、WorkBuddy 等平台框架做了优化，并要求把 DeepSeek Harness 升级到 0.2.1-rc.1 及以上版本才能获得最佳体验。模型厂商不只在卖模型，它在为具体的 Agent 框架做定向适配。这是生态打法，不是参数打法。

把这两条放到 DeepSeek 自己的时间线上看，节奏感更清楚：

从 4 月到 10 月，模型线每个月都有动作，接口线则一直在做"让 Agent 框架更好接"的事：Responses API、Anthropic 接口格式、Codex 一键配置、思考强度分档。搜索 API 是这条接口线上第一次把"模型之外的能力"拿出来卖。这不是一次孤立的功能发布，而是一条已经走了半年的路线上的新站点。 检索层为什么一直是 RAG 的工程债

要理解这次冲击的力度，得先承认一个不太体面的现实：过去三年，RAG 架构里的检索层，几乎一直是整个系统里工程质量最差的部分。

回忆一下经典 RAG 流水线长什么样：

图里"联网搜索拼装"那一块，是几乎所有 RAG 团队都踩过坑的地方。我把这些坑按出现顺序排一遍，你大概率会在其中认出自己的项目。

召回质量是第一个坑。向量检索擅长语义相似，对时效性、事实性问题束手无策。"某法规 2026 年最新修订版是哪一版"这类问题，向量库里存的旧文档会自信地给出过期答案。于是大家被迫外挂联网搜索。

联网搜索的"外包感"是第二个坑。市面上能用的搜索 API 屈指可数，要么贵到离谱，要么结果质量像开盲盒，排序逻辑是黑箱，返回的 snippet 是给人看的广告位文案而非给模型看的事实摘要。你花三个月调好的向量召回，被一次随意的搜索结果污染得干干净净。

内容污染是第三个坑，也是最近两年最棘手的一个。自从大模型开始批量产内容，搜索结果里掺进了海量 AI 生成的 SEO 垃圾。更麻烦的是针对 AI 的新型污染手法，GEO（Generative Engine Optimization，生成式引擎优化）：刻意生产让 AI 更容易引用的内容，操纵 AI 的答案。你的 RAG 系统吃进去的不再是网页，而是别人精心喂给你的饵料。

新鲜度是第四个坑。向量库是离线的、批处理的，现实世界是在线的、流动的。两者的缝隙里堆着无数过期答案，而你的用户只会记住那一次答错。

所以过去三年，检索层一直靠"打补丁"活着。加一层重排，加一层查询改写，加一层时效过滤，加一层来源白名单。每一层补丁都在证明这层架构是债而非资产。DeepSeek 这次的 Search API，本质上是对这层债说：别补了，这里有一层新地基，你看看能不能直接用。

能不能直接用，得看地基的材质。所以下一节我们把接口拆到字段级。 逐字段读 Search API：它把"给模型看的搜索"做成了什么样

多数解读文章止步于官方新闻稿里的三个形容词，"高相关、高权威、高时效"。这三个词在营销稿里没有信息量，在接口文档里才有。我把《网页搜索与抓取指南》逐字段读了一遍，发现真正值钱的东西全在响应结构里。

先看入口。两个接口都是裸 JSON API，与模型 API 共用同一套 Bearer 鉴权：

| 字段 | 类型 | 必填 | 默认 | 说明 | |---|---|---|---|---| | query | string | 是 | 无 | 1 到 128 个 Unicode 字符，支持检索运算符 | | count | integer | 否 | 10 | 返回条数，1 到 50 | | oriquestion | string | 否 | 无 | 触发本次搜索的用户原始问题，用于改善查询理解 | | localization | string | 否 | 空 | 可选 IP 地址，用于结果本地化 | | needcontent | boolean | 否 | false | 是否返回页面正文 |

oriquestion 这个字段值得单独停一下。RAG 工程里标准做法是先把用户问题改写成适合检索的 query，再去搜。改写会丢信息，所以引擎额外留了一个口子，让你把原始问题一并传过去，改写后的 query 负责召回，原始问题负责辅助理解。这个字段的存在，说明引擎的查询理解层是围绕"上游是一个 Agent 在做查询改写"这个场景设计的，而非围绕"一个人在搜索框里打字"。

检索运算符是另一个信号。site:、-site:、-、-"..."、"..."、lang:、after:、before: 全都支持，并且可以组合。after:2025-01-01 lang:zh,en site:gov.cn 这种查询能直接写进 query 字符串。对严肃场景来说，这意味着来源白名单和时效约束可以前置到引擎侧，而非在拿回结果之后再过滤。

再看响应。每条结果包含的字段如下：

| 字段 | 类型 | 说明 | |---|---|---| | rerankscore | number | 0 到 3 的综合分，融合相关性、权威性、时效性；1.5 及以上视为高质量结果 | | title / url | string | 标题与链接 | | snippet | string | 约 100 到 200 字的短摘要，官方注明"用于 UI 展示" | | summary | string | 约 600 到 800 字的长摘要，官方注明"用于模型阅读" | | content | string | 页面正文，needcontent 为 false 时为空串 | | sitename / siteicon | string 或 null | 站点名与图标 | | date | string 或 null | 发布时间，UTC，RFC 3339 格式 | | authority | integer | 权威等级 0 到 4，-1 表示未知；3 及以上为高权威来源 |

snippet 与 summary 分开，一个给人看，一个给模型读，长度相差四倍。传统搜索 API 只给前者，你得自己抓全文再做摘要，或者把一百多字的 snippet 直接塞给模型祈祷够用。这里引擎替你做了那一步，而且是针对 query 做的定向摘要。

rerankscore 是一个带阈值语义的数值。官方直接告诉你 1.5 以上算高质量，这等于给了你一个可以写进代码的质量闸门：低于阈值的结果不进上下文。多数搜索 API 只给排序，不给分，你无法区分"第一名很好"和"第一名只是矮子里的将军"。

authority 是一个 0 到 4 的离散等级，并且明确 3 以上算高权威。对医疗、金融、法律场景，这个字段可以直接作为白名单的第一道筛子，再叠加你自己的域名清单。

date 以 RFC 3339 给出发布时间，时效过滤不用再靠正则从网页里抠日期。

needcontent 的取舍需要单独算一笔账。它默认关闭，打开后每条结果会带回整页正文。十条结果的正文动辄几万字，全塞进上下文既贵又会稀释注意力。我的做法是先用 summary 回答，只对通过闸门的前三条、且 summary 不足以支撑回答的，才用 needcontent 或 Fetch 补正文。按次计费的好处在这里体现出来：count 取 10 和取 3 价格相同，可以多召回少入库，用自己的闸门做二次筛选。

Fetch 接口更简单，传一个不超过 8192 字符、不含用户名密码的 HTTP/HTTPS URL，返回 title 和 Markdown 格式的 content。它的作用是补 Search 的缺口：结果里 content 为空的页面、不在索引里的指定 URL、用户贴过来的链接，都走 Fetch。

错误码也设计得很"Agent 友好"。400 参数错，401 鉴权错，402 余额不足，403 Fetch 被安全策略拒绝，404 Fetch 拿不到可用正文（URL 不可达、站点策略屏蔽、内容类型不支持、提取不出 Markdown 都归这一类），408 读请求体超时，413 请求体过大，429 超 QPS，500 内部错误，504 下游超时。官方明确两条重试规则：408、429、5xx 等待后重试，402 充值后重试，其他 4xx 不改请求就不要重试。把这两条写进你的重试策略，能省掉一堆无意义的重试账单。

把一次完整调用画成时序，你会发现它和"把搜索接进 Agent 工具循环"的形态完全一致：

这张图里三个闸门全是对官方字段的直接使用，没有一个需要你训练模型。这就是"AI 原生搜索引擎"在工程上的实际含义：它把过去你要在应用层自己造的判断，变成了响应里的字段。

计费和限速决定了这个接口在架构里的位置，必须一起看。

Search 与 Fetch 各自按成功请求计费，国内站标价每千次 5 元，国际站 0.75 美元；按次而非按 token 或按返回条数，count 取 50 和取 5 价格相同。只有返回 HTTP 200 且产生结果的请求才计费，Search 的 results 为空不计费，Fetch 拿不到正文不计费，超时不计费。通过 DeepSeek Harness、Claude Code、Codex 以服务端工具方式触发的 Search/Fetch 调用目前免费，北京时间 2026 年 11 月 1 日 00:00 起按次计费。

限速是每个账号 Search 5 QPS、Fetch 5 QPS，两者独立，按账号而非 API Key 计算，与模型并发限制相互独立。Fetch 另有按目标域名的 QPS 限制。超限返回 429。

5 QPS 这个数字比价格更重要。它直接决定了你不能把这个接口当成无限弹性的云服务来用，后面第七节会专门讲它对架构的约束。 从六个自维护组件到两个原语

把前一节的字段级理解放回架构图，新旧对比就不再是感性的"方便了"，而是可以数出来的：

从八个自维护组件变成两个原语，省掉的是持续运营的认知负担，代码行数只是表象。你不再需要盯着爬虫的封禁率，不再需要为 SEO 垃圾写规则，不再需要维护一个"哪些域名算权威"的打分模型并担心它过期。

这里要做一次诚实的校准。图里的映射是"功能对应"，不是"效果等价"。authority 字段的打分逻辑在黑盒里，它对"权威"的定义未必和你的业务一致；索引层的 GEO 过滤有多强，官方没有给出任何量化指标；summary 是引擎生成的，它本身也是一段 AIGC，有没有引入幻觉只能靠你自己抽样。所以正确的姿态是：把这八个组件从"你必须自己造"降级为"你需要验证供应商造得好不好"，而不是直接删掉。验证方法在第八节和第十节。 V4.1-Flash-1017：涨分表、口径脚注与"变短变快"的成本账

说完检索，回来看模型。这次 1017 版本的基准提升，我把它和上一版（2026 年 9 月 10 日发布的 V4.1-Flash）做了逐项对照，数字全部来自官方更新日志，并把官方脚注里的测试口径一并列出，因为有两行不能直接相减。

| 基准 | V4.1-Flash（9 月） | V4.1-Flash-1017（10 月） | 变化 | 口径说明 | |---|---|---|---|---| | HLE（w/o tools） | 36.8 | 42.6 | +5.8 | 纯文本子集分别为 39.1 / 44.0 | | Terminal-Bench 4.0 | 31.2 | 42.3 | +11.1 | 1017 版使用 Claude Code 框架测试 | | DeepSWE v1.1 | 74.2 | 77.0 | +2.8 | 使用 Mini-SWE-V2 框架测试 | | ProgramBench | 20.3 | 29.1 | +8.8 | | | NL2Repo-Bench | 65.4 | 68.2 | +2.8 | | | Automation-Bench | 54.8 | 60.5（v1.0.6） | +5.7 | 9 月版未标注版本号，口径可能不同 | | Agents' Last Exam | 31.8 | 35.4 | +3.6 | | | Apex 系列 | 65.6（MathArena Apex） | 72.1（Apex Bench v1.1） | 不可直接比较 | 基准名称不同，视为两个指标 | | Chartography（w/tools） | 78.9 | 83.0 | +4.1 | | | BabyVision（w/tools） | 89.6 | 92.5 | +2.9 | | | ZeroBench-main（w/tools） | 49.0 | 51.0 | +2.0 | 使用 Pass@5 评测 |

去掉两行口径存疑的，剩下九行全部上涨，涨幅最大的是 Terminal-Bench 4.0 和 ProgramBench，这两个都是 Agent 执行与工程任务的重头基准。这次升级的主攻方向是 Agent 执行能力，不是聊天。官方新闻稿里把它归因于"基于自反馈的强化学习"，并给了四个端到端案例：紫禁城 3D 建模、网页赛车游戏、用 Godot 引擎复刻 Portal 2、一个从史前到现代的 3D 场景。中文媒体把这个能力称作"许愿式编程"，即提示词和素材极少的条件下直接产出可运行项目。我对这四个案例的态度是：演示视频证明上限存在，不证明中位数，中位数要靠你自己的任务集。

比涨分更重要的是成本账。官方新闻页放了一张"DeepSWE v1.1 Pass@1 对比单任务成本"的图，注明使用 mini-swe-v2 harness 测试。社区读图给出的数值是：新版本在 max 档通过率约 77%、单任务约 1.3 元，上一版 74.2% 对应约 3.3 元。这组数字来自对官方图表的读数，不是官方文字，我把它标为"可信度中等"，方向可信，具体数值以你自己的实测为准。

即便只看官方文字，"缩短任务运行时间与输出长度"这一句也值得逐词拆。

输出长度缩短，在按 token 计费的世界里，输出 token 单价通常是输入的数倍，同一道任务输出缩短两成，成本就实打实下降，而分数还在涨。能力和成本同向改善，在模型迭代里并不常见，多数时候是用更长的思考换更高的分。

任务运行时间缩短，对 Agent 来说时延不只是体验问题，还是成本和稳定性问题。一条二十步的链路，每步慢 15%，端到端时间被放大数倍，超时重试的概率跟着上升，重试又产生新的 token 消耗。

"在多个 Harness 下达到帕累托最优"这半句的隐含前提是：同一个模型在不同 Agent 框架下的表现差异巨大。模型能力和框架能力是乘积关系，一个糟糕的 Harness 能把好模型拖废一半。所以官方才会点名 DeepSeek Harness、腾讯 CodeBuddy、WorkBuddy 做了定向优化，并要求升级 Harness 到 0.2.1-rc.1 以上。如果你在用这些框架，升级版本本身就是一次零成本的模型升级。

模型权重同步在 Hugging Face 和 ModelScope 开源，仓库名 deepseek-ai/DeepSeek-V4.1-Flash-1017。参数规模社区有不同说法，官方新闻稿没有给出数字，本文不引用。 你的 RAG 还剩几层：公域外包、私域自建、路由自持

把检索和模型两条线合起来，回答标题的问题：你的 RAG 架构，还剩几层是必须自己做的？

我的答案是四层变两层半。

过去的四层是自建向量库、联网搜索拼装、重排、上下文拼装。新格局下，其中两层可以心安理得地外包，另外两层的价值反而被放大，还多出半层新的。

可以外包的是公域检索。凡是答案存在于公开网页的问题，政策法规、行业新闻、技术文档、产品信息，都应优先走 Search API。理由很直接：人家有千亿级索引、有生产级吞吐、有索引层反污染、有给模型读的摘要字段，你拼不过，也没必要拼。

反而更值钱的是私域召回。当公域检索变得廉价，你手里真正的差异化资产反而更清晰：私有数据、业务文档、行业 know-how。向量库从"整个 RAG 的核心"收缩为"私域知识的专属召回层"，这算回到了它该待的位置，谈不上降级。它是你唯一无法外包的东西。

必须自己做的是路由。一个用户提问，该走 Search API 还是走向量库，还是两边都走？这个决策是新架构的关键点，也是那"半层"的由来。

路由图里几个设计要点需要展开。

路由依据是问题性质，不是关键词。"我们公司去年的中标项目有哪些"走私域；"2026 年医保支付政策有什么变化"走公域；"这个政策对我们已有的项目有什么影响"两边都要。分类器可以是一个小模型，也可以是规则加模型的混合。我的经验是先用规则兜住高置信的两端，再让小模型处理中间地带，上线后把分错的样本回流进规则。

引用溯源从加分项变成必选项。检索一旦外包给黑盒，你失去的是对排序的控制，唯一还握在手里的是出处。每条检索结果必须带 URL、发布时间和抓取时间入库，每条生成答案必须能回溯到具体来源。这是合规底线，医疗和金融场景尤其如此，与工程洁癖无关。

检索质量的评价权发生了转移。过去"召回好不好"是你的工程问题，你可以调分块、调向量模型、调重排阈值；现在公域检索的质量被封装在 API 里，变成了供应商选择问题。供应商可以换，评价权不能丢，你仍然需要定期用固定问题集跑 Search API，监控它的召回漂移。第十节给出具体做法。

私域内容绝不进入公域请求。为了做查询改写，把内部文档片段拼进 query 发给搜索接口，是最容易犯、也最难在事后发现的错误。架构上必须物理隔离：发往 /v1/tools/search 的请求只允许包含脱敏后的查询词，oriquestion 字段同样要过脱敏，因为它会原样传给引擎。 5 QPS 决定了架构：缓存、合并与队列不是优化项，是前提

多数人看到按次计费会先算价格，其实限速才是真正决定架构形态的数字。

账号级 5 QPS，Search 和 Fetch 各 5，不随 API Key 数量增加。换算一下：一个做查询扩展的 Agent，每个用户问题展开成 4 个子查询，那么并发 2 个用户就会碰到上限；一个 Deep Research 风格的 Agent 单次任务搜二三十次，单个任务就要排队五六秒。这和模型 API 那种可以靠加并发堆上去的弹性完全不同。

再把容量上限算出来。5 QPS 乘以一天 86,400 秒，单账号 Search 的理论天花板是每天 43.2 万次，按每千次 5 元折算，一个账号一天最多花 2,160 元，Fetch 同理。这个数字说明两件事。一是对绝大多数企业级 RAG，预算根本不是约束，一天花不到上限的十分之一；二是对高并发的 toC 产品或重度 Deep Research 场景，单账号的吞吐是硬顶，你要么申请更高配额，要么在架构上把调用量压下来。后者是本节的主题。

Fetch 还多一层按目标域名的 QPS 限制，官方没有公布具体数值。实践上这意味着对同一个站点的批量抓取会比预期更早收到 429，抓取任务要按域名打散、错峰排队，并对 404 做分类记录。官方把 URL 不可达、站点策略屏蔽、内容类型不支持、提取不出 Markdown 四种情况全归在 404 里，你的日志里至少要区分"这个站点拒绝被抓"和"这个页面确实不存在"，前者该进白名单的例外清单，后者该从黄金集里剔除。

所以在接 Search API 之前，有三样东西必须先建好：

缓存要分两级。精确缓存解决重复问题，语义缓存解决"同一个问题的一百种问法"。TTL 不能一刀切，新闻类问题几小时，政策法规类问题几天，产品文档类问题可以按周。缓存里必须存原始抓取时间，并在答案里透出来，否则用户看到的"最新"可能是三天前的。

合并要做 single-flight。同一个规范化后的 query 在飞行中时，后来的请求挂到它上面等结果，而非再发一次。Deep Research 类 Agent 的子查询重复率远比你想的高，这一步经常能省掉三成调用。

队列要分优先级，并且用令牌桶把出口严格钉在 5 QPS 以内。用户面前的交互请求优先，后台批处理任务让路。超过 429 之后的重试要指数退避，不要让重试风暴把本来够用的配额吃光。

降级路径必须存在。Search API 不可用时，系统应退回私域结果或旧缓存，并明确标注 stale=true，而不是直接报错或者无声地给出没有来源的答案。

这四道机制在没有外部搜索 API 的年代同样该有，只是那时候你的瓶颈在自建爬虫上，没人逼着你建。5 QPS 这个硬数字把它们从"最佳实践"变成了"不建就上不了线"。 动手实验：20 条问题、三列指标、一段能直接跑的代码

理论说完，动手。我建议的实验极小，一个晚上能跑完，但它会给你未来三个月的架构决策提供第一手数据。

实验设计是这样的。准备 20 条真实问题，分成两组。公域组 10 条，时效性强、答案在公开网页上，比如"某款药品 2026 年最新说明书的适应症""某开源框架最新版本的重要变更"。私域组 10 条，答案只存在于你内部文档，比如"我们上季度项目中某接口的超时配置是多少"。

对照组 A 是现有链路，自建向量库加第三方联网搜索拼装。对照组 B 是 Search API 直连，公域走 Search API，私域仍走向量库。

下面这段代码用的是官方文档里的真实端点和字段名，可以直接跑。它把官方的三个质量字段记进日志，这是后面做漂移监控的基础：

要记录的三列指标：

召回质量，人工打 1 到 5 分，重点看答案是否引用了权威来源、是否被 SEO 垃圾带偏。打分时顺手把 nraw 与 nkept 的比例记下来，这个比例告诉你闸门有多严，太严会漏召回，太松会放垃圾。

端到端时延，检索时延和生成时延分开记。Search 的时延官方没有承诺，你需要自己的分布，尤其是 P95。

单次成本，检索调用费加输入输出 token 费，算到分。usage 字段里有 token 数，按当期价目表折算。

跑完之后你大概率会看到两个结论：公域问题上，B 组在质量和时延上不输甚至更好，成本结构完全不同；私域问题上，向量库依然不可替代。这就验证了前面的架构判断，公域外包，私域自建，路由分流。

如果结论和我预测的不一样，那更值得写下来，那是你自己场景里最有价值的数据。 严肃场景的三条红线：权威、溯源、隔离

泼三盆冷水。Search API 再好，医疗、金融、法律这类场景，有三件事你仍然不能交出去。

权威判定权不能外包。引擎给了 authority 字段，并说 3 以上算高权威，但"什么算权威"的定义权在黑盒里。医疗场景的权威是卫健委、药监局、指南共识；金融场景的权威是交易所公告、监管文件；法律场景的权威是法院、司法部、官方法规库。你必须在应用层维护一份来源白名单，authority 字段做第一道筛，域名白名单做第二道，两道都过的优先，只过一道的降权，都不过的丢弃。引擎负责召回，你负责信任。把白名单前置到 query 里的 site: 运算符，是更省钱的做法，命中率不够时再退回全网检索。

引用溯源不能外包。黑盒排序不可解释，你的答案必须可解释。每一条进入上下文的检索结果，都要把 url、title、date、authority、rerankscore 和你自己的抓取时间入库；每一条生成答案，都要能回溯到具体引用，并且要做引用校验，模型标的编号必须真实存在于登记的来源里。这既是给用户看的，也是给监管和审计看的。

私域数据永远不出门。当 Agent 同时接 Search API 和私域向量库，最危险的情况并非数据库被攻破，而是提示词拼接悄悄把私域内容带进了公域请求。查询改写时把内部文档片段拼进 query，或者把带客户信息的原话填进 oriquestion，都会把私域内容送到第三方。架构上要物理隔离：发往公域 API 的请求经过一个脱敏网关，只允许携带通过脱敏规则的查询词，网关记录每一次出站请求的内容以备审计。

这三条红线和 Search API 的能力并不冲突。恰恰因为检索变得便宜、变得字段化，你才有余力把应用层的信任体系做扎实。过去那些精力都花在让爬虫别被封上了。 召回漂移监控：把供应商当作被观测对象

把检索外包之后，最容易被忽略的风险是"它悄悄变差了而你不知道"。供应商升级了排序模型、调整了索引策略、改了过滤阈值，你的召回质量可能在一周内滑坡，而你的日志里只有 200。

所以要建一个针对供应商的观测闭环。这件事的成本比你想象的低，因为官方已经把可观测的字段放在响应里了：

黄金集的构造方法：从真实用户问题里挑 50 条公域问题，每条标注"期望出现的来源"，可以是具体 URL，也可以是域名集合。每天或每周用相同参数回放一次，计算六类指标：期望来源命中率、rerankscore 分布的中位数和 P10、authority 3 以上占比、date 中位数距今天数、空结果率和 429 率、单问题平均成本。任何一项跨过阈值就告警，告警后人工裁决，裁决结果回流进黄金集。

这个闭环顺带解决了另一个问题：当你想把更多问题类型从私域路由切到公域，或者想把 RERANKFLOOR 从 1.5 放宽到 1.2 以提高召回，你有数据说话。每一次扩大外包范围都以黄金集指标不恶化为前提，护栏不动就推广，护栏动了就撤回。 结语：检索层不会消失，但会换一个主人

我的完整答案是：四层变两层半。公域检索外包了，联网拼装外包了；私域召回还在，路由决策还在，溯源与白名单还在，外加一个针对供应商的观测闭环。剩下的这两层半，价值比以前更高，因为它们是你唯一无法从市场上买到的部分。

这件事的意义不在于 DeepSeek 一家做了什么，而在于它标志着 RAG 架构的一次范式转移：检索从"每个团队自己攒的工程"，变成了"平台提供的水电煤"。云计算消灭了自建机房，没有消灭架构师；API 化的检索消灭了杂牌军式的拼装，把架构师的战场推向更高处，路由策略、信任体系、私域资产、评测闭环、限速下的流量工程。

需要再次校准的是信心水平。官方已确认的部分：接口、字段、计费、限速、模型基准和口径脚注。社区读图的部分：单任务成本从约 3.3 元降到约 1.3 元。我自己的判断：公域外包、私域自建、5 QPS 倒逼缓存队列、黄金集监控供应商。前者可以直接用，中者方向可信，后者请用你自己的 20 条问题验证。

今晚就能开始的行动清单： 用第八节的代码跑通 Search API 的最小调用，看一眼 rerankscore 和 authority 的真实分布； 准备 20 条对照问题，本周内跑完 A/B 对照实验，拿到你自己场景的质量、时延、成本三列数据； 在接入正式流量之前，先把精确缓存、single-flight 合并、5 QPS 令牌桶和降级路径建好； 如果在用 DeepSeek Harness、CodeBuddy 或 WorkBuddy，立刻升级版本，这是零成本的模型升级，并留意 11 月 1 日起 Harness 内置搜索开始按次计费； 盘点引用溯源链，检索结果是否带 URL 和发布时间，答案是否能回溯到编号。断链先补这个，再谈别的。

三个思考题，留给你和你的团队： 当公域检索变成一次 API 调用，团队里维护爬虫和搜索拼装的同学，应该转向做什么？我的建议是转向黄金集和信任体系，那里正缺人。 如果三个月后 Search API 的召回质量悄悄下降了，你的系统能在多少天内发现？如果答案是"等用户投诉"，第十节的闭环就是你下一个迭代的内容。 在你的业务里，"什么是权威来源"现在由谁说了算，是引擎的 authority 字段，还是你的白名单？如果你答不上来，说明这个决定正在被默默外包。