What the Data for This Category Looks Like
The core data for this category comes from Kubernetes API, image registries, cluster monitoring systems, and CI pipelines. Daily operation and maintenance documents include cluster change tickets, namespace quota tables, Pod deployment records, and troubleshooting reports. Data is updated either daily or in real time when cluster changes occur. Document fields include professional operation and maintenance fields such as namespace name, Pod status, image version, resource quota threshold, and failure timestamp. The overall data structure is a mixed form of structured metadata and semi-structured operation and maintenance logs.
Constraints for Reranking and Hybrid Retrieval
Since data sources cover multiple cluster systems, hybrid retrieval must match both semantic content and structured metadata to avoid retrieving irrelevant cross-cluster configurations. Data updates are triggered by cluster changes, so the retrieval pipeline must support real-time synchronization. The reranking step must first filter expired cluster change records and resolved fault reports. The core requirement of operation and maintenance troubleshooting scenarios is to accurately match fault-related documents. The reranking step must adjust ranking based on professional term weights to avoid low-relevance general operation and maintenance documents interfering with troubleshooting efficiency. Because errors here can lead to business interruptions, the accuracy of retrieval results must be strictly controlled.
How to Configure the Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
| Similarity Threshold | 0.70–0.85 | Match professional terminology for container platform operation and maintenance documents, covering core retrieval needs for troubleshooting and quota adjustments |
| Single Search Limit | Top 6–10 entries | Control the number of documents returned per search, balancing retrieval efficiency and result completeness for multi-source cluster data |
| Search Mode | hybrid | Enable hybrid retrieval mode, combining vector semantic matching and metadata filtering, adapting to the multi-source heterogeneous data structure of Kubernetes clusters |
| Enable Reranking | Enabled | Optimize result ranking via reranking for long-text fault reports and cluster change tickets, improving the accuracy of operation and maintenance troubleshooting |
| Reranking Score Threshold | 0.75 | Filter results with reranking scores below this value, preventing low-relevance documents from entering the final context |
This configuration applies to FastGPT v4.17.0.
Three Common Configuration Errors
- The retrieval result reranking field returns false, and the knowledge base test page shows reranking is not effective: The corresponding reranking model is not bound in the FastGPT configuration, or the deployment port of the reranking model is not properly opened to the retrieval pipeline.
- Hybrid retrieval only returns pure vector matching results, without filtering using metadata such as namespace and cluster ID: The search mode is not correctly set to hybrid, and only pure vector retrieval logic is enabled.
- The channel model configuration page only displays reranking model options, and other large language models cannot be selected: The association link between the base model and the reranking model is not properly configured during commercial deployment, resulting in a limited range of selectable models.
How to Verify Correct Configuration
- Navigate to the knowledge base's retrieval test page, enter a query about cluster Pod exception troubleshooting, and check if the returned results rank fault reports and deployment records at the top.
- View the FastGPT system logs, confirm that reranking model call records exist, and that returned result scores meet the configured threshold requirements.
- Verify the hybrid retrieval mode, enter a query with a specified namespace, and confirm that returned results only include documents from the corresponding namespace.
- Check the reranking switch status on the configuration page, confirm that the reranking function is enabled and the correct reranking model is bound.
The values provided here 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.