Man kann eine Zahl nicht abrufen, die niemand notiert hat: OKF gegenüber einer Vektordatenbank-RAG-Lösung

Jedes Projekt kommt immer wieder auf denselben Punkt zurück – und zwar darauf, die Tabellen zusammenzustellen und den Text zu extrahieren. Dieser Hinweis stammt von einem Chatbot, der auf die übliche Weise arbeitete. Ein Dutzend CDC-Dokumente, darunter Beschreibungen der Umfragen, Codebücher, Zusammenfassungsberichte sowie PDFs zur Methodik, wurden in eine Bedrock Knowledge Base geladen, in der Hoffnung, dass ein gut gefüllter Datenspeicher gute Antworten liefern würde.

Das geschah jedoch nicht. Der Grund ist das häufigste Missverständnis bezüglich der retrieval-augmented Generation: dass mehr Dokumente zu genaueren Antworten führen. Eine Vektordatenbank kann nur Text zurückgeben, der bereits in ihr enthalten ist. Bei Fragen, deren Antwort niemals aufgeschrieben wurde, spielt die Größe der Sammlung überhaupt keine Rolle.

Die zwölf Dokumente beschrieben die Diabetes-Variablen detailliert: was sie bedeuten, wer befragt wurde und wie die Antworten kodiert sind. Keines von ihnen enthielt die Statistiken, nach denen ein Benutzer tatsächlich suchen würde. Diese Zahlen werden aus 29.522 Zeilen von Umfragedaten berechnet und erscheinen in keinem PDF – daher wird man sie durch keine Menge an Suchen finden.

Das führt zu einem noch gravierenderen Fehler. Die Leute gehen davon aus, dass RAG jede Frage zu einem Thema beantworten kann, sobald dieses Thema in den Dokumenten vorkommt. Tatsächlich kann es nur solche Fragen beantworten, deren Antworten in einem Absatz formuliert sind. Alles, was berechnet werden muss, liegt außerhalb seiner Reichweite.

So wurde der Chatbot neu aufgebaut. Er begann als Tutorial-App, die Amazon Bedrock Flow, AWS Amplify Gen 2 und Next.js kombinierte, und bei der Neuauflage wurde seine Suchmaschine durch ein geprüftes Open Knowledge Format (OKF)-Paket ersetzt. Zur fairen Vergleichbarkeit wurde auch eine echte Bedrock Knowledge Base auf denselben Dokumenten erstellt, und beide wurden direkt miteinander auf den einzigen wichtigen Kriterien getestet: Ist die Antwort richtig, und wie schnell wird sie geliefert?

Beim Stellen der zentralen Frage identifizierte die Wissensdatenbank fünf relevante Variablen und gab anschließend genau an, wo die Grenze liegt: Die Dokumente enthalten keine tatsächlich berechneten Statistiken. Sie empfahl sogar die richtige Analyse – einen gewichteten Anteil der Personen mit einer bestimmten Eigenschaft, die auch eine weitere Eigenschaft aufweisen, was genau das ist, was OKF zur Zeit der Erstellung ausführt, allerdings nicht korrekt von einem System angegeben werden kann, das es nicht ausführen kann. Es lässt sich auf einen Satz zusammenfassen: Man kann keine Zahl abrufen, die niemand notiert hat. Die OKF-Seite antwortete mit einer Zahl, die aus den Mikrodaten unter der richtigen Bevölkerungsdefinition und den richtigen Gewichten berechnet wurde.

Wie der Test aufgebaut war

Die Konfiguration war absichtlich symmetrisch. Claude Sonnet 4.5 erzeugte Antworten auf beiden Seiten in us-east-1, wobei eine Übertragung über das in-Prozess-SDK erfolgte und die gleiche Systemanfrage wie bei dem eingesetzten Lambda verwendet wurde. Die Methode wurde bereits vor dem Auftreten irgendwelcher Ergebnisse festgelegt, alle sieben Fragen sowie jede Testreihe werden dokumentiert, und die Rohantworten werden aufbewahrt. Eine Hinweis zur Zeitmessung: Das Tool ruft direkt auf die Datenabfrage- und Bedrock-Services zu, während die Live-App zunächst über AppSync und Lambda geleitet wird. Der getestete OKF-Code ist der echte Code der App, der Transportmechanismus hingegen nicht; daher vergleichen die Zeiten zwei auf dieselbe Weise gemessene Designs und spiegeln nicht das wider, was ein Browsernutzer sehen würde.

