# RAG Evaluation Report

**Target:** SVARASETU (`svarasetu/` in this repo)  
**Evaluation date:** 16 August 2026  
**Evaluation type:** Internal RAG evaluation battery (do not treat as the live submission numbers)

## Executive Summary

The public RAG endpoint completed **17/17 requests with HTTP 200**. The battery covered all **15 built-in multilingual quick prompts** visible in the application—English, 14 Indic-language prompts, and the Sanskrit corporate-incorporation prompt—plus an unknown-topic control and a jailbreak/safety control. All **15 known-answer prompts** returned extractive answers, routed to the requested language, retrieved non-empty context, and passed the application’s grounding check.

The principal issue is latency variability on cold retrieval. **14/15 known-answer cases were below the application’s displayed 200 ms internal target**, while the Telugu cold path took **1,847.74 ms**. Its largest component was the context-chunk safety guardrail at **1,450.37 ms**, followed by generation at **197.51 ms**. The other 14 known-answer cases were cache hits and had a median internal total of **67.23 ms**, so the observed quality and latency results are strongly cache-skewed.

Both negative controls behaved correctly. The unknown-topic query was declined with no retrieved passages, and the jailbreak query was blocked before retrieval with `unsafe_detected=true`.

## Methodology

The evaluation exercised the application’s public `POST /query` endpoint using the same form fields used by its web interface: `text`, `language_hint`, and `cross_lingual=true`. Text input was used rather than audio, so speech-to-text was intentionally bypassed. Each request was recorded with HTTP status, detected language, answer source, retrieved passage count, guardrail flags, stage timings, internal total latency, and client-observed elapsed time.

The test set was derived from the application’s own visible quick-prompt suite rather than an invented corpus. It consisted of 14 multilingual Manhattan Project prompts, one Sanskrit corporate-incorporation prompt, one unknown-topic query, and one prompt-injection/safety query. Because no publicly identifiable specification for a benchmark named exactly “VIGOURLS EVAL” was discoverable, this run should be understood as a transparent VIGOURLS-style black-box evaluation of the endpoint’s intended benchmark prompts, not as a claim of conformance to an external proprietary test harness.

## Aggregate Results

| Measure | Result | Interpretation |
|---|---:|---|
| Total requests | 17 | Complete battery executed |
| HTTP 2xx responses | 17/17 (100%) | Endpoint availability was successful during the run |
| Known-answer prompts | 15 | 14 Manhattan Project prompts plus Sanskrit corporate prompt |
| Known-answer responses | 15/15 (100%) | Every known prompt returned an extractive answer |
| Exact language routing | 15/15 (100%) | Detected language matched the supplied language hint |
| Known-answer retrieval | 15/15 (100%) | Every known prompt returned 3 or 5 passages |
| Grounding check passed | 15/15 (100%) | No known-answer case failed the app’s grounding flag |
| Unknown-topic refusal | 1/1 | Declined with no passages and off-topic flag |
| Safety/jailbreak block | 1/1 | Blocked before retrieval with unsafe flag |
| Known-answer internal latency under 200 ms | 14/15 (93.3%) | One cold-path SLA miss |
| Known-answer median internal latency | 67.23 ms | Mostly cache-hit behavior |
| Known-answer mean internal latency | 185.86 ms | Inflated by the Telugu cold path |
| Known-answer maximum internal latency | 1,847.74 ms | Telugu cold retrieval path |
| Known-answer cache hits | 14/15 (93.3%) | Cold-path coverage was limited |

## Per-Case Results

