TruthBase: verifizierbares RAG mit Zitaten, die zur markierten Textstelle führen

Das Problem

Jede RAG-Demo kann eine Antwort mit einem Zitat ausgeben. Kaum eine kann das Zitat belegen. Das übliche Muster („[1] report.pdf, S. 12“) verlangt vom Leser, das Dokument zu öffnen und selbst zu suchen; in der Praxis überprüft deshalb niemand etwas, und das Zitat ist Dekoration. Meine These für TruthBase lautet: Vertrauen braucht Belege. Ein Klick auf ein Zitat soll im PDF-Viewer genau zur richtigen Seite springen und genau die Passage hervorheben, die den Satz stützt, den Sie gerade gelesen haben.

Diese eine Interaktion ist das ganze Projekt. Sie erzwingt den größten Teil der interessanten Technik: Positionen müssen schon bei der Ingestion erfasst werden (sie nachzurüsten hieße, den gesamten Korpus neu zu parsen), sie müssen skalierungsunabhängig gespeichert und über alle Zoomstufen hinweg exakt rekonstruiert werden. Und die Retrieval-Pipeline dahinter muss gut genug sein, dass die hervorgehobene Passage die Antwort wirklich stützt.

Architektur

TruthBase läuft live unter truthbase.elbaymalik.com: eine einzige Nuxt-4-App, deren Arbeit mit Secrets und hohem Rechenbedarf (Embedding, Retrieval, Generierung) in Nitro-Server-Routen liegt, deployt als eine einzige Vercel Function auf Node 24 in dub1, neben der Supabase-Datenbank in AWS eu-west-1. Nichts Geheimes erreicht den Client. Der Demo-Korpus besteht aus vier öffentlichen PDFs (NIST CSF 2.0, NIST AI RMF 1.0 sowie die Paper zu RAPTOR und Self-RAG), eingespielt über eine CLI des Betreibers und nicht über den Browser.

Die Ingestion liest die Textelemente jeder Seite mit unpdf und PDF.js aus und spielt dann die Operator-Liste der Seite mit der Textvorschub-Mathematik von PDF.js nach, um die x-Ausdehnung jeder Glyphe zu erhalten. Das Chunking packt Sätze seitengebunden zusammen: bis 800 Zeichen mit 15 % Overlap, die kleinste Größe, bei der alle 60 Golden-Spans in einem Chunk liegen, denn die Markierung, die man sieht, ist der Chunk. Jeder Chunk speichert ein Rect pro gerenderter Zeile im PDF-Raum (chunks.highlight jsonb), neben einem generierten tsvector und einem Vektor von gemini-embedding-001 mit 768 Dimensionen, von Hand L2-normalisiert, weil Google nur die volle 3072-dimensionale Ausgabe normalisiert. Der Viewer zeichnet die gespeicherten Rects so, wie sie sind, bei jedem Zoom mit viewport.convertToViewportPoint von PDF.js umgerechnet. Er leitet sie nie aus der Textebene des Browsers ab, die Text in einer Ersatzschrift setzt; passt der gerenderte Text nicht mehr zum Chunk, sucht er die Passage über den Text und zeigt den Hinweis „ungefähr“.

Eine Frage passiert zuerst consume_quotas, einen einzigen Postgres-Aufruf, der die Zähler des Clients pro Minute und pro Tag und das globale Tagesbudget der Demo prüft, alles oder nichts, und noch vor jedem Modellaufruf mit 429 antwortet. Die Frage wird eingebettet, während ein selbstgesteuerter Rewriter auf gpt-oss-20b von Groq entscheidet, ob sie mehrdeutig genug ist, um sie in bis zu drei Anfragen aufzuteilen. Das Retrieval ist hybrid und bleibt in Postgres: hybrid_search, ein einziger SQL-RPC, fusioniert einen Volltext-Arm und einen exakten Kosinus-Arm per gewichteter Reciprocal Rank Fusion. Ein Listwise-LLM-Reranker auf gpt-oss-20b sortiert die fusionierten 15 besten; seine ersten vier Treffer stehen vorn, die fusionierte Reihenfolge füllt den Rest bis zu acht Quellen auf. Umformulieren und Reranking sind zur Laufzeit optional: Bei einem Fehler oder Timeout gilt die fusionierte Reihenfolge. Der Server streamt zuerst die Quellen mit ihren gespeicherten Rects, dann die Antwort von gpt-oss-120b bei Groq (Gemini Flash-Lite, wenn Groq ausfällt) über das Vercel AI SDK v7; sie zitiert mit [n]-Markern oder antwortet NO_ANSWER. Jede Chat-Anfrage wird nach Langfuse getraced. Das Entscheidungsprotokoll weiter unten hält fest, was dahintersteht, jeweils mit der Alternative, gegen die es sich durchgesetzt hat.

Aufbau der Evaluierung

