What this category of data looks like
This category of data originates from SIEM, EDR, NDR, and threat intelligence sources. Update cycles fall into two categories: real-time and daily. Daily processed documents include alarm disposal sheets, duty logs, threat intelligence reports, and daily/weekly reports. Alarm disposal sheets contain fields such as alarm ID, associated assets, disposal steps, and false positive tags. Duty logs cover duty periods and alarm transfer records. Threat intelligence reports include structured and unstructured content: threat type, impact scope, disposal suggestions, and more. Change review-related data includes code snippets, commit logs, review comments, and more. The overall data structure is complex, with large volumes of unstructured text.
Constraints imposed by these characteristics on context and token handling
Real-time alarm data creates frequent needs for context concatenation. Information associated with a single alarm, such as assets and disposal steps, may consume large amounts of tokens. Daily updated weekly reports and threat intelligence reports may contain long text that exceeds the base context window. When mixing multiple source data inputs, distinguish the priority of alarm fields and intelligence fields. This prevents irrelevant information from occupying valid context space. In code and change review assistance scenarios, binding review code snippets, commit logs, and alarm data further increases context token usage. Without proper configuration, context overflow and truncation of critical information become likely.
Configuration settings
The following configurations apply to FastGPT v4.17.0:
| Configuration Item | Recommended Range | Rationale |
|---|---|---|
maxContext | 8000–16000 token | Adapts to mixed input lengths of multi-source alarms and change logs in SOC scenarios, covering the base context windows of most mainstream large models |
quoteMaxToken | 2000–4000 characters | Limits the token share of a single alarm or change review code snippet reference, preventing single entries from occupying excessive overall context |
| Single recall limit | Top 10 entries | Controls the number of real-time alarm data recalls, preventing excess historical data from occupying context space |
| Context truncation strategy | Retain latest alarms and core change content | Prioritizes the latest alarms and change logs associated with current reviews, truncates expired historical duty records |
| Chunk overlap length | 200 characters | Adapts to the short paragraph structure of alarm disposal sheets, preventing critical disposal steps from being truncated during chunking |
Three common configuration mistakes
- Symptom: System prompts that context length exceeds limits, preventing association analysis of alarms and change reviews. Cause: Failing to adjust configurations for the multi-source data characteristics of SOC scenarios, using default small window parameters directly.
- Symptom: AI Proxy throws errors, with logs showing get tiktoken failure. Cause: Incorrect configuration of local tokenizer dependencies during offline deployment, or failure to point the tiktoken cache path to an offline storage directory.
- Symptom: Some tasks experience context truncation when processing multiple alarm review tasks concurrently. Cause: Failing to limit the token usage cap per task, leading to excessive overall token pool occupancy in concurrent scenarios.
How to confirm correct configuration
- Import a single complete alarm disposal sheet and change log, check the system-displayed context usage to confirm it does not exceed the configured maximum context threshold.
- Launch multiple concurrent review tasks, observe task execution status to confirm no context overflow or token occupancy abnormality errors occur.
- Check AI Proxy runtime logs to confirm no tiktoken-related connection or parsing errors are present.
- After adjusting configuration items, re-import a long-text threat intelligence report to verify that critical information is not truncated.
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.