最近正好在给客户做一个 AI 联网搜索的项目，给他们出技术方案调研及报价信息，趁着这个时间顺带把秘塔、博查这些比较热门的产品也扒了一遍。发现网上讲"AI 搜索架构"的文章大多停留在画个框图的层面—查询理解、检索、生成，谁都知道要这三步，但真要落地会发现每一步都有一堆坑。所以总结了这篇文章，想把这些细节和权衡写清楚，包括踩过的一些误区。

先说清楚定义，免得后面混淆。AI 联网搜索不是"大模型 + 搜索引擎"这么简单的拼接，它要解决的核心问题是：

大模型的知识是静态的、截止在某个训练时间点的，而用户的问题经常需要实时信息

比如问"今天北京天气怎么样"，模型本身答不了；问"这家公司最新的财报数据"，模型的知识可能已经过时半年。联网搜索要做的，是让模型在回答前先"查一下"，把查到的信息作为上下文喂给它，再让它生成答案。

这个思路听起来简单，但工程实现上大概分五个环节，缺一不可：

第一步：查询理解，别小看这一步

很多团队做联网搜索，第一版直接把用户问题原样丢给搜索引擎 API，然后把搜索结果拼进 prompt。这样能跑，但效果差得离谱，原因是用户的自然语言提问和搜索引擎期望的关键词查询是两种语言。

举个例子，用户问"我上个月买的那只股票现在怎么样了"，这句话里"上个月买的那只股票"是什么模型根本不知道（除非有上下文记忆），直接拿这句话去搜必然搜不到有用信息。

不是所有问题都需要联网。"帮我写一首诗""Python 怎么反转字符串"这类问题，联网反而是浪费时间和 API 成本。判断逻辑一般有两条路：

实际项目里我们两个都用——规则先过一遍明显不需要联网的（代码、创作类问题），剩下的交给模型判断，这样能把无效搜索砍掉六成以上。

查询改写：把人话变成搜索引擎能懂的话

这一步说白了就是让 LLM 做一次 prompt 转换，把对话式提问改写成搜索引擎友好的关键词组合。这里有几个容易被忽略的细节：

查询分解：复杂问题拆成子问题

"对比一下 A 公司和 B 公司过去三年的营收增长率"这种问题，单次搜索基本搜不出完整答案，得拆成"A 公司营收 2023-2025""B 公司营收 2023-2025"两次独立搜索，再把结果合并对比。

这一步秘塔做得比较好，他们的深度研究模式本质上就是把一个大问题拆解成一棵子问题树，每个叶子节点单独搜索，最后汇总。实现上不复杂，用 LLM 做一次 planning，输出结构化的子查询列表就行，难点在于怎么判断"拆到什么粒度算够"，拆太细会导致搜索次数爆炸、成本上升，拆太粗又达不到深度分析的效果。我们的经验是设置一个最大子查询数（比如 5 个），让模型自己在这个约束下决定怎么拆。

第二步：搜索召回，选型比想象中复杂

这一层看起来是"调个 API"的体力活，但实际选型要考虑成本、覆盖率、合规三个维度。

国内可用的选择不多，主流是这几个：

我们给客户的建议一般是：预算够、追求稳定性，用 Bing API；预算有限、想快速验证，用 Tavily 这类聚合 API 先跑通，后续量大了再自建。

通用搜索引擎对新闻时效性、学术文献深度这些场景覆盖并不好。比如学术搜索，直接搜百度找到的东西质量很一般，得接 arXiv API、Semantic Scholar API 这类专用源。新闻类问题接主流新闻聚合 API 效果会明显好于通用搜索。

这里的工程实现思路是做一个"搜索源路由"：查询理解阶段判断问题类型（新闻/学术/通用/实时数据），路由到不同的搜索源，再合并结果。多花一层判断逻辑，但召回质量提升很明显。

如果 API 覆盖不了目标网站（比如客户要求搜索企业内部指定的一批网站），可能要自己写爬虫。这里提醒几点：

第三步：内容处理，最容易被低估的环节

搜索 API 返回的往往只是标题+摘要，摘要通常一两百字，信息量有限。要拿到完整、干净的正文，得自己抓取网页并解析——这一步做得好不好，直接决定了最终答案的质量。