Die Referenz ist ein Golden Set aus 50 Fragen über die vier PDFs: 45 beantwortbare, jede mit dem exakten stützenden Zitat und der Seitenzahl, und 5 unbeantwortbare (TruthBase docs/golden/golden.json). Bei n = 45 verschiebt eine einzige Frage eine Kennzahl um 2,2 Punkte. Dieselben Datensätze treiben die Playwright-Tests der Markierung, denn „Hat die Eval den richtigen Chunk zitiert?“ und „Ist die Markierung auf dem richtigen Rect gelandet?“ sind dieselbe Frage auf zwei Ebenen.

Die Evaluierung läuft auf zwei Ebenen. Ein deterministisches Retrieval-Gate ist in der CI für jeden Pull Request eingerichtet (sein letzter CI-Lauf war am 21. Oktober 2026): das echte hybrid_search auf einer eingecheckten Korpus-Fixture, das bei jedem Rückgang gegenüber TruthBase docs/evals/retrieval-baseline.json scheitert. Die modellabhängigen Evals verbrauchen kostenloses Kontingent und laufen deshalb auf Abruf: ein Skript pro Retrieval-Technik und eine LLM-Eval mit promptfoo und einem eigenen Judge-Modell, wöchentlich eingeplant.

Der Plan benannte, was ihn widerlegen würde: Schlägt die hybride Suche beim Recall auf dem Golden Set die rein dichte Suche nicht, wird zuerst das Chunking überarbeitet, bevor weitere Retrieval-Kniffe dazukommen. In Phase 4 lagen beide gleichauf bei 73 % Recall@8 (TruthBase docs/evals/phase-4-baseline.json). Eine Prüfung ergab, dass der Keyword-Arm alle Begriffe per AND verknüpfte und allein auf 27 % kam. Mit OR über die Lexeme der Frage selbst, Gewichten und k aus einem Raster von 72 Konfigurationen mit Kreuzvalidierung, stieg der hybride Recall@8 auf 87 % gegenüber 76 % bei rein dichter Suche, auf 45 beantwortbaren Fragen über 564 Chunks. Mit den ausgelieferten 15 Kandidaten hob der Reranker MRR von 0,515 auf 0,735, nDCG@5 von 0,638 auf 0,811 und Recall@5 von 76 % auf 84 % (TruthBase docs/evals/phase-7-groq-20b-15.json). Das Umformulieren mit dem ausgelieferten gpt-oss-20b hob Recall@5 bei den vier mehrdeutigen Fragen von 75 % auf 100 % und insgesamt von 76 % auf 80 % und ließ Recall@8 bei 87 % (TruthBase docs/evals/phase-8-groq-20b-gated.json).

Die letzte Antwort-Eval prüft die ausgelieferte Pipeline Ende zu Ende auf allen 50 Fragen: Umformulieren und Reranking auf gpt-oss-20b, Antworten von gpt-oss-120b (TruthBase docs/evals/phase-8-groq.json). Sie verweigerte alle 5 unbeantwortbaren Fragen, beantwortete 93 % (42 von 45) der beantwortbaren und keine davon ohne Zitat. Mindestens ein Zitat war bei 86 % der beantworteten Fragen richtig, bei 80 % der beantwortbaren, gegenüber 69 % im Lauf aus Phase 5. Die Zitatpräzision lag bei 56 %: eine Untergrenze, denn ein Zitat auf eine richtige Passage, die nicht die Golden-Evidenz ist, zählt als falsch. Die falschen Verweigerungen sanken von 7 im Lauf aus Phase 5 auf 3 und liegen damit weiter über dem Ziel von höchstens 1: zwei Fragen, deren Evidenz das Retrieval nicht findet, und eine Tabelle, die die Extraktion zu Fließtext gemacht hat. Der erste vollständige promptfoo-Lauf bewertete danach die Faithfulness mit 95,2 % und die Zitatpräzision mit 92,5 % (TruthBase docs/evals/phase-9-llm.json, 23. Oktober 2026), mit einem qwen-Modell als Judge und Zielen von 0,90. Eine Prüfung von 5 Antworten von Hand zeigte, dass der Judge zu nachsichtig ist, wenn er Antworten in Aussagen zerlegt und ihnen Zitate zuordnet. Für diese Antworten korrigiert liegen die gepoolten Werte bei etwa 92–94 % und 88–90 %. Der Lauf scheitert weiter an seinem Gate mit 4 falschen Verweigerungen, daher verzeichnet das Repository noch keine LLM-Baseline.

Die Markierung selbst wird auf drei Ebenen geprüft. pnpm check:viewer steuert den echten Viewer in Headless Chromium über alle 60 Golden-Spans bei Zoom 50, 100 und 200 %: Seit dem 25. Oktober 2026 bestehen alle 180 Prüfungen gegen den gehosteten Korpus, mit einem Platzierungsfehler von höchstens 0,03 px. Vitest hält die Span-Kanten innerhalb von ±0,05 pt an MuPDF, einer unabhängigen PDF-Engine. Playwright wiederholt die Prüfungen von Geometrie und Farbdeckung in der CI, zuletzt am 21. Oktober 2026. Davor verursachten zwei Fälle vier Fehlschläge: ein großer Σ-Operator, der unter die Em-Box ragte, die das vertikale Modell abdeckt, und ein als Vektorgrafik gezeichneter Rahmen, der Seitengrafik ist und kein Text. Der Operator bekommt seine Box jetzt aus den Glyphen-Umrissen, und die Prüfung der Farbdeckung zählt nur Textfarbe.

