What data looks like for this category
Data for this category primarily comes from code repositories, test framework reports, requirement specifications, and interface definitions. Update frequency is daily or per commit. Routine documents include test cases, coverage reports, Mock instructions, and defect tickets. Fields cover test steps, expected results, coverage values, defect severity levels, interface parameters, and more. Individual document lengths vary widely, ranging from test case entries of tens of characters to coverage analysis reports of thousands of characters.
What constraints these characteristics impose on knowledge base retrieval and recall
High update frequency and frequent triggers require the retrieval pipeline to support low-latency recall. Diverse document types need weight configuration tailored to different fields. Wide variation in individual document lengths requires adjusting chunking strategies to prevent information truncation or redundancy. Test cases and defect tickets have associated retrieval needs, which require support for cross-document associated recall. Frequent updates raise index real-time requirements. A balance must be struck between index overhead and recall timeliness to avoid retrieval blocking caused by full indexing.
How to configure settings
The following configurations apply to FastGPT v4.17.0.
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
similarity | 0.72–0.80 | Adapts to the precise matching needs of test cases, and avoids recalling irrelevant coverage reports |
limit | Top 8 entries | Balances single-round context length and recall coverage, and adapts to the multi-associated test case requirements of testing scenarios |
searchMode | vector_search | Prioritizes semantic recall of relevant test cases and defect tickets, and matches the semantic retrieval needs of testing scenarios |
usingReRank | Enabled | Performs secondary sorting on recall results, and corrects sorting issues for cases with similar semantics but different priorities in testing scenarios |
datasetSearchUsingExtensionQuery | Enabled | Automatically expands synonyms related to testing, such as expanding "boundary conditions" to "abnormal input" and "extreme scenarios" |
collectionIds | Bind dedicated collections for test cases and coverage reports | Isolates test data from other business data, and avoids irrelevant documents interfering with retrieval results |
Three common mistakes
- Retrieval results show abnormal score ordering, such as a result with a score of 1.2717 ranking lower than a result with a score of 0.5208. Cause: Incorrect configuration of the trigger conditions for
usingReRank, or failure to adjust thesimilaritythreshold to filter low-relevance documents, resulting in the reranking logic not taking effect. - Test report images uploaded to the knowledge base cannot be displayed directly in responses. Cause: The media file external link permission for the knowledge base is not enabled, or image storage path rules matching test document formats are not configured.
- Knowledge base items remain in the indexing state for a long time after upload. Cause: The high-frequency update rhythm of test data is not adapted, incremental indexing mode is not enabled, and full indexing takes too long leading to task backlog.
How to confirm configuration is properly set up
- Upload a test case and its associated defect ticket. Run targeted retrieval, check the relevance and quantity of recall results. Adjust the
similarityandlimitparameters to meet business expectations. - Trigger a test data update after a code commit. Check if index update delay meets business requirements. Verify that the real-time configuration for
searchModetakes effect. - Enter a test query containing synonyms, such as "boundary condition test". Check if
datasetSearchUsingExtensionQueryautomatically expands relevant retrieval terms to improve recall coverage. - Review the sorting logic of retrieval results. Confirm that high-relevance results are displayed first after
usingReRankis enabled. Verify that the sorting rules meet the priority requirements of testing scenarios.
The values provided here are common starting points. They should be evaluated 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.