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

Enhancement: Allow specifying output parameters in LLM node configuration, not just text outputs #5541

New Issue
Closed
opened 2026-02-21 18:11:30 -05:00 by yindo · 3 comments
yindo commented 2026-02-21 18:11:30 -05:00
Owner
Copy Link
Copy Source

Originally created by @xuyi1243 on GitHub (Sep 11, 2024).

Self Checks

  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
  • Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Currently, when configuring an LLM node in the workflow, the output is restricted to text. This limitation makes it difficult to integrate more complex workflows that require multiple structured outputs. It would be beneficial to enhance the LLM node configuration to allow specifying multiple output parameters, such as JSON or key-value pairs, instead of limiting it to just text.
There is a example:
image

2. Additional context or comments

No response

3. Can you help us with this feature?

  • I am interested in contributing to this feature.
Originally created by @xuyi1243 on GitHub (Sep 11, 2024). ### Self Checks - [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 (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [X] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:） - [X] Please do not modify this template :) and fill in all the required fields. ### 1. Is this request related to a challenge you're experiencing? Tell me about your story. Currently, when configuring an LLM node in the workflow, the output is restricted to text. This limitation makes it difficult to integrate more complex workflows that require multiple structured outputs. It would be beneficial to enhance the LLM node configuration to allow specifying multiple output parameters, such as JSON or key-value pairs, instead of limiting it to just text. There is a example: ![image](https://github.com/user-attachments/assets/1ea0e114-d945-4c01-a5cd-90d4ea4f2b8f) ### 2. Additional context or comments _No response_ ### 3. Can you help us with this feature? - [X] I am interested in contributing to this feature.
yindo added the 💪 enhancement label 2026-02-21 18:11:30 -05:00
yindo closed this issue 2026-02-21 18:11:30 -05:00
yindo commented 2026-02-21 18:11:31 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Sep 11, 2024):

@xuyi1243 Hello there! I'm here to assist you with bug fixing, answering questions, and guiding you to become a contributor. Let me know how I can help you.

There are similar discussions related to enhancing the LLM node configuration to support multiple output parameters:

  1. Support for OpenAI Structured Outputs - This discussion is still open and was last updated on 2024-08-29.
  2. Refine tool output parameters - This discussion is also open and was last updated on 2024-08-13.
  3. Suggestions for chatflow - This discussion is open and was last updated on 2024-05-12 [1][2][3].

Regarding your enhancement request, the LLM node configuration can indeed be enhanced to allow specifying multiple output parameters, such as JSON or key-value pairs, instead of just text. The ParameterExtractorNode class already includes functionality to handle JSON responses and extract parameters from them. The _invoke_llm method processes the LLM's response and can handle tool calls that return JSON. Methods like _extract_json_from_tool_call and _extract_complete_json_response are used to extract JSON data from the LLM's response, ensuring that the extracted parameters conform to the expected types and formats [4].

Additionally, the LLM node in Dify's Chatflow/Workflow supports advanced configuration options, including setting response formats and using Jinja-2 templates for more complex prompts. This flexibility allows for the customization of output parameters to meet specific requirements, such as generating JSON or key-value pairs [5][6].

Feel free to contribute to this feature, as it aligns with the existing capabilities and can enhance the flexibility of the LLM node configuration.

To continue talking to Dosu, mention @dosu.

