（本文转载，原文为架构演练，不含线上事故或性能数据，原文链接见文末。）
DeepSeek 在 10 月开放的 Search 与 Fetch 两个 API，给联网搜索类应用提供了两件明确的工具：前者按查询返回结构化网页结果，后者把单个网页取成 Markdown。很多应用把这两步揉成一句「模型上网了」，结果出了错不好查：搜索找到了页面，抓取失败；抓取拿到正文，关键段落被截断；模型给了结论，却没有引用原始出处。
文章设计了一个具体场景：客服问「某个 API 版本最近有哪些变化」。系统要优先找官方更新日志，再找技术社区的迁移经验；不能仅凭摘要里一句话就宣布「已支持」，也不能把转载文章当成官方规格。检索、读取和回答分开记录，才能解释错误发生在哪一步。
一、一条查询留下三份证据
Search 返回的 title、url、snippet、summary、日期和排序信息，用来筛候选；Fetch 返回的正文，用来查原句；最终回答要指向与结论直接相关的 URL。三步各有各的证据，缺一份就没法复盘。
两个边界要写死：检索结果为空，就记录「未找到」，不要让模型补一个看起来真实的网页；Fetch 被 403 或 404 拒绝，就换可访问的原始文档，不能把搜索摘要冒充成已读全文。
建议每次提问留一条脱敏记录：question_id、原始问题、查询词、结果 URL、抓取状态、所用片段、最终引用 URL、回答时间。文档版本变了，答案要能回溯到当时那个页面。对「当前价格」「模型是否退役」这类会变的事实，回答里要显示核对日期，旧快照不能当成现在的报价。
二、控制上下文，而不是把十篇全文塞进去
搜索结果的排序不等于可信度。可以先按来源分层：官方规格、项目仓库、维护者讨论、第三方教程。每条候选只抓真正需要的页面，按段落挑能支持问题的片段，并保留段落出处。模型最终回答混合了多篇材料时，每个重要结论附近都要标出依据，没有出处的判断单独写成推断。
一个常见的失败分支：同一个页面里「旧版本不支持」和「新版本支持」各有一节，摘要只截到后者。系统没存发布时间和版本号，模型就可能把新能力套到旧客户端上。处理办法不是加一句「请谨慎」，而是把版本写进检索条件，再用官方文档的适用范围交叉核对。
还有一种失败是「URL 存在，但正文和问题无关」。可以把每条引用分成三类：直接支持结论、只提供背景、与结论相反。只有第一类放到关键判断附近，其他在解释里说明作用。引用条数多不等于可靠，一条精准的官方更新说明，比三条互相转述的目录页更能帮读者复核。
三、搜索费用和模型费用分开记账
按官方 Search/Fetch 指南 2026-11-10 的口径：两种接口分别按成功请求计费，不按返回条数；返回空搜索结果、失败或超时，不计这项成功请求。模型生成另有自己的 token 用量。
一次用户提问可能触发一次 Search、两次 Fetch、数次模型请求，所以账本至少分三行。重试也要记录，否则「模型太贵」的结论可能只是掩盖了重复抓取。
两个工具还有各自的账户级 QPS 边界，Fetch 另按域名限制。公开文档该缓存就缓存，尊重站点访问规则，别让多个 worker 同时抓同一页；收到 429 先看是哪个工具、哪条限制，再按规则退避，不要把模型请求的并发限制套到网页抓取上。
生产监控也要按这两层拆：Search 空结果率、Fetch 失败率、模型无引用回答率，分别统计。如果只有一个「用户说答案错了」的指标，很难判断该修查询词、抓取器还是提示词。
四、上线前先跑一个固定测试集
文章建议准备八个问题：五个能在官方文档找到答案，两个只能在项目仓库找到答案，一个故意没有公开答案。每题先标好允许的证据 URL 和判定条件。最后一题应该明确回答「没有足够资料」，而不是为了凑完整答案，引用一篇相似但不相关的旧文章。
测试集最好保留题目版本。资料变更后更新答案，不能悄悄改判定标准，让系统永远满分。
Search 和 Fetch 是两个工具，模型引用是第三步，不是同一步。把这三步分开记录、分开监控、分开计费，出错时才知道该修哪一段。
本文转载自腾讯云开发者社区 《给知识库接入实时搜索时，别把 Search、Fetch 和模型引用算成同一步》，原文链接：https://cloud.tencent.com.cn/developer/article/2780549。版权归原作者所有，如需删除请联系我们。