Wenn ein RAG-Bot die falsche Versicherungssumme zitiert

Alles, was hier unten steht, ist eine fiktive Erzählung zum Unterrichtszweck. Firmennamen, Personen sowie Beträge sind erfunden; die beschriebenen Fehlermuster entsprechen denen, mit denen Produktions-RAG-Systeme tatsächlich in regulierten Versicherungsbranchen sowie ähnlichen hochriskanten Bereichen konfrontiert werden.

Eines späten Dienstags kontaktierte ein Leiter der Schadensabwicklung die Ingenieure: Eine Assistentin hatte einem Kunden mitgeteilt, seine Selbstbeteiligung bei Überschwemmungen liege bei 500 Dollar, obwohl in der Police 5.000 Dollar angegeben waren. Der retrieval-augmented Bot „Atlas“ war bereits seit drei Wochen im Einsatz und verfügte über einen Vektor-Speicher, ein solides Embedding-Modell, eine leistungsstarke LLM sowie eine benutzerfreundliche Benutzeroberfläche. Was ihm fehlte, war eine durchdachte Strategie zur Aufteilung der Daten in Teilbereiche.

Der abgerufene Datensatz sah wie folgt aus:

...applies to all covered perils. Deductible: $5
00 for flood events in Zone A, $500 for wind events, and $1,0

Durch die PDF-Extraktion war eine Zahl über mehrere Zeilen verteilt worden. Ein Chunker mit fester Größe teilte anschließend jeden 500 Zeichen langen Abschnitt ab. Der Embedder indizierte dabei Fragmente mit den Angaben „50 $“ und „500 $. Das Modell antwortete zuversichtlich – doch falsch.

Im Folgenden wird beschrieben, wie der Eingabepipeline neu aufgebaut wurde: eine Parschestufe, die die Obergrenze festlegt, gefolgt von vier Ebenen des Chunkings, die mit steigendem Aufwand dieser Obergrenze entgegenstreben.

Durch eine klare Strukturierung bleibt die Kostenrechnung transparent: fast alle Kosten für das Chunking entstehen durch einmalige Indexierungsprozesse. Diese laufen offline, noch vor jeder Anfrage des Benutzers. Die einzigen mit dem Chunking verbundenen Kosten, die im p95-Wert der Abfragen auftauchen, sind die des Embedding-Modells selbst. „Teuer“ in den höheren Ebenen bedeutet teuer einmal pro Dokument, nicht pro Anfrage.

Stufe 0: Man kann keine Struktur chunken, die bereits bei der Parsung zerstört wurde

Der erste Ansatz ist ein intelligentereres Teilungstool. Die bessere erste Frage lautet: Zeigen Sie den Text, der geteilt werden soll, und nicht das PDF. Der ursprüngliche Atlas-Text bestand aus einer endlosen Reihe von Zeichen. Überschriften waren mit dem Haupttext verschmolzen. Eine Tabelle mit Abzugsbeträgen war zu einem zusammenhängenden Textblock geworden, in dem Werte aus verschiedenen Zeilen nebeneinander standen. Die Seitenüberschrift (“Policy Form HO-3 — Page 14 of 62”) wiederholte sich alle paar Tausend Zeichen.

Kein Teilungstool kann Grenzen wiederherstellen, die der Parser bereits zerstört hat. Wenn Überschriften fehlen, hat ein Markdown-Überschrift-Trenner nichts mehr, worauf er sich stützen kann. Wenn Tabellen aufgelöst wurden, bleibt nichts übrig, das die Zeilen zusammenhält.

Passen Sie jede Eingabetyp zu einem Parser an, der eine Struktur erzeugt, die das Teilungstool nutzen kann:

Eigene PDFs und DOCX-Dateien (Versicherungsanträge, Bestätigungen, Richtlinien). Es werden layoutbewusste Parser bevorzugt – wie LlamaParse, Unstructured.io, Docling, Azure Document Intelligence – anstelle einfacher Textausgaben. Es wird Markdown mit Elementtypen (Überschrift, Tabelle, Liste) gefordert, nicht nur ein einfacher String.

Gescannte PDFs, Bilder und Faxe. Führen Sie OCR durch (Tesseract ist am schwächsten; PaddleOCR, Textract, Document AI, Azure sind leistungsfähigerer). Es werden der Text sowie Layoutblöcke zusammen mit einer Vertrauenswürdigkeit pro Block benötigt. Die Vertrauenswürdigkeit dient später dazu anzuzeigen, „diese Zahl ist ungewiss – antworten Sie nicht darauf bezüglich der Abschläge.“

