What the data for this category looks like
Data comes from daily production documents and production equipment collection data from stamping workshops of automobile panel, household appliance sheet metal, and hardware enterprises. It covers fixed-format documents including stamping operation instructions, material utilization rate tables, mold inspection logs, first/last piece records, dimensional inspection reports, and mold change records. It also includes steel coil labels and quality certificates, real-time data from stamping presses and feeders, mold management systems, MES systems, and coordinate measuring machine or fixture inspection data. Data updates are synchronized with each coil of material, each batch of materials, or each mold change. Documents include standardized fields such as mold number, material grade, material thickness, processing beat, and dimensional deviation value of inspection. No additional custom non-standard fields are included.
What constraints do these characteristics impose on the vector model and index link
This category’s data is multi-source, scattered, and updated frequently. This imposes three core constraints on the vector model and index link. First, heterogeneous data collected from multiple systems must use a unified embedding format. This avoids vector consistency issues caused by field differences across sources. Second, the high-frequency updates per coil of material, batch of materials, or mold change require indexes to support incremental updates. This avoids excessive time spent on full reconstruction and ensures data timeliness before bidding. Third, documents with multiple types such as tables and records need splitting rules tailored to different structures. This prevents key processing parameters from being split and lost. Additionally, bid quotations need to associate mold, material, and inspection data. Indexes must retain field association relationships to ensure the business relevance of recalled content. Adjust the embedding and context length limits using defaultToken and maxToken.
How to set configurations
The following configurations are adapted for FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| Chunk Length | 800–1200 characters | Adapts to the single-chunk content length of stamping operation instructions and material utilization rate tables, avoids splitting key parameters across chunks |
| Overlap Length | 50–100 characters | Ensures contextual coherence for mold change records and dimensional inspection reports, prevents key process descriptions from being truncated |
| Similarity Threshold | 0.75–0.85 | Matches the semantic similarity of stamping processing parameters, filters irrelevant mold inspection logs, improves recall accuracy |
| Single Search Limit | Top 10 entries | Covers the multi-dimensional data required for bidding, avoids excessive redundant content interfering with quotation calculation |
defaultToken | Set from representative sample documents | defaultToken is the default token count for direct text chunking; tune it on representative source documents. See the v4.17.2 model-field reference. It is not a vector dimension, embedding-model input cap, or retrieval/LLM context. |
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. |
Three Common Misconfigurations
- A 401 status code is returned when connecting a custom vector model. This occurs because the API key and request address for the vector model are not configured correctly, or expired key information is used.
- After custom document splitting, the knowledge base automatically deletes duplicate document chunks, causing index order confusion. This happens because the document deduplication switch is enabled by default, and the configuration is not turned off for batch duplicate content in stamping production records.
- After configuring the vector model, search requests are incorrectly routed to the large language model interface. This occurs because the channel is not explicitly designated as a vector embedding-only channel in the channel configuration, and the default large language model routing rule is not disabled.
How to Confirm Proper Configuration
- Upload a typical stamping operation instruction, check the chunked results after vector embedding, confirm that key parameters are not split across chunks.
- Simulate a search request related to bid quotation, verify the document type and field matching degree of the returned results, adjust the similarity threshold to a range that meets business requirements.
- Submit an incremental data update task, check the index update time and incremental synchronization effect, confirm that no full reconstruction process is triggered.
- View the vector model call logs, confirm that the request address and key configuration are correct, no abnormal records of routing to the large language model.
The values provided above are common starting points and should be evaluated against samples relevant to the specific use case.