What the Data for This Category Looks Like
Data for this category is created and maintained by project security response teams, maintainers, and security researchers. Daily documents include security advisories, vulnerability reports, fix patches, and CVE application materials. Data sources include private vulnerability reports, code repositories, CVE numbering authorities, and official release channels. Updates are triggered per individual vulnerability event. Each piece of data contains core fields such as vulnerability identifier, impact scope, fix status, and disclosure time. There is no fixed batch update cycle. Updates are only triggered by new vulnerability disclosures or fix actions.
Constraints Imposed by These Characteristics on Re-Ranking and Hybrid Retrieval
The characteristics of this category’s data impose multiple constraints on the re-ranking and hybrid retrieval process. First, updates are triggered per individual vulnerability event. Retrieval recall datasets must be kept in sync with the latest disclosed vulnerability information to avoid recalling expired or undisclosed private vulnerability content. Second, document types include highly technical vulnerability reports, formally structured CVE application materials, and code snippet fix patches. Semantic characteristics vary significantly across different document types. Hybrid retrieval must adapt vector matching logic for multiple document types. Additionally, the data involves project security-sensitive information. Retrieval scope must be strictly limited to internal operations and ticket systems to prevent sensitive data leaks. Furthermore, vulnerability impact assessment is the most time-consuming step. The re-ranking process must prioritize recalling vulnerability content with high matching degrees to current operational tickets, reducing the workload of manual assessment.
How to Configure Settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
usingReRank | Enabled | This category requires prioritizing content highly relevant to operational tickets and vulnerability disclosures, to improve the accuracy of retrieval results |
limit | Top 8–12 entries | Controls the scale of the initial recall dataset, balances retrieval accuracy and response speed, and adapts to the rapid response needs of operational on-call duties |
similarity | 0.72–0.88 | Filters low-similarity irrelevant documents, avoids introducing incorrect vulnerability impact assessment information, and ensures the accuracy of security judgments |
searchMode | Hybrid Retrieval | Adapts to the characteristics of multiple document types in this category, matching both structured CVE application materials and unstructured vulnerability reports and fix patches |
| Re-ranking model call timeout threshold | 25–35 seconds | Limits the time spent on the re-ranking process, avoiding delays in operational ticket processing caused by model response latency |
Three Common Misconfigurations
- Phenomenon: After enabling the re-ranking function, the sorting of knowledge base retrieval results does not change significantly, matching the initial recall results. Cause: The initial recall
limitrange is too large, and thesimilaritythreshold is set too low, resulting in the initial recall results already containing all highly relevant content, so the re-ranking model cannot adjust the sorting order. - Phenomenon: The re-ranking model call times out, and the system returns a retrieval timeout error message. Cause: The re-ranking model call timeout threshold is set too short, or a re-ranking model version compatible with FastGPT v4.17.0 is not selected, resulting in failure to complete sorting calculations within a reasonable time frame.
- Phenomenon: Unauthorized private vulnerability report content appears in retrieval results. Cause: The retrieval scope is not limited to the internal knowledge base, resulting in external data being included in the recall set, violating security data access rules.
How to Verify Successful Configuration
- Access the FastGPT knowledge base configuration page, check whether the
usingReRankswitch is in the enabled state, and confirm that the re-ranking function is activated. - Submit a test ticket containing known vulnerability keywords, compare the initial recall results with the sorted results after re-ranking, and confirm that the sorting logic is effective.
- Check the system operation logs to confirm that the re-ranking model's call duration does not exceed the preset threshold, and that there are no error messages.
- Check the source tags of retrieval results to confirm that only compliant documents such as internal security advisories and vulnerability reports are included, with no external or unauthorized data.
The values provided here 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.