LLM Wiki

Das LLM-Wiki in der Softwareentwicklung: Persistentes Wissen über Code

Posted on by Christoph Hermanns

Der erste Beitrag dieser Serie beschrieb das LLM-Wiki als allgemeines Pattern zur kontinuierlichen Pflege von Wissen. Zwischen unveränderten Rohquellen und späteren Fragen entsteht eine persistente, menschenlesbare und überprüfbare Wissensschicht. Sie verdichtet Zusammenhänge, ohne die Quellen zu ersetzen, und macht Herkunft, Unsicherheit, Aktualität und Pflegebedarf sichtbar (Hermanns, 2026a).

Dieser zweite Artikel überträgt dieses Pattern auf die Softwareentwicklung. Die Rohquellen sind hier nicht vor allem Artikel, Notizen oder Gesprächsprotokolle, sondern Code, Tests, Tickets, Reviews, Releases, Konfiguration, Architekturentscheidungen und Betriebswissen. Gerade in langlebigen Softwareprojekten liegt der entscheidende Kontext selten an einem einzigen Ort.

Ein Beispiel macht das Problem sichtbar. Ein Entwickler steht vor einem API-Parameter, der ungewöhnlich defensiv behandelt wird. Der Code zeigt, wie der Parameter verarbeitet wird. Ein Test zeigt einen Grenzfall. Ein altes Ticket dokumentiert einen früheren Datenverlust. Ein Review erklärt, warum eine einfachere Lösung verworfen wurde. Eine Release Note zeigt, seit wann das Verhalten ausgeliefert ist.

Keine dieser Quellen erklärt den Zusammenhang allein. Erst zusammen beantworten sie die eigentliche Entwicklungsfrage: Darf dieser Parameter geändert werden, oder würde dadurch ein alter Fehler zurückkehren?

Genau an dieser Stelle wird das LLM-Wiki-Pattern für Softwareentwicklung relevant. Karpathy beschreibt das LLM-Wiki als eine von einem Large Language Model gepflegte Markdown-Wissensbasis zwischen Rohquellen und späterer Nutzung. Das Open Knowledge Format zeigt ergänzend, wie solche Wissensbestände durch gemeinsame Metadaten zu Herkunft, Vertrauen, Aktualität und Lebenszyklus portabler und besser bewertbar werden können (Karpathy, 2026; McVeety und Hormati, 2026a; McVeety und Hormati, 2026b; GoogleCloudPlatform, 2026).

Die zentrale These dieses Beitrags lautet: Softwareentwicklung braucht eine code-nahe Wissensschicht, weil Kontext sonst zur wiederkehrenden Nebenarbeit wird. Ein LLM-Wiki ersetzt weder Sourcecode noch Tests, Tickets oder Reviews. Es kann diese Quellen jedoch so miteinander verbinden, dass Menschen und KI-Agenten schneller erkennen, welche Aussagen belastbar sind, welche Quellen geprüft werden müssen und wo Unsicherheit oder Drift besteht.

Der Artikel ist damit noch kein Implementierungsleitfaden. Er erläutert, wie sich das Grundmuster aus der Pattern-Einführung auf Softwareentwicklung übertragen lässt, welche bestehenden Ansätze daran anschließen und woran der Nutzen eines solchen Knowledge Layers bewertet werden müsste.

1. Das Grundmuster in der Softwareentwicklung

Im Mittelpunkt des LLM-Wiki-Patterns steht nicht ein bestimmtes Werkzeug, sondern die Trennung zwischen ursprünglichen Quellen, synthetisierter Wissensbasis und Governance. Diese Trennung bleibt auch in der Softwareentwicklung maßgeblich. Sie verhindert, dass ein Wiki zur scheinbar autoritativen Ersatzquelle wird, und macht stattdessen sichtbar, aus welchen Primärquellen ein Verständnis abgeleitet wurde.

Übertragen auf Softwareentwicklung bedeutet dies: Die technische Realität bleibt in Code, Tests, Konfiguration, Datenmodell, Laufzeitverhalten und Releases verankert. Entwicklungswissen entsteht jedoch zusätzlich aus Tickets, Reviews, Architekturentscheidungen, Supportfällen, Fehlermeldungen, Betriebsnotizen und späteren Analysen. Ein code-naher Knowledge Layer hat die Aufgabe, diese Quellen in eine prüfbare Beziehung zu setzen. Die nachfolgende Abbildung fasst diese Übertragung zusammen: Aus unveränderten Softwarequellen entsteht eine kuratierte Wissensschicht, die durch Governance gepflegt und von Menschen sowie KI-Agenten genutzt wird.

