SAKIZLI AI
Article23. August 2026 · 15 Min. Lesezeit4 / 8Frei · Öffentlich

Vom Research-Pool zur Wissensdatenbank — Quellen in ein arbeitsfähiges System verwandeln

Ein Ordner voller Recherche ist noch kein Projektwissen. Erst wenn Quellen, Zusammenhänge, Widersprüche und Projektergebnisse so strukturiert werden, dass Menschen und KI sie wiederfinden, prüfen und für Entscheidungen nutzen können, entsteht eine arbeitsfähige Wissensbasis.

WissensmanagementWissensarchitekturHerkunftProjektmanagement
FFurkan SakızlıKI-Forscher & Tutor · unabhängig
Abstrakte Wissensarchitektur in Blau und Weiß: viele einzelne Research-Karten werden schrittweise zu einer verbundenen Wissensstruktur
Viele einzelne Research-Karten werden schrittweise zu einer verbundenen Wissensstruktur

Nach einer guten Research-Kette entsteht zunächst etwas sehr Wertvolles – und zugleich etwas Unbequemes: viele Dokumente. Verschiedene Recherchen beleuchten unterschiedliche Perspektiven, enthalten Überschneidungen, widersprechen sich teilweise und liegen oft in verschiedenen Detailstufen vor. Genau an diesem Punkt beginnt ein zweiter Arbeitsschritt, der im KI-Projektmanagement leicht unterschätzt wird.

Die Frage lautet nicht mehr: Was können wir noch recherchieren? Sie lautet: Wie wird aus dem gesammelten Material ein Wissenssystem, mit dem das Projekt tatsächlich arbeiten kann?

Dieser Übergang lässt sich sehr konkret beobachten: Dutzende Deep-Research-Dokumente werden zusammengeführt, semantisch verknüpft und in eine Wissensbasis überführt. Der entscheidende Gedanke dahinter ist unabhängig vom verwendeten Tool: Ein Research-Pool ist Rohmaterial. Eine Wissensdatenbank ist eine Arbeitsarchitektur.

Ein Research-Pool ist wertvoll, aber noch nicht steuerbar

Stellen wir uns 40, 60 oder 100 Recherchedateien vor. Jede einzelne kann gut sein. Trotzdem entstehen sofort praktische Probleme:

• Welche Datei beantwortet welche Frage?

• Welche Aussagen wiederholen sich nur?

• Wo widersprechen sich Quellen?

• Welche Erkenntnis ist bereits gesichert, welche nur wahrscheinlich?

• Welche Information gehört zum Markt, welche zur Technik, welche zu Risiken oder Anforderungen?

• Welche Erkenntnis wurde bereits in eine Projektentscheidung übersetzt?

• Welche Quelle ist veraltet oder nur noch historisch relevant?

Ein Mensch kann sich durch eine kleine Sammlung noch manuell arbeiten. Mit wachsendem Projektumfang wird das zunehmend teuer. Eine KI kann große Mengen schneller lesen, aber auch sie braucht eine Struktur, damit Herkunft und Zusammenhang nicht verloren gehen.

Das Problem ist deshalb nicht primär die Dateimenge. Das Problem ist fehlende Orientierung zwischen den Dateien.

Eine Wissensdatenbank hat mindestens drei Schichten

Für KI-Projekte ist es hilfreich, eine Wissensbasis nicht als einen großen Speicher zu betrachten, sondern als drei miteinander verbundene Ebenen.

1. Die Quellenebene

Hier liegen die Originale: Research-Dokumente, Studien, Protokolle, interne Analysen, Kundenfeedback, technische Notizen, Ergebnisse und später auch Projektdokumente.

Diese Ebene sollte möglichst wenig redaktionell verändert werden. Ein Original verliert an Wert, wenn niemand mehr weiß, was tatsächlich in der Quelle stand und was später zusammengefasst oder interpretiert wurde.

Zur Quellenebene gehören mindestens: eindeutiger Name oder stabile ID; Herkunft; Datum oder Versionsstand; Thema beziehungsweise Geltungsbereich; Status: aktuell, ungeprüft, ersetzt, historisch; bei Bedarf Sensitivität oder Zugriffsgrenze.

Die Quellenebene ist das Beweisgedächtnis des Projekts.

