工作流中同时上传了文件和一个问题，发现llm在思考时说未收到任何上传的文档

讨论
9

这是一个非常经典的问题，根据社区中类似的讨论（特别是该用户自己在另一个帖子 /t/topic/683 中的反馈），主要原因是 标准的文档提取器（Doc Extractor）节点默认不支持对扫描版 PDF（纯图片 PDF）进行 OCR 文字识别。

以下是针对此问题的分析和建议方案：

核心原因分析

  1. 扫描版 PDF 没有文本层：用户上传的是扫描件，本质上是一张张图片打包成的 PDF。
  2. 提取器限制：Dify 内置的“文档提取器”节点（Document Extractor）在处理 PDF 时，通常默认使用 pypdfium2 等工具，这些工具只能提取文件中的可选文本，无法对图片进行 OCR 识别。
  3. 结果：提取器输出的 text 变量为空字符串。
  4. LLM 的反应：因为传入 Prompt 的变量内容为空，LLM 确实“没有看到”任何内容，所以它的回答（“未收到任何上传的文档”）是完全诚实且正确的。

建议解决方案

请建议用户不要使用内置的“文档提取器”节点，而是采用以下替代方案之一：

方案一：使用 Unstructured 插件（推荐）

Dify 插件市场（Marketplace）中提供了 Unstructured 插件，它支持更高级的解析策略。

  1. 在工作流中删除原有的“文档提取器”。
  2. 在右侧“插件”或“工具”中搜索并添加 Unstructured 插件。
  3. 在配置插件时，确保启用或选择支持 OCR 的策略（例如 hi_res 或配置 OCR 相关的参数）。
  4. 注意：这通常需要用户自行部署 Unstructured 服务或使用其 API Key，并在 Dify 的设置中正确配置凭证。

方案二：使用专门的 OCR 插件

如果不使用 Unstructured，也可以在插件市场搜索 OCR 相关的工具（如 General OCR, Aliyun OCR 等），先将文件传入 OCR 工具获取文本，再将 OCR 输出的文本传递给 LLM。

总结给用户的回复示例

您可以这样回复用户：

这个问题的原因已经定位：Dify 内置的“文档提取器”节点默认不支持对扫描版 PDF（纯图片）进行 OCR 文字识别。因此提取出的 text 实际上是空的，LLM 确实没有收到任何文字内容。

解决方法：
请去 插件市场 (Marketplace) 寻找支持 OCR 功能的插件来替代原有的文档提取器节点。

  • 推荐尝试 Unstructured 插件（需要配置相应的服务或 API）。
  • 或者搜索其他 OCR 类的插件。

您自己在另一个帖子 (Topic 683) 中其实已经触及到了核心原因，即本地部署的 ETL 配置主要用于知识库，而不直接作用于工作流中的内置节点。工作流中处理扫描件必须显式使用支持 OCR 的工具节点。

:books: 相关文档与讨论：