Übertragung des LLM-Wiki-Schichtenmodells auf Softwareentwicklung. Code, Tests, Tickets, Reviews und weitere Primärquellen bleiben unverändert erhalten; der code-nahe Knowledge Layer verdichtet daraus prüfbare Zusammenhänge, während Governance Quellenführung, Aktualität, Unsicherheit und Informationsgrenzen steuert.

1.1 raw/: Code, Tests, Tickets und weitere Primärquellen

Die erste Ebene eines softwarebezogenen LLM-Wikis bildet die unveränderte Belegbasis. Im allgemeinen Pattern entspricht sie raw/; in der Softwareentwicklung umfasst sie mehrere Quelltypen. Dazu gehören der Sourcecode, automatisierte Tests, Konfigurationsdateien, Migrationsskripte, Build- und Deploymentlogik, Tickets, Pull-Request-Reviews, Architekturentscheidungen, Release Notes, Supportfälle und Betriebsnotizen.

Diese Quellen haben unterschiedliche Rollen. Code und Laufzeitverhalten zeigen, was ein System tatsächlich tut. Tests zeigen, welches Verhalten ausdrücklich abgesichert wird. Tickets und Reviews können Absichten, Alternativen und frühere Fehler erklären, sind aber nicht automatisch aktueller als der Code. Release Notes dokumentieren, ab wann ein Verhalten ausgeliefert wurde. Support- und Betriebsquellen zeigen, wie Annahmen in der Praxis brechen können.

Ein softwarebezogenes LLM-Wiki darf diese Quellen deshalb nicht überschreiben oder ersetzen. Es muss sie als Belegbasis erhalten und Aussagen auf sie zurückführen. Wenn Wiki und Code widersprechen, ist dies zunächst kein neues Wissen, sondern ein Drift-Signal. Die eigentliche Prüfung findet weiterhin an den Primärquellen statt.

1.2 wiki/: Der code-nahe Knowledge Layer

Die zweite Ebene entspricht der synthetisierten Wissensbasis des LLM-Wikis. Für Softwareentwicklung kann sie als code-naher Knowledge Layer verstanden werden. Er beschreibt Module, fachliche Abläufe, Schnittstellen, Architekturgrenzen, Entscheidungen, Risiken, bekannte Einschränkungen und offene Fragen.

Der Unterschied zu klassischer Dokumentation liegt in der Quellenbindung. Eine Wiki-Seite über ein Modul sollte nicht nur erklären, was das Modul tut. Sie sollte auch zeigen, welche Tests den beschriebenen Ablauf absichern, welche Tickets oder Entscheidungen den Kontext liefern, welche Konfiguration das Verhalten beeinflusst und welche Aussagen möglicherweise veraltet oder abgeleitet sind.

Damit wird der Knowledge Layer nicht zur Wahrheit über das System. Er wird zur Karte über die technische Realität. Seine Stärke besteht darin, Prüfpfade sichtbar zu machen: Welche Quellen stützen diese Aussage? Welche Annahmen sind nur abgeleitet? Welche Teile des Systems sollten vor einer Änderung gelesen werden?

1.3 Schema und Governance

Wie in der Pattern-Einführung ist Governance kein nachträglicher Zusatz, sondern Teil des Patterns. Für Softwareentwicklung muss das Schema festlegen, wie Wissensseiten aufgebaut sind, welche Quellenarten zulässig sind, wie Aktualität markiert wird, wie Widersprüche behandelt werden und welche Informationen an welche Konsumenten weitergegeben werden dürfen.

Praktische Regeln können sein:

  • Jede fachliche oder technische Wiki-Seite nennt maßgebliche Primärquellen.
  • Aussagen unterscheiden zwischen dokumentierter Realität, abgeleiteter Interpretation und offener Frage.
  • Widersprüche zwischen Wiki und Code werden nicht stillschweigend geglättet, sondern als Drift oder Klärungsbedarf markiert.
  • Seiten mit sicherheits-, betriebs- oder berechtigungsrelevantem Wissen führen Informationsgrenzen und zulässige Nutzergruppen.
  • Linting prüft regelmäßig veraltete Quellen, fehlende Rückverweise, unklare Statusangaben und wichtige Konzepte ohne eigene Seite.

