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.0 KiB

Raw Blame History

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

type

concept_type

Hybrid Search

Typ: Architecture (Multi-Modal-Suchsystem)

Definition

Hybrid Search kombiniert drei komplementäre Suchansätze, um skalierbare und genaue Wissensbeschaffung in Wikis zu ermöglichen, die ~100-200 Seiten übersteigen. Dies adressiert die Einschränkung des ursprünglichen Musters, das sich ausschließlich auf index.md für die Entdeckung verlässt.

Kernpunkte

Das Problem

Der ursprüngliche index.md-Katalog funktioniert bis zu ~100-200 Seiten. Darüber hinaus:

Der Index selbst wird zu lang, um vom LLM in einem Durchgang gelesen zu werden
Schlüsselwortabgleich vermisst semantische Ähnlichkeit
Flache Suche kann strukturelle Beziehungen nicht erfassen
Unimodale Suche hat Blindstellen

Die Lösung: Drei-Stream-Fusion

1. BM25 (Schlüsselwortabgleich)

Traditionelle Informationsbeschaffung mit Stammformreduktion und Synonymerweiterung
Stärken: Findet genaue Begriffe, schnell, gut verstanden
Schwächen: Vermisst semantische Ähnlichkeit, erfordert genaue Begriffsabgleiche
Anwendungsfall: "Alle Seiten über Docker finden"

2. Vector Search (Semantische Ähnlichkeit)

Nutzt Embeddings, um semantisch ähnliche Inhalte zu finden
Stärken: Findet verwandte Konzepte, auch ohne genaue Begriffsabgleiche
Schwächen: Kann präzise technische Begriffe verpassen, rechentechnisch teuer
Anwendungsfall: "Informationen über Container-Plattformen finden" (passt Docker, Podman, etc.)

3. Graph Traversal (Strukturelle Verbindungen)

Durchläuft den Knowledge Graph durch typisierte Beziehungen
Stärken: Findet strukturelle Verbindungen, die Schlüsselwort- und Vector-Suche verfehlen
Schwächen: Erfordert gut gepflegten Graph, findet nur verbundene Entitäten
Anwendungsfall: "Was ist die Auswirkung eines Redis-Upgrades?" (findet alle abhängigen Services)

Fusion mit Reciprocal Rank Fusion (RRF)

Anstatt einen Ansatz zu wählen, alle drei mit RRF fusionieren:

Alle drei Suchen parallel ausführen
Jede gibt eine rangierte Liste von Ergebnissen zurück
RRF kombiniert die Rankings mit gegenseitigen Rang-Scores
Ergebnis: Bessere Gesamtrangierung als bei einem einzelnen Ansatz

Warum RRF?

Einfach und effektiv
Keine Notwendigkeit, Gewichte zwischen Modi zu tunen
Robust gegen Unterschiede in der Ergebnisqualität
Funktioniert auch, wenn ein Modus schlecht abschneidet

Implementierung

Architektur

Abfrage: "Wie funktioniert das Auth-System?"
       │
       ├── BM25-Suche → [Seiten mit "Auth", "Authentication", "Login"]
       │
       ├── Vector Search → [semantisch mit Authentication verbundene Seiten]
       │
       └── Graph Traversal → [Seiten, die mit Auth-Entitäten im Graph verbunden sind]
               │
               └── Reciprocal Rank Fusion → Kombinierte, rangierte Ergebnisse

Wann wechseln

Wiki-Größe	Primärer Suchmechanismus
< 100 Seiten	`index.md` (manuell)
100-200 Seiten	`index.md` + grundlegende Suche
200-1000 Seiten	Hybrid-Suche (BM25 + Vector)
1000+ Seiten	Hybrid-Suche (BM25 + Vector + Graph)

Empfehlung: index.md als für Menschen lesbaren Katalog auch mit Hybrid-Suche bewahren. Es dient verschiedenen Zwecken:

index.md: Menschliche Navigation, Überblick
Hybrid-Suche: LLM-Abfragelösung

Vorteile

Skalierbarkeit: Funktioniert von 100 bis 10.000+ Seiten
Genauigkeit: Jeder Modus erfasst, was andere vermissen
Robustheit: Kein Single Point of Failure
Flexibilität: Passt sich verschiedenen Abfragetypen an
Zukunftssicher: Kann weitere Modi hinzufügen (z.B. Zeitsuche)

Wann zu verwenden

Wikis, von denen erwartet wird, dass sie über 200 Seiten hinauswachsen
Bereiche mit vielfältigen Abfragetypen
Situationen, die hohen Recall erfordern
Multi-modale Wissensdatenbanken

Wann NICHT zu verwenden

Kleine Wikis (<100 Seiten) - index.md ist ausreichend
Einfache, gleichmäßige Inhalte
Situationen, in denen die Implementierungskomplexität nicht gerechtfertigt ist

Siehe auch

Event-Driven Automation (für automatisierte Indizierung)
Scalable Search (verwandtes Concept)

5.0 KiB Raw Blame History