What the documents look like
Product information in wholesale stall trading sits in purchase receipts, handwritten sales slips, stall lease contracts and payment receipts. A stall owner and a buyer negotiate on the spot, then write the slip; product names, specifications, quantities and prices often appear in handwriting, and the same item can carry a short form or alias across different documents. A product-information and selection question-answering setup draws checkable fields from these materials, then answers buyer questions about specification, stock and substitutes according to what the connected model can do. Records update daily and per order. That update rhythm does not by itself trigger any automatic synchronization action.
Constraints at the model connections step
Model access depends on the AI Proxy service. 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 one causes startup validation to fail. AIPROXY_API_ENDPOINT holds the AI Proxy service root address and does not append /v1. The system needs at least one language model and one index model to work normally. The model ID in model configuration is the value of the model field in the interface request body and is globally unique; the model name is for display only. If product-information question answering involves image recognition, the selected language model needs vision capability, checked against the input the application actually requires rather than assumed on by default.
Hypothetical drill sample: one handwritten sales slip from a stall states "rebar HRB400, diameter 12 mm, quantity 3 tonnes, unit price 3850 yuan, valid for the current day," and one stall lease contract states "stall A-17, lease term 1 January 2026 to 31 December 2026." The draft sentence to be judged is "this stall can supply rebar HRB400 diameter 12 mm over the long term, at a price based on 3850 yuan." The comparison target is the current-day validity scope on the sales slip against the long-term supply wording in the draft.
Model probing covers only currently enabled system models; disabled models take part in no probing and produce no history. After a first probe failure the system retries at most 3 times, so only 4 failed attempts in one round produce an abnormal judgement. The alert Webhook pushes on edge changes of status, and a model that stays abnormal is not pushed again.
Configuration and implementation checks
The rows below concern this page's product-information and selection question-answering task. Each is a documented setting or an implementation check. Any number is a hypothetical starting point for this exercise, with its reason and its comparison target.
| Configuration item | Hypothetical starting point for this page | Reason and comparison method |
|---|---|---|
AIPROXY_API_ENDPOINT | Assume an internal AI Proxy root address, without /v1 | Compare the ending against the documented requirement of no /v1; confirm no /v1 at the end |
AIPROXY_API_TOKEN | Assume a non-empty administrator Token | Compare with the server-side configuration; confirm consistent and non-empty |
| Language model vision capability | Assume enabled as required | Compare against whether product materials include image input; not forced when no image input exists |
| Index model | Assume at least one enabled | Compare against the documented requirement of at least one index model |
| Model ID | Assume consistent with the model field in the channel | Compare with the channel's configured model field; confirm globally unique |
| Probe interval | Assume 10 minutes | Compare against the documented integer range of 5 to 60 minutes; this is only a starting point for this exercise |
Three common errors
- Treating a "valid for the current day" quote on a handwritten sales slip as a long-term supply commitment. The slip states only a current-day validity scope, so a draft sentence written as "long-term supply" goes beyond that scope and remains unsupported.
- Filling
AIPROXY_API_ENDPOINTwith a complete model request address and appending/v1. The documented requirement is a root address without/v1; an appended/v1fails that requirement, and the actual request path and response need testing. - Treating the lease term in a stall lease contract as a product supply period. The lease contract's object is the stall, while product-information question answering concerns goods; the two subjects and objects differ and cannot substitute for each other.
How to verify the setup
- Input the hypothetical sales slip text "rebar HRB400, diameter 12 mm, quantity 3 tonnes, unit price 3850 yuan, valid for the current day" together with the draft sentence "this stall can supply rebar HRB400 diameter 12 mm over the long term, at a price based on 3850 yuan." Check the price validity scope and the supply commitment separately. The source supports a current-day quote of 3850 yuan; it gives no specific date for the slip and no long-term supply commitment. Rewriting the draft as "current-day supply" alone still does not make it supported. Both the long-term price and the long-term supply claim remain to be verified.
- Input the hypothetical value filled into
AIPROXY_API_ENDPOINTand compare whether its ending contains/v1. If the ending contains/v1, it does not meet the documented requirement; if the ending is the root address, the condition is met.AIPROXY_API_TOKENis compared for being non-empty and consistent with the server side. - Input the hypothetical lease contract text "stall A-17, lease term 1 January 2026 to 31 December 2026" together with a product supply enquiry. Compare the contract object "stall" with the enquiry object "goods." The objects differ, so the contract lease term cannot serve as evidence of a product supply period; record it as pending verification and keep the evidence gap open.