Solche Regeln sind besonders wichtig, weil ein generierter oder mitgenerierter Wissenstext schnell glaubwürdiger wirken kann, als seine Quellenlage trägt.

1.4 Ingest, Query und Lint im Entwicklungsprozess

Auch die drei operativen Prozesse aus der Pattern-Einführung lassen sich auf Softwareentwicklung übertragen: Ingest, Query und Lint (Hermanns, 2026a).

Beim Ingest wird neues Entwicklungswissen in die Wissensschicht eingeordnet. Eine Änderung an Code, Tests, Ticketstatus, Release Notes oder Architekturentscheidung kann mehrere Wiki-Seiten berühren. Das LLM kann dabei helfen, betroffene Module, Begriffe, Entscheidungen und Risiken zu finden. Die fachliche Verantwortung verbleibt jedoch bei Menschen, Reviews und Tests.

Query bezeichnet die spätere Nutzung. Ein Entwickler, Tester, Supportmitarbeiter oder KI-Agent fragt nicht nur nach einer Datei, sondern nach einem Zusammenhang: Welche Module tragen einen bestimmten Ablauf? Welche Tests sichern ihn ab? Welche Entscheidung erklärt eine Architekturgrenze? Welche Quellen sollten vor einer Änderung gelesen werden?

Lint ist die Gesundheitsprüfung des Knowledge Layers. Sie sucht nach veralteten Aussagen, fehlenden Quellen, widersprüchlichen Modulbeschreibungen, nicht mehr passenden Testverweisen, offenen Begriffen und driftverdächtigen Seiten. Linting garantiert keine Richtigkeit, macht aber Pflegebedarf wiederholbar sichtbar.

2. Der praktische Nutzen für Softwareentwicklung

Der praktische Nutzen eines code-nahen LLM-Wikis entsteht nicht dadurch, dass ein Projekt mehr Dokumentation besitzt. Er entsteht, wenn vorhandenes Entwicklungswissen schneller, quellenklarer und mit weniger wiederholter Rekonstruktion nutzbar wird.

Softwareprojekte erzeugen fortlaufend Spuren: Codeänderungen, Tests, Tickets, Kommentare, Review-Diskussionen, Entscheidungen, Release Notes, Fehleranalysen, Betriebsnotizen, Workarounds und spätere Korrekturen. Diese Spuren sind nicht wertlos, nur weil sie verstreut sind. Oft liegt gerade in ihrer Verbindung der eigentliche Kontext.

Eine normale Suche kann Treffer liefern. Sie erklärt aber nicht automatisch, welche Treffer zusammengehören, welche Quelle aktueller ist, welche Aussage nur eine frühere Absicht beschreibt und welche Prüfung vor einer Änderung wirklich erforderlich ist. Das LLM-Wiki-Pattern adressiert genau diese Zwischenarbeit: Es macht aus einzelnen Quellen eine nachvollziehbare Wissensschicht, ohne deren Primärrolle aufzuheben.

Für Menschen kann ein solcher Knowledge Layer Onboarding, Reviewvorbereitung, Refactoring, Supportanalyse und Architekturarbeit unterstützen. Für KI-Agenten kann er den Einstieg in relevante Quellen verbessern und verhindern, dass jeder Arbeitsauftrag erneut bei ungeordneten Fragmenten beginnt. Das bedeutet nicht, dass ein Agent dadurch deterministisch richtig handelt. Es bedeutet nur, dass sein Kontextzustand besser kuratiert werden kann.

Der Nutzen lässt sich in drei Nutzungsweisen fassen, die bereits der erste Beitrag dieser Serie beschreibt:

  • Lesen: Entwickler, Tester oder Support öffnen Wiki-Seiten, Übersichten und Themenpfade, um sich in einem Systembereich zu orientieren.
  • Fragen: Menschen oder KI-Agenten stellen Fragen gegen die Wissensschicht und erhalten Antworten, die auf Primärquellen zurückführen.
  • Weiterpflegen: Neue Änderungen, Erkenntnisse und Korrekturen werden so eingeordnet, dass spätere Fragen nicht wieder bei null beginnen.