Der Austausch: ein Lambda

Der Amplify-Chatbot stellt Tools als Amplify-Datenwerkzeuge bereit, wobei jedes davon eine Lambda-Funktion hinter einer GraphQL-Anfrage ist – Bedrock Flow gehörte dazu. Die Änderung betrifft nun ein weiteres Tool, askOkf, das aus einem verifizierten Bundle statt aus einem Flow antwortet. Schema, Frontend und Deployment bleiben unverändert.

// amplify/functions/askOkf/handler.ts — the essence
export const handler: Schema["askOkf"]["functionHandler"] = async (event) => {
   // in-process TF-IDF over the bundle
  const hits = search(event.arguments.question, 3);
  const top = hits[0];

  // Grounded-or-refuse: below the score floor,
  // nothing verified matches → refuse
  // before ever calling the model.
  if (!top || top.score < MIN_SCORE) {
    return { answer: refusal().text, citation: "", grounded: false, mode };
  }

  // read the verified figure straight from frontmatter
  if (mode === "extractive") {
    // 0 model calls - sub-millisecond
    const a = extractiveAnswer(hits);
    return { answer: a.text, citation: a.citations[0] ?? "", grounded: true, mode };
  }

  // generative: ground Claude on the ONE retrieved concept,
  // safety-prompted grounded-or-refuse
  const concept = top.concept;
  const context = `Concept: ${concept.label}\nSource: ${conceptSource(concept.frontmatter)}\n\n${concept.text}`;
  const response = await bedrock.send(
    new ConverseCommand({
      modelId: env.MODEL_ID,
      // grounded-or-refuse; declines medical-advice intent
      system: [{ text: SYSTEM_PROMPT }],
      messages: [{ role: "user", content: [{ text: `Verified concept:\n${context}\n\nQuestion: ${question}` }] }],
      inferenceConfig: { maxTokens: 400, temperature: 0 },
    })
  );
  const text = response.output?.message?.content?.[0]?.text ?? "";
  return { answer: `${text}\n\nSource: ${citation}`, grounded: true, mode };
};

Im Handler scannt search() vier überprüfte Markdown-Dateien, die zusammen mit Lambda bereitgestellt werden. Es werden weder Vektordatenbanken noch Embedding-Dienste genutzt, und es finden keine Netzwerkübertragungen statt. Nur Konzepte, die die Überprüfung bestanden haben, werden berücksichtigt – das bedeutet, jemand hat die Analyse durchgeführt und das Ergebnis überprüft. Die verlockend falsche Zahl, der ungewichtete Gesamtinsulinwert von 3,66 %, kommt in keiner dieser Dateien vor, sodass sie niemals bereitgestellt werden kann.

Zwei Ansätze werden bereitgestellt, und der Benchmark misst beide. Der extraktive Ansatz liest die überprüfte Zahl aus dem Frontmatter aus, ohne dass dabei Modelle aufgerufen werden. Der generative Ansatz führt einen Converse-Aufruf durch.

Die Basislinie: ein echter Vektor-RAG

Der Gegner musste stark sein. Es handelt sich um eine verwaltete Bedrock Knowledge Base auf S3 Vectors, die das echte CDC 2023 NHIS-Material enthält: die Beschreibung der Umfrage, das Sample Adult Codebook, die Zusammenfassungs- und Methodenberichte, die technische Anleitung zur Imputation sowie die README-Datei zu den Paargewichten. Ein fähiger Ingenieur würde genau so etwas entwickeln. Da das Modell identisch ist, bleibt als einzige Variable nur noch die Herkunft der Antwort – entweder ein Vektorlager oder ein überprüftes Bundle innerhalb der Funktion.

