What the data for this category looks like
Daily documents for container platform operations typically include cluster change tickets, namespace quota tables, deployment records, and incident reports. Data sources include Kubernetes API, image registries, monitoring systems, and CI pipelines. Update frequency is daily or upon each cluster change. Document fields include namespace name, Pod replica count, image version, incident occurrence time, ticket number, and more. Units include entries, GB, hours, and others. Single record length ranges from tens of characters to thousands of characters.
What constraints do these characteristics impose on the knowledge base retrieval and recall link
Real-time data updates require retrieval to prioritize recalling cluster change and incident records from the last 7 days, to avoid returning outdated content. Differences in document structure across multiple sources require retrieval to distinguish field rules for different collections. For example, numeric fields in quota tables must match resource adjustment tickets. Text fields in incident reports must match exception troubleshooting questions. Data volume grows as cluster scale increases. The number of single-recall results must be limited to prevent context length from exceeding model processing limits. Irrelevant image registry historical records must also be filtered.
How to configure
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
similarity | 0.72–0.80 | Matches the precise troubleshooting needs of container operations, filters irrelevant cluster change records |
limit | Top 6 entries | Controls context length, adapts to the concise Q&A scenario of operational tickets |
usingReRank | Enabled | Reorders recall results by relevance, optimizes the display order of incident reports and change tickets |
datasetSearchUsingExtensionQuery | Enabled | Automatically expands the semantic scope of operational questions, for example, supplementing "Pod startup failure" with corresponding troubleshooting steps |
collectionIds | Bound to the exclusive knowledge base collection for the current cluster | Prevents recalling irrelevant data from other clusters, ensuring precise retrieval scope |
Three common mistakes
- The symptom is "permission denied to access dataset" when debugging the knowledge base. The cause is failing to bind the current operations team's role to the specified
collectionIdscollection. - The symptom is recall results including cluster change tickets older than 7 days. The cause is not configuring an update-time-based filter rule, or not limiting the retrieval time range.
- The symptom is retrieved results failing to match specific Pod exception troubleshooting steps. The cause is not enabling
datasetSearchUsingExtensionQueryautomatic query expansion, leading to insufficient semantic matching accuracy.
How to confirm the configuration is correct
- Navigate to the knowledge base debugging page of FastGPT v4.17.0, enter a test operational ticket question, and verify that the collection of recall results is the exclusive collection for the current cluster.
- Adjust the
similaritythreshold, observe changes in the relevance of recall results, and confirm the threshold meets the precision needs of operational troubleshooting. - After enabling
usingReRank, compare the order of results before and after reordering, and confirm that highly relevant incident reports appear first. - Submit a test resource quota adjustment ticket, and confirm that the retrieval results include the corresponding namespace quota table content.
The values given 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.