Feat: Support passing knowledge base id as variable in retrieval component

[notsyncing]

What problem does this PR solve?

Fix #6600

Hello, I have the same business requirement as #6600. My use case is:

We have many departments (> 20 now and increasing), and each department has its own knowledge base. Because the agent workflow is the same, so I want to change the knowledge base on the fly, instead of creating agents for every department.

It now looks like this:

Knowledge bases can be selected from the dropdown, and passed through the variables in the table. All selected knowledge bases are used for retrieval.

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

[asiroliu]

@KevinHuSh
Successfully validated all Agent Templates in this version - all templates are functioning normally with proper conversational responses.

[wsxiaotiana]

@notsyncing @KevinHuSh Hi, I really appreciate your team's hard work. But this feature hasn't been merged after two weeks of validation. Could you share the timeline? Thanks a lot.

[asiroliu]

@notsyncing
I've performed the following validation steps using your latest commit

1. Successfully built Docker image from latest commit (743751d)
2. Created test knowledge bases:

• Cash Management
• The Chu Shi Biao

3. Initialized simple agent

4. Retrieved KB ID for "The Chu Shi Biao": 7fd6509024ad11f0ae5f1e318b07bb72

5. Test question about Cash Management

6. Test question about The Chu Shi Biao

[asiroliu]

@notsyncing
Actually, KB names are already unique in our system (db_models.py#L591)

Could we consider using KB names directly instead?

[notsyncing]

Could we consider using KB names directly instead?

In our use case, we are passing KB ids from another program, so we don't need KB names. But I think it's better to add a knowledge base type input to the Begin component, and reuse the existing knowledge base selector for that type, so we can simply select KBs from the debug input. What do you think about this?

[notsyncing]

Actually, KB names are already unique in our system (db_models.py#L591)

Also, the index=True does not seem to mean unique=True, according to peewee document https://docs.peewee-orm.com/en/latest/peewee/models.html

[asiroliu]

You're right. The KB name uniqueness isn't enforced by index=True here—it's maintained by code like dataset.py#L139

[notsyncing]

You're right. The KB name uniqueness isn't enforced by index=True here—it's maintained by code like [dataset.py#L139]

Okay. Even you have enforced this, I still advice using id instead of name here:

1. When using ragflow as a backend service (like our use case), we usually prefer an id instead of a name, because name may change, or may cause some encoding issues with some non-UTF8 client.
2. When providing ragflow's frontend to user, we can use a selector (like the kb selector in the Retrieval component) for this, to keep a user-friendly behavior, because user may enter a wrong name and was not aware of it until an error occurs. The selector still gives id underneath.