Dreizehn Dateien wurden hochgeladen und zehn indiziert. Die drei Fehler traten bei .zip-Archiven auf, die von Bedrock abgelehnt werden, und es handelte sich dabei um die Rohdaten. Das klingt nach einem Schlupfloch, das die Vektordatenbank rettet, ist aber keines. Jedes Dokument, das die Diabetes-Variable beschreibt, wurde ordnungsgemäß indiziert. Was fehlt, sind die Rohdatenzeilen, und eine Abfrage dieser Rohdatenzeilen hätte auf jeden Fall keine solchen Zahlen ergeben, denn ein durch Umfragedaten gewichteter Prozentsatz bei 29.522 Datensätzen mit einem Sprungmuster-Universum ist eine Berechnung und kein Auszug. Man kann nicht einfach in Teile aufteilen, um dorthin zu gelangen.

Noch eine ehrliche Beobachtung: Die Vektorlösung war die günstigere Variante. Ein Dutzend Dokumente sowie eine Wissensdatenbank wurden in wenigen Minuten bearbeitet. Die OKF-Lösung erforderte hingegen echte Arbeit – Konzepte modellieren und die Analyse an den Mikrodaten durchführen, um jede Zahl zu überprüfen. Zu glauben, die Schnelligkeit der Abfrage sei gleichbedeutend mit Genauigkeit, ist ein eigenes Missverständnis. Günstige Lösungen und hohe Genauigkeit sind unterschiedliche Probleme; die Einfachheit ist ein Grund, die Vektordatenbank beizubehalten, nicht sie zu entfernen.

Genauigkeit

Die Aufgabensammlung bestand aus drei Zahlenfragen mit bekannten, überprüften Antworten, drei Ablehnungsfragen sowie einer Methodenfrage. Die Bewertungen erfolgten anhand eines im Voraus festgelegten Bewertungsschemas – 30 Versuche pro Zahlenfrage und zwei pro Ablehnungsfrage, wobei alle Ergebnisse dokumentiert wurden. Bei allen drei Zahlenfragen gelang es der Vektor-RAG-Lösung in keinem einzigen Versuch, die überprüfte Zahl zu ergeben.

Verzögerung

Bei Fragen zu Diagrammen mit jeweils 30 Versuchen (wobei die Warm-Up-Versuche die Nummern 2 bis 30 sind) wurde der generative OKF-Weg als 1,4 bis 2,4 Mal schneller angegeben, da er den Abruf über das Netzwerk überspringt und mit einem deutlich kleineren Kontext arbeitet. Der extraktive Weg ist nahezu sofortig, da überhaupt kein Modell aufgerufen wird. Beachten Sie den Streubereich und nicht den Durchschnitt: Die Lücke ist bei Insulin mit etwa 2,4 Mal am größten und bei Alter mit etwa 1,4 Mal am kleinsten, wobei die beiden Werte fast gleich sind; daher stellen die Zeilen pro Frage das Ergebnis dar und nicht ein einziges Gesamtratio. Geschwindigkeit ist ohnehin nicht das entscheidende Kriterium. Die 3,3 bis 3,7 Sekunden der Wissensdatenbank sind durchaus akzeptabel, und sie verliert im Bereich der Genauigkeit, nicht in Bezug auf die Zeit.

Die Erkenntnis: Abrufen versus Kompilieren

In jedem einzelnen Test konnte der Vektor RAG keine der überprüften Zahlen liefern, und mangelhafte Ingenieursarbeit ist keine Erklärung dafür. Diese Zahlen sind einfach nicht in den Dokumenten enthalten. Der durch Umfragen gewichtete Wert von 31,96 % stammt aus den Mikrodaten unter Verwendung der korrekten Bevölkerungsgruppe und Gewichte und findet sich in keinem PDF. Ein Retriever kann nur bereits vorhandenen Text zurückgeben. OKF kann antworten, weil die Zahl im Voraus berechnet und überprüft wurde, während die Wissensdatenbank nichts zum Abrufen hat.