2. Die semantische Ebene

Hier entstehen Beziehungen. Eine Recherche zu Datenqualität wird mit einer technischen Machbarkeitsanalyse verbunden. Eine Nutzerbeobachtung verweist auf eine Anforderung. Zwei Quellen werden als Widerspruch markiert. Mehrere Researches werden unter einem gemeinsamen Konzept zusammengeführt.

Die semantische Ebene beantwortet Fragen wie: Welche Dokumente sprechen über denselben Begriff? Welche Erkenntnisse stützen dieselbe Anforderung? Welche Aussagen widersprechen einander? Welche Informationen gehören zu einem gemeinsamen Risiko? Welche Quelle ist für eine bestimmte Entscheidung besonders relevant?

Diese Ebene verwandelt Speicherung in Orientierung.

3. Die operative Ebene

Hier wird Wissen handlungsfähig. Erkenntnisse werden in Entscheidungen, Anforderungen, Aufgaben, Risiken, Prüfungen und Projektartefakte übersetzt.

Ein Projektteam fragt dann nicht mehr nur: „Was steht in unseren Quellen?", sondern: Welche Erkenntnisse verändern unseren Scope? Welche offenen Punkte blockieren die nächste Entscheidung? Welche Anforderungen sind ausreichend belegt? Welche Annahme muss getestet werden? Welche Projektergebnisse müssen zurück in die Wissensbasis?

Erst diese Ebene macht aus einer Wissenssammlung ein Projektinstrument.

Das Original bleibt erhalten – die Verdichtung kommt darüber

Ein häufiger Fehler bei der Konsolidierung besteht darin, viele Quellen in einen einzigen großen „Mastertext" zu verschmelzen. Das wirkt aufgeräumt, kann aber genau die Unterschiede vernichten, die später wichtig werden.

Besser ist ein zweistufiges Prinzip: Original behalten. Verdichtung ergänzen.

Zu einem Quellendokument kann beispielsweise eine kurze Extraktion entstehen:

source-note.mdmarkdown
# SOURCE NOTE

Quelle: R-017
Thema: Datenanforderungen für lokales KI-System

## Kernaussagen
- ...
- ...

## Relevanz für das Projekt
- ...

## Grenzen / offene Punkte
- ...

## Verknüpfungen
- [[Datenqualität]]
- [[Lokale Architektur]]
- [[Risiko: fehlende Aktualität]]

Die Kurznotiz ist nicht die Quelle. Sie ist eine Navigationsschicht zur Quelle.

Das ist für Menschen genauso wichtig wie für KI-Agenten. Eine Zusammenfassung kann schnell gelesen werden. Wenn eine Aussage entscheidungsrelevant wird, muss der Weg zurück zum Original offen bleiben.

Semantische Verknüpfung ist mehr als Ordnerstruktur

Ordner beantworten vor allem die Frage: Wo liegt etwas? Eine Wissensarchitektur muss zusätzlich beantworten: Womit hängt es zusammen?

Eine Datei kann gleichzeitig relevant sein für:

• technische Machbarkeit;

• Datenschutz;

• Kosten;

• Nutzererlebnis;

• Beschaffung;

• Projektrisiko.

In einer klassischen Ordnerlogik müsste man sich für einen Ablageort entscheiden oder Kopien anlegen. Semantische Verknüpfungen erlauben stattdessen, dieselbe Quelle in mehreren fachlichen Zusammenhängen sichtbar zu machen.

Das ist besonders wichtig in KI-Projekten, weil viele Entscheidungen quer zu Disziplinen verlaufen. Eine Architekturentscheidung kann gleichzeitig Kosten, Datenhaltung, Fähigkeiten des Teams und spätere Compliance beeinflussen.

Wissen ist deshalb eher ein Netz als ein Regal.

Widersprüche gehören in die Datenbank – nicht unter den Teppich

Wenn zwei Researches zu unterschiedlichen Ergebnissen kommen, ist die Versuchung groß, die „bessere" Aussage auszuwählen und die andere verschwinden zu lassen. Für Projektarbeit ist das gefährlich.

Ein Widerspruch kann entstehen durch: unterschiedliche Zeitpunkte; unterschiedliche Definitionen; andere Zielgruppen; verschiedene Annahmen; ungleiche Datenqualität; unterschiedliche Messmethoden.

