DeepSeek把搜索塞进API，企业RAG是不是白建了？
搜索能力可以买，回答的责任买不走。
读者 正在评估"把企业RAG换成API自带搜索"的架构师
痛点 公网搜索便宜到让人怀疑自建检索是浪费
现在读 一次越权回答的代价，远高于省下的检索成本
读完 拿到一条公域可买、私域自控的分界线与四个落地动作
旧方案 自建爬虫 + 清洗 + 向量库 + 重排，人工维护语料
|
v
新需求 API 侧已提供网页 Search / Fetch，覆盖与时效强于自建
|
v
冲突 能搜到不等于有权答，租户、权限、时点、保密都不在供应商侧
|
v
后果 检索全托管，等于把"答错谁负责"一起托管出去
我是老李，做架构评审时常被问到同一个问题：外面都能搜了，我们自己那套检索还留几层？
据 DeepSeek 官方文档，其 API 侧已开放搜索类接口，具体能力、计费与配额需按当前官方文档核验（见更新日志与Search 接口文档）。这意味着"公网检索"这一层，确实可以外购。
真正的问题不在能不能搜，而在搜完之后敢不敢直接答------尤其当你的知识库里躺着合同、报价和客户名单时（可参考架构文章推荐）。
那自建 RAG 到底还剩哪几层？
把 Search 直接接在内部知识库前面，最先出事的会是什么？
凭什么判断哪些环节能外包、哪些必须自己扛？
01、故事
一次方案评审，投影上放着一张老图：爬虫、清洗、切分、向量库、召回、重排、拼 prompt。会上有人提了一句------DeepSeek API 已经有 Search/Fetch 了，这张图还留几层？
任务是：把"检索"这个词拆开，分成"谁能搜到"和"谁有权答"两件事，再分别决定买还是做。
讨论很快分成两派。一派说公网覆盖和时效，自建永远追不上，索性全换；一派说内部数据一泄露就是事故，一步也不能退。两派都没错，错在把两件事混成了一件。
真正要回答的不是"要不要自建 RAG"，而是"哪些检索结果一旦答错，业务承担不起"。
能力可外购
责任难外包
先问敢不敢
再问快不快
02、问题
旧方案的失效点很清楚：自建公网检索，覆盖面和时效的维护是长期负担，更新没有尽头。
新诱惑也很清楚：一个接口就把网页搜索和抓取拿回来。
业务影响不在"慢"，在"错"。用户问内部制度，系统从公网抓了一篇同名文件，答得头头是道，来源与版本都不是你的。
技术表现是：召回命中，权限没判。相似度给了一个"看起来很像"的文档，而它本不该出现在这个租户、这个时点、这个人的答案里。
可验证的完成标准只有一条：每条答案都能给出 source、date、tenant、authority 四要素，缺一不可入答。
旧路贵且慢
新路快且险
标准先立住
再谈省多少
03、原理
反直觉判断：企业检索系统真正的质量指标不是召回率，而是"越权答案的拦截率"。召回率高只说明你捞得多，拦截率才说明你答得对。
第二个反直觉判断：搜索是能力，权限是事实。能力可以采购，事实必须自己维护。网页搜索本质是拼装公开信息，它不知道你公司的组织架构、合同归属和保密等级。
第三点容易被忽略：时点一致性。网页是活的，今天抓到的政策和昨天不同；企业事实有生效与失效区间，答案必须锚定时间。
所以供应商给的准确率分数，不是你的批准名单。它衡量的是公网问答的相对表现，不是你内部哪条数据能对谁可见。
相似非授权
命中非可答
权限是事实
不是相似分
04、架构
输入 用户问题 + 租户ID + 身份
|
v
模块 路由器：公域 Search / 私域检索
|
v
数据/状态 租户标签 · 权限表 · 生效日期
|
v
处理 出站脱敏 → 检索 → 证据闸门 → 答案组装
|
v
输出 带来源/日期/租户的可追溯答案，或拒答
边界：公域路由只处理公开事实，私域路由只处理授权事实；两条路都不允许"先检索后过滤"。收益是越权面收窄、责任可追。代价是多了一层路由与闸门，延迟与运维复杂度上升。适用条件：只要存在多租户或敏感文件，这套结构就必须有。
一路分公私
一闸定取舍
出站先脱敏
入答留证据
05、实战一次
环境：Python 3.10 以上，仅标准库。以下为最小 V1，未在当前环境实测，以下为预期结果。
from dataclasses import dataclass
@dataclass
class Hit:
source: str # public / private
tenant: str
doc_tenant: str # 公域记为 *
date: str
text: str
def route(q: str) -> str:
private_kw = ('合同', '报价', '客户', '内部', '制度')
return 'private' if any(k in q for k in private_kw) else 'public'
def gate(hits, tenant):
ok = \[\]
for h in hits:
if h.source == 'private' and h.doc_tenant != tenant:
continue # 越权，直接挡
if not h.date:
continue # 无时点，不作证据
ok.append(h)
return ok
启动与请求：
hits = [
Hit('private', 't1', 't1', '2025-09-01', '内部报价口径'),
Hit('private', 't1', 't2', '2025-09-02', '他租户合同摘要'),
Hit('public', 't1', '*', '2025-10-17', '公开行情'),
]
print(gate(hits, 't1'))
示例输出：
Hit(source='private', doc_tenant='t1'), Hit(source='public', doc_tenant='\*')
V1 跑通了：跨租户那条被挡住，公域那条保留。问题也留在了这里------公域结果没经过出站脱敏，路由只靠关键词。
先跑通最小
再暴露最大
代码不省略
结论才站住
06、排查
现象一：某租户的答案里出现另一租户的合同摘要。
怀疑：向量库的租户过滤没生效。
检查：看检索日志里过滤发生在 top-k 之前还是之后。
证据：日志显示先取 top-k，再按 doc_tenant 过滤。
根因：过滤写在排序后，候选集里已经混入越权文档。
修复：把租户条件下推到检索语句，作为前置过滤。
现象二：出站查询里带出了客户证件号。
怀疑：拼 prompt 环节没做脱敏。
检查：比对入口日志与出站日志。
根因：脱敏只做在入口，出站二次拼装又把原文放回去了。
修复：出站再做一次 PII 与商业秘密扫描，命中即拦截或改写。
错误尝试： 一开始我们调高了相似度阈值，想让"不像"的结果自动掉出去。这没用------越权文档往往和问题长得非常像，相似度和权限是两个维度，阈值治不了授权问题。
先看证据链
再改参数表
阈值治不了
权限类的病
07、优化
根因：路由靠关键词、过滤在排序后、脱敏只有一次、结果没有证据元数据。
修改：一是把公域与私域拆成独立路由，各自带自己的约束；二是租户条件前置到检索；三是出站增加脱敏审计；四是所有命中必须携带来源、日期、租户标签，再过证据闸门。
原因：前三条把"不该出现的"挡在生成之前，第四条让"已经出现的"可被追溯与复核。
新行为：无来源或无时点的结果不进答案；高风险问题走白名单与人工复核，没把握时走拒答路径。
验证：用黄金集对比公域与私域两条路的准确率、单次成本与 P95 延迟，先小流量灰度，不拿供应商分数当验收标准。
根因定动作
动作带验证
不加新概念
只补真缺口
08、演进
同一输入
|
±-V1 单一检索 + 事后过滤
| 代价：越权面大，责任无法追溯
|
±-V2 公私分路由 + 前置隔离 + 证据闸门 + 出站脱敏
| 代价：延迟与运维成本上升，需维护权限表
|
Trade-off
得到：责任可追、越权可挡
失去：一部分"能搜到就答"的便利
边界：公域事实继续外购，私域事实与授权判断自持
正确性上，V2 把权限判定前移；稳定性上，多一层闸门就多一个故障点；复杂度上，路由与脱敏都需要持续维护；成本上，外购搜索省了爬虫，但省不掉治理；适用范围上，多租户、涉密、金融保险这类场景必须走 V2；遗留问题是证据闸门的判定规则仍需要人维护。
一图看两版
各算各的账
得到与失去
写在同一行
09、洞见
9.1 能搜到不等于有权答
反直觉判断：把搜索接进来，最先暴露的不是覆盖面不足，而是权限判定缺失。检索越强，越权面越大。
9.2 采购的是覆盖率，自建的是授权边界
反直觉判断：越是想省钱全托管，越需要自己维护一份权限表。省下的是爬虫，省不掉的是治理。
9.3 先列"绝不能错"，再谈能搜多少
逆向思考的用法：先写下哪些检索结果一旦答错就不可接受------工资、合同、客户名单、监管口径------再倒推数据隔离、脱敏与审计。顺序反过来，就会先被覆盖率说服。
9.4 黄金集是唯一能比较两条路的尺子
公域接口和企业私域检索不能靠感觉比较。准备一批带标准答案的问题，同时量准确率、成本与 P95 延迟，才有讨论基础。没有黄金集，所有结论都是情绪。
判断要有据
洞见不悬空
反直觉之处
最见真功夫
10、系统落地
原来有的：一套自建检索链路，覆盖公网与内部文档。
本篇新增的：公域/私域分路由、出站脱敏审计、带来源与日期的证据闸门、拒答路径。
现在能做的：公域事实直接采购，私域事实自持，每条答案可追溯。
还缺的：权限表与文档标签的自动化维护、高风险问题的白名单与人工复核流程、黄金集的持续更新。
下一步：先在低风险场景灰度公域路由，用黄金集做对照，再逐步放开；金融保险等高风险答案必须保留人工复核和拒答路径。
原有先盘点
新增可落地
缺口写清楚
演进才有路
11、小结
Q1 → 自建 RAG 剩下的不是检索能力，而是权限、租户、时点与证据链
Q2 → 最先出事的是越权答案：命中很像，但这个人无权看
Q3 → 公域事实可买，私域事实与责任不可外包，靠"绝不能错清单"划线
状态 → 一套可交付的分路由 + 脱敏审计 + 证据闸门的最小闭环
三问三作答
一图定状态
能交付什么
白纸黑字写
12、作业
12.1 理解题：为什么供应商的准确率分数不能当企业批准名单？
参考答案：它衡量的是公网问答的相对表现，不包含你内部的租户、权限、时点与保密要求。批准名单是授权问题，不是准确率问题。
12.2 实战题：给出一个最小证据闸门的判定条件。
参考答案：命中必须同时具备来源、日期、租户标签；私域命中的 doc_tenant 必须等于请求租户；缺失任一要素即不入答，落入拒答或人工复核。
12.3 排障题：答案里出现其他租户文档，先查什么？
参考答案：先查过滤发生在检索前还是排序后，看日志里 top-k 与 doc_tenant 的先后顺序；再看脱敏是否只在入口做过。不要先调相似度阈值。
12.4 架构判断题：是否可以把私域检索也整体交给外部搜索服务？
参考答案：不建议。私域检索的核心约束是权限与保密，属于事实与责任，不在外部服务的可控范围；可以外购公域能力，私域需自持隔离与审计。
题题有回响
答答有依据
练的是判断
不是背结论
13、思考
回到开头的争议：DeepSeek 把搜索塞进 API，企业 RAG 并没有白建，但必须重建。白建的是"我也能爬网页"这一层，没白建的是权限、隔离、证据和责任。判断一条检索链路能不能外包，只要问一句：答错了，是谁的责任？答不上来的那部分，就是你必须自己写的那几行代码。
搜索可以买
责任买不走
边界先划清
取舍自分明