What the data for this category looks like
Daily documents for sheet metal cutting and bending include unfolded drawings, CNC cutting programs, bending process cards, nesting diagrams, first-piece records and process flow cards. Data sources cover CAD/CAM exported files, order BOMs, sheet material inventory ledgers, laser cutter and bending machine operation data, and MES system records. Data updates trigger with order creation, daily inventory changes, or production changeovers. For multi-variety, small-batch business models, parameter differences across single-order documents are significant. Core fields include bending compensation coefficient, sheet thickness, cutting size, leftover material specification, and others.
What constraints these characteristics impose on knowledge base retrieval and recall
Data for this category comes from scattered sources and updates frequently. This requires knowledge base retrieval to adapt to real-time updated order documents and equipment data. The multi-variety, small-batch business trait leads to retrieval needs that highly match specific parameters. General keyword retrieval cannot meet this requirement. Core fields such as bending compensation coefficient and nesting leftover material specification directly affect production compliance. Retrieval must accurately match field-level information to avoid mixing irrelevant documents. Production errors have serious consequences, so recalled results must be accurate and complete, and key process parameters must not be missed.
How to set the configuration
This configuration is based on FastGPT v4.17.0, and adapts to the knowledge base retrieval and recall needs of sheet metal cutting and bending scenarios.
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
similarity | 0.75–0.85 | Matches precise parameters of sheet metal drawings, filters low-relevance general mechanical documents, and avoids excessive token consumption |
limit | Top 8 entries | Adapts to order-specific documents for multi-variety, small-batch scenarios, prevents token overflow caused by recalling too many irrelevant data points |
searchMode | fullTextRecall | The query examples emphasize identifiers or specialist terms; test this mode with representative data, not as a product default. |
usingReRank | Enabled | Performs secondary ranking on initial recall results, corrects deviations from single vector recall, and strengthens matching of core fields such as bending compensation and nesting rules |
datasetSearchUsingExtensionQuery | Enabled | Automatically expands relevant terms for cutting programs and process cards, for example, expanding "bending compensation" to "springback compensation" and "unfolding coefficient" to cover more professional expressions |
collectionIds | Exclusive dataset ID for sheet metal cutting and bending | Limits retrieval scope to documents of this category only, avoiding interference from cross-category data |
Three common misconfigurations
- Phenomenon: Retrieval returns results with unexpected token consumption, even short questions and answers use over 3000 tokens. Cause: The
similaritythreshold is not set, too many irrelevant documents are recalled, and thelimitparameter is not restricted. - Phenomenon: After triggering knowledge base retrieval, the nesting diagram or bending process card data for the corresponding order is not returned. Cause:
datasetSearchUsingExtensionQueryis not enabled, cannot match extended expressions of professional terms, leading to core documents not being recalled. - Phenomenon: The model does not call the knowledge base for cross-review by default, or cannot trigger retrieval normally in the existing retrieval template. Cause: The trigger condition for the knowledge base retrieval node is not configured in the workflow, or the retrieval node is not set as a mandatory process step.
How to confirm the configuration is complete
- Upload a test bending process card, enter a query that includes bending compensation coefficient and sheet thickness, run retrieval, confirm that the returned results include matching specific documents.
- Adjust the
similarityparameter to 0.7 and 0.85, compare the relevance of the results returned twice, confirm that the threshold setting meets business requirements. - After enabling
usingReRank, compare the initial recall results with the sorted results after reranking, confirm that the reranking function is active. - Check the token consumption statistics during retrieval, confirm that no unexpected overconsumption occurs.
The values given are common starting points and should be measured against the reader's own samples.