Drafting Requirements and Design Documents for Incident Management and Root Cause Analysis: Context and Token

Data for this category focuses on post-incident root cause analysis and issue closure. Teams use common documents including RCA reports, incident

Data Profile for This Category

Data for this category focuses on post-incident root cause analysis and issue closure. Teams use common documents including RCA reports, incident tickets, post-incident review minutes, and rectification tracking sheets. Data sources include incident timelines, system logs, monitoring metrics, and code commit records. The system updates data either following each major incident or once per month. Data fields include incident occurrence time, root cause description, rectification measures, and tracking status. There are no unified fixed units; values adjust flexibly based on document type. Data linked to a single incident typically covers logs and records spanning several hours to several days.

Constraints on Context and Token Processing

The data characteristics of this category impose multiple constraints on the context and token processing workflow. Data sources are scattered, and single-incident data volume varies based on incident scale. Strictly control the total context-loaded token count to avoid exceeding model processing limits. The system does not require frequent context refreshes because update frequency is not real-time. Trigger synchronization based on incident cycles or document updates. Common documents contain structured and semi-structured content. Split tokens reasonably for long documents such as complete incident timelines, while retaining key associated information. Root cause analysis relies on cross-source data correlation, so context must cover relevant logs, monitoring, and code records. Define clear recall scope to avoid interference from irrelevant information.

Configuration Settings

In FastGPT v4.17.0, adjust the context and token processing logic using the following configuration items:

Configuration ItemRecommended ValueRationale
maxContext8000–12000 tokenSingle-incident analysis for this category needs to cover multi-source data including incident timelines, logs, and monitoring metrics. This value can accommodate key associated information for typical incidents while adapting to the context limits of most open-source models
quoteMaxToken1500–2000 charactersSingle key segments of common documents such as RCA reports and review minutes typically fall within this range. This retains complete semantics while avoiding excessive splitting
Maximum context recall countTop 6 entriesRoot cause analysis requires correlation of key evidence. Excessive recall introduces irrelevant data. 6 entries can cover major incident-related logs and monitoring records
Full paragraph retention configurationRetain by document block markersSome key content such as continuous records of incident timelines should not be split. This configuration prevents semantic integrity damage from keyword splitting
Context refresh trigger conditionUpdate upon incident closureUpdate frequency for this category is either after each major incident or once per month. Updating based on incident nodes ensures context timeliness

Three Common Configuration Errors

  • Symptom: The system fails to retain context for continuous incident analysis across conversations, and subsequent questions cannot link to previous root cause hypotheses. Cause: The maxContext parameter is not configured correctly, or the recall count is set too low, failing to load key historical data.
  • Symptom: Key paragraphs such as complete incident timelines are split into multiple token chunks, leading to semantic fragmentation. Cause: Full paragraph retention configuration is not enabled, and the system automatically splits long text that should not be split.
  • Symptom: After attempting to configure maxContext to 2000 token, sufficient incident log data cannot be loaded. Cause: The parameter is not adjusted based on the data volume of this category. 2000 token is insufficient to cover multi-source associated information for typical incidents, and the configuration item was not modified correctly in the corresponding interface.

How to Verify Proper Configuration

  • Import a typical RCA report and associated incident logs, check whether the context content loaded by the system includes the root cause description and key log fragments in the report.
  • Initiate a continuous conversation, ask questions containing incident time, root cause hypotheses and other associated content, and confirm that subsequent questions can correctly link to historical context.
  • View the token usage statistics returned by the system, confirm that the actual used token count does not exceed the configured maxContext limit, and that unnecessary long text splitting does not occur.
  • Trigger a simulated incident update, confirm that the context content is refreshed according to the configured trigger conditions.

The values provided are common starting points and should be measured against respective 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.