What the documents look like
Complaints and official replies are addressed to a platform or a regulatory authority, so the file set carries formal evidence and remediation wording rather than informal after-sales notes. The material arrives from the 12315 platform, platform complaint centres, customer service chat, and the order system. Day-to-day documents include complaint tickets, regulatory inquiry letters, order evidence, and remediation reports. These structures differ from one another. A ticket holds a complainant statement and a demand. An inquiry letter holds a numbered question list and a reply deadline. Order evidence holds a transaction timeline and payment records. A remediation report holds problem items and measures. Updates are irregular and handled case by case.
For the product-information and option-selection question task, chunking has to keep subject, object, status, and validity scope together, so a condition is not separated from the content it constrains. A demand and its factual account belong in one block. A question and its reply deadline belong in one block. The material also mixes exact identifiers with natural language, which affects how retrieval is configured later.
Constraints at the document chunking step
Segmentation completeness is checked against the structure of each specific document type, not against a single uniform rule. Complaint tickets, inquiry letters, and order evidence each need their own inspection of where a paragraph begins and ends.
Data and index are distinct. Original data is stored in the dataset.datas table in MongoDB, and an indexes field records the corresponding vector IDs, so one data group can map to multiple vectors. Vector retrieval is handled by the PG Vector plugin in PostgresSQL, with an HNSW index. During retrieval, vectors are recalled first, then the original data is located in MongoDB by vector ID; when vectors map to the same data group, the results are merged and the highest score is taken. The smallest search unit is the library, and a collection only classifies data for management purposes.
Image retrieval depends on whether a corresponding index was built at ingestion time. Plain text queries work normally without a vision model; pure image queries are essentially unavailable in that configuration. Full-text retrieval on a PG vector store uses MongoDB $text with jieba tokenization. Hybrid retrieval merges semantic and full-text results through RRF. A ReRank model produces a 0-1 score used for filtering. Question optimization adds one model call before retrieval for coreference resolution and question expansion. The reference cap is measured in tokens, and the minimum relevance value takes effect only under semantic retrieval or result reranking.
Configuration and implementation checks
Hypothetical drill sample. The source text reads: "Complaint ticket number TS-2024-0871. The complainant asserts that order A-5521, placed on 5 March 2024, was not delivered by the agreed time, and requests a refund and compensation. Regulatory inquiry letter number JG-2024-112 requires a written reply by 10 April 2024 concerning the delivery records and customer service communication records for the above order." The draft sentence to be assessed reads: "Upon verification, order A-5521 was delivered on time on 5 March 2024, and the complainant's assertion does not hold." The order evidence shows a signed receipt time of 7 March 2024 in the delivery record, which differs from the "on time on 5 March 2024" wording in the draft sentence.
| Configuration item | Hypothetical starting value for this drill | Reason for the choice and comparison method |
|---|---|---|
| Search mode | Hybrid retrieval | The ticket contains both identifiers and natural language, so full-text and semantic recall are both used; compare recall coverage against semantic retrieval alone |
| Reference cap | 3000 tokens | The inquiry question and its reply deadline must stay in one block; compare against 2000 tokens for whether a single inquiry letter is covered completely |
| Minimum relevance | 0.3 | Takes effect only under semantic retrieval or reranking; compare against 0.5 for whether key remediation report items are dropped after filtering |
| Question optimization | Enabled | Follow-up questions such as "what is the second point" need completion; compare coreference resolution against the disabled state |
| Segmentation method | By document structure | Tickets, inquiry letters, and order evidence differ in structure; compare against fixed-length segmentation for whether conditions and constraints stay in one block |
| Index configuration | Text index plus image description index | Order evidence contains screenshots; compare against a text-only index for image query availability |
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 does not guarantee the vectors have been rebuilt.
- Treating a retrieval result as an authorization basis. A retrieval result or a form-collected value does not constitute business approval; submission of a remediation reply requires separate confirmation of authorization status.
- Treating minimum relevance as a permission or entity filter. That value only filters low-relevance results; it does not exclude unrelated businesses or unauthorized records.
How to verify the setup
- Input the delivery record for order A-5521 from the hypothetical sample and the draft sentence wording "delivered on time". Compare the signed receipt date of 7 March 2024 against the date of 5 March 2024 in the draft sentence. If retrieval returns that delivery record and the draft sentence date does not match the record, the draft sentence is judged to contradict the evidence.
- Input regulatory inquiry letter number JG-2024-112. Compare whether the retrieval result contains both the question list and the reply deadline of 10 April 2024. If both blocks appear in the same reference, segmentation satisfies completeness.
- Input the plain text query "order A-5521". Compare whether the returned result contains the text-indexed content from the order evidence. If the result is empty and the knowledge base has no image index configured, record that image query is unavailable, without inferring other failure causes.
These checks examine the named primary task of document chunking for product information and option-selection questions. They do not verify identity certification, report analysis, or any other task. Where the source text does not state a field, the field remains unknown. A pending request is not approval, an offered option is not execution, and an unsigned termination is not a completed termination.