What this category of data looks like
Data for this category primarily comes from code repositories, dependency lists, Static Application Security Testing (SAST) tools, and public vulnerability databases. Daily produced documents include code audit reports, vulnerability proof materials, remediation recommendation documents, and retest records. Data update triggers follow project version iterations or the completion of single audit tasks. Document structures vary across different projects, with core fields including vulnerability ID, risk level, associated code snippets, remediation solutions, and retest results. There are no unified fixed unit requirements.
What constraints do these characteristics impose on the reranking and hybrid retrieval link
Multi-source heterogeneous data sources lead to significant differences in retrieval content formats and fields. Hybrid retrieval must simultaneously support code snippets, tool output reports, and vulnerability database entries. Document structures are customized per project with no unified field specifications, so the reranking link needs to adapt to information weight allocation across different documents. Data updates with project versions or single audit tasks, so the retrieval system must support on-demand refresh of associated data. Core business time-consuming processes focus on dangerous function localization and attack path tracing. Reranking must prioritize retrieval results related to high-severity vulnerabilities to improve retrieval efficiency for core processes.
How to set the configuration
This configuration guide applies to FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| Retrieval data source scope | Only associate the current project’s code repository, audit reports, and associated vulnerability databases | Avoid cross-project irrelevant data interfering with retrieval results |
| Rerank model call timeout | 30–60 seconds | Adapt to the loading and analysis duration of code audit documents |
| Single recall result limit | Top 20 entries | Balance retrieval comprehensiveness and reranking calculation overhead |
| Rerank result retention count | Top 5–8 entries | Focus on core high-severity vulnerability and remediation recommendation content |
| Document chunk length | 800–1200 characters | Adapt to the information density of code snippets and audit reports |
| Retrieval result weight adjustment | Weight by vulnerability risk level | Align with core business requirements, prioritize displaying high-severity content |
Three common mistakes
- Rerank model call returns
Invalid URL (POST /v1/rerank)error, and the interface shows connection failed. The cause is that the rerank model’s API address is configured incorrectly, or the deployed rerank service did not properly expose the /v1/rerank interface. - After deploying and connecting using the
bge-rerank-baseimage, testing returns a401 unauthorizedstatus code. The cause is that the rerank model’s access key is configured incorrectly, or the deployed service did not enable valid access permission checks. - Retrieval results do not prioritize displaying content related to high-severity vulnerabilities. The cause is that the rule for adjusting retrieval result weights by vulnerability risk level is not configured, or the weight allocation logic does not associate with the risk level field in the document.
How to confirm the configuration is complete
- Check the rerank model’s connection logs to confirm there are no error messages related to API addresses or keys.
- Import a test code audit report and vulnerability database entry, execute a retrieval, and verify whether the number of recalled results matches the configured retention limit.
- Manually adjust the rerank result retention count configuration, and verify whether the number of results displayed on the interface changes synchronously.
- Simulate retrieval scenarios for high-severity and low-severity vulnerabilities, and verify whether the reranked results prioritize displaying content related to high-severity issues.
The values given 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.