Warum deine KI generisch antwortet

Die wichtigste Information über deine Notizen kann keine KI erzeugen: wofür sie gut sind — und wofür nicht. Dieser Artikel zeigt, was ein Datenkonzern daraus macht und wie du dieselben drei Handgriffe in einer halben Stunde in deinem eigenen System einrichtest.
Warum deine KI generisch antwortet

Seit Monaten kreist meine Arbeit um dieselbe Frage: Wie bringe ich meinen persönlichen Kontext so in eine KI ein, dass am Ende etwas herauskommt, das wirklich meins ist? Nicht bloss plausibel. Nicht generisch. Und vor allem: keine blosse Spiegelung dessen, was ich ohnehin schon denke.

Genau davor habe ich zuletzt in Die Narzissmusfalle der KI gewarnt. Eine KI, die dir vor allem dein eigenes Echo zurückgibt, fühlt sich gut an — sie bestätigt dich, aber sie bringt dich keinen Schritt weiter. Was ich suche, ist das Gegenteil: Antworten, die anschlussfähig sind an das, was ich denke, weiss und vorhabe — und die mir trotzdem widersprechen können.

Das ist mein eigentliches Interesse an der Arbeit mit KI. Nicht das Werkzeug, nicht das Modell — sondern die Frage, wie meine Perspektive in den Prozess kommt. Deshalb strukturiere ich Notizen, deshalb führe ich Chats statt einzelne Prompts abzufeuern, deshalb baue ich an einem System, das mein Denken abbildet.

Und genau deshalb hat die aktuelle Folge des Podcasts «AI to the DNA» mein Interesse geweckt, denn in ihr spricht Christoph Magnussen mit Marc Holger Berg, dem CEO von Statista. Angehört habe ich sie aus einem ganz anderen Grund: Mich interessierte die Geschäftsmodell-Frage — was passiert mit einem Datenanbieter, wenn KI-Suchmaschinen die Antworten direkt ausliefern und der Website-Traffic wegbricht? Hängengeblieben bin ich dann an einer völlig anderen Stelle.

Berg berichtet, dass Statista die Antwortqualität seiner KI-Schnittstellen um 15 bis 20 Prozentpunkte steigert. Kein neues Modell. Keine neuen Daten. Kein grösseres Kontextfenster. Derselbe Datensatz — nur anders vorbereitet.

In dem Moment war klar: Statista löst mit Konzernbudget exakt das Problem, an dem ich an meinem Schreibtisch arbeite. Und du vermutlich auch. Du hast Daten. Du hast ein LLM. Du verbindest beides — und das Ergebnis bleibt teilweise trotzdem erstaunlich beliebig. Nicht weil das Modell zu schwach wäre. Sondern weil ihm dein Kontext fehlt.

Warum gute Modelle an schlechten Daten scheitern

Berg unterscheidet im Gespräch sauber zwischen zwei Datenarten: Trainingsdaten und Kontextdaten. Trainingsdaten sind das, womit ein Modell gebaut wurde. Sie bringen die Logik mit — die Fähigkeit, eine Frage zu strukturieren und eine Antwort zu formulieren.

Seine Analogie dazu ist treffend: Foundation Models sind wie ein hochintelligenter Unternehmensberater. Sehr viel Strukturwissen, sehr viel Logik. Aber wenn du diesen Berater nicht in dein Unternehmen lässt und ihm keinen Blick in deine internen Zahlen erlaubst, bleibt jede Antwort generisch. Nicht falsch. Nur belanglos.

«Um diese Frage zu beantworten, braucht auch ein LLM oder ein gutes Foundation Model Zugang zu möglichst aktualisierten, gut strukturierten und vor allen Dingen verifizierten Daten», sagt Berg.

Drei Adjektive, die alles entscheiden: aktuell, strukturiert, verifiziert.

Magnussen bringt die Konsequenz auf den Punkt. Ohne saubere Datenaufbereitung, sagt er, hast du keine Chance, eine funktionierende Feedback-Schleife im Arbeitsprozess zu bauen. Alle versuchen es. Es funktioniert nicht. Es braucht einen Schritt davor.

