What the Data for This Category Looks Like
The data source for this category is SIEM, EDR, firewall logs, and host images. The update rhythm is real-time or per incident. Daily generated documents include emergency response reports, forensics records, disposal plans, and notification materials. Each document contains attack chain details, disposal steps, evidence hash values, and event level fields. There is no unified fixed length, and it varies with incident complexity. Data exists in a mixed form of structured log snippets and unstructured documents. Most fields include timestamps, event IDs, and associated asset information. Some fields require association and aggregation by incident dimension. Indexes generated after data upload are used to quickly locate vectors and structured fields. Vector features stored in the vector database are used for semantic matching. Retrieval combines indexes and vector features to complete recall.
What Constraints These Characteristics Impose on Knowledge Base Retrieval and Recall
Mixed structured and unstructured data, combined with real-time per-incident updates, requires retrieval to support both structured field matching and vector recall. Incident data has strongly associated fields such as assets and timestamps. Retrieval scope must be limited to datasets associated with the current incident to avoid interference from irrelevant results. Single document length varies widely. The system must adapt content splitting and recall logic for different content lengths. The real-time update feature requires retrieval index synchronization frequency to match incident processing rhythm. This prevents index lag that prevents recall of the latest disposal plans. The operations on-duty scenario requires fast result return. Retrieval time must be controlled within a reasonable interval to avoid delaying emergency response progress. Internal ticket Q&A requires association with the context of specific incidents. Retrieval results must carry event IDs and associated asset information to allow engineers to quickly locate the incident corresponding to the ticket.
How to Configure the Settings
This configuration guide is based on FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
similarity | 0.75–0.85 | Aligns with semantic matching accuracy for security incident disposal plans. A too low threshold leads to irrelevant results, while a too high threshold misses valid disposal steps. |
limit | Top 10 entries | Balances retrieval efficiency and information completeness. Meets the need to quickly obtain core disposal information during operations on-duty. |
searchMode | hybrid | Supports both vector recall and structured field matching. Adapts to mixed-format security incident data. |
usingReRank | Enabled | Re-ranks recall results. Prioritizes returning highly relevant content related to attack path restoration. |
datasetSearchUsingExtensionQuery | Enabled | Expands retrieval terms based on user questions. Covers synonymous matching of security domain professional terminology. |
collectionIds | Specified by incident-associated assets | Limits retrieval scope to the security dataset associated with the current ticket. Avoids interference from cross-incident data. |
Three Common Misconfigurations
- Phenomenon: Retrieval results are empty, and the tool call returns an empty response. Cause: The
datasetSearchUsingExtensionQueryparameter is not correctly configured, and the retrieval scope is not limited to the local security dataset. This results in failure to recall local emergency disposal data. - Phenomenon: Retrieval results include external internet content not from the local knowledge base. Cause: The global internet retrieval switch is not turned off. This causes extended queries to trigger external data sources and leads to data leakage risks.
- Phenomenon: Retrieval results have overly high matching but do not hit valid disposal steps. Cause: The
similaritythreshold is set too high. This filters forensics records with similar semantics but different details, affecting the completeness of attack path restoration.
How to Verify That the Configuration Is Correct
- Upload a historical emergency response report, enter the question corresponding to the incident, and check whether the returned results include the disposal steps and forensics records from that report.
- View the retrieval log, confirm that only the local security dataset is called, with no external internet requests. Verify that data is not leaked to the internet.
- Adjust the
similarityparameter, observe the correlation changes of recall results, and verify that the parameter configuration takes effect. - Trigger real-time updated incident data, confirm that the retrieval results can synchronously include the latest disposal plans and notification materials.
The values provided 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.