What the data for this category looks like
Core data for vulnerability scanning services comes from scan results exported by vulnerability scanners, internal enterprise asset inventories, public CVE vulnerability databases, and official patch announcements. Daily maintained documents include scan plans, vulnerability lists, rectification tickets, and re-scan reports. Scan plans contain fields for asset scope and scan cycle. Vulnerability lists mark CVE IDs, risk levels, and affected assets. Rectification tickets associate ticket numbers and processing statuses. Re-scan reports record re-scan times and repair results. Data update frequency is weekly or monthly, to cover regular scanning and patch synchronization needs.
What constraints these characteristics impose on knowledge base retrieval and recall
The data sources for vulnerability scanning services include structured documents exported by tools and public knowledge base content. Retrieval must accurately match field attributes to avoid mixing irrelevant documents. Fixed update cycles require the knowledge base vector database to refresh weekly or monthly. This ensures recall results include the latest CVE information and patch announcements. The most time-consuming steps of confirming asset scope, eliminating false positives, and verifying re-scans require retrieval results to quickly locate corresponding documents. This reduces manual screening costs. Serious consequences of high-risk vulnerability exposures require recall results to have sufficient semantic matching accuracy. This avoids omission of key vulnerability information.
How to set configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
similarity | 0.72–0.80 | Matches the semantic similarity between on-duty operations questions and vulnerability documents, filters low-correlation recall results, and adapts to the precision needs of false positive elimination |
limit | Top 10 entries | Limits the number of documents recalled per single request, adapts to the quick review needs of on-duty operations scenarios, and avoids information overload |
searchMode | local | Restricts the retrieval scope to the bound exclusive knowledge base, avoiding cross-library recall of irrelevant penetration testing or other category documents |
usingReRank | Enabled | Re-sorts initial recall results by relevance, optimizing the information display order for re-scan result verification steps |
datasetSearchUsingExtensionQuery | Enabled | Automatically expands retrieval terms to cover exact matches for fields such as CVE IDs and asset names, improving retrieval efficiency for asset scope confirmation steps |
collectionIds | Fill in the knowledge base collection IDs for the actually deployed vulnerability scanning service | Accurately binds the exclusive knowledge base, ensuring retrieval only covers document data related to vulnerability scanning |
Three common errors
- Failing to return document source traceability information after calling the
/api/v1/chat/completionsinterface. The cause is that the knowledge base content traceability configuration is not enabled, or the correct associated parameters are not specified in the retrieval parameters. - Recall results containing a large number of non-vulnerability scanning related irrelevant documents. The cause is that the exclusive knowledge base collection is not bound via
collectionIds, orsearchModeis incorrectly set to cross-library retrieval mode. - Retrieval results failing to hit the latest patch announcements or re-scan reports. The cause is that the knowledge base vector data is not refreshed at the weekly or monthly update frequency, or the
similaritythreshold is set too high, causing new documents to not be recalled normally.
How to confirm the configuration is correct
- Call the
/api/v1/chat/completionsinterface, pass the configuredcollectionIdsand retrieval parameters, and check if the returned results only include documents related to the vulnerability scanning service. - Trigger a simulated on-duty operations query, check if the returned results include corresponding document source traceability information, and confirm that the
usingReRankanddatasetSearchUsingExtensionQueryfunctions are active. - Upload a new vulnerability list document, confirm that the FastGPT v4.17.0 file processing model has correctly parsed the document content, wait for the vector refresh process to complete, then initiate a retrieval request, and confirm that the new document can be recalled normally.
- View the FastGPT v4.17.0 knowledge base management interface, confirm that the associated collection IDs match the configuration items, and the
similarityvalue falls within the preset 0.72–0.80 range.
Note: The configuration values listed above are common starting points. They should be evaluated against the specific samples of the relevant deployment.
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.