torben/chemenu

Fork 0

Files

T

torben 18ae28f918

CI / verify (push) Failing after 32s

Details

Release / release (push) Successful in 38s

Details

Chemenu 2.1.0 - deterministischer Wissenskompiler

Chemenu kompiliert Rohnotizen zu einem verlinkten, quellengebundenen Wiki:
raw/ -> types/ + tools/ -> kb/ -> reports/. Was mechanisch ist, macht
tools/wikitool; was Urteil braucht, macht ein Agent unter Contracts, deren
Grenzen in Code durchgesetzt sind statt im Prompt.

Dieser Commit ist der Startpunkt der oeffentlichen Historie. Die vorherige
Entwicklung fand in einer privaten Instanz statt und ist nicht Teil dieses
Repositorys; ihre Erzaehlung steht vollstaendig in CHANGES.md, das mit 44
Eintraegen von 0.1.0 bis 2.1.0 erhalten geblieben ist.

Der mitgelieferte Korpus ist ein Testbett und eine Demo: 170 Seiten ueber den
Stack selbst - Gates, Lint, Versionierung, Suche, das Wiki-Muster. Er
dokumentiert das Werkzeug mit den eigenen Mitteln des Werkzeugs.

Lizenz: AGPL-3.0 fuer den Stack (tools/, types/), CC-BY-4.0 fuer die Inhalte.
Die Grenze zwischen beiden ist der Dateiplan, den dist export berechnet -
siehe NOTICE.

2026-09-01 16:26:14 +02:00

5.6 KiB

Raw Blame History

type, concept_type, tags, created, modified, related, sources, confidence, confidence_base, provenance, summary

type

concept_type

Knowledge Graph

Typ: Architektur (Strukturierte Wissensrepräsentation)

Definition

Ein Knowledge Graph ist eine typisierte, strukturierte Ebene über Wiki-Seiten, die Entities und ihre Beziehungen darstellt. Während das ursprüngliche LLM Wiki Seiten mit Wikilinks verwendet (was funktioniert), erfasst das Hinzufügen einer Knowledge-Graph-Ebene eine reichere Struktur, die bessere Abfrage und Entdeckung ermöglicht.

Dieses Konzept wird in LLM Wiki Pattern v2 als Verbesserung der ursprünglichen flachen Seitenstruktur eingeführt.

Kernpunkte

Was das Original richtig macht

Seiten mit Wikilinks sind:

Menschenlesbar
Einfach zu erstellen und zu pflegen
Gut für Narrativ-Informationen
Funktionieren gut für kleine bis mittlere Wikis

Was fehlt

Wikilinks allein erfassen nicht:

Entity-Typen (person, project, concept usw.)
Beziehungstypen (uses, depends on, contradicts usw.)
Beziehungssemantik (Richtung, Stärke, Vertrauen)
Strukturelle Verbindungen, die Keyword-Suche vermisst

Die Knowledge-Graph-Lösung

Der Graph ergänzt (ersetzt nicht) Wiki-Seiten durch:

1. Entity Extraction Bei der Aufnahme einer Quelle strukturierte Entities extrahieren:

Typen: People, projects, libraries, concepts, files, decisions, systems, tools, technologies
Attribute: Für jede Entity typspezifische Metadaten speichern
Beispiele: "React" (type: library), "Auth migration" (type: project), "Sarah" (type: person)

2. Typed Relationships Nicht alle Verbindungen sind gleich. Typisierte Beziehungen mit semantischem Gewicht verwenden:

Beziehung	Gewicht	Beschreibung
depends on	Hoch	Funktionale Abhängigkeit
uses	Mittel	Tool/Library-Nutzung
implements	Hoch	Schnittstellen-/Spec-Implementierung
extends	Mittel	Vererbung/Erweiterung
replaces	Mittel	Austauschbeziehung
conflicts with	Hoch	Inkompatibilität
requires	Hoch	Voraussetzung
produces	Mittel	Ausgabe/Artefakt
consumes	Mittel	Eingabe/Ressource
owns	Mittel	Verantwortung
maintains	Mittel	Wartungsverantwortung
causes	Hoch	Kausalität
fixed	Hoch	Behebung
supersedes	Hoch	Versionskontrolle für Wissen
contradicts	Hoch	Gegensätzliche Aussagen
relates to	Niedrig	Allgemeine Beziehung

3. Graph-Traversal für Abfragen Statt nur Keyword-Suche kann das LLM:

Bei einem Entity-Knoten beginnen (z. B. Redis)
Durch Beziehungskanten nach außen gehen
Alles Nachgelagerte finden (z. B. alle Services, die von Redis abhängen)
Verbindungen erfassen, die Keyword-Suche vermisst

Beispiel-Abfrage: „Wie wirkt sich ein Redis-Upgrade aus?"

Bei Redis-Knoten beginnen
„depends on"-Kanten nach außen folgen
Finde: Service A, Service B, Service C
„uses"-Kanten von diesen Services folgen
Finde: Deployment X, Deployment Y
Ergebnis: Vollständige Auswirkungsanalyse

Implementierung

Basierend auf Agent Memory und iii Engine:

Entities extrahieren bei Quellaufnahme
Im Graph-Datenbank oder strukturiertem Format speichern
Bidirektionale Links pflegen zwischen Graph-Knoten und Wiki-Seiten
Graph-Traversal aktivieren für komplexe Abfragen
Graph visualisieren für menschliches Verständnis

Graph vs. Seiten

Aspekt	Seiten	Graph
Zweck	Lesen, Narration	Navigation, Entdeckung
Stärke	Menschenlesbar, reichhaltiger Kontext	Maschinenlesbar, präzise Beziehungen
Anwendungsfall	Ein Thema verstehen	Verbindungen finden, Auswirkungsanalyse
Wartung	LLM schreibt Prosa	LLM extrahiert Struktur

Best Practice: Beide verwenden. Seiten zum Lesen, Graph zur Navigation und Entdeckung.

Vorteile

Bessere Abfragen: Verbindungen finden, die Keyword-Suche vermisst
Auswirkungsanalyse: Abhängigkeiten und Beziehungen nachverfolgen
Entdeckung: Verwandte Entities automatisch anzeigen
Präzision: Typisierte Beziehungen sind aussagekräftiger als untypierte Links
Skalierbarkeit: Graph-Struktur ermöglicht effizientes Traversal

Wann zu verwenden

Wikis mit >100 Seiten (wo Keyword-Suche zu fehlschlagen beginnt)
Domänen mit komplexen Beziehungen (Softwaresysteme, Organisationen)
Situationen, die Auswirkungsanalyse oder Abhängigkeitsverfolgung erfordern
Multi-Hop-Abfragen (finde X, das sich auf Y bezieht, das sich auf Z bezieht)

Wann NICHT zu verwenden

Kleine Wikis (<100 Seiten) - Wikilinks könnten ausreichend sein
Einfache, lineare Wissensbereiche
Situationen, in denen der Overhead nicht gerechtfertigt ist

Siehe auch

Hybrid Search (nutzt Graph-Traversal als einen Stream)
Event-Driven Automation (für automatische Graph-Updates)
Supersession (als Graph-Beziehung verfolgt)

5.6 KiB Raw Blame History