Dieser Schritt davor ist das Thema dieses Artikels — und ein Thema, das mich seit Langem begleitet. Natürlich habe auch ich an Prompts gefeilt, Modelle verglichen und Tools gewechselt. Aber der eigentliche Hebel war mir klar: Es ist der Kontext, den ich der KI vorlege. Genau das habe ich in «Werde zum Kontext-Architekten» ausgeführt.

Umso mehr freut mich, diese Überzeugung hier bestätigt zu finden — nicht als Meinung, sondern belegt durch die Praxis eines Datenunternehmens. Was Statista mit Taxonomien und Evals im grossen Massstab betreibt, mache ich seit Jahren im Kleinen in meinem eigenen System.

Das Bild zeigt eine Notiz aus meinem Notion-Setup — die Zusammenfassung eines Coaching-Gesprächs. Bevor der eigentliche Inhalt beginnt, steht dort ein Block aus Metadaten: Datum, Status («In Progress»), Typ («Thought»), das verknüpfte Projekt und eine kurze Zusammenfassung in eigenen Worten. In der Seitenleiste kommen Kontext, PARA-Status und Verantwortlichkeit dazu.

Für mich ist das Ordnung. Für ein LLM ist es der entscheidende Unterschied. Es liest nicht nur, was in der Notiz steht, sondern erfährt auch, wofür sie gut ist, wie verbindlich sie ist und zu welchem Projekt sie gehört. Das ist nichts anderes als ein Eval im Kleinformat.

Von Taxonomien zu Evals

Statista hat sein Selbstverständnis verschoben: Nicht mehr die Plattform statista.com ist das Produkt, sondern die Daten selbst — ausgeliefert über APIs, MCP-Server und direkte Integrationen in Word, Salesforce oder Copilot. Damit das funktioniert, mussten die Daten anders aufbereitet werden.

Erstens: neue Taxonomien und viel mehr Metadaten.
Berg beschreibt es am Beispiel alkoholfreier Getränke. Man muss eine relativ breite Masse an Informationen bereitstellen, die mit der Originärstatistik gar nichts zu tun haben. Warum? «LLMs sind nicht deterministisch. Die lernen über Kontext. Und je mehr Kontext ich provide, desto besser ist es.»

Das klingt banal, ist es aber nicht. Ein LLM sucht nicht wie eine SQL-Datenbank nach exakten Begriffen. Es sucht nach semantischer Nähe. Eine Tabelle mit dem Titel «Absatz von alkoholfreiem Bier in Lateinamerika 2018–2025» scheitert an der Frage «Welche Getränkemärkte in Südamerika eignen sich für den Premium-Einstieg?». Nicht weil die Daten fehlen. Sondern weil «Südamerika» und «Premium» im Datensatz nicht vorkommen — und weil nirgends steht, welche Frage diese Statistik überhaupt beantworten kann.

Zweitens: Evaluation Frameworks, kurz Evals.
Hier wird es interessant. Statista schaltet beim Anlegen der Daten einen menschengeführten Qualifizierungsprozess dazwischen. Der Researcher, der eine Statistik erfasst, bekommt vom System rund fünf gezielte Fragen gestellt:

  • Kann diese Statistik Fragen zu Gesundheitstrends in Schwellenländern beantworten? → vollständig / teilweise / gar nicht
  • Eignet sich die Statistik für Ländervergleiche? → teilweise, nur Brasilien und Mexiko

Diese Antworten werden als strukturierte Metadaten direkt an das Datenobjekt gehängt. Über Tausende von Statistiken hinweg entsteht daraus ein Such-Kompass — eine Art Routing-Layer, den das Modell liest, bevor es die Rohdaten anfasst.

Das Ergebnis: 15 bis 20 Prozentpunkte bessere Antworten auf identischer Datenbasis. Bergs Erklärung dafür ist nüchtern: «Es fehlten qualitative, beschreibende Elemente, die LLMs brauchen, um die richtigen Daten zu extrahieren.»

Drei Effekte greifen ineinander. Das Retrieval wird präziser, weil nur noch nachweislich passende Daten in die Auswahl kommen. Das Modell versteht seine eigenen Lücken und kann sie transparent benennen. Und bei tausenden ähnlichen Datensätzen entsteht ein sinnvolles Ranking.