Deshalb sollte ein Wissenssystem Konflikte sichtbar halten.

conflict-note.mdmarkdown
# CONFLICT NOTE

Thema: Erwartete Betriebskosten

Quelle A:
- Aussage ...

Quelle B:
- Aussage ...

Mögliche Ursache des Unterschieds:
- ...

Was muss geprüft werden?
- ...

Auswirkung auf Entscheidung:
- ...

Damit wird der Widerspruch selbst zu einer Arbeitsaufgabe. Das System verhindert, dass Unsicherheit durch eine schöne Zusammenfassung unsichtbar wird.

Eine Wissensdatenbank braucht Karten, nicht nur Dateien

Je größer die Sammlung wird, desto wichtiger werden Einstiegspunkte. Niemand sollte 80 Dateinamen überfliegen müssen, um zu verstehen, wie das Projektwissen organisiert ist.

Hilfreich sind sogenannte Maps of Content, Übersichten oder Themenkarten. Sie bündeln nicht den gesamten Inhalt, sondern zeigen die wichtigsten Beziehungen.

Eine Themenkarte „Technische Architektur" könnte beispielsweise enthalten:

map-technische-architektur.mdmarkdown
# MAP — TECHNISCHE ARCHITEKTUR

## Grundlagen
- [[R-004 Systemanforderungen]]
- [[R-011 Infrastrukturvergleich]]

## Entscheidungen
- [[D-003 Hybridarchitektur]]

## Risiken
- [[RK-007 Anbieterabhängigkeit]]
- [[RK-012 Datenabfluss]]

## Offene Fragen
- [[Q-018 Betriebskosten]]
- [[Q-024 Backup-Strategie]]

Eine solche Karte ist kein Ersatz für die Dokumente. Sie ist eine Lesebrille für den Wissensraum.

Struktur muss aus dem Inhalt wachsen

Dabei wird ein wichtiger Punkt deutlich: Eine vorhandene Datenbankstruktur sollte nicht blind kopiert werden, nur weil sie bereits existiert. Die Struktur muss zum Material und zum Projekt passen.

Das bedeutet: Nicht zuerst 30 Ordner erfinden und anschließend versuchen, jede Quelle hineinzuzwingen. Besser ist:

1. Quellen lesen;

2. wiederkehrende Themen erkennen;

3. relevante Beziehungen identifizieren;

4. daraus Kategorien, Karten und Verknüpfungen entwickeln;

5. Struktur später vereinfachen, wenn sie zu komplex wird.

Diese Vorgehensweise ist näher an echter Wissensarbeit. Sie vermeidet ein häufiges Problem: eine technisch schöne Ablage, die fachlich nichts erklärt.

Verdichten ohne Herkunftsverlust

In realen Projekten gibt es Plattformgrenzen. Ein Browser-Workspace kann vielleicht nur eine begrenzte Zahl von Dateien aufnehmen. Ein Modell hat ein begrenztes Kontextfenster. Ein Teammitglied arbeitet mobil und kann nicht den gesamten Vault laden.

Dann ist Kompression sinnvoll – aber sie muss kontrolliert sein.

Ein robustes Prinzip lautet: Quelle → Extraktion → Synthese → Arbeitskontext. Nicht: Quelle → Zusammenfassung → Original vergessen.

Für einen kleineren Arbeitskontext können beispielsweise 60 Quellen in zehn thematische Synthesen verdichtet werden. Diese Synthesen müssen jedoch weiterhin auf die ursprünglichen Quellen verweisen. So bleibt nachvollziehbar, woher eine Aussage stammt.

Die komprimierte Ebene ist eine Transportform des Wissens, nicht dessen alleiniger Speicher.

Die Datenbank endet nicht mit der Recherchephase

Eine der stärksten Ideen aus dem Kurs ist, dass die Wissensdatenbank nicht nur den Projektstart unterstützt. Sie begleitet das gesamte Vorhaben.

Während des Projekts kommen neue Artefakte hinzu: Machbarkeitsanalysen; Entscheidungen und Begründungen; Tests und Testergebnisse; Kundenfeedback; Änderungswünsche; Fehler und Incidents; neue Recherchen; Statusberichte; Retrospektiven; finale Ergebnisse.

