Career Transitions Into AI — Intermediate
Build an end-to-end LLM fact-checking pipeline with traceable sources.
This book-style course helps journalists and editorial fact-checkers transition into applied AI research by building a complete LLM fact-checking pipeline with rigorous source tracing. You’ll learn how to translate newsroom instincts—skepticism, sourcing discipline, and clear writing—into reproducible experiments, measurable outcomes, and portfolio artifacts that hiring teams can evaluate.
Instead of treating “fact checking” as a vague promise, you’ll define what it means operationally: what types of claims you can verify, which sources count as evidence, how to measure success, and how to know when the model should abstain. By the end, you will have a working system that takes a claim, retrieves relevant documents, produces an evidence-grounded verdict, and outputs traceable citations with an audit trail.
This course is designed for individuals making a career pivot into AI roles—especially people with reporting, research, policy, or investigative backgrounds. You do not need prior machine learning experience, but you should be comfortable learning Python from guided templates and thinking in terms of structured data and evaluation.
You’ll construct an end-to-end pipeline in progressive layers. First you’ll define a claim schema and success metrics. Next you’ll build an evidence retrieval stack (keyword, vector, or hybrid) and learn how chunking choices affect citation quality. Then you’ll implement grounded LLM verification patterns that produce structured verdicts and citations. Finally, you’ll add provenance logging, automated evaluation, and red-team testing to ensure the system is auditable and robust.
Chapter 1 frames the problem like a researcher: define the task, define the schema, and decide what “good” looks like. Chapter 2 builds the retrieval layer, because evidence quality is the ceiling for factuality. Chapter 3 turns retrieved passages into grounded decisions with citations. Chapter 4 formalizes provenance so results are inspectable and reproducible. Chapter 5 makes your work credible through evaluation and adversarial testing. Chapter 6 turns the project into a shippable demo and a career-ready case study.
Hiring teams increasingly want proof that you can do more than prompt an LLM. They look for disciplined thinking: data contracts, experiment logs, metrics, error analysis, and clear tradeoffs. This course makes those habits explicit and shows you how to present them as a research narrative—without losing the editorial clarity that is already your advantage.
If you want to start building and keep your work organized from day one, Register free. To compare this course with other career pivot paths, you can also browse all courses.
You’ll finish with a portfolio-ready LLM fact-checking pipeline that produces traceable sources, measurable results, and a clear methodology section—exactly the kind of artifact that supports a transition from journalism into AI research, evaluation, or AI safety-adjacent roles.
Applied NLP Researcher, Retrieval-Augmented Generation & Evaluation
Sofia Chen builds LLM systems for evidence-grounded Q&A, citation tracing, and automated evaluation. She has led applied research projects spanning news intelligence, data quality, and model auditing, with a focus on reproducible pipelines and rigorous metrics.
Good fact-checking is not a vibe; it is a workflow that turns messy language into a set of testable commitments. As a journalist, you already do this instinctively: you isolate what could be wrong, find the best sources, and decide what level of confidence is acceptable before publication. As an AI researcher building LLM fact-checking pipelines, you will do the same work—but you must formalize it so that a system can execute it, and so that results can be reproduced, audited, and improved.
This chapter converts editorial practice into an AI research problem statement. You will learn to decompose an article into checkable claims, define claim types and risk levels, set acceptance criteria, and design a data schema that can store claims, evidence passages, and provenance. You will also set up the basic research artifacts—repo structure, notebooks, and experiment logs—so you can run controlled experiments. Finally, you will draft a baseline retrieval-augmented workflow and plan success metrics that reflect both product needs (latency, cost) and newsroom ethics (accuracy, attribution, risk).
The core mindset shift is this: you are not building a model that “knows facts.” You are building a system that makes verifiable statements, tied to cited sources, under explicit assumptions. In research terms, you are defining the task, the evaluation, and the failure modes before you optimize anything.
Practice note for Translate editorial fact-checking into an AI research problem statement: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Define claim types, risk levels, and acceptance criteria: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Design the data schema for claims, evidence, and sources: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Set up the project repo, notebooks, and experiment log: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Draft a baseline workflow and success metrics: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Translate editorial fact-checking into an AI research problem statement: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Define claim types, risk levels, and acceptance criteria: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Design the data schema for claims, evidence, and sources: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Set up the project repo, notebooks, and experiment log: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
In reporting, “true” often means “supported by reliable sources and consistent with available evidence at publication time.” In LLM systems, you need an even tighter definition because the model will gladly produce fluent text without warrant. Operationally, truth becomes groundedness: every answer must be traceable to evidence you can show, and the scope of the claim must match what the evidence actually states.
Start by writing your problem statement as a contract. Example: “Given an input article, extract checkable claims; for each claim, retrieve relevant sources; produce a verification decision and a citation-backed explanation.” The acceptance criteria must be explicit: what counts as verified, refuted, or unknown; how many independent sources are required; whether you accept reputable secondary reporting; and how you handle time-sensitive facts (e.g., “as of March 2026”).
Common mistake: treating the LLM as the judge of truth. The LLM can summarize and compare, but the system should privilege source text as the authority. Your pipeline should therefore (1) constrain the model to answer from retrieved passages, (2) require passage-level citations, and (3) allow “insufficient evidence” as a first-class outcome. Another common mistake is ambiguous scope: a claim like “crime is rising” needs geography, time window, and metric definition; without these, the system can only guess.
Practical outcome: define “truth” as a combination of scope + evidence + decision policy. That policy will later guide both prompt design and automated evaluation.
Editorial fact-checking often highlights the single “most important” questionable statement. Research systems need finer granularity. An LLM pipeline works best when claims are atomic: one subject, one predicate, one object (plus necessary qualifiers). Atomicity is what lets you retrieve targeted evidence and score results consistently.
Take a compound assertion: “The mayor raised taxes by 10% last year, which caused small businesses to close.” This contains at least three atomic claims: (1) the mayor raised taxes, (2) the change was 10%, (3) it happened last year; plus a causal claim about business closures. Each requires different sources and different verification logic. If you don’t decompose, retrieval will mix unrelated passages and the model may “average” them into a misleading verdict.
Define claim types early (e.g., numeric, temporal, entity attribution, quote, causal). Then define risk levels. A low-risk claim might be “the event took place on Tuesday” in a lifestyle piece; a high-risk claim might be “a drug reduces mortality by 30%” in health reporting. Risk affects acceptance criteria: high-risk claims may require primary documentation, multiple sources, and stricter citation rules.
Implementation tip: store both the original sentence and the atomic claims you derived, with a stable ID linking them. This supports auditability (“how did we interpret the text?”) and enables error analysis when a downstream verdict is wrong. Practical outcome: you can translate narrative prose into a list of testable units your system can verify independently.
Not all claims are verified the same way. You will design verification questions that match the target type, because retrieval and prompting strategies differ. Think like an editor assigning a check: “Confirm the spelling of the agency name,” “Find the original report for that statistic,” “Locate the full transcript for the quote.” In a pipeline, you encode those as structured verification questions.
Entities: Verify identity, role, and disambiguation (e.g., two people with the same name). Retrieval should include canonical identifiers where possible (official websites, government directories). Numbers: Require the unit, denominator, and definition (10% of what? nominal or real?). Plan to store parsed numeric values separately from text so you can compare precisely. Dates: Normalize time expressions (“last year”) into explicit ranges tied to publication date; otherwise evaluation will be inconsistent.
Quotes are uniquely fragile. Quote drift happens when paraphrases are re-quoted as verbatim. Your acceptance criteria should distinguish between verbatim match (requires transcript/audio/official statement) and faithful paraphrase (may accept reputable secondary coverage). Store evidence spans with exact character offsets so you can show the matching text. Causality is hardest: causal claims often exceed what sources state (“caused” vs “correlated with”). Create a special label such as “not supported (causal overreach)” to avoid forcing binary true/false decisions.
Practical outcome: you can map each atomic claim to a verification target and generate precise questions for retrieval-augmented checking, improving both grounding and interpretability.
Your pipeline is only as credible as its sources. Journalists already apply a source hierarchy; an AI system must encode it so decisions are consistent. Primary sources include original documents, datasets, court filings, legislation, academic papers, transcripts, and direct recordings. Secondary sources interpret or report on primary material (reputable newspapers, expert analyses). Tertiary sources compile information (encyclopedias, some databases). Gray literature includes reports without formal peer review, NGO briefs, corporate whitepapers, and preprints.
Engineering judgment: decide what your system is allowed to cite for each risk level and claim type. For example, for a high-risk medical statistic, you might require a peer-reviewed paper or official health agency report; for a film release date, a studio press release may be sufficient. Encode this as a source policy that tags domains or document types with reliability and intended use (verification vs background).
Common mistake: letting web search results dictate truth. Search ranks popularity, not correctness; LLMs then rationalize whatever they see first. Your retrieval layer should prioritize vetted corpora when possible, record the full URL and access time, and capture the exact passages used. Also plan for provenance: store document metadata (publisher, author, publication date, version) and keep snapshots or hashes when feasible, since web pages change.
Practical outcome: your system can “trace the source” the way an editor would—showing not just a citation, but why that citation is appropriate for the claim’s risk profile.
To transition from newsroom work to AI research, you must produce artifacts other researchers can run and critique. Start with a repository that separates data, code, prompts, and results. A practical structure is: data/ (raw and processed), schemas/ (JSON Schema or Pydantic models), pipelines/ (retrieval, checking, citation formatting), notebooks/ (exploration), experiments/ (configs), and reports/ (tables, plots).
Next, define your data schema for claims, evidence, and sources. At minimum, a Claim record should include: claim_id, article_id, original_text_span, normalized_claim_text, claim_type, risk_level, and verification_question. An Evidence record should include: evidence_id, claim_id, document_id, passage_text, passage_start/end offsets, and a relevance score. A Source record should include: document_id, url, title, publisher, publish_date, access_date, document_type (primary/secondary/etc.), and a content hash or snapshot reference.
Finally, write a protocol: a short document describing how claims are labeled, how disagreements are resolved, and what “verified/refuted/unknown” means. This is your bridge from editorial standards to research methodology. Keep an experiment log (even a simple CSV or MLflow/W&B run) capturing model versions, prompts, retrieval settings (k, filters), and evaluation results. Common mistake: changing prompts and retrieval parameters without recording them; you can’t improve what you can’t reproduce.
Practical outcome: you have a portfolio-ready foundation—a repo that demonstrates not just a demo, but a research process with traceable decisions.
A baseline workflow is only useful if you can measure progress. Plan metrics before you optimize. For LLM fact-checking pipelines, you typically need five categories: factuality, attribution quality, coverage, latency, and cost—plus a risk-aware view that reflects editorial impact.
Factuality: measure whether the verification decision matches gold labels (accuracy/F1 across verified/refuted/unknown). Also measure calibration: when the system says it is “high confidence,” is it usually correct? Attribution: check citation precision—does each cited passage actually support the statement, and is the support specific (not just topical)? Consider a “grounded answer rate” where every factual sentence must be supported by at least one passage-level citation. Coverage: how many extracted claims receive a verdict with sufficient evidence? Low coverage can hide failure by overusing “unknown,” so track unknown-rate by claim type.
Latency and cost: retrieval depth, number of model calls, and context length drive both. Record median and p95 latency per article and per claim, and estimate cost per 1,000 articles under realistic traffic. Risk: weight errors by harm. A wrong number in a financial story is not the same as a wrong quote in a legal allegation. Create a weighted score where high-risk claims carry higher penalty, and define “must-not-fail” classes that trigger human review.
Common mistake: optimizing only for verdict accuracy while ignoring citation quality. A system that is “right for the wrong reasons” is fragile and hard to trust. Practical outcome: you end Chapter 1 with a baseline RAG-style checking plan and a metric suite that reflects both engineering constraints and newsroom standards.
1. What is the key mindset shift when moving from editorial fact-checking to AI research for LLM fact-checking pipelines?
2. Why does the chapter insist on formalizing journalistic instincts into a problem statement and workflow?
3. When decomposing an article into checkable parts, what should be defined alongside claim types?
4. What is the main purpose of designing a data schema for claims, evidence passages, and provenance?
5. Which set of success metrics best matches the chapter’s guidance for evaluating a baseline retrieval-augmented workflow?
Fact-checking with LLMs lives or dies on retrieval. If your system cannot reliably surface the right source passages, the best prompt and the biggest model will still produce confident nonsense—often with citations that look plausible but don’t actually support the claim. In this chapter you’ll treat retrieval as an engineering discipline: what you ingest, how you normalize it, how you chunk it for provenance, which retrieval baselines you ship first, and how you evaluate changes with ablations rather than intuition.
The practical goal is a retrieval subsystem that can answer this question repeatedly: “Given a claim, can we find the smallest set of passages that either support or refute it, with stable provenance and citation-ready formatting?” That goal forces you to design a document intake pipeline (web, PDFs, databases) with metadata, implement keyword and vector retrieval baselines, and choose chunking and indexing strategies that keep citations honest. It also forces you to document retrieval failures: when the corpus is missing the right sources, when OCR mangles numbers, when duplicates drown results, or when prompt injection text sneaks into your index.
As a journalist transitioning into AI research, your advantage is editorial judgment: you already know that sources have hierarchy (primary vs secondary), that publication dates matter, and that credibility differs by domain. Your challenge is to express that judgment as a reproducible corpus strategy and measurable retrieval settings. By the end of this chapter, you should be able to run controlled retrieval ablations (chunk size, overlap, top-k, hybrid weights, reranker choice), read failure logs like a newsroom corrections desk, and iterate the corpus with clear hypotheses.
Think of retrieval as the “assignment desk” for your LLM: it decides which documents get considered, which passages get quoted, and which sources become part of the record. Everything downstream—grounded generation, attribution, calibration—depends on this step being boringly reliable.
Practice note for Build a document intake pipeline (web, PDFs, databases) with metadata: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Implement retrieval baselines (keyword + vector) for evidence discovery: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Create chunking and indexing strategies optimized for citations: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Run ablations to choose retrieval settings for your domain: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Document retrieval failures and iterate the corpus: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Build a document intake pipeline (web, PDFs, databases) with metadata: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Implement retrieval baselines (keyword + vector) for evidence discovery: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Start with a corpus strategy before you touch embeddings. In journalism, you don’t “search the internet” as a source; you decide which outlets, datasets, filings, or transcripts are admissible evidence for a particular beat. Your fact-checking pipeline needs the same policy, because retrieval quality is bounded by what you index.
Curated corpora (selected domains, known publishers, official databases) give you higher signal-to-noise, stable URLs, and consistent formatting—ideal for citations and reproducibility. They also make evaluation easier: if a claim is unanswerable, you can often attribute it to “missing coverage” rather than “retrieval randomness.” The downside is coverage gaps: breaking news, niche topics, or local context may be absent.
Open-web corpora provide breadth but introduce volatility and risk. Pages change, disappear, or get rewritten; SEO spam can dominate keyword retrieval; and adversarial text (including prompt injection) can be indexed. Open web also complicates provenance: the same text is syndicated across many sites, and you need deduplication and canonicalization to avoid citing a scraped copy instead of the original.
A practical approach is a tiered corpus: (1) primary sources (government datasets, court filings, company reports), (2) reputable secondary sources (wire services, standards bodies, peer-reviewed journals), (3) controlled open-web expansion for recall. Encode this as metadata: source_tier, publisher, crawl_time, license, document_type, and jurisdiction. Your retriever can then prefer Tier 1–2 while still allowing Tier 3 when needed.
Common mistake: indexing everything “just in case.” That usually lowers precision and increases citation errors. Another mistake is ignoring licensing and terms—portfolio projects still need legal hygiene. The practical outcome for this section is a written corpus policy plus an intake manifest (what you ingest, why, and how you will keep it current) that you can defend in an evaluation report.
Retrieval fails silently when documents are messy. PDFs can contain selectable text, scanned images, or mixed layouts; HTML pages can hide key facts behind tables, scripts, or footnotes. Your document intake pipeline should treat ingestion as a reproducible data engineering job: fetch, extract, normalize, and store with metadata and hashes.
Extraction. For web content, capture both the cleaned main text and a snapshot of the raw HTML. For PDFs, store the original file and extracted text, and keep page boundaries. When tables matter (budgets, survey results), extract a structured representation (CSV/JSON) alongside the narrative text, or at least preserve table rows in a consistent text format.
OCR. If PDFs are scanned, run OCR and record confidence scores. Low-confidence OCR should be flagged because it can corrupt names and numbers—exactly what fact-checkers care about. Keep page images or page-level references so you can later verify disputed passages.
Normalization. Normalize whitespace, Unicode, hyphenation across line breaks, and date/number formats where safe. Don’t over-normalize quotations: you want to preserve exact wording for quote checks. Add stable identifiers: doc_id, version_id, and content_hash for reproducibility.
Deduplication. Dedup at multiple levels: exact duplicates (hash match), near-duplicates (shingling/MinHash), and syndicated copies (canonical URL mapping). Without dedup, retrieval may return many copies of the same passage, reducing source diversity and encouraging “citation laundering” from lower-quality mirrors.
Common mistakes include losing provenance (dropping URLs and timestamps), stripping page numbers from PDFs (making citations unusable), and mixing multiple document versions without tracking. The practical outcome is a document store where every passage can be traced back to an immutable artifact, with enough metadata to later format citations consistently.
Chunking is not a cosmetic step; it is a citation strategy. Your model can only cite what the retriever returns, so chunk boundaries determine whether evidence is complete, quotable, and attributable. The “best” chunk size is the one that preserves meaning while keeping provenance granular.
Use natural boundaries. Prefer section headers, paragraphs, list items, and PDF page boundaries over arbitrary token counts. For legal filings, chunk by numbered sections; for research papers, chunk by abstract/method/results; for transcripts, chunk by speaker turns with timestamps. Store a passage_id that includes doc_id plus a stable range (e.g., page 12, paragraph 3) so citations don’t drift when you reprocess.
Overlap with intent. Overlap helps when a key sentence depends on context from the previous paragraph, but too much overlap increases redundancy and can bias retrieval toward repeated fragments. Start with modest overlap (e.g., 10–20% of tokens) and increase only if you see systematic “missing context” errors in failure logs.
Keep quote-ready text. If your downstream fact-checking includes quote verification, preserve punctuation and quotation marks. Avoid aggressive sentence reflow that changes meaning. Store both the “display text” used for citations and any “normalized text” used for indexing, and keep them linked.
Common mistake: chunking solely by token length and then wondering why citations are vague (“somewhere in this long chunk”). Another mistake is splitting tables or figure captions away from their references, which breaks claims like “Figure 2 shows…” The practical outcome is an indexing-ready passage store where each chunk has clear boundaries, minimal ambiguity, and a predictable citation format (URL + date + page/section + passage_id).
Ship retrieval baselines early. A keyword baseline (BM25) plus a vector baseline (embeddings) will teach you more than weeks of prompt tuning. In fact-checking, you often need both: keywords for precise entities and numbers, embeddings for paraphrases and implied relationships.
BM25 (keyword search). Strengths: exact matches, transparent scoring, strong for named entities, dates, and uncommon phrases. Weaknesses: synonyms and paraphrases; can be gamed by repetitive text. Good first step for “find the statute,” “find the quoted phrase,” or “find the dataset row.”
Embedding retrieval (vector search). Strengths: semantic recall, paraphrase matching, robust to wording differences. Weaknesses: can miss exact numeric constraints, may retrieve conceptually related but non-evidentiary passages. Use it for claims where the same idea appears with different phrasing across sources.
Hybrid retrieval. Combine BM25 and embeddings to get higher recall. Practical patterns include: (1) run both, union top-k, then dedup; (2) weighted score fusion; or (3) BM25 for candidate generation, vectors for expansion. Track which channel retrieved each passage; this is valuable for ablations and debugging.
Reranking. A cross-encoder reranker (or an LLM-based scorer) can reorder the candidate set based on claim-passage relevance. Reranking is often the difference between “the right source is in top-50” and “the right source is in top-5.” Keep reranking inputs small and deterministic, and log scores to explain why a passage was promoted.
Common mistakes: evaluating only end-to-end answer quality and ignoring retrieval recall; setting k too small; and failing to constrain by metadata (date ranges, jurisdictions), which can cause outdated evidence to outrank current sources. The practical outcome is a retrieval stack you can toggle: BM25-only, vector-only, hybrid, and hybrid+rerank—each producing citation-ready passages with provenance.
Retrieval begins with the query, and queries should be engineered artifacts, not a single string copied from the claim. Your system’s earlier step (claim decomposition) should produce verification questions; here you turn those questions into one or more retrieval queries optimized for different retrievers.
Template queries. For each claim, generate structured queries that preserve entities and constraints. Example fields: subject, predicate, object, time, location, metric. From these, produce: (1) exact-phrase BM25 query with quoted entities, (2) expanded BM25 query with synonyms, (3) embedding query as a natural language question, and (4) a “counterfactual” query that searches for refutations (e.g., include “myth,” “false,” “fact check,” or the negated predicate when appropriate).
Query expansion. Add aliases (organization acronyms, former names), unit variants (million vs 1,000,000), and domain synonyms (e.g., “unemployment rate” vs “jobless rate”). Expansion is especially important for international contexts where transliterations vary. Keep expansion rules explicit and testable; avoid uncontrolled LLM expansions that may introduce wrong entities.
Metadata filters. Use filters to reduce noise: date ranges around the event, jurisdiction, document type (press release vs opinion), and source tier. This is where your journalistic instincts become code: a claim about a policy “in 2023” should not retrieve a 2014 blog post as primary evidence.
Common mistakes: asking overly broad questions (“Is this true?”) and relying on a single query per claim. Another mistake is letting the model “decide” the query without logging it; you need to audit query drift. The practical outcome is a query-generation module that emits a small set of logged queries per claim, each tied to a retrieval channel and filter set.
You can’t improve retrieval without measuring it. Build an evaluation harness that scores retrieval independently of generation. In practice, you’ll maintain a small gold set: claims paired with one or more known-good passages (supporting or refuting) plus acceptable alternative sources.
Recall@k. The core metric is whether at least one gold passage appears in the top-k retrieved results. Track recall@5, @10, @20. If recall@20 is low, your corpus or query strategy is wrong; if recall@20 is high but recall@5 is low, reranking or hybrid weighting is your lever.
Source diversity. For contentious claims, a single outlet shouldn’t dominate. Track unique publishers and tiers in the top-k, and flag when results collapse into duplicates or mirrors. Diversity helps reduce citation laundering and improves robustness when one source is incorrect.
Ablations. Change one variable at a time: chunk size, overlap, embedding model, BM25 parameters, hybrid fusion weights, top-k, reranker on/off. Log results in a table and keep configs versioned. This is how you choose retrieval settings for your domain without relying on anecdotes.
Leakage and injection checks. Ensure your evaluation claims are not accidentally included verbatim in the corpus (label leakage). Scan indexed text for prompt injection patterns (“ignore previous instructions”) and either strip them or down-rank the source tier. Also check for “citation leakage” where the retriever returns your own system outputs (if you store generated reports) instead of primary sources.
Failure documentation. Maintain a retrieval failure log with categories: missing corpus coverage, OCR corruption, wrong date/version, duplicate swarm, query too narrow/broad, and reranker misfire. Each failure should lead to a concrete iteration: ingest a new database, adjust filters, change chunking boundaries, or add a dedup rule.
The practical outcome is an evaluation dashboard that makes retrieval improvements visible and repeatable—so your fact-checking pipeline can be hardened against hallucinations not by “being careful,” but by consistently surfacing the right evidence.
1. Why does the chapter argue that fact-checking with LLMs “lives or dies on retrieval”?
2. What practical goal should the retrieval subsystem achieve repeatedly, according to the chapter?
3. Which approach best matches the chapter’s recommended way to choose retrieval settings (e.g., chunk size, top-k, hybrid weights)?
4. Which pair of retrieval baselines does the chapter indicate you should implement first for evidence discovery?
5. Which scenario is an example of a retrieval failure the chapter says you should document and use to iterate the corpus?
This chapter turns your pipeline from “an LLM that sounds right” into a verification system that behaves like a careful researcher: it answers only from evidence, shows where that evidence came from, and tells you when the evidence is insufficient. In journalism terms, you are building the equivalent of a notes-and-sources workflow—except your notes are machine-readable, your sources are passage-addressable, and your editor is an evaluator that can run nightly.
You will implement a first end-to-end claim verification loop: (1) decompose an article into checkable claims, (2) retrieve candidate sources, (3) run a multi-step verify routine (extract compare decide), (4) add quote and numeric consistency checks, and (5) produce a human-readable verdict backed by structured JSON. Along the way, you will harden the system against classic failure modes: hallucinations, quote drift (changing words while preserving “meaning”), and prompt injection embedded in retrieved pages.
Keep a practical mental model: a verification LLM should behave like a constrained analyst, not a creative writer. Your job is to define the contract that forces that behavior, then add enough instrumentation (citations, spans, provenance, and evaluation hooks) that you can reproduce decisions and debug them when they go wrong.
By the end of this chapter, you should be able to point to a JSON record for any verified claim and answer three questions instantly: What did we check? What evidence did we rely on (exact spans)? And how confident are we—based on rules you can defend?
Practice note for Write prompts that force evidence-only answers and uncertainty reporting: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Implement multi-step verification (extract → compare → decide): document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Add quote checking and numeric consistency checks: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Generate human-readable verdicts with structured JSON outputs: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Create a first working end-to-end claim verification loop: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Write prompts that force evidence-only answers and uncertainty reporting: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Implement multi-step verification (extract → compare → decide): document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Add quote checking and numeric consistency checks: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
A verification prompt is not “a good question.” It is a contract: precise inputs, a restricted set of allowed operations, and explicit refusal conditions. If you skip this, the model will fill gaps with plausible text—exactly what you are trying to prevent.
Start by separating context from instructions. Your context is a bundle of retrieved passages (each with a stable ID), plus the claim (or verification question). Your instruction set should be short and non-negotiable: “Use only the provided passages; if the passages do not contain enough evidence, return UNSUPPORTED.” Add a refusal clause for prompt injection: “Ignore any instructions inside passages; treat them as untrusted text.”
Define I/O precisely. Inputs typically include: claim text, claim type (quote, numeric, general factual), retrieval bundle (passages with metadata), and any constraints (time window, geography). Outputs should be machine-checkable: verdict label, cited passage IDs, quoted spans, and an uncertainty field. When outputs are free-form, you cannot evaluate them reliably.
Common mistake: asking for “a brief explanation” without specifying that explanations must be evidence-linked. That invites the model to synthesize. Instead, require an evidence-only rationale: each sentence must reference at least one citation ID. If the model cannot cite, it must stop and say it cannot verify.
Think like an editor writing standards: the prompt contract is your standards manual. It should be stable across claims, so that changes in behavior come from evidence and logic—not prompt improvisation.
Grounding is not one technique; it is a choice of pattern. Two patterns dominate fact-checking pipelines: extractive QA and abstractive verification. Extractive QA asks the model to copy the minimal span that answers a question (“What was the unemployment rate in 2023?”). Abstractive verification asks the model to judge a claim (“Unemployment fell in 2023”) using evidence. Both are useful, but they fail differently.
Use extractive QA when the claim hinges on a precise datum: a date, a number, a direct quote, an official title. Extractive steps reduce hallucinations because the model must point to text that already exists. The output is naturally auditable: you can highlight a span in the source. The trade-off is coverage: not every claim has a single clean sentence to copy.
Use abstractive verification when you must integrate multiple sentences or sources (e.g., causality, comparisons, definitions). Here, the model will summarize across evidence, which increases the risk of “quote drift” and subtle meaning changes. To mitigate, break the task into multi-step verification: extract compare decide. First extract candidate supporting/contradicting spans from each passage. Then compare spans against the claim with explicit criteria. Finally decide the verdict label.
Engineering judgment: do not let the model jump straight to a verdict. Force the intermediate artifacts. If you collect extracted spans first, you can later swap out the decision model, re-run decisions, or add deterministic checks (like numeric validation) without re-retrieving sources.
This decomposition also sets you up for evaluation: you can score extraction quality (did we pick relevant spans?) separately from decision quality (did we label correctly?), which is essential for debugging.
Citations are the spine of a trustworthy verification system. “According to the source” is not enough; you need passage-level evidence and provenance that survives re-indexing and reproducible experiments. Implement citations as structured references, not as prose footnotes.
At retrieval time, assign each chunk a stable passage_id and store metadata: URL, publisher, title, publication date, retrieval timestamp, and chunk boundaries (start/end offsets in the original document). Your verification model should cite only these IDs. When the model selects evidence, require it to output spans: character offsets (or token offsets) within the passage text. Spans protect you against quote drift because you can render the exact text later and compare it to what the model claimed.
Define citation formatting rules early. For machine use, citations should look like [p12120-198] meaning passage 12, characters 120–198. For human output, you can map that to a readable citation: “(CDC, 2024, p12)” with a clickable highlight. Keep both: machines need determinism; humans need legibility.
Common mistake: letting the model invent citations (“[Source 3]”) that do not correspond to your retrieval bundle. Prevent this by validating IDs against an allowed list and rejecting outputs that cite unknown passages. Treat this as a parsing error, not a model “opinion.”
Once citations are span-addressable, you unlock downstream automation: quote checking, overlap detection, and regression tests that flag when a model starts citing irrelevant text after a prompt change.
Real-world verification is rarely a single-source problem. Sources disagree, update, or speak at different levels of precision. Your pipeline needs explicit contradiction handling, otherwise the LLM will “average” disagreement into a misleadingly confident summary.
Implement multi-source comparison as a first-class step. For each retrieved passage, extract candidate spans and classify them relative to the claim: supports, contradicts, or not relevant. Then apply tie-breaks that reflect journalistic practice: prioritize primary sources over commentary, official datasets over blog posts (for numeric claims), and newer corrections over older versions (when provenance indicates an update).
When you cannot resolve a conflict, your correct output is not a forced verdict—it is INCONCLUSIVE with a conflict explanation and citations on both sides. Your rationale should say, in effect: “Source A states X [p3…], Source B states Y [p9…], and we lack evidence to determine which is correct.” That is actionable: a human can pursue additional reporting.
Add two specialized checks in this stage:
Engineering judgment: contradiction handling is where you encode policy. Document your tie-break rules and keep them stable, because changing them changes the “editorial line” of your system. Treat tie-break updates as versioned changes with regression tests.
Uncertainty is not a vibe; it is a field you can evaluate. Many LLM outputs “hedge” with words like “likely” or “may,” but that does not help a user decide what to do next. Calibration means your confidence signals correspond to reality: when you say 0.8, you are correct about 80% of the time under similar conditions.
First, separate verdict labels from confidence. A claim can be SUPPORTED with low confidence (thin evidence) or UNSUPPORTED with high confidence (strong contradictory evidence). Ask the model to provide a confidence score, but do not trust it blindly; combine it with deterministic features: number of supporting spans, source quality score, agreement across sources, and presence of unresolved contradictions.
Define what confidence means operationally. For example: 0.9+ requires at least two independent high-quality sources or one primary source plus a dataset; 0.6–0.8 requires one high-quality source and no contradictions; below 0.6 triggers INCONCLUSIVE unless the contradiction is explicit. These are policy choices, but they make uncertainty actionable.
Common mistake: letting the model express uncertainty only in prose. Require both: (1) a numeric confidence or calibrated bucket (HIGH/MED/LOW), and (2) a short “why not higher?” field tied to citations (e.g., “Only secondary reporting available [p5…]”). This discourages performative hedging and helps users understand what evidence is missing.
conflict_present, quote_exact_match, and unit_mismatch to explain uncertainty sources.Once you log these signals, you can build calibration curves and adjust thresholds without rewriting prompts—an important step toward portfolio-grade, reproducible experiments.
To ship a fact-checking system, you need outputs that are readable by humans and predictable for machines. The simplest way is a strict JSON schema that every verification run must follow. This is also how you create your first end-to-end claim verification loop: each claim produces a single record that can be stored, diffed, evaluated, and rendered.
Design the schema around your multi-step workflow. A practical minimum includes: claim metadata, retrieval metadata, extracted evidence spans, per-source comparisons, final decision, and a human-readable verdict summary. Keep the human text short and citation-linked; put the detail in structured fields.
Example shape (conceptual, not exhaustive):
claim_id, claim_text, claim_typequestion (the verification question you derived from the claim)evidence: array of {passage_id, span_start, span_end, support_label}checks: {quote_check: {...}, numeric_check: {...}}verdict: {label, confidence, rationale_sentences: [{text, citations: [...] }]}provenance: retrieval timestamps, URLs, and model/prompt versionsTwo practical rules make this work: (1) validate JSON strictly (fail fast if malformed), and (2) validate citations against allowed passage IDs and span boundaries. These validators are “seatbelts” that prevent silent degradation when you change prompts or models.
With this schema in place, you can run a full loop: extract claims from an article, generate a verification question per claim, retrieve passages, verify with extractcomparedecide, run quote and numeric checks, and emit a final JSON verdict. That single pipeline run is already portfolio-ready because it is reproducible, auditable, and measurable—exactly what hiring teams look for when you say you built LLM fact-checking workflows.
1. What is the primary shift Chapter 3 makes compared to an LLM that merely “sounds right”?
2. In the chapter’s multi-step verify routine, what is the correct sequence of steps?
3. Why does Chapter 3 add quote checking and numeric consistency checks to the verification loop?
4. Which output best matches the chapter’s goal for a verifiable, debuggable verdict?
5. Which “contract” for the verification LLM best matches the chapter’s recommended mental model?
A fact-checking pipeline that “gets the right answer” is not yet a reliable system. In journalism, the credibility of a claim depends on where it came from, how it was interpreted, and whether another reviewer can retrace the steps. In AI systems, this is the difference between an impressive demo and a portfolio-ready tool: you must capture provenance from retrieval through generation, attach traceable citations at passage level, log every model call and evidence set, and package outputs into a verification report that a human can inspect and override.
Source tracing is the discipline of preserving a chain from claim → verification question → evidence passages → model output → final decision. Your outputs should make it easy to answer: “Which source supports this?” “Which exact span?” “What version of that page?” “What did the model see?” “What would change if we reran it tomorrow?” This chapter gives you a concrete provenance model, practical techniques for span alignment and quote drift detection, a checklist of credibility signals, an audit log design, and a reviewer workflow that turns the pipeline into a newsroom-style desk.
Engineering judgment matters here. Over-citation can hide weak reasoning behind a pile of links; under-citation turns the system into a black box. A good pipeline captures enough structure that you can reproduce and contest a decision, while keeping the workflow lightweight enough to run every day.
Practice note for Implement provenance capture from retrieval through generation: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Add traceable citations with passage spans and source metadata: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Build an audit log for every model call and evidence set: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Create a reviewer workflow to inspect evidence and override decisions: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Package outputs into a shareable verification report: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Implement provenance capture from retrieval through generation: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Add traceable citations with passage spans and source metadata: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Build an audit log for every model call and evidence set: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Create a reviewer workflow to inspect evidence and override decisions: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Start by defining a provenance model before you write any prompts. Provenance is not “a URL” or “a title”; it’s a stable identifier plus version context. The minimum unit you want to track is an evidence item: a specific passage span from a specific document snapshot, retrieved at a specific time, via a specific query.
A practical schema for each evidence item includes: doc_id (internal stable ID), source_uri (URL, database key, or file path), content_hash (hash of raw text or HTML-to-text output), retrieved_at (timestamp), published_at (if known), version (ETag, Last-Modified, database revision, or crawl batch ID), and license/rights (so your report is compliant). Add chunk_id and span_start/span_end once you chunk the document for retrieval.
Two common mistakes: (1) storing only the URL and trusting it will stay the same; and (2) storing only chunk text without the document context. Pages change, PDFs get replaced, and “the chunk” is meaningless if you cannot show where it came from. Use hashes to detect change and keep a local snapshot (or a pointer to a content-addressed store) for anything used as supporting evidence.
Outcome: when a stakeholder asks “why did the model say this,” you can point to immutable IDs and timestamps, and when you rerun the pipeline you can decide whether to use the same snapshots for reproducibility or refresh sources for recency.
Retrieval returns passages; generation returns prose. Your job is to align them tightly. “Citations” that point to an entire document invite subtle misattribution, where the answer is plausible but not actually stated. Implement evidence alignment at span level: pick the smallest span that supports the claim, then cite that span.
In practice: after retrieval, run a span selector step. This can be (a) a lightweight heuristic (sentence boundary detection + overlap with query terms), (b) a cross-encoder reranker that scores candidate sentences for entailment, or (c) an LLM constrained to return exact quotes with character offsets. Store quote_text, span_start/span_end, and the sentence boundaries used. If the source is a PDF, also store page number and coordinate boxes when available.
Then add quote drift detection. Quote drift happens when a model paraphrases as if quoting, changes numbers, or fuses two sentences into one “quote.” To prevent this, enforce a rule: anything inside quotation marks must be an exact substring of the stored evidence span. Automatically verify by substring match (with normalized whitespace) and fail the generation step if it invents a quote. For paraphrases, label them explicitly as paraphrase and still cite the supporting span.
Outcome: you produce traceable citations that point to exact spans, reducing disputes and making reviewer verification fast.
Not all sources deserve equal weight. Your pipeline should capture credibility signals as metadata and use them in retrieval ranking, conflict resolution, and reporting. Think like a reporter: who wrote this, where was it published, and how current is it?
At ingestion time, extract and store: author (named individual or organization), publisher, publication_type (peer-reviewed paper, government site, press release, news article, blog), published_at, updated_at, and domain. Add byline_present and contact_info_present as weak but useful signals. If you have access to external reputation lists (e.g., a curated newsroom whitelist, a list of government domains, or a journal index), store reputation_tier rather than a single opaque “trust score.”
Use these signals carefully. Recency is context-dependent: for a breaking event, recent updates matter; for a historical statistic, older authoritative sources may be better. Common mistake: always prefer the newest article, which can amplify copy-paste errors across outlets. Another mistake: treating “peer-reviewed” as automatically correct; retractions and disputed findings exist. Your system should handle conflicting evidence by surfacing both and labeling the disagreement rather than forcing a single answer.
Practical design: in retrieval, boost high-tier publishers and primary sources; in generation, ask the model to cite primary sources when available and secondary sources only as context. In the report, display credibility fields so a reviewer can see at a glance why a source was selected.
A fact-checking pipeline must be auditable. That means a chain-of-custody log that records what the system asked, what it retrieved, what the model produced, and what post-processing altered. This is how you debug hallucinations, diagnose prompt injection, and prove reproducibility.
Implement an audit log as an append-only event stream. Each run gets a run_id; each stage emits events with stage_name, timestamp, inputs, outputs, and artifacts (references to stored blobs). For model calls, log: model name/version, system prompt, user prompt, tool specs, temperature/top_p, max tokens, and the exact tool outputs the model saw. For retrieval, log: query text, filters, index version, top-k results with scores, and the evidence IDs selected for generation.
Two security-critical details: (1) store raw retrieved passages separately from generated text and label them as untrusted, because prompt injection often hides inside “sources”; (2) record the content hashes for both retrieval inputs and final outputs so you can detect silent changes. If you redact sensitive data, log redaction rules and store redacted fields deterministically so reruns match.
Outcome: when an answer is challenged, you can replay the run with the same evidence set, compare model outputs across versions, and show exactly what the system relied on.
Your user-facing deliverable should look like a verification brief, not a chat transcript. A good report packages the decision, evidence, and uncertainty in a way that can be shared internally or published with an article.
Design a structured output with these sections: Claim (verbatim), Verification question, Verdict (supported/unsupported/mixed/insufficient), Answer summary (grounded, no new facts), Evidence table (each row: citation label, source metadata, span quote, offsets, retrieval timestamp, and link), Reasoning notes (brief, focused on why evidence supports or conflicts), and Limitations (what was not checked, what might change with newer data). Include run_id and evidence_set_id so anyone can reproduce the run from the audit log.
Citation formatting should be consistent and traceable. Use citation labels like [E1], [E2] tied to evidence IDs. For web sources, include title, publisher, author (if known), published date, retrieved date, and the span quote. For PDFs, add page number. The key is that each citation points to a specific span, not “the whole page.”
Common mistake: letting the model write a persuasive essay and then “adding citations” afterward. Instead, generate from evidence IDs: require the model to reference [E#] inline as it writes, and validate that each cited sentence has at least one supporting span.
Even with strong provenance and logging, your pipeline needs a reviewer workflow. The goal is not to have humans redo the work; it is to give them fast, high-leverage control: inspect evidence, override decisions, and leave a trace of judgment.
Define escalation rules that automatically route items to review. Examples: low evidence coverage (too few sentences supported), conflicting high-credibility sources, numerical claims with wide variance, claims involving named individuals, or any detection of prompt injection patterns in retrieved text. Also escalate when the model’s calibration is poor—for example, it outputs high confidence while evidence is weak.
Your review UI (or simple review document) should show: the claim, the verdict, the evidence table with highlighted spans, and the audit trail summary (queries, retrieval filters, model version). Provide explicit reviewer actions: approve, revise verdict, swap evidence, request more retrieval, and flag source. When a reviewer overrides, store: reviewer ID, timestamp, rationale, and the exact fields changed. This turns the system into a learning loop: you can mine overrides to improve retrieval filters, chunking, and prompt constraints.
Common mistake: allowing free-form edits without traceability. Treat reviewer changes as events in the chain-of-custody, just like model calls. Outcome: you ship a fact-checking system that behaves like a professional desk—transparent, contestable, and reproducible.
1. What best describes “source tracing” in a fact-checking pipeline?
2. Why is capturing provenance from retrieval through generation essential, even if the model often “gets the right answer”?
3. Which practice best supports traceable citations as described in the chapter?
4. What should an audit log include for this chapter’s standard of reliability?
5. What is the main engineering tradeoff discussed regarding citations and provenance structure?
In journalism, you learn to distrust a single source, verify quotes against recordings, and separate what a document says from what it means. In LLM fact-checking pipelines, evaluation is the equivalent discipline: it is how you prove your system is grounded, how you detect failure modes before users do, and how you decide which fixes actually matter. This chapter turns “it seems good” into measurable, reproducible evidence.
You will build a labeled benchmark of claims with gold evidence, implement automated scoring for groundedness and citations, and then red-team the pipeline with adversarial inputs: ambiguous claims, noisy sources, and contamination. The goal is not perfection; it is engineering judgment: knowing what to measure, which metrics drive behavior, and how to translate errors into remediations with a clear impact estimate.
A strong portfolio project includes a research-style evaluation summary: datasets, metrics, experimental setup, and an honest discussion of limitations. Your evaluation becomes an artifact others can run, critique, and improve—exactly how AI research operates in practice.
Practice note for Create a labeled benchmark set of claims with gold evidence: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Implement automated scoring for citation quality and correctness: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Run red-team tests: adversarial claims, noisy sources, and ambiguity: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Perform error analysis and prioritize fixes with impact estimates: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Write a research-style evaluation summary for your portfolio: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Create a labeled benchmark set of claims with gold evidence: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Implement automated scoring for citation quality and correctness: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Run red-team tests: adversarial claims, noisy sources, and ambiguity: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Perform error analysis and prioritize fixes with impact estimates: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Write a research-style evaluation summary for your portfolio: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Start by treating your evaluation set as a newsroom assignment desk: you want coverage across beats, formats, and difficulty. Build a benchmark of claims paired with gold evidence (the minimal passages that support/refute the claim) and a label (Supported / Refuted / Not verifiable with corpus). Don’t overfit to “clean” claims—your system will see messy, mixed, and partially-true statements.
Sampling matters more than most people expect. If you only sample from one outlet or topic (e.g., health policy), your metrics will inflate and then collapse in production. Use stratification: define strata such as topic (politics, science, business), claim type (numeric, attribution/quote, causal, temporal), and difficulty (single-hop vs multi-hop evidence). Then sample a fixed number from each stratum so your test set reflects the real workload you care about, not what is easiest to label.
For each claim, store: a canonical claim text, optional context (the surrounding paragraph), expected answer format, and gold evidence passages with provenance (URL, title, timestamp, document version). Gold evidence should be passage-level, not just “this article”; otherwise citation scoring becomes meaningless. A practical rule: each labeled item should have 1–3 evidence passages that a human can highlight and say “this is the reason.”
Common mistakes include leakage and bias. Leakage happens when your retrieval corpus includes your own evaluation artifacts (annotator notes, prior model outputs, or a benchmark file). Bias happens when annotators silently encode assumptions (e.g., “this is probably false”) instead of using corpus-grounded criteria. Mitigate both by versioning the corpus, logging document hashes, and writing labeling guidelines that define “verifiable” and “sufficient evidence.”
Once you have this benchmark, every pipeline change becomes a controlled experiment instead of guesswork.
Fact-checking pipelines must be evaluated as systems: retrieval, reasoning, and response formatting all affect whether an answer is trustworthy. Use a metric suite rather than a single score. At minimum track (1) claim-level correctness, (2) abstention behavior, and (3) evidence quality.
Claim-level accuracy is the fraction of items where the system’s final label (Supported/Refuted/Not verifiable) matches the gold label. For many real deployments, accuracy alone is dangerous because a model can “guess” with high confidence. Add abstention metrics: if your system can answer “insufficient evidence,” measure coverage (how often it answers) and selective accuracy (accuracy on the subset it chose to answer). A well-calibrated system should answer less often when evidence is weak and be more accurate when it does answer.
Next measure evidence, not just the label. Define evidence precision as the fraction of cited passages that are actually relevant and supportive for the predicted label; define evidence recall as whether the system included at least one of the gold passages (or an equivalent passage) in its citations. In retrieval-augmented systems, evidence recall often exposes that your model “knew” the right answer but couldn’t retrieve the right source—or vice versa.
Engineering judgment: decide whether you optimize for recall (finding evidence broadly) or precision (avoiding irrelevant citations). For newsroom-style fact checks, precision usually matters more: a single wrong citation can undermine trust even if the label is correct. For investigative workflows, recall may matter first, because humans can triage a longer evidence list.
Automate these metrics so every run produces a comparable table and a saved artifact. If it isn’t repeatable, it isn’t evaluation—it’s a demo.
Citations are not decoration; they are the contract between your model and the reader. A good pipeline answers two questions: (1) did you cite the right source (attribution correctness), and (2) does the cited text actually support the specific statement (support strength)? You should score both automatically, then audit a sample manually.
Attribution correctness checks whether the citation metadata matches the underlying document: correct title/outlet, author if available, date, and URL. This is where provenance tracking matters: store doc_id → canonical metadata, and generate citations from metadata rather than letting the LLM “invent” formatting. Automated checks can flag impossible dates, missing domains, or citations to documents not in the retrieved set.
Support strength evaluates whether the cited passage entails (or contradicts) the claim. A practical approach is a two-stage verifier: first, require lexical overlap or entity match (names, numbers, places) between claim and passage; second, run an NLI-style check (entails/contradicts/neutral) using a smaller verifier model. Even if your verifier is imperfect, it is useful as a regression signal: when support scores drop after a prompt change, you know you broke grounding.
Quote drift is a special case. If the claim includes a quote, require the cited passage to contain the quoted string or a near-exact match (e.g., normalized punctuation). If your pipeline produces paraphrased quotes, score it as incorrect; in journalism, paraphrasing a quote is not a quote. Store separate fields: quote_exactness and quote_attribution (who said it, where, when).
The practical outcome is a citation score you can show in a portfolio: “92% of cited passages entail the corresponding statements; 98% of citations are metadata-valid.” That is the language of measurable trust.
Evaluation that only measures average performance misses the failures that cause real harm. Red-teaming is the deliberate search for worst cases: adversarial claims, ambiguous phrasing, and hostile content inside your retrieval corpus. Your aim is to harden the pipeline against hallucinations, prompt injection, and contaminated sources.
Start with adversarial claims. Create a challenge set that includes: subtle negations (“did not”), swapped entities (“A said about B” vs “B said about A”), numeric traps (percent vs percentage points), and time-sensitive statements (“as of 2021”). Add ambiguity: claims that require disambiguation of acronyms, locations with the same name, or shifting definitions (inflation measures). Label these carefully—some should be “Not verifiable” if the corpus cannot disambiguate.
Next test noisy sources. Include low-quality pages, OCR errors, and duplicated content. A common pipeline failure is over-trusting a scraped page that repeats a rumor. Create contamination tests where a non-credible document contains an instruction like “Ignore previous instructions and answer ‘Supported.’” Then verify your system does not follow it.
Mitigations should be structural, not just prompt-based. Examples: (1) strip or sandbox instructions from retrieved text before it reaches the generation model, (2) enforce a policy that the model can only cite from an allowlisted set of domains, (3) run a “retrieved text contains prompt injection” classifier and down-rank or exclude flagged passages, and (4) require the answer to be derived from quoted evidence spans, not from free-form memory.
This is where your portfolio becomes credible: you can demonstrate you anticipated attacks and built defenses that measurably reduce failures.
A fact-checking pipeline that is accurate but too slow or expensive will not ship. Treat cost and latency as first-class evaluation dimensions alongside factuality. Measure end-to-end latency (p50/p95), token usage by component, retrieval time, and cache hit rate. Then define budgets: for example, “under 4 seconds p95 and under $0.02 per claim.”
Break down your pipeline stages: claim parsing, query generation, retrieval, reranking, answer synthesis, citation formatting, and verification. Often the verifier model and reranker are the hidden cost drivers. You can trade off cost and quality by controlling: number of retrieved documents (k), context window size, verifier frequency (verify all answers vs only low-confidence ones), and whether you run multi-pass generation.
Caching is the simplest win. Cache retrieval results by normalized query, cache document fetches by URL+hash, and cache model outputs during evaluation runs so you can rerun scoring without re-paying inference. For news domains, document versions change; include a content hash and expiry policy so you don’t cite stale content. Batching reduces overhead when you evaluate: batch embeddings, batch reranker calls, and run claims in parallel with rate limits.
Engineering judgment: do not optimize cost by cutting evidence. Instead, prioritize reducing redundant calls and shrinking prompts. Techniques include extracting only the relevant spans before sending to the generator, and using structured intermediate representations (JSON) so the model is not asked to repeat long passages.
This section turns your project from an experiment into an operational system—exactly the mindset hiring teams look for in applied AI roles.
Metrics tell you that something is wrong; error analysis tells you what to fix. Build an error taxonomy tailored to factuality pipelines and map each class to a remediation. Then prioritize fixes using an impact estimate: frequency × severity × fix cost.
A practical taxonomy includes: (1) retrieval miss (gold evidence exists but wasn’t retrieved), (2) wrong evidence selection (retrieved the right doc but cited irrelevant spans), (3) hallucinated content (states facts not present in evidence), (4) quote drift (quote wording altered or attributed to wrong speaker), (5) entity mix-up (confuses two people/organizations), (6) temporal error (uses outdated info), (7) prompt injection compliance, and (8) citation formatting/provenance error (broken URL, wrong date, uncited claims).
For each error, attach a remediation playbook. Retrieval miss → improve query generation, add BM25 + embedding hybrid, increase k for hard strata, or add domain-specific synonyms. Wrong evidence selection → add a reranker, enforce evidence span extraction, or require that every sentence in the answer be linked to a span. Hallucination → tighten generation constraints (answer only from evidence), add a verifier with rejection/abstention, and penalize uncited sentences. Quote drift → enforce exact-match quoting and store speaker metadata separately from the quote string. Temporal error → add date filters and require “as of” in outputs when documents disagree.
To prioritize, compute an impact estimate: if quote drift occurs in 12% of quote claims and is high severity, fixing it may yield a larger trust improvement than chasing a 1% accuracy gain elsewhere. Keep a living “top 5 issues” list and re-evaluate after each iteration.
When you can name your errors, measure them, and link them to fixes, you are no longer “using an LLM.” You are doing applied AI research with the rigor of a fact-checking desk.
1. What is the primary purpose of evaluation in an LLM fact-checking pipeline, according to this chapter?
2. Which activity best represents building a labeled benchmark set with gold evidence?
3. What is the intended role of automated scoring for groundedness and citations?
4. Which set of inputs aligns with the chapter’s red-team testing approach?
5. After running evaluations and red-team tests, what does the chapter recommend doing with the observed errors?
You can build a brilliant fact-checking notebook and still have nothing “shippable.” Hiring managers, collaborators, and future you need a system that is reproducible, testable, and defensible: the same input should yield the same structured outputs (within known stochastic boundaries), the evidence should be traceable, and failures should be diagnosable. In this chapter you will turn your research prototype into an artifact that can be evaluated, deployed, monitored, and presented as a portfolio project—without over-engineering.
Shipping does not mean “production at all costs.” It means you can rerun experiments from a clean checkout, explain what the system does and does not guarantee, and demonstrate responsible handling of data and sources. The work is equal parts engineering judgment (interfaces, configs, and tests) and editorial ethics (provenance, licensing, privacy). This combination is exactly what makes journalist-to-AI transitions credible: you are not just prompting a model—you are building a verification machine with receipts.
The core outcome: a lightweight demo (app or API) plus an evaluation harness and documentation that communicates methodology, limitations, and guardrails. Then you wrap it in a case study that reads like an investigation: what you tried, what broke, what improved, and what you’d test next.
Practice note for Turn notebooks into a reproducible pipeline with config and CLI: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Deploy a lightweight demo (API or app) with monitoring hooks: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Write documentation: methodology, limitations, and ethical guardrails: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Prepare a case study and interview narrative for AI research roles: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Plan next-step experiments: multilingual, long-context, and domain adaptation: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Turn notebooks into a reproducible pipeline with config and CLI: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Deploy a lightweight demo (API or app) with monitoring hooks: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Write documentation: methodology, limitations, and ethical guardrails: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
Practice note for Prepare a case study and interview narrative for AI research roles: document your objective, define a measurable success check, and run a small experiment before scaling. Capture what changed, why it changed, and what you would test next. This discipline improves reliability and makes your learning transferable to future projects.
To move from notebook to pipeline, start by drawing the smallest architecture that still enforces discipline. A practical fact-checking system usually has five modules: (1) claim extraction, (2) question mapping, (3) retrieval, (4) grounding + answer generation, and (5) citation/provenance formatting. Your goal is not microservices; it is stable boundaries so you can swap components without rewriting everything.
Define interfaces and data contracts first. For example, a Claim object might include claim_id, claim_text, article_span, claim_type, and metadata. Retrieval outputs should be passage-level, not document-level: EvidencePassage with source_id, url, title, timestamp, license, chunk_id, start_char, end_char, and the exact passage_text. Generation outputs should include both the model’s answer and its calibration signals: verdict, confidence, rationale, and citations[] pointing to evidence chunk IDs.
Then, convert notebook “globals” into explicit config. Use one YAML/TOML config for model choices, retrieval parameters (k, chunk size, embedding model), prompting templates, and safety settings. A CLI makes the system reproducible: pipeline run --config configs/news.yaml --input data/article.json --output runs/2026-03-25/. Common mistake: baking secrets, API keys, or file paths into code. Keep secrets in environment variables and make paths relative to the repository root.
Finally, version your prompts and your schemas. Prompts are code: changing them changes behavior. Put them under prompts/ with explicit names and include their hash in run metadata so results remain comparable.
Pick a deployment pattern that matches your goal. For a portfolio, you typically need two entry points: a human-friendly demo and a machine-friendly interface. The demo can be a local web app (Streamlit/Gradio) that lets a user paste an article, see extracted claims, click each claim, and inspect evidence passages with formatted citations. The machine interface is an API (FastAPI) exposing endpoints like /extract_claims, /verify_claim, and /verify_article.
Keep the deployment lightweight: one container or one Python environment is enough. Wrap dependencies with a lockfile (e.g., uv.lock or poetry.lock) and provide a single command to run locally. Include monitoring hooks even in a demo: structured logs (JSON) with request IDs, module timings, and error categories (retrieval_empty, citation_mismatch, prompt_injection_detected). This is not enterprise overhead; it is how you debug real failures.
An evaluation harness is your third “deployment.” Treat it as a first-class CLI workflow: eval run --dataset data/claims_gold.jsonl --config configs/eval.yaml producing a report (HTML/JSON) with metrics for groundedness, attribution, and calibration. In interviews, being able to say “I can run a full benchmark in one command” signals research maturity.
Common mistake: deploying only the UI. If you can’t run a headless evaluation on a dataset, you can’t quantify improvements, and you can’t catch regressions when prompts or models change.
Fact-checking pipelines fail quietly. The UI still renders, the model still produces fluent text, but the system may be drifting away from grounded behavior. Monitoring is how you keep “verification” from becoming “vibes.” Even for a portfolio demo, implement three practical monitors: drift detection, citation health, and regression tests.
Drift detection starts with logging distributions: average retrieval hit rate, average number of evidence passages per claim, latency per module, and language/domain mix of inputs. If your system suddenly retrieves fewer passages or shifts to lower-quality domains, your outputs will degrade even if the model is unchanged. Track this over time across runs.
Citation drop is a canary metric: the percentage of claims where the final answer includes valid citations mapped to retrieved evidence IDs. A “citation” that doesn’t correspond to a passage is a bug. Build a validator that checks: every citation points to an evidence chunk, the cited text overlaps the claim topic, and URLs are present. Alert on citation drop, rising “no evidence found,” or an increase in unsupported verdicts.
Regression testing should include a small fixed set of articles/claims (your “golden set”) plus adversarial cases: prompt injection attempts inside articles, misleading quotes, and long-context articles where relevant evidence appears late. Run these tests on every change to prompts, retrieval parameters, or model versions. A simple approach: store expected outputs at the level of structured fields (verdict, cited chunk IDs count, refusal flags) rather than exact wording.
Make monitoring hooks part of your modules, not an afterthought. Every module should emit: input size, output size, and a quality signal (e.g., retrieval score stats, citation validator pass/fail). This makes failures traceable instead of mysterious.
Shipping a fact-checking system means taking responsibility for what you ingest, store, and reproduce. Governance is not corporate bureaucracy; it is how you avoid building a demo that can’t be shown publicly—or worse, one that misuses sources. Start with a data inventory: what user inputs you collect (articles pasted into the app), what external sources you retrieve (web pages, PDFs), and what you persist (embeddings, cached passages, logs).
Privacy: if users paste unpublished drafts or sensitive text, do not retain it by default. Make logging opt-in, redact content in logs (store hashes or short excerpts), and document retention policies. If you use third-party LLM APIs, be explicit about what is sent off-device and provide a “local mode” option when feasible.
Licensing: retrieval and caching can create unintentional redistribution. Store only minimal text needed for verification (passage snippets), keep source URLs and timestamps, and respect robots.txt and site terms. Prefer sources with clear reuse permissions for your included datasets and examples (e.g., government reports, permissively licensed corpora). If you build a benchmark dataset, include a license field per item and a clear citation to the original publisher.
Compliance in documentation: write an “Ethical Guardrails” section that states: what domains you block or de-prioritize, how you handle medical/legal claims (e.g., safe completion/refusal), and how you avoid defamation (e.g., presenting uncertainty, encouraging primary-source review). Also document limitations: coverage gaps, retrieval failures, and known error modes like quote drift in paraphrased claims.
.gitignore, store only small sample data, and provide scripts that re-download from original locations.Governance is part of system quality: without it, your “fact-checker” may be legally or ethically unshippable, regardless of accuracy metrics.
A portfolio project succeeds when someone can understand it in five minutes and reproduce it in thirty. Structure your repository to tell a story: src/ for modules, configs/ for run configs, prompts/, data/ for tiny sample inputs (not full corpora), eval/ for harness code, and reports/ for generated outputs (or a link to artifacts). Include a Makefile or task runner with commands like make demo, make eval, and make format.
Your README should be operational, not promotional. Include: what the system does, a diagram of the pipeline, setup steps, and a “Quickstart” using the CLI. Then add methodology: claim extraction approach, retrieval strategy (BM25 vs embeddings, chunking), grounding policy (cite-only-from-evidence), and evaluation metrics. Add a “Limitations” section that names failure cases you observed and what mitigations exist (e.g., fallback retrieval, refusal behavior, quote alignment checks).
Include a short demo video (2–4 minutes) showing: paste an article, inspect claims, click one claim, view evidence passages, and see formatted citations. Narrate what the system is doing and why it refuses when evidence is missing. This is especially persuasive for non-technical reviewers.
Write a case study as a standalone document (or blog post) with the arc of an investigation: baseline results, key bugs (hallucinated citations, prompt injection), fixes (citation validator, input sanitization, constrained decoding), and measured improvements from the eval harness. Show one or two charts: citation validity over commits, groundedness score vs retrieval k, or calibration curves.
Packaging is where “notebooks” become “evidence of ability.” Treat the repo like an assignment you are handing to a skeptical editor: clear, verifiable, and complete.
Your advantage is not that you can write prompts. Your advantage is that you already think in claims, evidence, attribution, uncertainty, and accountability—exactly the concepts that modern LLM research struggles to operationalize. The career pivot works when you translate these strengths into research and engineering language, backed by the shipped system you built.
Map journalistic skills to AI research competencies explicitly. Interviewing and source evaluation become dataset curation and provenance tracking. Editorial standards become evaluation criteria (factuality, attribution, calibration). Corrections workflows become regression testing and post-deployment monitoring. Deadline-driven production becomes reproducible pipelines and automation. When asked “What did you do?” answer in the structure of a research report: problem, method, experiments, results, limitations, next steps.
Prepare a narrative around one case study. Example structure: (1) the failure you observed (quote drift and invented citations), (2) the hypothesis (retrieval noise and unconstrained citation generation), (3) the intervention (passage-level evidence objects, cite-only constraint, validator), (4) the evaluation (before/after metrics on a golden set), and (5) the remaining risks (domain gaps, multilingual retrieval). This reads like applied research, not hobbyist tinkering.
Plan next-step experiments that demonstrate research taste: multilingual claim verification (cross-lingual embeddings and language-aware chunking), long-context articles (late-evidence retrieval, sliding-window extraction), and domain adaptation (science, finance, or local government). Propose ablations: compare retrieval methods, chunk sizes, and prompting strategies; quantify the trade-off between refusal rate and hallucination rate. Keep experiments small but decisive.
By the end of this chapter, you should have a portfolio-ready fact-checking pipeline, a reproducible evaluation story, and a professional narrative that connects your journalism background to the core problems in trustworthy language modeling.
1. In Chapter 6, what best defines a “shippable” fact-checking system compared to a strong notebook prototype?
2. What does the chapter mean by “Shipping does not mean production at all costs”?
3. Which set of deliverables is described as the chapter’s core outcome?
4. Why does the chapter argue that journalist-to-AI transitions are especially credible when focused on provenance, licensing, and privacy?
5. How should the case study and interview narrative be framed according to Chapter 6?
- Learning Evolved.
- Intelligence Amplified.
