What the documents look like
Complaints and official replies are directed at a platform or a regulator, so the material has to carry formal evidence and remediation wording. The usual sources are the 12315 platform, platform complaint centres, customer service chats and order systems; the working documents are complaint tickets, regulator enquiry letters, order evidence and remediation reports. In cross-border work, one case often holds tickets in several languages, overseas order proof and a Chinese remediation draft at the same time, and retrieval has to place material of different languages and different origins into one case thread. The material updates irregularly, case by case. This page focuses on model connections and case-material correspondence without inferring synchronization or trigger mechanisms.
For model connections this matters in two ways. First, the connection layer is a hard prerequisite rather than an optional add-on: from V4.17.0, AI Proxy is a required dependency, and both the App and an Admin service that reuses App/Service configuration must set AIPROXY_API_ENDPOINT and a non-empty AIPROXY_API_TOKEN. Missing either one causes startup validation to fail, and legacy OpenAI environment variables or a single-model custom request address cannot replace these two settings. AIPROXY_API_ENDPOINT takes the AI Proxy service root address, without /v1 appended. Second, multilingual retrieval depends on an index model to build vectors for text chunks while the language model handles dialogue and extraction, and the system needs at least one language model and one index model to work normally. Model capabilities have to be checked item by item against what the application actually receives; multimodal input, tool calling and thinking configuration are verified separately, and a same-named field on a compatible chat interface cannot be assumed to override orchestration settings.
Hypothetical paper exercise sample. A cross-border shop receives a regulator enquiry letter whose text reads: "This authority received a consumer complaint on 10 March 2026 concerning order number A-2026-0310, and requires the respondent to submit a written explanation and transaction evidence within ten working days of receiving this letter." A proposed draft sentence reads: "The shop has completed rectification and submitted all evidence." A handover request awaiting review reads: "Please retrieve the refund record for this order and reply to the regulator."
Constraints at the model connections step
The letter states a submission requirement and a deadline. It does not state that anything has been submitted. The draft sentence asserts a completed state that the letter does not support, so that sentence stays pending verification and cannot be treated as filed. The handover request asks for retrieval and for a reply to the regulator; retrieval is not authorisation, and a retrieval hit does not authorise that reply. Whether a refund record exists in the retrieval scope is a separate question from whether the shop may answer the regulator.
Retrieval libraries that use the same vector model can be associated with one another; libraries on different vector models cannot be associated, and the correct step is to check the identifier first and exclude those that do not match. Semantic recall and relevance scores do not carry permission or entity isolation duties, and retrieval itself does not constitute authorisation. Whether the material needed for the check sits inside a retrieval scope the operator may access, or inside a clearly identified manual input, has to be established; where it is missing, the gap is recorded as a gap.
Configuration and implementation checks
The table below lists documented settings or implementation checks tied to this page's task. Values marked as hypothetical exercise starting points are paper values for this exercise only; each needs a stated reason and a comparison target, and none is an official default.
| Configuration item | Hypothetical exercise starting point | Check method and reason |
|---|---|---|
AIPROXY_API_ENDPOINT | http://aiproxy:3000 | Root address, no /v1 appended; compare against the documented root-address requirement and the startup validation rule |
AIPROXY_API_TOKEN | A non-empty administrator token entered for the exercise | Compare against the server-side configuration to confirm it is non-empty and consistent |
| Index model | One index model assumed enabled | Compare against the requirement that the system has at least one index model |
| Language model | One language model assumed enabled | Compare against the requirement that the system has at least one language model |
MILVUS_LANGUAGE_IDENTIFIER | lingua assumed | Full-text search uses BM25 only when the vector store is Milvus; compare against the actual vector store type |
| Model probe interval | 15 minutes assumed | The documented range is an integer between 5 and 60 minutes; compare against that range |
Three common errors
- Writing
AIPROXY_API_ENDPOINTas a full request address with/v1appended. Input is the configured value; the comparison object is the documented root-address requirement. Check the root-address format first against that requirement; the overall startup and request outcome remains untested. - Using an application API key in place of
AIPROXY_API_TOKEN. Input is the token value; the comparison object is the server-side administrator token. The observable result is whether authentication is accepted. - Treating a retrieval hit as authorisation already granted or as evidence already submitted. Input is the retrieval result; the comparison object is whether the written explanation and transaction evidence required by the enquiry letter actually exist. The observable result is whether the material stays in a pending-verification state.
How to verify the setup
The three checks below use the hypothetical sample above and state input, comparison and satisfaction condition. All are paper expectations and were not executed.
- Input the sample letter text and the proposed draft sentence "The shop has completed rectification and submitted all evidence." The comparison object is the letter's requirement to submit a written explanation and transaction evidence within ten working days. The letter states only a submission requirement and does not record a submission fact; the completed state asserted in the draft sentence is unsupported by the material. Record it as pending verification, and do not conclude that submission occurred.
- Input the handover request "Please retrieve the refund record for this order and reply to the regulator." The comparison object is whether a refund record for that order exists in the retrieval scope. If retrieval returns an empty result, check the downstream design against the explicit paper input and record the gap; whether the actual query is empty remains untested, and the paper empty array is used only for downstream design checking. A retrieval hit does not constitute authorisation to reply to the regulator.
- Input order number A-2026-0310 from the sample. The comparison object is the vector model identifier used by each retrieval library. Check the identifier first and exclude those that do not match; do not run cross-model retrieval to compare missed recall. Record what is actually observed and what remains unknown.
Signature, agreement reached and contract effectiveness in the material are distinct facts; a pending review does not show that an operating permission is absent. This page addresses model connection and configuration only. Which materials, operations and requests hold what authorisation state during operational handover cannot be settled by retrieval or by a form.