What the data for this category looks like
Data for this category comes from cell capacity grading data, MES systems, welding equipment, torque tools, BMS software version records, and EOL test benches. Daily documents include grouping rules, BOM lists, welding and torque records, BMS flashing records, insulation and voltage withstand reports, EOL test results, and system configuration lists. Data is updated once per battery pack or energy storage cabinet, and synchronized whenever the BMS software version changes. Document fields include cell capacity grading parameters, torque values, test voltage, BMS version number, and other items. Minor format differences exist across different vendors.
What constraints these characteristics impose on the "multi-turn dialogue and prompt engineering" link
Data sources for this category are scattered and formats are inconsistent. The multi-turn dialogue process must retrieve records from different devices and systems step by step to avoid overloading a single request. Frequently updated single-pack or single-cabinet data requires that the conversation context only loads associated documents from the current batch, to prevent historical data from interfering with current audits. Document fields vary across vendors, so prompts must clearly specify field rules matching the current batch to avoid confusion between cross-category or cross-vendor fields. Inspection and audit require checking multi-dimensional associated data; multi-turn dialogue must trigger parameter checking, record verification, and result summary steps in sequence according to the process to ensure logical coherence.
How to set up the configuration
This configuration is based on FastGPT v4.17.0.
| Configuration Item | Recommended Approach | Rationale |
|---|---|---|
chatId | Bind to the current batch’s cell SN code + production timestamp | Ensure that the conversation context for the same batch’s inspection is not confused with other batches, meeting the verification requirements for session identifiers |
messages | Limit context to the first 10 conversation histories of the current batch | The number of associated items for a single batch of data is limited; an overly long context will cause prompt confusion, adapting to the short-process nature of inspection audits |
variables | Predefine the current batch’s BOM number, cell SN code, and test voltage threshold | Quickly call batch-specific data, avoid repeated input of fields, and improve audit efficiency |
| Maximum context length | 800–1200 characters | Adapt to the total character count of single-batch documents, preventing context overflow from causing prompt failure |
| Question optimization | Calibrate based on actual testing | Significant format differences exist across vendor documents, requiring adjustment of question decomposition logic according to actual scenarios |
| Conversation log persistence | Enabled | Match the log retention requirements for login-free scenarios, preventing background records from being cleared by user-side deletion operations |
Three common mistakes
- Phenomenon: The
chatIdparameter is passed when calling the API, but the corresponding identifier is not displayed in the background conversation log. Cause: ThechatIdis not bound to the current batch’s unique identifier, so the system cannot identify the session ownership. - Phenomenon: After a login-free link user deletes a conversation, the background log is also cleared synchronously. Cause: Conversation log persistence configuration is not enabled, causing user-side deletion operations to trigger background log deletion synchronously.
- Phenomenon: Workflow nodes cannot load global variables from historical conversations. Cause: No association rule between historical sessions and the current batch is configured in the workflow, so corresponding batch global variable data cannot be called.
How to confirm the configuration is correct
- Initiate a test request, pass the
chatIdparameter, and check whether the corresponding identifier is displayed in the background log. - Enter a test question, and check whether the conversation context only loads current batch document data with no irrelevant historical content.
- Check whether the pre-defined
variablesparameter includes current batch-specific fields, and verify whether field calls work normally via conversation replies. - Simulate a login-free user deleting a conversation, and check whether the corresponding record is retained in the background log to verify that the persistence configuration is effective.
Note: The configuration values listed above are common starting points and should be evaluated against your own specific samples.