Sentence-Level Groundedness Checker for RAG Answers with Human-Calibrated Thresholds
RAG apps cite sources, but a citation does not prove the sentence next to it is supported. Build a drop-in checker that splits each answer into claims, checks every claim against the retrieved passages with a natural language inference model and an LLM judge, highlights unsupported sentences in the UI, and sets its thresholds from human labels rather than guesses. Test it on English and Urdu answers.
Advanced
Needs a team, real planning, and a supervisor who knows the area.2 semesters · 2 to 3 students
7 to ship
3 optional extrasSuggested stack
What you should ship
- A claim splitter that turns an answer into atomic, checkable statements
- Two checkers: an NLI model run locally and an LLM judge, each producing supported, contradicted or not-found per claim with the evidence span
- A labelling app where people mark claims as supported or not, used to build at least 1,000 labelled claims across English and Urdu
- Threshold calibration from the labels, with precision and recall curves and a chosen operating point
- An HTTP API and a small React component that shows an answer with unsupported sentences highlighted and evidence on hover
- Integration into a demo RAG app over a public document set (for example university regulations or public policy documents)
- An evaluation comparing your checker with an open baseline such as RAGAS faithfulness on the same labels
If you have time left
- A rewrite mode that removes or softens unsupported sentences and re-checks
- Distilling the LLM judge into a small model that runs on a CPU
- Bangla support
The problem: a citation is not a proof
A user asks a RAG assistant about exam rules. The answer looks great: three sentences, two footnotes. But the second sentence adds a detail that appears in no source, and the footnote next to it points to a passage about something else. Users trust citations, so these errors are worse than an answer with none.
The OWASP Top 10 for LLM Applications (2025) lists misinformation as a risk. For any RAG product, the most useful single number is how many sentences are actually supported by what was retrieved.
What already exists and the gap
- RAGAS offers a faithfulness metric that uses an LLM to check statements against context.
- Vectara's HHEM is an open hallucination evaluation model for checking a summary against its source.
- DeepEval and promptfoo include faithfulness and context-based checks for test suites.
- FActScore (Min and colleagues, EMNLP 2023) introduced scoring long answers by splitting them into atomic facts.
These are mostly offline metrics with default thresholds. The gap is a runtime checker that a product can show to users sentence by sentence, with thresholds set from human labels for the app's own domain, and tested beyond English.
Inspiration
FActScore's atomic-fact idea is the core. The rest of the project is making it fast, calibrated and visible to a user, which is what it takes to move a research metric into a product.
What you build
- Claim splitting and two checkers you can compare.
- A labelling app to create ground truth.
- Calibration that turns scores into supported or not.
- A UI component that highlights unsupported sentences.
The technically interesting part
- Splitting claims well. Too coarse and errors hide inside long claims. Too fine and you check trivia. Measure how splitting affects accuracy.
- NLI versus LLM judge. A local NLI model is fast and cheap but brittle on paraphrase. An LLM judge is better but slower and costs money. Show the trade-off and maybe combine them.
- Urdu. Few NLI models handle Urdu well. Test translation-then-check against direct checking and report honestly.
How you will evaluate it
- Precision and recall for unsupported claims against human labels, per language.
- Latency added per answer and cost per thousand answers.
- A user study: do people notice and correct wrong answers more often when highlights are shown?
Path to a product
Every company running RAG wants a groundedness score on each answer, for dashboards and for user trust. A hosted checker API priced per answer, or a self-hosted package with an admin dashboard, is a realistic product.
Scope warning
Use public documents and answers generated by your own demo app. Two checkers are enough; do not try to train a new NLI model from scratch.
Learn what you need on Sefism
- AI evals cheat sheet: faithfulness, judges and calibrating thresholds against people.
- GenAI app architecture cheat sheet: where a checker sits in a RAG pipeline.
- AI engineering roadmap: RAG, embeddings and evaluation in order.
- RAG techniques: retrieval patterns your demo app can use.
- DeepEval: existing faithfulness metrics to compare against.
- Hugging Face Transformers documentation: running the NLI model.
- Speech and Language Processing: the chapter on natural language inference.
- What does an AI evals engineer do?: the role this kind of checker belongs to.
- Do I need a vector database for my AI project?: retrieval choices that decide what your checker sees.
Get help with this idea
The risk is a checker whose scores mean nothing because nobody calibrated them. Tauseef can help you plan the labelling, choose models and design the user study. If you are new here, create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.