HTML-Dateien und interne Wikis. Entfernen Sie unnötige Elemente und erzeugen Sie sauberes Markdown mit beibehaltenen Überschriften.

Präsentations- und Tabellenkalkulationsdateien. Bewahren Sie die Grenzen zwischen Folien oder Tabellenblättern bei, damit keine unzusammenhängenden Folien miteinander vermischt werden.

Audio und Video (Anrufe, Webinare). Whisper, Deepgram oder AssemblyAI sollten eine Transkription liefern, die angeben, wer wann gesprochen hat. Wenn die Sprecher nicht getrennt werden, können gegensätzliche Aussagen eines Schadensbehandlers und eines Kunden zu einem einzigen irreführenden Absatz verschmelzen.

Nach der layoutorientierten Neuparzerung sah der Abschnitt mit den Abzugsbeträgen wie folgt aus:

## Section 4 — Deductibles

### 4.2 Peril-specific deductibles

| Peril          | Zone A  | Zone B  |
|----------------|---------|---------|
| Flood          | $5,000  | $2,500  |
| Wind / hail    | $500    | $500    |
| Named storm    | $1,000  | $1,000  |

Die Tabelle wurde zurückgegeben. Der Überschriftenbaum wurde ebenfalls zurückgegeben. „$5,000“ war wieder ein einziger Token. Der Chunking-Code hatte sich noch nicht geändert, wodurch die Datenabfrage bereits sicherer war.

Ebene 1: Syntaktischer Chunking – günstig, schnell und der richtige Ausgangspunkt

Fester Größe: Das Prototyp, das versehentlich veröffentlicht wurde

Jede N Zeichen oder Token aufteilen (CharacterTextSplitter, tiktoken). Die Indexierungskosten sind nahe null. Geeignet für kurzfristige Anstiege; in der Produktion jedoch katastrophal. Dadurch werden Sätze, Tabellen oder Zahlen mitten im Text abgeschnitten – genau wie bei einem auslösenden Vorfall. Regel nach jener Nacht: Festgröße darf niemals in einem Notizbuch verwendet werden.

Die Teams entdecken immer wieder dasselbe Muster: Ein Demo-Korpus aus kurzen Blogbeiträgen übersteht die Aufteilung nach Zeichen, doch sobald das erste mehrspaltige PDF oder eine mit OCR verarbeitete Bestätigung eintrifft, bricht die Antwortqualität über Nacht zusammen. Betrachten Sie feste Fenster als Hilfsmittel für lokale Experimente und legen Sie explizit fest, sie vor jedem externen Benutzerverkehr durch etwas anderes zu ersetzen.

Überschneidung: Ein Regler, keine Strategie

chunk_overlap wiederholt den Abschluss von Chunk N am Anfang von N+1. Zehn bis fünfzehn Prozent sind üblich (zum Beispiel 50 bei einem Chunk mit 500 Token). Die Überlappung dient als günstige Absicherung für die Ebenen 1–2; sie behebt keine schlechten Grenzen – sie dupliziert sie lediglich. Man kann mit etwa 10 Prozent mehr Vektoren sowie doppelten Treffern in der top-k-Liste rechnen, wenn die Übereinstimmung innerhalb der Überlappung liegt.

Wenn Duplikate die Nachbarliste dominieren, verschwenden Reranker sowie das LLM den Kontextfenster zweimal für denselben Satz. Die Deduplizierung mithilfe von Eltern-ID oder nahezu identischen Text-Hashes nach der Abfrage ist eine kostengünstige Gegenmaßnahme, falls die Überlappung aus anderen Gründen hoch bleiben muss.

Satz/Paragraf: Achtet auf Grammatik, ignoriert das Dokument

Verpacken Sie ganze Sätze in einen Budgetrahmen (NLTK, spaCy, LlamaIndex SentenceSplitter). Schneiden Sie niemals mitten im Satz – sonst würde dies die Zeilenumbrüche stören – doch der Tool kennt keine Überschriften, Tabellen oder Ausschlusslisten. Hervorragend für Transkripte von Telefonaten; mittelmäßig bei strukturierten Vertragsformularen.

Rekursiver Zeichenseparator: Die Standardoption, die zuerst verwendet wird

