In RAGFlow, how do top_k and top_n differ in a chat assistant's retrieval config?

## Two stages, two limits A RAGFlow retrieval has a funnel shape. Candidates come out of the indexes, get a blended keyword-plus-vector score, are optionally rescored by a rerank model, are filtered by the similarity threshold, and the survivors are cut to a final handful that is rendered into the prompt. `top_k` bounds the top of that funnel; `top_n` bounds the bottom. ## top_k — the candidate pool `top_k` defaults to 1024. It governs how deep the vector search goes before RAGFlow does its own scoring work. A larger pool improves the chance that the genuinely correct chunk is present at all, which matters most on large or heterogeneous knowledge bases where the right passage does not rank near the top on either signal alone. The cost is not free, and it is not linear in the way people expect. Without a reranker, a bigger pool mostly costs search and scoring time. With a rerank model configured, every candidate in the pool is a pair the reranker must score, so pool size becomes the dominant latency and spend term of the whole request. This is why RAGFlow's own guidance flags reranking as time-consuming: the slowness is usually the pool, not the model. If you turn on a reranker and keep a large `top_k`, you have signed up for that cost on every turn. ## top_n — the prompt budget `top_n` defaults to 6. After thresholding, this is how many chunks are formatted into the `{knowledge}` block. It is the direct lever on prompt size: chunk size times `top_n` is roughly your retrieved-context token bill per turn, paid on every message of every conversation. It also interacts with the threshold. The threshold runs first and is a floor on quality; `top_n` runs second and is a cap on quantity. If the threshold already leaves three chunks, a `top_n` of 20 changes nothing. If the threshold is permissive, a large `top_n` fills the prompt with marginal material. ## Tuning them against each other The useful mental model is that `top_k` buys recall and `top_n` spends context. Diagnose which one you need by replaying real queries in the retrieval-testing panel: if the chunk you know is correct never appears at any threshold, the pool or the scoring is wrong and `top_k` or the weight is the lever. If it appears but sits below the cut, `top_n` or the threshold is the lever. If it appears at rank one and the answer is still bad, neither knob is your problem — look at the template and the model. A reasonable production shape is a generous `top_k` with no reranker, or a deliberately reduced `top_k` once a reranker is on, paired with a small `top_n` — because past a handful of chunks the marginal one rarely helps and reliably costs tokens. ## Things people get wrong Treating `top_n` as the thing that controls retrieval quality is the classic error: it only decides how many of the already-selected chunks are used. Assuming a bigger `top_n` is safer is the second: more context is more tokens, more latency, and more chance the model leans on a weak passage. And forgetting that these are per-assistant settings means a knowledge base tuned in the testing panel can behave differently in the assistant that uses it, because the assistant carries its own copies of the values.