What the data for this category looks like
Core data for this category is sourced from landing page access logs, heatmap data, form submission data, and advertising source parameters. Routinely processed documents include landing page plans, event tracking requirement documents, AB test reports, and form field lists. Data update frequency is weekly or per individual marketing campaign cycle. Fields cover page paths, dwell time, form submission status, advertising channel identifiers, and more. There is no unified fixed standard format, so adaptation adjustments are required based on specific campaign scenarios.
What constraints do these characteristics impose on the "reranking and hybrid retrieval" link
The multi-source mixed data and fragmented document structure of this category require the reranking and hybrid retrieval link to balance semantic matching and metadata filtering. The weekly or campaign-level update frequency limits the retrieval scope to the current campaign’s dataset, to avoid interference from invalid cross-cycle data. The presence of multiple field types requires retrieval to support custom weight configuration, prioritizing high-value conversion-related information such as form fields and page paths. The rapid response requirement in operations on-call scenarios requires the number of single-round retrieval results to be controlled within a reasonable range, to avoid excessive information increasing processing burdens for on-call personnel.
How to set configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
usingReRank | Enabled | The data sources for landing page conversion optimization include multiple document types, and reranking can improve the ranking priority of highly relevant content |
similarity | 0.62–0.78 | Adapts to the semantic similarity range required for precise matching of landing page paths, form fields, and other elements |
limit | Top 6–10 entries | Adapts to the rapid response needs of operations on-call, controlling the number of results returned per retrieval round |
searchMode | hybrid | Combines metadata (such as advertising source, campaign cycle) and semantic retrieval to match the characteristics of multi-source mixed data |
Three common misconfigurations
- Phenomenon: Reranking results are not displayed during online recall testing, and the interface prompts a request error. Cause: The reranking switch was not enabled during the knowledge base indexing phase, or the rerank model’s API address was configured incorrectly.
- Phenomenon: The number of retrieval results does not match the configured
limitparameter, with excess or insufficient results. Cause: The linkage logic between the retrieval recall upper limit and rerank output upper limit was not correctly associated, leading to parameter conflicts. - Phenomenon: The ollama-deployed rerank model displays the
Invalid URL (POST /v1/rerank)error in FastGPT. Cause: The rerank model’s API path was not configured as/v1/rerank, or the intermediate forwarding service rules did not correctly map this endpoint.
How to confirm the configuration is complete
- Access the knowledge base retrieval test page in FastGPT v4.17.0, enable the reranking switch, initiate a test, and check whether the sorting of returned results differs from when the switch is disabled.
- View the background rerank model call logs to confirm that corresponding POST requests and returned data exist, with no error prompts.
- Adjust the value of the
similarityparameter, and observe whether the relevance of retrieval results changes as expected. - Verify the configured
limitparameter, confirming that the number of returned results matches the set value.
The values provided here are common starting points and should be measured against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.