What the data for this category looks like
Data sources for this category include monitoring systems, ticket systems, contract documents, and customer communication records. Update frequency is monthly or quarterly. Daily processed documents include SLA clauses, monthly service reports, availability statistics tables, and customer review minutes. Core fields cover SLA indicator entries, event occurrence times, service response durations, customer binding identifiers, and service result descriptions. The overall data structure centers on service performance summaries within contract cycles, with no temporary records of individual one-off tickets.
What constraints do these characteristics impose on the re-ranking and hybrid retrieval link
Multi-source heterogeneous data sources require hybrid retrieval to support both structured contract fields and unstructured ticket and communication text, to avoid scattered retrieval results. Low update frequency means high-frequency refresh of retrieval indexes is not needed, so re-ranking thresholds can be set to a relatively stable range. Documents structured by contract cycles require retrieval to prioritize matching bound customers’ SLA clauses, ensuring results align with service scenarios within contract cycles. Re-ranking logic must prioritize associating contract IDs and SLA indicator fields.
How to set the configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
usingReRank | Enabled | This category’s data is multi-source and heterogeneous. Re-ranking unifies sorting logic to match the priority requirements of business summaries |
similarity | 0.72–0.85 | Adapts to professional text matching for SLA clauses. The range is calibrated via actual testing to avoid mismatching unrelated service records |
limit | Top 8 entries | Balances retrieval recall volume and sorting efficiency for monthly service reports, aligning with the typical data volume of business reports |
searchMode | hybrid | Integrates multi-source data including tickets, monitoring, and contracts, adapting to the characteristics of multiple data types for this category |
| Re-ranking model call timeout | 10 seconds | Adapts to the scenario of batch generating monthly reports, avoiding timeouts that block overall task workflows |
Three common mistakes
- After enabling the re-ranking feature in the interface, the order of knowledge base retrieval results does not change. The cause is that the re-ranking model’s API key is not configured correctly, or the configuration has not been synchronized to take effect for the application.
- The re-ranking model option cannot be checked when creating an application. The cause is that the re-ranking model configured in config.js does not meet the compatibility requirements of FastGPT v4.17.0.
- The number of results returned by retrieval does not match the set
limitparameter. The cause is that the recall upper limit of hybrid retrieval is not aligned with the re-ranking upper limit, resulting in some results being truncated in intermediate steps.
How to confirm the configuration is complete
- Enter the application’s configuration page and confirm that the
usingReRankswitch is enabled. - Submit a test query containing SLA clause keywords, and compare the sorting differences of retrieval results before and after enabling re-ranking.
- Check the application’s running logs to confirm that the re-ranking model’s call requests have been sent normally and that the returned results have no errors.
- Verify that the number of results returned by a single retrieval matches the set
limitparameter.
The values provided are common starting points and should be tested against local deployment 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.