What This Category of Data Looks Like
Daily data from foundries, die casting workshops, and equipment component suppliers’ casting process and quality departments. This includes documents such as casting process cards, batching lists, heat records, mold histories, first-piece inspection records, material test reports, and nonconforming product review forms.
Data sources cover ERP material master data, melting furnaces and thermometers, spectrometers, MES heat records, mold management systems, customer drawings and technical requirements. Update frequency is per heat, per batch, or daily. Core fields include heat number, mold count, alloy batching ratio, melting temperature, pouring parameters, and defect type, among others.
Constraints on Vector Models and Indexing
Data in this category has high update frequency and is split by heat and batch. Vector models and indexing must support incremental updates and filtering by business dimensions. The data includes both numeric parameters and textual descriptions, so mixed-semantic embedding matching must be supported.
The content length of individual documents is strongly tied to business relevance. Chunking and indexing must avoid splitting cross-heat associated data, while adapting to unified embedding formats for multi-source data. This ensures that full-chain information such as batching, processes, and defects can be associated during retrieval.
How to Set Configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
| Chunk Length | 800–1200 characters | Matches the average length of single-heat process cards and heat records, avoids splitting cross-heat associated data |
| Overlap Length | 50–80 characters | Retains context for key identifiers such as heat number and mold count, prevents loss of business association information during cross-chunk retrieval |
| Similarity Threshold | 0.75–0.85 | Adapts to the semantic matching accuracy of casting defect descriptions and process parameters, filters low-correlation historical records |
maxToken | Set to the selected embedding model/service maximum supported input tokens | maxToken is the input-token maximum supported by the selected embedding model/service; verify it in that provider configuration. See the v4.17.2 model-field reference. It is not retrieval/LLM context or a FastGPT-wide fixed cap. |
| Single Search Limit | Top 10 entries | Limits the number of returned historical heats or batches to avoid context overload that impacts retrieval efficiency |
defaultToken | Calibrated via actual testing | Adapts to the input length limit of external vector models, compatible with hardware resources of different deployment environments |
Three Common Configuration Mistakes
- Phenomenon: The vector model cannot be invoked after configuration, and the interface returns a connection error. Cause: The call address and key of the external vector model are not correctly configured in oneapi, or the port permissions of the model service are not opened.
- Phenomenon: Exported knowledge base data cannot be restored individually by heat or mold count. Cause: Only a global knowledge base-level backup strategy is used, and rules for splitting indexes by business classification are not configured.
- Phenomenon: Retrieval response is slow after deployment on an ARM soft router. Cause: The
maxTokenparameter is not adjusted lower, or a vector model with high computing power requirements is selected, exceeding the hardware carrying capacity of the soft router.
How to Confirm Configuration Completion
This page is written based on the configuration logic of FastGPT v4.17.0. Verify the configuration effect with the following actions:
- Uploading a single heat record document and reviewing returned results after retrieval confirms if associated data such as batching and temperature from the same heat is included.
- Exporting knowledge base data and reviewing the exported data confirms if the corresponding subset can be filtered and restored by heat number and mold number.
- Calling the vector model interface and verifying the returned embedding vector length confirms compliance with the configuration requirements of
defaultToken. - Running a lightweight vector model in an ARM soft router environment and checking retrieval response confirms there is no obvious lag.
The values given are common starting points and should be measured against the reader's own samples.