Data characteristics for this category
This category’s data covers configuration BOMs, assembly work instructions, refrigerant charging records, electrical safety test reports, performance spot check records, and repair archives related to production of complete products including air conditioners, refrigerators, and small household appliances. Data sources include ERP/MES systems, component batch ledgers, tightening and charging equipment logs, safety compliance testers, performance laboratory data, and after-sales fault feedback. Data updates run per single product, per shift production batch, or per spot check plan. Fields include component batch numbers, process parameters, test results, repair reasons, and more. Data is dynamically generated across production links.
Constraints on model access and configuration
Multi-source heterogeneous data from different devices and systems has significant format differences. Parsing rules adapted to multiple document types must be configured to prevent the model from failing to read key traceability information due to inconsistent formats. Single-product high-frequency update data requires the model’s context length to match the production data volume of a single batch, to prevent loss of key fields from context overflow. Consumer-facing product requirements mean the model must handle anomalies across safety compliance, appearance, and functional dimensions. Configuration must support prompt templates aligned with multiple tasks. Associating repair records with after-sales data requires the model to support cross-document association. Context parameters must be set reasonably to limit redundant information loading, avoiding reduced analysis efficiency.
Setting configurations
This configuration guide is written for FastGPT v4.17.0.
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
AIPROXY_API_ENDPOINT | Match the API access address of the deployed model, for example http://localhost:11434/api | Adapt to access paths for locally deployed models such as ollama, ensuring requests reach the target model service correctly |
AIPROXY_API_TOKEN | Leave blank for locally deployed models; fill in the token generated by the corresponding platform for cloud deployments | Match the authentication requirements of the model service, preventing requests from being blocked due to authentication failures |
maxContext | 8000–12000 token | Match the multi-stage production data volume of a single complete appliance, avoiding context overflow and loss of key traceability fields |
maxTokens | 2000–3000 token | Control the output length of a single analysis round, ensuring defect analysis results are concise and traceable |
temperature | 0.1–0.3 | Improve the certainty of defect analysis, avoiding deviations in traceability results caused by randomness |
| Workflow/API tool selection | auto | Enable the model to automatically select tools for processing multi-dimensional quality data, supporting multi-stage associated analysis needs |
Three common configuration mistakes
- Entering an incorrect path when configuring
AIPROXY_API_ENDPOINT, resulting in a 404 status code returned by the interface. This occurs when the actual API access address of the locally deployed model is not matched, such as failing to correctly fill in the port or path suffix for the ollama default address. - Failing to enable streaming output when calling an external model in a workflow, with only full content returned as the result. This happens when the streaming output switch is not enabled in the model configuration, or the code running module does not correctly adapt to streaming data receiving logic.
- Persistent errors when configuring the vector model, making successful recall impossible. This stems from not clarifying the model’s input and output format requirements, or failing to adjust the vector database chunking rules based on the category’s data characteristics, leading to failed data embedding.
How to verify successful configuration
- Initiate a test call targeting the repair record of a single complete appliance. Check if the interface returns a 200 status code to confirm authentication and address configuration are correct.
- Import a single batch of production test data. Check if the model’s loaded context content includes key fields to confirm the context parameters match the data volume.
- Submit a joint analysis request for safety compliance and functional anomalies. Check if the output result covers multi-dimensional anomaly associations to confirm the multi-parameter configuration meets requirements.
- Start a streaming output test. Check if the workflow receives model return content segment by segment to confirm the streaming configuration is active.
The values provided are common starting points and should be measured against the reader's own samples.