HTML 转纯文本这件事，正则表达式基本处理不了，因为不同网站的 DOM 结构千差万别。实用的方案是：

我们线上跑的做法是：Trafilatura 做主力，解析失败或内容质量太差（正文字数低于阈值）时 fallback 到 Jina Reader，这样兼顾了成本和覆盖率。

分块和检索：不是无脑切段就完事

抓回来的网页正文可能有几千字，直接全塞进 prompt 会浪费上下文窗口，还容易让模型注意力分散。标准做法是切块（chunk）+ 向量检索，只挑和用户问题最相关的几段。

切块大小和重叠区间的选择直接影响检索效果

。切得太碎（比如按句子切），语义信息不完整，模型理解不了上下文；切得太大，检索粒度不够精细，容易把无关内容也带进去。我们实践下来，中文场景 300-500 字一个 chunk、chunk 之间留 50-100 字重叠，效果比较均衡，但这个数值没有放之四海皆准的答案，得根据实际网页内容特点调。

向量模型的选择上，国产开源模型（BGE、GTE 系列）对中文语义的理解已经不输 OpenAI 的 Embedding API，而且可以本地部署，省了调用成本和网络延迟，中文场景我个人更推荐用 BGE。向量数据库用 Qdrant 或者轻量场景直接用 FAISS 都行，没必要一上来就上 Milvus 这种重量级方案，除非数据规模已经到了单机存不下的程度。

多模态处理：按需加，别为了炫技加

图片 OCR、视频转录这些能力技术上都不难实现（OCR 用现成模型，转录用 Whisper），但这两个功能会显著拉长响应时间和增加成本。除非客户明确有这个场景需求（比如搜索结果里经常出现图表类信息），否则第一期不建议做，容易变成"为了功能而功能"。

第四步：生成，重点是让模型讲实话

内容检索到手之后，剩下的就是让 LLM 基于这些信息生成答案。这一步大家容易觉得"不就是拼个 prompt 吗"，但实际上有几个细节决定了答案质量和可信度。

只基于提供的搜索结果回答，不要用自己的训练知识去补充或编造

。这句话说起来简单，但模型天然有"脑补"的倾向，尤其是搜索结果信息不全的时候。实践中有效的做法：

这几条做好之后，幻觉率能压下去不少，但没法完全消除，这是当前 LLM 的固有局限，不用指望靠 prompt 工程彻底解决。

博查的一个卖点是支持在 GPT-4、Claude、通义千问、Kimi 之间切换。这个能力实现起来不难（无非是统一接口封装），但真正的价值在于

比如中文场景下，通义千问、DeepSeek 这类国产模型对中文语境的理解经常不输 GPT-4，价格却便宜一个量级；需要处理长文档综合分析的场景，Claude 的长上下文能力和逻辑推理更稳；纯粹追求速度和成本的简单问答，用小参数模型（甚至不联网直接答）就够了。做一个简单的路由策略，能在保证效果的前提下把整体成本压下来不少，这个是我们给客户的成本优化建议里最容易落地见效的一条。

流式输出：用户体验的隐形门槛

联网搜索天然比普通对话慢（多了搜索和内容处理的耗时），如果不做流式输出，用户盯着一个转圈的 loading 等 5-8 秒会觉得系统很卡。用 SSE 把生成过程实时推给前端，哪怕总耗时没变，体感会好很多。这个工程量不大，但很多 MVP 版本图省事跳过了，上线后被用户吐槽最多的就是这块。

第五步：呈现，别小看 UI 这一层的技术含量

答案生成完之后，怎么呈现给用户，直接影响产品的"专业感"。

来源卡片这个东西看着简单（标题+摘要+favicon），但要做得好得处理不少边缘情况：网页没有 favicon 怎么办、标题里有恶意脚本注入怎么防、图片加载失败怎么降级。这些细节积累起来，才是产品体验和 demo 版本的差距所在。

思维导图这类可视化功能，秘塔做得比较早也比较有代表性。技术实现上，先让 LLM 把搜索结果的层级关系提炼成结构化 JSON（比如父子节点关系），再用 D3.js 或 Mermaid 渲染成图。这里的难点不在渲染，在于让模型稳定输出格式正确的结构化数据——建议用 JSON Schema 约束输出格式，配合重试机制，不然模型偶尔会输出不合法的结构导致渲染失败。

