What the documents look like
Retail checkout and loyalty materials arrive from several operational systems: the point-of-sale system, the member CRM, payment platforms and the price-tag system. The everyday documents in this category are promotional price tags, membership point rules, the daily checkout report and abnormal refund slips. They are updated daily and by shift. Price and membership entitlement sit at the center of this material, and multilingual versions need to preserve the store, the effective period and the document identifier so that a rule and its actual handling record can be traced back.
Cross-border and multilingual retrieval in this category therefore has to keep two separate things apart. One is the rule text, such as a points multiplier and its applicable time window. The other is the handling record, such as the current state of a refund slip. A retrieval result or a completed form field is not an authorization decision. An unsigned termination is not a completed termination, a pending refund request is not an approval, and an offered option is not an execution.
Constraints at the model connections step
From V4.17.0, AI Proxy is a required dependency. The App and any Admin service that reuses App/Service configuration must both set AIPROXY_API_ENDPOINT and a non-empty AIPROXY_API_TOKEN; missing either item causes startup validation to fail. Older OpenAI environment variables or a single-model custom request address do not replace these two settings. The system needs at least one language model and one index model to work normally. Only one speech recognition model takes effect, so configuring one is sufficient.
Model configuration covers the model ID, the model name, the model channel, and the custom request address and key. The model ID is the value of the model field in the request body and is globally unique. Model mapping can map a model requested from FastGPT to the actual upstream model, for example mapping gpt-4o-test to gpt-4o. Channel priority ranges from 1 to 100; a larger value is more likely to be selected first. Model probing covers only currently enabled system models. The probe interval accepts an integer between 5 and 60 minutes. After a first failure the system retries at most 3 times, so a single round makes at most 4 attempts; only when all four attempts fail is the model judged abnormal. Using the same vector model is a precondition for associating retrieval libraries, and this requirement does not extend to external business-registration websites or other systems.
Hypothetical paper exercise sample: a store's daily checkout report dated 15 March 2026 records "member points follow promotional price tag A-0315, points multiplier 2x, applicable window 09:00-12:00". On the same date, abnormal refund slip R-0315-07 records "customer claims points were not accumulated at 2x, refund amount 48 yuan, status is pending review". A drafted sentence reads "this customer's points have been accumulated at 2x, and the refund request has been approved". In this sample the daily report and the refund slip are two independent materials. The refund slip status is pending review, so the drafted phrase "has been approved" does not match the recorded status, and "points have been accumulated at 2x" has no corresponding record in the materials.
Configuration and implementation checks
The table below lists documented settings or implementation checks relevant to this page's feature and primary task. The starting values are hypothetical for this paper exercise, not official defaults.
| Configuration item | Hypothetical starting value for this exercise | Reason and comparison object |
|---|---|---|
AIPROXY_API_ENDPOINT | http://aiproxy:3000 | Documented root-address example, with no /v1 appended; compare against the documented root-address format |
AIPROXY_API_TOKEN | Non-empty administrator token | Documented requirement that it be non-empty and consistent with the server; check non-emptiness, server consistency and credential source; call result remains untested |
| Model channel protocol type | OpenAI | Adopted only when the upstream supports that protocol; check interface compatibility against the provider |
| Model mapping | gpt-4o-test to gpt-4o | Documented mapping example; compare the upstream actual model value against the unmapped case |
| Channel priority | 50 | Hypothetical starting point, mid-value inside the 1 to 100 range; compare actual routing against another channel's priority record; a larger value is only more likely to be preferred |
| Probe interval | 30 minutes | Documented support for an integer between 5 and 60; compare against the boundary values 5 and 60 to confirm the value is in range |
Model capability must be checked against the input the application needs. Multimodal input, tool calling and thinking configuration are verified separately. Application parameters are set in the application or node configuration; do not assume that a same-named field on a compatible chat interface overrides orchestration.
Three common errors
- Treating a retrieval result or a completed form as an authorization execution. In the sample, the refund slip status is "pending review" while the drafted sentence says "has been approved". The input is the refund slip text and the drafted sentence; the comparison object is the status field value; the observable result is that "pending review" and "has been approved" do not agree, so the drafted sentence does not hold.
- Reading the probe's "at most 4 attempts" as a guaranteed 4 retries. The input is the probe configuration and the single-round result; the comparison object is the
attemptsfield value; the observable result is thatattemptsmay be 1 to 4, and only when all four attempts fail is the model judged abnormal. - Extending the same-vector-model requirement to external systems. The input is the retrieval library configuration and the external data-source list; the comparison object is the vector model identifier; the observable result is that only libraries inside the retrieval set need the same model, and external systems fall outside this constraint.
How to verify the setup
The three checks below use the hypothetical sample above. Each states the input, the comparison and the expected phenomenon. No test has been performed.
- Input the daily report text, the refund slip text and the drafted sentence from the hypothetical sample. Compare the drafted phrase "the refund request has been approved" against the refund slip status field "pending review". When the two values are clearly mutually exclusive, the drafted sentence is judged to contradict the material. If the refund slip does not state a review conclusion, record it as unsupported and keep the evidence gap open.
- Input the daily report text "points multiplier 2x, applicable window 09:00-12:00" and the drafted sentence "points have been accumulated at 2x". Compare the rule recorded in the daily report against the fact asserted in the drafted sentence. The daily report records only the rule and does not record this customer's actual accumulation result, so the asserted fact has no corresponding record in the materials and is judged pending verification.
- Input the hypothetical sample's retrieval request and returned results. Compare whether the returned entries point to the daily report or the refund slip text. When the returned result is an empty array, do not infer that the rule does not exist; record only that this retrieval did not match, and check whether the downstream handles the empty result as designed. A first-hit or full-recall guarantee is not provided.
Probe alerts and refund and points reconciliation are recorded separately. No test was executed on this page.