Der erste Anwendungsbereich liegt damit nahe am Entwicklungsprozess. Ein softwarebezogenes LLM-Wiki ist zunächst kein Endanwenderhandbuch. Es kann später bessere Produkthilfe, Supportantworten oder Administratorendokumentation ermöglichen, ersetzt diese Schichten aber nicht.

3. Einordnung gegenüber verwandten Softwareentwicklungsansätzen

Das LLM-Wiki-Pattern entsteht in der Softwareentwicklung nicht im luftleeren Raum. Es berührt mehrere etablierte oder entstehende Ansätze, die jeweils einen Teil des Problems adressieren. Für die Reihenlogik ist jedoch entscheidend, diese Ansätze nicht als lose Literaturumgebung zu behandeln, sondern entlang des LLM-Wiki-Modells einzuordnen: Welche Quellen gehören zur Belegbasis, welche Aussagen können in der Wissensschicht verdichtet werden, und welche Governance-Regeln verhindern Drift oder Überdehnung?

Architectural Knowledge Management beschreibt, dass Architekturwissen über heterogene Artefakte verteilt ist und dadurch Zugriffsprobleme, Inkonsistenzen und Drift entstehen können. Keim und Kaplan formulieren dies als Problem verstreuter Architekturinformationen; Hyun und Hurtado untersuchen Traceability zwischen Architekturentscheidungen und Softwareartefakten und beziehen dabei auch Repositories, Pull Requests, Task-Systeme und technische Dokumente ein (Keim und Kaplan, 2026; Hyun und Hurtado, 2023). Im LLM-Wiki-Modell stützen diese Arbeiten vor allem die Belegbasis: Architekturwissen liegt nicht nur in Architekturdokumenten, sondern in mehreren Quellen, deren Beziehungen gepflegt werden müssen.

Architecture Decision Records adressieren einen engeren Ausschnitt. Nygard beschreibt ADRs als kurze Dokumente, die eine Architekturentscheidung, ihren Kontext und ihre Konsequenzen festhalten (Nygard, 2011). Im LLM-Wiki-Modell gehören ADRs deshalb nicht in Konkurrenz zur Wissensschicht, sondern zu ihren maßgeblichen Quellen. Eine Wiki-Seite kann eine Entscheidung einordnen, sollte aber auf den ADR, betroffene Codebereiche, Tests, Tickets und spätere Betriebserfahrung zurückführen.

Living Documentation und Docs-as-Code betreffen stärker die Verbindung zwischen Wissensschicht und laufendem System. Adzic beschreibt Living Documentation als Dokumentation, die mit Beispielen, Spezifikation und Tests verbunden bleibt, statt getrennt vom System zu altern (Adzic, 2020). Das LLM-Wiki-Pattern erweitert diese Idee nicht durch einen weiteren Dokumentationstyp, sondern durch eine Quellen- und Pflegeordnung: Jede belastbare Aussage soll zeigen, aus welchen Primärquellen sie abgeleitet wurde, wie aktuell sie ist und wo sie geprüft werden muss.

Für KI-Assistenten gehört dieselbe Frage in den Bereich des Context Engineering. Anthropic beschreibt Context Engineering als bewusste Gestaltung des Informationszustands eines Agenten; Böckeler ordnet Kontext für Coding Agents ebenfalls als gestaltete Arbeitsgrundlage ein und betont, dass Agenten nicht immer erwartungsgemäß entscheiden, welchen Kontext sie nutzen (Anthropic, 2025; Böckeler, 2026). Im LLM-Wiki-Modell betrifft dies vor allem Query und Governance. Der Knowledge Layer kann relevante Einstiegsseiten, Quellenpfade und Grenzen anbieten, garantiert aber nicht, dass ein Agent diese Informationen vollständig oder richtig verwendet.

Die verwandten Ansätze stützen damit unterschiedliche Teile derselben Grundstruktur. Architectural Knowledge Management und Traceability erklären, warum Softwarewissen verteilt ist. ADRs liefern entscheidungsbezogene Primärquellen. Living Documentation betont die Nähe zum Systemverhalten. Context Engineering erklärt, warum kuratierter Kontext für Agenten relevant ist. Das LLM-Wiki ersetzt diese Ansätze nicht. Es ordnet sie als Quellen, Pflegeprinzipien und Nutzungswege in eine persistent gepflegte Wissensschicht ein.

4. Potenzial und Grenzen

