What this category of data looks like
Semiconductor wafer fabrication data typically comes from MES systems, equipment FDC monitoring modules, defect detection and metrology equipment, process recipe libraries, and other sources. Daily documents include process flow cards, batch operation records, SPC control charts, defect maps, yield reports, and more. Fields cover wafer batch numbers, etching depth, equipment runtime, defect coordinates, and other related information. Data update frequencies include per-wafer batch reporting, real-time equipment parameter uploads, and daily yield summaries. Single-batch data volume increases as the number of process steps grows.
What constraints these characteristics impose on the "tool calling and plugins" link
The multi-step process chain and nanoscale parameter coupling properties of wafer fabrication require tool calling to accurately match historical data at the batch dimension. Real-time updated equipment parameters require tool calling to support low-latency responses, to avoid exceeding limited rework windows. Cross-module yield attribution requires calling multiple associated plugins to integrate data from different sources, while strict parameter format verification is needed to prevent the risk of wafer batch scrapping. A large volume of process documents and defect maps also requires tool calling to support batch retrieval of context content.
How to set the configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| Tool calling mode | functionCall mode | Adapts to structured parameter calling requirements for wafer fabrication, avoids unintended natural language calls |
| Tool calling strategy | toolChoice: auto | Supports automatic matching of batch parameters, meets flexible calling needs for multi-step traceability |
| Single tool call timeout | 120 seconds | Matches the average time range for wafer batch data retrieval and defect map analysis |
| User input confirmation | Enable confirmation after parameter extraction | Meets risk control requirements before tool execution, avoids accidental triggering of batch rework |
| Maximum context length | 800–1200 characters | Adapts to the typical length of single-batch process documents, avoids exceeding context thresholds |
| Tool call result caching | Retain for 24 hours | Adapts to the daily updated yield report data cycle, reduces repeated retrieval overhead |
Three common misconfigurations
- Automatically displaying intermediate response content after tool calling, with no option to hide tool execution results separately. This happens because output filtering rules for
functionCallare not configured, and full-link conversation content is retained by default. - Directly executing plugins without triggering user confirmation after extracting parameters such as wafer batch numbers via tool calling. This happens because the user confirmation configuration after parameter extraction is not enabled, and only relies on AI to complete parameter verification automatically.
- Using one API as the default transit when calling embedding models, with no way to directly bind self-developed vector models for wafer fabrication scenarios. This happens because one API proxy is not disabled in model management, and endpoint information for direct calling is not configured.
How to confirm the configuration is correct
- In the FastGPT v4.17.0 environment, submit a simulated wafer batch number to trigger tool calling, and check whether a parameter confirmation pop-up appears.
- View the tool calling logs, confirm that one API transit is not used, and the target vector model or business plugin is called directly.
- Test the tool call timeout scenario, and check whether a reasonable timeout prompt is triggered within 120 seconds.
- Execute a multi-step traceability workflow, confirm that multiple associated plugins can be called in sequence, and only the final yield attribution result is displayed.
The values listed above are common starting points and should be evaluated against the reader's own samples.