What the documents look like
Inventory-procurement and supplier records sit inside customer-service knowledge-base maintenance as preparatory question-and-answer material. They do not approve refunds or returns. The usual sources are the customer-service system, product detail pages, after-sales issue statistics, and quality spot checks. Day-to-day documents include FAQ entries, reply templates, product parameter tables, and escalation tickets. The people who handle them include customer-service supervisors, knowledge-base operators, and product operators. Errors produce mismatched answers, escalated complaints, and failed agent training. The supplied brief gives weekly and monthly update frequencies; this page does not derive batch synchronization, full synchronization, real-time processing, or transaction-triggered updates from them. The most time-consuming steps are consolidating frequent questions, rewriting standard replies, and synchronizing new-product parameters.
For the vector-model-and-index step, these characteristics mean that several things need to be checked together: the model identifier, the correspondence between original data and indexes, the quality of index content, and whether image descriptions or image vectors were generated at ingestion time.
Constraints at the vector indexes step
Knowledge-base search can select one or more knowledge bases that use the same vector model, so the actual model and input type are checked first. One original data block can be associated with multiple indexes, and the indexes and the original text content are checked separately. Index content is built from complete and focused information, and retrieval coverage and index length are weighed against the sample. Image retrieval also depends on whether image descriptions or image vectors were generated at ingestion; the query side alone does not settle it. After a model or index change, the same set of questions is used to compare cited original text, and vector scores alone do not support a performance commitment.
FastGPT uses the PostgresSQL PG Vector plugin as the vector retriever, with HNSW as the index. MongoDB stores vector original data in the dataset.datas table, and an indexes field records the corresponding vector IDs. During retrieval, vectors are recalled first, then the vector IDs are used to find original data in MongoDB; entries corresponding to the same original data are merged, and the vector score takes the highest value. Hybrid retrieval merges multiple result paths through RRF, Rerank performs a second ordering, and the minimum relevance value takes effect only in semantic retrieval or when result reordering is used. The citation limit controls the maximum tokens cited per search. Knowledge bases that use different vector models cannot be associated together; the identifiers are checked, non-matching ones are excluded, and the actual observation is recorded.
Configuration and implementation checks
The table below lists officially described settings or implementation checks relevant to this feature and the main task, organized around a hypothetical drill sample. The values are starting points for this hypothetical trial only and are not official defaults.
| Configuration or check | Hypothetical trial starting point and reason | Comparison method |
|---|---|---|
| Vector model of the associated knowledge base | The sample knowledge base is labelled vector model A, to check the same-model requirement | Compare item by item with the model identifier of the knowledge base to be associated; exclude association when identifiers differ |
| Original data and index correspondence | Sample original data block S-01, with two index groups recorded in the indexes field | Open S-01 in dataset.datas and check the length of the indexes array and the index content |
| Index content length | Sample index text of about 80 characters, to observe retrieval coverage | Compare with another index of about 200 characters in the same knowledge base for completeness of recalled content |
| Image index creation | The sample was ingested without generating an image vector index | Check whether the ingestion record contains an image description or image vector; uploading an image on the query side does not create one retroactively |
| Search mode | The sample uses hybrid retrieval, to observe RRF merging | Compare cited original text with the result of semantic retrieval alone |
| Citation limit | The sample is set to 2000 tokens, to observe trimming | Compare the number of cited items with the same question at 1000 tokens |
Three common errors
- Treating multiple indexes of the same original data block as multiple original data blocks. Input is the indexes array of S-01 in dataset.datas; the comparison is between the vector IDs inside the array and the original data ID; the observable result is that the same original data ID is counted twice or missed.
- Treating an image uploaded on the query side as an image index already created at ingestion. Input is a pure-image query and the ingestion record; the comparison is whether an image description or image vector was generated at ingestion; the observable result is that the query side has an image but retrieval has no corresponding index.
- Treating the minimum relevance value as a permission or entity filter. Input is the minimum relevance setting and the recalled results; the comparison is the original text of the filtered content; the observable result is that unrelated business or unauthorized records can still enter the candidate set, because retrieval does not perform authorization.
How to verify the setup
The verification below uses a hypothetical drill sample and does not claim that it was actually tested. The sample original text is: "Supplier A's quotation number Q-2024-017, valid until 30 June 2024; inventory purchase order PO-2024-088 corresponds to product parameter table version V3." The proposed draft sentence is: "Supplier A's quotation is valid until 30 June 2024, and purchase order PO-2024-088 has been executed according to the V3 parameter table." The pending request is: "Please confirm that this quotation covers the supply period of PO-2024-088."
- Input the proposed draft sentence and the sample original text; compare the two fields of quotation validity period and supply period. The sample original text states only the quotation validity period and does not state a supply period; the observable result is that the part of the draft sentence about the supply period is unsupported, and the evidence gap must be recorded.
- Input the pending request and the sample original text; compare the request subject, object, and authorization scope. The request asks to confirm that the quotation covers the supply period, and the sample original text has no supply-period field; the observable result is that the request remains pending verification and cannot be treated as approved or executed.
- Input the sample original text and the associated knowledge-base model identifier; compare whether the model identifiers match. If the knowledge base to be associated is labelled vector model B, the observable result is that the two cannot be associated together, so that knowledge base is excluded and the actual observation is recorded; if the identifiers match, index content can be checked next. An empty result can carry an explicit paper input of [] for checking the downstream design.
This page addresses only customer-service knowledge-base maintenance / inventory-procurement and supplier records / vector models and indexes. During operational handover, the authorization state of materials, operations, and requests must be tracked, and retrieval or forms must not be treated as authorization execution.