Wide Research：超越上下文窗口
星期五, 10月 31
产品
AI 驱动研究的承诺一直很有吸引力:将信息收集和综合的繁琐工作委托给智能系统,从而释放人类认知能力用于更高阶的分析和决策。然而,任何在非平凡用例上推动这些系统的人都遇到了一个令人沮丧的现实:在多主题研究任务中,到第八或第九个项目时,AI 就开始编造内容。
不仅仅是简化。不仅仅是更简洁地总结。而是编造。
这不是提示工程问题。也不是模型能力问题。这是一个架构约束,自 AI 研究工具诞生以来就悄悄限制了其实用性。而这正是 Wide Research 旨在克服的约束。
上下文窗口:一个根本性瓶颈
每个大型语言模型都在上下文窗口内运行,这是一个有限的内存缓冲区,限制了模型在任何给定时刻可以主动处理的信息量。现代模型已经令人印象深刻地推动了这一边界:从 4K tokens 到 32K、128K,甚至最新版本的 1M tokens。
然而问题依然存在。
当你要求 AI 研究多个实体——比如五十家公司、三十篇研究论文或二十个竞争产品——上下文窗口会迅速填满。不仅仅是每个实体的原始信息,还包括:
•原始任务规范和要求
•一致输出格式的结构模板
•每个项目的中间推理和分析
•交叉引用和比较笔记
•所有先前项目的累积上下文
当模型到达第八或第九个项目时,上下文窗口已经承受巨大压力。模型面临一个不可能的选择:明确失败,或开始走捷径。
它总是选择后者。
编造阈值
实践中会发生以下情况:
项目 1-5: 模型进行真实研究。它检索信息,交叉引用来源,并产生详细、准确的分析。
项目 6-8: 质量开始微妙地下降。描述变得稍微更通用。模型开始更多地依赖先前的模式而不是新鲜的研究。
项目 9+: 模型进入编造模式。无法在管理溢出的上下文的同时维持彻底研究的认知负荷,它开始基于统计模式而非实际调查生成听起来合理的内容。
这些编造内容很复杂。它们听起来很权威。它们完美地遵循既定格式。它们通常在语法上无懈可击,在风格上与早期合法条目保持一致。
它们也经常是错误的。
竞争对手分析可能会将功能归因于不提供这些功能的公司。文献综述可能会引用带有编造发现的论文。产品比较可能会捏造定价层级或规格。
阴险的部分是,这些编造内容很难在没有人工验证的情况下检测到——这违背了自动化研究的全部目的。
为什么更大的上下文窗口无法解决这个问题
直观的反应是简单地扩大上下文窗口。如果 32K tokens 不够,就使用 128K。如果还不够,就推到 1M 或更高。
这种方法误解了问题。
首先,上下文衰减不是二元的。 模型不会在其整个上下文窗口中保持完美的回忆。研究表明,检索准确性会随着与当前位置的距离而下降——即"迷失在中间"现象。上下文开头和结尾的信息比中间的信息更可靠地被回忆起来。
其次,处理成本不成比例地增长。 处理 400K token 上下文的成本不仅仅是 200K 成本的两倍——它在时间和计算资源方面呈指数级增长。这使得大规模上下文处理在许多用例中在经济上不切实际。
第三,问题在于认知负荷。 即使有无限的上下文,要求单个模型在数十个独立研究任务中保持一致的质量也会产生认知瓶颈。模型必须在项目之间不断切换上下文,维护比较框架,并确保风格一致性——同时执行核心研究任务。
第四,上下文长度压力。 模型的"耐心"在某种程度上由其训练数据中样本的长度分布决定。然而,当前语言模型的后训练数据混合仍然主要由为聊天机器人式交互设计的相对较短的轨迹主导。因此,当助手消息内容的长度超过某个阈值时,模型自然会经历一种上下文长度压力,促使它加速总结或诉诸于不完整的表达形式,如要点列表。
上下文窗口是一个约束,是的。但它是更深层架构限制的症状:单处理器、顺序范式。
架构转变:并行处理
Wide Research 代表了对 AI 系统应如何处理大规模研究任务的根本性重新思考。我们不是要求一个处理器顺序处理 n 个项目,而是部署 n 个并行子代理同时处理 n 个项目。
Wide Research 架构
当你启动 Wide Research 任务时,系统按如下方式运行:
1. 智能分解
主控制器分析你的请求并将其分解为独立的、可并行化的子任务。这涉及理解任务结构、识别依赖关系并创建连贯的子规范。
2. 子代理委托
对于每个子任务,系统启动一个专用的子代理。至关重要的是,这些不是轻量级进程——它们是功能齐全的 Manus 实例,每个都具有:
•完整的虚拟机环境
•访问完整的工具库(搜索、浏览、代码执行、文件处理)
•独立的互联网连接
•全新的、空的上下文窗口
3. 并行执行
所有子代理同时执行。每个子代理专注于其分配的项目,执行与单项目任务相同深度的研究和分析。
4. 集中协调
主控制器维护监督,在子代理完成工作时收集结果。重要的是,子代理之间不相互通信,所有协调都通过主控制器流动。这可以防止上下文污染并保持独立性。
5. 综合与整合
一旦所有子代理都报告完成,主控制器将结果综合成一个单一的、连贯的、全面的报告。这个综合步骤利用了主控制器的全部上下文容量,因为它没有被原始研究工作所负担。
为什么这改变了一切
规模化的一致质量
每个项目都得到相同的处理。第 50 个项目的研究与第 1 个项目一样彻底。没有退化曲线,没有编造阈值,也没有质量悬崖。
真正的水平可扩展性
需要分析 10 个项目?系统部署 10 个子代理。需要分析 500 个?它部署 500 个。架构随任务大小线性扩展,而不是像基于上下文的方法那样呈指数级扩展。
显著加速
因为子代理并行操作,分析 50 个项目所需的实际时间与分析 5 个项目大致相同。瓶颈从顺序处理时间转移到综合时间——这是整体任务中小得多的组成部分。
降低幻觉率
每个子代理都在其认知舒适区内运行。有了全新的上下文和单一的、集中的任务,就没有编造的压力。子代理可以进行真实研究、验证事实并保持准确性。
独立性和可靠性
因为子代理不共享上下文,一个子代理工作中的错误或幻觉不会传播到其他子代理。每个分析都是独立的,降低了系统性风险。
超越单处理器范式
Wide Research 不仅仅是一个功能——它代表了从单处理器范式向编排的并行架构的根本转变。AI 系统的未来不在于更大的上下文窗口,而在于智能任务分解和并行执行。
我们正在从"AI 助手"时代转向"AI 劳动力"时代。
何时使用 Wide Research: 涉及多个需要一致分析的类似项目的任何任务——竞争研究、文献综述、批量处理、多资产生成。
何时不使用: 每个步骤都严重依赖于先前结果的深度顺序任务,或单处理器处理更具成本效益的小任务(少于 10 个项目)。
Wide Research 面向所有订阅者
从单个 AI 助手到协调的子代理劳动力的架构飞跃现在对所有订阅者开放。这是 AI 驱动研究和分析的新范式。
我们邀请你亲身体验这种差异。带来你的大规模研究挑战——那些你认为 AI 不可能完成的挑战——并见证并行处理方法如何在规模上提供一致的高质量结果。
AI 劳动力时代已经到来。今天就开始你的 Wide Research 任务吧。