What this category’s data looks like
This category’s data is generated around post-failure root cause analysis and incident management. Daily documents include RCA reports, incident tickets, review minutes, and rectification tracking forms. Data sources are fault timelines, system logs, monitoring metrics, and code commit records. Update frequency follows after each major fault, with at least one update per month. Document structures include fields such as fault occurrence time, impact scope, troubleshooting steps, root cause conclusion, and rectification items. There is no unified fixed format, and it adjusts according to team review habits. Most fields are text-based, including identifying content such as timestamps, device IDs, and error codes.
What constraints these characteristics impose on reranking and hybrid retrieval
Fault-related logs and monitoring data are mostly time-series text, and the length of individual data varies widely. This requires hybrid retrieval to balance semantic matching and temporal relevance. Documents such as RCA reports and review minutes have low update frequency but strong professional content. Reranking models must prioritize matching core paragraphs related to root causes. Rectification tracking forms include status fields, and retrieval must associate the corresponding incident ticket’s associated ID. This requires retrieval results to carry associated fields. Fault timeline data is scattered across multiple source logs. Hybrid retrieval must integrate structured and unstructured data from different sources to avoid missing key time-series nodes.
How to set configurations
| Configuration Item | Recommended Approach | Rationale |
|---|---|---|
usingReRank | Enabled | This category’s documents have strong professional content, and low-relevance non-root-cause fragments need to be filtered. Reranking improves the recall accuracy of core content |
similarity | 0.72–0.80 | Balances recall of root-cause-related content and filtering of non-relevant content, adapting to the semantic matching requirements of professional documents such as RCA reports |
limit | Top 8–12 entries | Covers the core evidence required for a single fault troubleshooting, avoiding excessive redundant data occupying the context window |
searchMode | hybrid | Integrates vector retrieval and keyword retrieval, adapting to the hybrid retrieval requirements of multi-source logs, monitoring metrics, and text documents |
| Reranking minimum relevance threshold | 0.60–0.68 | Filters low-match fragments unrelated to root cause analysis, calibrated based on actual testing |
Three common misconfigurations
- Phenomenon: Retrieval results are empty after reranking is enabled, and referenced fields have no content. Cause: Associated parameters for the reranking model are not configured, or the reranking minimum relevance threshold is set too high, filtering all matching fragments.
- Phenomenon: Core root cause content in reranking results ranks low. Cause: Reranking weights are not adjusted based on the professional document characteristics of this category, and configuration values for general scenarios are used blindly.
- Phenomenon: The reranking model cannot be called normally after deployment. Cause: Environment variables for the reranking model are not correctly configured in docker-compose.yml, causing model startup failure.
How to confirm configuration is complete
- Access the knowledge base configuration page of FastGPT v4.17.0, confirm that the
usingReRankswitch is enabled. - Upload an RCA report as a test document, execute retrieval, and check the sorting priority of returned results. Verify whether core root cause paragraphs rank at the top.
- Adjust the
similaritythreshold, verify changes in the number of recall results under different thresholds, and confirm that the expected filtering effect is achieved. - Check the running logs of the reranking model, confirm that there are no records of call failures or timeouts.
The values provided are common starting points and should be evaluated against the user’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.