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

从单篇论文问答到多论文比较：今天用 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的主要创新点有什么不同？

这时候系统有时能说出前者的大概内容，但到了后者，就会变成：

没有足够证据给出答案

这说明单个知识检索节点更适合处理“单篇问答”这种任务。
一旦变成“多篇比较”，它返回的上下文就很容易不完整，或者只命中一边。

这个问题后来逼着我去思考：

如果问题本身就是“多文档知识”，那工作流是不是也应该拆成多个检索节点？

后来实践证明，这个思路是对的。

坑 3：LLM 节点的上下文入口，不适合硬塞多个检索结果

再往后做多论文比较时，我遇到的第三个坑，是 Dify 里 LLM 的那个“上下文”入口，用起来更像是给单一知识检索服务的。

也就是说：

• 一个知识检索节点 + 一个 LLM 节点，比较顺
• 两个知识检索节点 + 一个上下文入口，就开始别扭了

后来我没有继续硬拧这个入口，而是换了一个思路：
先用Template 节点把两个检索节点返回的结果都整理成标准文本，再统一交给 LLM。

这一步做完后，整个流程就顺很多了。

这个坑让我更直观地看到了：

平台已经帮你搭好了“通用路径”，但如果你要做稍微复杂一点的工作流，就必须自己继续拆。

坑 4：知识源质量比我想象中更关键

今天还有一个很深的体会是：

影响 RAG 效果的，真的不只是模型。

一开始为了省一点成本，我只放了论文第一页。
结果发现：

• 作者信息
• 单位信息
• 邮箱
• 页眉页脚

这些噪声会大量混进检索结果里。

另外，最开始的 chunk 配置用的是200 / 50，对于论文这种材料来说也偏碎。
后面改成更大的 chunk 后，单篇论文问答的效果是明显改善的。

这让我再次确认了一件事：

RAG 的核心问题，还是知识源质量、chunk 切分、检索命中和上下文组织。
Dify 把流程搭建这件事做快了，但这些底层问题并不会自动消失。

图5 同一个知识库中同时包含两篇论文，后续测试中发现这种方式不利于稳定做多文档比较

图6 单篇问答流中，知识检索结果接入 LLM 的配置界面

四、今天最硬核的收获

收获 1：Dify 的定位不是做“最强效果”，而是帮助开发者快速搭原型

今天最大的认识之一，是 Dify 的价值并不在于把每个细节都做到最好。
它真正厉害的地方在于：

你可以很快把一个 AI 应用原型搭出来。

如果我只是想验证：

• 论文问答这个场景能不能做
• 知识库问答流程能不能跑
• 多文档比较有没有基本可行性

那 Dify 的效率是很高的。

收获 2：Dify 很快，但不解决智能体的细节问题

Dify 确实很快。
这一点今天感受特别明显。

很多在 LangGraph 里要自己定义状态、自己写节点逻辑、自己连状态流的东西，在 Dify 里可以直接用模块拖出来。

但问题是，它快归快，不会自动帮你做这些事情：

• 检索细节优化
• 文档级别精细控制
• 多文档复杂比较
• 特定业务逻辑定制
• 更深层的上下文组织

说白了，它更适合做一个“通用且快速的工作流原型”，不太适合承担所有精细化控制。

收获 3：很多问题不是业务本身的问题，而是工作流组织的问题

今天特别值钱的一个体会是：

有些问题，不一定要在模型或者业务逻辑上硬优化，而是可以通过重新组织工作流来解决。

比如今天的多论文比较，就是一个很典型的例子。

一开始我总想让一个知识检索节点把所有问题都扛住，后来发现不对。
真正合理的方式是：

• 多篇文档
• 多个检索节点
• 多份证据先独立组织
• 最后再统一交给 LLM

也就是说，工作流拆得合理，本身就是一种优化。

收获 4：多文档比较不是“把多个 PDF 丢进去”这么简单

今天最后一个很重要的收获是：

多文档比较本质上就是一个更复杂的工作流问题。

不是说把多个 PDF 都传进知识库里，再接一个知识检索节点，就自动拥有了“比较能力”。

真正要做比较，至少要考虑：

• 证据是不是分别来自不同文档
• 检索是不是分别做的
• 上下文是不是有清晰归属
• LLM 最后拿到的是不是结构化的证据

这个认识对我后面做手写智能体其实很有帮助。
因为它让我更加确认：
复杂任务，本来就应该拆步骤，而不是指望一个节点解决所有问题。

五、今天这轮实践之后，我对 Dify 和手写项目的看法

如果现在让我用一句话总结今天的感受，那就是：

Dify 更适合快速搭建智能体原型，LangGraph 更适合认真做工程落地。

前者像平台交付，强调的是：

• 速度
• 搭建效率
• 原型验证
• 模块复用

后者像框架开发，强调的是：

• 可控性
• 可定制性
• 节点逻辑
• 状态流组织
• 更复杂业务的承接能力

所以现在我不会再简单地说“Dify 好”或者“LangGraph 好”。
更准确的说法应该是：

• Dify 适合快速试产品
• LangGraph 适合认真做产品

六、最后的小结

图7 最终的Chatflow

今天这轮 Dify 实践，对我来说最大的价值，不是“我会用了一个低代码平台”，而是我终于更清楚地看到了：

1. Dify 在 AI 应用开发里的位置是什么
2. 它和手写智能体项目的区别是什么
3. 哪些问题适合靠平台快速验证
4. 哪些问题最终还是得靠自己手写逻辑去解决

所以今天最关键的收获，并不是某个节点怎么配，而是这件事：

AI 应用平台能帮你把流程搭得很快，但真正决定效果上限的，仍然是知识源、检索、上下文和工作流设计。

这也是为什么，这次补 Dify 对我来说不是在“换路线”，而是在补齐自己对智能体开发这条路的理解。