@dosubot[bot] commented on GitHub (Sep 11, 2024): <!-- Greeting --> @xuyi1243 Hello there! I'm here to assist you with bug fixing, answering questions, and guiding you to become a contributor. Let me know how I can help you. <!-- Answer --> There are similar discussions related to enhancing the LLM node configuration to support multiple output parameters: 1. [Support for OpenAI Structured Outputs](https://github.com/langgenius/dify/discussions/7170) - This discussion is still open and was last updated on 2024-08-29. 2. [Refine tool output parameters](https://github.com/langgenius/dify/discussions/7211) - This discussion is also open and was last updated on 2024-08-13. 3. [Suggestions for chatflow](https://github.com/langgenius/dify/discussions/3337) - This discussion is open and was last updated on 2024-05-12 <sup>[[1]](https://github.com/langgenius/dify/discussions/7170)</sup><sup>[[2]](https://github.com/langgenius/dify/discussions/7211)</sup><sup>[[3]](https://github.com/langgenius/dify/discussions/3337)</sup>. Regarding your enhancement request, the LLM node configuration can indeed be enhanced to allow specifying multiple output parameters, such as JSON or key-value pairs, instead of just text. The `ParameterExtractorNode` class already includes functionality to handle JSON responses and extract parameters from them. The `_invoke_llm` method processes the LLM's response and can handle tool calls that return JSON. Methods like `_extract_json_from_tool_call` and `_extract_complete_json_response` are used to extract JSON data from the LLM's response, ensuring that the extracted parameters conform to the expected types and formats <sup>[[4]](https://github.com/langgenius/dify/blob/main/api/core/workflow/nodes/parameter_extractor/parameter_extractor_node.py)</sup>. Additionally, the LLM node in Dify's Chatflow/Workflow supports advanced configuration options, including setting response formats and using Jinja-2 templates for more complex prompts. This flexibility allows for the customization of output parameters to meet specific requirements, such as generating JSON or key-value pairs <sup>[[5]](https://github.com/langgenius/dify-docs/blob/main/en/guides/workflow/node/llm.md)</sup><sup>[[6]](https://github.com/langgenius/dify/blob/main/web/app/components/workflow/nodes/llm/panel.tsx)</sup>. Feel free to contribute to this feature, as it aligns with the existing capabilities and can enhance the flexibility of the LLM node configuration. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.*
yindo commented 2026-02-21 18:11:31 -05:00
Author
Owner
Copy Link
Copy Source

@xuyi1243 commented on GitHub (Sep 11, 2024):

While I understand that the current system, particularly the ParameterExtractorNode, allows for extracting JSON or structured responses from LLM outputs, my concern is more about streamlining this process directly within the LLM node itself. The current workflow requires using an additional node (such as the ParameterExtractorNode) to extract and handle structured data, which adds an extra step and complexity.

What I'm proposing is the ability to specify and extract structured output (e.g., JSON, key-value pairs) directly from the LLM node without needing an additional node to process the results. This would reduce the overhead for users, especially in more straightforward workflows, where the response format could be specified and returned directly in the LLM node configuration. This would also align with how many users expect modern AI workflows to function: being able to generate structured responses without requiring additional parsing nodes.

For instance, allowing the LLM node to natively define outputs such as:

  • Direct JSON structure or variables in the output configuration.
  • Output parameters like response_text, metadata, etc., natively from the LLM node.

This enhancement would simplify workflows, reducing node dependencies and making the overall process more intuitive and efficient.

@xuyi1243 commented on GitHub (Sep 11, 2024): While I understand that the current system, particularly the `ParameterExtractorNode`, allows for extracting JSON or structured responses from LLM outputs, my concern is more about streamlining this process directly within the LLM node itself. The current workflow requires using an additional node (such as the `ParameterExtractorNode`) to extract and handle structured data, which adds an extra step and complexity. What I'm proposing is the ability to specify and extract structured output (e.g., JSON, key-value pairs) directly from the LLM node without needing an additional node to process the results. This would reduce the overhead for users, especially in more straightforward workflows, where the response format could be specified and returned directly in the LLM node configuration. This would also align with how many users expect modern AI workflows to function: being able to generate structured responses without requiring additional parsing nodes. For instance, allowing the LLM node to natively define outputs such as: - Direct JSON structure or variables in the output configuration. - Output parameters like `response_text`, `metadata`, etc., natively from the LLM node. This enhancement would simplify workflows, reducing node dependencies and making the overall process more intuitive and efficient.
yindo commented 2026-02-21 18:11:31 -05:00
Author
Owner
Copy Link
Copy Source

@VincePotato commented on GitHub (Sep 11, 2024):

Thank you for your suggestion. We will include it in our product roadmap.

@VincePotato commented on GitHub (Sep 11, 2024): Thank you for your suggestion. We will include it in our product roadmap.
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 💪 enhancement
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#5541
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?