What the data for this category looks like
This category's data comes from change management systems, CI pipelines, monitoring data, and business calendars. Daily generated documents include change request forms, risk assessment reports, launch window schedules, and rollback plan documents. Data updates occur once weekly or are triggered by an individual change. Individual documents contain fields such as change ID, planned launch window, risk level, and rollback trigger conditions. Document lengths vary significantly, ranging from hundreds of characters to thousands of words.
What constraints do these characteristics impose on reranking and hybrid retrieval?
Data sources for this category are scattered, and update schedules are inconsistent. Hybrid retrieval must integrate structured fields from change management systems and log text from CI pipelines simultaneously. Individual document lengths vary widely, so reranking models must adapt to input content of different lengths. Content related to changes has strict timeliness requirements. Fields such as launch window times and rollback conditions must first match the time range of user queries. Outdated historical change data must be avoided in recall results. Therefore, the retrieval link must perform pre-filtering based on data update time.
How to configure settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
similarity | 0.65–0.75 | Filter low-relevance change documents, avoid interference from irrelevant historical changes on retrieval results |
limit | Top 8 entries | Set the upper limit for the number of documents related to a single change in this category to balance recall coverage and retrieval efficiency |
usingReRank | Enabled | Adapt to the wide variance in document lengths for this category, perform secondary ranking on recall results |
searchMode | Hybrid retrieval | Retrieve both structured change fields and unstructured content such as risk assessments and rollback plans simultaneously |
| Rerank trigger threshold | 800–1200 characters | Trigger reranking when the total length of recalled documents exceeds this range, adapting to the length characteristics of documents in this category |
This configuration guide applies to FastGPT v4.17.0.
Three common configuration mistakes
- Symptom: The rerank field in retrieval results returns false, or results do not sort as expected. Cause: The
usingReRankparameter is not correctly set to enabled, or the rerank model deployment path is not linked to the current retrieval link. - Symptom: The rerank model is not called after retrieved content from the knowledge base is too long. Cause: No rerank trigger document length threshold is set, or the threshold is set lower than the total length of currently recalled documents, causing the rerank logic to not trigger.
- Symptom: Retrieval results include outdated historical change data. Cause: No update time filter condition is added to the retrieval link, causing recall of old documents beyond the update cycle.
How to confirm configuration is correct
- Navigate to the FastGPT retrieval test page, input a query that includes a change window time, and check if returned results sort as expected.
- Upload a change risk assessment document longer than 1000 characters, confirm that rerank model call logs exist after triggering retrieval.
- Adjust the
similarityparameter to 0.5, check if retrieval results include more low-relevance documents to verify parameter effectiveness. - Check the configuration items in the retrieval link, confirm that the
usingReRankparameter is enabled, and the rerank model API address is configured correctly.
The values given are common starting points and should be measured 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.