feat: add observable article link following - #35
feat: add observable article link following#35openjiuwen-sync-bot[bot] wants to merge 9 commits into
Conversation
…ollow-observability # Conflicts: # deepsearch/docs/feature/framework/article-link-follow.md # deepsearch/openjiuwen_deepsearch/algorithm/prompts/collector_article_link_follow_compress.md # deepsearch/openjiuwen_deepsearch/algorithm/report/article_link_follow_diagnostics.py # deepsearch/openjiuwen_deepsearch/algorithm/research_collector/article_link_follow.py # deepsearch/tests/info_collector/algorithm/test_article_link_follow.py # deepsearch/tests/info_collector/test_webpage_enrichment_article_link_follow.py # deepsearch/tests/report/test_article_link_follow_diagnostics.py
…ollow-observability # Conflicts: # deepsearch/openjiuwen_deepsearch/algorithm/report/report.py # deepsearch/tests/utils/test_url_utils.py
|
|
openjiuwen-collaboration-bot
Bot
added
ci-successful
ci-running
and removed
ci-failed
ci-successful
labels
![openjiuwen-collaboration-bot[bot]](https://avatars.githubusercontent.com/u/264091041?s=60&v=4){kind=small}
| @@ -0,0 +1,83 @@ | |||
| # 信息收集文章内链接跟进 | |||
There was a problem hiding this comment.
head_sha: d8d159fa78d4733655cf6706f62de38704975685
增加这个工具之后的耗时情况怎么样？跑一篇默认5 章节的文章，会触发多少次这个跳转 tool？是否有限流？这个跳转是否合理？得到的结果是否有助于报告生成？这些东西都往评论贴一下
There was a problem hiding this comment.
head_sha: d810a858c4637cba05af14110c18abc3c791378e
补充做了一次默认5章节报告的A/B验证。A组关闭article-link-follow，B组开启；两组均开启webpage enrichment，最终都生成了5个顶层章节。
1. 耗时和token开销
本次单次观测结果如下：
| 指标 | 关闭 | 开启 |
|---|---|---|
| 墙钟耗时 | 1979s | 1559s |
| LLM调用数 | 274 | 363 |
| total tokens | 1,018,281 | 1,505,099 |
| 所以会导致增加一定的耗时和token消耗 |
2. 默认5章节会触发多少次？
本次实际执行漏斗是：
follow节点执行26轮
→ 5轮发现候选
→ 19条原始候选
→ 18条通过安全检查
→ 8条被选择并实际fetch
→ 6条fetch成功
→ 6次LLM压缩
→ 4条压缩和evaluation成功
→ 0条成功写回
因此需要区分：
- 节点执行：26轮；
- 真正跳转网页：8次；
- follow专用LLM压缩：6次。
follow并不是每章固定执行一次，而是随每个collector step执行；没有候选的轮次不会发起网页请求。
3. 是否触发限流？
本次日志中没有发现限流：
- 没有HTTP 429；
- 没有QPS limiter等待；
- 没有semaphore等待记录。
两条fetch失败也不是明确的限流问题： - Wiley论文的direct fetch和Jina fallback均返回403，属于目标站点访问限制；
- GEOMAR仓储页返回empty。
4. 实际跳转是否合理？
本次实际跳转8条：
| 链接 | 结果 | 判断 |
|---|---|---|
| Frontiers 2020文章自身DOI | 成功处理，写回时判重 | 不应重复跟随 |
| Wiley SPiCT论文DOI | direct和Jina均403 | 目标合理，但抓取失败 |
| LinkedIn短链 | fetch成功，压缩为空 | 目标不透明，且parent超出时间范围 |
| Frontiers 2022文章自身DOI | 成功处理，写回时判重 | 不应重复跟随 |
同一Frontiers文章的另一/full URL |
成功处理，写回时判重 | URL变体重复 |
| Creative Commons许可证页 | fetch成功，压缩为空 | 明显不合理 |
| Frontiers 2026文章自身DOI | 成功处理，写回时判重 | 重复且超出任务时间范围 |
| GEOMAR仓储页 | fetch为空 | 可能是有效学术来源，但抓取失败 |
整体看，8条中只有Wiley论文和GEOMAR仓储页具有潜在新增证据价值，但两条都没有成功获取内容；其余主要是同文URL、许可证页、短链或超出时间范围的链接。
另外，19条原始候选中有11条被过滤。
5. 是否有助于报告生成？
本次没有产生实际报告贡献。
4条文档完成了fetch、压缩和evaluation，但最终都因与已有文档重复而没有写回。因此后续链路均为0：
writeback=0
report_candidate=0
report_prefilter=0
report_classification=0
report_final_reference=0
即本轮没有任何follow文档进入报告筛选或成为最终引用，也没有给报告带来article-link-follow独有的新证据。
结论
本轮5章节报告中，article-link-follow执行26轮、实际fetch 8次、增加6次专用LLM调用和68,055 tokens，但最终写回及引用均为0。
There was a problem hiding this comment.
head_sha: d810a858c4637cba05af14110c18abc3c791378e
实测下来没有实际报告贡献。不建议合入
…ollow-observability # Conflicts: # deepsearch/tests/report/test_sub_report.py
2 participants
Paired: GitHub #35 ↔ GitCode !320
变更概述
为信息收集流程增加可配置的一跳文章链接跟进（article-link-follow）能力。系统能够从搜索结果或网页增强后的正文中提取文章链接，选择与当前任务相关的候选页面，并将抓取、压缩和评估通过的页面作为独立证据写回收集上下文。
功能默认关闭，不影响现有流程。
主要变更
info_collector_article_link_follow_enable配置及 Server API 透传。report_candidatereport_prefilterreport_classificationreport_final_reference开关关系
info_collector_article_link_follow_enable与info_collector_webpage_enrich_enable相互独立：测试
相关测试：