What the data for this category looks like
This category of data comes from ticketing systems, chat logs, product logs, and customer contract SLAs, with a daily or real-time update frequency. Daily documents include customer tickets, issue tiering tables, processing records, and service reports. Tickets contain fields such as unique identifier, issue description, associated product module, customer feedback time, and tiering tags. Issue tiering tables include fields such as priority, response time limit, and responsible team mapping. Processing records include fields such as response duration and resolution results. Service reports include statistical items such as total number of tickets and tiering distribution within the cycle.
What constraints these characteristics impose on the knowledge base retrieval and recall link
Decentralized data sources and flexible update frequencies require retrieval systems to support cross-domain recall of multi-source data, while adapting to index logic for real-time incremental updates to avoid excessive resource consumption from full indexing. Significant differences in field structures between tickets and tiering tables require configuring differentiated recall rules for different document types, to prevent irrelevant content from interfering with issue matching. SLA-related data has high timeliness requirements; retrieval must prioritize matching near-real-time updated SLA rules to ensure issue tiering complies with compliance requirements. Most customer chat logs are unstructured colloquial content, so semantic matching accuracy needs to be optimized to reduce misjudgments caused by fuzzy matching. Ticket volume fluctuates with business; retrieval must support dynamic adjustment of recall limits to avoid service response delays caused by resource overload.
How to set configurations
The following configurations are formulated based on FastGPT v4.17.0.
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
similarity | 0.75–0.85 | Adapt to the semantic matching accuracy of ticket issue descriptions, and avoid recalling irrelevant tickets or tiering rules |
limit | Top 10 entries | Control the number of results retrieved in a single call, adapting to the scenario where customer service teams browse results quickly |
searchMode | semantic | Improve the accuracy of semantic matching for unstructured tickets and chat logs |
usingReRank | Enabled | Optimize the sorting logic of recall results, prioritizing content with higher relevance to the issue |
datasetSearchUsingExtensionQuery | Enabled | Generate extended queries based on the original question to cover synonyms and industry terminology, improving recall coverage |
Three common mistakes
- Phenomenon: Indexing tasks stall, the interface shows no update to indexing progress, and uncompleted ticket data cannot be retrieved. Cause: The indexing breakpoint resume function is not configured. After a full indexing process is interrupted, it cannot be resumed, resulting in partial data not being indexed.
- Phenomenon: Duplicate tickets or tiering rule entries appear in retrieval results. Cause: File deduplication verification for the knowledge base is not enabled, and documents with the same content are indexed multiple times, leading to duplicate recall.
- Phenomenon: The retrieval API returns a format error prompt containing the
$schemafield. Cause: Non-standard metadata fields were mistakenly introduced when configuring dataset associations, violating FastGPT's interface format requirements.
How to confirm the configuration is complete
- Upload a test ticket document and issue tiering table, perform a retrieval test, and check whether the recall results include the target content.
- View the indexing log to confirm that incremental indexing updates automatically at a daily or real-time frequency, with no stalls.
- Check the sorting of retrieval results to confirm that high-relevance content is displayed first after the reranking switch is enabled.
- Compare retrieval results with and without the question optimization switch enabled, confirming that extended queries improve recall coverage.
The values provided 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.