Das Potenzial eines softwarebezogenen LLM-Wikis liegt vor allem in besserer Kontextqualität. Neue Entwickler können schneller erkennen, welche Teile eines Systems zusammengehören. Reviews können gezielter prüfen, ob eine Änderung zu früheren Entscheidungen und abgesicherten Erwartungen passt. Support, Administration und Product Owner können technische und fachliche Auswirkungen besser einordnen. KI-Agenten können mit präziserem Einstiegskontext arbeiten, statt große Teile des Repositories immer wieder neu zu interpretieren.

Ein weiterer Nutzen liegt in der Sichtbarkeit von Wissensdrift. Wenn eine Wiki-Seite einem Modul eine bestimmte Verantwortung zuschreibt, der Code aber inzwischen etwas anderes zeigt, entsteht ein prüfbarer Widerspruch. Wenn eine alte Entscheidung nicht mehr zur aktuellen Umsetzung passt, wird sie als überholt oder klärungsbedürftig sichtbar, statt im Projektgedächtnis zu verschwinden.

Diese Potenziale haben klare Grenzen. Ein LLM-Wiki ersetzt keinen Code, keine Tests, keine Reviews und keine fachliche Prüfung. Es macht Wissen nicht automatisch wahr. Es kann sogar riskant werden, wenn generierte Zusammenfassungen autoritativer wirken als die Quellen, aus denen sie abgeleitet wurden. Deshalb müssen Herkunft, Status, Unsicherheit und Aktualität in der Wissensschicht sichtbar bleiben.

Eine zweite Grenze betrifft Berechtigungen und Informationsräume. Wenn ein Wiki Wissen aus Tickets, Reviews, Supportfällen, Betriebsnotizen und Code zusammenführt, kann es Zusammenhänge sichtbar machen, die in den Ursprungssystemen bewusst getrennt waren. Ein code-naher Knowledge Layer braucht deshalb Regeln dafür, welche Informationen zusammengeführt, gespeichert und an welche Konsumenten weitergegeben werden dürfen.

Eine dritte Grenze ist Vollständigkeit. Softwareprojekte ändern sich zu schnell, als dass jede kleine Bewegung sofort in eine perfekte Wissensstruktur überführt werden könnte. Entscheidend ist nicht eine vollständige Modellierung des Systems, sondern die verlässliche Pflege relevanter Zusammenhänge, Risiken und Prüfpfade.

Das LLM-Wiki ist damit keine Wahrheitsmaschine und kein Kontrollinstrument für Agenten. Es ist eine zusätzliche Orientierungs- und Prüfschicht über lebender Software.

5. Wie lässt sich der Nutzen bewerten?

Der erste Beitrag dieser Serie endete mit der Frage, wie sich das LLM-Wiki-Pattern bewerten lässt. Für Softwareentwicklung lässt sich diese Frage nicht grundsätzlich anders beantworten, sondern nur domänenspezifisch zuspitzen. Entscheidend bleibt, ob eine gepflegte Wissensbasis Zusammenhänge schneller und zuverlässiger erschließbar macht, Entscheidungen und ihre Begründungen nachvollziehbar hält, den erneuten Aufwand zur Wissenserschließung verringert, Menschen und KI-Agenten unterstützt und in einem sinnvollen Verhältnis zum Pflegeaufwand steht (Hermanns, 2026a).

Für Softwareentwicklung werden daraus konkrete Prüffragen. Bleiben Entscheidungen und ihre Begründungen langfristig mit Code, Tests und Releases verbunden? Verringert sich der Aufwand, vor einer Änderung relevante Primärquellen zu finden? Unterstützt der Layer Entwickler, Tester, Support und KI-Agenten bei der täglichen Arbeit? Werden Drift, Unsicherheit und fehlende Quellen früher sichtbar? Karpathy, OKF und angrenzende Literatur zu Retrieval und Antwortbewertung liefern dafür keine einfache ROI-Formel, aber sinnvolle Bewertungsachsen: Antworten sollten relevanter, quellenklarer und belastbarer werden; mehrere Quellen sollten leichter zusammengeführt werden; Wissen sollte auffindbar, aktuell und nützlich bleiben (Karpathy, 2026; McVeety und Hormati, 2026a; McVeety und Hormati, 2026b; Es et al., 2023; Ming et al., 2026).