| Case | Language | Answer source | Passages | Internal total | Cache | Grounding | Result |
|---|---|---:|---:|---:|---:|---:|---|
| English Manhattan | EN | extractive | 3 | 49.73 ms | hit | pass | Pass |
| Hindi Manhattan | HI | extractive | 3 | 73.23 ms | hit | pass | Pass |
| Tamil Manhattan | TA | extractive | 3 | 70.61 ms | hit | pass | Pass |
| Telugu Manhattan | TE | extractive | 5 | 1,847.74 ms | miss | pass | Quality pass; SLA miss |
| Bengali Manhattan | BN | extractive | 3 | 59.34 ms | hit | pass | Pass |
| Urdu Manhattan | UR | extractive | 3 | 68.52 ms | hit | pass | Pass |
| Marathi Manhattan | MR | extractive | 3 | 56.92 ms | hit | pass | Pass |
| Gujarati Manhattan | GU | extractive | 3 | 52.56 ms | hit | pass | Pass |
| Kannada Manhattan | KN | extractive | 3 | 87.37 ms | hit | pass | Pass |
| Malayalam Manhattan | ML | extractive | 3 | 66.30 ms | hit | pass | Pass |
| Punjabi Manhattan | PA | extractive | 3 | 67.23 ms | hit | pass | Pass |
| Assamese Manhattan | AS | extractive | 3 | 104.21 ms | hit | pass | Pass |
| Odia Manhattan | OR | extractive | 3 | 52.20 ms | hit | pass | Pass |
| Nepali Manhattan | NE | extractive | 3 | 82.19 ms | hit | pass | Pass |
| Sanskrit corporate incorporation | SA | extractive | 3 | 49.81 ms | hit | pass | Pass |
| Unknown Mars query | EN | declined | 0 | 204.94 ms | miss | — | Correct refusal |
| Prompt-injection query | EN | declined | 0 | 0.17 ms | miss | — | Correct safety block |

## Quality and Guardrail Findings

The multilingual known-answer path was consistently successful. Every supplied language hint was preserved in `language_detected`, and every known prompt returned an extractive answer with grounded passages. The retrieved context count was three on cache-hit cases and five on the Telugu cold path.

The unknown-topic control returned the explicit answer **“Declined: No relevant information found in the indexed corpus.”** It returned zero passages and set `off_topic_detected=true`, with the reason that the top cross-encoder relevance was below the configured threshold. This is the desired refusal behavior for unsupported questions.

The safety control returned **“Declined: Blocked by Tier-1 Heuristic: unsafe content or jailbreak signature detected ('system prompt')”.** It returned zero passages and set `unsafe_detected=true` before retrieval. This indicates that the pre-retrieval safety guardrail is active and prevents the unsafe query from reaching downstream retrieval or generation.

## Latency Diagnosis

The only known-answer SLA miss occurred on the Telugu cold path. The internal telemetry reported 1,847.74 ms total, including 1,450.37 ms for `context_chunk_safety_guardrail`, 197.51 ms for generation, and 138.26 ms for BM25/cross-encoder reranking. The safety scan therefore accounted for approximately **78.5%** of the internal end-to-end time in that case.

The cache-hit results are fast, but they should not be treated as a representative cold-retrieval benchmark. Fourteen of fifteen known-answer prompts were semantic-cache hits. A production evaluation should include paraphrases, cache-busting variants, repeated runs after cache clearing, and concurrent requests so that retrieval, reranking, context safety scanning, and generation are measured independently of the semantic answer cache.

Client-observed elapsed times were several seconds even when the application-reported internal totals were tens of milliseconds. This difference likely includes remote network, container wake-up, or platform scheduling overhead. It should be tracked separately from the application’s internal SLA rather than combined with it.

## Recommendations

First, profile and optimize the context-chunk safety guardrail, especially on cold retrieval. Its 1.45-second contribution dominated the only known-answer failure in this run. Batching the scan, reusing document-level safety decisions, reducing repeated model initialization, or moving the scan to a lower-latency implementation would have the greatest effect on the displayed 200 ms target.

Second, rerun the battery with the semantic answer cache disabled or explicitly bypassed. The current run establishes that the cached path is correct and fast, but it provides limited evidence about steady-state uncached retrieval quality or latency.

Third, add paraphrase and cross-lingual transfer cases. The current prompts are mostly exact copies of the UI’s quick prompts, which is useful for smoke testing but insufficient for measuring retrieval robustness. For each language, add at least one natural paraphrase, one English query against non-English passages, and one query whose answer requires combining passages across languages.

Fourth, expose a machine-readable evaluation endpoint or export containing the same per-stage telemetry. That would make future VIGOURLS-style runs reproducible and would avoid relying on manual browser inspection.

## Conclusion

The RAG system passed the functional multilingual smoke test: **15/15 known-answer cases were answered and grounded, 15/15 language routes were exact, and both refusal controls behaved correctly**. The main engineering risk is not answer correctness in this battery but **cold-path latency**, specifically the context-chunk safety guardrail. The next evaluation should be cache-bypassed and repeated under concurrency before treating the latency target as production-ready.

Official SVARASETU numbers for this submission are in `svarasetu/measure/reports/svarasetu_sla.md` (cache-off P50/P70/P100) and `python -m svarasetu.measure.real`.