Bemerken Sie, wie die Wissensdatenbank versagt: Sie gibt an, den Prozentsatz in den Dokumenten nicht finden zu können, und erfindet keine Zahl. Das ist ehrlich und unterstreicht den Punkt noch mehr. Selbst ein gut funktionierender, ordnungsgemäß konstruierter Vektor RAG ist strukturell nicht in der Lage, eine Frage zu berechneten Statistiken auf der Grundlage von Dokumenten zu beantworten.

Hier treten noch zwei weitere Missverständnisse auf.

• Grounding garantiert keine Korrektheit. Diese Wissensdatenbank lehnte ab und erzeugte keine Inhalte, doch das liegt an guten Standardeinstellungen und nicht an einer Eigenschaft von RAG. Ein etwas eifrigeres Modell oder ein Zusammenfassungsdokument, das zufällig eine ungewichtete Häufigkeit enthielt, würde eine zuverlässig falsche Zahl liefern.
• Eine Quellenangabe beweist wenig. Ein Quellennachweis zeigt lediglich an, dass ein Dokument abgerufen wurde, nicht jedoch, dass die Antwort daraus abgeleitet ist. Eine OKF-Quellenangabe ist eine andere Art von Angabe, da sie eine Zahl nennt, die anhand der Daten berechnet und zur Zeit der Kompilierung überprüft wurde – nicht einen Text, der neben einem ähnlichen Satz steht.

Bessere Anfragen oder zusätzliche Datenblöcke werden das nicht beheben. Die Lösung besteht darin, auf die Abfrage dieser Zahlen zu verzichten und sie nicht weiter zu verarbeiten.

Beschränkungen und Kompromisse von OKF

OKF ist kein universelles Antwortwerkzeug, und der Vergleich zeigt, wo seine Grenzen liegen.

Es beantwortet die Frage nach dem „Wie viel“ und nicht nach dem „Warum“. Bei der qualitativen Frage, wie Umfragedurchschnittswerte die Prävalenz verändern, lieferte das Vektor-RAG eine umfassende, fundierte Antwort, die direkt aus der Beschreibung der Umfrage stammte, während das vierkonzeptionelle OKF-Set nur eine verwandte Zahl anbieten konnte. Ein mit Daten verifiziertes Set ist bezüglich der berechneten Statistiken genau, schweigt aber zu narrativen Aspekten. Das ist eine Grenze und kein Mangel – und es weist direkt auf die folgende Architektur hin.

Schnelligkeit bedeutet keine Urteilsfähigkeit. Der extraktive Ansatz antwortet in unter einem Millisekunden, doch bei der Anfrage nach medizinischem Rat gibt er lediglich „31,96%“ zurück, weil er nicht erkennen kann, wonach der Nutzer sucht. Der generative Ansatz lehnt den Rat ab und liefert die Bevölkerungsstatistik zusammen mit der klaren Warnung, dass diese nichts über die Situation eines einzelnen Menschen aussagt. Diese Unterscheidungskraft kostet einen Modellaufruf, etwa zwei Sekunden. Betrachten Sie den sofortigen Antwortweg sowie den auf die Absicht ausgerichteten Ansatz als separate Tools und berichten Sie über beide, ohne sie miteinander zu vermischen.

Das Ergänzungstool: ein drittes Werkzeug

Diese Einschränkungen führen zu einem Schluss: OKF stellt die überprüfte Schicht bereit, während die Vektordatenbank bei der qualitativen, narrativen Schicht, die OKF nicht erreichen kann, hervorragend funktioniert. Ein sinnvoller Entwurf nutzt beide als unterschiedliche Tools, aus denen der Agent wählen kann.

Der auf Fakten basierende Agent verwendet bereits in diesem Sinne zwei Tools, beide überprüft, im Lauf des Prozesses und auf Aggregaten beschränkt: eine Konzeptsuche (search_okf) sowie eine auf einer Erlaubnisliste basierende Aggregatabfrage (analyze_rows). Jedes liefert nur das, wofür es eine Garantie bieten kann. Die Bedrock-Wissensdatenbank wird zum dritten Tool, das eindeutig als unüberprüfte Erzählung gekennzeichnet ist. Der Agent bietet anschließend für Zahlenfragen eine überprüfte Zahl, für Erklärungen einen auf Fakten basierenden Text sowie eine Ablehnung, wenn keines davon zutrifft, und hält diese drei Elemente voneinander getrennt.