Eine Evaluation sollte deshalb nicht mit abstrakten Erfolgsversprechen beginnen, sondern mit wiederkehrenden Arbeitsfragen. Beispiele sind:

  • Welche Module sind für einen bestimmten fachlichen Ablauf verantwortlich?
  • Welche Tests sichern diesen Ablauf ab?
  • Welche Tickets oder Entscheidungen erklären, warum er so gebaut wurde?
  • Welche Konfiguration beeinflusst das Verhalten?
  • Welche bekannten Einschränkungen oder Risiken gibt es?
  • Welche Quellen sollte ein Entwickler oder Agent lesen, bevor er an diesem Bereich arbeitet?

Für einen ersten Versuch genügt eine kleine Baseline aus zehn bis fünfzehn solchen Fragen. Nach einigen Wochen ließe sich prüfen, ob Antworten häufiger mit klarer Quelle erfolgen, ob Suchschritte bis zu den maßgeblichen Primärquellen sinken, ob Unsicherheiten früher benannt werden und ob Reviews oder Supportanalysen weniger Rework wegen übersehener Quellen erzeugen.

Tokenverbrauch kann dabei ein ergänzendes Signal sein, ist aber keine ausreichende Metrik. Ein guter Knowledge Layer kann breite Suche und wiederholte Kontextrekonstruktion reduzieren. Absolute Tokenzahlen hängen jedoch von Modell, Tooling, Sessionlänge, Promptstrategie und Prüfpflichten ab. Sinnvoller ist daher die qualitätsbezogene Frage, wie viele Tokens, Turns und Suchschritte für eine quellenklare, relevante und fachlich belastbare Antwort erforderlich sind.

Ein kleiner Vergleich könnte dieselben Fragen in zwei Varianten prüfen: einmal ohne gezielten Wiki-Einstieg und einmal mit Wiki-Einstieg. Bewertet würden Suchschritte, Quellenklarheit, Antwortqualität, benannte Unsicherheiten, Rückfragen und späterer Rework. Weniger Tokens wären nur dann ein Erfolg, wenn die Antwortqualität mindestens gleich bleibt.

Der Nutzen eines code-nahen LLM-Wikis ist damit nicht theoretisch gegeben. Er muss sich daran bewähren, ob typische Entwicklungsfragen mit klareren Quellen, weniger Rekonstruktion, früheren Drift-Signalen und vertretbarem Pflegeaufwand beantwortet werden können.

6. Fazit und Ausblick

Das LLM-Wiki-Pattern lässt sich auf Softwareentwicklung übertragen, ohne seinen Kern zu verändern. Wie in der Pattern-Einführung bleiben Rohquellen erhalten, eine synthetisierte Wissensschicht verdichtet Zusammenhänge, und Governance regelt Quellenführung, Aktualität, Unsicherheit und Pflege. Der Unterschied liegt in der Domäne: Die maßgeblichen Quellen sind Code, Tests, Tickets, Reviews, Releases, Konfiguration, Entscheidungen und Betriebswissen.

Ein code-naher Knowledge Layer kann dadurch sichtbar machen, welche Primärquellen für ein Systemverständnis relevant sind und wie belastbar dieses Verständnis ist. Er ersetzt nicht die technische Realität, sondern macht Wege zu ihr kürzer und prüfbarer. Gerade für langlebige Softwareprojekte und KI-gestützte Entwicklungsarbeit ist dies ein relevanter Beitrag, weil Kontext sonst bei jeder anspruchsvolleren Aufgabe erneut zusammengesucht werden muss.

Gleichzeitig bleibt der Ansatz begrenzt. Ein LLM-Wiki garantiert keine Wahrheit, keine vollständige Aktualität und kein deterministisches Agentenverhalten. Sein Wert hängt von Quellenqualität, Governance, regelmäßiger Prüfung und einem realistischen Zuschnitt ab.

Damit ist die Bewegung der ersten beiden Artikel klar: Der erste Beitrag dieser Serie erklärt das Pattern. Dieser Artikel überträgt es auf Softwareentwicklung und beschreibt, woran sein Nutzen erkennbar werden müsste. Der nächste Beitrag kann darauf aufbauen und untersuchen, wie ein solcher Knowledge Layer konkret, klein und überprüfbar erprobt werden kann.

Quellenverzeichnis

Primärartikel dieser Reihe

Externe Primärquellen

Ergänzende Fachquellen

Category: AI, Data & Automation

Leave a Reply

Your email address will not be published. Required fields are marked *