Store price and display checks: model connections for product questions

What the documents look like

Price and display auditing happens during day-to-day operations, where the emphasis falls on sustained execution of standards rather than on launch support. The working document set for this category consists of store visit photographs, price tag lists, display standards, and rectification notices, with updates arriving weekly or monthly. Product information and selection questions require extracting product names, specifications, tag status, and display positions from those materials, then answering selection or rectification questions from the extracted content.

The direct constraint at the model connection step is that answer quality depends on whether the connected model can read images, whether it handles Chinese price tag text steadily, and whether the index model can split product information into retrievable segments. FastGPT connects to model providers through AI Proxy, and the system needs at least one language model and one index model to operate normally. Only one speech recognition model takes effect, and this task does not involve that model type.

Constraints at the model connections step

From V4.17.0 onward, AI Proxy is a required dependency. Both the app and the admin service that reuses app and service configuration must set AIPROXY_API_ENDPOINT and a non-empty AIPROXY_API_TOKEN; a missing item in either place causes startup validation to fail. Legacy OpenAI environment variables and single-model custom request addresses cannot substitute for these two settings.

Model capabilities are checked against the inputs the application needs. When photographs are used, the vision capability is checked. Price tag text extraction is checked against the actual mode in use, and the documentation also describes a prompt mode for cases where neither tool capability is available. The vision, toolChoice, and functionCall fields are declared separately in model configuration, and there is no basis for assuming that a same-named field on a chat interface overrides orchestration.

The index model determines whether product information can be retrieved. defaultToken is the token value used during text splitting, and maxToken is the maximum token count. Both are index model fields, checked against the actual model and chunking, and neither value can be inferred from the name of a vector store.

Model probing covers only currently enabled system models. Disabled models do not participate in probing. After a first probe failure, the system retries automatically up to 3 times, and only when all 4 attempts fail is the model judged abnormal.

Configuration and implementation checks

The following is a hypothetical exercise sample. Material text: a March 2026 store visit photograph archiving note from a chain brand operations department states that "price tag photographs must show the product front and the price tag in the same frame, with the capture date on the day of the visit." A separate price tag list has the column headers "store number, product name, specification, listed price, effective date." Draft sentence to be assessed: "The price tag photograph for this store on March 12 shows a listed price of 9.9 yuan, consistent with the effective date on the list, which confirms correct price execution."

Three common errors

1. Writing AIPROXY_API_ENDPOINT as a full model request address with /v1 appended. The documentation requires the service root address. Check method: read the variable value, compare it against "root address, no /v1," and treat any /v1 as not satisfying the requirement.
2. Entering an application API key into AIPROXY_API_TOKEN. The documentation requires an administrator token that is non-empty. Check method: compare the entered value against the server-side administrator token; a mismatch or an empty value does not satisfy the requirement.
3. Treating old probe history as new probing during a disabled period. According to the documentation, disabled models do not participate in probing. Check method: examine the enabled state and the record timestamps, and check only whether new records appear during the disabled period; the presence of old history alone does not establish an error.

How to verify the setup

1. Input the draft sentence from the hypothetical sample together with the two source materials. Compare the draft sentence's claim of "correct price execution" against what the materials actually state. The materials state only that photographs must show product and tag in the same frame and that the list contains an effective date; they do not state that the store's actual listed price on that date matched the list. Expected observation: the draft sentence's conclusion is not supported by the materials and should be marked as pending verification.
2. Once actual store visit photographs are available, check the selected model's vision declaration and upstream image support, then test actual input and results with the same image. The archiving note alone does not demonstrate that a photograph was processed, and a declared value does not replace actual invocation verification.
3. Input the price tag list text together with the index model defaultToken setting. Compare whether the split segments cover complete product rows. Expected observation: when a segment is truncated so that the specification or listed price is missing, the value needs adjustment and re-checking. When retrieval returns empty, a clearly written paper input of [] can be used to check downstream design, without claiming that a fictional rule necessarily returns empty.

Model probe alerts are pushed only on edge changes in state, and a sustained abnormal state is not pushed repeatedly. Retrieval does not carry authorization duties, and a similarity setting does not exclude unauthorized records.

Related reading

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