What the documents look like
After-sales and fulfillment answering for low-price campaign stores on Pinduoduo works from four recurring materials: campaign registration forms, product cost calculation sheets, after-sales refund orders, and platform internal messages. These materials update daily or per campaign, and they record campaign stock estimates, campaign-price gross margin, and abnormal refund tracking. The retrieval step has to pull out the content that corresponds to a specific order, a specific campaign session, or a specific refund order, so that fulfillment decisions and after-sales replies can cite it.
The materials carry a subject, an object, a time range, and a status. A campaign registration form states the participating store, the campaign session, the registered product, and the registration status. An after-sales refund order states the order number, the refund reason, the refund status, and the handling node. A platform internal message states the notified party and the notified matter. Whether a retrieval result is usable depends on whether these fields are recalled together for later manual cross-checking.
Because the same order can appear in a refund order, a cost sheet, and a campaign form at once, the retrieval request usually names one document type and one identifier. A question that names only a campaign session, without a product or order number, tends to return material from several sessions. A question that names only a product, without a session, tends to return material from several campaigns. The retrieval step does not resolve which of those records belongs to the case at hand.
Constraints at the retrieval step
The knowledge base search node can associate one or more knowledge bases that use the same vector model. Knowledge bases built on different vector models cannot be associated together. Before configuration, check the vector model identifier, exclude those that do not match, and record the actual observation. Do not run cross-model retrieval to compare missed recalls.
Search modes are semantic retrieval, full-text retrieval, and hybrid retrieval. Semantic retrieval computes similarity by vector distance. Full-text retrieval suits precise queries such as numbers, model designations, proper nouns, and error codes. Hybrid retrieval uses both recall paths and merges the results through RRF. RRF is a merging process, not a separate switch that can be turned on. Image retrieval requires an image input and a model with the corresponding capability. Reranking requires a ReRank model and must be enabled in the settings. The paths shown in the documented flow diagram do not mean every request executes all of them.
The citation limit is measured in tokens and controls how much content a single search may cite. The minimum relevance score is a filter threshold between 0 and 1, effective only in semantic retrieval or when result reranking is used. It is a filter condition and does not perform permission or entity isolation. Retrieval by itself is not authorization and does not decide whether a business subject may view a given record.
Question optimization performs coreference resolution and question expansion, adding one model call before the formal retrieval. An empty result is output as an array whose length can be 0, and the output path still completes.
Hypothetical drill sample
The following is a hypothetical drill sample, not a real record. Material text: a store's campaign registration form states "campaign session A-0715, registered product summer mat, registration status submitted, pending platform review." A platform internal message from the same period states "registration information for session A-0715 has been received, review result will be notified separately." A proposed handover request reads: "Session A-0715 mat registration has passed, orders may be accepted at the campaign price and stock may be locked."
Decision point: the material records the registration status as submitted and pending platform review, and the internal message only confirms receipt of the registration information without stating that review passed. The proposed sentence writes the pending-review status as passed and on that basis asks to accept orders and lock stock. The request is not supported by the material and remains pending verification. Accepting orders and locking stock are business actions that require a separately connected system implementation; retrieval or a form does not constitute authorization.
Configuration and implementation checks
| Configuration item | Hypothetical trial starting point | Reason for the choice and comparison method |
|---|---|---|
| Associated knowledge bases | Associate only bases using the same vector model | Check the vector model identifier first, exclude non-matching bases, and do not compare cross-model missed recalls |
| Search mode | Run semantic retrieval and full-text retrieval separately | Use the same test question to compare the two recall paths and observe differences between number-type and natural-language hits |
| Citation limit | Set to a token amount that holds one complete refund order | Test with actual materials of different lengths to see whether content is truncated, then adjust |
| Minimum relevance score | Label related and unrelated samples first, then set the value | Effective only in semantic retrieval or result reranking; observe whether unrelated fragments are filtered |
| Question optimization | Trial-enable for multi-turn follow-ups and short questions | Compare the original question with the optimized question and check whether the subject was altered incorrectly |
| Empty-result handling | Use a paper input of an empty array to check the downstream design | Check whether the downstream branch handles a citation length of 0 |
The values in the table are hypothetical trial starting points for this drill, not official defaults.
Three common errors
- Treating a pending-review status as passed. Input is the material text "registration status submitted, pending platform review"; compare the proposed sentence "registration has passed"; observe whether the proposed sentence matches the status field in the material. When they do not match, the request is not supported, and order acceptance and stock locking must not proceed on that basis.
- Treating a retrieval result as an authorization credential. Input is one refund-order retrieval hit; compare the handling node stated in that refund order with the refund action proposed for execution; observe whether the material states that the action may be executed. When it does not, record the evidence gap and do not presume authorization.
- Associating knowledge bases across different vector models. Input is the vector model identifiers of two knowledge bases; compare whether the two are identical; observe whether the configuration permits joint association. When the identifiers differ, exclude that base, record the actual observation, and do not infer a runtime result.
How to verify the setup
- Against the sample material text "registration status submitted, pending platform review," input the proposed sentence "registration has passed, orders may be accepted at the campaign price and stock may be locked," compare the status field with the proposed wording, and observe whether the retrieved citation contains "pending platform review." If the citation does not contain that status, the decision is not supported and remains pending verification.
- Against the sample internal message "registration information has been received, review result will be notified separately," input the question "has the A-0715 mat registration passed," compare the recalled content with the internal message text, and observe whether the recall reflects only "received" without the appearance of "passed." If a passed conclusion appears in the recalled content, check the source; when the source is absent, record the gap.
- For the case of a citation length of 0, use a paper input of an empty array to check the downstream branch, and observe whether the downstream handles it as no citation. Do not claim that a fictional rule retrieval necessarily returns an empty array; check only the empty-result handling design.
All three verification steps are paper checks. No retrieval or business action was actually executed.