langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 12:05:30 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

LLM nodes do not have the variables of knowledge retrieval nodes. #21502

New Issue
Open
opened 2026-02-21 20:12:52 -05:00 by yindo · 7 comments
yindo commented 2026-02-21 20:12:52 -05:00
Owner
Copy Link
Copy Source

Originally created by @libin1219 on GitHub (Jan 7, 2026).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.10.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

LLM nodes do not have the variables of knowledge retrieval nodes.
Image

✔️ Expected Behavior

LLM nodes need to have variables from knowledge retrieval nodes.

❌ Actual Behavior

No response

Originally created by @libin1219 on GitHub (Jan 7, 2026). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.10.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce LLM nodes do not have the variables of knowledge retrieval nodes. <img width="1688" height="844" alt="Image" src="https://github.com/user-attachments/assets/9c49688c-f352-4d2c-b131-2a5ce5826c4e" /> ### ✔️ Expected Behavior LLM nodes need to have variables from knowledge retrieval nodes. ### ❌ Actual Behavior _No response_
yindo added the 🐞 bugstale labels 2026-02-21 20:12:52 -05:00
yindo commented 2026-02-21 20:12:52 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 7, 2026):

This is a known issue in Dify workflows, especially in complex scenarios with multiple branches or LLM nodes: LLM nodes sometimes can't access variables (like the result from a knowledge retrieval node) even when the workflow connections look correct. The root cause is that variables are managed in a centralized pool, and if the engine doesn't properly expose the retrieval node’s output selector to downstream nodes, the LLM node can't resolve the variable—even if the knowledge retrieval node produced it. This leads to missing variables in the LLM node's input list or "variable does not exist" errors when referencing them in prompts (example, example).

