What the Data for This Category Looks Like
The core documents for this category are Release Notes, change logs, version tags, and release checklists. Data sources include Git tags, merge records, CI artifacts, and Issue milestones. Data is updated per version cycle. Content generated during a single release cycle centers on a single version number, and includes fields such as change type, associated artifacts, and milestone information. Data formats differ across sources, so unified processing is required before the data can be used for retrieval.
Constraints for Reranking and Hybrid Retrieval
Data is updated per version cycle. A single retrieval must be limited to the target version range to prevent cross-version content from disrupting user inquiries. Change type (breaking/regular) is a core business field. The reranking step must prioritize matching version risk points that users care about. Data comes from multiple heterogeneous sources. Hybrid retrieval must support content in varying formats, including Git metadata and change text. The time-consuming task of categorizing changes requires retrieval results to directly point to clear change descriptions, cutting down on subsequent manual sorting costs.
Configuration Settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
usingReRank | Enabled | For structured change content in Release Notes, reranking can first filter irrelevant historical change entries and match version details that users inquire about |
limit | Top 8 entries | Single-version change entries typically number 10-20. Limiting returns to the top 8 entries avoids result overload and adapts to the quick review needs of pre-sales Q&A |
similarity | 0.75–0.85 | For matching core fields such as version numbers and change descriptions, this range filters low-relevance cross-version content while retaining sufficient candidate entries |
searchMode | Hybrid retrieval | Combines Git tag metadata and change log text to cover multi-dimensional questions that users may ask, such as version numbers, breaking changes, and artifact associations |
Three Common Misconfigurations
- Phenomenon: After enabling the reranking model, application retrieval returns no results, but knowledge base tests work normally. Cause: The version tag field of Release Notes is not configured as retrieval metadata. When the reranking model only matches text content, it filters entries linked to core version numbers.
- Phenomenon: Reranking results have inconsistent priority, and breaking changes do not appear first. Cause: Matching weights are not adjusted for the change type field, so regular change entries disrupt the sorting logic.
- Phenomenon: Retrieval results include historical change content from across versions. Cause: The retrieval range is not limited to the current target version via
searchMode, or thesimilaritythreshold is set too low, matching content from unrelated versions.
How to Confirm Successful Configuration
- In the knowledge base test interface of FastGPT v4.17.0, enter an inquiry that includes the target version number to verify that retrieval results include change content for that version.
- Check the reranking model activation logs to confirm that the
usingReRankparameter is enabled, and that retrieval results prioritize breaking change entries. - Adjust the
similaritythreshold, observe changes in retrieval result relevance, and confirm that the threshold range meets business needs. - Simulate a pre-sales consultation scenario, enter questions about artifact associations and rollback risks, and verify that
searchModecovers multi-dimensional retrieval requirements.
The values provided here are common starting points and 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.