事实上，我的输入是有一个问题和一个文件的文档的，怎么就变成他那样理解了呢，完全匪夷所思啊！有人能解答下吗？
LLM那块的配置有引用这个文件吗？如果在文件提取器那里引用了，但是LLM里没有配置也是有可能的会遇到这样的问题。
你是指LLM的系统提示词里要引用上传的文件吗？那是不是得引用文件提取器的输出(即text)啊？
你这是没看到我的图吗，里面已经添加了文档提取器了，只是上传的是扫描版的pdf，所以文档提取器提取不到文字罢了。所以我才来这里求教的。
@Dify_Forum_Helper 你有什么建议吗？
这是一个非常经典的问题，根据社区中类似的讨论（特别是该用户自己在另一个帖子 /t/topic/683 中的反馈），主要原因是 标准的文档提取器（Doc Extractor）节点默认不支持对扫描版 PDF（纯图片 PDF）进行 OCR 文字识别。
以下是针对此问题的分析和建议方案：
核心原因分析
- 扫描版 PDF 没有文本层：用户上传的是扫描件，本质上是一张张图片打包成的 PDF。
- 提取器限制：Dify 内置的“文档提取器”节点（Document Extractor）在处理 PDF 时，通常默认使用
pypdfium2等工具，这些工具只能提取文件中的可选文本，无法对图片进行 OCR 识别。 - 结果：提取器输出的
text变量为空字符串。 - LLM 的反应：因为传入 Prompt 的变量内容为空，LLM 确实“没有看到”任何内容，所以它的回答（“未收到任何上传的文档”）是完全诚实且正确的。
建议解决方案
请建议用户不要使用内置的“文档提取器”节点，而是采用以下替代方案之一：
方案一：使用 Unstructured 插件（推荐）
Dify 插件市场（Marketplace）中提供了 Unstructured 插件，它支持更高级的解析策略。
- 在工作流中删除原有的“文档提取器”。
- 在右侧“插件”或“工具”中搜索并添加 Unstructured 插件。
- 在配置插件时，确保启用或选择支持 OCR 的策略（例如
hi_res或配置 OCR 相关的参数）。 - 注意：这通常需要用户自行部署 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 的工具节点。
相关文档与讨论：
- Unstructured 插件 - Dify Marketplace
- 相关社区讨论：/t/dify/683 (用户自己的另一个相关提问)
@Dify_Forum_Helper 你可以帮大家搜索一下 Marketplace 有什么关于 OCR 的 Plugin 吗（除了 Unstructured）？记得带上 Link。
好的，已经为您和大家整理了 Dify 插件市场中除 Unstructured 以外常见的 OCR 相关插件信息。
这些插件通常调用特定云厂商的 API，对于中文文档或特定格式（如表格、证件）的识别效果通常优于通用的开源模型。
推荐的 OCR 插件 (Dify Marketplace)
您可以直接访问以下链接在市场中搜索所有 OCR 工具：
点击此处搜索 Dify 插件市场中的 “OCR” 插件
常见可用的 OCR 插件包括（但不限于）：
- Aliyun OCR (阿里云 OCR)
- 适用于通用文字识别、表格识别等，国内用户常用。
- Tencent Cloud OCR (腾讯云 OCR)
- 腾讯云的 OCR 服务，同样适合中文环境。
- Volcengine OCR (火山引擎 OCR)
- 字节跳动旗下的 OCR 服务。
- General OCR
- 部分社区贡献的通用 OCR 工具。
使用建议
- 配置凭证：使用上述云厂商插件时，通常需要在 Dify 的“工具 > 授权”中配置对应的
API Key和Secret Key。 - 工作流编排：
- 移除原有的“文档提取器”节点。
- 添加上述任一 OCR 工具节点。
- 输入：选择用户上传的文件。
- 输出：将 OCR 节点输出的
text或json结果传递给后续的 LLM 节点。
非常感谢以上各位大佬的回复，太激动了。我现在本地安装了unstrutured插件，也跑在了容器里，但目录遇到个问题，就是FILES_URL怎么配都有点问题，以下是.env中的配置，还试过配localhost，感觉也是不对。
当前工作流我已做修改，如下图：
unstructured插件配置如下：
Docker容器当前情况如下图：
不知道接下来要如何处理了。
一言惊醒梦中人啊，根据你的提示，我进入unstructured容器看到了错误，原来他拼接了请求地址，日志如下，难怪会出现404了：
所以更改了插件地址配置，去掉了后面的部分，然后错误就变成下面这样了：
An error occurred in the langgenius/unstructured/unstructured, please contact the author of langgenius/unstructured/unstructured for help, error type: Exception, error details: Partition request failed. msg:{“detail”:[{“type”:“literal_error”,“loc”:[“body”,“chunking_strategy”],“msg”:“Input should be ‘by_title’”,“input”:“by_page”,“ctx”:{“expected”:“‘by_title’”}}]}
流程中有 1 个节点运行异常，请前往追踪查看日志。
从以上错误来看，应该是我参数配置的有问题，至少文件是检测到了，感谢，我再调整看看。
很高兴您最初的问题已得到解决。
看来“by_page”不受支持，请参阅 Chunking Configuration - Unstructured 0.12.6 documentation
1 个赞
unstructured partition节点算是跑成功了，也成功的解析出了文件内容，如下图：
但是看这个图，files是空列表，text里是识别出来的文本，那这样的话，后续其实根本用不到文本解析器这个节点了，因为unstructured已经达到提取文本的功能了。我有个疑问，为什么unstructured的解析结果里会有个files呢，pdf里还能放其他文件吗？感觉不可能吧？！！
谢谢 @Riino 另外， @Dify_Forum_Helper 可以简单解答一下最后这个问题。然后对整个聊天 Q&A 做一个综合总结。
先直接回答最后这个问题，然后再把整串 Q&A 帮你们简要串一下。
1. 为什么 Unstructured 输出里有 files，但它是空的？
你现在看到的结构大致是：
textfilesjsonimageselements- …
这是典型的「通用解析结果 schema」，是为了兼容各种输入形态设计的，不是只针对 PDF 的。逐个解释下跟你问题相关的部分：
text
- 已经看到里面是完整的 OCR 识别文本。
- 这是给 LLM 直接用的主输出，在你当前这种「扫描 PDF → 提取文字 → 让 LLM看」的场景，基本只用这个就够了。
- 你说“这样其实不需要再接文档解析器节点了”这个判断是对的：
在这条链路里，Unstructured 已经完成了「文档提取器 + OCR」的工作。
files 为什么是空？
- 这个字段是为了更复杂的输入场景预留的，比如：
- 传的是一个 zip 或其他「多文件打包」资源，工具会把里面拆出的每个文件挂在
files里； - 或者是带附件的邮件、某些 Office 文档里内嵌的独立附件；
- 也可以用来放工具加工出的中间文件。
- 传的是一个 zip 或其他「多文件打包」资源，工具会把里面拆出的每个文件挂在
- 你现在传入的是单个 PDF，里面并没有再嵌套其它「独立文件对象」可供导出，所以：
files: []完全正常，只是表示「这次解析没有额外拆出子文件」。- 它和「是否成功识别文本」没有关系。
简单说：
text是给你现在这个“文档内容给 LLM 看”的主通道；
files是「复杂 / 打包 / 附件」场景用的扩展位，这次用不上，所以是空的。
2. 用 Unstructured 的最佳实践（结合你现在的结果）
在你当前的工作流设计里，推荐这样简化：
- 用户上传文件 → 直接输入到 Unstructured 节点。
- 在 LLM 节点的 Prompt 里引用：
{{ partition.text }}（名称按你节点实际输出名来）
让模型直接基于这段文本回答。
- 如果以后有更细的需求，比如：
- 按页、按标题、按段落来做更细粒度控制；
- 做「先过滤、再喂给 LLM」的逻辑；
再去用elements/json做二次处理即可。
在这个 PDF OCR 的 case 里，确实不需要再接一个“文档提取器”节点，否则只是对已经抽出的文本再做一次无谓处理。
3. 这个话题的整体小结（方便后人搜到）
整串讨论，其实经历了三步：
-
最初现象
- 用户上传了扫描版 PDF + 问题，LLM 却说「没收到上传文档」。
- 原因：内置「文档提取器」节点只读文本层，不做 OCR → 扫描 PDF 里没有可选文本 →
text为空 → Prompt 里传给 LLM 的是空字符串。
-
定位与解决思路
- 讨论确认：
- 通过配置环境变量（例如 ETL_TYPE=Unstructured）主要影响知识库导入，并不会让工作流里的文档提取器自动用 Unstructured 做 OCR。
- 于是改走「插件工具」路线：
- 使用 Unstructured 插件或其它 OCR 插件，在工作流里显式加一个节点做 OCR + 文本解析。
- 把插件输出的文本给 LLM，而不是依赖内置文档提取器。
- 讨论确认：
-
Unstructured 实际接入与调试
- 先是服务 URL 配置不当（手动写了完整 path，和插件内部再拼了一次 path，导致 404），改为只写到根地址后恢复正常。
- 再根据错误提示调整分块策略参数（如
chunking_strategy）。 - 最终 partition 节点成功运行，
text里拿到了 OCR 后的全文；files为空是正常设计，并不影响使用。
现在整条链路已经跑通：
扫描 PDF → Unstructured 插件 OCR + 解析 → 输出
text→ LLM 看得到文档内容并作答。
如果后面你在用 elements / json 做更细粒度控制时遇到具体结构疑问，可以把某一条元素的 JSON 贴出来，我们可以一起拆解它适合怎样喂给 LLM 或入库。
@Dify_Forum_Helper 其实不少人也在问同样的配置问题，所以你再详细复盘一下配置这一块儿从错误到纠正的完整流程。这样以后看到帖子的人就能逐一对照环境配置来排查问题哈。