在 Dify 上传了 Word 文件,模型却只知道文件名,无法回答里面的内容,先确认工作流有没有完成文本提取。本文面向已能运行一个 LLM 节点的新手,使用一页虚构 DOCX 搭建单文件问答,逐层检查文件、提取文本和模型输入。适用于具备文档提取器的 Dify,接入已配置的国内文本模型;依据 2026 年 10 月 14 日资料整理,未在读者实例实测。
1. 最短路线:文件先变文本,再交给模型
打开一个用于测试的 Workflow,在开始节点添加单文件输入,允许上传文档。接上 Document Extractor 文档提取器,输入选择刚创建的文件变量;再连接 LLM 节点,在用户提示词里通过变量选择器插入提取器的 text 输出。最后把模型回答连接到输出节点。
测试时只上传一份 DOCX,先不要加入知识库、循环或 Agent 工具。提取器负责读文件,模型负责读提取出的内容,两步应该分别观察。不要把 file 对象直接作为普通文本变量放进提示词,期待它自动变成文件正文。
当前 Dify 官方文档说明,文档提取器能把支持的文件转换为文本,单文件输出字符串,多文件输出字符串数组。Document Extractor 本文用单文件模式,是为了把首次排查范围固定下来。
LLM 节点选择已经能正常调用的文本模型。在提示词里写清“根据下面提供的文档文本回答;文档里没有的内容就说未找到”,然后插入 text 和用户问题两个真实变量。变量标记应由你的实例生成,不要照抄另一种平台的花括号语法。
2. 做一页能客观验收的 Word 样本
在本地文档编辑器中写入以下虚构内容,保存为 DOCX。不要使用真实内部通知,也不要加扫描图片或复杂排版。
演示借阅规则 保管地点:南窗柜 可借数量:每人两册 归还时间:周三下午上传后先查看提取器的运行输出。预期 text 包含保管地点、数量和时间三个信息,而不只是名称或下载地址。这里是读者可执行的验证设计,并非本文已经测得的运行日志。
问模型“演示书籍放在哪里,什么时候归还?”时,不要在问题里写出南窗柜或周三下午。只有模型从文档中得到这两个独有字段,才能证明你的链路大致有效。得到一段流畅的阅读建议不算完成这个任务。
| 检查层 | 必须能看到的东西 | 失败时先改哪里 |
|---|---|---|
| 开始输入 | 有实际上传的文件 | 上传字段与文件绑定 |
| 提取输出 | 三项虚构规则文本 | 文档格式和解析过程 |
| 模型输入 | 包含提取器的 text | 提示词变量引用 |
| 最终回答 | 地点和时间符合样本 | 问题和模型能力 |
这张表用于找第一处断点。提取输出为空时,改系统提示词通常没有帮助;提取内容完整却没有进入模型时,反复导出文件也不是最短路径。
3. 不同现象要在不同节点定位
开始节点没有文件值,先看是否绑定到了你刚添加的文件输入,而不是对话文字或另一个上传字段。名称相似不代表同一个变量。测试副本里把输入字段改成容易辨认的名称,可以减少选错概率。
提取器拒绝文件,先确认实际格式。把老格式文件的扩展名改成 docx,不会完成转换;应使用编辑器正常另存。文件损坏、密码保护和解析器不支持的具体结构也需要分别检查,不要为了排障修改生产服务器的沙箱权限。
text 只剩少量字,看看文件主体是不是图片。文本提取路线主要针对可解析文字;拍照嵌入的整页扫描内容需要专门的图像识别处理。本文没有给这条路线添加 OCR,也不承诺普通提取器能完整识别图片里的字。
text 完整,模型回答却像没看到文件,打开模型节点的运行输入,确认实际提示词中包含那三条规则。提示词面板显示一个变量名,不代表运行时一定拿到了对应值。LLM 官方说明支持引用工作流变量,不同模型的原生文件处理能力则需要分别判断。LLM 节点说明
4. 从单文件扩展时,留意输出类型变化
单文件链路稳定后,可以换成两个内容明显不同的 DOCX。此时提取器可能输出数组,不能把它继续当成一份连续文档。如果你的目标是分别回答两份材料的问题,应为每份文本保留文件名或序号,避免把两个来源混在一起后失去可追溯关系。
若只是合并阅读,可先在模板中给每份材料加清晰边界,例如“文件一”和“文件二”。模型提取出的字段应附带来源名称,人工检查是否来自正确文件。不要用一个来自文件一的地点搭配文件二的时间,生成看似完整但实际拼接错误的结论。
长文档不是首次验收样本。随着输入增大,应观察送给模型的文本长度及模型允许的上下文,必要时按章节处理。文件上传成功与模型能接收整份长文本是两种约束,不能因为一个很小的 DOCX 成功就推断上百页材料也可直接处理。
表格内容需额外检查行列对应。提取后可能变成 Markdown 表格,先确认标题和数据仍在正确位置。若复杂合并单元格难以阅读,可在测试副本里把它改成普通表格重新导出,用这个对照判断问题是否来自排版。
5. 保存一份输入到答案的证据
完成首次链路后,记录 Dify 版本、模型名称、文件格式、单文件还是多文件、提取结果是否包含三项规则,以及最终两个答案。实例没有显示某个版本信息时就注明未知,不凭界面样式推断版本。
再改一次样本,把地点换成北门架,保留其他信息。重新上传后应得到新地点。这是检查模型是否用了当前文件的有效方法;如果答案仍是旧值,要对比实际输入,不应先认定模型永久记住了旧文件。
上线前删去虚构样本与输出全文的调试日志,保留必要的状态和长度即可。真实文件上传到模型服务属于数据传输,应沿用你的业务访问与用途约定。求助时分享一页自行制作的同结构样本,通常比分享原业务文件更容易复现。
修复完成的标准是提取器得到正文、模型实际收到该正文、回答符合独有字段。下一步再考虑长文档、批量处理或检索功能。先把这一页走通,能避免在一个缺少提取步骤的工作流上叠加更多节点。
参考资料
- Document Extractor,Dify,更新于 2026-08-27。
- LLM,Dify,更新于 2026-08-27。访问于 2026-10-14。