What this category of data looks like
The core data for this category consists of daily operation and maintenance records from enterprise IT service desks. Sources include ITSM systems, phone and online chat interaction logs, enterprise asset systems, and internal technical knowledge bases. Data updates run daily or in real time. New ticket submissions, processing progress updates, and satisfaction feedback sync to the data source immediately or once per day. Document structures include fields such as ticket ID, problem description, processing steps, associated asset number, and user satisfaction score. Each entry is tied to a single ticket, with most fields using technical terminology or operation and maintenance-related text.
Constraints imposed on the knowledge base retrieval and recall link
Scattered data sources and multi-system operation and maintenance text require the retrieval link to support cross-knowledge base associated recall. This prevents missed cross-system related information. Frequent data updates require the retrieval link to adapt to incrementally updated knowledge base content. This avoids returning outdated operation and maintenance solutions. Ticket problem descriptions focus on specific technical faults, with concentrated professional terminology and relatively fixed phrasing. This demands a recall capability that balances semantic matching and keyword matching. Ticket processing must meet service time requirements. The retrieval link must ensure fast response times to avoid timeouts caused by excessive recall latency.
How to configure settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
similarity | 0.75–0.85 | Technical problem descriptions in IT service tickets are highly specialized. This threshold filters irrelevant results and retains knowledge base content that closely matches fault descriptions |
limit | Top 10–15 results | Balances recall coverage and model context length limits. It prevents excessive redundant results from exceeding the model's processing capacity |
searchMode | vector + fulltext | Adapts to tickets that have both semantic associations and clear technical keywords. Mixed recall mode improves result accuracy |
usingReRank | Enabled | Multi-knowledge base recall results may contain redundancy. Reranking optimizes the relevance of top results to support rapid ticket troubleshooting |
datasetSearchUsingExtensionQuery | Enabled | Ticket problem descriptions may have ambiguous phrasing. Extended queries add synonyms and technical term variants to improve recall coverage |
collectionIds | Bind to the IT service desk's dedicated knowledge base collection | Isolates business data and prevents unrelated knowledge base results from interfering with ticket processing workflows |
Three common configuration mistakes
- Symptom: After mounting multiple knowledge bases, returned results do not follow the expected priority order. Troubleshooting: Confirm the
collectionIdsparameter specifies the priority knowledge base collections. This avoids mixing results from all mounted knowledge bases. - Symptom: After importing knowledge base documents using mongorestore, the imported content cannot be queried. Troubleshooting: Confirm the document index rebuild operation has completed. This ensures imported raw data has generated vector or full-text indexes recognizable by the retrieval link.
- Symptom: After batch retraining knowledge base documents, retrieval results do not update. Troubleshooting: Confirm the knowledge base's vector index has been rebuilt, and real-time recall logic has been triggered. Do not use outdated cached index results.
How to verify successful configuration
- Check the FastGPT v4.17.0 server environment variables. Confirm
AIPROXY_API_ENDPOINT(the root address of the AI Proxy service, for example http://aiproxy:3000. Do not append /v1 or /chat/completions. This is not a single-model address for VLLM/Ollama/Xinference) andAIPROXY_API_TOKEN(the AI Proxy administrator token, matching the AI Proxy server configuration and not empty. This is not an application API key, model vendor key, or per-application issued token) are correctly set and not blank. Missing these configurations causes service startup verification to fail, per official deployment requirements. - Run a simulated ticket query. Verify returned results include content from the specified dedicated knowledge base, and the result count matches the
limitparameter range. - Adjust the
similarityparameter value, then run a duplicate query. Observe changes in result relevance to confirm the parameter configuration took effect. - Review the AI Proxy service logs. Confirm no connection timeout or authentication failure errors appear in retrieval requests. This ensures the retrieval link operates normally.
The values provided are common starting points and should be evaluated 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.