What Data for This Category Looks Like
Normally, this data comes from silicon wafer incoming material records, workshop MES systems, operation logs of diffusion furnaces, coating equipment, and printing presses, EL detection images, IV performance test reports, and laboratory quality inspection archives. Updates are generated based on production batches, single-chip detection results, and daily summaries. Common documents include process cards, diffusion and coating parameter ledgers, printing and sintering process records, EL detection images, IV performance grading data, and batch yield reports. Common data fields include single-chip ID, process parameter values, defect types, electrical performance indicators, and grading results.
Constraints Imposed by These Characteristics on Workflow Orchestration
Because data is updated at the single-chip, batch, and daily level, workflows must support triggering execution at the chip or batch level to avoid redundant global calculations. Multi-source heterogeneous data includes device logs, images, and numerical indicators, so workflows must adapt to input and output formats for different node types. For example, image nodes must preprocess EL detection images, and numerical nodes must associate with MES parameters. The high update frequency of single-chip data requires workflow variables to bind single-chip IDs as local identifiers to prevent global variable conflicts. Defect traceability requires linking multi-process data, so workflows must support context transfer and associated queries between nodes to enable cross-verification of detection data from different links.
Configuration Settings
The following configurations are based on FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
variables scope configuration | Enable local scope, bind single-chip ID by nodeId | Need to distinguish parameters for different single chips or batches to avoid global variable conflicts, and adapt to the high update frequency of single-chip data |
| Knowledge base retrieval trigger timing | Execute only after the process parameter collection node completes | Need to obtain process benchmark data for the current batch before associating with the defect library for traceability analysis |
| Intermediate node output shielding | Enable the node output shielding switch | Intermediate reasoning steps do not need to be displayed to end users, only core analysis results should be retained |
| Maximum number of retrieval results | Top 5 | Photovoltaic cell defect types are relatively concentrated, and a small number of highly relevant results can support defect analysis |
| Context cache duration | 600 seconds | Single batch production cycle usually ranges from several minutes to tens of minutes, this cache duration covers the complete traceability process |
| Single retrieval context length | 800–1200 characters | Process parameters and defect descriptions for photovoltaic cells usually fall within this range, covering the information required for core analysis |
Three Common Misconfigurations
- Issue: Variables with the same name configured in the workflow have value conflicts across different single chips or users, and the call parameters for knowledge base retrieval nodes are empty. Cause: The local scope of
variablesis not enabled, and global variables are used for binding directly. - Issue: Reasoning content from intermediate AI conversation nodes is displayed in the final delivered analysis report. Cause: The output shielding switch for the corresponding node is not enabled, or the configuration is not associated with the specified
nodeId. - Issue: When testing a workflow based on problem classification, only the first problem triggers knowledge base retrieval, and no retrieval results are returned for subsequent problems. Cause: The retrieval context is not dynamically updated based on the output of the classification node, and the current batch ID parameter in
variablesis not bound.
How to Verify Proper Configuration
- Submit single-chip test data, check if the
nodeIdbound byvariablesin the variable panel matches the current single-chip ID, to confirm variable isolation is active. - Run the workflow, verify that the output of intermediate AI nodes is shielded, with only core analysis results retained.
- Submit quality problems of different classifications sequentially, confirm that each classification triggers knowledge base retrieval and returns matching results.
- View the configuration logs of the retrieval node, confirm that parameters such as datasetid have no call failure alerts, and the associated
variablesfield correctly matches the current batch.
The values listed above are common starting points, and should be validated against applicable samples.