探索AI联网搜索如何突破上下文长度限制，实现高效信息处理，是当前大模型应用中的关键课题。本文将深入解析其背后策略。

前言

上一篇《大模型联网搜索是怎么回事？一文搞懂AI联网搜索原理》，我们详细介绍了AI联网搜索的基本原理，明确了它并非单纯依赖模型能力，而是一个整合了搜索引擎API、网页解析等工具能力的Agent应用。

文章末尾留下了一个核心问题：LLM存在上下文长度限制。目前主流大模型的上下文窗口在8K到128K之间不等。粗略估算，按1 token对应1个汉字计算，理论上32K的上下文可容纳约3.2万字符，实际使用中已能满足绝大多数场景。但除了应对边界情况，这里更隐藏着一笔经济账——大模型按token计费。因此，在工程产品中处理对话上下文时，核心目标非常明确：在确保完成任务的前提下，使用的token越少越好。

而AI联网搜索产品为了提供更全面、更精准的答案，不仅要理解用户当前查询，还可能需考虑历史提问以及从互联网检索到的大量内容。当这些信息累积起来，很容易超过LLM能处理的上下文长度上限。本文围绕这一难题，结合实验深入探究AI联网搜索产品如何突破LLM上下文限制。

可能的策略与技术

在上一篇文章的评论区，有读者提到可采用摘要技术。确实，面对长文本，首先想到的就是能否通过摘要进行概括。结合我们在AI智能知识库产品研发中的实际经验，以及相关文献查阅，下面总结AI联网搜索产品可能采用的几种策略与技术。

1. 利用更大上下文窗口的模型

最直接的方法，是选用拥有更大上下文窗口的模型作为底层LLM。这样便无需在模型能力受限时“螺蛳壳里做道场”。

当前越来越多模型具备显著增长的上下文长度，例如DeepSeek R1的上下文长度限制已达128K。使用这种长上下文模型，应用产品的发挥空间自然更大，许多用户场景甚至根本不会触及上下文长度超限问题。

2. 联网搜索召回内容限制

其次，在需要联网搜索时，情况与日常检索类似——我们更关心的是除去广告后的第一页内容。AI联网产品也类似，虽然召回结果可能成千上万，但高质量内容通常集中在前TopN返回之内。因此，没必要使用过多搜索引擎召回的内容，合理限制召回数量即可有效控制上下文。

3. 联网搜索召回内容解析并使用摘要

用户提问的相关信息，可能仅存在于检索召回文档的部分片段中。若为了这些片段将全部内容塞入上下文，既不经济，也可能干扰大模型运行。

在研发RAG智能知识库时，我们解析知识文档的做法是：将文档按句读划分为不超过500字的知识片段，每个片段进行向量化。因此，在问答阶段，用户提问的召回以知识片段为维度。

联网搜索产品也同理。搜索引擎API返回检索内容时，通常会包含文档的内容摘要。不同产品实现可能有差异，有些还会通过大模型自行概括网页，生成更详细、更精细的摘要内容。

总之，在此阶段，通过将检索召回的网页文档进行概括总结、压缩生成摘要，能有效减少整体内容大小，显著降低上下文占用。

4. 基于相关性的历史压缩

除了外部互联网召回的内容，用户多轮对话产生的历史信息也会被加入每轮对话的上下文中，这是另一个可能导致上下文超限的重要原因。

基于相关性的历史压缩策略，旨在智能筛选并保留对理解当前问题最有价值的历史片段。并非所有前述对话都与当前问题直接相关。

这种策略的实现通常依赖语义相似度模型。例如，先将用户历史对话的问题传递给大模型，筛选出与当前问题相关的问题，再组合相关的历史对话内容作为上下文，从而压缩无效信息。

5. 多轮信息状态追踪与摘要

在与用户多轮对话过程中，处理的联网搜索召回内容越多，回答也可能越长，后续对话涉及的上下文也会持续增长。

该策略将摘要技术同时应用于历史对话的回答上，将冗长的历史对话浓缩为几句关键信息，保留核心要点，去除不必要细节。这种方法能在保持对话连贯性的同时，极大减少需要处理的文本长度。

6. 动态上下文窗口管理

一些先进的AI联网搜索产品还具备动态调整上下文窗口的能力。系统可根据当前查询的复杂性以及检索到的外部信息量，灵活决定输入给大模型的上下文长度和具体内容。

