What the data for this category looks like
Data for this category mainly comes from team-maintained source code repositories, third-party dependency lists, static application security testing (SAST) tool output results, and public vulnerability databases. Target users include security R&D teams, security service providers, and development teams. Daily deliverables include code audit reports, vulnerability proof materials, repair recommendation documents, and retest records. Data updates follow project version iterations or individual audit task progress, typically updated per version or upon completion of an independent audit project. Data fields cover code file paths, dangerous function call records, vulnerability impact scope, repair status, and more. There are no unified fixed units, adjusted flexibly based on document type.
What constraints these characteristics impose on the "context and token" link
Data for this category is scattered, and a single audit covers a large number of code files and dependencies. This easily causes the total context token count to exceed the model's preset limit. Data is updated in real time with project version iterations, so the context must be linked to the latest code versions, vulnerability database information, and repair records. Fixed cached contexts cannot be relied on. Daily documents contain multiple types of structured content, with significant differences in reference value across different fields. Effective fragments must be accurately screened, and the maxContext and quoteMaxToken parameters must be properly set to control token consumption. Additionally, cross-document relationships such as the binding between vulnerabilities and repair records need to be retained. This further increases the complexity of context and token management. Improper handling may lead to key logic being omitted or invalid content occupying excessive resources.
How to set the configurations
| Configuration Item | Recommended Range | Rationale |
|---|---|---|
maxContext | 8000–12000 token | The context for a single code security audit project typically includes multiple audit reports and code snippets. This range covers the needs of most small and medium-sized audit projects, and is compatible with the model adaptation scope of FastGPT v4.17.0 |
quoteMaxToken | 2000–3000 characters | The core content of a single vulnerability proof or repair recommendation typically falls within this range, allowing accurate extraction of key information while avoiding invalid token consumption |
| Single recall limit | Top 6 entries | Context entries related to code auditing need to focus on high-risk content. Excessive entries will cause token overflow, and 6 entries can cover the main high-risk vulnerabilities and associated code snippets |
| Context slice overlap length | 150–200 characters | The key logic of code snippets typically spans adjacent blocks. The overlap length avoids cutting key logic while controlling the total token count |
| Context refresh rule | Triggered by project version | Data for this category updates with project versions, and refreshing by version ensures the context is always linked to the latest code and audit results |
Three common mistakes
- Phenomenon: A context overflow error is returned when calling the code security audit tool, or generated content is truncated with missing high-risk vulnerability information. Cause: The
maxContextparameter is not adjusted based on the actual data scale of the audit project, and the default small-range configuration is used, resulting in insufficient tokens. - Phenomenon: After consecutively launching audit-related follow-up questions, the answers become irrelevant to the question. Cause: Reasonable context refresh rules are not set, and old version code and audit data are still retained in the context, interfering with analysis of the current question.
- Phenomenon: The extracted context fragments contain a large number of redundant non-critical code comments or dependency descriptions. Cause: The
quoteMaxTokenparameter is not configured to limit the length of a single reference, resulting in invalid content occupying a large amount of token resources.
How to confirm the configuration is correct
- Launch a complete code audit task, check the generated context preview interface, and confirm that the covered code file paths and vulnerability record quantities match the scale of the current audit project.
- Launch 3 consecutive follow-up questions related to different audit stages, and check whether the answers can correctly associate previous vulnerability information and repair recommendations.
- View the token consumption log, and confirm that the token occupancy of a single round of context does not exceed the preset limit of the model, and no large number of invalid fragments are introduced.
- After adjusting the
maxContextparameter, rerun the test task, and verify whether the context overflow error disappears.
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.