improve-suggestion1.0

[siri666942]

我刚看了下readme.md,还没看代码,我觉得有几个优化的点;

1 信息源是一个很重要的东西,比如我问模型训练技术,我个人期望的优质信息原可能是arxiv,而一个通用的信息源可能比较低效且烧token;
假如我问memory的问题,我可能希望你搜GitHub开源项目;
网站级别的根据问题个性化查找而非web search将信息源交给搜索引擎可能会好点;

2 benchmark;
关于一个回答好不好,实际上这很难看出,人自己读很难辨别且费时间不利于快速迭代;
所以正好可以研究一下学界如何定义模型回答好坏这么一个模糊的主观问题,也就是deep research 领域的benchmark;
这不就把benchmark也贯通起来了

[siri666942]

对于事实型查询，设置 include_answer=True 以获取直接答案。
对于深度研究，设置 search_depth="advanced" 和 max_results=5-10。
使用 include_domains 和 exclude_domains 来控制信息来源的质量，例如只搜索学术站点。

好像我说的1 tavily是支持的

[limit-coding]

NB，收到了，改进一下

[limit-coding]

针对问题1对于事实型查询，设置 include_answer=True 以获取直接答案。:
我的判断:这条建议本身没错(Tavily
文档里确实这么推荐),但直接套到这个项目里有个根本冲突。

冲突点:这个项目的核心卖点和评测重点(CLAUDE.md 里写明的)是"agent
自己综合多来源信息 + 引用必须可验证对应到具体来源"。Tavily 的 include_answer
返回的是它自己内部 LLM 生成的一段总结文字,没有逐句的来源归属——只是一个独立的
answer 字符串,不像 results 里每条都带 url。如果把这段文字塞进 synthesize_node
的资料池,你的报告里就可能出现"这个结论是基于 Tavily
自己脑补的总结"而不是"基于某个可点开验证的
URL"——这恰好踩在你评测里"引用是否真的支持结论"这条红线上。换句话说,用了它,等于在
你最想证明严谨性的地方引入了一个不严谨的捷径。

另一层问题:这条建议默认你能区分"事实型查询"和"深度研究型查询",但现在的架构里
decompose_node 拆出来的 sub_questions 没有类型标签,要用上这条建议得先加一层查询分
类逻辑——这是额外的复杂度,而且分类本身也会出错(没法保证"事实型"判断准确)。

我的结论:不是这条建议不对,而是它更适合"快速问答类"产品,不适合"每条结论都要可追溯
引用"的 DeepResearch agent。如果一定要用,只能限定在不进入引用链路的地方,比如喂给
reflect_node 当一个旁证去对照草稿有没有明显跑偏,但绝对不能进 format_sources
那个会被编号引用的资料池。

[limit-coding]

issue #2 原话(重新读一遍):"对于深度研究，设置 search_depth='advanced' 和
max_results=5-10"。
这句话很朴素——它没有在讨论"分类",它的隐含前提是"这整个项目本来
就是深度研究产品",所以建议直接全局把 Tavily 的搜索参数从默认的 basic/4
条结果,换成 advanced/5-10条结果。就这么简单,没有"按轮次"或"按类型"分支的意思,那是我自己加进去的东西。

现状(代码里实际的样子),nodes.py:46-57:
MAX_RESULTS_PER_QUERY = 4 # 没有 search_depth，Tavily 默认走 basic

def search_node(state):
queries = state.get("follow_up_questions") or state["sub_questions"]
for q in queries:
results.extend(web_search(q, max_results=MAX_RESULTS_PER_QUERY)) #
第一轮、follow-up 轮完全一样
不管是第一轮拆出来的子问题,还是反思后补查的 follow-up
问题,走的是同一套参数:basic,每条查询固定要 4 条结果。

issue 字面建议的改法(方案 A,全局拉满):
MAX_RESULTS_PER_QUERY = 8 # 改成 5~10 之间

def search_node(state):
...
results.extend(web_search(q, max_results=MAX_RESULTS_PER_QUERY,
search_depth="advanced")) # 所有轮次都用 advanced
所有搜索调用,不管第几轮,都用 advanced + 更多结果。简单,改两行。

我提的替代方案(方案 B,分轮次):只把 advanced/更多结果用在 follow-up 轮,第一轮维持
basic/4 不变。这是我自己加的取舍,不是 issue 原意,理由是 advanced
大概贵一倍/慢一些,全局拉满意味着哪怕是第一轮广撒网的查询也要付这个代价。

两者的真实区别就是成本:这个项目典型情况下一次研究会调用 Tavily 大概 3-6
次(decompose 出最多 4 个子问题 + reflect 后 follow-up 通常 1-2 个)。方案 A 让这
3-6 次全部变贵;方案 B 只让其中 follow-up 的那 1-2 次变贵。差距不大,但方案 A
更简单、改动更小,也更贴合 issue 原话。
所以呢，用advanced是好的，但是需要在后面的follow-up轮执行比较好，第一轮单纯就是初次筛选，不需要走advanced

