What the data for this category looks like
This category covers the entire production process for air conditioners, refrigerators, washing machines, and small household appliances. Daily documents include bill of materials (BOM), assembly work instructions, refrigerant charging records, electrical safety test reports, performance sampling inspection reports, and repair records. Data sources include ERP/MES systems, component batch ledgers, tightening and charging equipment logs, safety tester data, performance laboratory reports, and after-sales fault archives. Updates run per individual device, per shift output, or according to sampling inspection schedules.
What constraints these characteristics impose on multi-turn dialogue and prompt engineering
This category has scattered data sources and high update frequency. Multi-turn dialogue must link fields across multiple systems such as ERP/MES and equipment logs. It must also limit the length of historical context to adapt to real-time updated production data. Document fields are numerous and specialized, so prompts must explicitly specify extraction of specific fields such as component batches, charging parameters, and safety test results to avoid confusion between assembly data for different models. In mixed-line production scenarios, chatId must bind to the corresponding production batch. This ensures dialogue context only links to production and quality inspection data for the current batch, preventing cross-batch information from interfering with analysis.
How to set configurations
| Configuration Item | Recommended Approach | Rationale |
|---|---|---|
chatId | Bind to production batch ID | Ensure dialogue context only links to BOM, quality inspection, and repair data for the current batch, avoiding information interference from mixed-line production |
messages | Retain the most recent 20 dialogue messages | Adapt to the update rhythm of production data per single device per shift, preventing analysis delays caused by excessive historical messages |
variables | Map to component batch, charging parameter, and safety test result fields | Extract corresponding business fields from ERP/MES and equipment logs to support precise queries for defect analysis |
| Maximum context character count | 8000–12000 characters | Cover full-process document data for a single complete household appliance, avoiding truncation of critical information |
| Historical message cleanup frequency | Automatically clean after each shift ends | Match the update rhythm of production shifts, reducing resource usage from invalid context |
| Streaming output trigger threshold | Calibrate based on actual testing | Adapt to delay conditions in multi-device data synchronization, avoiding output interruptions or lag |
Three common misconfigurations
- Phenomenon: In FastGPT v4.17.0, when only a dozen characters are entered as a query, the system returns all results at once before starting streaming output. Cause: The historical message truncation rule for
messagesis not configured correctly, causing abnormal context loading logic and triggering the legacy one-time output mode. - Phenomenon: The AI dialogue node in a workflow cannot obtain the output content of the code running node. Cause: The output results of the code run are not mapped to the
variablesparameter, so the dialogue node cannot read the corresponding variable values. - Phenomenon: After attempting to save workflow parameters passed from the system side to global variables, the variables are not recognized. Cause: The mapping range of
variablesis not specified in the dialogue configuration, so system-side parameters are not included in the callable variable pool.
How to confirm configurations are correct
- Initiate a query containing production batch keywords, and check whether the returned results only link to BOM, quality inspection, and repair data for the current batch.
- Enter multi-round progressive questions, and confirm that the dialogue context retains key information from previous questions and answers, with no context loss.
- Trigger the code running node, then call the corresponding variable in the AI dialogue node, and confirm that the variable value can be read normally.
- Observe the output mode, and confirm that streaming output starts even for short queries, with no abnormal one-time return behavior.
The values listed above are common starting points. They should be evaluated against specific samples tailored to the intended use case.