RecursiveCharacterTextSplitter probiert die Trennmethoden in Prioritätsreihenfolge aus – leere Zeile, Zeilenumbruch, Satz, Wort – und greift nur dann auf andere Methoden zurück, wenn ein Teil immer noch zu groß ist; anschließend werden kleine Teile zu chunk_size zusammengeführt. Ein gängiger Standardwert sind 500 Token mit 50 Prozent Überlappung:

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
)
chunks = splitter.split_text(policy_markdown)

In dem neu analysierten Abschnitt mit den Abzugsbeträgen wurden alle 4,2 Elemente beibehalten – einschließlich der Tabelle –, da leere Zeilen eine natürliche Einheit unter 500 Tokens bildeten. Der Fehler verschwand. Senden Sie recursive-500/50 als Referenzwert zum Vergleich, nicht als fertiges Design.

Schreiben Sie diesen Referenzwert an eine Tafel und lehnen Sie Verbesserungen „intelligenterer“ Teilungsalgorithmen ab, die bei denselben Testfragen nicht besser abschneiden können. Viele teure Ideen erscheinen brillant, bis sie mit einem einfachen rekursiven Teilungsalgorithmus auf sauberem Markdown verglichen werden.

Tier 2: strukturbewusste Teilung – schneiden dort, wo das Dokument bereits Trennlinien hat

Mit einer Testmengung von etwa 80 realen Fragen erreichte recursive-500/50 etwa 71 %. Fehler traten häufig in langen Abschnitten auf, die mehrere Teile umfassten, sowie bei Antworten, bei denen das Modell nicht erkennen konnte, von welcher Richtlinie oder welchem Abschnitt die Antwort stammte.

Teilung von Markdown-/HTML-Überschriften

MarkdownHeaderTextSplitter / HTMLHeaderTextSplitter teilen den Text nach der Überschriftenhierarchie auf und übertragen den Überschriftenpfad in die Metadaten:

from langchain_text_splitters import MarkdownHeaderTextSplitter

header_splitter = MarkdownHeaderTextSplitter(
    headers_to_split_on=[("#", "h1"), ("##", "h2"), ("###", "h3")]
)
sections = header_splitter.split_text(policy_markdown)
# then apply the recursive splitter inside each section

Jedes aus Abschnitt 4.2 abgetrennte Fragment sollte einen „Breadcrumb-Link“ enthalten, wie z. B. form HO-3 → Abzüge → riskspezifische Tabelle. Diesen Link sollte man vor der Einbettung dem Text hinzufügen, damit der Vektor sowohl die Position als auch Zahlen kodiert. Fehler wie „Welcher Abschnitt?“ treten dadurch nicht auf; Verweise können lauten „gemäß Abschnitt 4.2“. Die Kosten bleiben nahezu null – aber nur, wenn in Phase 0 echter Markdown erzeugt wurde. Der vereinfachte Text wird sonst stillschweigend zu einem einzigen großen Block. Am besten geeignet für Wikis, technische Dokumente sowie dokumentierte Richtlinien.

Metadatenfelder sollten zusammen mit dem Vektor übertragen werden: ID des Quelldokuments, Abschnittspfad, Gültigkeitsdatum sowie Zuständigkeitsbereich, falls die Richtlinien je nach Bundesstaat unterschiedlich sind. Diese Felder ermöglichen Filter wie „nur HO-3, der nach 2024-01-01 in Kraft getreten ist“, die eine reine Ähnlichkeitssuche nicht darstellen kann.

Layout-bewusst / by_title

Die unstrukturierte Methode chunk_by_title (sowie ähnliche Ansätze in LlamaParse/Docling) berücksichtigt die Grenzen der Parser-Elemente: Tabellen bleiben vollständig, Überschriften bilden den Beginn von Abschnitten und Listen behalten ihren Einleitungs-satz. Die ideale Lösung für Verträge und komplexe PDFs. Parse-APIs kosten einmalig bei der Indizierung Geld. Ein günstiger, upstream-basierter Parser macht diese Kosten überflüssig – man sollte kein aufwendiges Lenkrad für ein Auto ohne Motor kaufen.

Code-bewusst (AST)

Für Policy-Korpora unbedeutend, für Terraform/Python RAG jedoch unerlässlich. Zeilenspalten trennen Signaturen vom Haupttext. tree-sitter oder sprachbewusste rekursive Spalter teilen an Funktion-/Klasse-Noden auf. Standardmäßig verwendet, wenn das Korpus aus Repositories oder IaC-Dokumenten besteht.

