What the documents look like
Regional dealer stock replenishment runs as a daily rolling order flow rather than a seasonal buying meeting. The working documents are replenishment requests, inventory turnover sheets, outbound notes and payment plans, and they are refreshed weekly or monthly. Product data and selection questions draw on these documents for checkable facts such as available stock for a model, quantity in transit, and collection status. The model connection and configuration step does not edit business records. It determines whether questions can reliably reach the source text and return traceable answers.
Two features of this category shape the task. First, replenishment questions name a specific model, a quantity and a date, so the index model must handle tabular text and the language model must quote the source rather than restate numbers. Second, the system requires at least one language model and one index model before it can run normally. The model ID is the value of the model field in the request body and is globally unique; the model name is for display only. The proxy address entered for a channel is a BaseUrl, not a full request address. Model mapping sends a FastGPT model to a different upstream model, for example gpt-4o-test mapped to gpt-4o.
Constraints at the model connections step
Assume a paper exercise sample, not a real record. On 10 March 2026 a dealer's sales support staff reviews a replenishment request. The source text reads: "As of 9 March, model A stock is 120 units, 80 units in transit, 60 units shipped out last week; model B stock is 15 units, a replenishment request has been submitted but the brand has not confirmed a shipping date." A draft sentence under review reads: "Model B replenishment has been confirmed by the brand, expected to arrive on 15 March." The comparison uses the source text and the draft sentence. The source states only that a request was submitted and no shipping date is confirmed. The draft claims confirmation and a delivery date. The two differ on the confirmation field and the arrival date field, and the draft is not supported by the source.
This sample fixes the boundary for the page. A submitted request is not a confirmed shipment. A draft sentence that adds a status is unsupported even when the surrounding numbers are correct. The model connection step can retrieve the source paragraph and quote it, but it does not convert a pending request into a confirmed one, and retrieval is not authorization for any user to act on the record.
Configuration and implementation checks
The settings below relate to this sample. Values are hypothetical starting points for a paper comparison and are not official defaults.
| Setting | Hypothetical starting point | Reason and comparison method |
|---|---|---|
| Language model and index model | One of each enabled | The documents require at least one of each; compare question answers before and after enabling |
| Model mapping | gpt-4o-test mapped to gpt-4o | Compare the request model with the upstream model in the channel |
| Channel test | Run model test on the configured channel | Observe each model's test result and request duration |
| Model probe interval | 30 minutes | The documents allow integers from 5 to 60 minutes; compare probe records with alert events |
| Alert webhook | One receiving address | Receives model_status_error and model_status_recovered events |
| Model call log retention | Set through the environment variable | The documents state error requests keep inputs and error details, with configurable retention |
The model probe applies only to enabled system models. A probe retries up to three times after a first failure, so one round makes at most four attempts; one success counts as valid, and only four failures mark the model abnormal. A successful response at or under 30s is normal, above 30s is high latency, and four consecutive errors are abnormal. Alerts fire on edge changes only, so a model that stays abnormal does not repeat the alert.
Three common errors
- Treating a pending replenishment request as a confirmed shipment. Input: the source text and the draft sentence above. Comparison: the confirmation field and the arrival date field. Observable result: the draft asserts confirmation and 15 March arrival, while the source states the request was submitted and no shipping date is confirmed. The draft is unsupported.
- Reading model mapping as a change to business data. Input: the mapping configuration. Comparison: the model identifier recorded in the request log against the mapping target. Observable result: the upstream request carries the mapped model, while the replenishment request, stock and collection status remain unchanged. Mapping affects the request only.
- Treating a retrieval hit as authorization. Input: the returned document fragment. Comparison: the fragment against the user's permitted scope. Observable result: retrieval and permission decisions are recorded separately, and where authorization information is absent the item stays pending verification. A similarity result is not a permission filter.
How to verify the setup
- Run a question against the sample source and draft. Input: the three source clauses and the draft sentence. Compare whether the answer identifies that "no shipping date is confirmed" conflicts with the draft's confirmation and 15 March arrival. The condition is met when the output quotes the source and marks the draft as unsupported. If the answer does not cite the source, record the gap rather than treating it as a pass.
- Check the model probe records. Input: the list of enabled models. Compare the probe status with the alert event type. The condition is met when an abnormal transition produces
model_status_errorand a recovery producesmodel_status_recovered, withprobe.attemptsbetween 1 and 4. Where no probe record exists, the result remains unknown. - Inspect the model call log. Input: one question request. Compare the model identifier in the log with the mapping configuration. The condition is met when the logged request model matches the configured mapping. If the log is missing or the field is not stated, record it as pending verification and do not infer success or failure.
Across all three checks, a missing field stays missing. A pending request is not an approval, an offered option is not an execution, and an unsigned termination is not a completed termination.