Workarounds:

  • Double-check that your workflow connections are correct and try reconnecting or renaming nodes if variables don't appear.
  • Use a Template or Variable Assigner node to convert the knowledge retrieval output to a string and pass it explicitly to the LLM node (discussion).
  • Avoid chaining multiple LLM nodes after a knowledge retrieval node if possible, or ensure each LLM node explicitly references the needed context (issue).
  • If you reference variables manually in prompts, use the node title and variable name (e.g., {{#知识检索.result#}}).

Recent versions of Dify have improved variable handling, so upgrading may help if you're not already on the latest release (changelog). This issue is actively tracked and has been marked as a duplicate by maintainers, so a more robust fix is likely in progress (issue).

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Jan 7, 2026): <!-- Answer --> This is a known issue in Dify workflows, especially in complex scenarios with multiple branches or LLM nodes: LLM nodes sometimes can't access variables (like the result from a knowledge retrieval node) even when the workflow connections look correct. The root cause is that variables are managed in a centralized pool, and if the engine doesn't properly expose the retrieval node’s output selector to downstream nodes, the LLM node can't resolve the variable—even if the knowledge retrieval node produced it. This leads to missing variables in the LLM node's input list or "variable does not exist" errors when referencing them in prompts ([example](https://github.com/langgenius/dify/issues/30026), [example](https://github.com/langgenius/dify/issues/22465)). Workarounds: - Double-check that your workflow connections are correct and try reconnecting or renaming nodes if variables don't appear. - Use a Template or Variable Assigner node to convert the knowledge retrieval output to a string and pass it explicitly to the LLM node ([discussion](https://github.com/langgenius/dify/discussions/24391)). - Avoid chaining multiple LLM nodes after a knowledge retrieval node if possible, or ensure each LLM node explicitly references the needed context ([issue](https://github.com/langgenius/dify/issues/27806)). - If you reference variables manually in prompts, use the node title and variable name (e.g., `{{#知识检索.result#}}`). Recent versions of Dify have improved variable handling, so upgrading may help if you're not already on the latest release ([changelog](https://github.com/langgenius/dify/issues/27806)). This issue is actively tracked and has been marked as a duplicate by maintainers, so a more robust fix is likely in progress ([issue](https://github.com/langgenius/dify/issues/30026)). <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/24c5ecdc-b0ff-43df-ada9-d578512b8427?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/24c5ecdc-b0ff-43df-ada9-d578512b8427?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/24c5ecdc-b0ff-43df-ada9-d578512b8427?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/24c5ecdc-b0ff-43df-ada9-d578512b8427?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/24c5ecdc-b0ff-43df-ada9-d578512b8427?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/24c5ecdc-b0ff-43df-ada9-d578512b8427?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/24c5ecdc-b0ff-43df-ada9-d578512b8427?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=This%20is%20a%20known%20issue%20in%20Dify%20workflows%2C%20especially%20in%20complex%20scenarios%20with%20multiple%20branches%20or%20LLM%20nodes%3A%20LLM%20nodes%20sometimes%20can%27t%20access%20variables%20%28like%20the%20result%20from%20a%20knowledge%20retrieval%20node%29%20even%20when%20the%20workflow%20connections%20look%20correct.%20The%20root%20cause%20is%20that%20variables%20are%20managed%20in%20a%20centralized%20pool%2C%20and%20if%20the%20engine%20doesn%27t%20properly%20expose%20the%20retrieval%20node%E2%80%99s%20output%20selector%20to%20downstream%20nodes%2C%20the%20LLM%20node%20can%27t%20resolve%20the%20variable%E2%80%94even%20if%20the%20knowledge%20retrieval%20node%20produced%20it.%20This%20leads%20to%20missing%20variables%20in%20the%20LLM%20node%27s%20input%20list%20or%20%22variable%20does%20not%20exist%22%20errors%20when%20referencing%20them%20in%20prompts%20%28%5Bexample%5D%28https%3A//github.com/langgenius/dify/issues/30026%29%2C%20%5Bexample%5D%28https%3A//github.com/langgenius/dify/issues/22465%29%29.%0A%0AWorkarounds%3A%20%0A-%20Double-check%20that%20your%20workflow%20connections%20are%20correct%20and%20try%20reconnecting%20or%20renaming%20nodes%20if%20variables%20don%27t%20appear.%0A-%20Use%20a%20Template%20or%20Variable%20Assigner%20node%20to%20convert%20the%20knowledge%20retrieval%20output%20to%20a%20string%20and%20pass%20it%20explicitly%20to%20the%20LLM%20node%20%28%5Bdiscussion%5D%28https%3A//github.com/langgenius/dify/discussions/24391%29%29.%0A-%20Avoid%20chaining%20multiple%20LLM%20nodes%20after%20a%20knowledge%20retrieval%20node%20if%20possible%2C%20or%20ensure%20each%20LLM%20node%20explicitly%20references%20the%20needed%20context%20%28%5Bissue%5D%28https%3A//github.com/langgenius/dify/issues/27806%29%29.%0A-%20If%20you%20reference%20variables%20manually%20in%20prompts%2C%20use%20the%20node%20title%20and%20variable%20name%20%28e.g.%2C%20%60%7B%7B%23%E7%9F%A5%E8%AF%86%E6%A3%80%E7%B4%A2.result%23%7D%7D%60%29.%0A%0ARecent%20versions%20of%20Dify%20have%20improved%20variable%20handling%2C%20so%20upgrading%20may%20help%20if%20you%27re%20not%20already%20on%20the%20latest%20release%20%28%5Bchangelog%5D%28https%3A//github.com/langgenius/dify/issues/27806%29%29.%20This%20issue%20is%20actively%20tracked%20and%20has%20been%20marked%20as%20a%20duplicate%20by%20maintainers%2C%20so%20a%20more%20robust%20fix%20is%20likely%20in%20progress%20%28%5Bissue%5D%28https%3A//github.com/langgenius/dify/issues/30026%29%29.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/30696)
yindo commented 2026-02-21 20:12:52 -05:00
Author
Owner
Copy Link
Copy Source

@libin1219 commented on GitHub (Jan 7, 2026):

Image It seems that my code doesn't retrieve this variable information.
@libin1219 commented on GitHub (Jan 7, 2026): <img width="1638" height="855" alt="Image" src="https://github.com/user-attachments/assets/f872aa32-19cd-4b27-b3f4-a102df48df4d" /> It seems that my code doesn't retrieve this variable information.
yindo commented 2026-02-21 20:12:52 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 7, 2026):

The most common reason LLM nodes can't access variables from knowledge retrieval nodes is a workflow connection or variable mapping issue. In Dify, variables are managed in a centralized pool and referenced using the node's title and variable name, like {{#知识检索.result#}}. If you use nested properties (e.g., {{知识检索.result.content}}), this may not always work—only top-level variables are guaranteed to be accessible in all contexts. If you need a nested property, use a Code node to extract it and pass it as a new variable downstream1 2 .

To troubleshoot:

  • Make sure the knowledge retrieval node is directly connected to the LLM node.
  • Use the variable picker in the UI (not manual typing) to insert variables into your prompt.
  • If the variable doesn't appear, try reconnecting or renaming the knowledge retrieval node.
  • If you chain multiple LLM nodes after a knowledge retrieval node, variable propagation can break—try to avoid this or explicitly pass the needed variable to each LLM node3 .
  • Upgrading to a newer Dify version may help, as recent releases improved variable handling.

If you still can't retrieve the variable, check for any error messages or logs, as there could be a misconfiguration or a model-specific issue.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Jan 7, 2026): <!-- Answer --> The most common reason LLM nodes can't access variables from knowledge retrieval nodes is a workflow connection or variable mapping issue. In Dify, variables are managed in a centralized pool and referenced using the node's title and variable name, like `{{#知识检索.result#}}`. If you use nested properties (e.g., `{{知识检索.result.content}}`), this may not always work—only top-level variables are guaranteed to be accessible in all contexts. If you need a nested property, use a Code node to extract it and pass it as a new variable downstream[^1][^2]. To troubleshoot: - Make sure the knowledge retrieval node is directly connected to the LLM node. - Use the variable picker in the UI (not manual typing) to insert variables into your prompt. - If the variable doesn't appear, try reconnecting or renaming the knowledge retrieval node. - If you chain multiple LLM nodes after a knowledge retrieval node, variable propagation can break—try to avoid this or explicitly pass the needed variable to each LLM node[^3]. - Upgrading to a newer Dify version may help, as recent releases improved variable handling. If you still can't retrieve the variable, check for any error messages or logs, as there could be a misconfiguration or a model-specific issue. [^1]: [Variable reference and workflow connection details](https://github.com/langgenius/dify/issues/22465) [^2]: [Nested property limitations and workarounds](https://github.com/langgenius/dify/issues/23007) [^3]: [Known issue with multiple LLM nodes and workarounds](https://github.com/langgenius/dify/issues/27806) <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/ec0e638d-8d62-46de-863c-8911ef2460db?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/ec0e638d-8d62-46de-863c-8911ef2460db?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/ec0e638d-8d62-46de-863c-8911ef2460db?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/ec0e638d-8d62-46de-863c-8911ef2460db?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/ec0e638d-8d62-46de-863c-8911ef2460db?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/ec0e638d-8d62-46de-863c-8911ef2460db?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/ec0e638d-8d62-46de-863c-8911ef2460db?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=The%20most%20common%20reason%20LLM%20nodes%20can%27t%20access%20variables%20from%20knowledge%20retrieval%20nodes%20is%20a%20workflow%20connection%20or%20variable%20mapping%20issue.%20In%20Dify%2C%20variables%20are%20managed%20in%20a%20centralized%20pool%20and%20referenced%20using%20the%20node%27s%20title%20and%20variable%20name%2C%20like%20%60%7B%7B%23%E7%9F%A5%E8%AF%86%E6%A3%80%E7%B4%A2.result%23%7D%7D%60.%20If%20you%20use%20nested%20properties%20%28e.g.%2C%20%60%7B%7B%E7%9F%A5%E8%AF%86%E6%A3%80%E7%B4%A2.result.content%7D%7D%60%29%2C%20this%20may%20not%20always%20work%E2%80%94only%20top-level%20variables%20are%20guaranteed%20to%20be%20accessible%20in%20all%20contexts.%20If%20you%20need%20a%20nested%20property%2C%20use%20a%20Code%20node%20to%20extract%20it%20and%20pass%20it%20as%20a%20new%20variable%20downstream%5B%5E1%5D%5B%5E2%5D.%0A%0ATo%20troubleshoot%3A%0A-%20Make%20sure%20the%20knowledge%20retrieval%20node%20is%20directly%20connected%20to%20the%20LLM%20node.%0A-%20Use%20the%20variable%20picker%20in%20the%20UI%20%28not%20manual%20typing%29%20to%20insert%20variables%20into%20your%20prompt.%0A-%20If%20the%20variable%20doesn%27t%20appear%2C%20try%20reconnecting%20or%20renaming%20the%20knowledge%20retrieval%20node.%0A-%20If%20you%20chain%20multiple%20LLM%20nodes%20after%20a%20knowledge%20retrieval%20node%2C%20variable%20propagation%20can%20break%E2%80%94try%20to%20avoid%20this%20or%20explicitly%20pass%20the%20needed%20variable%20to%20each%20LLM%20node%5B%5E3%5D.%0A-%20Upgrading%20to%20a%20newer%20Dify%20version%20may%20help%2C%20as%20recent%20releases%20improved%20variable%20handling.%0A%0AIf%20you%20still%20can%27t%20retrieve%20the%20variable%2C%20check%20for%20any%20error%20messages%20or%20logs%2C%20as%20there%20could%20be%20a%20misconfiguration%20or%20a%20model-specific%20issue.%0A%0A%5B%5E1%5D%3A%20%5BVariable%20reference%20and%20workflow%20connection%20details%5D%28https%3A//github.com/langgenius/dify/issues/22465%29%0A%5B%5E2%5D%3A%20%5BNested%20property%20limitations%20and%20workarounds%5D%28https%3A//github.com/langgenius/dify/issues/23007%29%0A%5B%5E3%5D%3A%20%5BKnown%20issue%20with%20multiple%20LLM%20nodes%20and%20workarounds%5D%28https%3A//github.com/langgenius/dify/issues/27806%29)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/30696)
yindo commented 2026-02-21 20:12:52 -05:00
Author
Owner
Copy Link
Copy Source

@libin1219 commented on GitHub (Jan 7, 2026):

The knowledge retrieval node is directly connected to the LLM node, but the variables are not displayed in the LLM node. How can I fix this?

@libin1219 commented on GitHub (Jan 7, 2026): The knowledge retrieval node is directly connected to the LLM node, but the variables are not displayed in the LLM node. How can I fix this?
yindo commented 2026-02-21 20:12:52 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 7, 2026):

This usually happens due to workflow connection or UI mapping issues, not a backend bug. Here’s how to fix it:

  1. In the LLM node, use the variable picker (not manual typing) to add the knowledge retrieval node’s output—look for the node’s title (e.g., “知识检索”) and select result or a subfield like result.content. If you don’t see it, try reconnecting the nodes or renaming the knowledge retrieval node to something unique, then check the picker again. This often refreshes the variable list and resolves the issue [source].

  2. If the output is an array/object (which is common for knowledge retrieval), LLM prompts only accept string variables. Add a Template node between the knowledge retrieval and LLM nodes to convert the result into a string, then pass that to the LLM node [source].

  3. If you have multiple LLM nodes after a knowledge retrieval node, variable propagation can break. Try to avoid chaining LLM nodes, or explicitly pass the needed context variable to each LLM node [source].

  4. If you change the workflow structure or LLM model, re-add the variable in the UI and restart your containers to ensure the changes take effect.

If you still don’t see the variable, check your Docker logs for errors, and make sure all required nodes are present and connected. Upgrading to the latest Dify version may also help, as recent releases improved variable handling in workflows.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Jan 7, 2026): <!-- Answer --> This usually happens due to workflow connection or UI mapping issues, not a backend bug. Here’s how to fix it: 1. In the LLM node, use the variable picker (not manual typing) to add the knowledge retrieval node’s output—look for the node’s title (e.g., “知识检索”) and select `result` or a subfield like `result.content`. If you don’t see it, try reconnecting the nodes or renaming the knowledge retrieval node to something unique, then check the picker again. This often refreshes the variable list and resolves the issue [[source]](https://github.com/langgenius/dify/issues/22465#issuecomment-3076542634). 2. If the output is an array/object (which is common for knowledge retrieval), LLM prompts only accept string variables. Add a Template node between the knowledge retrieval and LLM nodes to convert the result into a string, then pass that to the LLM node [[source]](https://github.com/langgenius/dify/issues/18580). 3. If you have multiple LLM nodes after a knowledge retrieval node, variable propagation can break. Try to avoid chaining LLM nodes, or explicitly pass the needed context variable to each LLM node [[source]](https://github.com/langgenius/dify/issues/27806#issuecomment-3484526434). 4. If you change the workflow structure or LLM model, re-add the variable in the UI and restart your containers to ensure the changes take effect. If you still don’t see the variable, check your Docker logs for errors, and make sure all required nodes are present and connected. Upgrading to the latest Dify version may also help, as recent releases improved variable handling in workflows. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/23c96fb7-0cd6-4c5f-a942-1af209ad8655?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/23c96fb7-0cd6-4c5f-a942-1af209ad8655?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/23c96fb7-0cd6-4c5f-a942-1af209ad8655?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/23c96fb7-0cd6-4c5f-a942-1af209ad8655?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/23c96fb7-0cd6-4c5f-a942-1af209ad8655?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/23c96fb7-0cd6-4c5f-a942-1af209ad8655?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/23c96fb7-0cd6-4c5f-a942-1af209ad8655?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=This%20usually%20happens%20due%20to%20workflow%20connection%20or%20UI%20mapping%20issues%2C%20not%20a%20backend%20bug.%20Here%E2%80%99s%20how%20to%20fix%20it%3A%0A%0A1.%20In%20the%20LLM%20node%2C%20use%20the%20variable%20picker%20%28not%20manual%20typing%29%20to%20add%20the%20knowledge%20retrieval%20node%E2%80%99s%20output%E2%80%94look%20for%20the%20node%E2%80%99s%20title%20%28e.g.%2C%20%E2%80%9C%E7%9F%A5%E8%AF%86%E6%A3%80%E7%B4%A2%E2%80%9D%29%20and%20select%20%60result%60%20or%20a%20subfield%20like%20%60result.content%60.%20If%20you%20don%E2%80%99t%20see%20it%2C%20try%20reconnecting%20the%20nodes%20or%20renaming%20the%20knowledge%20retrieval%20node%20to%20something%20unique%2C%20then%20check%20the%20picker%20again.%20This%20often%20refreshes%20the%20variable%20list%20and%20resolves%20the%20issue%20%5B%5Bsource%5D%5D%28https%3A//github.com/langgenius/dify/issues/22465%23issuecomment-3076542634%29.%0A%0A2.%20If%20the%20output%20is%20an%20array/object%20%28which%20is%20common%20for%20knowledge%20retrieval%29%2C%20LLM%20prompts%20only%20accept%20string%20variables.%20Add%20a%20Template%20node%20between%20the%20knowledge%20retrieval%20and%20LLM%20nodes%20to%20convert%20the%20result%20into%20a%20string%2C%20then%20pass%20that%20to%20the%20LLM%20node%20%5B%5Bsource%5D%5D%28https%3A//github.com/langgenius/dify/issues/18580%29.%0A%0A3.%20If%20you%20have%20multiple%20LLM%20nodes%20after%20a%20knowledge%20retrieval%20node%2C%20variable%20propagation%20can%20break.%20Try%20to%20avoid%20chaining%20LLM%20nodes%2C%20or%20explicitly%20pass%20the%20needed%20context%20variable%20to%20each%20LLM%20node%20%5B%5Bsource%5D%5D%28https%3A//github.com/langgenius/dify/issues/27806%23issuecomment-3484526434%29.%0A%0A4.%20If%20you%20change%20the%20workflow%20structure%20or%20LLM%20model%2C%20re-add%20the%20variable%20in%20the%20UI%20and%20restart%20your%20containers%20to%20ensure%20the%20changes%20take%20effect.%0A%0AIf%20you%20still%20don%E2%80%99t%20see%20the%20variable%2C%20check%20your%20Docker%20logs%20for%20errors%2C%20and%20make%20sure%20all%20required%20nodes%20are%20present%20and%20connected.%20Upgrading%20to%20the%20latest%20Dify%20version%20may%20also%20help%2C%20as%20recent%20releases%20improved%20variable%20handling%20in%20workflows.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/30696)
yindo commented 2026-02-21 20:12:53 -05:00
Author
Owner
Copy Link
Copy Source

@libin1219 commented on GitHub (Jan 7, 2026):

The variable is displayed in the context, but not in the system prompt.
Image
If Knowledge Retrieval 3 is set as the context, large models will have problems recognizing videos.

@libin1219 commented on GitHub (Jan 7, 2026): The variable is displayed in the context, but not in the system prompt. <img width="1662" height="843" alt="Image" src="https://github.com/user-attachments/assets/467bc41e-e0f6-46c9-866e-c261cc93a03f" /> If Knowledge Retrieval 3 is set as the context, large models will have problems recognizing videos.
yindo commented 2026-02-21 20:12:53 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 7, 2026):

The reason you see the knowledge retrieval variable in the context but not in the system prompt is due to how Dify filters variable types for each input area. The context field allows complex types like arrays and objects (which is what knowledge retrieval outputs), but the system prompt (prompt template) only accepts strings, numbers, and a few simple types. That’s why the knowledge retrieval result appears in the context picker but is filtered out from the system prompt variable picker—arrays/objects can’t be used directly in prompts and must be converted to strings first1 2 .

To use the knowledge retrieval result in your system prompt, add a Template node after the knowledge retrieval node to convert the result array/object into a string, then connect that output to your LLM node and reference it in the prompt3 4 .

For video or file variables: LLM nodes only support file/array-file types in prompts, and most models require a Document Extractor node (for text extraction) or vision mode enabled to process media. Some large models in Dify 1.10.1 have known bugs and may not recognize video input at all, even if the workflow is set up correctly5 6 .

Let me know if you want a step-by-step example for your workflow or need help with a specific model or node setup.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Jan 7, 2026): <!-- Answer --> The reason you see the knowledge retrieval variable in the context but not in the system prompt is due to how Dify filters variable types for each input area. The context field allows complex types like arrays and objects (which is what knowledge retrieval outputs), but the system prompt (prompt template) only accepts strings, numbers, and a few simple types. That’s why the knowledge retrieval result appears in the context picker but is filtered out from the system prompt variable picker—arrays/objects can’t be used directly in prompts and must be converted to strings first[^1][^2]. To use the knowledge retrieval result in your system prompt, add a Template node after the knowledge retrieval node to convert the result array/object into a string, then connect that output to your LLM node and reference it in the prompt[^3][^4]. For video or file variables: LLM nodes only support file/array-file types in prompts, and most models require a Document Extractor node (for text extraction) or vision mode enabled to process media. Some large models in Dify 1.10.1 have known bugs and may not recognize video input at all, even if the workflow is set up correctly[^5][^6]. [^1]: [Variable filtering logic in Dify UI](https://github.com/langgenius/dify/blob/187bfafe8b001cf8afad95e257374f2b2e7e5983/web/app/components/workflow/nodes/llm/panel.tsx#L46-L245) [^2]: [Knowledge retrieval outputs are arrays/objects, filtered out from prompt editor](https://github.com/langgenius/dify/blob/187bfafe8b001cf8afad95e257374f2b2e7e5983/web/app/components/workflow/constants.ts#L140-L262) [^3]: [Template node workaround for prompt usage](https://github.com/langgenius/dify/issues/18580) [^4]: [Variable propagation and prompt referencing details](https://github.com/langgenius/dify/issues/22465) [^5]: [Document Extractor and model support for files/media](https://github.com/langgenius/dify/issues/23886) [^6]: [Known bug: large models not recognizing video input in 1.10.1](https://github.com/langgenius/dify/issues/30639) Let me know if you want a step-by-step example for your workflow or need help with a specific model or node setup. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/f2cb8350-1cc3-4eab-b696-2a5845b9b8f1?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/f2cb8350-1cc3-4eab-b696-2a5845b9b8f1?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/f2cb8350-1cc3-4eab-b696-2a5845b9b8f1?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/f2cb8350-1cc3-4eab-b696-2a5845b9b8f1?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/f2cb8350-1cc3-4eab-b696-2a5845b9b8f1?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/f2cb8350-1cc3-4eab-b696-2a5845b9b8f1?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/f2cb8350-1cc3-4eab-b696-2a5845b9b8f1?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=The%20reason%20you%20see%20the%20knowledge%20retrieval%20variable%20in%20the%20context%20but%20not%20in%20the%20system%20prompt%20is%20due%20to%20how%20Dify%20filters%20variable%20types%20for%20each%20input%20area.%20The%20context%20field%20allows%20complex%20types%20like%20arrays%20and%20objects%20%28which%20is%20what%20knowledge%20retrieval%20outputs%29%2C%20but%20the%20system%20prompt%20%28prompt%20template%29%20only%20accepts%20strings%2C%20numbers%2C%20and%20a%20few%20simple%20types.%20That%E2%80%99s%20why%20the%20knowledge%20retrieval%20result%20appears%20in%20the%20context%20picker%20but%20is%20filtered%20out%20from%20the%20system%20prompt%20variable%20picker%E2%80%94arrays/objects%20can%E2%80%99t%20be%20used%20directly%20in%20prompts%20and%20must%20be%20converted%20to%20strings%20first%5B%5E1%5D%5B%5E2%5D.%0A%0ATo%20use%20the%20knowledge%20retrieval%20result%20in%20your%20system%20prompt%2C%20add%20a%20Template%20node%20after%20the%20knowledge%20retrieval%20node%20to%20convert%20the%20result%20array/object%20into%20a%20string%2C%20then%20connect%20that%20output%20to%20your%20LLM%20node%20and%20reference%20it%20in%20the%20prompt%5B%5E3%5D%5B%5E4%5D.%0A%0AFor%20video%20or%20file%20variables%3A%20LLM%20nodes%20only%20support%20file/array-file%20types%20in%20prompts%2C%20and%20most%20models%20require%20a%20Document%20Extractor%20node%20%28for%20text%20extraction%29%20or%20vision%20mode%20enabled%20to%20process%20media.%20Some%20large%20models%20in%20Dify%201.10.1%20have%20known%20bugs%20and%20may%20not%20recognize%20video%20input%20at%20all%2C%20even%20if%20the%20workflow%20is%20set%20up%20correctly%5B%5E5%5D%5B%5E6%5D.%0A%0A%5B%5E1%5D%3A%20%5BVariable%20filtering%20logic%20in%20Dify%20UI%5D%28https%3A//github.com/langgenius/dify/blob/187bfafe8b001cf8afad95e257374f2b2e7e5983/web/app/components/workflow/nodes/llm/panel.tsx%23L46-L245%29%0A%5B%5E2%5D%3A%20%5BKnowledge%20retrieval%20outputs%20are%20arrays/objects%2C%20filtered%20out%20from%20prompt%20editor%5D%28https%3A//github.com/langgenius/dify/blob/187bfafe8b001cf8afad95e257374f2b2e7e5983/web/app/components/workflow/constants.ts%23L140-L262%29%0A%5B%5E3%5D%3A%20%5BTemplate%20node%20workaround%20for%20prompt%20usage%5D%28https%3A//github.com/langgenius/dify/issues/18580%29%0A%5B%5E4%5D%3A%20%5BVariable%20propagation%20and%20prompt%20referencing%20details%5D%28https%3A//github.com/langgenius/dify/issues/22465%29%0A%5B%5E5%5D%3A%20%5BDocument%20Extractor%20and%20model%20support%20for%20files/media%5D%28https%3A//github.com/langgenius/dify/issues/23886%29%0A%5B%5E6%5D%3A%20%5BKnown%20bug%3A%20large%20models%20not%20recognizing%20video%20input%20in%201.10.1%5D%28https%3A//github.com/langgenius/dify/issues/30639%29%0A%0ALet%20me%20know%20if%20you%20want%20a%20step-by-step%20example%20for%20your%20workflow%20or%20need%20help%20with%20a%20specific%20model%20or%20node%20setup.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/30696)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label stale 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#21502
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?