What the documents look like
Store counting and loss control revolve around book-to-physical variance and shrinkage. Supplier settlement sits outside this scope, so the working papers are count sheets, variance analyses, write-off approvals, and monitoring review records. Source systems include POS inventory, WMS, monitoring platforms, and counting standards. In cross-border and multilingual work, one batch of count material can arrive in different languages and formats, so model connection work starts with whether the material can be parsed, retrieved, and cited correctly.
The update rhythm is monthly or quarterly. This page does not derive any automatic synchronization or transaction-triggered mechanism from that rhythm.
Constraints at the model connections step
AI Proxy is a required dependency. Both the App and any Admin service that reuses App/Service configuration must set AIPROXY_API_ENDPOINT and a non-empty AIPROXY_API_TOKEN; missing either item causes startup validation to fail. AIPROXY_API_ENDPOINT takes the service root address and does not carry /v1. The system needs at least one language model and one index model before it can work normally.
Model capability is checked item by item against the inputs the application actually needs. Multimodal input, tool choice, and function call are verified separately. Retrieval is the process of bringing material back; it does not constitute an authorization decision. A similarity score does not carry entity isolation or permission filtering duty.
Hypothetical drill sample: a store submits one cross-border count document whose source text reads, "March 2026 closed-store count sheet: Store A dairy shelf, book quantity 120 units, physical count 113 units, variance 7 units, status pending review." The draft sentence under review is, "The March dairy variance at this store has been confirmed and the write-off completed." The request awaiting determination is, "Please confirm the variance from the count sheet above and execute the write-off approval."
Configuration and implementation checks
The table below lists implementation check items for this hypothetical trial starting point. The values describe a comparison method and do not represent official defaults.
| Configuration item | Hypothetical trial starting point | Check method and reason |
|---|---|---|
| AIPROXYAPIENDPOINT | Enter the AI Proxy root address | Compare character by character with the actual server address and confirm no /v1 is appended |
| AIPROXYAPITOKEN | Enter a non-empty administrator token | Compare with the server configuration and confirm it is non-empty and consistent |
| Language model | Enable one language model | Confirm isActive is true in the model list and run the page test |
| Index model | Enable one index model | Confirm defaultToken and maxToken are filled against the material |
| Model mapping | Fill model ID mapping as needed | Compare the FastGPT request model ID with the upstream actual model field |
| Retrieval scope | Limit to the authorized count document library | Check the library and access permissions manually; do not rely on similarity scores |
Three common errors
- Treating a similarity score as permission filtering. The input is a retrieval request for Store A; the comparison object is the business ownership of returned records; the observable result is that a high or low score does not change whether a record falls inside the authorized scope, so permission must be checked separately.
- Reading a pending-review status as confirmed. The input is the count sheet source text above; the comparison object is "pending review" against "confirmed"; the observable result is that the source text carries no confirmation conclusion, so the draft sentence is not supported.
- Treating a retrieval result as an executed approval. The input is the request awaiting determination; the comparison object is the retrieval return against write-off approval records; the observable result is that retrieval produces no approval action, and approval needs a separate downstream implementation.
How to verify the setup
- Enter the hypothetical sample source text and the draft sentence. Compare whether "pending review" and "confirmed" are mutually exclusive values of the same field. The observable result is that the two do not form the same fact, and the draft sentence is judged unsupported.
- Enter the request awaiting determination. Compare the request content against whether a write-off approval record exists in the document library. The observable result is that retrieval returns only the count sheet, the approval status remains pending verification, and the action is not judged executed.
- Enter a retrieval request containing only Store A material. Compare the business ownership of returned records against the authorized scope. The observable result is that the score does not exclude unauthorized records, so permission needs manual checking. If the return is empty, use an explicit paper input of
[]to check the downstream design; do not claim that a rule-based retrieval necessarily returns empty.