个性化科研情报智能体

原型项目 · 2026 · 独立设计与开发

做研究时，我经常需要在论文网站、代码仓库和技术社区之间来回切换。每天出现的内容太多，很难快速判断哪些值得细读、哪些仓库适合做 baseline。

这个项目就是从这个问题开始的。我独立完成了多 Agent 流程、数据源接入、RAG 检索、评估和 Web 界面，希望把分散的研究信号整理成可以采取行动的每日简报。

从收集信息到辅助判断

系统接入了 arXiv、Semantic Scholar、OpenAlex、Papers with Code 和 GitHub。多个 Connector 并发获取候选内容，再根据用户画像过滤，从新颖性、技术深度、证据强度、可复现性和实用性等维度分析。

我把过程拆成发现、过滤、价值分析、证据审查、趋势识别和推荐等职责。它们通过 PipelineState 传递数据，由 Supervisor 调整流程，每一步都能被单独观察。

最终报告会区分论文、代码仓库和趋势信号，并给出优先阅读项、潜在问题和下一步行动。它应该减少研究者的判断成本，而不是继续增加信息数量。

用户点开一篇论文后，常常只会问：“这个适合做 baseline 吗？”如果只检索这句话，系统能识别“baseline”，却不知道“这个”具体指哪篇论文。检索没有出错，但查询并不完整。

我使用 Embedding 与 BM25 混合召回，权重分别是 68% 和 32%；如果界面传入 selected_item_id，再为对应内容增加 0.35。语义检索理解相近表达，BM25 保留模型名称和论文标题，当前选择则成为额外的意图信号。

但增加分数仍然只是软约束。如果内容没有正确进入索引或原始得分过低，它仍可能落在 Top-K 之外。因此系统还会检查结果是否包含当前条目；如果没有，就根据候选数据和已有分析重新构造上下文，显式放入证据集合。

这个细节改变了我对 RAG 的理解：用户的问题并不等于完整意图，界面状态和当前选择也是上下文。能够由系统确定的信息，不应该再交给模型猜。

我使用 300 多条人工标注数据做过阶段性测试。相比单一 BM25，混合检索在 Recall@50 和 Precision@10 上都有提升；数据源改为并发检索后，等待时间也明显缩短。

这个项目源于我在日常科研中遇到的实际困境。完成它之后，我最大的收获是：好的产品往往不是凭空想出来的，而是来自对身边问题的观察。