Security Baseline Checking: Operations On-Duty and Internal Ticket Query – Re-ranking and Hybrid Retrieval

This category of data originates from server configuration files, middleware runtime parameters, security device policy configurations, and baseline

What this category of data looks like

This category of data originates from server configuration files, middleware runtime parameters, security device policy configurations, and baseline scanning tool output results. Daily generated documents include baseline checklists, configuration verification records, rectification suggestion sheets, and exception approval sheets. Data update cycles are monthly or quarterly. Most document structures include configuration item names, current values, baseline requirements, compliance status, and rectification notes. No unified fixed units are used, and fields are adjusted based on organizational security baselines. In operations on-duty and ticket scenarios, rapid association of configuration items with abnormal descriptions in tickets is required. The degree of data structuring and field correlation directly affects retrieval efficiency.

What constraints do these characteristics impose on re-ranking and hybrid retrieval?

Data in this category is scattered and has significant format differences. Hybrid retrieval must match configuration item names, current values, and baseline requirements simultaneously, and handle multi-source heterogeneous content. Data update cycles are slow, but individual documents contain numerous configuration entries. The re-ranking link must avoid redundant content interfering with core matching. Exception approval sheets have a high proportion of unstructured content. It is necessary to distinguish compliance status fields from auxiliary explanatory text, and ensure retrieval results first associate high-risk configuration items. In operations on-duty scenarios, rapid location of abnormal items is required. Re-ranking must first return high-priority configuration items associated with the current ticket, and avoid irrelevant entries interfering with troubleshooting.

How to configure the settings

The following configurations are formulated for FastGPT v4.17.0.

Configuration ItemRecommended SettingRationale
usingReRankEnabled, trigger when recall results ≥5 entriesCore configuration items for security baseline checking are mostly structured entries. A small number of recall results can be filtered without re-ranking. The trigger threshold avoids invalid calculations
limitTop 6 entriesA single baseline checklist usually contains dozens of configuration items. Returning the top 6 entries covers high-risk configurations, which meets the rapid review needs of operations on-duty
similarity0.70–0.75, calibrated via actual testingConfiguration item names for security baselines are mostly industry-standard terms. This range filters non-matching general configurations and retains highly relevant items
searchModehybridMust match both configuration item keywords and compliance status semantics. Hybrid retrieval mode balances exact matching and business correlation
Custom re-ranking model request addressFill in the intranet address of the re-ranking model service deployed via Docker, such as http://127.0.0.1:8000/v1/rerankSecurity baseline checking business scenarios are mostly deployed on intranets. Using intranet addresses avoids public network latency and adapts to Docker-deployed models

Three common configuration mistakes

  • Phenomenon: The re-ranking model passes independent testing, but all re-ranking results returned for retrieval requests are false. Cause: The re-ranking model input format is not configured correctly, or the FastGPT API protocol does not match the model, preventing the re-ranking logic from properly parsing returned results.
  • Phenomenon: The re-ranking model is not called for sorting when knowledge base retrieval content is too long. Cause: The re-ranking model trigger threshold is not set, or the system default limit on single re-ranking input character count is exceeded, causing the re-ranking link to be skipped automatically.
  • Phenomenon: The Docker-deployed re-ranking model cannot be called normally, and retrieval results are not re-ranked. Cause: The custom re-ranking model request address is incorrectly filled, not pointing to the model service port inside the Docker container, or network policies restrict intranet access.

How to verify successful configuration

  • Navigate to the FastGPT knowledge base configuration page, check the re-ranking function switch status and trigger conditions, and confirm they match the preset configuration.
  • Upload a baseline checklist and rectification suggestion sheet, initiate a retrieval containing configuration item keywords, and verify that returned result sorting conforms to business priority.
  • Call the re-ranking model test interface, input retrieval results and query terms, and confirm that returned re-ranking scores and sorting logic meet expectations.
  • View system logs, confirm that re-ranking model requests have been sent normally, returned results have been correctly parsed, and no error messages are present.

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.