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

[PR #10505] feat : add evaluation code for code generator #26843

New Issue
Closed
opened 2026-02-21 20:40:22 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 20:40:22 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/langgenius/dify/pull/10505

State: closed
Merged: No

Checklist:

Important

Please review the checklist below before submitting your pull request.

  • Please open an issue before creating a PR or link to an existing issue
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I ran dev/reformat(backend) and cd web && npx lint-staged(frontend) to appease the lint gods

Description

In this PR, I have created the code to run evaluations for the Code Generator. This PR only includes the code to perform the evaluation, with minimal test cases added, and no actual evaluation has been conducted. These aspects will be addressed in a separate PR.

Background for Adding Evaluation of Code Generator

I want to avoid users choosing not to use the CodeGenerator simply because they’re uncertain about the quality of the generated code.
By evaluating accuracy as part of the product, I believe we can create a reliable standard that users can trust.

Additionally, in the future, I want to allow users to freely choose the LLM specifically for the code generator without needing to change the entire system model. There are several reasons for this. A search on platform X shows that some users are still using GPT-3.5 in dify, while others set their system model to GPT-4o-mini to reduce costs. It’s cumbersome for these users to change system settings every time they need a different model just for code generation. Dify is very convenient, so I want to avoid this inconvenience in only this aspect.

Therefore, I aim to enable model selection specifically within the code generator, regardless of the main system model. For this purpose, I want to establish evaluation criteria to determine the best LLM to use for creating code tailored for Dify. That’s why I'm setting up the evaluation process now.

Requirements for Evaluation

The following will be provided:

  • Instructions
  • Target language
  • Necessary input arguments for the generated code to produce the desired result
  • Ground Truth

Environment for Evaluation

Code execution will take place in the Dify-Sandbox.
Code generation will be performed via the Code Generator API.
The evaluation itself will be conducted using Golang code.

The reason for choosing Go is to package everything into a single binary, making it easy for anyone to run anywhere.
I included a single binary to allow anyone to run it quickly in any environment, but would it be better to remove it?

Evaluation Method

The evaluation simply checks whether the output from executing the generated code matches the expected result.

Currently, I am considering presenting the accuracy results categorized by "model" and "task complexity level."
This will be addressed in a separate PR.

Test Cases

Test cases will be added in a separate PR.

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update, included: Dify Document
  • Improvement, including but not limited to code refactoring, performance optimization, and UI/UX improvement
  • Dependency upgrade

Testing Instructions

スクリーンショット 2024-11-10 22 33 31
**Original Pull Request:** https://github.com/langgenius/dify/pull/10505 **State:** closed **Merged:** No --- # Checklist: > [!IMPORTANT] > Please review the checklist below before submitting your pull request. - [x] Please open an issue before creating a PR or link to an existing issue - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I ran `dev/reformat`(backend) and `cd web && npx lint-staged`(frontend) to appease the lint gods # Description In this PR, I have created the code to run evaluations for the Code Generator. This PR only includes the code to perform the evaluation, with minimal test cases added, and no actual evaluation has been conducted. These aspects will be addressed in a separate PR. ## Background for Adding Evaluation of Code Generator I want to avoid users choosing not to use the CodeGenerator simply because they’re uncertain about the quality of the generated code. By evaluating accuracy as part of the product, I believe we can create a reliable standard that users can trust. Additionally, in the future, I want to allow users to freely choose the LLM specifically for the code generator without needing to change the entire system model. There are several reasons for this. A search on platform X shows that some users are still using GPT-3.5 in dify, while others set their system model to GPT-4o-mini to reduce costs. It’s cumbersome for these users to change system settings every time they need a different model just for code generation. Dify is very convenient, so I want to avoid this inconvenience in only this aspect. Therefore, I aim to enable model selection specifically within the code generator, regardless of the main system model. For this purpose, I want to establish evaluation criteria to determine the best LLM to use for creating code tailored for Dify. That’s why I'm setting up the evaluation process now. ## Requirements for Evaluation The following will be provided: - Instructions - Target language - Necessary input arguments for the generated code to produce the desired result - Ground Truth ## Environment for Evaluation Code execution will take place in the Dify-Sandbox. Code generation will be performed via the Code Generator API. The evaluation itself will be conducted using Golang code. The reason for choosing Go is to package everything into a single binary, making it easy for anyone to run anywhere. I included a single binary to allow anyone to run it quickly in any environment, but would it be better to remove it? ## Evaluation Method The evaluation simply checks whether the output from executing the generated code matches the expected result. Currently, I am considering presenting the accuracy results categorized by "model" and "task complexity level." **This will be addressed in a separate PR.** ## Test Cases **Test cases will be added in a separate PR.** ## Type of Change - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update, included: [Dify Document](https://github.com/langgenius/dify-docs) - [ ] Improvement, including but not limited to code refactoring, performance optimization, and UI/UX improvement - [ ] Dependency upgrade # Testing Instructions <img width="507" alt="スクリーンショット 2024-11-10 22 33 31" src="https://github.com/user-attachments/assets/9f87a52c-512c-47bd-af14-97362b0f056e">
yindo added the pull-request label 2026-02-21 20:40:22 -05:00
yindo closed this issue 2026-02-21 20:40:22 -05:00
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 pull-request
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#26843
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?