Diese Aufteilung ist auch die richtige Einsatzweise der Ressourcen. Minuten für die Wissensdatenbank, Stunden für den überprüften Datensatz. Erzählungen können günstig abgerufen werden, die aufwändige Arbeit sollte nur dort eingesetzt werden, wo eine Zahl unbedingt korrekt sein muss: Kompilieren Sie nicht das, was die Suche kostenlos liefert, und suchen Sie nicht nach dem, was überprüft werden muss.

Vorabansicht eines verwandten Ergebnisses

Man platziert vier Funktionen in einem Agenten (Überprüfung, Berechnung, Abruf und Echtzeitdaten) – und es stellt sich die natürliche Frage: Hält ein größeres Modell die verschiedenen Modi auseinander? Ein gefälschter Nachrichtentitel mit einer erfundenen Statistik wurde drei Modellen gezeigt, und alle drei wiederholten die Zahl in neun von neun Versuchen, wobei sie sie als unüberprüfte Angabe Dritter bezeichneten. Dennoch erreichte jede Mal eine erfundene Gesundheitsstatistik den Leser. Nur eine im Code implementierte Herkunftskontrolle verhinderte dies in allen neun Fällen. Das gewählte Modell hatte keinen Einfluss auf die Sicherheit.

Das verändert die Wahrnehmung dieses Benchmarks. Ein überprüfter Datensatz liefert die richtige Zahl – das ist bereits die Hälfte der Arbeit. Die andere Hälfte besteht darin, zu verhindern, dass falsche Zahlen unter demselben Etikett weitergegeben werden, und das hängt vom Code und nicht vom Modell ab.

Echtzeitdaten und unabhängige Überprüfung

Nichts davon blieb auf einem Laptop. askOkf wurde in einer echten Amplify-Sandbox (Cognito, AppSync, Lambda) in Betrieb genommen und antwortete mit „31,96 % nehmen derzeit Insulin ein“ zusammen mit der entsprechenden Quelle, lehnte dabei die Frage nach medizinischen Ratschlägen ab und nutzte dabei eine echte IAM-Rolle. Zuvor hatte eine unabhängige Sicherheitsprüfung den Code aus der Quelle analysiert und contract-satisfied gemeldet: Die Abfrage erfordert Authentifizierung, die Berechtigung bedrock:InvokeModel folgt dem Prinzip des geringsten Privilegs und ist auf ein einzelnes Modell beschränkt, es kann nichts eingefügt werden, und jede Anfrage ist auf einen begrenzten Modellaufruf beschränkt.

Eine Anmerkung zu den Modellen: Bedrock hatte gerade Claude 3 Sonnet als veraltet markiert, weshalb sowohl der OKF-Lambda-Code als auch der Benchmark Claude Sonnet 4,5 verwenden. Die Gleichheit der Modelle auf beiden Seiten sorgt dafür, dass der Vergleich fair ist.

Fazit

Eine Vektor-Datenbank ist die richtige Wahl für offene, qualitative Fragen und verdient daher ihren Platz. Wenn ein Chatbot einen Wert angeben muss – wie beispielsweise eine Prävalenz, einen KPI-Wert, eine Umsatzzahl oder einen Konformitätsgrenzwert – ist das Abrufen aus einer Datenbank das falsche Verfahren, denn eine zuverlässige Version dieses Wertes wurde bereits berechnet und niemals in Prosa festgehalten. RAG wird entweder darauf verzichten, was ehrlich ist, oder ihn erfinden, was es nicht ist. OKF berechnet den Wert, überprüft ihn gegen die Quelle bei der Erstellung und liefert ihn aus: vier Markdown-Dateien in einer Lambda-Instanz, ohne zusätzliche Einrichtung, und das bei jeder Testversion.

Die Dutzend Dokumente waren nicht das Problem – der fehlende Wert schon, und das Weiterfüllen des Speichers würde ihn niemals liefern. Berechnen Sie Ihre eigenen Werte.