What the documents look like
Livestream after-sales work concentrates after a single broadcast. Refund requests and replacement orders arrive in the same window, and customer service staff must check the livestream order list to confirm the product and the promise made on air, then use a script template to explain the outcome consistently. Material updates follow the broadcast and the day. Document parsing and chunking determine whether these materials can be recalled accurately.
The livestream order list carries order numbers and product names. Refund requests carry an application reason and a status. Replacement orders carry the replacement target and a quantity. Script templates carry an applicable scenario and wording. The structure and semantic completeness of these materials directly affect retrieval precision. Because several document types share overlapping terms such as order numbers and product names, a chunk that separates a condition from the content it constrains can be recalled for the wrong question.
Constraints at the document chunking step
In FastGPT, a knowledge base consists of libraries, collections and data. The smallest search unit is the library; collections only classify data and do not affect search results. One data group can map to multiple vectors, and the vector score takes the highest score. During retrieval, vectors are recalled first, then the vector ID is used to find the original data in the MongoDB dataset.datas table; entries corresponding to the same original data group are merged. Chunking should therefore keep a condition, its explanation and the content it constrains in the same group.
Full-text retrieval suits numbers, model names and proper nouns. Semantic retrieval suits natural-language questions. Hybrid retrieval uses both and merges results through RRF. Rerank requires a model and a setting; it produces a 0-1 score used for filtering. The relevance threshold applies only under semantic retrieval or reranking. Image retrieval requires image input and matching model capability, and reranking requires a model enabled by configuration.
Hypothetical paper test case: the source material reads, "The refund request for order A has status pending review, and the application reason is that the product does not match the livestream display; replacement order B has order A as its replacement target, a quantity of one item, and has not yet left the warehouse." The draft sentence to be judged reads, "The refund for order A has been approved, and replacement order B has left the warehouse." The source states only that the refund request is pending review and that the replacement order has not left the warehouse. The status values in the draft sentence do not match the source.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason and comparison object |
|---|---|---|
| Search mode | Hybrid retrieval | Materials contain order numbers and natural-language reasons; compare recall coverage against semantic retrieval alone |
| Reference limit | Measured in tokens; starting value undetermined | The official control is tokens; compare stability across differing chunk lengths |
| Minimum relevance | A 0-1 value; starting value undetermined | Applies only under semantic retrieval or reranking; compare results before and after filtering |
| Question optimization | Enabled as needed | Completes references in follow-up turns; compare elapsed time against the disabled state |
| Rerank | Enabled when a model is available | Secondary ordering when candidates are numerous; compare ordering before reranking |
| Chunk review | Manual review | Check whether conditions and the content they constrain stay in one group; compare against source structure |
These values are hypothetical starting points for this exercise and are not official defaults. RRF is a fusion process for hybrid results and is not configured as a switch. Image retrieval requires image input and corresponding model capability. Reranking requires a model enabled by configuration.
Three common errors
- Treating a successful upload as an updated index. After material changes, check the actual training and index state. The upload action and index activation are two separate facts.
- Treating retrieval or a form as authorized execution. Retrieval does not provide permission isolation. A form collects values; business verification, approval and external synchronization require separate downstream implementation.
- Treating pending review as approved. In the sample, the refund request status is pending review while the draft sentence states approved. This is a value conflict within the same field.
How to verify the setup
- Input the sample source material and the draft sentence, then compare the refund request status field. The source says pending review and the draft says approved. These are mutually exclusive values in the same field, so the result is a contradiction.
- Input the sample source material and the draft sentence, then compare the replacement order outbound status. The source says not yet left the warehouse and the draft says left the warehouse, which is a contradiction. If the source did not state an outbound status, record the claim as unsupported.
- Input an order number and a natural-language question separately, then observe whether the returned content points to the same original data group. If the return is empty, check the downstream design against the explicit paper input rather than asserting that a fictional rule must return empty. Libraries using different vector models cannot be associated jointly; verify identifiers first and exclude non-matching ones, then record the actual observation.