举例而言，若当前查询非常简单且搜索召回内容很简洁，系统可能选择包含更多历史对话信息；相反，若查询复杂且需引入大量外部信息，系统则可能缩减历史对话长度，优先保留最新用户提问和回答内容。

在研发RAG智能知识库时，我们实现了类似的简化功能：系统默认以FIFO方式淘汰历史对话，保留最多10轮，用户可在运行时自行配置。

使用Coze验证一下

接下来，我们使用Coze搭建一个AI联网搜索产品的Demo，直观观察其运作过程，验证上述策略与技术的具体实现。真正的用户级产品可能更为复杂，但以管窥豹，总能窥见端倪。

使用Coze创建一个工作流如下：

流程节点较多，分开截图展示：

挑选几个重点节点，将具体配置列出，方便感兴趣的读者复现。

1）生成搜索query

该节点根据用户输入判断是否需要进行互联网检索，若需要则生成对应检索query。

系统prompt如下：

用户输入：{{input}} 请根据上面的用户输入问题，判断是否需要进行联网搜索，涉及时效性相关的问题需要进行联网搜索。 需要联网搜索的问题生成对应的检索query，确保这些query能够涵盖相关的基本背景信息、事实依据或其他影响判断的关键信息。

2）搜索材料

该节点是名为“头条搜索”的搜索引擎插件，在添加节点时从插件商店选中该插件。

将上一节点返回的query参数作为入参传递。

该节点为批处理模式，该模式下节点会多次运行，在每次运行中，批处理列表会按照顺序将列表中的一项赋值给批处理变量，直到达到批处理的上限或列表的最大长度。

输入参数里可以通过指定count来确定召回条数。

3）处理输出结果

添加一个代码处理节点，处理一下搜索引擎输出的结果。

代码部分输入：

async def main(args: Args) -> Output:
    params = args.params
    outputList = params['outputList']
    markdown_str = ""
    message_count = 0
    for item in outputList:
        data = item.get('data', {})
        doc_results = data.get('doc_results', [])
        for doc in doc_results:
            sitename = doc.get('sitename', '')
            summary = doc.get('summary', '')
            title = doc.get('title', '')
            url = doc.get('url', '')
            markdown_str += f"##### {title}nn"
            markdown_str += f"**网站**: {sitename}nn"
            markdown_str += f"**摘要**: {summary}nn"
            markdown_str += f"[点击这里查看详情]({url})nnn"
            message_count = message_count + 1
    ret: Output = {
        "markdown_str": markdown_str,
        "message_count": message_count,
    }
    return ret

这部分代码从搜索引擎返回的网页文档中，解析出网站的摘要。此处使用了搜索引擎API自带的摘要，没有再使用网页爬取插件加LLM来整理摘要。

4）生成初步总结

工作流搭建完成，开启debug模式运行一下，查看各节点的处理过程。

输入问题：“字节跳动和腾讯哪个成立时间早？”，运行后打开运行日志：

在搜索引擎节点，可以看到：

大模型首先根据用户提问，生成了两个待查询的query：“字节跳动成立时间”以及“腾讯成立时间”。然后搜索引擎两次调用查询，每次查询返回了10个文档（工作流未设置count，默认返回最优召回10条）。

返回内容中包含了summary字段，该字段即对应网页的摘要部分。在此阶段还可以添加网页爬取节点，将搜索引擎返回的网页链接url字段输入给爬取插件，再将爬取内容交由大模型进行摘要总结。为了降低实验复杂度，我们信任搜索引擎返回的摘要，原理上一致。

搜索展示过程中，可以看到经过处理，搜索内容的摘要被整合成与大模型交互的上下文信息：

搜索引擎访问了20个网页，结果摘要内容的token数大约为3828，而模型的上下文长度限制在12.8万左右。

这里着重展示了联网搜索的内容如何通过摘要技术控制上下文长度，再结合上文提到的其他策略，可在保证正确性的前提下将上下文压缩得更小。

总结

本文基于AI应用研发领域的经验和对AI Agent的深入理解，解析了AI联网产品在检索外部互联网海量信息后，突破大模型对话上下文限制的若干实用办法。

并通过Coze搭建工作流，按照上述策略成功实现了一个AI联网产品的Demo。

当然，工程层面的用户级产品需考虑更多复杂场景，对应实现手段可能更加丰富。如果你有任何想法或疑问，欢迎留言讨论~