What the documents look like
This page covers the category of marketplace advertising and on-site traffic, with the specific task of product material and selection questions handled through vector models and indexes. The working documents are campaign plans, keyword reports, audience package descriptions, and conversion attribution tables. Sources named in the brief include Juliang Qianchuan, JD Kuaiche, Alimama, and store transaction data. Field naming and measurement definitions differ across these sources, so the actual content of each item needs to be confirmed before it enters a knowledge base.
The update rhythm is daily or hourly. That rhythm affects how quickly a campaign plan or keyword report changes, and it shapes how often the indexed content may need to be rebuilt. It does not by itself create any batch synchronization, full synchronization, real-time trigger, or transaction-triggered mechanism.
A vector model and index step takes these materials, splits them, and builds a retrievable association between vectors and original data so that selection questions can cite the corresponding passage. In FastGPT, the 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. In the dataset.datas table in MongoDB, original data is stored together with an indexes field that records the corresponding vector IDs as an array, so one data block can map to multiple vectors. PostgresSQL with the PG Vector plugin is used as the vector retriever with an HNSW index, and PostgresSQL is used only for vector retrieval. During retrieval, vectors are recalled first, then the original content is found in MongoDB by vector ID, and entries that map to the same original data are merged with the highest vector score kept.
Constraints at the vector indexes step
Knowledge bases associated for retrieval must use the same vector model. This requirement applies to the knowledge bases selected in the dataset search node. It does not extend to external systems such as business registration sites, and it does not mean those external systems must also use the same model.
Index content should be built from complete and focused information. Retrieval coverage and index length need to be weighed against samples. A single original data block can carry multiple indexes, and each index needs to be checked against the original content separately.
Image retrieval depends on whether image descriptions or image vectors were generated at ingestion time. It is not determined only by what happens on the query side. Whether an image can be retrieved depends both on the search-time input and on whether a corresponding index was built when the data was stored. The documented table of knowledge base capabilities shows that with a plain vector model and no vision model, image-only queries are basically unusable, while mixed text-image queries mainly use the text portion. With a vision model, images are converted to descriptions and then participate in text retrieval. With a vector model that supports images, image vector retrieval is available. With both, image description and image vector retrieval run as two paths.
Semantic recall and relevance do not handle permission or entity isolation. A relevance score is a filtering threshold, not a final ranking rule. It applies only in semantic retrieval or when result reranking is used. After question optimization, hybrid retrieval, image retrieval, or result reranking is enabled, final results may be fused from multiple recall paths and are not necessarily ordered strictly by a single vector similarity.
A hypothetical paper exercise sample: the source material reads "Campaign A-107 ran from March 1, 2025 to March 31, 2025, with a daily budget of 800 yuan, manual bidding, and target audience package P-22." A second sentence reads "The attribution basis for Campaign A-107 is 7 days after click." The draft sentence to be judged reads "A-107 used automatic bidding for the full month of March, with an attribution window of 1 day after click." The draft and the source take mutually exclusive values on two fields of the same subject: bidding method and attribution window. The draft is unsupported.
Configuration and implementation checks
| Configuration item | Setting for this page | How to check |
|---|---|---|
| Vector model | All collections in one knowledge base use the same vector model | Check the model identifier and input type, exclude those that do not match |
| Index association | Correspondence between original data blocks and the indexes array | Compare index IDs against original content |
| Index content | Length of segments from campaign plans, keyword reports | Use sample questions to observe recall coverage |
| Image index | Whether image descriptions or image vectors were generated at ingestion | Check ingestion records and model capability |
| Reference cap | Maximum tokens cited per search | For this exercise, a starting value of 3000 is assumed to cover several report segments; compare against a smaller value for citation completeness |
| Minimum relevance | A 0 to 1 filter threshold | Applies only in semantic retrieval or with result reranking |
The reference cap uses tokens rather than top k because in mixed knowledge bases the chunk lengths differ greatly, which makes top k results unstable. The 3000 figure above is a hypothetical starting point for this exercise, not an official default. The minimum relevance value is a filter threshold and does not serve as the final ranking rule.
Three common errors
- Associating knowledge bases that use different vector models. Input: two libraries with different model identifiers. Compare whether the identifiers match. Observable result: the identifiers do not match, so the mismatched library is excluded before retrieval, and cross-model retrieval is not executed.
- Treating a vector score as evidence of permission or entity isolation. Input: the same question and different audience package descriptions. Compare whether the returned passages fall within the authorized scope. Observable result: the score carries no permission information, so authorization must be checked separately.
- Treating the bidding method in the draft sentence as a verified fact. Input: the sample source text and the draft sentence. Compare the values on the same fields. Observable result: the values are mutually exclusive, so the draft is unsupported.
How to verify the setup
- Input the sample source text and the draft sentence. Compare the bidding method and attribution window fields. If the draft values are mutually exclusive with the source, the draft is unsupported. This is a paper check of proposed copy against supplied source wording.
- Input two libraries with different model identifiers. Compare the identifiers. If they differ, exclude the mismatched library and do not execute cross-model retrieval. Record the actual observation without asserting a recall outcome.
- Input a question with no image. Compare the retrieval path. If neither image description retrieval nor image vector retrieval is triggered, record this as not enabled, and do not infer its effect. An empty result can be checked against a downstream design using the explicit paper input []. Do not claim that a rule-based retrieval returns [] as a guaranteed outcome.
The dataset search node can be added repeatedly, has external input, has static configuration, and triggers execution. Its reference output is an array whose length can be 0, meaning the downstream path still runs when no content is retrieved. Whether question optimization, reranking, or image paths execute depends on the model capability and the settings in use. A pending request is not an approval, an offered option is not an execution, and an unsigned termination is not a completed termination.