Thank you for the explanation.

I understand that the uploaded file and the configured knowledge base may be treated as two separate context sources. However, even if this is the intended design, I think the current interaction is not very convenient.

In practice, users may have three different needs for each message:

1. Use only the uploaded file.
2. Use only the configured knowledge base.
3. Use both the uploaded file and the knowledge base.

At the moment, if I only want to analyze a temporary uploaded file, I may need to remove or switch the knowledge base configuration first. This is inconvenient, especially when the assistant is already connected to multiple knowledge bases.

A per-message retrieval scope option, such as “Uploaded file only / Knowledge base only / Both”, would make this behavior much clearer and easier to control.

I am currently using RAGFlow v0.24.0. Could you also confirm whether the latest version still behaves in the same way? In my case, when the configured knowledge base does not retrieve relevant content, the response may be empty even though a file has been uploaded. Therefore, I am also wondering whether the knowledge-base empty-response logic may be triggered before the uploaded file content is added to the model context.

Thank you again for your help.

@zzming-tjufe Thanks for the additional context—it helps clarify what you're observing.

From what I can find, I couldn't find any documentation indicating that this behavior has changed in the latest releases. The current documentation still treats:

• Knowledge base retrieval (retrieving indexed chunks from the selected dataset), and
• Uploaded files in Chat/Agent (passed directly to the model and not ingested into a knowledge base)

as two separate mechanisms. :contentReference[oaicite:0]{index=0}

So as of the latest documentation, it still appears to be the intended design rather than a documented change.

Regarding this part:

"When the configured knowledge base does not retrieve relevant content, the response may be empty even though a file has been uploaded."

That is particularly interesting. If the uploaded file is always added to the model context independently of KB retrieval, I would have expected the model to at least attempt to answer from the uploaded file.

This makes me wonder whether the retrieval pipeline is short-circuiting before the uploaded file context is incorporated. I couldn't find documentation confirming the internal execution order, so I can't say whether that's expected behavior or a bug.

One way to verify would be to try the exact same uploaded file in:

1. A chat without any knowledge base selected.
2. A chat with the knowledge base selected, but using the identical prompt.

If (1) answers correctly from the uploaded file while (2) returns an empty response because no KB chunks were retrieved, I'd be inclined to consider that a bug (or at least an unexpected interaction), since the uploaded file should still be available to the model regardless of retrieval results.

Your suggestion of a per-message retrieval scope such as:

• Uploaded file only
• Knowledge base only
• Both

also seems like a reasonable feature request. It would remove the ambiguity and give users explicit control over which context source should be used for a given message.

If this solves your problem, feel free to mark it as the accepted answer so others can find it easily.

Thank you for the additional explanation. I checked api/db/services/dialog_service.py in both RAGFlow v0.26.4 and the current main branch, and I now have a more specific understanding of the issue.

According to the source code, text attachments uploaded in chat are first read through split_file_attachments() and stored in attachments_. Therefore, it may be more accurate to say that the attachments are first converted into text context rather than being passed to the model completely unprocessed.

However, the knowledge base retrieval is performed afterward, and the current execution order appears to include the following logic:

if not knowledges and prompt_config.get("empty_response"):
    ...
    return

Only after this condition does the code add the uploaded attachment content to the system prompt:

system_content = prompt_config["system"].format(**kwargs) + attachments_

This appears to be the same in both v0.26.4 and the current main branch.

Therefore, when the configured knowledge base retrieves no relevant content and empty_response is enabled, the system may return before the uploaded file content is added to the model context. This seems consistent with the behavior I encountered: the file was uploaded successfully, but because the original knowledge base did not retrieve any relevant content, the final response was still empty.

If my understanding is correct, there may be two separate issues here:

1. A possible bug: When a valid chat attachment exists, a failed knowledge base retrieval should perhaps not trigger empty_response before the attachment content is passed to the model.
2. A feature or UX request: Users currently seem unable to choose the retrieval scope for each individual message, such as “uploaded file only,” “knowledge base only,” or “both.” When a user only wants to analyze a temporary file, they may need to remove or change the assistant’s existing knowledge base configuration, which is inconvenient in practice.

I understand that uploaded files and knowledge bases may be designed as two separate context sources, but I would like to confirm the following:

• Is the execution order described above intentional?
• When a valid chat attachment exists, should a failed knowledge base retrieval still trigger empty_response immediately?
• Would it be more appropriate to submit this as a bug issue or as a feature request?
• Alternatively, would you recommend submitting them separately: one bug issue for the early-return behavior and one feature request for a per-message retrieval scope selector?

Thank you again for your help.