What the documents look like
Presale group buying collects orders first and organizes purchasing and fulfillment afterwards. Product-question answering in this category turns on a narrow set of facts: whether a presale item can still reach its group threshold before cut-off, how a specification maps to an incoming batch, and whether a purchase plan already covers that item. The working documents are the presale product table, the group-order result, the purchase plan and the cut-off notice. They are refreshed daily or per session, so the same product can carry different descriptions in different sessions. Any comparison has to lock the same session, the same product and the same field.
A hypothetical drill sample is used throughout this page. The presale product table text available for checking reads: “Session: 2026-09-23 morning. Product: A, 500 g frozen shrimp, specification 500 g. Cut-off time: 2026-09-23 06:00. Group-order result: this item has collected 42 units, below the 50-unit group threshold.” One draft sentence is pending judgment: “Item A, 500 g frozen shrimp, has reached its group threshold this session and purchasing can be arranged.” The material contains a collected-quantity figure and a threshold figure. It contains no group-conclusion field and no purchase plan record.
Constraints at the model connections step
Model access depends on AI Proxy. Both the App and an Admin service that reuses App/Service configuration must set AIPROXY_API_ENDPOINT and a non-empty AIPROXY_API_TOKEN; a missing value in either 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 to work normally. The model ID is the value of the model field in the request body and is globally unique; the model name is for display only.
A retrieval hit does not carry authorization or entity isolation. Knowledge-base retrieval and authorization are separate layers: a matched fragment does not mean the current operator may view or change that product record. Forms collect values; business verification, approval, database writes and external synchronization each need their own downstream implementation.
Channel priority runs from 1 to 100, and a larger value is more likely to be selected first. Model call logs are retained for 1 hour, configurable through an environment variable. Model status probing covers enabled system models only. After a first failure the system retries at most 3 times, so a round makes at most 4 attempts; only when all 4 attempts fail is the model judged abnormal. Normal means a successful test with latency at or below 30 s, and high latency means a successful test above 30 s. The alert webhook fires on edge changes of model status. When automatic probing is off, the page shows an empty state.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this drill | Reason and comparison object |
|---|---|---|
| AIPROXYAPIENDPOINT | AI Proxy service root address | Matches the documented requirement; compare against a value that wrongly appends /v1 |
| AIPROXYAPITOKEN | Non-empty token consistent with the server | Compare against an application API key used in its place |
| Language model | One language model that passed a channel test | The system needs at least one language model |
| Index model | One index model that passed a channel test | The system needs at least one index model |
| Model capability | Check vision and toolChoice against the input the question answering needs | Compare model capability with the actual task input |
| Probe interval | 30 minutes as a hypothetical starting point | The documented range is an integer from 5 to 60 minutes; compare against the alerting delay the operator needs |
The starting values above are drill assumptions, not official defaults. The documented defaults for AIPROXY_API_ENDPOINT and AIPROXY_API_TOKEN are absent and both are required.
Three common errors
- Treating a retrieval hit as authorization. The input is a product-data fragment returned by retrieval; the comparison object is the current operator's permission scope; the observable result is whether the fragment falls inside the target retrieval scope the operator may access. A matched fragment by itself does not authorize a change or a purchase action.
- Reading a collected-quantity figure as a group conclusion. The input is “42 units collected, below the 50-unit group threshold”; the comparison object is whether the material contains a group-conclusion field; the observable result is that the field is absent. With the field absent, the conclusion is unsupported.
- Treating a passed model test as business availability. The input is a channel test result; the comparison object is the actual input and output of product-data question answering; the observable result is whether the answer cites the source text. A passed test shows connectivity only.
How to verify the setup
- For the draft sentence “Item A, 500 g frozen shrimp, has reached its group threshold this session and purchasing can be arranged,” the input is the three-sentence source text above together with this draft. The comparison object is whether the source text contains a group-conclusion field. The observable result is that the source text carries only a quantity and a threshold. The condition is met when the draft is judged unsupported and the missing group-conclusion field is recorded.
- For a purchasing-arrangement request, the input is the same session and product identifier. The comparison object is whether the purchase plan contains a record for that item. The observable result is that no purchase plan was provided. The condition is met when the request is recorded as pending verification and is not treated as arranged.
- For the retrieval step, the input is an explicit paper input of
[]. The comparison object is the downstream design for handling an empty result. The observable result is whether the empty result is handled separately. The condition is met when the empty result is not treated as a hit and no inference is drawn from it that the product does not exist.
These are expected outcomes for the drill, not results of an executed test. No deployment, approval, refund or other business action is claimed here. Where the material does not state a field, that gap remains open.