Multi-store management: model connections for multilingual work

What the documents look like

Multi-store matrix operations draw cross-border material from platform merchant backends, ERP channel pricing, brand anti-counterfeit systems and distributor reports. The working documents are store authorization lists, price control sheets, cross-territory complaint forms and monthly sales reports. These materials update daily or monthly, and their languages and formats differ across platforms. The cross-border material and multilingual retrieval task turns authorization, pricing and complaint information into retrievable corpus, and model connection and configuration determine whether that corpus is indexed and recalled correctly. Retrieval does not itself constitute authorization, and field values collected by forms require downstream business verification before they take effect.

A store authorization list carries a subject, an object, an authorized matter, an effective range and an authorization status. A price control sheet carries channel prices that must stay aligned across stores. A cross-territory complaint form records a suspected unauthorized store. A monthly sales report carries volume figures by store and period. Retrieval over these materials returns text; it does not confirm that an authorization is valid, that a price is approved, or that a complaint is resolved.

Constraints at the model connections step

AI Proxy is a required dependency. 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 takes the service root address without appending /v1. A model ID is the value of the model field in the request body and is globally unique; the model name is a display label and can be customized. One model can be configured across different channels to achieve load balancing, and channel priority ranges from 1 to 100, where a larger value is more likely to be selected. The system needs at least one language model and one index model. Only one speech recognition model takes effect. Index model fields include defaultToken and maxToken. Language model fields include maxContext, maxResponse, quoteMaxToken, maxTemperature, vision, toolChoice and functionCall. Model status probing covers only currently enabled system models. After a first failure the probe retries at most 3 times, so a single round makes at most 4 attempts; only when all 4 attempts fail is the model judged abnormal. Normal means a successful test with latency at or below 30s, high latency means a successful test above 30s, and abnormal means 4 consecutive request errors. The alert Webhook fires on edge changes of status, one notification per model, with event types model_status_error and model_status_recovered, request method POST, and a 5-second timeout.

The following hypothetical drill sample is used throughout this page. A brand e-commerce lead submits a store authorization list whose source text reads: "Authorization object: three platform stores in the East China region; Authorized matter: use of multilingual product material provided by the brand owner for store page display; Authorization validity: 2026-01-01 to 2026-12-31; Authorization status is pending legal review by the brand owner." A draft sentence is submitted for judgment: "The above three stores are authorized to use the multilingual material within the validity period." The draft sentence states a completed authorization where the source records a pending review, so it is not supported.

Configuration and implementation checks

The table below lists implementation check items for this hypothetical drill starting point. These are not official default values.

Three common errors

1. Writing a pending status as a completed authorization. In the sample the authorization status is "pending legal review by the brand owner," while the draft sentence says "are authorized." The same subject, the same period and the same field carry mutually exclusive values, so the draft sentence is unsupported.
2. Treating a retrieval hit as an authorization credential. Retrieval returns corpus text only. Whether the authorization takes effect requires completion of the brand owner's legal review, and a retrieval hit does not change the authorization status.
3. Entering AIPROXY_API_ENDPOINT as a full request address with /v1. The documentation requires the root address, and an appended path produces an incorrect request address.

How to verify the setup

1. Input the sample authorization list source text and the draft sentence. Compare whether "pending legal review by the brand owner" and "are authorized" refer to the same subject, the same period and the same field. If the two values are mutually exclusive, the draft sentence is judged unsupported. Only if the source text were changed to "review passed" could an authorized statement be supported.
2. Input the candidate AIPROXY_API_ENDPOINT value. Compare whether it ends at the root address and contains no /v1. If it contains /v1, it does not meet the documented requirement. If it is a plain root address, proceed to check the token.
3. Input the model status probe configuration. Compare whether the probe interval falls within the 5 to 60 minute integer range. If it falls outside, it does not meet the requirement. If it falls inside, record the configured value; the actual probe result depends on system operation and is not asserted in advance.

Retrieval and relevance scores do not perform permission or entity isolation. A shared vector model requirement inside one retrieval library does not extend to external systems such as business registration sites. Cross-model libraries cannot be jointly associated; verify identifiers first, exclude non-matching items, and record actual observations rather than predicting missed recalls.

Related reading

• self-host/config/env
• self-host/config/model/intro
• FastGPT model connections