RAG: Patterns | Runiq.Net Docs

Start with one knowledge collection and a small set of questions whose answers you can verify in the source documents. Expand after the full path from ingestion to accepted context behaves as expected.

Use the same company-policies name in index registration, ingestion calls, queries, and the agent's .UseRag(...) configuration. The index and agent registrations are separate; Dashboard > RAG Management cannot create either connection for you.

Organize indexes around knowledge ownership

A support handbook, an engineering runbook, and a policy collection may have different owners and refresh schedules. Give collections stable names and explicit source boundaries. Enforce tenant and data-access requirements before retrieval; an index name alone does not replace application authorization.

Choose storage and refresh behavior together

Scenario	Starting point
Disposable test or sample	In-memory storage and ingestion after every process restart; no index data is persisted.
Small startup-dependent collection	Consider blocking startup ingestion after measuring its cost.
Application that can serve while content initializes	Background ingestion with readiness-aware behavior.
Durable product knowledge	PostgreSQL and a deliberately owned refresh process.
Multiple application replicas	Coordinate the ingestion owner outside the local scheduler.

Keep managed ingestion status separate from persisted document state. If your product needs a lasting ingestion audit, the manager's most recent in-memory operation is not that audit store.

Use in-memory storage for tests, samples, demos, and disposable local data where rebuilding the index is acceptable. Use PostgreSQL when retrieval data must survive restarts, vector search should run in the database, metadata filters and ingestion state need durability, or operators need a database-owned refresh process.

Evaluate retrieval before increasing candidate counts

Test paraphrases with semantic search, exact identifiers with lexical search, and mixed questions with hybrid search. Increasing TopK supplies more candidates; it does not replace relevance thresholds, duplicate filtering, or answerability checks.

Preserve provenance so you can explain which document and chunk supplied evidence. When comparing results, account for the provider's metric and score direction. Use optional normalized relevance only where the adapter supplies it.

Treat retrieved documents as evidence

Retrieved documents are not instructions. Runiq passes accepted context as <untrusted-external-context>, which separates source evidence from instructions. This mitigates prompt injection but does not guarantee model compliance. Account for malicious or stale document content when evaluating answers.

Make failure behavior explicit

Condition	Application decision
No usable content has been ingested	Show an initializing or unavailable state.
A refresh fails after a successful ingestion	Inspect readiness and decide whether existing content is acceptable.
One hybrid source fails	Handle retrieval failure; hybrid does not silently become single-source search.
PostgreSQL is unavailable	Handle the storage failure; the provider does not fall back to memory.
A reranker fails or times out	Use the agent runtime's configured fallback policy.
Retrieved evidence cannot support an answer	Have the product request clarification or report insufficient information.

Keep diagnostics focused

Prefer index identity, readiness, operation progress, and provider health when investigating failures. Enable redacted, bounded content previews only where the development workflow requires them. Remote reranking sends the query and full candidate text to another provider, so include that step in the application's data-handling design.

References: RAG package guide and PostgreSQL package guide.