深度解析：AI 联网搜索（Search-based RAG）的生产级架构实践

最新推荐文章于 2025-11-23 19:13:18 发布

原创最新推荐文章于 2025-11-23 19:13:18 发布 · 496 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #架构 #langchain #python #后端

agent 专栏收录该内容

10 篇文章

订阅专栏

ModelEngine·创作计划征文活动 10w+人浏览 1.4k人参与

深度解析：AI 联网搜索（Search-based RAG）的生产级架构实践

1. 引言：打破大模型的“知识围墙”

在大语言模型（LLM）的应用开发中，我们经常面临一个核心痛点：模型训练数据的截止时间导致了“知识过时”，且模型无法获取私域或实时的互联网信息。

为了解决这个问题，联网搜索（Online Search） 结合 RAG（检索增强生成） 成为了当前最主流的解决方案。但这不仅仅是简单地调用一下 Google 搜索接口。在生产环境中，如何平衡响应速度、token成本与回答质量，需要一套精密设计的流水线。

本文将基于实际的生产级架构，详细拆解从“用户提问”到“精准回答”的全链路技术实现，并辅以真实场景下的实战案例。

2. 核心架构概览

整个联网搜索流程可以被视为一个漏斗形的筛选与加工系统。由于大模型的上下文窗口（Context Window）和推理成本是有限的，我们不能将互联网上的海量信息全部塞给模型。

我们的架构设计遵循以下原则：广度召回 -> 精度筛选 -> 深度解析 -> 知识增强。

架构流程图

3. 全链路步骤拆解与实战案例

第一阶段：广度检索 (The Wide Net)

目标： 快速获取互联网上的相关线索。

一切始于用户的自然语言提问。系统接收到 Query 后，首先会调用搜索引擎接口（如 Google Custom Search API, Bing Search API, 或 Serper.dev）。
在此阶段，我们关注的不是网页全文，而是搜索引擎返回的元数据快照（Snippets）：

Title：网页标题，用于初步判断相关性。
Snippet：摘要信息，通常包含关键词上下文。
URL：原文链接。

生产实践： 为了保证召回率，我们通常会设定较大的召回窗口，例如获取前 20 条 搜索结果。

【生产实战案例】

假设用户提问：“2025年发布的 iPhone 17 有什么新特性？”
调用 Serper Dev API 返回的 JSON 结构如下：

{
  "organic": [
    {
      "title": "iPhone 17 Rumors: Release Date, Price, and Specs",
      "link": "[https://www.techradar.com/news/iphone-17](https://www.techradar.com/news/iphone-17)",
      "snippet": "Apple represents a major leap forward with the A19 Bionic chip and under-display Face ID..."
    },
    {
      "title": "Buy iPhone 16 - Apple Store",
      "link": "[https://www.apple.com/shop/buy-iphone/iphone-16](https://www.apple.com/shop/buy-iphone/iphone-16)",
      "snippet": "Shop the latest iPhone models..."
    }
    // ... 共20条数据
  ]
}

注意：这里第二条结果虽然来自官网，但标题是购买 iPhone 16，与用户问的 iPhone 17 关联度较低，这为下一阶段的筛选埋下了伏笔。

第二阶段：智能筛选 (Re-ranking & Filtering)

目标： 去伪存真，剔除噪音，降低后续处理成本。

如果直接爬取 20 个网页，不仅耗时（网络IO延迟），还会消耗大量 Token，甚至引入无关信息导致模型幻觉。因此，我们需要引入一个评分机制：

相似度计算：利用轻量级模型或算法，计算“用户问题”与这 20 个结果的“标题+摘要”之间的语义相似度。
Top-N 截断：根据评分排序，只保留最相关的 Top 5。

这一步是系统性能的关键分水岭，确保后续昂贵的算力只用于最有价值的信息源。

【生产实战案例】

在生产中，通常使用 Cross-Encoder 模型（如 BAAI/bge-reranker-base 或 Cohere Rerank API）进行精细打分，而不是简单的向量余弦相似度。

输入对：

Query: “2025年发布的 iPhone 17 有什么新特性？”
Candidate A: “iPhone 17 Rumors: Release Date…” (得分: 0.92) -> 保留
Candidate B: “Buy iPhone 16 - Apple Store…” (得分: 0.15) -> 剔除

代码逻辑示意 (Python)：

from sentence_transformers import CrossEncoder
model = CrossEncoder('cross-encoder/ms-marco-MiniLM-L-6-v2')

query = "iPhone 17 features"
passages = [res['title'] + " " + res['snippet'] for res in search_results]
scores = model.predict([(query, p) for p in passages])

# 仅保留 Score > 0.7 的 Top 5 URL 进入下一阶段

第三阶段：深度爬取与数据清洗 (Deep Crawling & ETL)

目标： 将非结构化的网页转化为模型可读的高质量文本。

拿到优选的 Top 5 URL 后，系统启动并发爬虫任务。这里不仅是简单的 HTTP 请求，更包含复杂的数据工程（Data Engineering）：

正文提取：去除广告、导航栏、版权声明等噪音。
格式转换：将 HTML DOM 树转换为大模型最友好的 Markdown 格式。Markdown 的标题层级结构能很好地保留原文的逻辑关系。
数据封装：最终形成结构化的 Key-Value 对，Key 为 URL，Value 为清洗后的 Markdown 内容。

【生产实战案例】

在这一步，常用的生产级工具是 Python 的 Trafilatura 库或 Jina Reader API，它们能高效地将混乱的 HTML 转化为干净的 Markdown。

原始 HTML (混乱)：

<div class="ad-banner">Buy Now!</div>
<nav>Home > Tech > Mobile</nav>
<h1>iPhone 17 Leaks</h1>
<p class="content">The new device is expected to feature...</p>

清洗后的 Markdown (干净)：

# iPhone 17 Leaks

The new device is expected to feature...

这大大减少了 Token 消耗，因为我们丢弃了大概 60% 的无用 HTML 标签代码。

第四阶段：RAG 增强与生成 (RAG & Generation)

目标： 基于事实进行回答。

这是最后且最关键的一步。虽然我们拥有了 5 篇高质量文档，但直接将它们全部放入 Prompt 可能会超出上下文限制。因此，我们再次引入标准的 RAG 流程：

切片（Chunking）：将 Markdown 文档按语义或字符数切割成小块。
入库（Storage）：将切片向量化后存入存储引擎（向量数据库）。
精准检索：拿着用户的问题，在存储引擎中进行最后一次高精度检索，找到包含答案的那几段具体文字。
增强生成：将这些精准的“知识片段”作为上下文（Context）喂给大模型，指令模型“基于上述信息回答用户问题”。

【生产实战案例】

使用 LangChain 的 RecursiveCharacterTextSplitter 进行智能切分。

配置策略：

Chunk Size: 500 tokens (适合承载一个完整的知识点)
Chunk Overlap: 50 tokens (保持上下文连贯性)

Prompt 组装示例：

你是一个智能助手。请基于以下上下文回答用户的问题。如果上下文中没有答案，请直接说不知道。

---上下文开始---
[来源: techradar.com]
iPhone 17 预计将搭载 A19 芯片...

[来源: macrumors.com]
新的显示屏下 Face ID 技术将首次亮相...
---上下文结束---

用户问题：iPhone 17 有什么新特性？