架构讲完了，聊几个我们在实际项目里踩过、但很少有文章会提的坑。

成本是个无底洞，得提前算清楚

。一次完整的联网搜索问答，可能包含：1 次意图判断（LLM 调用）+ 1 次查询改写（LLM 调用）+ 1 次搜索 API 调用 + 5-10 次网页抓取解析 + 1 次向量化检索 + 1 次最终生成（LLM 调用，这次输入通常很长因为塞了检索到的上下文）。算下来一次问答可能要调 3-4 次 LLM，输入 token 因为塞了搜索结果经常上万。如果不做好缓存和成本控制，量一上来账单会很难看。缓存策略上，简单问题的搜索结果按小时级缓存、复杂问题按天级缓存，能省下相当一部分重复调用的成本。

响应时间是硬指标，但很难同时兼顾速度和深度

。用户能接受简单问答 2-3 秒出结果，但深度研究模式如果做多轮搜索+综合分析，跑到 30 秒以上很正常。这两种模式的产品预期完全不同，做产品设计的时候一定要让用户提前知道自己选的是"快速模式"还是"深度模式"，别让系统在后台默默跑很久用户却以为卡死了。

。前面提过 prompt 层面能缓解，但做不到根治。如果客户对准确性要求特别高（比如金融、医疗场景），得再加一层事实核验——对关键结论做多源交叉验证，标注可信度等级，而不是简单地信任模型输出。这一层会显著增加系统复杂度和成本，需要提前和客户对齐预期，别把"消除幻觉"当成一个可以拍胸脯承诺的功能点。

私有化部署和公网服务的架构差异很大

。很多方案设计的时候是按纯 SaaS 场景想的，等客户提出要私有化部署才发现，搜索 API 这类外部依赖在内网环境根本调不通——企业内网大概率访问不了 Bing API、也访问不了公开的 LLM API。私有化场景要么额外开一条出网白名单通道，要么整个搜索环节换成企业内部可控的数据源+私有化部署的模型，这是两种完全不同的技术方案，最好在方案设计阶段就问清楚客户的部署环境要求，别等开发到一半才发现地基不对。

多租户和权限隔离容易被一期忽略，二期改造成本很高

。如果最终要做企业知识库混合搜索（内部文档+公网搜索合并呈现），权限模型从一开始就要设计好——不同用户能看到的内部文档范围不同，这个逻辑如果不是在检索层就做好隔离，很容易出现"用户搜到了不该看到的内部信息"这种安全事故。建议第一期哪怕功能简单，权限设计的骨架也要搭对，后续加功能才不至于推倒重来。

AI 联网搜索这套系统，单看每个模块技术上都不新—爬虫、向量检索、Prompt Engineering 都是成熟技术，真正的难点在于把这些模块拼接起来之后，怎么处理好速度、成本、准确率三者的平衡，以及各种边缘情况的兜底。秘塔、博查这些产品能做起来，靠的也不是某个模块的黑科技，而是在无数细节上的持续打磨。如果要自己从头搭一套，建议先跑通一个简化版 MVP（单一搜索源+单模型+基础生成），把流程走顺，再逐层往上叠加深度研究、多模型调度、企业知识库这些高级能力，一步到位的复杂方案，往往是踩坑最多的那种。

AI 联网搜索：架构拆解与实现细节

AI 联网搜索并非简单的"大模型+搜索引擎"拼接，而是要解决大模型知识静态、无法覆盖实时信息的核心问题。单个模块的技术都不新，难点在于把速度、成本、准确率的平衡做好。

人工智能

架构设计

算法

AI联网搜索技术详解：从查询理解到内容生成全流程解析，揭秘大模型实时搜索的5大核心环节与落地难点。涵盖查询改写、多源搜索、内容处理、生成优化等关键技术，分享实际项目中的成本控制、响应时间优化及私有化部署经验，助力企业构建高效AI搜索系统。

向量数据库

结构化数据

数据接口

网络延迟

数据库

DeepSeek

路由

Python

JSON

SaaS

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

AI 联网搜索：架构拆解与实现细节

AI 联网搜索：架构拆解与实现细节

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