Hallucination is not one measurable defect. A response can invent a fact, misstate a fact present in the source, answer a different question, combine two true facts into a false conclusion, or present an unsupported claim with high confidence. Treating all of those failures as a single \u201challucination rate\u201d produces a number that is easy to report and hard to act on.<\/p>\n
In an AWS generative AI<\/a> program, evaluation should separate model quality from retrieval quality, prompt behavior, and runtime guardrails. That distinction also matters for Amazon AWS AIP-C01<\/a>: a grounded RAG answer can fail because the right evidence was never retrieved, because the model ignored it, or because the evaluation metric did not represent the real business requirement.<\/p>\n For a retrieval-augmented application, two useful categories are grounding and relevance. Grounding asks whether the answer is supported by the supplied source. Relevance asks whether the answer actually addresses the user\u2019s question. Amazon Bedrock Guardrails exposes contextual grounding checks around those two dimensions, which is useful because a response can be perfectly grounded and still irrelevant, or directly relevant and still unsupported.<\/p>\n Other systems need different categories. A financial summarizer may care about numeric fidelity and omission. A support assistant may care about policy compliance and whether it invents entitlement. A code assistant may care about compilability and dependency correctness. The evaluation design should use error labels that correspond to decisions engineers can make, not a generic label that collapses every bad output together.<\/p>\n This is the same reason LLM judges and metrics<\/a> need scrutiny. A metric is a lens, not the truth. If the lens cannot distinguish retrieval failure from generation failure, it cannot tell the team where to intervene.<\/p>\n A useful hallucination dataset includes ordinary requests, edge cases, adversarial phrasing, ambiguous questions, incomplete source material, stale facts, conflicting documents, and requests that should produce an explicit \u201cI do not know\u201d or escalation. Sampling only clean questions with obvious answers makes the model look safer than it is in production.<\/p>\n Ground-truth design also matters. For factual QA, the expected answer and supporting passages should be reviewed by a subject-matter expert when risk is material. For summarization, ground truth may be a set of required facts and prohibited additions rather than one canonical paragraph. The evaluation record should capture why an answer failed, not merely that a scorer assigned 0.63.<\/p>\n Regression datasets should preserve important failures after they are fixed. The approach described in LLM evaluation and regression testing<\/a> turns incidents into permanent test cases. That prevents a prompt, model, retrieval, or guardrail change from reintroducing a defect that the team already paid to discover.<\/p>\n Amazon Bedrock evaluations can assess RAG systems in retrieve-only mode or retrieve-and-generate mode. Retrieve-only metrics such as context relevance and context coverage focus on whether the system brought back useful evidence. Retrieve-and-generate evaluation adds response-oriented measures so the team can examine whether the model used that evidence effectively.<\/p>\n This separation is essential for hallucination work. If the correct passage was not retrieved, prompt tuning may not solve the root cause. The team may need better chunking, metadata, filters, embeddings, or query rewriting. The existing RAG chunking<\/a> discussion is relevant because retrieval quality is created before the model starts generating text.<\/p>\n Amazon Bedrock Knowledge Bases can participate in that evaluation workflow, but the same logic applies to external RAG sources. A useful test run keeps retrieval metrics and generation metrics visible together. That makes it possible to see cases where retrieval is excellent but the model still adds unsupported material, and cases where generation is faithful to weak evidence.<\/p>\n Bedrock Guardrails contextual grounding checks can score grounding and relevance when the application provides a grounding source, user query, and response. Thresholds can be configured between 0 and 0.99. Higher thresholds block more low-confidence responses, which can reduce exposure to ungrounded output but can also increase false rejections of useful answers.<\/p>\n The feature is valuable for supported use cases such as summarization, paraphrasing, and question answering, but it has scope limits. Current AWS documentation notes that conversational QA or chatbot use cases are not supported by contextual grounding checks in the same way. Streaming also requires care because an irrelevant response may be streamed before the final check marks it as irrelevant.<\/p>\n That is why AI guardrails<\/a> should be treated as runtime policy enforcement, while offline evaluation remains the place to compare versions, examine distributions, and investigate failures. A guardrail can block a response today; it does not tell you whether the next model release improved across the full risk set.<\/p>\n Amazon Bedrock supports evaluation jobs that use an LLM as a judge. Built-in metrics include dimensions such as correctness, completeness, faithfulness, style, and other quality characteristics depending on the evaluation type. Teams can also define custom metrics with their own evaluation prompt and rating scale.<\/p>\n Judge models make broad evaluation practical, but the evaluator is also a model with biases, blind spots, and prompt sensitivity. A high score should not be treated as ground truth merely because the service computed it. Calibrate judge results against human-reviewed examples, particularly around the exact hallucination categories that create business risk.<\/p>\nDefine the failure before choosing the metric<\/h3>\n
Build a prompt set from real risk, not only easy examples<\/h3>\n
Use Bedrock RAG evaluation to separate retrieval from generation<\/h3>\n
Use contextual grounding as a runtime control, not a complete evaluation program<\/h3>\n
Model-as-judge evaluation is scalable but not self-validating<\/h3>\n