Financial Research Dashboard Retrieval — Query Limits, Chunking, and Freshness

To set retrieval query limits for a financial research dashboard, the product boundary should be the guiding factor rather than an arbitrary number. Start by defining the user-visible answer and then work backward to create a retrieval contract. This contract should include the selected collection, the retrieval unit, metadata filters, freshness requirements, a cap on candidate count, and the preservation of source context in the result.

If filter leaves too few candidates, it's safer to return fewer traceable passages than to silently widen the financial query.

Separate the retrieval process into distinct stages: ingestion, querying, and answer generation. Each stage should have its own observable input and output. Set an application limit, such as 20 candidates before reranking, while still displaying only the citations that are actually used. This is different from claiming the maximum capacity of any service.

The definition of "fresh" for your dashboard will depend on measurable product SLA terms, such as the source timestamp controlling eligibility, the time required for an update to become searchable, and whether superseded chunks can ever appear. Until these are defined, "near real-time" should be considered more of an aesthetic choice.

Regarding source versioning, use a combination of the source ID, version, chunk ordinal, and ingestion timestamp. This deterministic identity ensures that old and new passages do not mingle while the replacement is being prepared. Only publish the new generation after the ingestion stage completes and retain the prior generation according to the system's rollback policy.

Treat HTTP 429 as flow control by honoring the Retry-After header when present, otherwise use exponential backoff. For writes, include an idempotency key or deterministic client ID to prevent the same logical update from being applied multiple times. Lastly, before comparing operating contracts, consider the amount of retrieval-specific infrastructure the team wants to own, the portability boundary needed, and the evidence that can be collected during evaluation.