What the documents look like
After-sales repair and reship work aims to restore a product to use, and it does not close a case through a direct refund. The everyday materials are repair applications, reship orders, inspection reports and accessory outbound orders. These come from the after-sales system, the order system, repair sites and the accessory warehouse WMS. Product data and selection questions must answer whether an accessory fits, and how a repair item differs from a reship item. Material updates are per order and daily. This page addresses one step only: model connections and configuration for product data and selection questions. It does not construct business functions that the supplied documents do not support.
A repair application records a subject, an object, a status and a validity scope. A reship order records its own object and status. Retrieval or a form does not create authorization. A pending status is not an approval, an offered option is not execution, and an unsigned termination is not a completed termination. For this task, the model connection must be able to answer selection questions from these materials without treating any status as a downstream action.
The following hypothetical drill sample is written for this page. It is not a real customer, a real company or a real identifier.
Hypothetical drill sample: a repair site submits paper material. The original text reads: "Repair application WX-0731, subject is the brand after-sales site, object is the bearing noise of model A motor, status is accepted pending inspection, validity scope is the July 2026 batch." A second document reads: "Reship order, object is the outer shell of the same model, status is pending review." A draft sentence to be checked reads: "This site can execute a reship of the outer shell for model A motor and close the case directly." The draft sentence touches the subject, the object and the status, so each item is compared against the original text.
Constraints at the model connections step
Model connection depends on AI Proxy. Both the App and Admin services must set AIPROXY_API_ENDPOINT and a non-empty AIPROXY_API_TOKEN; if either is missing, startup validation fails. AIPROXY_API_ENDPOINT holds the service root address and does not append /v1. The system needs at least one language model and one index model to work. Model capabilities are checked against the input the application needs: image input, tool choice and function call are verified separately. Application parameters are set in the application or node configuration; the same-named fields of a compatible chat interface cannot be assumed to override orchestration.
The model ID is the value of the model field in the request body and is globally unique. The model name is for display and can be customized. A model channel is a provider protocol, and one model can be configured across several channels for load balancing. A custom request address and key can bypass the channel, and the documents do not recommend this because it is harder to manage. A model mapping such as {"gpt-4o-test": "gpt-4o"} means FastGPT requests gpt-4o-test and AI Proxy sends gpt-4o upstream. The proxy address is a BaseUrl, and whether /v1 is needed must be checked.
Model status probing covers enabled system models only. Disabled models do not participate and produce no history. A probe retries up to three times after a first failure, so a single round makes at most four attempts; one success counts as valid, and only four failed attempts mark the model abnormal. Green means success with latency at or below 30s, yellow means success with latency above 30s, and red means four consecutive request errors. Webhook alerts fire on edge changes only, with event types model_status_error and model_status_recovered, and a model that stays abnormal does not repeat the alert.
Configuration and implementation checks
The table below ties each row to this page's documents. Every value in the "assumed starting point" column is a hypothetical trial starting point for this drill, not an official default. Each row states why it was chosen and what it is compared against.
| Configuration item | Assumed starting point for this drill | Reason and comparison object |
|---|---|---|
AIPROXY_API_ENDPOINT | Assumed http://aiproxy:3000 | Document example form; compare whether /v1 is appended |
AIPROXY_API_TOKEN | Assumed non-empty admin token | Compare whether it is empty and whether it matches the server side |
| Language model | Assumed one tested model enabled | Compare whether the model test result succeeds |
| Index model | Assumed one tested model enabled | Compare whether the minimum two model types are met |
| Model capability | Assumed checked for image input | Compare the vision and toolChoice fields |
| Application parameter | Assumed set inside the node | Compare whether a same-named interface field is used instead |
The repair application status "accepted pending inspection" and the reship order status "pending review" are read as they are written. Neither status is treated as inspection completion or as approval. The validity scope of the July 2026 batch stays attached to the material; it is not extended to other batches.
Three common errors
- Treating the reship order status "pending review" as an approved execution. Input: the status field of the reship order. Comparison: "pending review" against "approved". Observable result: the two values differ, so the draft sentence "execute a reship" is not supported by the original text.
- Treating the repair application status "accepted pending inspection" as completed inspection. Input: the status field of the repair application. Comparison: "pending inspection" against "inspection completed". Observable result: the stages differ, so any statement that inspection is finished is not supported.
- Writing
AIPROXY_API_ENDPOINTas a full address that contains/v1. Input: the configured value. Comparison: whether a path is appended. Observable result: the address form does not match the documented root-address requirement, and the value must be corrected and the service restarted before rechecking.
How to verify the setup
- Input the hypothetical original text "Repair application WX-0731, status is accepted pending inspection". Compare it with "close the case directly" in the draft sentence. Observable result: the original text does not state a closing authorization, so the draft sentence is not supported. The evidence gap stays open.
- Input the hypothetical reship order "status is pending review". Compare it with "execute a reship" in the draft sentence. Observable result: pending review does not constitute approval, so the action is not supported.
- Input the configured value of
AIPROXY_API_ENDPOINT. Compare whether/v1is appended. Observable result: when appended, the form does not match the documented requirement, and the value is corrected and the service restarted before a further check.
For retrieval checks, record observations and failure branches only. An empty result can be checked against the explicit paper input [] to verify the downstream design; this does not claim that a fabricated rule retrieval must return []. Libraries across different vector models cannot be associated together; check the identifier and exclude the non-matching ones, and do not run a cross-model retrieval to compare missed recall. A relevance score is not a category, entity or permission filter, and retrieval is not authorization. The documented MILVUS_LANGUAGE_IDENTIFIER setting applies when the vector store is Milvus and full-text search uses BM25; other vector stores use MongoDB $text for full-text search. Whether the optional paths in the overall flow diagram run on every request is unknown, so image retrieval needs a corresponding image input and model capability, and reranking needs a model enabled by configuration.