This prompt is for RAG pipeline architects and search engineers who combine retrieval results from multiple backends—such as vector search, BM25 keyword search, and hybrid retrievers—and need a unified relevance scale to make downstream decisions. Each backend produces scores in its own distribution: cosine similarity might cluster between 0.7 and 0.95, while BM25 scores can span orders of magnitude. Without normalization, a passage scoring 0.8 from one source might be treated as equivalent to a passage scoring 0.8 from another, even when one is a near-perfect match and the other is marginal. The prompt takes raw scores, source metadata, and optional calibration samples, then outputs normalized scores on a consistent scale with cross-source calibration checks and outlier detection.
Prompt
Evidence Score Normalization Prompt Across Sources

When to Use This Prompt
Define the normalization job, the required inputs, and the production constraints that make this prompt necessary.
Use this prompt when you have at least two retrieval sources with incompatible score distributions and you need to merge or compare results before re-ranking, filtering, or answer generation. The prompt requires raw scores per passage, the source identifier for each score, and optional calibration data such as known-relevant and known-irrelevant score samples from each source. Do not use this prompt when you have a single retrieval source with a well-understood score distribution, when you can apply a fixed mathematical transform such as min-max scaling or z-score normalization without model reasoning, or when latency constraints require sub-50ms decisions that a model call cannot meet. For single-source pipelines, a deterministic normalization function in application code is faster, cheaper, and more predictable.
Before deploying this prompt, validate its output against a held-out set of passages with known relevance judgments across sources. Common failure modes include over-normalizing sparse score ranges into a narrow band where all passages appear equally relevant, misidentifying legitimate high-variance sources as outliers, and producing calibration recommendations that drift when source score distributions shift after index updates. Wire the prompt into a batch processing step that runs after retrieval and before re-ranking, with logging that captures raw scores, normalized scores, and any outlier flags for offline analysis. If the normalization output feeds directly into answer generation or user-facing ranking, add a human review gate for the first production week to confirm that cross-source score alignment matches human relevance expectations.
Use Case Fit
Where the Evidence Score Normalization Prompt works well and where it introduces risk. Use these cards to decide if this prompt fits your retrieval pipeline before integrating it.
Good Fit: Multi-Backend Retrieval Pipelines
Use when: Your RAG system combines results from vector search, BM25, and hybrid retrievers with incompatible score distributions. Guardrail: The prompt expects raw scores and backend identifiers as input; feed it structured retrieval metadata, not just text passages.
Bad Fit: Single-Retriever Setups
Avoid when: You only use one retrieval backend with a consistent scoring function. Risk: Normalization adds latency and complexity without benefit when score distributions are already comparable. Guardrail: Use direct relevance scoring prompts instead.
Required Input: Raw Scores with Source Labels
What to watch: The prompt cannot normalize scores without knowing which backend produced each score. Guardrail: Always include a source identifier and the original score for every passage. Missing source labels produce unreliable normalization.
Operational Risk: Score Distribution Drift
Risk: Retrieval backends change their scoring behavior after model updates or index rebuilds, breaking normalization assumptions. Guardrail: Run calibration checks weekly and monitor normalized score distributions for sudden shifts. Trigger re-calibration when drift exceeds thresholds.
Good Fit: Cross-Source Calibration Audits
Use when: You need auditable evidence of fair comparison across retrieval sources for compliance or debugging. Guardrail: The prompt includes outlier detection and calibration check outputs. Log these alongside normalized scores for downstream audit trails.
Bad Fit: Real-Time Latency-Sensitive Systems
Avoid when: Your system requires sub-100ms retrieval-to-response pipelines. Risk: LLM-based normalization adds latency that may violate user-facing SLAs. Guardrail: Pre-compute normalization mappings offline or use statistical normalization for latency-critical paths.
Copy-Ready Prompt Template
A reusable prompt that normalizes raw retrieval scores from multiple backends into a unified, calibrated evidence score with outlier detection.
The prompt below is designed to be dropped into a RAG pipeline after retrieval but before evidence selection. It accepts a list of passages from different sources—each with its own raw score distribution—and normalizes them onto a common 0–1 scale. The template includes placeholders for the passages, their source identifiers, raw scores, and any domain-specific calibration rules. Use it when your retrieval architecture combines vector search, BM25, and hybrid retrievers that produce incomparable score ranges.
textYou are an evidence score normalization engine for a multi-source retrieval pipeline. Your job is to convert raw retrieval scores from different backends into a unified 0–1 relevance scale, detect outliers, and flag calibration risks. ## INPUT [PASSAGES] Each passage includes: - `passage_id`: unique identifier - `source`: retrieval backend name (e.g., vector_search, bm25, hybrid) - `raw_score`: the original score from that backend - `text`: the passage content - `query`: the user's original query ## NORMALIZATION RULES 1. For each source, estimate the observed score distribution from the provided passages and normalize to 0–1 using min-max scaling within that source. 2. If a source has fewer than [MIN_PASSAGES_PER_SOURCE] passages, apply a conservative penalty of [SPARSE_SOURCE_PENALTY] to all normalized scores from that source. 3. After per-source normalization, apply cross-source calibration: if one source's normalized scores are systematically higher than others for passages with similar semantic relevance, apply a calibration shift of up to [MAX_CALIBRATION_SHIFT]. 4. Flag any passage whose normalized score is more than [OUTLIER_STD_THRESHOLD] standard deviations above its source mean as a potential outlier. ## OUTPUT SCHEMA Return a JSON object with this structure: { "normalized_passages": [ { "passage_id": "string", "source": "string", "raw_score": number, "normalized_score": number, "calibration_adjustment": number, "is_outlier": boolean, "outlier_reason": "string or null" } ], "source_statistics": { "[source_name]": { "count": number, "raw_min": number, "raw_max": number, "normalized_mean": number, "normalized_std": number } }, "calibration_notes": ["string"], "warnings": ["string"] } ## CONSTRAINTS - Do not invent or modify passage text. - If a source has only one passage, set its normalized score to [DEFAULT_SINGLE_PASSAGE_SCORE] and add a warning. - If the raw score range for a source is zero (all identical scores), assign all passages from that source a normalized score of [UNIFORM_SCORE_DEFAULT] and add a warning. - Preserve all input passage_ids exactly. ## RISK_LEVEL [HIGH] — Downstream answer generation depends on these normalized scores. Incorrect normalization can promote irrelevant evidence or suppress critical context.
Adaptation guidance: Replace the square-bracket placeholders with your pipeline's specific thresholds. [MIN_PASSAGES_PER_SOURCE] should reflect the minimum sample size you trust for distribution estimation—typically 5–10. [SPARSE_SOURCE_PENALTY] is a multiplier like 0.8 that down-weights scores from under-sampled sources. [OUTLIER_STD_THRESHOLD] is usually 2.0–3.0. [MAX_CALIBRATION_SHIFT] prevents over-correction; start with 0.15. [DEFAULT_SINGLE_PASSAGE_SCORE] and [UNIFORM_SCORE_DEFAULT] are fallback values—0.5 is a neutral default. Before deploying, run this prompt against a golden dataset where you know the correct relative ordering of passages across sources, and measure whether the normalized scores preserve that ordering. If your domain has known authority hierarchies (e.g., academic sources should rank above web forums), add a post-normalization authority boost as a separate step rather than baking it into this normalization prompt.
Prompt Variables
Required inputs for the Evidence Score Normalization Prompt Across Sources. Each placeholder must be populated before the prompt is assembled and sent to the model. Validation notes describe how to verify the input is well-formed before execution.
| Placeholder | Purpose | Example | Validation Notes |
|---|---|---|---|
[SOURCE_A_RESULTS] | Raw scored results from the first retrieval backend, including passage text and native score | [{"id":"vec_1","text":"...","score":0.92},{"id":"vec_2","text":"...","score":0.78}] | Must be valid JSON array with id, text, and score fields. Score must be numeric. Empty array allowed but triggers insufficient-evidence path. |
[SOURCE_B_RESULTS] | Raw scored results from the second retrieval backend with incompatible score distribution | [{"doc_id":"kw_15","content":"...","bm25":23.4},{"doc_id":"kw_7","content":"...","bm25":18.1}] | Must be valid JSON array. Score field name may differ from SOURCE_A. Validate that score values are numeric and non-null. Empty array allowed. |
[SOURCE_A_SCORE_FIELD] | Field name containing the native score in SOURCE_A_RESULTS objects | score | Must match an actual numeric field in SOURCE_A_RESULTS. Check with JSON path existence before prompt assembly. |
[SOURCE_B_SCORE_FIELD] | Field name containing the native score in SOURCE_B_RESULTS objects | bm25 | Must match an actual numeric field in SOURCE_B_RESULTS. Validate field exists and contains numeric values across all records. |
[NORMALIZATION_METHOD] | Specifies the normalization strategy to apply across score distributions | min-max | Must be one of: min-max, z-score, rank-percentile, or quantile. Reject unknown values before prompt execution. Method choice affects outlier sensitivity. |
[TARGET_SCALE] | The unified output score range after normalization | {"min":0.0,"max":1.0} | Must be valid JSON with numeric min and max where max > min. Typical ranges: 0-1, 0-100, or -1-1. Validate bounds are finite numbers. |
[OUTLIER_THRESHOLD] | Z-score or percentile threshold for flagging anomalous scores during normalization | 2.5 | Must be a positive float. Null allowed to disable outlier detection. When enabled, values exceeding threshold should trigger outlier flag in output rather than silent clipping. |
[CROSS_SOURCE_CALIBRATION] | Boolean flag enabling cross-source calibration checks to detect systematic score distribution mismatches | Must be true or false. When true, prompt includes calibration diagnostic output. When false, normalization proceeds without cross-source comparison. Recommend true for initial pipeline setup. |
Common Failure Modes
Normalizing evidence scores across disparate retrieval backends introduces specific failure patterns. These cards identify the most common breaks and the operational guardrails to prevent them.
Score Distribution Collapse
What to watch: When one backend (e.g., vector search) returns scores tightly clustered between 0.85–0.95 and another (e.g., keyword BM25) returns scores spread across 0.10–0.90, naive min-max normalization compresses the first backend's scores into near-identical values, destroying its ranking signal. Guardrail: Apply backend-specific z-score normalization before cross-source scaling, and log pre- and post-normalization distribution statistics per source to detect variance collapse.
Outlier Score Dominance
What to watch: A single anomalously high score from one retriever can shift the entire normalized range, causing all other passages to be scored near zero and effectively excluded from downstream selection. This is common when a keyword match returns a perfect lexical hit while semantic scores are moderate. Guardrail: Implement winsorization at the 95th percentile before normalization, and flag any passage whose raw score exceeds the source's mean by more than three standard deviations for separate review.
Cross-Source Scale Mismatch
What to watch: Vector similarity scores (cosine distance) and keyword relevance scores (TF-IDF or BM25) have fundamentally different mathematical properties and ranges. Treating them as directly comparable produces rankings where one source systematically dominates, regardless of actual relevance. Guardrail: Calibrate each source's scores against a shared relevance benchmark using a held-out query set with human judgments, then fit per-source mapping functions to a common 0–1 relevance scale before merging.
Empty Result Set Handling
What to watch: When one backend returns zero results, normalization logic that assumes non-empty input can divide by zero, assign default scores that inadvertently promote irrelevant passages from other backends, or crash the pipeline entirely. Guardrail: Add explicit pre-normalization checks for empty result sets per source, assign a sentinel score of 0.0 with a source_empty flag, and ensure downstream selection logic treats empty-source passages as ineligible rather than defaulting to mid-scale.
Normalization Drift Over Time
What to watch: Score distributions shift as document corpora grow, retrieval indexes are rebuilt, or embedding models are updated. A normalization calibration performed last month may silently degrade, causing systematic over-weighting or under-weighting of certain sources. Guardrail: Schedule recurring calibration runs against a stable evaluation set, monitor per-source score distribution metrics in production, and trigger alerts when the Kolmogorov-Smirnov distance between current and baseline distributions exceeds a configured threshold.
Over-Normalization Erasing Confidence Signal
What to watch: Aggressive normalization that forces all sources onto an identical score distribution strips away the model's own confidence signal. A passage that the retriever was highly uncertain about becomes indistinguishable from one it was confident about, removing useful information for downstream abstention or re-query decisions. Guardrail: Preserve the original raw score and source identifier alongside the normalized score, and include a score_confidence field derived from the pre-normalization distribution percentile to retain uncertainty information for downstream consumers.
Evaluation Rubric
Use this rubric to test whether the Evidence Score Normalization Prompt produces calibrated, auditable, and production-safe outputs before integrating it into a multi-source RAG pipeline.
| Criterion | Pass Standard | Failure Signal | Test Method |
|---|---|---|---|
Unified Scale Adherence | All normalized scores fall within the specified [TARGET_RANGE] (e.g., 0.0 to 1.0) with no raw-source leakage. | Output contains raw scores outside the target range or retains original source-specific scales. | Schema validation: parse every score field, assert min >= [TARGET_MIN] and max <= [TARGET_MAX]. |
Cross-Source Calibration | Passages with equivalent relevance from different sources receive normalized scores within a [CALIBRATION_TOLERANCE] (e.g., ±0.1) of each other. | A highly relevant vector result scores 0.4 while an equally relevant keyword result scores 0.9, indicating source bias. | Pairwise comparison: select anchor passage pairs from different sources with known equivalent relevance, assert score difference <= [CALIBRATION_TOLERANCE]. |
Outlier Detection Flagging | Prompt correctly flags passages where the normalized score is an outlier relative to the retrieval set distribution. | A passage with a z-score > 3.0 is not flagged, or a passage within 1 standard deviation is incorrectly flagged. | Statistical check: compute z-score for each normalized score, assert flag is |
Score Justification Completeness | Every normalized score includes a non-empty [JUSTIFICATION] field explaining the calibration adjustment applied. | [JUSTIFICATION] field is missing, null, or contains only generic text like 'score normalized'. | Field presence check: assert [JUSTIFICATION] exists, is a string, and length > [MIN_JUSTIFICATION_LENGTH]. |
Source Traceability | Output preserves a [SOURCE_ID] and [RAW_SCORE] for every passage, linked to the normalized score. | Normalized scores are returned without mapping back to the original source or raw score, breaking audit trail. | Join check: assert every normalized score row has a corresponding [SOURCE_ID] and [RAW_SCORE] present in the input set. |
Distribution Shape Preservation | The relative ordering of passages by normalized score preserves the rank order of the raw scores within each source. | A passage with a higher raw score receives a lower normalized score than a passage from the same source with a lower raw score. | Rank correlation: compute Spearman's rank correlation between raw and normalized scores per source, assert rho >= [MIN_RHO] (e.g., 0.95). |
Calibration Method Disclosure | Output includes a [CALIBRATION_METHOD] field describing the normalization technique applied (e.g., min-max, z-score, Platt scaling). | [CALIBRATION_METHOD] is missing, or describes a method inconsistent with the actual score transformation observed. | Field presence and consistency check: assert [CALIBRATION_METHOD] is non-empty and matches the expected method for the pipeline configuration. |
Low-Confidence Handling | When the model cannot reliably calibrate a score (e.g., due to insufficient distribution data), it sets [CONFIDENCE] below [CONFIDENCE_FLOOR] and does not assert a precise normalized value. | Model assigns a precise normalized score with high confidence when only one passage exists from a source, making calibration unreliable. | Boundary test: provide a single passage from a source, assert [CONFIDENCE] < [CONFIDENCE_FLOOR] and [NORMALIZED_SCORE] is null or flagged as unreliable. |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Troubleshooting and Edge Cases
Common failure modes, debugging strategies, and edge-case handling for evidence score normalization across heterogeneous retrieval sources.
Check for source-specific score inflation before normalization. Some retrievers (e.g., keyword BM25) produce scores on different distribution shapes than vector cosine similarity. Run a pre-normalization distribution audit: compute mean, variance, and skew per source on a calibration sample. If one source's raw scores are compressed into a narrow high range, apply source-specific z-score normalization before the cross-source calibration step. Also verify that your calibration pairs are balanced—if 80% of calibration queries favor one source, the normalization will inherit that bias.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us