What data for this category looks like
This category of data mainly comes from defect management systems, test reports, code commit records, and user feedback. Daily produced documents include defect tickets, regression test checklists, repair verification records, and defect statistical reports. The data update frequency is daily or per version release cycle. Document fields include unique defect identifiers, priority levels, reproduction steps, associated version numbers, repair statuses, verification results, and some reports include statistical cycles and defect distribution dimensions.
What constraints do these characteristics impose on the knowledge base retrieval and recall link
Defect management and regression test data has high timeliness requirements. Fields with associated version numbers require filtering by version range during retrieval to avoid invalid cross-version results. Frequent data updates require regular index refreshes; otherwise, newly submitted defect tickets may fail to be recalled. There is a large amount of homogeneous content, such as descriptions of reproduction steps for similar defects, so deduplication and weight sorting of recall results need to be controlled. Single-piece data has high field information density, so retrieval must accurately match core fields such as priority and reproduction steps. Matching only keywords is insufficient to cover core needs. In customer technical support scenarios, solutions for high-priority defects need to be recalled quickly, so recall result sorting must combine priority and repair status.
How to set configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
similarity | 0.75–0.85 | Matches core fields and reproduction steps of defect tickets, avoids recalling irrelevant low-similarity content |
limit | Top 8–12 entries | Adapts to the quick review needs of technical support scenarios, avoids excessive results interfering with judgment |
searchMode | vector + fulltext | Balances semantic matching and keyword matching, accurately recalls defect reproduction steps and version-associated content |
usingReRank | Enabled | Rearranges recalled homogeneous defect ticket content, prioritizes displaying high-priority results |
datasetSearchUsingExtensionQuery | Enabled | Automatically expands user technical support questions, supplements field keywords such as version numbers and defect types |
collectionIds | Specify the dedicated collection for defect management and regression testing | Isolates business data, avoids recalling irrelevant documents from other categories |
Three common mistakes
- No results returned after importing the knowledge base, with an empty list returned. The cause is failing to rebuild the index for imported documents such as defect tickets and regression checklists, or the index update not being completed.
- Too much homogeneous content in recall results, with low-priority defect tickets ranked first. The cause is failing to enable the reranking function, or setting the similarity threshold too low, resulting in irrelevant content being recalled.
- Unable to sort by date weight even after batch retraining. The cause is failing to configure date-based weight rules, or the reranking logic not being associated with the document update time field.
How to confirm the configuration is correct
This verification is based on FastGPT v4.17.0:
- Upload a test defect ticket, perform a search containing the defect ID keyword, confirm that the document can be recalled.
- After enabling
usingReRank, submit a query containing high-priority defect keywords, confirm that high-priority results are ranked first. - Perform a batch index rebuild operation, check the system log to confirm that the index update progress is completed.
- After configuring
datasetSearchUsingExtensionQuery, submit a query that does not include a version number, confirm that the recall results automatically associate with current version defect content.
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.