[Question]: RAGFlow Chat assistant seems unstable and find nothing in the beginning of chatting.

[Bob123Yang]

Self Checks

• [x] I have searched for existing issues search for existing issues, including closed ones.
• [x] I confirm that I am using English to submit this report (Language Policy).
• [x] Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
• [x] Please do not modify this template :) and fill in all the required fields.

Describe your problem

1. Retrieval testing pass for knowledge base which name is "JSON_1304" displayed in the below picture.
2. Create the chat assistant and ask 3 questions continuously without any other interruption as the below picture:
   • Q1: "LRP-1205" and answer is something like nothing found.
   • Q2: "help summarize the knowledge base" and answer is still something like nothing found.
   • Q3: Repeat the Q1 to input "LRP-1205" and now got the right answer.

Why does the chat assistant say something like nothing found for Q1 and Q2 after The retrieval testing passed and then show the right answer for the repeated Q1?

Can you provide some method to check whether the user's query was sent to the embedding database successfully? Or you can give me some debug methods that I can use for the next time encountering the same issue.

[dosubot[bot]]

The most common reasons for the chat assistant returning "nothing found" at first—even when retrieval testing passes—are configuration mismatches and stricter retrieval settings in the chat assistant. For example, the chat may use a higher similarity threshold (like 0.2) than the retrieval test (which defaults to 0.0), or the {knowledge} variable might be missing or misconfigured in the system prompt, which is required for retrieved content to reach the LLM and generate an answer. Also, embedding model mismatches or metadata filters can cause the chat to miss relevant chunks even if the retrieval test works fine. See this explanation and this one.

To check if your query is reaching the embedding database, use the "light bulb" icon in the chat UI—if it shows retrieved content, the query made it through; if not, the problem is likely in retrieval or configuration, not the LLM itself (source). You can also inspect backend logs for retrieval and embedding calls, which include debug info about queries and results.

For debugging, make sure:

• The {knowledge} variable is present in both the chat configuration and the system prompt (source).
• The similarity threshold and top_k/top_n settings match between retrieval test and chat assistant (source).
• The same embedding model is used for both the knowledge base and the chat assistant (source).
• All documents are fully parsed and indexed.
• Metadata filters are not excluding relevant documents.
• If you see inconsistent results when repeating questions, try starting a new session, as repeated questions in the same session can sometimes confuse the system (source).

If you’re running an older version, consider upgrading to the latest nightly Docker image, as some retrieval bugs have been fixed in recent releases (source).

To reply, just mention @dosu.

---

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

[Bob123Yang]

Really not good to use!

All the reasons mentioned by @dosu don't exist and I stop the server by "docker compose down -v" and reboot all the servers and load the model again successfully and then create the dataset again with retrieval testing pass and create the chat assistant linked to the dataset with the matching configuration, but still nothing found!!!

so beautiful structure data with satisfied retrieval test result but always appears stupid at the chat assistant. In fact this problem has never bee far away from me but it is becoming more and more blatant. I feel like I'm about to be defeated by it.

[dosubot[bot]]

Based on recent changes and the code, the most likely causes for your issue are hidden configuration mismatches or overly strict metadata filters in the chat assistant. Even if the UI looks correct, the chat assistant pulls its retrieval parameters (like similarity threshold, top_k, rerank model, and especially metadata filters) from a dialog config stored in the backend database, which can become stale or incomplete—especially after recreating assistants or restarting with docker compose down -v (which also wipes all data and may require a full re-import) [source].

Recent updates added metadata filtering (disabled, automatic, manual) to the chat config. If set to "manual" with restrictive conditions, or if the config is out of sync, the chat may return "nothing found" even when retrieval tests succeed [source][source]. Also, the chat and retrieval test endpoints use different default similarity thresholds (chat: 0.2, test: 0.0), which can cause discrepancies [source].

To debug:

