What the data for this category looks like
This category of data primarily comes from switch consoles, wireless controllers, office area monitoring systems, and frontline user trouble reporting channels. Documents generated during daily maintenance include network topology diagrams, change orders, fault records, and wireless coverage inspection reports. Data updates occur either daily or in real time alongside network changes. Fields include port numbers, VLAN identifiers, wireless signal strength, fault location nodes, and more. Some documents are structured tables, while others are plain text records, with no unified standardized format.
What constraints do these characteristics impose on re-ranking and hybrid retrieval?
Decentralized data sources cause retrieval recall results to mix content of different formats, such as device logs, fault records, and inspection reports. Hybrid retrieval must support matching logic for both structured and unstructured data. Differences in update frequencies require retrieval to prioritize recalling change and fault records from the past 7 days, to avoid interference from outdated data. The diversity of fields means simple semantic retrieval cannot accurately match operation and maintenance-specific identifiers such as ports and VLANs. Keyword and semantic matching must be combined. Retrieval results for operation and maintenance scenarios must first associate with the office area managed by the current on-duty personnel. The re-ranking link must add weight adjustments based on regional dimensions, to ensure core operation and maintenance information is displayed first.
How to set the configuration
This configuration is based on FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| Enable re-ranking | Enabled | Decentralized operation and maintenance data sources and mixed formats require re-ranking to filter irrelevant device logs and inspection records |
| Similarity threshold | 0.72–0.85 | Balance the precision and coverage of semantic recall, and avoid missing low-similarity key fault location information |
| Single recall limit | Top 8 entries | Valid associated information for operation and maintenance tickets is usually concentrated in the top 8 recall results. Excess entries will exceed context window limits |
| Retrieval mode | Hybrid retrieval | Adapts to the characteristics of operation and maintenance data where structured fields (such as VLAN ID, port number) and unstructured text (such as fault descriptions) coexist |
| Re-ranking model timeout | 30 seconds | Avoid delays in on-duty ticket processing caused by model response latency, and adapt to the real-time requirements of operation and maintenance scenarios |
| Re-ranking model selection | Determined based on actual testing | Adapts to the multi-source characteristics of operation and maintenance data. Different models have varying matching effects on device logs and fault records |
Three common misconfigurations
- Phenomenon: After configuring the re-ranking model, the sort order of retrieval results matches the order when re-ranking is not enabled, with no obvious adjustment. Cause: The similarity threshold and re-ranking trigger conditions are not set correctly, so the re-ranking link does not execute.
- Phenomenon: When creating an application, the check box for the re-ranking model is grayed out and unavailable. Cause: The API address and key for the re-ranking model are not correctly configured in config.js, or the configuration format does not meet platform requirements.
- Phenomenon: A 504 status code appears in retrieval results, or a model response timeout prompt is displayed. Cause: The re-ranking model timeout setting is too short, or the open-source model is deployed on a node with high latency, causing network transmission time to exceed the threshold.
How to confirm the configuration is complete
- Enter the application's retrieval configuration page, and confirm that the "Enable re-ranking" switch is turned on.
- Submit a test query containing a VLAN ID or port number, and check whether the sort order of retrieval results differs from the initial recall results.
- Check the application logs to confirm that the re-ranking model call request has been sent normally and valid results have been returned.
- Adjust the similarity threshold, observe whether the number of recall results changes accordingly, and verify that the configuration has taken effect.
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.