What the Data for This Category Looks Like
Data for this category comes primarily from WAF, IDS, firewalls, and threat intelligence platforms. Daily documents include rule change tickets, blocking logs, false positive analysis reports, and policy rollback records. Data updates occur daily or when triggered by security incidents. Fields include rule ID, blocking threshold, false positive rate, business association domain, change time, and more. Document structures differ across sources, with no unified fixed format.
Constraints on Reranking and Hybrid Retrieval
Data sources for this category are scattered, and updates occur frequently. Reranking and hybrid retrieval must cover multi-source logs, reports, and ticket data simultaneously to avoid missing key security event information. Document structures vary widely across sources, so semantic weighting for different fields must be adapted. This ensures retrieval relevance for core content such as false positive analysis and rule changes. In operations on duty scenarios, rapid response is required. The reranking step must not add excessive time overhead. Consequences of errors are severe, so reranking result accuracy must be guaranteed. This prevents normal business from being mistakenly blocked or attacks from being missed.
Configuration Guidelines
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| Reranking Toggle | Enabled | Security product rule data has a high false positive rate. Reranking filters low-relevance blocking logs or rule records, improving retrieval accuracy |
| Similarity Threshold | 0.75–0.85 | Matches semantic association for rule change tickets and blocking logs, avoiding missed key policy changes or false positive analysis content |
| Maximum Recall Results | Top 10 | In operations on duty scenarios, core results must be browsed quickly. Too many entries increase analysis burden and reduce duty response efficiency |
| Retrieval Mode | Hybrid Retrieval | Must cover WAF/IDS logs, threat intelligence, and historical ticket data simultaneously. A single retrieval mode cannot meet full data source retrieval needs |
| Post-Reranking VRAM Release | Automatically unload after retrieval completes | Prevents reranking models from continuing to occupy VRAM after retrieval, affecting resource availability for other security tools |
Three Common Misconfiguration Issues
- Phenomenon: A red error cross appears in the interface after the knowledge base enables result reranking, and normal enabling fails. Cause: Access credentials for the Reranker model are not configured correctly, or credentials have insufficient permissions to call the model.
- Phenomenon: The reranking model call succeeds, but retrieval results do not show expected sorting changes. Cause: The reranking toggle is not enabled correctly, or the similarity threshold is set outside a reasonable range. This causes the reranking logic to not trigger, or filtering rules to be too strict or too loose.
- Phenomenon: The reranking model continues to occupy VRAM without being released after the retrieval process finishes. Cause: The parameter for automatically unloading the reranking model after retrieval completes is not configured, leading to long-term VRAM resource occupation.
How to Confirm Proper Configuration
- Access the knowledge base settings page of FastGPT v4.17.0. Confirm the reranking toggle is enabled, with no red error markers.
- Submit a test query containing rule change keywords. Compare initial retrieval results with reranked results to confirm sorting aligns with business relevance requirements.
- Run a complete retrieval and reranking process. Use system monitoring to check if reranking model VRAM usage is automatically released after retrieval completes.
- Verify that the configured similarity threshold matches the business scenario. Adjust through multiple tests to confirm result reasonableness.
The configuration values provided here are common starting points. Adjust them based on your own specific samples and business needs.
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.