What the documents look like
Customer-service knowledge base maintenance covers FAQ entries, script templates, product parameter tables and escalation tickets. It is preparation of question-and-answer material, and it does not directly approve refunds. In the contract and transaction material comparison task, the material that enters the knowledge base commonly includes quotation sheets, order confirmation information, after-sales commitments and escalation ticket records. These materials carry version differences, missing fields and undetermined states.
In FastGPT, a knowledge base consists of library, collection and data. A collection can be understood as a file. A library contains multiple collections, and a collection contains multiple groups of data. The smallest search unit is the library: a knowledge base search runs against the whole library, while collections only classify data and do not affect search results. MongoDB's dataset.datas table stores the original data of vectors, and its indexes field records the corresponding vector IDs, so one group of data can map to multiple vectors. PostgresSQL stores vectors in a vector field. Retrieval recalls vectors first, then uses the vector IDs to find the original data in MongoDB; entries that map to the same group of original data are merged, and the vector score takes the highest value. The quality of parsing and chunking therefore directly determines whether later comparison can obtain complete material.
Constraints at the document chunking step
First, material identity and version must remain traceable to the source text. Contract and transaction material comparison requires the same subject, the same period and the same field. If parsing splits apart the subject, the object, the status or the validity scope, later comparison loses its basis for judgment.
Second, chunk completeness takes priority over chunk count. A passage whose structure and meaning are complete and singular yields higher precision. When a condition, an explanation or a qualification is separated from the content it constrains, the result answers the wrong question.
Third, original data and indexes must be distinguished. One group of original data can correspond to multiple indexes. Enriching the number of indexes can improve precision, while reducing index content sacrifices retrieval scope and suits scenarios with strict answers.
Fourth, after an update, a successful upload does not mean retrieval has been updated. The actual training and index status must be checked.
Fifth, retrieval returns content and does not perform authorization judgment. The minimum relevance score is a filtering threshold, not a permission or entity isolation mechanism. A similarity setting cannot exclude unrelated businesses or unauthorized records. The same-model retrieval association condition means libraries using different vector models cannot be associated together; the check is to verify model identifiers, exclude those that do not match and record the actual observation.
Configuration and implementation checks
The configuration below centers on a hypothetical drill sample for this page. It lists only settings documented in the official material or implementation check items. Hypothetical drill sample: a customer-service knowledge base operator, on 10 March 2025, organizes one escalation ticket. The source text reads: "Customer A submitted order B on 1 March 2025. Quotation sheet C states a unit price of 120 yuan and a validity period ending 31 March 2025. The ticket status is pending review. No signing or contract-effective information is recorded." The draft sentence to be assessed is: "Order B has been signed and has taken effect under quotation sheet C." In this sample, the subject, the object, the status and the validity scope are all stated, while signing and effectiveness information is not stated.
| Configuration item | Setting or check item relevant to this page | Relation to the sample |
|---|---|---|
| Search mode | Semantic retrieval, full-text retrieval or hybrid retrieval | Numbers and status fields suit full-text retrieval; natural-language descriptions suit semantic retrieval |
| Reference limit | Each search references at most n tokens of content | Controls the total material returned to the model and avoids long unrelated passages |
| Minimum relevance | A 0-1 value, effective only in semantic retrieval or with result reranking | Filters low-relevance results and cannot replace authorization judgment |
| Question optimization | Coreference resolution and question expansion before retrieval | Completes the subject in follow-up turns and adds one model call and latency |
| Result reranking | ReRank secondary sorting with a 0-1 score | Improves text relevance when candidates are numerous; requires a model and must be enabled by setting |
| Chunking check | Check whether conditions, explanations and the content they constrain stay in one chunk | In the sample, the status and validity period must stay in the same chunk as the subject |
The starting point for this hypothetical trial: minimum relevance set to 0.5, because the sample fields are explicit and the candidate range is small. It is compared with 0.3 and 0.7 to observe whether the returned passage still contains the original text of the pending-review status. This value is a hypothetical trial starting point, not an official default.
Three common errors
- First, treating a retrieval hit as evidence of authorization or effectiveness. The input is the sample source text and the draft sentence. The comparison is between the draft sentence "has been signed and has taken effect" and the source text "pending review, no signing or contract-effective information recorded." The observable result is that the source text does not state signing or effectiveness, so the draft sentence is unsupported. Treating retrieval of this ticket as completed signing is an error.
- Second, associating libraries that use different vector models. The input is the model identifiers of two libraries. The comparison is whether the identifiers match. The observable result is that when the identifiers differ, the libraries cannot be associated. At this point only the identifiers are checked, non-matching ones are excluded, and the actual observation is recorded. No cross-model retrieval is executed to compare missed recalls.
- Third, treating a successful upload as an updated index. The input is the upload record and training status after a material change. The comparison is between the upload time and the index status. The observable result is that a successful upload does not mean retrieval has been updated. The actual training and index status must be checked, and any gap is recorded as missing.
How to verify the setup
- Verification one: input the sample source text and the draft sentence; compare whether the draft sentence exceeds what the source text states; the observable result is that the signing and effectiveness claimed in the draft sentence are not stated in the source text, so the judgment is unsupported or pending verification, and it is not called a denial or a conflict.
- Verification two: input the subject, the object, the status and the validity scope in the sample source text; compare whether each field can still be traced back to the source text after chunking; the observable result is that the status "pending review" and the validity period "ending 31 March 2025" must stay in the same chunk as the subject, and separation fails the condition.
- Verification three: input the paper empty result
[]; compare whether the downstream design distinguishes an empty result from unauthorized access and from no match; the observable result is that the empty-result handling must be defined as returning no content, cannot claim that a fictional rule retrieves[]with certainty, and cannot treat an empty result as a permission conclusion.
All three verifications describe expectations and observation methods only, and no actual test is claimed. Retrieval checks state observations and failure branches, and do not guarantee a first hit, full recall or an empty result for unrelated queries.