Dadurch wächst aus einer Recherchebasis schrittweise ein Projektgedächtnis.

Die Wissensdatenbank wird damit zum verbindenden Element zwischen Planung, Umsetzung, Review und späterem Lernen. Im Kurs wurde dafür das Bild des „Rückenmarks" verwendet: Informationen laufen nicht nur hinein, sondern verbinden die verschiedenen Teile der Projektarbeit.

Die KI wird zum Archivar – aber nur mit klaren Regeln

Eine gut strukturierte Wissensbasis erlaubt der KI, Beziehungen schneller zu erkennen. Sie kann Fragen beantworten wie: Welche Entscheidung beruht auf dieser Quelle? Welche offenen Risiken hängen mit dieser Anforderung zusammen? Welche Erkenntnisse wurden seit dem letzten Planungsstand ergänzt? Welche Quellen widersprechen der aktuellen Annahme? Welche Dokumente müssen für eine Review gelesen werden?

Das bedeutet jedoch nicht, dass eine KI automatisch zum verlässlichen Wissensmanager wird. Sie braucht Regeln:

• Quellen dürfen nicht stillschweigend überschrieben werden;

• Synthesen müssen von Originalen unterscheidbar bleiben;

• Widersprüche werden markiert statt geglättet;

• unklare Herkunft wird als Unsicherheit behandelt;

• veraltete Informationen werden nicht wie aktuelle verwendet;

• sensible Daten erhalten klare Zugriffsgrenzen.

Die Qualität des KI-Zugriffs hängt direkt von der Qualität der Wissensarchitektur ab.

Tool-neutral denken: Die Methode kommt vor Obsidian oder Drive

Obsidian eignet sich sehr gut für verknüpfte Markdown-Wissensräume. Ein Dateisystem kann für kleine Projekte völlig ausreichen. Auch spezialisierte Knowledge-Graph-Systeme können sinnvoll sein.

Für die Methode ist das Werkzeug zunächst zweitrangig.

Eine minimale Wissensarchitektur kann so aussehen:

wissensarchitektur.txttext
01 Quellen
02 Extraktionen
03 Konzepte
04 Widersprüche
05 Entscheidungen
06 Risiken
07 Projektergebnisse
08 Übersichten

Wichtiger als die Ordnernamen sind vier Eigenschaften:

1. Herkunft bleibt sichtbar.

2. Beziehungen sind nachvollziehbar.

3. Status und Aktualität sind erkennbar.

4. Wissen kann in eine konkrete Projektentscheidung überführt werden.

Wenn diese vier Punkte erfüllt sind, kann die Struktur später in Obsidian oder ein anderes System überführt werden, ohne die Logik neu erfinden zu müssen.

Ein praktischer Acht-Schritte-Ablauf

Schritt 1 — Quellen inventarisieren

Jede Datei erhält eine stabile Kennung, Herkunft, Datum und einen groben Themenbezug.

Schritt 2 — Duplikate und Varianten erkennen

Gleiche oder fast gleiche Dokumente werden markiert. Ältere Versionen bleiben auffindbar, aber ihr Status wird sichtbar.

Schritt 3 — Kernaussagen extrahieren

Nicht alles zusammenfassen. Nur projektentscheidende Aussagen, Grenzen, Beispiele und offene Fragen herausziehen.

Schritt 4 — Konzepte und Themen bilden

Wiederkehrende Begriffe werden zu Konzeptkarten. Quellen können mehreren Konzepten zugeordnet werden.

Schritt 5 — Widersprüche markieren

Abweichende Aussagen werden nicht sofort aufgelöst. Zuerst werden Ursache und Entscheidungsrelevanz untersucht.

Schritt 6 — Übersichten bauen

Für zentrale Projektbereiche entstehen Maps oder Indexseiten, die Menschen und KI schnell in den Wissensraum führen.

Schritt 7 — Projektentscheidungen verknüpfen

Entscheidungen verweisen auf die Quellen und Synthesen, auf denen sie beruhen. So bleibt sichtbar, warum der aktuelle Plan so aussieht.

Schritt 8 — Wissen während der Umsetzung weiterpflegen

