What Data Looks Like for This Category
Typical data sources for this category include requirement research notes, PRD documents, user story lists, and requirement change orders. It also links to operations duty tickets, customer interview records, competitor public pages, and event tracking dashboards. Daily documents typically include fields such as requirement ID, business goal, acceptance criteria, and change records. Most updates occur weekly or per version release cycle. The data covers structured requirement entries and unstructured interview descriptions. Document formats and content weights vary widely across different sources.
Constraints Imposed by These Characteristics on Reranking and Hybrid Retrieval
Requirement analysis and PRD management data has diverse sources and mixed formats. Hybrid retrieval must cover both keyword matching and semantic relevance. It must balance recall accuracy across different document types. Document update frequency is high. The reranking step must prioritize linking to the latest requirement change orders and ticket content, to avoid using outdated requirement information. Single PRD documents have long content. The number of retrieved results must be kept within a reasonable range, to prevent context overflow that affects model understanding. Requirement-related questions have clear boundary conditions. The reranking step must filter out redundant content unrelated to the current query, to ensure retrieval results focus on business goals and acceptance criteria.
Configuration Settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
usingReRank | Enabled | Requirement analysis documents have multi-field associations; reranking can filter low-relevance recall results |
limit | Top 8–12 entries | Single PRD documents have long content; limiting recall count prevents context overflow |
similarity | 0.65–0.75 | Requirement-related questions have clear boundaries; filters irrelevant recall results below the threshold |
searchMode | hybrid | Combines keyword matching and semantic retrieval, adapts to the mixed characteristics of structured requirement entries and unstructured interview content in PRDs |
Three Common Mistakes
- After enabling
usingReRank, testing shows an error. Forcing the setup to run works in testing but fails in formal deployment. The cause is incorrect configuration of rerank model access permissions, which prevents normal retrieval of model results during formal calls. - When the reranking function is enabled, the status shows a cross mark. The cause is failure to correctly obtain the rerank model access token, or incorrect port mapping for the model service during container deployment.
- The number of results returned by hybrid retrieval does not match the set
limitvalue. The cause is a conflict between the initial recall volume during the recall phase and the filtering logic during the reranking phase, which causes valid results to be filtered out early.
How to Confirm Proper Configuration
- Navigate to the knowledge base configuration page in FastGPT v4.17.0, confirm that the
usingReRanktoggle is enabled. - Submit a test query that includes business goals or acceptance criteria, check if retrieval results include relevant content from PRDs and requirement change orders to verify hybrid retrieval performance.
- View rerank model call logs, confirm that the relevance scores of returned results match the
similaritythreshold setting. - Cross-check the final number of returned retrieval results, confirm that it matches the value set in the
limitconfiguration.
Note: The provided values are common starting points and should be validated against deployment-specific 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.