What the Data for This Category Looks Like
This category’s data originates from vulnerability scanners, enterprise asset inventories, public CVE vulnerability databases, and official patch announcements. Four types of documents are generated daily: scan plans, vulnerability lists, rectification tickets, and rescan reports. Data fields include vulnerability CVE numbers, associated asset IPs and domains, vulnerability severity levels, rectification statuses, scan execution times, and additional relevant fields. Data updates occur weekly or monthly, synchronized with scan plan runs or patch announcement releases.
What Constraints Do These Characteristics Impose on Re-Ranking and Hybrid Retrieval
This category’s data structure includes multiple document types and multi-dimensional fields, with fixed update cycles. This imposes three constraints on re-ranking and hybrid retrieval:
- Support hybrid matching across document types. For example, retrieve technical details from vulnerability lists and associated asset information from rectification tickets at the same time. This prevents information loss caused by matching only a single document type.
- Set differentiated relevance weights for vulnerability severity levels and rectification statuses. Prioritize content related to high-risk unrectified vulnerabilities to meet priority requirements in on-call operations scenarios.
- Adapt to datasets with fixed update cycles. Avoid frequent adjustments to retrieval thresholds. Calibrate retrieval parameters based on weekly or monthly scan cycles to reduce unnecessary parameter maintenance costs.
How to Configure the Settings
| Configuration Item | Recommended Range | Rationale |
|---|---|---|
similarity | 0.65–0.75 | Vulnerability scanning data contains a large number of similar vulnerability descriptions and asset information. This range filters low-relevance false positive scan results and retains core vulnerability and ticket content. |
limit | Top 10–15 results | On-call operations scenarios require quick review of core results. Excessive entries increase troubleshooting workload. This range covers the typical number of high-risk vulnerabilities from a single scan. |
searchMode | Hybrid Retrieval | Must simultaneously match technical details from vulnerability lists and process information from rectification tickets. Hybrid retrieval balances semantic and keyword matching performance. |
usingReRank | Enabled | Vulnerability data contains a large number of semantically similar descriptions, such as differences in how different scanners describe the same CVE. Re-ranking further filters semantically redundant results and improves the sorting priority of high-risk vulnerabilities. |
This configuration is compatible with FastGPT v4.17.0 and later versions.
Three Common Misconfigurations
- Symptom: Re-ranked results do not change, or are sorted incorrectly. Cause:
usingReRankis not set to Enabled, or channel association for the re-ranking model is incomplete. - Symptom: The number of retrieval results is far lower than expected. Cause: The
similaritythreshold is set too high, filtering out low-similarity but relevant vulnerability information that meets business requirements. - Symptom: Hybrid retrieval cannot match rectification tickets and vulnerability lists. Cause:
searchModeis not set to Hybrid Retrieval, only a single retrieval type is used.
How to Confirm Successful Configuration
- Verify that the FastGPT server’s
AIPROXY_API_ENDPOINT(AI Proxy service root address, format example: http://aiproxy:3000, no additional path required) andAIPROXY_API_TOKEN(AI Proxy administrator Token, must match the AI Proxy server configuration and not be empty) environment variables are correctly set. - Run a test retrieval, input "High-risk unrectified vulnerabilities". Confirm that returned results prioritize high-risk vulnerability entries in their sorting order.
- Adjust the
similaritythreshold, observe changes in the number of retrieval results to confirm the threshold aligns with business requirements. - Review retrieval logs to confirm that the
searchModeandusingReRankparameters are applied correctly.
The values provided are common starting points and should be evaluated against local deployment 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.