Die Vermischung von Prozessrichtlinien und Quellcode in einem einzigen Index ohne Trennung durch Speichermechanismen führt in der Regel zum Schlimmsten aus beiden Welten: Funktionen werden mitten im Text abgeschnitten und Richtlinientabellen durch auf Klammern ausgerichtete Heuristiken zerstört.

Kategorie 3: modellbasiertes Chunking – nur dort Urteile fällen, wo die Struktur fehlt

Auf etwa 84 % der Testdaten trat eine neue Fehlerklasse auf: unstrukturierte Anrufprotokolle ohne Überschriften. Rekursive Blöcke von 500 Tokenen umfassten mehrere Themenwechsel – zunächst eine Dachreparaturanfrage, anschließend eine Postanschrift – wodurch die Embeddings im Durchschnitt zwei Themen widerspiegelten und zu keiner davon eine gute Übereinstimmung aufwiesen.

Semantisches Chunking

Embedden Sie den Text Satz für Satz; schneiden Sie dort ein, wo die konsekutive Kosinusähnlichkeit unter einen Schwellenwert fällt (SemanticChunker, jeder brauchbare Embedder). Eine einzige Embedding-Schleife zum Zeitpunkt der Indexierung. Bei Sprache ist dies transformierend; die Schwellenwerte sind korpusbezogen. Der Schwellenwert für Telefonate zerlegte dichten Vertragstext in winzige Teile – nutzen Sie daher das semantische Chunking nur bei unstrukturierten Sprachdaten und behalten Sie Verträge auf Ebene 2.

Routing nach Dokumentklasse – Sprache gegen Formulare gegen Wiki – ist besser als das Suchen nach einem universellen Chunker. Die Orchestrierungskosten bestehen aus einem Klassifikator oder einem einfachen Wechsel des Dateityps bei der Eingabe; der Vorteil sind weniger unklare Embeddings.

Vorschlag / atomares-Fakt-Chunking

Ein kleines LLM überschreibt Abschnitte in eigenständige Aussagen („Die Überschussfreiheit für Zone A nach HO-3 beträgt 5.000 Dollar“). Die Genauigkeit steigt, da jede Einheit eine Tatsache mit eingebettetem Kontext darstellt. Die Kosten belaufen sich auf einen LLM-Aufruf pro Abschnitt – was für kleine, hochpräzise Korpora wie eine 40-seitige FAQ angemessen ist. Problem: Die Formulierungen weichen von der ursprünglichen Sprache ab. Wenn Kunden die Antworten in Frage stellen, ist eine wörtliche Zitierung besser als eine Paraphrase. Nutzen Sie die Formulierungen lediglich als Hilfsmittel zur Suche und geben Sie den ursprünglichen Abschnitt zur Zitierung zurück.

Kompliance- und Schadensregulierungsorganisationen werden letztendlich nach dem Bild der Seite oder einer PDF-Hervorhebung hinter einer Antwort fragen. Planen Sie die Zitierungsidentifikatoren frühzeitig ein, damit die Indexe weiterhin als Beschleuniger dienen und nicht zum alleinigen Aufzeichnungssystem werden.

Aggressives Chunking

Übergeben Sie ein ganzes Dokument an ein Flaggschiff-Modell, damit dieses die Grenzen festlegt. Dies funktioniert zwar, ist aber wenig skalierbar: Die Kosten steigen linear mit der Größe des Korpus, während der Nutzen nicht zunimmt. Geeignet für ein paar hundert besonders wertvolle Dokumente – nicht jedoch für Millionen.

Ebene 4: Chunking zum Zeitpunkt der Suche – Suche nach kleinen Einheiten, Rückgabe größerer Einheiten

Ebenen 1–3 gehen davon aus, dass die indizierte Einheit auch die zurückgegebene Einheit ist. Das erzwingt einen falschen Kompromiss: Kleine Chunks ermöglichen saubere Embeddings, vernachlässigen aber den Kontext für das LLM; große Chunks liefern zwar Kontext, verschwimmen aber die Embeddings. Die Anpassung von chunk_size führt niemals zu einem universell optimalen Wert.

