What the documents look like
Pinduoduo low-price campaign operations revolve around low-price resource slots, campaign inventory, and refund-rate swings. Four document families carry most of the evidence: campaign registration forms, product cost calculation sheets, after-sales refund orders, and platform internal messages. These materials update daily or once per campaign, and they drive inventory estimation, abnormal-refund tracking, and campaign-price gross-margin checks.
The chunking step has to cut stable fields out of those materials: campaign price, registration quantity, cost items, refund status. A product question then has to be traceable back to a specific material and version. Because the same product appears in several campaign sessions at different prices, chunk boundaries must keep the session scope attached to the price and quantity it governs.
Constraints at the document chunking step
In FastGPT, a knowledge base is made of library, collection, and data. The smallest search unit is the library; collections only classify data and do not affect search results. Vector source data lives in the MongoDB dataset.datas table, and an indexes field records the corresponding vector IDs, so one group of data can map to multiple vectors. During retrieval, vectors are recalled first, then the vector IDs are used to find source content in MongoDB; matches to the same source group are merged and the highest vector score is kept.
Segmentation must keep conditions, descriptions, and the content they constrain together. If a price condition in a campaign registration form is separated from the product range it applies to, a selection question cannot return a complete basis. Semantic retrieval depends on vector distance; full-text retrieval suits precise lookups such as numbers, models, and proper nouns; hybrid retrieval merges multiple result paths through RRF; ReRank performs a second ordering of candidate text. None of these steps performs permission or entity isolation, and retrieval results do not replace authorization checks.
Configuration and implementation checks
The table below concerns a hypothetical exercise sample and lists only documented settings or implementation check items relevant to this feature and primary task. The values are starting points for this exercise, not official defaults.
| Configuration item | Hypothetical exercise starting point | Reason and comparison method |
|---|---|---|
| Search mode | Hybrid retrieval | The sample contains campaign numbers and natural-language questions, so semantic and keyword hits both matter; compare against semantic retrieval alone |
| Citation limit | Hypothetical start 3000 tokens | The sample holds several cost and inventory fields and needs a complete segment; compare against a lower value to see whether condition sentences are truncated |
| Minimum relevance | Hypothetical start 0.5 | Sample questions are explicit; used to observe whether low-relevance fragments are filtered, compared against results with filtering off |
| Question optimization | On | The sample contains follow-up references that need their subject completed; compare retrieval terms against the off state |
| Result reranking | Enabled | Candidate segments are numerous and need filtering by rerank score; compare against ordering by vector score alone |
| Segmentation basis | By product and campaign session | The same product has different campaign prices in the sample, so fields must stay complete; compare against fixed-length splitting |
Three common errors
- Treating a successful upload as an updated retrieval state. After material changes, the actual training and index status must be checked; the upload action itself does not indicate that new segments can be recalled.
- Treating semantic recall or a relevance score as a permission or entity filter. A similarity setting does not exclude unrelated businesses or unauthorized records, and retrieval results still require manual checking of the authorization boundary.
- Describing RRF after hybrid retrieval as a separate switch that can be turned on. RRF is a result fusion process, not a configuration item; reranking requires a model and must be enabled according to settings.
How to verify the setup
Hypothetical exercise sample: the source text is "Campaign registration form: product A, campaign number HD-0715, registration price 9.9 yuan, registration quantity 500 units, applicable session July 15 to July 17. Product cost calculation sheet: product A unit cost 8.2 yuan, including logistics 1.1 yuan." The draft sentence to be judged is "Product A can register 500 units at 9.9 yuan in session HD-0715, and the gross margin is negative." The judgment compares whether registration price, cost items, and quantity share the same subject, the same session, and the same field.
- Input the draft sentence and the source text, and compare whether product A's campaign number, registration price, and cost items agree. If total cost exceeds the registration price, the draft sentence's gross-margin judgment is supported; if the cost field is missing, record it as unsupported.
- Search "HD-0715" and "product A registration price" separately, and compare whether returned segments contain the campaign number, registration price, and session range. If a segment keeps the condition sentence intact, the check condition is met; if condition and price are separated, record a segmentation problem.
- Input an empty-result downstream scenario, using the explicit paper input [] to check the downstream display design, and observe whether the system handles it as an empty citation. Do not claim that a fictional rule's retrieval necessarily returns []. If the downstream design does not define empty-result behavior, record it as pending verification.
This page addresses only Pinduoduo low-price campaign operations, product data and selection questions, and document parsing and chunking. Which materials, operations, or requests are in what authorization state during an operations handover remains a separate question; retrieval or a form cannot be treated as authorization execution.