What this category of data looks like
The ledger data for new energy development comes from project approval documents, on-site construction logs, grid connection acceptance reports, monthly operation and maintenance records, quarterly safety inspection archives, and similar sources. Update frequency adjusts based on project phase: daily progress updates during the project approval phase, weekly operation data updates during the operation and maintenance phase, and monthly ledger summary updates after grid connection. Most documents are structured tables with fixed fields. These fields include project ID, project name, construction location, installed capacity (unit: MW), grid connection time, operation and maintenance count, fault type, and more. Single document length typically ranges from 500 to 2000 characters.
What constraints do these characteristics impose on knowledge base retrieval and recall?
New energy development ledger data uses structured fields with clear units such as MW. Retrieval must precisely match field names and units. Fuzzy matching may lead to incorrect associations. Data update frequency changes with project phase. Knowledge base synchronization cycles must align with business update rhythms. Misalignment causes data lag or redundancy. Single document length is moderate, but batch data volume is large. Retrieval must control the number of returned entries to avoid context overflow. Additionally, ledger fields vary across categories such as wind power and photovoltaic. Knowledge base collections must be divided by category to ensure accurate targeted retrieval.
How to configure the settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
similarity | 0.75–0.85 | Matches the structured field precision of new energy ledgers, prevents low-similarity irrelevant project data from being included |
limit | Top 10 entries | New energy project ledger batch data volume is moderate. Excessive entries increase context processing load |
searchMode | Precise matching | Adapts to the structured ledger field retrieval needs, avoids incorrect associations caused by fuzzy matching |
usingReRank | Enabled | Performs secondary sorting on recalled long document ledger results by relevance, improves retrieval accuracy |
datasetSearchUsingExtensionQuery | Disabled | New energy ledger fields are fixed, no additional query extension is needed, prevents introducing irrelevant content |
collectionIds | Knowledge base collection IDs classified by wind power and photovoltaic | Divides collections by project type, enables targeted retrieval of ledger data for corresponding categories |
Three common mistakes
- Symptom: The ledger summary report generated via the API does not reference project data from the knowledge base, and only returns generic responses. Cause: The
collectionIdsparameter is not specified correctly, or thesimilaritythreshold is set too low, resulting in recalled knowledge base entries failing to match target ledger data. - Symptom: The number of results returned by a single retrieval is far higher than expected. Context overflow causes the conversation page to crash. Cause: No reasonable
limitparameter is set. Recalling too many long documents causes token limit exhaustion. - Symptom: Retrieval results include ledger data from non-new energy projects, such as construction engineering ledgers. Cause: The
searchModeis not configured for precise matching, or no exclusive knowledge base collection is bound, resulting in cross-category data being included.
How to confirm the configuration is correct
- Run a test query. Enter a specific new energy project ID, check if the returned results include exclusive field data such as the project’s installed capacity and grid connection time.
- View retrieval logs. Confirm that recalled entries come from the knowledge base collection corresponding to the specified
collectionIds, with no cross-category data included. - Adjust the
similarityparameter. Observe changes in returned result relevance, verify that the threshold setting meets business requirements. - Test retrieval of long document ledgers. Confirm that results sorting meets expectations after
usingReRankis enabled, with irrelevant entries moved to the end.
Reference only; verify against the target FastGPT release and deployment documentation. 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-09-28.