19.从单篇论文问答到多论文比较：今天用 Dify 做了一次 RAG 工作流实践

目 录从单篇论文问答到多论文比较今天用 Dify 做了一次 RAG 工作流实践一、今天到底干了什么1. 先做了一个单篇论文的 RAG 问答 Chatflow2. 在单篇问答的基础上又做了一个多论文比较的 RAG Chatflow二、今天对 Dify 的定位有了更实际的理解三、今天踩过的坑坑 1一开始提问方式就有问题坑 2只用一个知识检索节点不适合做跨文档比较坑 3LLM 节点的上下文入口不适合硬塞多个检索结果坑 4知识源质量比我想象中更关键四、今天最硬核的收获收获 1Dify 的定位不是做“最强效果”而是帮助开发者快速搭原型收获 2Dify 很快但不解决智能体的细节问题收获 3很多问题不是业务本身的问题而是工作流组织的问题收获 4多文档比较不是“把多个 PDF 丢进去”这么简单五、今天这轮实践之后我对 Dify 和手写项目的看法六、最后的小结从单篇论文问答到多论文比较今天用 Dify 做了一次 RAG 工作流实践今天主要花时间补了一下 Dify。这次补 Dify 的目的并不是说后面要专门转去做低代码平台而是想把这个工具摸清楚然后和目前自己手写的“论文检索 RAG Agent LangGraph”项目做一个对照。因为现在自己在做的是手写智能体所以我更关心的不是“会不会点这个平台”而是它到底解决了什么问题、适合什么场景、和手写项目比起来差异在哪里。今天这一轮实践下来最大的感受是Dify 更像是一个用于快速搭建 AI 应用原型的平台而不是一个专门帮你把智能体细节做到极致的框架。它搭起来很快原型产出速度也很高但一旦问题进入到检索细节、上下文组织、多文档比较这些层面就还是得靠开发者自己去拆工作流、补逻辑。一、今天到底干了什么今天主要做了两件事。1. 先做了一个单篇论文的 RAG 问答 Chatflow我先在 Dify 里搭了一个最小的论文问答流整体结构很简单用户输入 → 知识检索 → LLM → 返回结果这个过程中做的事情主要包括上传论文建知识库配置文本切分配置检索方式把知识检索节点接到 LLM 前面跑通一个最小的单论文 RAG 问答流程这一步做完以后其实已经能回答“某一篇论文的方法是什么”“解决了什么问题”这一类问题了。图1 最小 Chatflow 骨架用户输入 → 知识检索 → LLM → 直接回复图2 在 Dify 中上传论文并创建知识库的入口图3 知识库切分参数配置最初采用 200 / 50 的 chunk 设置2. 在单篇问答的基础上又做了一个多论文比较的 RAG Chatflow单篇论文问答跑通以后我继续做了第二步升级让这个系统不仅能问“某一篇论文讲了什么”还能够回答“论文1和论文2的主要差异是什么”这种跨文档问题。一开始我以为把两篇论文都放进同一个知识库然后用一个知识检索节点就够了。但实际测试之后发现这种做法对于“多文档比较”并不稳。所以后面我把流程改成了一个更清晰的工作流一个知识库只放 Paper1一个知识库只放 Paper2一个检索节点只负责检索 Paper1另一个检索节点只负责检索 Paper2检索结果先经过 Template 节点整理最后统一交给 LLM 做比较也就是说后面做出来的已经不是单篇问答流而是一个多分支的比较型 workflow。这个结构让我一下子就看清楚了多文档比较不是把多个 PDF 丢进知识库就自动会比较而是要把工作流拆开。图4 多论文比较版 workflow两个检索分支分别取证再由 LLM 汇总比较二、今天对 Dify 的定位有了更实际的理解今天这一轮做下来我对 Dify 的理解比之前清楚了很多。如果让我用一个比喻来形容Dify 更像是用现成构件搭建板房LangGraph 更像是从地基开始一块砖一块砖砌房子Dify 的特点是模块都封装好了可以直接拖节点、接工作流很快就能把一个 AI 应用原型搭出来很适合验证一个产品想法能不能成立而 LangGraph 这种框架虽然搭起来慢很多但优势也很明显细节可以自己定义节点逻辑可以自己控制状态流可以自己设计更适合处理复杂业务和更真实的工程落地所以我现在更倾向于这样理解两者的区别Dify 不是“更高级”的 LangGraph也不是 LangGraph 的替代品。它们的定位不一样。Dify 更适合快速验证产品原型LangGraph 更适合往真正可控、可扩展的产品实现上走这两者没有所谓绝对好坏只是适合的阶段和目标不同。三、今天踩过的坑今天其实踩了不少坑但正是这些坑让我对 Dify 的边界看得更清楚了。坑 1一开始提问方式就有问题最开始建完知识库以后我的文档名字是paper1、paper2这种形式。所以我一开始提问的时候会直接问paper1 的主要工作是什么paper2 的主要工作是什么结果很有意思问paper1的时候系统有时能答出来但问paper2的时候效果就明显不稳后来我才意识到这其实是个“假象”。原因是Dify 的知识检索并不会像我手写项目里那样天然理解“paper1 对应哪篇文献paper2 对应哪篇文献”。对它来说更可能是把你的问题转成向量然后去知识库里按语义相似度匹配文本块。所以你嘴里的paper1和paper2对它来说并不一定真的是一个稳定可识别的“文档标识”。后来我把提问方式改成直接问论文全名比如挑战场景下的 VoIP 隐写分析那篇论文的主要工作是什么这时回答就明显稳定多了。这个坑让我意识到Dify 这种平台在“文档级别的精细控制”上不像手写系统那么明确。它能做但很多时候更偏“通用语义检索”而不是“你说哪个文件它就严格锁定哪个文件”。坑 2只用一个知识检索节点不适合做跨文档比较今天第二个大坑是我发现最开始做出来的那个 Chatflow并不能很好地回答多篇论文比较的问题。比如我问论文1和论文2的主要创新点有什么不同这时候系统有时能说出前者的大概内容但到了后者就会变成没有足够证据给出答案这说明单个知识检索节点更适合处理“单篇问答”这种任务。一旦变成“多篇比较”它返回的上下文就很容易不完整或者只命中一边。这个问题后来逼着我去思考如果问题本身就是“多文档知识”那工作流是不是也应该拆成多个检索节点后来实践证明这个思路是对的。坑 3LLM 节点的上下文入口不适合硬塞多个检索结果再往后做多论文比较时我遇到的第三个坑是 Dify 里 LLM 的那个“上下文”入口用起来更像是给单一知识检索服务的。也就是说一个知识检索节点 一个 LLM 节点比较顺两个知识检索节点 一个上下文入口就开始别扭了后来我没有继续硬拧这个入口而是换了一个思路先用Template 节点把两个检索节点返回的结果都整理成标准文本再统一交给 LLM。这一步做完后整个流程就顺很多了。这个坑让我更直观地看到了平台已经帮你搭好了“通用路径”但如果你要做稍微复杂一点的工作流就必须自己继续拆。坑 4知识源质量比我想象中更关键今天还有一个很深的体会是影响 RAG 效果的真的不只是模型。一开始为了省一点成本我只放了论文第一页。结果发现作者信息单位信息邮箱页眉页脚这些噪声会大量混进检索结果里。另外最开始的 chunk 配置用的是200 / 50对于论文这种材料来说也偏碎。后面改成更大的 chunk 后单篇论文问答的效果是明显改善的。这让我再次确认了一件事RAG 的核心问题还是知识源质量、chunk 切分、检索命中和上下文组织。Dify 把流程搭建这件事做快了但这些底层问题并不会自动消失。图5 同一个知识库中同时包含两篇论文后续测试中发现这种方式不利于稳定做多文档比较图6 单篇问答流中知识检索结果接入 LLM 的配置界面四、今天最硬核的收获收获 1Dify 的定位不是做“最强效果”而是帮助开发者快速搭原型今天最大的认识之一是 Dify 的价值并不在于把每个细节都做到最好。它真正厉害的地方在于你可以很快把一个 AI 应用原型搭出来。如果我只是想验证论文问答这个场景能不能做知识库问答流程能不能跑多文档比较有没有基本可行性那 Dify 的效率是很高的。收获 2Dify 很快但不解决智能体的细节问题Dify 确实很快。这一点今天感受特别明显。很多在 LangGraph 里要自己定义状态、自己写节点逻辑、自己连状态流的东西在 Dify 里可以直接用模块拖出来。但问题是它快归快不会自动帮你做这些事情检索细节优化文档级别精细控制多文档复杂比较特定业务逻辑定制更深层的上下文组织说白了它更适合做一个“通用且快速的工作流原型”不太适合承担所有精细化控制。收获 3很多问题不是业务本身的问题而是工作流组织的问题今天特别值钱的一个体会是有些问题不一定要在模型或者业务逻辑上硬优化而是可以通过重新组织工作流来解决。比如今天的多论文比较就是一个很典型的例子。一开始我总想让一个知识检索节点把所有问题都扛住后来发现不对。真正合理的方式是多篇文档多个检索节点多份证据先独立组织最后再统一交给 LLM也就是说工作流拆得合理本身就是一种优化。收获 4多文档比较不是“把多个 PDF 丢进去”这么简单今天最后一个很重要的收获是多文档比较本质上就是一个更复杂的工作流问题。不是说把多个 PDF 都传进知识库里再接一个知识检索节点就自动拥有了“比较能力”。真正要做比较至少要考虑证据是不是分别来自不同文档检索是不是分别做的上下文是不是有清晰归属LLM 最后拿到的是不是结构化的证据这个认识对我后面做手写智能体其实很有帮助。因为它让我更加确认复杂任务本来就应该拆步骤而不是指望一个节点解决所有问题。五、今天这轮实践之后我对 Dify 和手写项目的看法如果现在让我用一句话总结今天的感受那就是Dify 更适合快速搭建智能体原型LangGraph 更适合认真做工程落地。前者像平台交付强调的是速度搭建效率原型验证模块复用后者像框架开发强调的是可控性可定制性节点逻辑状态流组织更复杂业务的承接能力所以现在我不会再简单地说“Dify 好”或者“LangGraph 好”。更准确的说法应该是Dify 适合快速试产品LangGraph 适合认真做产品六、最后的小结图7 最终的Chatflow今天这轮 Dify 实践对我来说最大的价值不是“我会用了一个低代码平台”而是我终于更清楚地看到了Dify 在 AI 应用开发里的位置是什么它和手写智能体项目的区别是什么哪些问题适合靠平台快速验证哪些问题最终还是得靠自己手写逻辑去解决所以今天最关键的收获并不是某个节点怎么配而是这件事AI 应用平台能帮你把流程搭得很快但真正决定效果上限的仍然是知识源、检索、上下文和工作流设计。这也是为什么这次补 Dify 对我来说不是在“换路线”而是在补齐自己对智能体开发这条路的理解。