What the data for this category looks like
Data for this category originates from wafer test maps, MES systems, bonding and molding equipment, ATE test machines, X-ray/SAM testing equipment, and customer specification documents. Daily documents include packaging process cards, bonding and molding parameter tables, incoming wafer maps, test program version files, yield reports, and failure analysis reports. Data updates occur per production batch, after each chip test, and daily. Fields include batch number, parameter thresholds, test bin values, failure types, and other items, with varying fields and units based on document type.
What constraints these characteristics impose on the vector models and indexes link
The strong link between incoming wafer maps and test program versions requires indexes to support precise matching by batch and parameter dimensions. High-granularity data blocks must be split for storage. Multi-source heterogeneous data covers equipment logs, drawings, reports, and other formats. The index model must adapt to vector conversion logic for different content types. The high-frequency update rhythm requires indexes to support incremental synchronization, avoiding excessive time spent on full reconstruction. Single-chip test data has fine granularity, so chunk length must be controlled to prevent semantic fragmentation. Supplier audit scenarios require associating multiple documents across batches, so indexes must support cross-document associated queries.
How to set the configurations
| Configuration Item | Suggested Value | Basis for This Setting |
|---|---|---|
| Chunk Length | 800–1200 characters | Adapts to long texts such as packaging process cards and yield reports, avoids semantic fragmentation |
| Overlap Length | 100–150 characters | Retains cross-chunk parameter association information, meets the matching requirements of incoming wafer maps and test programs |
| Similarity Threshold | 0.75–0.85 | Filters low-match batch data, reduces the risk of mixed batch or wrong program errors |
| Single Search Limit | Top 20 entries | Covers all associated data, enables precise cross-document retrieval, meets the query requirements of supplier audits |
maxToken | 4096 | Adapts to long-text vector conversion for failure analysis reports, complies with standard parameters for FastGPT v4.17.0 |
| Reranking | Enabled | Adapts to the access requirements of private reranking models, improves the precision of matching retrieval results, and supports detailed queries for test bin distributions and failure analysis |
Three common configuration mistakes
- Retrieval results include mismatched incoming wafer maps across batches, and the number of results returned by the interface exceeds the set limit. The cause is that the single search limit is not configured correctly, and the retrieval scope is not filtered by batch dimension.
- Vector conversion fails, and the log prompts that
maxTokenis exceeded. The cause is that themaxTokenparameter is not adjusted to adapt to the long-text content of failure analysis reports, resulting in failure to generate vectors for long documents. - The matching degree of failure analysis reports in retrieval results is extremely low, and entries with empty equipment parameter fields are recalled first. The cause is that a reasonable similarity threshold is not set, low-quality associated data is not filtered, and the risk of mixed batch errors is increased.
How to confirm the configuration is correct
- Import a batch of packaging process cards and the corresponding batch of incoming wafer maps, perform queries related to supplier audits, and check the batch association consistency of retrieval results.
- Upload a single failure analysis report, check whether vector conversion is successful, and confirm that the
maxTokenparameter adapts to long-text loading. - Adjust the similarity threshold and single search limit, compare the number of retrieval results and matching accuracy under different configurations, and determine the values that meet business requirements.
- View the index synchronization log, confirm that the incremental update task is triggered normally according to the daily and per-batch rhythm, and there is no abnormal time consumption from full reconstruction.
The values given are common starting points and should be measured against the reader's own samples.