技术知识库 · 工具评测 · · 国科智飞 Gavin

文献发现与文档记忆层：PaperSeek 与 Knowhere 能做什么

PaperSeek 把自然语言变成可复核的检索式与候选文献，Knowhere 在文档解析与 RAG 之间补上记忆层。两把铲子，各管一段。

知识工作流的两头各有一个老问题：前端是"找不到文献"，后端是"找到了也读不出结构"。前者消耗的是研究者的检索技巧，后者消耗的是工程师的清洗时间。PaperSeek 和 Knowhere 分别打磨这两把铲子——一个做文献发现，一个做文档记忆层。两个项目都是 Apache 2.0，都处在早期阶段，能力边界写得比宣传多。

PaperSeek：把文献发现变成可复核的流水线

PaperSeek 是"自然语言 → 检索式 → 候选文献 → 引用图 → 可复核 CSV"的 LLM 文献发现 agent（GitHub：MingfengHong/paperseek）。Python 3.8+，默认数据源 OpenAlex，另接 Crossref 与 Web of Science Starter；LLM 适配 15 家以上，覆盖 OpenAI、Anthropic、Gemini、DeepSeek、通义千问、Kimi、智谱、Ollama 等；部署形态有 Docker、Vercel 和云端创空间，本地版本用 SQLite 存储。

它的工作方式值得拆开看：把一句自然语言需求拆成概念、生成多组检索式，先试搜、根据反馈校准（默认最多 5 轮），再对候选文献做 LLM 打分排序，最后接 OpenAlex 做前后向引用扩展。全程可见——当前查哪个库、生成了什么检索式、返回多少条、是否进入引用扩展、排序依据是什么，都暴露在界面上。作者有一个明确的设计判断："终端和命令行对大家来说没有感知可供性"——Web UI 优先不是审美选择，而是降低使用门槛的产品决策。

两个工程细节对做工具的人有参考价值。一是输出格式固定：CSV 字段锁定为 rank / title / authors / year / venue / doi / url / citation_count / relevance_score / relevance_reason，JSON 保留完整检索历史——能不能把结果交给下一个工具，决定一个工具能不能进流程。二是安全细节：Web UI 只显示 API Key 的配置状态，不把 key 内容发到浏览器，用户输入的 key 也只存在于当前会话。

它的六条设计原则——自然语言转可执行检索式、候选相关性排序、引用网络扩展、过程可视化、结构化结果导出、Web UI 优先——其实是一份小型产品宣言。还有一条隐含原则同样值得注意：项目附带 Agent Skill，但选择不自动安装，把是否接入交给用户决定。这种克制在当下的工具生态里并不常见。

部署形态也对应不同的试用深度：Vercel 一键 demo 和云端创空间适合先验证思路，Docker 自部署适合把数据留在本地并接自己的 LLM Key；自部署版本用 SQLite 存本地数据，云端版则持久化登录态。对机构用户来说，数据放在哪、Key 掌握在谁手里，往往比功能清单更能决定能不能采购——这个项目把选择权留给了使用者。还有一个使用姿势值得参考：把导出的 CSV 当"检索日志"留存，三个月后回看当时生成了哪些检索式、为什么这些文献排在前面，等于给文献综述留下一份可复现的方法记录。

边界也写得清楚：它构建候选文献池并排序，不替代研究者对理论脉络的最终判断。项目自承早期的局限：不同数据源字段不统一、摘要偶尔缺失、模型会误判、引用扩展有噪音。另外适配 15 家以上 LLM 是优势也是维护负债——每家的协议细节都不同，Alpha 阶段 38 个 commit 的迭代节奏下，长期维护成本会逐渐显现。引用图是亮点，但对非视觉思考者价值有限，更接近 nice-to-have。

适合：需要系统检索、要留痕和可复查的科研人员，以及想把检索结果接入下游流水线的工程团队。不适合：指望 AI 替你读文献、写综述的人——它的输出是候选清单和排序理由，不是结论。把它放进真实流程的正确位置，是开题前的文献地毯式扫描和综述的前期建池；最后的筛选与判断，仍然要在人这边完成。

