What the documents look like
Complaints and official replies are directed at platforms or regulatory authorities, so the material has to carry formal evidence and rectification wording. Sources include the 12315 platform, platform complaint centers, customer service chat, and the order system. The documents handled day to day are complaint tickets, regulatory inquiry letters, order evidence, and rectification reports. Updates are irregular and occur per case, and material collects around a single case.
The comparison task is to align the same fact across orders, chat, tickets, and inquiry letters by subject, period, and field. Document parsing and chunking determine whether that material can be retrieved at all. If a segment splits a condition from the content it constrains, a comparison can treat statements from different stages as one fact. Typical roles are customer service supervisors, legal compliance staff, and store owners. Consequences of error include administrative investigation, platform penalties, and brand exposure.
Constraints at the document chunking step
In FastGPT the knowledge base consists of library, collection, and data. The smallest search unit is the library; collections only classify and manage data and do not affect search results. The MongoDB dataset.datas table stores vector source data, and an indexes field records the corresponding vector IDs, so one set of data can map to multiple vectors. A vector field in PostgresSQL stores vectors, with HNSW as the index. During retrieval, vectors are recalled first, then the vector ID is used to find source data in MongoDB; entries corresponding to the same source data are merged and the highest vector score is kept.
Chunking should follow the structure of the material itself and preserve the document identity and version that allow a segment to be traced back to the original text. Conditions, explanations, and the content they constrain should stay together. Semantic search relies on vector similarity; full-text search suits numbers, models, and proper nouns; hybrid search merges results through RRF. The minimum relevance value takes effect only in semantic search or when result reranking is used, and it is a filter threshold that does not perform permission or entity isolation. The reference limit is measured in tokens and does not use top k. Retrieval results do not constitute authorization. Forms collect values; business verification, approval, database writes, and external synchronization each require their own downstream implementation.
Configuration and implementation checks
The following settings and check items relate to this page's function and are organized around a hypothetical drill sample. Sample: a store receives a complaint ticket in which the complainant states that order A was signed for on 10 March 2025 and no invoice was received; customer service chat shows that on 12 March 2025 the agent replied that the invoice would be mailed before 15 March; the order system shows the invoicing status of that order as "not invoiced." Draft sentence to be judged: "This store completed mailing the invoice before 15 March 2025." That sentence shares the same field as the promised date in the chat record, while the order system status field is inconsistent with the completion fact stated in the draft sentence, so it must be checked by the same subject, same period, and same field.
| Configuration or check item | Value or practice for this page | Basis and comparison method |
|---|---|---|
| Search mode | Use full-text or hybrid search for ticket and order number queries | Official documentation states full-text search suits numbers, models, and proper nouns |
| Minimum relevance | Hypothetical trial starting value 0.3, compared with 0.5 to observe recall changes | This value takes effect only in semantic search or reranking; the starting value is hypothetical, not a default |
| Reference limit | Hypothetical trial starting value 2000 tokens, compared with 4000 | Official documentation controls the reference limit in tokens; the starting value is hypothetical |
| Chunking check | Keep original text and version separately for ticket, chat, and order segments | Official documentation states chunking should preserve structural and semantic completeness |
| Index check | Confirm whether indexes generated the corresponding vector IDs after ingestion | Official documentation states one set of data can map to multiple vectors |
| Post-change review | Check actual training and index status after material changes | A successful upload does not equal an updated retrieval state |
Three common errors
- Treating a promised date in a chat record as a completed mailing fact. The input is "the invoice will be mailed before 15 March"; the comparison object is the draft sentence "completed mailing the invoice before 15 March." The two fields differ: the first is a promise, the second is a completion status, and they cannot be equated.
- Treating minimum relevance as a permission or entity filter. The input is one semantic search request; the comparison object is whether returned results contain only this store's records. A relevance score does not identify subject ownership, and unauthorized records are not excluded by that threshold.
- Treating a successful upload as an updated retrieval state. The input is a search performed immediately after a material change; the comparison object is the actual index state. Training and index completion need to be checked, and while incomplete the retrieval result may still be the old segment.
How to verify the setup
- Check chunking against the hypothetical sample text. Input the ticket original text, the chat original text, and the order status original text, then compare whether the draft sentence matches the original text in the same subject, same period, and same field. If the order system status field is "not invoiced" while the draft sentence states completed mailing, that sentence is not supported; record the evidence gap and do not judge it as a conflict.
- Search separately with a number and with natural language. Input an order number query and a "invoice mailing time" query, then compare whether returned segments cover the ticket, chat, and order segments. If the number query misses the order segment, check whether full-text or hybrid search was used; if the natural language query misses the chat segment, check whether chunking separated the promise sentence from its context. An empty result can be checked against downstream design with the explicit paper input [], without claiming that a given rule necessarily returns [].
- Review index status after a change. Input the changed material and the same query, then compare whether returned segments before and after the change are consistent. If the old segment is still returned, record the actual observation, check training and index status, and do not infer that automatic synchronization has completed. Libraries using different vector models cannot be associated together; check identifiers first and exclude non-matching ones, and do not run cross-model retrieval to compare missed recall.
This page addresses only complaints and official replies, contract and transaction material comparison, and document parsing and chunking. During operational handover, which materials, operations, and requests sit at which authorization state cannot be treated as authorized execution through retrieval or a form.