What data looks like for this category
Core data for general mechanical equipment assembly comes from PLM/ERP systems, part inspection records, assembly tool collection data, test bench data, MES systems, and customer technical agreements. Data is updated per single device or individual order. A corresponding ledger is generated when assembly of one device is completed. Daily documents include assembly process cards, multi-level BOMs, torque records, gap adjustment records, commissioning reports, factory inspection sheets, and packing lists. Fields include assembly-related parameters: torque value (unit N·m), gap value (unit mm), coaxiality tolerance (unit μm). Document structure adjusts slightly based on order category.
Constraints for model access and configuration
This category’s data characteristics create multiple constraints for model access and configuration. First, multi-level BOMs and nested assembly documents require models to handle long contexts and accurately identify nested fields. This limits overload risks for single context inputs. Second, data updates occur per single device or individual order. Model response speeds must align with real-time or near-real-time ledger summary requirements. Third, document fields vary widely across different orders. Models need flexible field identification capabilities, while maintaining high extraction accuracy for assembly parameters. Parameter errors may lead to subsequent assembly issues.
How to set configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
maxTokens | 8000–12000 token | Covers complete content of multi-level BOMs and multiple assembly documents, avoids truncating critical ledger data |
temperature | 0.1–0.3 | Ensures accuracy for field extraction and ledger verification, reduces interference from irrelevant content |
AIPROXY_API_ENDPOINT | Fill in the deployed proxy address, for example http://192.168.1.100:3000/v1 | Connects to proxy services, enables forwarding and permission management for model calls |
AIPROXY_API_TOKEN | Valid token obtained from the proxy platform | Completes identity verification for proxy services, ensures legitimate call permissions |
quoteMaxToken | 2000–3000 token | Limits the length of single referenced documents, avoids context overload affecting model inference |
| Workflow/API tool selection | none | No tool calls needed, focuses on extraction and summarization of document content |
Three common configuration mistakes
- Symptom: Model calls return curl errors with status code 401 or 403. Cause: Incorrect
AIPROXY_API_TOKENconfiguration, or proxy service not restarted properly, leading to failed identity verification. - Symptom: System shows no available channels, even after proxy service restart and correct model name. Cause: Proxy service model group configuration does not cover the currently used model, or group quota is exhausted.
- Symptom: Model calls trigger automatically on the hour, without a regularly scheduled application configured. Cause: System scheduled task cache not cleared, or context trigger condition accidentally activated, leading to unintended model calls.
How to confirm correct configuration
- Call the proxy service’s test interface, input
AIPROXY_API_ENDPOINTandAIPROXY_API_TOKEN, verify return of a normal model response, confirm proxy service configuration is correct. - Upload one assembly process card and corresponding BOM document, test model accuracy when extracting fields such as torque value and gap parameters, check that extraction results match source documents.
- Import 3 to 5 assembly ledger documents from different orders, verify that
maxTokensandmaxContextconfigurations can handle batch documents completely, without truncation or errors. - Check FastGPT v4.17.0 system logs, confirm no abnormal records of hourly automatic calls, verify trigger logic is working correctly.
The values provided here are common starting points, and should be measured against the reader’s own samples.