What data belongs to this category
The primary data for this category consists of daily operational documents for SREs, on-call operations staff, and on-call development leads. This includes fault tickets, event timelines, emergency response plans, and fault notifications. Fault tickets contain fields such as event ID, occurrence time, affected service scope, and current disposal status. Event timelines are sorted by timestamp, recording the full sequence of alert triggers, executed operations, and state changes. Emergency response plans divide disposal processes by impact level. Data sources include real-time pushed monitoring alerts, aggregated log platforms, APM trace data, and user feedback tickets. Data is updated each time an incident is triggered.
What constraints do these characteristics impose on the model access and configuration workflow
Real-time updated incident data requires model call latency to align with the service interruption window allowed by the business, to avoid extending fault recovery time. Multi-source heterogeneous data formats require model access to support prompt splicing for multiple data types, with parameters adapted to length differences across data sources. Structured fields in fault tickets and notifications require model outputs to follow fixed formats, with output length and format constrained. Severe potential consequences require configuring failure retry and degradation strategies, to avoid delaying disposal due to model call failures.
How to set configurations
| Configuration Item | Recommended Range | Rationale |
|---|---|---|
maxContext | 8000–12000 token | Matches the spliced multi-source data length of fault incidents, avoids truncating critical alert and log content |
maxTokens | 1500–2000 token | Limits the length of disposal suggestions output by the model, adapts to the fast reading needs of operations personnel |
quoteMaxToken | 3000–4000 token | Restricts the length of referenced original alert and log data, avoids call failures caused by overloaded context |
toolChoice | auto | Allows the model to independently choose whether to call built-in fault disposal tools, adapts to disposal needs across different scenarios |
temperature | 0.2–0.4 | Reduces output randomness, ensures consistency and executability of disposal suggestions |
AIPROXY_API_ENDPOINT | Fill in the root address of the AI Proxy service, for example http://aiproxy:3000. Do not append /v1 or model path suffix | Serves as the root address for the AI Proxy service, ensures correct request routing, adapts to multi-tenant and cross-region model call needs |
Three common configuration errors
- Phenomenon: After upgrading FastGPT v4.17.0, setting
AIPROXY_API_ENDPOINTto an m3e model address returns a call failure with a parameter format error prompt. Cause:AIPROXY_API_ENDPOINTmust be the root address of the AI Proxy service, not a single model address. An address with a model path was incorrectly configured. - Phenomenon: When configuring a local reranking model, the interface displays a request error with a 500 status code returned. Cause: Cross-domain access is not enabled for the local model deployment port, or the upstream model channel configuration is incorrect.
AIPROXY_API_ENDPOINTis the root address of the AI Proxy service; do not point it to the local model listening address. - Phenomenon: As concurrent requests increase, model answer latency increases significantly, accompanied by MongoDB write timeouts. Cause:
maxContextis set too large, with each call needing to load excessive historical incident data, leading to extended time spent on MongoDB queries and context splicing.
How to confirm the configuration is complete
- Check the environment variables deployed on the FastGPT server, confirm that non-empty
AIPROXY_API_ENDPOINT(AI Proxy service root address) andAIPROXY_API_TOKEN(AI Proxy admin token) are configured, and the configuration matches the deployment environment. - Trigger a simulated fault incident, verify that the disposal suggestions output by the model meet preset format and length requirements.
- Adjust the number of concurrent requests, observe whether model call latency in system monitoring falls within an acceptable range.
- Check the log platform for successful model call logs, with no error messages present.
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.