What this category of data looks like
Data for this category primarily comes from Kubernetes APIs, image registries, monitoring systems, and CI pipelines. Update frequency is either daily or upon each cluster change. Daily generated documents include cluster change tickets, namespace quota tables, deployment records, and fault reports. Data fields include cluster identifiers, namespace names, Pod running statuses, image versions, change times, and more. Units used include bytes, seconds, and entry counts.
What constraints these characteristics impose on re-ranking and hybrid retrieval
Heterogeneous data sources create differences in document formats. Hybrid retrieval must adapt to both structured data such as quota tables and unstructured data such as fault reports. Daily or cluster-change-based update frequency requires retrieval results to align with data timeliness. The re-ranking step must prioritize cluster data from the most recent changes. Core operational scenarios center on resource quota adjustments and Pod exception troubleshooting. Re-ranking logic must prioritize high-frequency operational keywords to prevent irrelevant results from disrupting troubleshooting efficiency.
How to set the configurations
| Configuration Item | Recommended Setting | Rationale for This Setting |
|---|---|---|
usingReRank | Enabled | Container platform operations data includes structured quota tables and unstructured fault reports. Enabling re-ranking filters irrelevant results and improves troubleshooting efficiency |
similarity | 0.72–0.85 | Matches the specialized terminology density of operational scenarios. Prevents missing critical fault reports if the threshold is too high, and avoids introducing redundant data if the threshold is too low |
limit | Top 8–12 entries | Covers the core number of documents required for a single operational troubleshooting session. Prevents excessive results from increasing engineer filtering costs |
searchMode | hybrid | Adapts to structured data from Kubernetes APIs and unstructured data from monitoring logs. Hybrid retrieval can return both quota information and abnormal logs |
Three common misconfigurations
- Phenomenon: Retrieval result order does not adjust as expected, with no clear error logs in the console. Cause: The
usingReRankparameter is not enabled, or the re-ranking model is not bound to the current retrieval task. - Phenomenon: The re-ranking model selection box cannot be selected when creating an application, and a parameter missing prompt appears in the configuration panel. Cause: The access information for the re-ranking model is not correctly configured in the system configuration file, or the configuration format does not comply with the validation rules of FastGPT v4.17.0.
- Phenomenon: Redundant content is not filtered from results returned after calling the re-ranking API, and retrieval latency does not decrease as expected. Cause: The
similarityparameter range is not set correctly, or thelimitparameter value is too large, leading to excessive re-ranking calculation load.
How to confirm the configuration is correctly applied
- Access the FastGPT v4.17.0 management backend, navigate to the retrieval configuration page for the target container platform operations knowledge base, and verify that the
usingReRankparameter is enabled. - Execute a simulated retrieval, input high-frequency operational keywords such as "Pod CrashLoopBackOff", and check whether retrieval results are reordered by relevance.
- Verify that the
similarityparameter value range matches the document density of the current knowledge base, and that thelimitparameter value matches the document requirements for a single troubleshooting session. - Review system logs for successful re-ranking model call logs, with no error prompts present.
The values provided are common starting points and should be measured against local sample data.
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.