Ein Nebenbefund, der mich überrascht hat: Berg sagt, die Antwortqualität über den eigenen MCP-Server sei teilweise deutlich besser als die Suchtechnologie, die Statista sechs Jahre lang selbst entwickelt hat. «Du musst kein Experte mehr sein, du musst kein SQL mehr können.» Natural Language Query schlägt die spezialisierte Suchmaschine — sobald die Daten richtig beschrieben sind.

Und wo es trotzdem an Grenzen stösst

Jetzt die Übersetzung auf die persönliche Wissensarbeit. Wenn du ein persönliches Wissensmanagement pflegst — einen Zettelkasten, ein Second Brain, ein Notion-Setup — dann machst du einen grossen Teil dieser Arbeit bereits. Unbewusst, aber systematisch.

Inhärenter Kontext statt Rohdaten. Jemand ohne System lädt einen 50-seitigen Branchenbericht in den Chat. Du lädst deine Zusammenfassung hoch, in der bereits steht: wichtig für Projekt X, trifft auf Markt Y nicht zu, Problem ist Z. Das ist kein Rohdatensatz. Das ist ein qualifizierter Datensatz.

Vernetzung und Blickwinkel. Durch deine Fragen, deine Kommentare und die Art, wie du Gedanken verknüpfst, lieferst du dem Modell deinen persönlichen Denkrahmen mit. Genau das habe ich in «Werde zum Kontext-Architekten» beschrieben: Dein Kontext ist der Leuchtturm, an dem sich die KI orientiert.

Filterwirkung. Dein System enthält vorgefiltertes Wissen. Das Modell muss nicht aus zehntausend Webseiten auswählen, sondern greift auf eine kuratierte Basis zu.

Soweit die gute Nachricht. Jetzt die schlechte.

Auch ein gepflegtes PKM hat blinde Flecken — und zwar genau die drei, die Statista mit Evals schliesst.

Der Status- und Zeitkonflikt. Ein LLM sieht alle deine Notizen als gleichwertig nebeneinander. Die Notiz von 2022 («Wir launchen Produkt X im Mai») und die von 2024 («Produkt X wurde verworfen») haben für das Modell dasselbe Gewicht. Ein Entwurf wiegt so schwer wie eine finale Entscheidung.

Der blinde Fleck für Nicht-Wissen. Fragst du nach Daten zur Altersgruppe 18–25 und die gibt es nicht, leitet das Modell lieber irgendetwas Ähnliches ab, als klar zu sagen: fehlt.

Der blinde Fleck für Intent. Ohne Kennzeichnung weiss das Modell nicht, wofür ein Dokument gedacht war — strategische Richtlinie, flüchtige Notiz oder veralteter Bericht.

Die Lösung ist unspektakulär und in einer halben Stunde eingeführt. Zum Beispiel mit drei Ebenen:

  1. Metadaten-Kopf. Gib wichtigen Notizen einen kurzen Block: Dokumenttyp, Gültigkeitszeitraum, «beantwortet Fragen zu», und — der unterschätzte Teil — «beantwortet NICHT».
  2. Guardrails im Prompt. Das ist der Punkt, der mich an dieser Recherche am meisten begeistert hat — und mein persönlicher Lernschritt daraus. Bisher habe ich meine Prompts vor allem darauf ausgerichtet, was die KI tun soll. Was gefehlt hat: die klare Ansage, was sie nicht darf. Genau das ist eine Guardrail — eine Leitplanke im Prompt: «Nutze eine Quelle nur, wenn ihre Metadaten das Thema vollständig oder teilweise abdecken. Reicht die Datenbasis nicht, sag es mir offen, statt zu ergänzen.» Zwei Sätze — aber sie verschieben die Haltung des Modells von «irgendetwas liefern» zu «sauber arbeiten».
  3. Automatisierte Anreicherung. Bei grösseren Beständen kannst du ein zweites, günstigeres Modell vorschalten, das Tags und Leitfragen generiert, bevor die Notiz in den Bestand wandert.

In vielen Apps hast du das Werkzeug dazu bereits: Tags, Kategorien, Ordnerstrukturen — oder, wie in Notion, Datenbank-Properties. So unterschiedlich sie heissen, sie leisten dasselbe: Sie hängen Metadaten an deine Inhalte. Status, Datum, Kontext, Zusammenfassung — jedes ausgefüllte Feld ist ein Eval. Der Unterschied zwischen einem Notizhaufen und einer KI-lesbaren Wissensbasis liegt oft nur darin, ob diese Felder gepflegt sind.