[limit-coding]

**关于第三个issue：
1 信息源是一个很重要的东西,比如我问模型训练技术,我个人期望的优质信息原可能是arxiv,而一个通用的信息源可能比较低效且烧token;
假如我问memory的问题,我可能希望你搜GitHub开源项目;
网站级别的根据问题个性化查找而非web search将信息源交给搜索引擎可能会好点;

2 benchmark;
关于一个回答好不好,实际上这很难看出,人自己读很难辨别且费时间不利于快速迭代;
所以正好可以研究一下学界如何定义模型回答好坏这么一个模糊的主观问题,也就是deep research 领域的benchmark;
这不就把benchmark也贯通起来了**

你的理解我get了,而且比我之前想的更对:我之前说"等 eval 跑出真实的低质量来源问题再
做"——你已经亲手撞见了这个问题(问模型训练查出豆瓣、搜狐),所以证据已经有了,不是假设
。而且你说的不是"通用黑名单",是"按问题主题动态选信息源"(ML
问题→arxiv,memory/agent 工程问题→GitHub)。这个理解是对的。

但有个 API 层面的硬限制要先说清楚:Tavily 的 include_domains/exclude_domains
是硬过滤,不是"优先级/排序权重"。没有"优先 GitHub、其次 Google
Scholar、再其次别的"这种打分机制——你给了 include_domains=["arxiv.org"],它就只在
arxiv 里搜,搜不到就是 0 条结果,不会自动退回到更宽的范围。所以"优先搜
GitHub/学术/arxiv"这个想法不能直接翻译成一个 API 参数,得自己在外面包一层逻辑。

可行的设计,分两块,复杂度不一样:

1. 黑名单(低风险,建议先做):维护一个静态 exclude_domains(豆瓣、搜狐之类明显低质量
   的内容聚合站),所有查询统一排除。这是纯减法,不会让结果变少到
   0,直接解决你观察到的具体问题。

2. 按主题动态白名单(有真实代价,需要你定调):在 decompose_node 拆子问题的时候,让
   LLM 顺带给每个子问题打一个"建议域名"标签(比如这个子问题适合 arxiv,那个适合
   GitHub),拆完之后 search_node 先带着 include_domains 去查,如果结果太少(比如 <2
   条)就退回不限域名再查一次——用"先窄后宽"的兜底,绕开硬过滤可能 0
   结果的问题。代价是:多了一个 schema 字段、多了一次条件性的二次搜索调用(延迟和
   credit 都会增加)。这个值得做,但要不要现在做——这是典型的"加一层复杂度换
   准确率"的取舍,不是非做不可。

关于第二点(benchmark),我去查了真实文献,不是凭印象说的,这块找到的东西质量很高,直接
能用:

最对口的是 DeepResearch Bench(2025年6月, arXiv:2506.11763),专门评测深度研究类
agent,提出两套框架:

• RACE:四个维度——Comprehensiveness(信息覆盖广度)、Insight/Depth(分析深度)、Instru
  ction Following(是否切题)、Readability(结构/可读性)
• FACT:专门评测引用——effective citation count(有效引用数量)+ Citation
  Accuracy(引用准确率,即引用是否真的支撑结论)

FACT 这个框架几乎就是你们 CLAUDE.md
里写的"引用是否真的支持给出的结论"那条评测要求——这不是巧合,是同一个问题在学界已经
有人专门定义过、还做了和人类专家判断的一致性验证(论文里 Pairwise Agreement Rate
92.7%,Citation Accuracy 相关系数 0.88)。这条线索的价值是:你现在可以把 eval
设计直接对标 RACE+FACT 的维度命名,面试时能说"我的评测维度不是自己拍的,是参考了
DeepResearch Bench 这篇论文的框架",比"我设计了准确性和引用支持度两项"更站得住。

另外两个相关但次要的:

• ResearcherBench(arXiv:2507.16280):dual rubric 事实性评测,65 个前沿 AI 问题
• 一篇专门讲引用幻觉检测的论文(arXiv:2604.03173,"Detecting and Correcting
  Reference Hallucinations in Commercial LLMs and Deep Research
  Agents")——这个和你们 reflect_node
  想抓的问题(引用编号对不上)几乎是同一件事的学术化版本,值得读一下当 reflect
  设计的理论依据。

你的"个性化按用户偏好选源"想法,学界也有对应方向(arXiv:2509.25106, "Towards
Personalized Deep Research"),但那篇讲的是按用户画像个性化,不是按查询主题选域名,跟
你说的不完全是一回事,提一下供参考,不建议现在深挖。

建议的下一步:黑名单先落地(改动小、零风险);RACE/FACT 对标可以用来重写 eval
的评分维度文档。按主题动态选域名那块,下一轮再优化