What the data for this category looks like
The core data for this category is generated around independent innovation hardware and software replacement scenarios, typically sourced from existing system inventories, official directories of domestic hardware and software, test environment output results, and publicly available vendor materials. Daily produced documents include adaptation lists, compatibility test reports, migration plans, and issue logs. Common data fields include hardware and software models, version numbers, compatibility status, test environment parameters, and more. The data update rhythm is adjusted according to project progress or quarterly cycles, with a single update covering all relevant information for a single project or batch of domestic replacement efforts.
What constraints these characteristics impose on re-ranking and hybrid retrieval
The data updates for independent innovation replacement adaptation are adjusted per project or quarter, and the volume and field complexity of documents updated in a single batch are relatively high. This requires hybrid retrieval to first recall hardware and software compatibility information matching the current inquiry. Documents such as adaptation lists and test reports have large differences in fields, with some fields only valid in specific scenarios. The re-ranking link must perform targeted sorting of recalled results based on the specific scenario of the inquiry, such as server replacement or office software migration. Data for existing system inventory has high timeliness requirements, so hybrid retrieval must first recall the latest version of compatibility information and avoid using expired test results. At the same time, fault troubleshooting steps in issue logs must accurately match the hardware and software models of the current inquiry, and the re-ranking link must associate model fields with inquiry keywords to improve troubleshooting efficiency.
How to configure the settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
similarity | 0.72–0.85 | Meets the precise matching requirements for hardware and software models and version numbers in independent innovation scenarios, filtering low-correlation compatibility information |
limit | Top 10 entries | Adapts to the typical number of entries in a single project adaptation list, avoiding excessive redundant recalled data that affects retrieval efficiency |
searchMode | hybrid | Combines vector recall and keyword recall to cover multiple types of data such as model keywords and compatibility status descriptions |
usingReRank | Enabled | Addresses field differences in independent innovation documents, performs secondary sorting on recalled results based on inquiry scenarios to improve accuracy |
| Re-ranking candidate upper limit | Top 20 entries | Reserves sufficient candidate data for secondary sorting, avoiding omission of key compatibility information |
| Retrieval timeout threshold | 300–600 seconds | Adapts to the relatively long single-item length of independent innovation documents, avoiding task failure caused by retrieval timeout |
Three common configuration mistakes
- Re-ranking of search results has no response: the re-ranking marker field in the interface search result panel is empty or displays false. The cause is that the reranker service call channel is not configured correctly, or the interface address of the custom channel does not point to an available reranker instance.
- Hybrid retrieval recalled results do not match the inquiry keywords, and the re-ranking process is not triggered. The cause is that the
usingReRankswitch is not enabled, or the re-ranking candidate upper limit is set too low, causing valid data to be filtered out. - Custom reranker service call fails, returning 400 or 404 status codes. The cause is that when configuring the transit channel, the service key or interface path is not filled in correctly, causing the request to fail to forward normally.
How to confirm the configuration is successful
- Enter the knowledge base configuration page of FastGPT v4.17.0, check whether the
usingReRankswitch is in the enabled state. - Initiate an inquiry targeting a specific hardware and software model, verify that the search results include the compatibility information of the corresponding model, and that the sorted results follow the expected order.
- Call the test interface of the reranker service, confirm that the returned result has a status code of 200 and includes valid sorting scores.
- View the search log panel, confirm that
searchModeis set to hybrid, and that thesimilaritythreshold is within the preset 0.72–0.85 range.
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.