1. Double-check the chat assistant's metadata filter mode and conditions—set to "disabled" for testing.
2. Compare the similarity threshold, top_k, and rerank settings in both the chat config and retrieval test.
3. After recreating the assistant, verify that the backend dialog config matches the UI (sometimes changes don't propagate).
4. Check backend logs for the actual retrieval parameters used during chat queries.
5. If you use SQL-based retrieval (triggered by field mapping), make sure the knowledge base IDs are correctly filtered [source].

If you still get "nothing found," try creating a new assistant with minimal config (no metadata filters, default thresholds) and see if retrieval works. This will help isolate whether the problem is with config propagation or something deeper in the retrieval pipeline.

To reply, just mention @dosu.

---

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

[Bob123Yang]

Yes, metadata filtering = disabled. Here is the log for ragflow-server when displaying nothing found when I input "LRP-1025".

2025-09-09 15:15:58,318 INFO     851859 127.0.0.1 - - [09/Sep/2025 15:15:58] "POST /v1/conversation/set HTTP/1.1" 200 -
2025-09-09 15:15:58,364 INFO     851859 127.0.0.1 - - [09/Sep/2025 15:15:58] "GET /v1/conversation/list?dialog_id=b71273808d2711f0a7c7adcd580052c8 HTTP/1.1" 200 -
2025-09-09 15:15:58,569 INFO     851859 [HISTORY][
  {
    "role": "system",
    "content": "## Role\nYou are a text analyzer.\n\n## Task\nExtract the most important keywords/phrases of a given piece of text content.\n\n## Requirements\n- Summarize the text content, and give the top 3 important keywords/phrases.\n- The keywords MUST be in the same language as the given piece of text content.\n- The keywords are delimited by ENGLISH COMMA.\n- Output keywords ONLY.\n\n---\n\n## Text Content\nLRP-1025"
  },
  {
    "role": "user",
    "content": "Output: "
  }
]
2025-09-09 15:15:59,691 INFO     851859 POST http://es01:1200/ragflow_dbc55f578d2411f0a7c7adcd580052c8/_search [status:200 duration:0.111s]
2025-09-09 15:15:59,870 INFO     851859 [HISTORY STREAMLY][
    {
        "role": "system",
        "content": "You are an intelligent assistant. Please summarize the content of the knowledge base to answer the question. Please list the data in the knowledge base and answer in detail. When all knowledge base content is irrelevant to the question, your answer must include the sentence \"The answer you are looking for is not found in the knowledge base!\" Answers need to consider chat history.\n      Here is the knowledge base:\n      \n------\n\n      The above is the knowledge base."
    },
    {
        "role": "user",
        "content": "LRP-1025"
    }
]

[KevinHuSh]

Could you share the file with us? [email protected]

[Bob123Yang]

Hi Kevin,

Sorry for so late response and I have sent you the mail for the document in my knowledge base.

the below version check is a little confuse and not sure if it is normal: (I rebuilt the docker with the name "infiniflow/ragflow:nightly-slim", but the version displayed in ragflow web is "v0.20.5-2-g41cdba19 slim")

[KevinHuSh]

That's normal. The nightly-slim is a docker image version. The system applies the code of version v0.20.5-2....

[mikoskinen]

I think I'm hitting this same issue. The first answer to the first question is quite often stupid/empty. It feels like this answer comes from some cache? When I then ask something like "are you sure?" it then often retrieves the information correctly.

I've tested that the document is correctly retrieved in datasets retrieval testing. So I've been following the Ragflow's logs and it seems to get completely different results from the first search than the retrievel testing.

Can I somehow see the search logs? So that searches are done against the ES and what it finds? They don't seem to be visible in the ES logs.

[mikoskinen]

@Bob123Yang were you able to solve your issue?

[Bob123Yang]

Not yet. I found it related to Top N value setting.

The original Top N max = 30, and I change it to 1000 and rebuild the frontend and the docker just like I did it before, maybe 0.19.0? I cannot remember it exactly. In the previous version, change topN=1000, it's ok, everything seems normal and I can get more than 100 effective records that is limited finally by the context length of LLM or the rerank model.

but after that, ragflow had changed to be unfriendly when I change TopN to the value more than some number, maybe 100 for 0.20.0 and 30 for 0.20.3, and 50 for 0.21.1. For example, when I set topN=200, LLM will always answer with "nothing found" something like that, and once I adjust it to 50 or less than 50, LLM can answer with the normal capability.

I don't know what's the behavior for API calling with topN >=50 (maybe 75 or 99, not sure), but for ragflow web UI, the behavior is bad. I don't know how to solve it.

[KevinHuSh]

The bigger the topN is, the more irrelevant information LLM recieved.

[Bob123Yang]

But now, once topN>30, the retrieval content is empty (click the light bulb in the Chat) and the LLM will answer "nothing found" in the knowledge base instead of many irrelevant information was retrieved to feed the LLM.

By the way, use the web UI to adjust topN = 50 after rebuilding the docker with front file modified to make TopN max = 1000 or 500.

[Magicbook1108]

You finished with it?

[Magicbook1108]

Since there has been no further activity for over three weeks, we will proceed to close this issue. If the problem persists or you have additional questions, please feel free to reopen the issue or create a new one. We’re happy to assist anytime.