What the data for this category looks like
This category of data primarily comes from code repositories, test framework reports, requirement specifications, and interface definitions. Update frequency is daily or after each code commit. Daily associated documents include test cases, coverage reports, Mock interface descriptions, and defect tickets. Data fields include test case numbers, covered code ranges, boundary condition descriptions, defect reproduction steps, severity levels, and more. There are no unified fixed units; values vary based on document type. Data volume fluctuates with project scale. Core content revolves around verification logic for code units and components. Some data contains mixed content of code snippets and test steps.
What constraints these characteristics impose on reranking and hybrid retrieval
Data updates occur at high frequency, so retrieval pipelines must support fast incremental synchronization to avoid retrieval result deviations caused by data lag. Documents such as test cases and defect tickets have fragmented structures. Hybrid retrieval must match both semantic and keyword features to avoid missing content related to boundary conditions. Data sources include code and test reports, so weights for code logic and test result data must be distinguished. The reranking stage must adjust ranking criteria based on different document types. A single retrieval involves a large number of test data entries, so return range must be limited to control time consumption, while ensuring core boundary condition test cases are recalled first.
How to configure settings
The following configurations are optimized for FastGPT v4.17.0, tailored for customer technical support and pre-sales Q&A scenarios for unit testing and component testing:
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| Similarity Threshold | 0.72–0.85 | Matches semantic similarity between test cases and user questions, covers recall requirements for boundary condition test cases |
| Single Search Limit | Top 10–15 entries | Limits the number of basic results returned per retrieval, adapts to the fragmented characteristics of test data |
| Retrieval Mode | hybrid | Enables hybrid retrieval mode, matches both keyword and semantic features, adapts to multi-type structures of test documents |
| Reranking Toggle | Enabled | Performs reranking on recalled results, prioritizes core test-related content such as defect reproduction steps and boundary conditions |
| Reranking Recall Count | Top 5–8 entries | Narrows reranking scope, controls retrieval time consumption, adapts to scenarios with high test data update frequency |
| Retrieval Timeout | 8–12 seconds | Adapts to fluctuations in test data volume, avoids build blocking risks caused by retrieval timeouts |
Three Common Misconfigurations
- Phenomenon: An error is thrown when calling the reranking stage, returning an error prompt in the format
rerank error fastgpt | { message: { detail: '. Cause: Reranking model call parameters are not configured correctly, or the model is incompatible with the current FastGPT version. - Phenomenon: Hybrid retrieval pipeline execution time exceeds 10 seconds, exceeding business acceptable thresholds. Cause: Single search limit and reranking recall count are not restricted, resulting in too many test case and defect ticket data being recalled and reranked simultaneously.
- Phenomenon: After deploying the reranking model, GPU memory usage on single or multi-GPU nodes quickly rises to high levels with each call. Cause: Concurrent call limits for the reranking model are not configured, causing multiple requests to occupy GPU resources simultaneously.
How to Confirm Successful Configuration
- Perform a single retrieval test, verify that the number of returned results matches the configured single search limit.
- Trigger the reranking stage, check whether system logs contain sorting basis fields for reranking results, confirm that reranking logic is active.
- Simulate a high-frequency data update scenario, verify that synchronization delay of the retrieval pipeline meets business expectations.
- Call pure semantic retrieval and hybrid retrieval modes separately, compare result differences between the two modes, confirm that hybrid mode functions correctly.
The values listed here are common starting points, and should be evaluated against the reader's own specific 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.