Ebene 4 trennt die Rollen: eine Sucheinheit, die auf den Embedder abgestimmt ist, und eine Übergebungseinheit, die auf das LLM zugeschnitten ist. Prüfkriterium: Wenn Sie einen zweiten Speicher (Docstore, Eltern-Mappe, Baumstruktur) benötigen, befinden Sie sich in Ebene 4.

Elterndokument / von klein zu groß

Index kleiner Kinder-Elemente (150–200 Token). Bei einer Abfrage wird das größere Elternelement zurückgegeben (entweder der gesamte Abschnitt 4.2 oder ein Unterabschnitt mit etwa 1.500 Token):

from langchain.retrievers import ParentDocumentRetriever
from langchain.storage import InMemoryStore

parent_splitter = RecursiveCharacterTextSplitter(chunk_size=1500)
child_splitter = RecursiveCharacterTextSplitter(chunk_size=200)

retriever = ParentDocumentRetriever(
    vectorstore=vectorstore,
    docstore=InMemoryStore(),     # the "second store"
    child_splitter=child_splitter,
    parent_splitter=parent_splitter,
)
retriever.add_documents(policy_docs)

LlamaIndex AutoMergingRetriever bietet eine ähnliche Hierarchie. Die zusätzlichen Indexkosten sind nahezu null – man integriert denselben Text in kleinere Teile. Allein durch diesen Ansatz stieg bei der „goldenen“ Datensammlung Atlas’ Genauigkeit von etwa 84 % auf etwa 91 %: Die Abfrage „what’s my flood deductible“ fand die exakte Tabellenzeile, während das große Sprachmodell weiterhin die umliegenden Anmerkungen sah (einschließlich der Definition von Zone A). Betriebskosten: ein Docstore, der nach dem Elternteil-ID-Code sortiert ist und bei Aktualisierungen synchron bleibt.

Löschen und Versionierung sind hier wichtig: Wenn Abschnitt 4.2 überarbeitet wird, müssen Kinder- und Elternelemente gemeinsam aktualisiert werden, andernfalls lädt das System ein spezifisches Kind-Element, das auf ein veraltetes Elternelement verweist. Die Eingabe von Inhalten sollte als transaktionale Veröffentlichung von Elternelementen, Kinderelementen und Embeddings betrachtet werden – nicht als drei unabhängige Aufgaben.

Kontextbasierte Abfrage

Vor dem Einbetten sollten Sie ein Mini-LLM um ein oder zwei einleitende Sätze bitten und diese voranstellen; kombinieren Sie dies mit BM25. Fragmente wie „Zone A: $5.000 / Zone B: $2.500“ werden so auffindbar. Die Kosten betragen einen LLM-Aufruf pro Teil – ohne Prompt-Caching extrem teuer; mit Caching bleibt das Dokumentpräfix aktiv und die Aufrufe pro Teil günstig.

Spätes Chunking

Einbetten Sie das gesamte Dokument mit einem Embedder für lange Kontexte und fassen Sie anschließend die Token-Vektoren innerhalb jedes Chunk-Bereichs mittels Mean-Pooling zusammen. Die Chunk-Vektoren tragen den Dokumentkontext, ohne dass für jeden Chunk ein LLM-Aufruf nötig ist. Dies ist konkurrenzfähig mit dem kontextbasierten Abruf, bindet Sie jedoch an Modelle für lange Kontexte.

Hierarchisch / RAPTOR

Klusterblöcke werden zusammengefasst und zu einem Baum strukturiert; jede Ebene wird indiziert. Allgemeine Fragen beziehen sich auf Zusammenfassungen, spezifische Fragen auf die Endpunkte des Baums. Die Kosten für die höchste Stufe 4 sind hoch, und Änderungen an Dokumenten sind problematisch – Neubauten sind teuer. Quartalsweise Policy-Updates machten RAPTOR zur geeigneten Wahl für Atlas.

Statische Wissensbasen – interne Enzyklopädien, die jährlich aktualisiert werden – können Neubauten des Baums verkraften. Lebende Versicherungsformulare hingegen nicht. Wählen Sie hierarchische Methoden nur dann, wenn sich die Änderungshäufigkeit und das Budget für Neubauten klar festgelegt haben.

Was die neu erstellte Anleitung besagt

Sechs Wochen nach dem Übungslauf in Slack erreichte Atlas bei einer goldenen Sammlung mit etwa 300 Fragen einen Wert von fast 93 %. Die kurze Version zur Designprüfung:

