开源项目阅读
deep-searcher
github: https://github.com/zilliztech/deep-searcher
架构大图
代码走读
- 文档进行切割，递归切割（不同的文档，对应不同的策略，pdf urls）
- 将切割后的文件，存储到向量库
将用户的query，讲给RAG_Router，RAGROuter 下面挂了两个Agent
- This agent is suitable for handling general and simple queries, such as given a topic and then writing a report, survey, or article.
- This agent can decompose complex queries and gradually find the fact information of sub-queries. It is very suitable for handling concrete factual queries and multi-hop questions.
- rag router 返回选择哪个agent
- agent将用户的query，进行拆解，使用llm，返回sub query
- 使用拆解后的sub query，去进行rag召回
- 如果没有达到最大的迭代次数，则将用户的原始query和sub query 及召回的chunk，一起交给llm，判断是否有缺失/可以补充的query
- 如果没有新增的sub query，则直接退出，如果有的话，则重复6-7步骤，知道达到max_iter
- 使用LLM，将sub query 和 召回的文档，均返回给LLM，生成最终答案
问题梳理
优点
缺点
- RAG索引构建前置了，导致数据范围被限制了，严重依赖用户的输入和知识库的内容
- 召回的内容，没有审查，且向量化模型+milvus的准确率不高，交给LLM的数据质量不能保证，容易garbage in,garbage out
- 用户无法介入和调整，且没有对规划进行审查，严重依赖LLM自身的能力边界，最终结果的质量容易受影响
- 生成的研究报告，比较依赖LLM的输出限制，测试了几次，输出的研究报告都是1000字左右
open_deep_research
github: https://github.com/langchain-ai/open_deep_research
架构大图
代码走读
- 用户输入一个 topic
report结构生成逻辑
- 调用llm，开始去生成跟这个topic相关的query，query数量可自定义，以支持更好的补充报告的结构
- 拿到query后，调用搜索api去进行搜索
使用搜索到的结果，开始调用llm，去生成报告的结构，每个结构的包含以下内容，这里使用了推理模型
- Name - Name for this section of the report. - Description - Brief overview of the main topics covered in this section. - Research - Whether to perform web research for this section of the report. IMPORTANT: Main body sections (not intro/conclusion) MUST have Research=True. A report must have AT LEAST 2-3 sections with Research=True to be useful. - Content - The content of the section, which you will leave blank for now.
- 结构化输出后，进入feedback模块
开始进入用户反馈环节
- 用户如果输入true，则认可前面给出的报告结构，则继续执行
- 如果用户输入的非true，则是反馈的内容，重复执行第二步，并将反馈的内容填充进去
开始构建每个段落结构的内容
- 使用llm，为当前段落的构建，提出来几个问题
- 根据llm输出的问题，去调用搜索工具进行搜索
- 根据搜索出来的结果，组装prompt，开始去构建当前段落的内容
- 根据上面输出的内容，交给审查llm进行审查，如果审查llm认可内容，则输出pass即可，如果不认可，则继续提出几个问题
- 如果审查没有通过的话，则跳转到b重新执行，否则，当前段落输出结束
- 开始构建 Introduction 和 Conclusion 段落的内容
- 最后整合所有的内容，输出完整的报告
问题梳理
优点
- 规划与执行分离，不同的模型，做不同的模块内容
- 用户反馈，补充LLM的思考不完善、LLM的幻觉问题等
- 反思审查模块：通过LLM审查内容及段落的相关性，提出问题，来进一步完善内容的质量和完备性
- 分段书写，可以提高报告的字数和完整性
- 搜索这里，不仅仅只是搜索出来结果，还使用了llm来对内容进行总结，可以进一步过滤无效信息
缺点
- 每个段落，可以添加一下段落内容预期summary，进一步提高各个段落的相关性
shandu
github: https://github.com/jolovicdev/shandu
架构大图
代码走读
- 用户输入一个topic
针对用户的topic，生成一个研究计划
- 研究目标：3-5个
- 关键研究section：4-6个
- 研究方法：研究的具体方法，信息来源和分析方法
- 预期成果：3-5个交付物
- 基于上述，组成一个具体的研究计划
- 根据用户输入的topic和上面生成的研究计划，生成sub query，sub query的数量由用户自定义
根据sub query，开始进行搜索，并整理搜索结果
- 使用google sucksuckgo wiki进行搜索
- 使用llm判断，每条搜索结果，跟用户的query是否有关，无关则过滤掉
- 根据不同来源的搜索结果的来源url进行排序，选择前8个，提高搜索效率和聚焦最相关的url
- 开始抓取这8个url的内容
对每个抓取成功url，对页面内容进行评估，并给出评级和理由
- 信息来源的可信度与专业性
- 证据质量
- 与已知事实的一致性
- 发布日期的新近度
- 是否包含引用或参考文献
- 根据抓取的结果，进一步分析，给出来key finding和核心主题，并优化生成分析报告，并给出相关性和可靠度
- 根据用户设置的迭代次数，来判断是否需要继续，如果继续的话，则开始反思上面的搜索结果和报告
- 根据初始的报告计划和根据sub query搜索生成的分析结果，反思一下核心发现、尚未解决的问题和后续研究步骤，重复执行第四步
完成反思和搜索之后，如果来源url大于25个，则进一步聚焦核心来源url，否则就直接返回了
- 每个搜索结果组装成 url/title/summary/date的格式
- 交给LLM返回15-20个llm认为最有价值的url
将得到的urls及内容，格式化为研究报告的标准编号引用格式，eg
- [1] _techreview.com_，"GPU架构新进展"，2024-01-15，https://techreview.com/articles/gpu-advances
生成第一版研究报告
- 使用llm，生成报告标题
- 提取这个报告的关键主题，每个主题为一个独立的章节，并输出这个章节主题要包含的内容要点
- 格式化引用的内容
- 使用llm，输出一份全面且详细的研究报告，至少5000字以上
针对第一版的报告，对每个章节进一步优化
- 对核心概念进行更详细的阐释
- 扩充案例研究和实例说明
- 加强研究发现的分析与解读
- 优化章节内部的行文连贯性
- 补充相关统计数据、数据点或证据
- 确保全文使用正确的引用格式
- 保持科学准确性和信息时效性
选择3个章节，进一步扩展深度和细化内容
- 在保证准确性的前提下，将该部分内容扩展至三倍长度
- 添加具体案例、研究实例或数据点来支持论点
- 补充相关背景信息和上下文
- 增加细节说明、注意事项和替代观点
- 全文使用标准引用格式
- 保持现有结构，必要时可增加子章节
- 确保所有信息截至{current_date}准确有效
- 最后，格式化输出完整的报告
问题梳理
优点
- 对搜索结果逐一进行评判，降低了垃圾数据对llm的幻觉影响
- 真的详细，相对于其他产品，考虑的细节很多，包括对搜索结果的审查，对章节内容的补充完善，对报告的关键点定义
缺点
- 代码无法运行，无法看最终效果
deer-flow
github: https://github.com/bytedance/deer-flow
架构大图
代码走读
首先用户的topic，会交给coordinator这个角色处理，主要职责是，如果coordinator认为自己获取到足够的信息，且这个topic可以调研的话，则判断是否开启先搜索后plan，开启的话，跳转到搜索，否则跳转到plan模块
- 礼貌拒绝不当或有害的请求（如提示词泄露、生成有害内容）
- 需要时与用户沟通以获取足够的上下文
- 将所有研究问题、事实查询和信息请求转交给规划助手
- 调用搜索api，搜索跟topic相关的内容，接下来交给planner
- 开始使用planner进行规划，llm需要思考当前收集的数据是否足够支撑完整的报告，输出格式如下，这里可以由用户显式设置最大迭代次数
interface Step {
need_search: boolean; // Must be explicitly set for each step
title: string;
description: string; // Specify exactly what data to collect. If the user input contains a link, please retain the full Markdown format when necessary.
step_type: "research" | "processing"; // Indicates the nature of the step
}
interface Plan {
locale: string; // e.g. "en-US" or "zh-CN", based on the user's language or specific request
has_enough_context: boolean;
thought: string;
title: string;
steps: Step[]; // Research & Processing steps to get more context
}根据planner的输出，交给用户进行反馈
- 如果反馈认可的话，则直接执行
- 用户的topic，会交给coordinator这个角色处如果反馈不通过的话，则将用户的反馈，交给planner，重新制定计划
- 构建agent，对planner的每个step，如果需要搜索的话，则进行搜索，并使用crawel转成markdown格式，并给出每个step的结果
- 循环3-5步骤，知道超出用户设置的最大迭代次数
- 最后调用llm，生成报告
问题梳理
优点
- 引入了反馈机制，来降低LLM规划中的偏颇
- 引入了实时搜索，来提高LLM的知识库能力边界
缺点
- 搜索的内容，没有审查，且内容直接填充，会导致prompt爆炸
- 生成的研究报告，比较依赖LLM的输出限制，官方给出的示例和测试的示例，均显示最终报告的内容比较简单，字数比较少
项目对比
优缺点对比
| 项目 | 优点 | 缺点 |
|---|---|---|
| deep-searcher | 1. 引入RAG的能力，可以针对企业内部用户使用 | 1. RAG索引构建前置了，导致数据范围被限制了，严重依赖用户的输入和知识库的内容<br/>2. 召回的内容，没有审查，且向量化模型+milvus的准确率不高，交给LLM的数据质量不能保证，容易garbage in,garbage out<br/>3. 用户无法介入和调整，且没有对规划进行审查，严重依赖LLM自身的能力边界，最终结果的质量容易受影响<br/>4. 生成的研究报告，比较依赖LLM的输出限制，测试了几次，输出的研究报告都是1000字左右 |
| open_deep_reseach | 1. 规划与执行分离，不同的模型，做不同的模块内容<br/>2. 用户反馈，补充LLM的思考不完善、LLM的幻觉问题等<br/>3. 反思审查模块：通过LLM审查内容及段落的相关性，提出问题，来进一步完善内容的质量和完备性<br/>4. 分段书写，可以提高报告的字数和完整性<br/>5. 搜索这里，不仅仅只是搜索出来结果，还使用了llm来对内容进行总结，可以进一步过滤无效信息 | 1. 每个段落，可以添加一下段落内容预期summary，进一步提高各个段落的相关性 |
| shandu | 1. 对搜索结果逐一进行评判，降低了垃圾数据对llm的幻觉影响<br/>2. 真的详细，相对于其他产品，考虑的细节很多，包括对搜索结果的审查，对章节内容的补充完善，对报告的关键点定义<br/>3. 在每个章节，进一步增加例子和demo | 1. 代码无法运行，无法看最终效果 |
| deer-flow | 1. 引入了反馈机制，来降低LLM规划中的偏颇 | 1. 搜索的内容，没有审查，且内容直接填充，会导致prompt爆炸<br/>2. 生成的研究报告，比较依赖LLM的输出限制，官方给出的示例和测试的示例，均显示最终报告的内容比较简单，字数比较少 |
特性对比
| 项目/特性 | deep-searcher | open_deep_research | shandu | deer-flow |
|---|---|---|---|---|
| 基本框架 | 单智能体 | langgraph | langgraph | langgraph |
| 规划能力 | 无 | 有 | 有 | 无 |
| 反思能力 | 有 | 有 | 有 | 有 |
| 审查机制 | 无 | 有，章节内容审查 | 有，章节内容/搜索结果均有审查 | 无 |
| 实时搜索 | 无 | 有 | 有 | 有 |
| 人工确认 | 无 | 有 | 无 | 有 |
| 生成内容完善度 | 低 | 丰富 | 丰富 | 低 |
| 成本和效率 | 低 | 较高 | 高 | 低 |
基准测试
| 项目 | GAIA准确率 | BrowseComp准确率 | 人类终极考试 (HLE) | 多跳问答表现 |
|---|---|---|---|---|
| deep-searcher | 48.2% | 未公开 | 未公开 | HotpotQA 72.1% |
| open_deep_research | 55.0% (开源最佳) | 未公开 | 未公开 | 自研测试集 84.3% |
| shandu | 未公开 | 未公开 | 未公开 | 未公开 |
| deer-flow | 未公开 | 未公开 | 未公开 | 企业数据 75.8% |
DeepResearch架构设计构思
注：本设计是基于自己的理解和借鉴上述开源框架的思想而来，暂未实现，具体效果未知
在这个设计里，分为了四个模块
搜索模块：
对于大纲的聚合搜索：主要目的是根据搜索，来判断这个研究报告要包含哪些主题
- RAG：这里默认文档是基于图结构存储的，所以RAG会根据相关内容召回实体及关系
搜索：
- 如果条件允许，那么我们可以限定搜索范围，类似于官网、wiki、arxiv等比较权威的网站，eg: 对于MCP介绍的研究报告，基本上对MCP官网抓取即可
- 在限定范围，我们开始进行搜索，搜索结果主要是url title 和 description，这里需要评估这些信息够不够，如果不够的话，则可以进一步抓取网页内容
- 将上一步抓取的到内容，交给LLM评审，从若干维度（相关性、权威性等），进一筛选，保留5-10个页面和主题
- 将保留的页面，构建出来图关系，交给LLM
- LLM基于构建的图信息，生成LLM的大纲和关键主题
- 下一步，LLM审查，当前这个研究报告的大纲，是否符合主题及要求，如果审查不通过，则LLM提出sub query，重复上述步骤
- 注：对于迭代搜索，要过滤掉相同的url，同时对于前后的搜索结果，进一步补充这个图
对于段落内容的主题搜索：主要目的是搜索出来这个主题下的具体信息，用于LLM输出段落内容
- RAG：这里默认文档是基于图结构存储的，所以RAG会根据相关内容召回实体及关系，以及实体、关系对应的chunk，以便于内容编写
搜索：这里搜索跟上述搜索的主要区别是，在于增加了对抓取的网页内容的压缩
- 如果条件允许，那么我们可以限定搜索范围，类似于官网、wiki、arxiv等比较权威的网站，eg: 对于MCP介绍的研究报告，基本上对MCP官网抓取即可
- 在限定范围，我们开始进行搜索，搜索结果主要是url title 和 description，这里需要评估这些信息够不够，如果不够的话，则可以进一步抓取网页内容
- 将上一步搜索的到内容，交给LLM评审，从若干维度（相关性、权威性等），进一筛选，保留5-10个页面和主题
- 将保留的页面，使用爬虫进一步抓取网页内容，并让LLM对网页内容进行总结，大约300-500字
- LLM基于抓取的网页和生成的总结内容，开始编写当前段落的具体内容
- 下一步，LLM审查，当前这个研究报告的当前段落内容，是否符合主题及要求，如果审查不通过，则LLM提出sub query，重复上述步骤（这里LLM可以拿到其他段落的大纲，以提高段落内容的平滑过渡）
- 注：对于迭代搜索，要过滤掉相同的url
反馈模块：通过每个模块的score，计算出来一个最终的score
- 数据相关性模块：主要检测，给定的内容和topic/section的相关性，并给出一个score
- 数据权威性审查：主要是对搜索的网站的权威性判断，官网 > 学术性网站 > github等
- 数据时间相关性审查：搜索的网页，与当前时间的差距，时间越远，则认为相关性越差
- 其他方面的审查：可逐步补充
规划模块：这个模块主要是为了编写跟topic相关的研究报告的大纲，这里以推理模型为主
- 规划模块主要是sub query 的迭代，循环进行搜索，来获取更多的内容，这里允许设置最大迭代次数
段落编写模块：这个模块主要是为了编写段落具体的内容，对搜索的内容要保持高度的遵从，降低幻觉，这里以Chat模型为主
- 规划模块主要是sub query 的迭代，循环进行搜索，来获取更多的内容，这里允许设置最大迭代次数
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。