What data for this category looks like
Typical users of this category include R&D teams, Tech Leads, and open source project maintainers. Core data originates from Git repositories, CI pipelines, static scanning reports, and defect trackers. Daily generated documents include merge requests, code review comments, commit records, and branch strategy descriptions. Data updates daily or in real time alongside code commits. Each entry includes fields such as change content, review comments, and associated CI results. Field structures vary across document types: merge requests include target branches and lists of changed files, while commit records include commit hashes and commit messages. There is no unified fixed unit.
What constraints these characteristics impose on re-ranking and hybrid retrieval
Data for this category comes from multiple sources and updates frequently. Re-ranking and hybrid retrieval must support real-time synchronization of the latest commits and merge requests from Git repositories, to avoid retrieving outdated change records. Data field structures are diverse. Hybrid retrieval must match code semantics, review comments, and business issues from operational tickets simultaneously. For example, an on-call operations ticket asking whether a specific change will cause an online service exception needs to be linked to the changed files, review comments, and CI scan results of the corresponding merge request. Since this category includes business semantics requiring manual judgment, the re-ranking step must prioritize sorting review comments and change impact analyses directly related to operational issues. Relying solely on code similarity cannot cover business association requirements. Additionally, frequently updated data requires retrieval and re-ranking response speeds to meet the real-time needs of on-call operations, to avoid excessive waiting times.
Configuration Settings
| Config Item | Recommended Value | Rationale |
|---|---|---|
usingReRank | Enabled | This category has a large number of semantically similar change records and review comments. Re-ranking can filter low-relevance results and improve the accuracy of operational ticket Q&A |
similarity | 0.75–0.85 | The semantic differences of change content in merge requests are large. This threshold can filter irrelevant commit records and static scanning reports, while retaining highly matched target data |
limit | Top 10 entries | Operational on-call tickets usually focus on a small number of relevant merge requests and review records. Too many results will exceed the context window and increase the model's processing load |
searchMode | Hybrid retrieval mode | It is necessary to recall code data from Git repositories, CI pipeline results, and static scanning reports at the same time, and complete matching by combining code semantics and operational business issues |
Three common configuration mistakes
- Phenomenon: After enabling
usingReRank, internal application retrieval returns empty results, but results are normal when testing the bound knowledge base separately. Cause: The re-ranking model is not linked to the knowledge base bound to this scenario. The re-ranking model is only loaded during knowledge base testing, and the re-ranking logic is not triggered when the application is invoked. - Phenomenon: The number of retrieval results is far fewer than the expected merge requests and review records. Cause: The
similaritythreshold is set too high, filtering out relevant data whose semantic matching degree meets business requirements. - Phenomenon: After upgrading to FastGPT v4.8.20, offline deployed re-ranking model configuration fails. Cause: Re-ranking model dependency packages are not pre-downloaded in the offline environment, or the full path of the local model is not specified in the configuration file.
How to confirm the configuration is complete
- Enter the configuration page for this scenario in the FastGPT backend, verify that
usingReRankis set to Enabled, and that the values ofsimilarity,limit, andsearchModematch the preset configuration, adapting to the configuration logic of FastGPT v4.17.0. - Navigate to the bound knowledge base test page, input an on-call operations ticket-related question, and confirm that retrieval results include target data such as merge requests, commit records, and static scanning reports, with re-ranked results aligned with business expectations.
- Trigger a ticket Q&A request in the associated application, check that the returned context contains correct retrieval results, with no empty returns or abnormal error messages.
- Review system operation logs, confirm that the re-ranking model call status is normal, with no records of timeouts or model loading failures.
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.