What Data This Category Includes
Data for this category typically originates from Kubernetes APIs, image registries, cluster monitoring systems, and CI pipelines. Updates occur daily or after each cluster change. Daily operations documentation includes cluster change tickets, namespace quota tables, Pod deployment records, and fault reports. Fields include cluster ID, namespace name, resource quota values, Pod status codes, and fault root causes. There is no unified unstructured format. Some data takes the form of structured API return results.
Constraints on Knowledge Base Retrieval and Recall
Data sources for container platform operations include structured API results and unstructured operations documentation, with a high update frequency. Knowledge base retrieval and recall must balance structured matching and timeliness. Different types of operations documentation, such as quota tables and fault reports, have substantial differences. Retrieval scopes must be split by cluster and namespace to prevent retrieval of irrelevant data. Queries for high-frequency scenarios like resource quota adjustment and Pod exception troubleshooting require precise recall results and concise context. Excessively redundant documentation must not be returned.
How to Configure Settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
similarity | 0.65–0.75 | Matches term density in container operations scenarios, filters low-relevance cluster configuration documents |
limit | Top 10 entries | Controls the number of documents retrieved per call, avoids context overload that reduces Pod exception troubleshooting efficiency |
usingReRank | Enabled | Performs secondary ranking on initially retrieved fault reports and monitoring alert documents, improves accuracy of root cause localization |
datasetSearchUsingExtensionQuery | Enabled | Automatically supplements context keywords such as cluster ID and namespace, matches structured quota tables and change tickets |
collectionIds | Specified per target cluster | Limits retrieval scope to the knowledge base collection for the current operations cluster, reduces interference from cross-cluster irrelevant data |
Three Common Misconfigurations
- Semantic retrieval scores fall outside the 0-1 range, displaying values in the thousands. This occurs when normalization rules for the
similarityparameter are not configured correctly, and raw embedding similarity scores are used directly. - API calls cannot return associated knowledge base file lists. This happens when the file metadata return switch for the dataset is not enabled, or the
collectionIdsparameter is not correctly specified to link the knowledge base collection for the target container cluster. - Knowledge base capacity estimates are significantly inaccurate. This occurs when total storage requirements are not calculated using the average character count per document for cluster change tickets and deployment records (approximately 800–1200 characters). Raw file sizes are incorrectly summed instead.
How to Verify Successful Configuration
- Submit a test query for Pod exception troubleshooting. Confirm that the
similarityscores of returned results fall within the 0.65–0.75 range. - Call the knowledge base file list API. Confirm that all returned files belong to configuration documents and operations records for the target container cluster.
- Run a simulated resource quota adjustment query. Confirm that recall results include relevant documents such as namespace quota tables and cluster change tickets.
- Check the FastGPT v4.17.0 retrieval logs. Confirm that
usingReRankanddatasetSearchUsingExtensionQueryare active, with no parameter configuration errors.
The values provided here are common starting points. They should be evaluated against samples from the relevant deployment.
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.