Neue Ergebnisse, Tests, Feedback und Änderungen fließen zurück. Die Wissensbasis bleibt lebendiges Arbeitsmaterial statt statisches Archiv.

Wann ist eine Wissensdatenbank arbeitsfähig?

Nicht wenn sie groß ist. Nicht wenn sie hübsch aussieht. Und auch nicht, wenn jedes Dokument irgendwo abgelegt wurde.

Sie ist arbeitsfähig, wenn eine Person oder ein Agent zuverlässig beantworten kann: Welche Quelle trägt diese Aussage? Welche anderen Informationen hängen damit zusammen? Wo gibt es Unsicherheit oder Widerspruch? Welcher Stand ist aktuell? Welche Entscheidung wurde daraus abgeleitet? Welche nächste Frage oder Aufgabe entsteht daraus?

Damit verändert sich die Rolle der Recherche. Sie ist nicht länger eine Vorphase, die nach dem Projektplan verschwindet. Sie wird zum ersten Teil eines kontinuierlichen Wissenskreislaufs.

Fazit: Nicht mehr Dateien, sondern mehr Zusammenhang

KI macht es leicht, große Mengen an Recherche zu erzeugen. Genau deshalb wird die zweite Fähigkeit wichtiger: Wissen zu organisieren, ohne seine Herkunft, Unterschiede und Unsicherheiten zu zerstören.

Ein Research-Pool sammelt Perspektiven. Eine Wissensdatenbank macht sie auffindbar, verknüpft und handlungsfähig. Sie hält Originale und Synthesen auseinander, bewahrt Widersprüche, verbindet Erkenntnisse mit Entscheidungen und wächst während des Projekts weiter.

Der entscheidende Schritt ist also nicht, möglichst viel Material in ein Tool zu laden. Er lautet: Baue einen Wissensraum, in dem jede wichtige Erkenntnis einen Ort, eine Herkunft, einen Zusammenhang und eine nächste Verwendung besitzt.

Genau auf dieser Grundlage kann der nächste Artikel aufbauen: Wenn mehrere Menschen oder Projekte unterschiedliche Vorgehensweisen, Erfahrungen und Lösungen liefern, kann diese Wissensbasis genutzt werden, um daraus ein gemeinsames Methoden-Mapping zu entwickeln.

Übungsblatt: Baue aus sechs Researches eine Mini-Wissensdatenbank

Wähle sechs Recherche- oder Projektdokumente zu einem gemeinsamen Thema. Ziel ist kein perfekter Vault, sondern eine kleine, nachvollziehbare Wissensarchitektur.

1. Quellen inventarisieren

Vergib für jede Datei eine ID und notiere Herkunft, Datum, Thema und Status.

2. Kernaussagen extrahieren

Schreibe pro Quelle höchstens fünf Aussagen auf, die eine Projektentscheidung verändern könnten.

3. Drei Konzeptkarten anlegen

Bilde drei wiederkehrende Themen und verknüpfe jede Quelle mit mindestens einer Konzeptkarte.

4. Einen Widerspruch dokumentieren

Suche zwei Aussagen, die nicht vollständig zusammenpassen. Formuliere Ursache, offene Frage und mögliche Auswirkung.

5. Eine Übersichtsseite bauen

Erstelle eine Seite, von der aus du Quellen, Konzepte, Widerspruch und offene Fragen direkt erreichen kannst.

6. Eine Entscheidung verknüpfen

Formuliere eine kleine Projektentscheidung und nenne die Quellen, auf denen sie beruht.

7. Rückfluss definieren

Lege fest, welche neuen Projektergebnisse später wieder in die Wissensbasis aufgenommen werden müssen.

Reflexion

Welche Information wäre in einem reinen Dateiordner am wahrscheinlichsten verloren gegangen? __________________________________________

Welche Beziehung zwischen zwei Quellen verändert deine Projektentscheidung am stärksten? _____________________________________________

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

HTMLThemenübersicht: Vom Research-Pool zur Wissensdatenbank1 SeiteDOCXÜbungsblatt: Baue aus sechs Researches eine Mini-Wissensdatenbank30–45 min

0 Kommentare

Kommentare werden geladen…

Zum Kommentieren anmelden · Mitglied werden →