What this category of data looks like
The data for this category comes from requirement specification documents, test environment configuration records, customer business sample data, and defect tracking systems. Daily produced documents include UAT use cases, acceptance issue tickets, acceptance reports, and signed confirmation forms. Data is updated once per delivery phase or per version iteration. Document structures include fields such as scenario description, preconditions, expected results, reproduction steps, and associated versions. Some documents have multiple rounds of comments and version iteration traces.
What constraints do these characteristics impose on reranking and hybrid retrieval
This category of data is updated per delivery phase or version iteration. Reranking and hybrid retrieval must associate with the dataset for the corresponding version to avoid matching invalid content across versions. Daily documents vary significantly in length: short UAT use cases are only a few hundred characters, while long acceptance issue tickets can reach several thousand characters. Hybrid retrieval must support text inputs of different lengths. Additionally, the data includes two core types of content: business scenario descriptions and defect reproduction steps. The reranking link must prioritize matching acceptance scenario-related information that customers care about, rather than relying solely on basic semantic similarity.
How to configure settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
usingReRank | Set to true | Adapts to the reranking model invocation logic of FastGPT v4.17.0. This category of documents mixes short and long texts, and reranking optimizes the matching priority for acceptance scenarios |
limit | Top 8-12 entries | The dataset scale per phase for this category is moderate. This retains a sufficient candidate set while controlling the computational overhead of retrieval and reranking |
similarity | 0.65-0.85 | Adapts to the semantic matching accuracy required for acceptance scenarios. Prevents introducing irrelevant results if the threshold is too low, or missing valid acceptance-related content if the threshold is too high |
searchMode | hybrid | This category of data includes two core content types: business scenario descriptions and defect reproduction steps. Hybrid retrieval covers both types of retrieval needs |
Three common misconfigurations
- Phenomenon: When retrieving long-text acceptance issue tickets, the reranking model is not triggered, and sorting results are based solely on basic semantic similarity. Cause: The
usingReRankconfiguration is not enabled correctly, or the reranking model invocation logic does not support long-text inputs. - Phenomenon: The reranking model deploys and tests normally, but the reranking result is marked as false after retrieval. Cause: The number of retrieved candidate sets does not meet the minimum input requirements of the reranking model, or the
limitvalue in the configuration is lower than the minimum number of candidates required by the reranking model. - Phenomenon: The reranking function fails in the large model invocation chain, but the knowledge base retrieval test works normally. Cause: The reranking switch is not enabled synchronously in the large model's retrieval configuration, and the reranking function is only enabled during separate knowledge base tests.
How to confirm the configuration is correct
- View retrieval logs to confirm that the
usingReRankfield is true and that there is a reranking model invocation record. - Input UAT use cases and acceptance issue tickets of different lengths, and check whether the sorting order of retrieval results matches the priority of business scenarios.
- Switch between different retrieval modes to verify that hybrid retrieval covers matching results for both business descriptions and defect reproduction steps.
- Compare retrieval results with and without reranking enabled to confirm that there is a noticeable difference in sorting order.
The values provided here are common starting points and should be evaluated against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.