Knowhere：解析与检索之间的记忆层

Knowhere 的自我定位很明确：不是下一个 MinerU，而是 MinerU 之后的关键一步。它做的是"文档解析和 RAG 检索之间"的中间层——把 PDF、Word、PPT 解出来的平铺文本，重建为带层级、带多模态关联、带跨文档图谱的结构化记忆。用一句话解释它解决的问题：RAG 检索出来的是"文本块"，而 Agent 需要知道"这块文本属于哪一章、和哪张表有关、和哪份文档互证"。

架构上，它在"解析 → 向量化"之间插入一条结构重建流水线：树形层级恢复 → 多模态关联 → 跨文档图谱 → Agentic Retrieval。每个 Chunk 知道自己所在的标题、层级和上下文路径；图片做 OCR 加描述、表格做摘要与结构化，并关联回来源 Chunk；跨文档图谱把"单文档"提升到"知识库"维度。检索时融合关键词、路径、内容与语义，沿章节树和图谱链接深入。这套设计对应一个直觉：人读文档是"看目录 → 定位章节 → 进入细节"，而不是在文本堆里盲找。

Parser 默认用 MinerU，但不强绑定，可换 Unstructured、Markitdown 等任何输出 Markdown 的工具；LLM 默认 DeepSeek（文本/表格摘要）加 Qwen-VL（图像 OCR 与描述），模型解耦，支持 OpenAI、通义、智谱、火山方舟。代码要求 Python 3.11+，后端、Web UI、私有化部署和两个 SDK 拆成 5 个子仓库；使用路径有三档：云端 API、集成进现有 RAG、私有化 Docker。格式上支持 PDF/DOCX/PPTX/XLSX/CSV/图片/Markdown/TXT/JSON，音频视频在路线图里。工程组织上，五个子仓库的好处是接入方可以只用 SDK 而不碰整套部署；国内团队常用的一些细节也考虑到了——镜像有阿里云加速，默认模型是国产模型，多 Key 轮换、匿名遥测可关。

官方内部评测称首次准确率提升 36%、召回率提升 11%、反馈准确率 79%（基线 53%），并宣称更少的 Agent 循环与更省的 Token——这些数字尚无第三方复现，选型时应自行验证。项目发布一个月拿到 1500+ Star，冷启动不错，但还没有公开的企业级生产案例。它的卡位意识很清晰：所有人抢"解析"或"生成"，而"解析之后到 Agent 用得起来之前"这块是空白——不抢上下游，反而更容易成为连接层。

风险也要说清楚：默认依赖 MinerU，意味着解析质量的天花板握在别人手里；自评测数字缺复现；音视频场景得等路线图落地；五个子仓库意味着接入时要做一次架构选择，不是一行代码的事。适合：已经有解析工具、想补一层"Agent 能用得起来"的记忆结构的企业知识库团队。不适合：想要开箱即用全家桶 RAG 产品的团队，或者现在就要求支持长音频、会议记录的场景。

两把铲子的分工

PaperSeek 解决的是"入口"：让找文献这件事可复核、可留痕、可交接。Knowhere 解决的是"中间层"：让解析后的文档变成 Agent 能用的记忆。它们不在同一条流水线上竞争，但共享同一种产品气质——克制的自我定位。

两个项目都属于"克制型工具"：过程透明、结构化导出、边界声明。它们不承诺替你做判断，只保证把脏活做得可检查——在 Agent 工具普遍夸口的当下，这反而是稀缺能力。对选型者更实际的建议是：先用 PaperSeek 的 CSV 契约思维检查现有工具链——上一个环节的输出能否直接交给下一个环节；再用 Knowhere 的分层思维检查你的 RAG——检索出来的 Chunk 有没有上下文。这两个检查不依赖你是否采用这两个项目，做完就会知道自己的知识流水线缺哪一段。

最后提醒一句：选型时最忌讳的标准是"它能不能替我做研究"。这两个工具都不会，也不打算会——它们把候选池从几百篇收敛到几十篇，把判断留给读文献的人。