Begonnen werden sollte mit rekursivem Zeichensegmentieren sowie strukturbezogenen Schnitten bei etwa 500 Tokens und 50 Prozent Überschneidung – das kostet fast nichts und liefert eine messbare Grundlage. Erst danach sollte man auf die Abrufung des übergeordneten Dokuments upgraden, damit sich Größe der Abgleichsergebnisse und der bereitgestellten Inhalte unterscheiden können. Erst wenn das Bewertungsset weiterhin Probleme mit der Vollständigkeit hat, sollte man in kontextbasierte Abfragemethoden investieren.

Nichts von dem Gesagten kann eine schlechte Parsing-Leistung retten. Beheben Sie zunächst die Probleme bei der Extraktion, bevor Sie die Segmentierungsverfahren anpassen.

Die einseitige Version

Phase 0 – Parsing. Passen Sie die Parser an die Eingaben an: strukturiertes Markdown für native Dokumente; Text plus Layout plus OCR-Vertrauenswerte für Scans; sauberes Markdown mit Überschriften für HTML; Grenzen von Folien für Präsentationen; diarisierte Transkripte für Audiodateien. Das legt die Obergrenze fest.

Ebene 1 – Syntaktisch. Festes Format nur für Prototypen. Die Überschneidung wird über einen Regler (10–15 %) gesteuert, was zu doppelten top-k-Ergebnissen führt. Die Satzteilung berücksichtigt die Grammatik, ignoriert jedoch die Dokumentlogik. Die rekursive Verteilung 500/50 ist die Standardbasis, nicht das Endziel.

Ebene 2 – strukturbezogen. Die Teilung der Überschriften enthält Abschnittspfade; die Qualität hängt vom Parser ab. Die Layout-Methode by_title behält Tabellen zusammen; günstige Parser heben dies auf. Für Code-Repositories werden AST-Teilungen verwendet.

Ebene 3 – modellbasiert. Semantische Schnitte aufgrund von Ähnlichkeitswerten; Anpassung je nach Korpus. Propositionen erhöhen die Genauigkeit bei kleinen Korpora, weichen aber von der Wortwahl ab. Aggressive Schnitte rechtfertigen sich in großem Maßstab selten.

Ebene 4 – Abrufzeit. Abgleich in kleinen Einheiten; Lieferung großer Einheiten. Das Elterndokument stellt die optimale Upgrade-Lösung mit dem höchsten ROI dar. Für den kontextbasierten Abruf ist Caching erforderlich. Spätes Aufteilen in Blöcke ist günstiger, aber an den Embedder gebunden. RAPTOR veraltet bei Updates. Wenn ein zweiter Speicher erforderlich ist, handelt es sich um Ebene 4.

Der entscheidende Punkt lag nie wirklich darin, zwischen LangChain und LlamaIndex zu wählen. Es ging vielmehr darum, vor der mathematischen Verarbeitung die Dokumentstruktur zu respektieren, die Aufteiler anhand echter Kundenfragen zu testen und Modellelemente abzulehnen, die unmöglich eine vollständige numerische Information enthalten konnten.

Bauen Sie das „goldene Set“ aus Tickets auf, die das Produkt bereits in Verlegenheit gebracht haben – falsche Abschläge, fehlende Ausschlüsse, verwirrende Zusicherungen – und nicht aus künstlich erzeugten Fakten. Bewerten Sie die Richtigkeit der Antworten sowie die Genauigkeit der Quellenangaben getrennt voneinander, damit eine offensichtlich falsche Zahl niemals wie ein Sieg aussieht. Wenn ein neuer Splitter eingeführt wird, muss er in beiden Metriken die rekursive Basislinie übertreffen, bevor er mit dem Produktverkehr in Berührung kommt.

Zuletzt sollte es einen Abschaltmechanismus geben: Wenn das OCR-Vertrauensniveau bei einer numerischen Angabe niedrig ist oder sich die Eltern- und Kindversionen nicht einigen, sollte der Assistent die Frage zum Abschlag ablehnen und das Problem weiterleiten, anstatt ein fiktives Vertrauensniveau zu erfinden. Nutzer verzeihen weitaus schneller die Aussage „Das lässt sich aus dem eingereichten Formular nicht überprüfen“ als eine lässig falsche Antwort in Höhe von fünfhundert Dollar. Dieser Ablehnungsweg gehört zu den Produktanforderungen und nicht nur in ein Nachbesprechungs-Präsent, das erst nach dem Schaden geteilt wird.