What This Category of Data Looks Like
The data for this category primarily comes from Git repository tags, merged commit records, CI build artifacts, and Issue milestones. The update frequency is once per version, with all content generated during a single release cycle. The core daily produced documents are Release Notes, change logs, version tags, and release checklists. Data fields include version numbers, change types, associated commit IDs, artifact verification information, and more. There is no unified format, but all content is bound to a specific version identifier. This binding is used to clarify the correspondence between changes and versions.
What Constraints Do These Characteristics Impose on Knowledge Base Retrieval and Recall?
The characteristics of this category of data impose multiple constraints on retrieval and recall. First, data is updated in version-specific batches and bound to a unique version identifier. This requires adding version range filter conditions during retrieval to prevent irrelevant cross-version data from being recalled. Second, core content includes high-impact semantics such as breaking change descriptions. Results matching the change type and version relevance must be prioritized for recall. Third, the data includes short string fields such as commit IDs and artifact hashes. Retrieval logic must adapt to text blocks of different lengths. Fourth, data is generated in batches during the release cycle. The retrieval pipeline must support temporary incremental index loading to avoid excessive resource usage from full index rebuilding.
Configuration Settings
The following configurations apply to FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
similarity | 0.65–0.75 | Matches the recall accuracy for high-semantic content such as breaking changes in this category. Prevents irrelevant results from being included if set too low, and prevents valid change descriptions from being missed if set too high |
limit | Top 8–12 results | The document content per version in this category is moderately sized. Recalling 8 to 12 results at a time covers core change information, and avoids excessive results exceeding the context window |
searchMode | vector | This category of data contains a large number of structured and semi-structured fields. Vector retrieval better matches semantically related change content |
usingReRank | Enabled | Enhances the sorting priority of results with high relevance to breaking changes and version associations, improving the matching accuracy of user queries |
datasetSearchUsingExtensionQuery | Enabled | Automatically expands query semantics to cover synonyms such as "change log" and "release notes", adapting to vague user queries about version-related content |
collectionIds | Specify the collection ID of the version-specific documents | Precise limitation of the retrieval scope, avoiding interference from cross-version data, which aligns with the data isolation by version characteristic of this category |
Three Common Configuration Mistakes
- Symptom: No results are returned when calling the knowledge base API, and version change content cannot be obtained. Cause: The
collectionIdsconfiguration for limiting the retrieval scope is not set, so the system cannot locate the Release Notes documents for the corresponding version. - Symptom: An error occurs in the question answering pipeline after configuring the knowledge base, but the knowledge base search test runs normally. Cause:
datasetSearchUsingExtensionQueryis not enabled, so the query cannot match version-related keywords in synonym form, and the downstream pipeline cannot parse the result format. - Symptom: The knowledge base model is clearly configured, but the question answering function cannot return qualified version change content. Cause:
usingReRankis not enabled, resulting in disordered sorting of results with similar semantic matching degrees, so key change information is not prioritized for recall, or thesimilaritythreshold is set incorrectly, causing valid results to be filtered out.
How to Verify Proper Configuration
- Access the knowledge base retrieval configuration interface, check whether
collectionIdsis bound to the version-specific document collection for this category. - Submit a test query containing "vX.X.X breaking change" to verify that the returned results include the change description for the corresponding version.
- View the retrieval logs to confirm that the parameter values of configuration items such as
similarityandusingReRankmatch the preset values. - Compare retrieval results with and without
datasetSearchUsingExtensionQueryenabled to confirm that synonym expansion is working.
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.