Bei mir ist das inzwischen Routine. Jede Notiz, die in meinem System landet, bekommt Status, Kontext und eine Zusammenfassung in eigenen Worten. Was früher nach Ordnungsliebe aussah, ist heute Vorarbeit für jeden KI-Chat — und der Grund, warum meine Antworten präziser ausfallen als die aus einem leeren Chatfenster.

Einwände und Antworten

«Das ist Enterprise-Kram. Ich bin eine Einzelperson mit 800 Notizen.»

Der Massstab unterscheidet sich, das Prinzip nicht. Statista braucht Evals für Millionen Datenpunkte und automatisiert deshalb. Du brauchst sie für die zwanzig Notizen, die du regelmässig als Kontext einspeist. Fang mit denen an.

«Die Modelle werden besser. Das erledigt sich von selbst.»

Grössere Kontextfenster lösen das Auffinden, nicht das Bewerten. Kein Modell kann von aussen erkennen, ob deine Notiz von 2024 die von 2022 ersetzt oder ergänzt. Diese Information existiert nur in deinem Kopf — bis du sie aufschreibst. Kontextkompetenz wird mit besseren Modellen wichtiger, nicht überflüssig.

«Das ist zu viel Aufwand. Ich will schneller werden, nicht langsamer.»

Der Aufwand fällt einmal an, der Nutzen bei jeder Abfrage. Und er ist kleiner, als er klingt: drei Zeilen Metadaten pro Notiz. Meine Erfahrung deckt sich mit dem, was ich in «Werde zum Kontext-Architekten» beschrieben habe — wer seinen Kontext vorbereitet hat, braucht für einen produktiven Chat Minuten statt Stunden.

«Dann macht die KI am Ende doch meine Denkarbeit.»

Nein — im Gegenteil. Vorstrukturieren ist Denkarbeit. Zu entscheiden, welche Frage eine Notiz beantwortet und welche nicht, zwingt dich zur Klärung. In «KI im Zettelkasten» habe ich argumentiert, dass die KI die Verwaltung übernehmen darf, aber nicht das Denken. Evals sind der Beweis: Die wertvollste Metadateninformation stammt vom Menschen, weil nur er den Zweck kennt.

Abschlussgedanken

Statista investiert erheblich in Taxonomien, Metadaten und Evaluation Frameworks — und bekommt dafür 15 bis 20 Prozentpunkte bessere Antworten auf unveränderter Datenbasis. Das ist die eigentliche Nachricht aus diesem Podcast.

Übersetzt auf deine Arbeit heisst das: Der Hebel liegt nicht im Modellwechsel. Er liegt davor. In der Frage, ob deine Notizen dem System sagen können, wofür sie gut sind — und wofür nicht.

Ein gepflegtes Second Brain gibt dir dabei einen echten Vorsprung, weil dein Kontext bereits eingebaut ist. Aber der Vorsprung ist nicht automatisch. Er entsteht dort, wo du bewusst kennzeichnest, was aktuell ist, was gilt und was eine Notiz beantwortet.

Das LLM steht dir zur Verfügung. Die Stärke seiner Antwort liegt in der Kontextualisierung deiner Frage.


Alles, was hier beschrieben ist, setzt eines voraus: ein System, in dem dein Wissen überhaupt strukturiert liegt. Genau dafür habe ich die Roadmap zum Second Brain geschrieben. Sie zeigt dir Schritt für Schritt, wie du erfasst, strukturierst und verdichtest.

Du hast dein System bereits und willst den nächsten Schritt? Tiago Forte hat sein Programm nach drei Jahren Lehrpause komplett neu gedacht. The AI Second Brain* ist ein dreiwöchiges Live-Training, in dem du ein personalisiertes KI-System auf Basis deiner eigenen Notizen und Dateien baust. Kein Prompting-Kurs — Systemarbeit.


Quellen & Referenzen

Abonniere meinen Newsletter

Und erhalte regelmässig Gedanken aus meinem digitalen Garten.