Kosten und Latenz als Entwurfsvorgaben

Das ursprüngliche Budget war eine harte Obergrenze von 5 EUR/Monat. Die Live-Demo kostet 0 EUR/Monat: Jeder Dienst läuft im Free Tier, und die Grenzen der Free Tiers waren Eingangsgrößen für den Entwurf, keine Überraschungen (TruthBase README.md, Cost and free-tier limits). Groq erlaubt jedem Modell 8K Tokens pro Minute, 1K Anfragen und 200K Tokens pro Tag; deshalb laufen die Antworten auf gpt-oss-120b und Umformulieren und Reranking auf gpt-oss-20b, jedes gegen sein eigenes Kontingent. Postgres setzt 10 Chats pro Minute und 30 pro Tag je Client durch und ein Budget von 80 Chats pro Tag für die ganze Demo; nach rund 60 erweiterten Chats am Tag ist gpt-oss-20b erschöpft, und der Chat antwortet aus der fusionierten Reihenfolge. Die kostenlosen 500 MB von Supabase fassen die 564 Chunks in rund 2 MB an Vektoren, und ein Keep-alive-Workflow ist zweimal pro Woche gegen die Pause nach 7 Tagen Inaktivität eingeplant; sein letzter erfolgreicher Lauf war am 19. Oktober 2026. Vercel Hobby erlaubt 4 Active-CPU-Stunden im Monat, und das reicht, weil das Warten auf ein Modell nicht als aktive CPU zählt.

Auf einem lokalen Produktions-Build bewertet Lighthouse die Startseite mit 98 auf Mobilgeräten und 100 auf dem Desktop, mit 100 für Barrierefreiheit, einem mobilen LCP von 2,40 s und einem CLS von 0 (Lighthouse 13.5.0, Median aus 3 Läufen, 2026-10-20). Eine Stichprobe auf dem Live-Deployment am 21. Oktober 2026 ergab 1,7 s für eine Suche und 1,5 s bis zum ersten Token einer Chat-Antwort: eine Messung, kein Perzentil. Traces auf dem Dev-Server zeigen 1,35–1,6 s bis zum ersten Token ohne Umformulieren und 2,2–2,9 s, wenn die Frage umformuliert wird (TruthBase docs/TECH_NOTES.md §15); das p50 bei echtem Traffic hängt also davon ab, wie viele Fragen umformuliert werden, und bleibt ausstehend, bis Langfuse diesen Traffic hat. Auch der Tokenverbrauch pro Anfrage ist nicht veröffentlicht: Langfuse erfasst Tokens pro Modellaufruf, und allein der Rewriter kostet rund 650 Tokens pro Frage, aber ein Wert für die ganze Anfrage ist noch nicht erhoben.

Was steht, was als Nächstes kommt

TruthBase läuft seit dem 21. Oktober 2026 live unter truthbase.elbaymalik.com, ohne Anmeldung: Frage stellen, auf ein Zitat klicken, und das PDF öffnet sich auf der richtigen Seite mit markierter Passage. Die Phasen 0 bis 15 der Roadmap sind gebaut, vom Golden Set, der Ingestion und dem Viewer mit Markierung über hybride Suche, Reranking, Umformulieren, Tracing, Missbrauchsschutz und Barrierefreiheit bis zu den Testsuiten in Vitest und Playwright und dem Deployment, bis auf eine: Die Eval-Harness (Phase 9) bleibt offen, bis ihr erster vollständiger Lauf mit promptfoo vorliegt. Reranking und Umformulieren wurden am 21. Oktober 2026 mit ihren ausgelieferten Einstellungen nachgemessen, dazu die ganze Pipeline Ende zu Ende.

Die bekannten Lücken stehen im Repository. Sechs Fragen aus dem Golden Set werden unter den 15 besten nie gefunden (drei über mehrere Seiten oder Schritte, drei Zahlen- oder Faktendetails), und das Umformulieren erreicht sie nicht. Die Extraktion macht aus Tabellen Fließtext, was zu Verweigerungen führt, selbst wenn die Evidenz gefunden ist. Die falschen Verweigerungen sind in der Antwort-Eval Ende zu Ende auf 3 gesunken, liegen aber weiter über dem Ziel von 1. Prompt Injection über Dokumenttext ist erschwert, aber nicht verhindert. Die nächste Phase, 11b, sind eigene Uploads hinter Supabase Auth, mit Kontingenten pro Nutzerkonto und einer Prüfung auf Prompt Injection, bevor Uploads öffnen; sie ist zurückgestellt.