What this category's data includes
Data for this category typically includes fields such as VPC subnet configuration, security group port rules, load balancer backend server groups, and health check thresholds. Units used include milliseconds, count, IP ranges, and port numbers. Data sources include configuration files exported from cloud platform consoles, network topology diagrams, traffic monitoring logs, and architecture change forms submitted by customers. Updates are synchronized with every completed network change. Core associated fields for individual data entries include configuration ID, change order number, and associated server group information.
Constraints on the reference source and traceability link
Data for this category is updated synchronously with each individual change. Core associated fields rely on change order numbers. The traceability link must bind change order IDs to ensure traceability results match the latest configuration. Data sources include multiple types of heterogeneous documents, such as cloud platform consoles and network topology diagrams. The priority of different data sources must be clarified to avoid confusing real-time exported configurations with historical topology data. Most fields are network-specific, such as IP ranges and port numbers. Traceability matching must focus on core fields to avoid matching failures caused by differences in non-key fields. Data update frequency is high. Traceability results must be timely and synchronized with current configurations.
How to set configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
quoteMaxToken | 800–1200 token | Cloud network configuration documents typically fall within this range. This avoids truncating critical configurations such as health checks and port rules. |
| Traceability Matching Threshold | 0.85–0.95 | This meets the precision requirement for matching core fields such as IP ranges and port numbers. It avoids recalling irrelevant configurations. |
responseData | Only return configId, changeOrderId, topologyPath | This reduces redundant data returned by traceability, and focuses on core associated fields. |
detail | Enabled | Configuration change details must be displayed for traceability, such as changes to security group rules. |
| Reference Source Binding Rule | Bind by change order ID | Cloud network configuration updates use change orders as the smallest unit. This makes it easier to trace complete change histories. |
| Traceability Recall Limit | Top 3 entries | Single cloud network configuration typically associates with no more than 3 change records. This avoids information overload. |
Three common mistakes
- Phenomenon: When referencing cloud network configuration variables in a workflow, variables passed via the API cannot match the corresponding knowledge base content. Cause: Variables are not bound and mapped to the fields specified by
responseData. This prevents the traceability link from recognizing the passed configuration ID. - Phenomenon: Calling the chat API first returns an empty reference list, or returns irrelevant subnet configuration entries. Cause: The correct traceability matching threshold is not set. This leads to insufficient matching precision, and irrelevant IP ranges or port rules are recalled.
- Phenomenon: Local knowledge base content associated with the configuration is not correctly referenced, and returned results do not include change order details. Cause: The
detailparameter is not enabled. This causes the traceability link to only return basic configuration information, and not associate the corresponding change documents.
How to confirm configurations are set correctly
- In FastGPT v4.17.0, call the test API with a known cloud network configuration ID. Check if the returned reference list includes the corresponding change order ID and configuration details.
- Adjust the traceability matching threshold. Verify if the number of recall results matches expectations across different thresholds, to confirm the threshold range fits the current business data.
- Review the variable mapping configuration of workflow nodes. Confirm that API variables passed are correctly bound to the fields specified by
responseData. - Check the
quoteMaxTokensetting. Ensure long configuration documents are not truncated, and critical fields such as health checks and port configurations are fully displayed.
The values listed 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.