kb/concepts/ bekommt Areas: layout: fuer concept, Area-Titel aus jedem Type-Spec, Schwellen-Empfehlung im lint (schliesst #59)
Files changed: - CHANGES.md - README.md - VERSION - kb/concepts/Ambient Environment Dependency.md - kb/concepts/Anti-Cramming Heuristic.md - kb/concepts/Audit Trail.md - kb/concepts/BM25.md - kb/concepts/Bulk Operations.md - kb/concepts/CI Integration.md - kb/concepts/COLLECTION.md - kb/concepts/CPPC.md - kb/concepts/Checkpoint Audit.md - kb/concepts/Claude Code Auto Mode.md - kb/concepts/Command Round-Trip Integrity.md - kb/concepts/Confidence Scoring.md - kb/concepts/Consolidation Tiers.md - kb/concepts/Content Quality Control.md - kb/concepts/Context Isolation.md - kb/concepts/Contradiction Resolution.md - kb/concepts/Cross-platform Agent Skills.md - kb/concepts/Crystallization.md - kb/concepts/Delete Rather Than Anonymize.md - kb/concepts/Denylist over Allowlist.md - kb/concepts/Detect-Repair Asymmetry.md - kb/concepts/Diff-Reviewable Agent Edits.md - kb/concepts/Dual Licensing by File Plan.md - kb/concepts/Entity Extraction.md - kb/concepts/Episodic Memory.md - kb/concepts/Event-Driven Automation.md - kb/concepts/Filter on Ingest.md - kb/concepts/Forgetting.md - kb/concepts/Graph Traversal.md - kb/concepts/Green Suite Blind Spot.md - kb/concepts/Hooks.md - kb/concepts/Hybrid Search.md - kb/concepts/INDEX.md - kb/concepts/Implementation Spectrum.md - kb/concepts/Index Scaling.md - kb/concepts/Issue Label Scheme.md - kb/concepts/Iteration and Cost Limits.md - kb/concepts/KB Migration.md - kb/concepts/KB Stack Versioning.md - kb/concepts/Knowledge Compounding.md - kb/concepts/Knowledge Graph.md - kb/concepts/LLM Wiki Pattern.md - kb/concepts/Lint Workflow.md - kb/concepts/MCP-Leseserver.md - kb/concepts/Mass-Update Gate.md - kb/concepts/Memory Lifecycle.md - kb/concepts/Mesh Sync.md - kb/concepts/Modbus.md - kb/concepts/Multi-Agent Collaboration.md - kb/concepts/Naming Convention Conflict.md - kb/concepts/OKF Compatibility.md - kb/concepts/Optional Instance Context File.md - kb/concepts/Personalization Plane.md - kb/concepts/Privacy and Governance.md - kb/concepts/Procedural Memory.md - kb/concepts/Publish-Remote Gate.md - kb/concepts/Quality Scoring.md - kb/concepts/Quality and Self-Correction.md - kb/concepts/RAG.md - kb/concepts/Reciprocal Rank Fusion.md - kb/concepts/SSD TRIM.md - kb/concepts/Scale Ceiling.md - kb/concepts/Self-Healing.md - kb/concepts/Semantic Lint Automation.md - kb/concepts/Semantic Memory.md - kb/concepts/Session Orientation.md - kb/concepts/Shared vs Private.md - kb/concepts/Split Merge Reclassify.md - kb/concepts/Split Threshold.md - kb/concepts/Structural Enforcement over Documented Rule.md - kb/concepts/Stub Threshold.md - kb/concepts/Supersession.md - kb/concepts/Three-Layer Architecture.md - kb/concepts/Token Economics.md - kb/concepts/Typed Relationships.md - kb/concepts/User Management.md - kb/concepts/Vector Search.md - kb/concepts/Work Coordination.md - kb/concepts/Workflow Extraction.md - kb/concepts/Workflow Orchestration.md - kb/concepts/Working Memory.md - kb/concepts/Write-Once Frontmatter Fields.md - kb/concepts/architectures/Consolidation Tiers.md - kb/concepts/architectures/Context Isolation.md - kb/concepts/architectures/Cross-platform Agent Skills.md - kb/concepts/architectures/Episodic Memory.md - kb/concepts/architectures/Hybrid Search.md - kb/concepts/architectures/Implementation Spectrum.md - kb/concepts/architectures/Knowledge Graph.md - kb/concepts/architectures/LLM Wiki Pattern.md - kb/concepts/architectures/MCP-Leseserver.md - kb/concepts/architectures/Memory Lifecycle.md - kb/concepts/architectures/OKF Compatibility.md - kb/concepts/architectures/Optional Instance Context File.md - kb/concepts/architectures/Personalization Plane.md - kb/concepts/architectures/Procedural Memory.md - kb/concepts/architectures/RAG.md - kb/concepts/architectures/Scale Ceiling.md - kb/concepts/architectures/Semantic Memory.md - kb/concepts/architectures/Three-Layer Architecture.md - kb/concepts/architectures/Token Economics.md - kb/concepts/architectures/Working Memory.md - kb/concepts/decisions/Delete Rather Than Anonymize.md - kb/concepts/decisions/Denylist over Allowlist.md - kb/concepts/decisions/Diff-Reviewable Agent Edits.md - kb/concepts/decisions/Dual Licensing by File Plan.md - kb/concepts/decisions/Issue Label Scheme.md - kb/concepts/decisions/KB Stack Versioning.md - kb/concepts/decisions/Structural Enforcement over Documented Rule.md - kb/concepts/patterns/Audit Trail.md - kb/concepts/patterns/BM25.md - kb/concepts/patterns/Command Round-Trip Integrity.md - kb/concepts/patterns/Confidence Scoring.md - kb/concepts/patterns/Contradiction Resolution.md - kb/concepts/patterns/Entity Extraction.md - kb/concepts/patterns/Filter on Ingest.md - kb/concepts/patterns/Forgetting.md - kb/concepts/patterns/Graph Traversal.md - kb/concepts/patterns/Mesh Sync.md - kb/concepts/patterns/Quality Scoring.md - kb/concepts/patterns/Reciprocal Rank Fusion.md - kb/concepts/patterns/Self-Healing.md - kb/concepts/patterns/Shared vs Private.md - kb/concepts/patterns/Typed Relationships.md - kb/concepts/patterns/Vector Search.md - kb/concepts/patterns/Work Coordination.md - kb/concepts/problems/Ambient Environment Dependency.md - kb/concepts/problems/Detect-Repair Asymmetry.md - kb/concepts/problems/Green Suite Blind Spot.md - kb/concepts/problems/Naming Convention Conflict.md - kb/concepts/problems/Write-Once Frontmatter Fields.md - kb/concepts/protocols/CPPC.md - kb/concepts/protocols/Modbus.md - kb/concepts/protocols/SSD TRIM.md - kb/concepts/workflows/Anti-Cramming Heuristic.md - kb/concepts/workflows/Bulk Operations.md - kb/concepts/workflows/CI Integration.md - kb/concepts/workflows/Checkpoint Audit.md - kb/concepts/workflows/Claude Code Auto Mode.md - kb/concepts/workflows/Content Quality Control.md - kb/concepts/workflows/Crystallization.md - kb/concepts/workflows/Event-Driven Automation.md - kb/concepts/workflows/Hooks.md - kb/concepts/workflows/Index Scaling.md - kb/concepts/workflows/Iteration and Cost Limits.md - kb/concepts/workflows/KB Migration.md - kb/concepts/workflows/Knowledge Compounding.md - kb/concepts/workflows/Lint Workflow.md - kb/concepts/workflows/Mass-Update Gate.md - kb/concepts/workflows/Multi-Agent Collaboration.md - kb/concepts/workflows/Privacy and Governance.md - kb/concepts/workflows/Publish-Remote Gate.md - kb/concepts/workflows/Quality and Self-Correction.md - kb/concepts/workflows/Semantic Lint Automation.md - kb/concepts/workflows/Session Orientation.md - kb/concepts/workflows/Split Merge Reclassify.md - kb/concepts/workflows/Split Threshold.md - kb/concepts/workflows/Stub Threshold.md - kb/concepts/workflows/Supersession.md - kb/concepts/workflows/User Management.md - kb/concepts/workflows/Workflow Extraction.md - kb/concepts/workflows/Workflow Orchestration.md - kb/index.md - kb/log.md - tools/CONTRACT.md - tools/README.md - tools/chemenu/catalog.py - tools/chemenu/commands/index_build.py - tools/chemenu/lint_core.py - tools/chemenu/tests/conftest.py - tools/chemenu/tests/test_cite_cmd.py - tools/chemenu/tests/test_git_publish.py - tools/chemenu/tests/test_index_build.py - tools/chemenu/tests/test_lint.py - tools/chemenu/tests/test_new_page.py - tools/chemenu/tests/test_provenance.py - tools/chemenu/tests/test_type_resolver.py - tools/chemenu/tests/test_xref.py - types/concept.md - types/type-spec.md
This commit is contained in:
@@ -0,0 +1,216 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [memory, tiers, consolidation, knowledge-management]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- part-of: Memory Lifecycle
|
||||
- composition: Working Memory
|
||||
- composition: Episodic Memory
|
||||
- composition: Semantic Memory
|
||||
- composition: Procedural Memory
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Hierarchische Speicherarchitektur, die Informationen durch zunehmend verdichtete Schichten vom Working Memory bis zum Semantic und Procedural Memory befördert.
|
||||
---
|
||||
# Consolidation Tiers
|
||||
|
||||
**Typ:** Architektur (Tiered Knowledge Consolidation)
|
||||
|
||||
## Definition
|
||||
|
||||
Consolidation Tiers ist eine **hierarchische Speicherarchitektur**, die Informationen durch progressiv stärker komprimierte, bestätigte und langfristig verfügbare Schichten fördert. Dies adressiert das Problem, alle Beobachtungen gleich zu behandeln, und ermöglicht dem Wiki, zwischen Tentativbeobachtungen und gut etablierten Fakten zu unterscheiden.
|
||||
|
||||
Dies ist eine Kernkomponente des [[Memory Lifecycle]]-Managements, inspiriert durch kognitive Psychologie und implementiert in [[Agent Memory]].
|
||||
|
||||
## Tier-Struktur
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ PROCEDURAL MEMORY │
|
||||
│ Workflows, patterns, best practices, automated procedures │
|
||||
│ Longest-lived, highest confidence, most compressed │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Promote (extract patterns)
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ SEMANTIC MEMORY │
|
||||
│ Cross-session facts, consolidated from multiple episodes │
|
||||
│ Long-lived, high confidence, moderately compressed │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Promote (consolidate facts)
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ EPISODIC MEMORY │
|
||||
│ Session summaries, compressed from raw observations │
|
||||
│ Medium-lived, medium confidence, lightly compressed │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Promote (summarize session)
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ WORKING MEMORY │
|
||||
│ Recent observations, not yet processed │
|
||||
│ Short-lived, low confidence, uncompressed │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Ingest (raw source)
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ RAW SOURCES │
|
||||
│ Immutable source documents (articles, notes, data) │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Tier-Details
|
||||
|
||||
### Working Memory
|
||||
|
||||
**Zweck:** Aktuelle, unverarbeitete Beobachtungen halten
|
||||
|
||||
**Charakteristiken:**
|
||||
- **Lebensdauer:** Tage bis Wochen (kurzlebig)
|
||||
- **Konfidenz:** Niedrig (vorläufig, unbestätigt)
|
||||
- **Komprimierung:** Keine (rohe Beobachtungen)
|
||||
- **Zugriff:** Häufig zugegriffen während aktiver Arbeit
|
||||
- **Förderungstrigger:** Sitzungsabschluss, manuelle Überprüfung
|
||||
|
||||
**Inhalte:**
|
||||
- Aktuelle Quellenausschnitte
|
||||
- Vorläufige Erkenntnisse
|
||||
- Laufende Analysen
|
||||
- Unbestätigte Aussagen
|
||||
|
||||
**Beispiel:** "Beobachtet, dass das API-Ratelimit möglicherweise 100 req/min beträgt"
|
||||
|
||||
### Episodic Memory
|
||||
|
||||
**Zweck:** Sitzungsbezogene Zusammenfassungen und Erkenntnisse speichern
|
||||
|
||||
**Charakteristiken:**
|
||||
- **Lebensdauer:** Wochen bis Monate
|
||||
- **Konfidenz:** Mittel (in der Sitzung verifiziert)
|
||||
- **Komprimierung:** Leicht (aus Working Memory zusammengefasst)
|
||||
- **Zugriff:** Sitzungsbasierter Abruf
|
||||
- **Förderungstrigger:** Sitzungsübergreifende Bestätigung
|
||||
|
||||
**Inhalte:**
|
||||
- Sitzungszusammenfassungen
|
||||
- Haupterkenntnisse aus einzelnen Quellen
|
||||
- Sitzungsspezifischer Kontext
|
||||
- Verifizierte Fakten innerhalb der Sitzung
|
||||
|
||||
**Beispiel:** "Sitzung 2026-07-20: API-Ratelimit für Endpoint X bestätigt ist 100 req/min"
|
||||
|
||||
### Semantic Memory
|
||||
|
||||
**Zweck:** Sitzungsübergreifende allgemeine Fakten beibehalten
|
||||
|
||||
**Charakteristiken:**
|
||||
- **Lebensdauer:** Monate bis Jahre
|
||||
- **Konfidenz:** Hoch (sitzungsübergreifend bestätigt)
|
||||
- **Komprimierung:** Moderat (aus episodischem Speicher destilliert)
|
||||
- **Zugriff:** Allgemeiner Abfrageabruf
|
||||
- **Förderungstrigger:** Mustererkennung, wiederholte Beobachtung
|
||||
|
||||
**Inhalte:**
|
||||
- Etablierte Fakten
|
||||
- Querverweisenes Wissen
|
||||
- Domänenspezifische Informationen
|
||||
- Gut verifizierte Aussagen
|
||||
|
||||
**Beispiel:** "Das API-Ratelimit beträgt 100 req/min für Standard-Endpoints, 500 req/min für Premium"
|
||||
|
||||
### Procedural Memory
|
||||
|
||||
**Zweck:** Arbeitsabläufe, Muster und Best Practices erfassen
|
||||
|
||||
**Charakteristiken:**
|
||||
- **Lebensdauer:** Jahre (am längsten verfügbar)
|
||||
- **Konfidenz:** Sehr hoch (durch Wiederholung bewiesen)
|
||||
- **Komprimierung:** Hoch (abstrahierte Muster)
|
||||
- **Zugriff:** Arbeitsablauf- und Mustenabruf
|
||||
- **Förderungstrigger:** Mustererkennung aus semantischem Speicher
|
||||
|
||||
**Inhalte:**
|
||||
- Arbeitsabläufe und Verfahren
|
||||
- Entwurfsmuster
|
||||
- Best Practices
|
||||
- Automatisierte Verfahren
|
||||
- Bewährte Lösungen für wiederkehrende Probleme
|
||||
|
||||
**Beispiel:** "Beim Treffen von Ratelimits: 1) Endpoint-Tier prüfen, 2) Backoff implementieren, 3) Antworten cachen, 4) Kontingent-Erhöhung anfordern"
|
||||
|
||||
## Förderungskriterien
|
||||
|
||||
Informationen werden von einer Ebene zur nächsten befördert, wenn:
|
||||
|
||||
| Von → Zu | Kriterien |
|
||||
|-----------|----------|
|
||||
| Working → Episodic | Sitzung abgeschlossen, Beobachtungen zusammengefasst |
|
||||
| Episodic → Semantic | Fakt beobachtet in ≥2 unabhängigen Sitzungen, keine Widersprüche |
|
||||
| Semantic → Procedural | Muster erkannt über ≥5 Instanzen, bewiesenerweise wirksam |
|
||||
|
||||
## Aufbewahrung und Verfall
|
||||
|
||||
Jede Ebene hat unterschiedliche **Aufbewahrungsrichtlinien**:
|
||||
|
||||
| Ebene | Aufbewahrung | Verfallsrate | Archiv nach |
|
||||
|------|-----------|------------|---------------|
|
||||
| Working Memory | Aggressiv | Schnell | 30 Tage |
|
||||
| Episodic Memory | Moderat | Mittel | 90 Tage |
|
||||
| Semantic Memory | Konservativ | Langsam | 1 Jahr |
|
||||
| Procedural Memory | Dauerhaft | Sehr langsam | Nie |
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Effizienz:** Höhere Ebenen ermöglichen schnellere und zuverlässigere Abfragen
|
||||
- **Klarheit:** Unterscheidet zwischen vorläufigem und bewiesenem Wissen
|
||||
- **Skalierbarkeit:** Komprimierung reduziert Speicher- und Suchaufwand
|
||||
- **Lernen:** Ermöglicht Mustererkennung und Arbeitsablauf-Automatisierung
|
||||
- **Anpassungsfähigkeit:** Ebenenstruktur ermöglicht Wissensentwicklung
|
||||
|
||||
## Implementierung
|
||||
|
||||
Basierend auf [[Agent Memory]]-Erfahrung:
|
||||
|
||||
1. **Automatische Förderung:** [[Event-Driven Automation]] verwenden, um Förderungen beim Sitzungsabschluss auszulösen
|
||||
2. **Konfidenz-Verfolgung:** Mit [[Confidence Scoring]] für jede Ebene integrieren
|
||||
3. **Komprimierungsalgorithmen:** Inhalt automatisch zusammenfassen und destillieren beim Fördern
|
||||
4. **Querverweis-Verwaltung:** Sicherstellen, dass Links über Ebenen funktionieren
|
||||
5. **Suchoptimierung:** Höhere Ebenen in Suchergebnissen priorisieren
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Jedes Wiki, das diverse Arten von Wissen verarbeiten soll
|
||||
- Domänen mit flüchtigen und permanenten Informationen
|
||||
- Situationen, in denen Wissensreife wichtig ist
|
||||
- Sitzungsübergreifende Forschungs- oder Entwicklungsprojekte
|
||||
|
||||
## Verwandte Konzepte
|
||||
|
||||
- [[Agent Memory]] - Produktive Implementierung
|
||||
- [[Forgetting]] - Ergänzender Aufbewahrungsmechanismus
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Confidence Scoring]] (für ebenenspezifische Konfidenz)
|
||||
- [[Event-Driven Automation]] (für Förderungstrigger)
|
||||
- [[Knowledge Graph]] (für ebenenübergreifende Beziehungen)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Memory Lifecycle]]
|
||||
- **composition:** [[Working Memory]]
|
||||
- **composition:** [[Episodic Memory]]
|
||||
- **composition:** [[Semantic Memory]]
|
||||
- **composition:** [[Procedural Memory]]
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [context, isolation, efficiency]
|
||||
created: 2026-08-04
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- see-also: Token Economics
|
||||
- see-also: Scale Ceiling
|
||||
- see-also: Workflow Extraction
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Grundsatz, für jede Aufgabe nur den jeweils benötigten Kontext zu laden
|
||||
---
|
||||
# Context Isolation
|
||||
|
||||
**Typ:** Architektur
|
||||
|
||||
## Definition
|
||||
|
||||
Context Isolation ist das Prinzip, nur die relevanten Anweisungen und Kontexte für jede spezifische Aufgabe zu laden, anstatt einen gesamten monolithischen Anweisungssatz unabhängig von der ausgeführten Aufgabe zu laden[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Task-spezifisches Laden**: Nur das für die aktuelle Aufgabe relevante Skill wird in den Kontext geladen
|
||||
- **Reduzierte Token-Nutzung**: Signifikant niedrigere Token-Kosten im Vergleich zu monolithischen Ansätzen[^s-copilot-skill-restructure-instructions]
|
||||
- **Verbesserte Qualität**: LLMs können sich auf die spezifische Aufgabe konzentrieren, ohne von irrelevanten Anweisungen abgelenkt zu werden
|
||||
- **Gemeinsames Verzeichnismuster**: Erreicht durch `.agents/skills/`-Verzeichnis mit Tool-spezifischer Verdrahtung[^s-copilot-skill-restructure-instructions]
|
||||
|
||||
## Beispiele
|
||||
|
||||
- Nur `wiki-ingest` Skill beim Ausführen einer Ingest-Operation laden
|
||||
- Nur `wiki-query` Skill beim Beantworten einer Abfrage laden
|
||||
- Der RTFM/Abruf-Schicht-Ansatz, der zuerst Metadaten bereitstellt und nur bei Bedarf erweitert[^s-copilot-skill-restructure-instructions]
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Context Isolation verwenden, wenn:
|
||||
- der Anweisungssatz mehrere unterschiedliche Arbeitsabläufe enthält
|
||||
- Token-Nutzung zu optimieren und Kosten zu senken ist
|
||||
- Aufgaben mit minimaler Überschneidung sauber getrennt werden können
|
||||
- mehrere LLM-Tools mit unterschiedlichen Kontextfenstern angewendet werden
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
Context Isolation ist weniger wirksam, wenn:
|
||||
- Aufgaben stark voneinander abhängig sind und erfordern ein Verständnis mehrerer Arbeitsabläufe gleichzeitig
|
||||
- Der Overhead für die Verwaltung separater Kontexte die Vorteile überwiegt
|
||||
- Ihr Anweisungssatz klein genug ist, dass das Laden von allem kein Problem darstellt
|
||||
|
||||
## Verwandte Konzepte
|
||||
|
||||
- [[Cross-platform Agent Skills]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Token Economics]]
|
||||
- **see-also:** [[Scale Ceiling]]
|
||||
- **see-also:** [[Workflow Extraction]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [skills, agents, cross-platform]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related:
|
||||
- rests-on: Context Isolation
|
||||
- rests-on: Token Economics
|
||||
- see-also: Scale Ceiling
|
||||
- see-also: Workflow Extraction
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Architektur fuer Agent-Skills, die ueber mehrere LLM-Werkzeuge hinweg funktionieren; in Chemenu selbst am 2026-08-04 umgesetzt und ueberprueft
|
||||
---
|
||||
# Cross-platform Agent Skills
|
||||
|
||||
**Typ:** Architektur
|
||||
|
||||
## Definition
|
||||
|
||||
Cross-platform Agent Skills ist ein Architekturmuster, bei dem diskrete, aufrufbare Agent-Anweisungen einmal geschrieben und mehreren LLM-Tools (wie GitHub Copilot, Claude Code, Codex CLI und Mistral Vibe) über eine gemeinsame Verzeichnisstruktur und Tool-spezifische Verdrahtung zur Verfügung gestellt werden[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Einzelne Quelle der Wahrheit**: Skills werden einmal an einem gemeinsamen Ort (`.agents/skills/`) definiert und von allen Tools referenziert
|
||||
- **Tool-spezifische Verdrahtung**: Jedes LLM-Tool hat seine eigene Art, Skills zu entdecken, die über Symlinks oder Konfiguration einheitlich gestaltet werden können
|
||||
- **Context Isolation**: Jeder Skill wird nur bei Aufruf geladen, was die Token-Nutzung im Vergleich zu monolithischen Anweisungsdateien reduziert
|
||||
- **Lossless Extraction**: Workflow-Logik wird wörtlich aus monolithischen Dateien in diskrete Skills extrahiert, ohne die Substanz zu ändern
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[wiki-skills]] - Sechs eigenständige Claude Code Skills, die das Muster demonstrieren
|
||||
- [[wiki-skills-vanillaflava]] - Referenzimplementierung für Cross-Platform-Verteilung
|
||||
- [[llm-wiki-skills]] - Eine weitere Cross-Platform-Implementierung
|
||||
- [[Chemenu]] - **Implementiertes Muster am 2026-08-04**: 5 Skills
|
||||
(`wiki-ingest`/`wiki-query`/`wiki-lint`/`wiki-manage`/`wiki-status`) unter `.agents/skills/`,
|
||||
gespiegelt zu `.claude/skills/` via `tools/wikitool skills sync`[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]
|
||||
|
||||
## Überprüfte Tool-Unterstützung (2026-08-04)
|
||||
|
||||
Direkte Bestätigung pro Tool, korrigiert/überlagernd die unverifizierten Aussagen aus dem Original
|
||||
Ingest[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]:
|
||||
|
||||
- **GitHub Copilot** (VS Code): liest nativ `.github/skills/`, `.agents/skills/` und
|
||||
`.claude/skills/` im Projektumfang - kein Symlink oder zusätzliche Konfiguration in den
|
||||
gebündelten Dokumentationen bestätigt.
|
||||
- **Codex CLI**: liest nativ `.agents/skills` (CWD bis zum Repo-Stamm) plus
|
||||
`$HOME/.agents/skills` - **nicht** `~/.codex/skills/` wie ursprünglich behauptet; kein Symlink erforderlich.
|
||||
- **Mistral Vibe**: liest nativ `.vibe/skills/` und `.agents/skills/` (Projekt,
|
||||
vertrauensordner-gated) plus die Benutzerumfang-Entsprechungen - direkt aus der Quelle bestätigt.
|
||||
- **Claude Code**: liest nur `.claude/skills/` (Projekt) oder `~/.claude/skills/` (persönlich) -
|
||||
liest **nicht** nativ `.agents/skills/`, daher ist es das einzige Tool, das einen generierten
|
||||
Spiegel benötigt.
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Cross-Platform Agent Skills verwenden, wenn:
|
||||
- die gleichen Workflows über mehrere LLM-Tools hinweg erforderlich sind
|
||||
- der Anweisungssatz groß genug ist, dass das Laden von allem für jede Aufgabe ineffizient ist
|
||||
- eine einzige Quelle der Wahrheit für die Agent-Anweisungen beibehalten werden soll
|
||||
- Workflows sauber in diskrete, selbstständige Operationen unterteilt werden können
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
Dieses Muster vermeiden, wenn:
|
||||
- nur ein einzelnes LLM-Tool verwendet wird und keine Cross-Platform-Kompatibilität erforderlich ist
|
||||
- Workflows so eng gekoppelt sind, dass sie nicht sauber unterteilt werden können
|
||||
- der Overhead für die Verwaltung der Skill-Struktur die Vorteile überwiegt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]: [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **rests-on:** [[Context Isolation]]
|
||||
- **rests-on:** [[Token Economics]]
|
||||
- **see-also:** [[Scale Ceiling]]
|
||||
- **see-also:** [[Workflow Extraction]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- part-of: Consolidation Tiers
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Speicherschicht für verdichtete Sitzungszusammenfassungen und Befunde; Brücke zwischen rohem Working Memory und langlebigem Semantic Memory.
|
||||
---
|
||||
# Episodic Memory
|
||||
|
||||
**Typ:** architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Enthält mittelfristig beständiges Wissen mit mittlerem Vertrauen und leichter Komprimierung; wird aus dem Arbeitsgedächtnis beim Sitzungsende hochgestuft und ins Semantische Gedächtnis konsolidiert, wenn Muster entstehen.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Consolidation Tiers]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,140 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [search, bm25, vector, graph, scalability]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- see-also: BM25
|
||||
- composition: Vector Search
|
||||
- composition: Reciprocal Rank Fusion
|
||||
- rests-on: Knowledge Graph
|
||||
- see-also: Graph Traversal
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Multimodale Suche, die BM25-Schlüsselwortabgleich, Vektor-Embeddings und Graph Traversal verbindet, um Wissensabruf im Wiki skalierbar zu machen.
|
||||
---
|
||||
# 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**:
|
||||
1. Alle drei Suchen parallel ausführen
|
||||
2. Jede gibt eine rangierte Liste von Ergebnissen zurück
|
||||
3. RRF kombiniert die Rankings mit gegenseitigen Rang-Scores
|
||||
4. 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
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Agent Memory]] - Produktionsimplementierung
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Event-Driven Automation]] (für automatisierte Indizierung)
|
||||
- Scalable Search (verwandtes Concept)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[BM25]]
|
||||
- **composition:** [[Vector Search]]
|
||||
- **composition:** [[Reciprocal Rank Fusion]]
|
||||
- **rests-on:** [[Knowledge Graph]]
|
||||
- **see-also:** [[Graph Traversal]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,251 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [implementation, modular, levels, adoption]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- rests-on: LLM Wiki Pattern
|
||||
- composition: Memory Lifecycle
|
||||
- composition: Knowledge Graph
|
||||
- composition: Event-Driven Automation
|
||||
- composition: Multi-Agent Collaboration
|
||||
- composition: Privacy and Governance
|
||||
- composition: Crystallization
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Modularer Einführungspfad für die Funktionen von LLM Wiki v2, vom minimal tragfähigen Wiki bis zur vollen Umsetzung mit Automatisierung und Governance.
|
||||
---
|
||||
# Implementation Spectrum
|
||||
|
||||
**Typ:** Architecture (Modularer Adoptionspfad)
|
||||
|
||||
## Definition
|
||||
|
||||
Das Implementation Spectrum erkennt an, dass **alle Features des LLM Wiki v2 modular sind** - nicht alles ist am ersten Tag erforderlich. Dies bietet einen **progressiven Adoptionspfad** von minimalem praktikablem Wiki bis zu einem vollständig ausgestatteten Wissensmanagementsystem.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Das Spektrum
|
||||
|
||||
Alle Features in [[LLM Wiki Pattern]] v2 können schrittweise eingeführt werden:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ VOLLSTÄNDIGE IMPLEMENTIERUNG │
|
||||
│ Memory Lifecycle + Knowledge Graph + Skalierbare Suche + │
|
||||
│ Event-Driven Automation + Qualitätskontrollen + │
|
||||
│ Multi-Agent-Zusammenarbeit + Datenschutz & Governance + │
|
||||
│ Kristallisierung + Implementation Spectrum │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Zusammenarbeit hinzufügen
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ SKALIERUNG HINZUFÜGEN │
|
||||
│ Hybrid Search + Consolidation Tiers + Qualitätsbewertung │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Automatisierung hinzufügen
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ AUTOMATISIERUNG HINZUFÜGEN │
|
||||
│ Hooks für Auto-Ingest, Auto-Lint, Context Injection │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Struktur hinzufügen
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ STRUKTUR HINZUFÜGEN │
|
||||
│ Entity Extraction + Typisierte Beziehungen + Knowledge Graph│
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Lebenszyklus hinzufügen
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ LEBENSZYKLUS HINZUFÜGEN │
|
||||
│ Confidence Scoring + Supersession + Grundlegender Verfall │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Hier beginnen
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ MINIMALES PRAKTIKABLES WIKI │
|
||||
│ Raw-Quellen + Wiki-Seiten + index.md + Schema (AGENTS.md) │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Level-Details
|
||||
|
||||
#### Level 0: Minimales praktikables Wiki
|
||||
**Hier beginnen** - Dies ist ungefähr das, was das ursprüngliche [[LLM Wiki Pattern]] beschreibt.
|
||||
|
||||
**Komponenten:**
|
||||
- `raw/` - Unveränderbare Quelldokumente
|
||||
- `kb/` - Von LLM generierte Markdown-Seiten
|
||||
- `kb/index.md` - Inhaltskatalog
|
||||
- `kb/log.md` - Chronologischer Datensatz
|
||||
- `AGENTS.md` - Schema zur Definition von Workflows
|
||||
|
||||
**Operationen:** Manueller Ingest, Abfrage, Lint
|
||||
|
||||
**Wann nutzen:** Einstieg, kleine Wikis, Mustererlernung
|
||||
|
||||
**Seiten:** ~1-100
|
||||
|
||||
---
|
||||
|
||||
#### Level 1: Lebenszyklus hinzufügen
|
||||
Verhindert, dass das Wiki zu einer Rumpelkammer wird.
|
||||
|
||||
**Hinzufügen:**
|
||||
- [[Confidence Scoring]] - Jeder Fakt trägt eine Zuverlässigkeitsbewertung
|
||||
- [[Supersession]] - Neue Informationen ersetzen explizit alte
|
||||
- Grundlegendes [[Forgetting]] - Aufbewahrungsverfall für alte Informationen
|
||||
|
||||
**Wann hinzufügen:** Wenn bemerkt wird, dass veraltete Informationen persistieren
|
||||
|
||||
**Seiten:** ~100-500
|
||||
|
||||
---
|
||||
|
||||
#### Level 2: Struktur hinzufügen
|
||||
Verbessert Abfragen und enthüllt Verbindungen, die bei flachen Seiten vermisst würden.
|
||||
|
||||
**Hinzufügen:**
|
||||
- [[Entity Extraction]] - Strukturierte Entitäten aus Quellen extrahieren
|
||||
- [[Typed Relationships]] - Typisierte Links verwenden (hängt ab von, nutzt, etc.)
|
||||
- [[Knowledge Graph]] - Graph-Ebene für Navigation und Entdeckung
|
||||
|
||||
**Wann hinzufügen:** Wenn Verbindungen über viele Seiten hinweg gefunden werden müssen
|
||||
|
||||
**Seiten:** ~500-2000
|
||||
|
||||
---
|
||||
|
||||
#### Level 3: Automatisierung hinzufügen
|
||||
Wo die Wartungslast auf nahe Null sinkt.
|
||||
|
||||
**Hinzufügen:**
|
||||
- [[Event-Driven Automation]] - Hooks für Auto-Ingest, Auto-Lint, etc.
|
||||
- [[Hooks]] - Event-Listener für verschiedene Auslöser
|
||||
|
||||
**Wann hinzufügen:** Wenn manuelle Wartung zur Last wird
|
||||
|
||||
**Seiten:** Beliebige Größe
|
||||
|
||||
---
|
||||
|
||||
#### Level 4: Skalierung hinzufügen
|
||||
Was benötigt wird, wenn das Wiki über ein paar hundert Seiten hinauswächst.
|
||||
|
||||
**Hinzufügen:**
|
||||
- [[Hybrid Search]] - BM25 + Vector + Graph Traversal
|
||||
- [[Consolidation Tiers]] - Gestaffelte Memory-Architektur
|
||||
- [[Quality Scoring]] - Qualitätskennzahlen für alle Inhalte
|
||||
|
||||
**Wann hinzufügen:** Wenn die Suchleistung degradiert oder index.md unhandlich wird
|
||||
|
||||
**Seiten:** ~1000+
|
||||
|
||||
---
|
||||
|
||||
#### Level 5: Zusammenarbeit hinzufügen
|
||||
Für Teams oder Multi-Agent-Setups.
|
||||
|
||||
**Hinzufügen:**
|
||||
- [[Multi-Agent Collaboration]] - Mesh Sync, gemeinsame/private Gültigkeitsbereiche
|
||||
- [[Mesh Sync]] - Beobachtungen von parallelen Agenten zusammenführen
|
||||
- [[Work Coordination]] - Leichte Aufgabenverfolgung
|
||||
|
||||
**Wann hinzufügen:** Wenn mehrere Agenten oder Personen beitragen
|
||||
|
||||
**Seiten:** Beliebige Größe, mehrere Mitwirkende
|
||||
|
||||
---
|
||||
|
||||
#### Level 6: Governance hinzufügen
|
||||
Für Produktionsumgebungen.
|
||||
|
||||
**Hinzufügen:**
|
||||
- [[Privacy and Governance]] - Filter beim Ingest, Audit Trail
|
||||
- [[Filter on Ingest]] - Sensible Daten automatisch entfernen
|
||||
- [[Audit Trail]] - Alle Operationen protokollieren
|
||||
- [[Bulk Operations]] - Geprüfte, reversible Massenoperationen
|
||||
|
||||
**Wann hinzufügen:** Bei sensiblen Daten oder Compliance-Anforderungen
|
||||
|
||||
**Seiten:** Beliebige Größe, sensible Daten
|
||||
|
||||
---
|
||||
|
||||
#### Level 7: Kristallisierung hinzufügen
|
||||
Maximale Wissensverflechtung.
|
||||
|
||||
**Hinzufügen:**
|
||||
- [[Crystallization]] - Erkundungen in strukturiertes Wissen destillieren
|
||||
|
||||
**Wann hinzufügen:** Wenn maximale Rendite aus Forschungs-/Debug-Sitzungen gewünscht wird
|
||||
|
||||
**Seiten:** Beliebige Größe, forschungsintensiv
|
||||
|
||||
## Anleitung zur Einführung
|
||||
|
||||
### Den Eintrittspunkt wählen
|
||||
|
||||
Die Startebene basierend auf den Anforderungen wählen:
|
||||
|
||||
| Bedarf | Start bei | Dann hinzufügen |
|
||||
|------|----------|----------|
|
||||
| Persönliches Wissensmanagement | Level 0 | Level 1, dann je nach Bedarf |
|
||||
| Team-Dokumentation | Level 0 oder 1 | Level 5, dann Level 6 |
|
||||
| Forschungsprojekt | Level 0 | Level 2, dann Level 7 |
|
||||
| Produktions-Wissensdatenbank | Level 1 | Level 3, dann Level 6 |
|
||||
| Großes Wiki | Level 3 | Level 4, dann andere |
|
||||
|
||||
### Migrationspfad
|
||||
|
||||
Sie können jederzeit zwischen Ebenen migrieren. Jede Ebene **baut auf** der vorherigen auf:
|
||||
|
||||
```
|
||||
Level 0 → Level 1 → Level 2 → Level 3 → Level 4 → Level 5 → Level 6 → Level 7
|
||||
```
|
||||
|
||||
**Hinweis:** Level 2, 4 und 5 haben externe Abhängigkeiten (Graphdatenbank, Vektorsuche, etc.), die möglicherweise zusätzliche Infrastruktur erfordern.
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Niedrige Eintrittsbarriere:** Einfach beginnen, bei Bedarf Komplexität hinzufügen
|
||||
- **Flexibilität:** Nur die Features wählen, die erforderlich sind
|
||||
- **Skalierbarkeit:** Jede Ebene verarbeitet mehr Skala als die vorherige
|
||||
- **Zukunftssicher:** Features können schrittweise hinzugefügt werden
|
||||
- **Kostengünstig:** Nicht für Komplexität zahlen, die nicht erforderlich ist
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- **Immer:** Auf Level 0 oder 1 starten
|
||||
- **Je nach Bedarf:** Ebenen hinzufügen, wenn auf Grenzen gestoßen wird
|
||||
- **Nie:** Nicht alle Ebenen auf einmal implementieren (zu viel Komplexität)
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Hybrid Search]] - Level-4-Erweiterung
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Three-Layer Architecture]] (Grundlage für alle Ebenen)
|
||||
- [[Agent Memory]] (Implementierung höherer Ebenen)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **rests-on:** [[LLM Wiki Pattern]]
|
||||
- **composition:** [[Memory Lifecycle]]
|
||||
- **composition:** [[Knowledge Graph]]
|
||||
- **composition:** [[Event-Driven Automation]]
|
||||
- **composition:** [[Multi-Agent Collaboration]]
|
||||
- **composition:** [[Privacy and Governance]]
|
||||
- **composition:** [[Crystallization]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,154 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [graph, entities, relationships, knowledge-management]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- see-also: Memory Lifecycle
|
||||
- see-also: Entity Extraction
|
||||
- composition: Typed Relationships
|
||||
- see-also: Graph Traversal
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Typisierte Schicht aus Entities und Beziehungen über den Wiki-Seiten, die eine reichere Wissensdarstellung und graphbasierte Abfragen ermöglicht.
|
||||
---
|
||||
# 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]]:
|
||||
|
||||
1. **Entities extrahieren** bei Quellaufnahme
|
||||
2. **Im Graph-Datenbank** oder strukturiertem Format speichern
|
||||
3. **Bidirektionale Links pflegen** zwischen Graph-Knoten und Wiki-Seiten
|
||||
4. **Graph-Traversal aktivieren** für komplexe Abfragen
|
||||
5. **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
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Agent Memory]] - Produktionsimplementierung
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Hybrid Search]] (nutzt Graph-Traversal als einen Stream)
|
||||
- [[Event-Driven Automation]] (für automatische Graph-Updates)
|
||||
- [[Supersession]] (als Graph-Beziehung verfolgt)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[Memory Lifecycle]]
|
||||
- **see-also:** [[Entity Extraction]]
|
||||
- **composition:** [[Typed Relationships]]
|
||||
- **see-also:** [[Graph Traversal]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,245 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [knowledge-management, llm, wiki, pattern]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- rests-on: Three-Layer Architecture
|
||||
- see-also: Knowledge Compounding
|
||||
- contrasts: RAG
|
||||
- see-also: Vannevar Bush
|
||||
- composition: Memory Lifecycle
|
||||
- see-also: Memex
|
||||
sources: [Source - LLM Wiki Pattern, Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Methodik für persönliches Wissensmanagement, bei der ein LLM aus Rohquellen ein dauerhaftes Wiki aufbaut - Wissen wird kompiliert statt per RAG neu hergeleitet.
|
||||
---
|
||||
# LLM Wiki Pattern
|
||||
|
||||
**Typ:** Architektur (Muster für Personal Knowledge Management)
|
||||
|
||||
## Definition
|
||||
|
||||
Das LLM Wiki Pattern ist eine Methodik zum Aufbau persönlicher Wissensdatenbanken, bei der ein Large Language Model (LLM) schrittweise einen persistenten, strukturierten Wiki aus Raw-Source-Dokumenten aufbaut und verwaltet. Im Gegensatz zu traditionellen RAG-Systemen (Retrieval Augmented Generation), die Wissen bei jeder Abfrage von Grund auf neu ableiten, kompiliert das LLM Wiki Pattern Wissen einmal und hält es aktuell.
|
||||
|
||||
**Dieses Wiki selbst implementiert das LLM Wiki Pattern.**
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Das Kernproblem
|
||||
Traditionelle RAG-Ansätze (exemplifiziert durch [[NotebookLM]], [[ChatGPT]] Datei-Uploads) leiden unter:
|
||||
- Wissen wird bei jeder Abfrage von Grund auf neu entdeckt
|
||||
- Keine Ansammlung von synthetisiertem Verständnis
|
||||
- Subtile Fragen, die Synthese mehrerer Dokumente erfordern, müssen jedes Mal neu abgeleitet werden
|
||||
- Keine persistenten Cross-References oder Widerspruchsmarkierung
|
||||
- Kein Akkumulationseffekt durch das Hinzufügen neuer Quellen
|
||||
|
||||
### Die Lösung
|
||||
Das LLM Wiki Pattern führt eine **persistente Wiki-Ebene** zwischen dem Benutzer und den Rohdatenquellen ein:
|
||||
- Wissen wird einmal aus jeder Quelle kompiliert
|
||||
- Das Wiki wird durch Updates aktuell gehalten, wenn neue Quellen ankommen
|
||||
- Cross-References werden automatisch verwaltet
|
||||
- Widersprüche werden bei Erkennung markiert
|
||||
- Wissen sammelt sich an, wenn mehr Quellen hinzugefügt werden
|
||||
|
||||
### Wichtige Einsicht
|
||||
> "Das Wiki ist ein persistentes, akkumulierendes Artefakt. Die Cross-References sind bereits vorhanden. Die Widersprüche wurden bereits markiert. Die Synthese spiegelt bereits alles wider, was Sie gelesen haben. Das Wiki wird mit jeder hinzugefügten Quelle und jeder gestellten Frage reicher."
|
||||
|
||||
## V2-Erweiterungen
|
||||
|
||||
Das ursprüngliche Muster wurde in **LLM Wiki v2** (von [[Rohit Gupta]], aufgebaut auf [[Andrej Karpathy]]s Original) mit Produktionslektionen aus [[Agent Memory]] erweitert. Diese Ergänzungen behandeln, was in der Skalierung bricht und was ein Wiki unterscheidet, das nützlich bleibt, von einem, das verfällt.
|
||||
|
||||
### Kernverbesserungen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Memory Lifecycle** | Wissen hat einen Lebenszyklus - er muss verwaltet werden | [[Memory Lifecycle]] |
|
||||
| **Confidence Scoring** | Jede Tatsache trägt eine Zuverlässigkeitsbewertung | [[Confidence Scoring]] |
|
||||
| **Supersession** | Neue Informationen ersetzen explizit alte (Versionskontrolle für Wissen) | [[Supersession]] |
|
||||
| **Forgetting** | Alte, irrelevante Informationen verblassen (nicht gelöscht) | [[Forgetting]] |
|
||||
| **Consolidation Tiers** | Informationen fördern durch Tiers, wenn Beweise ansammeln | [[Consolidation Tiers]] |
|
||||
|
||||
### Strukturverbesserungen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Knowledge Graph** | Typisierte Entities und Beziehungen auf Seiten | [[Knowledge Graph]] |
|
||||
| **Entity Extraction** | Strukturierte Entities aus Quellen extrahieren | Teil von [[Knowledge Graph]] |
|
||||
| **Typed Relationships** | Nicht alle Links sind gleich (depends on, uses, contradicts usw.) | [[Knowledge Graph]] |
|
||||
| **Graph Traversal** | Durch den Graphen gehen für komplexe Abfragen | [[Graph Traversal]] |
|
||||
|
||||
### Skalierungsverbesserungen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Hybrid Search** | BM25, Vektorsuche und Graph-Traversal kombinieren | [[Hybrid Search]] |
|
||||
| **BM25** | Keyword-Matching mit Stemming | [[BM25]] |
|
||||
| **Vector Search** | Semantische Ähnlichkeit durch Einbettungen | [[Vector Search]] |
|
||||
| **Reciprocal Rank Fusion** | Sucherergebnisse aus mehreren Modalitäten zusammenführen | [[Reciprocal Rank Fusion]] |
|
||||
|
||||
### Automatisierungsverbesserungen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Event-Driven Automation** | Hooks für Auto-Ingest, Auto-Lint usw. | [[Event-Driven Automation]] |
|
||||
| **Hooks** | Event-Listener, die Aktionen auslösen | [[Hooks]] |
|
||||
|
||||
### Qualitätsverbesserungen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Quality Scoring** | Score aller von LLM geschriebenen Inhalte | [[Quality and Self-Correction]] |
|
||||
| **Self-Healing** | Automatisch beheben, was Lint kann | [[Quality and Self-Correction]] |
|
||||
| **Contradiction Resolution** | Automatisch Widersprüche beheben | [[Quality and Self-Correction]] |
|
||||
|
||||
### Zusammenarbeit-Verbesserungen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Multi-Agent Collaboration** | Mehrere Agenten tragen zum gleichen Wiki bei | [[Multi-Agent Collaboration]] |
|
||||
| **Mesh Sync** | Beobachtungen von parallelen Agenten zusammenführen | [[Multi-Agent Collaboration]] |
|
||||
| **Shared vs Private** | Wissen angemessen scoping | [[Multi-Agent Collaboration]] |
|
||||
| **Work Coordination** | Doppelte Arbeit verhindern | [[Multi-Agent Collaboration]] |
|
||||
|
||||
### Governance-Verbesserungen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Privacy and Governance** | Sicherheit und Rechenschaftspflicht | [[Privacy and Governance]] |
|
||||
| **Filter on Ingest** | Sensitive Daten automatisch entfernen | [[Privacy and Governance]] |
|
||||
| **Audit Trail** | Alle Vorgänge protokollieren | [[Privacy and Governance]] |
|
||||
| **Bulk Operations** | Geprüfte, reversible Massenvorgänge | [[Privacy and Governance]] |
|
||||
|
||||
### Erweiterte Funktionen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Crystallization** | Erkundungen zu strukturiertem Wissen destillieren | [[Crystallization]] |
|
||||
| **Implementation Spectrum** | Modularer Adoptionspfad von minimal bis voll | [[Implementation Spectrum]] |
|
||||
|
||||
Für einen geführten Adoptionspfad siehe [[Implementation Spectrum]].
|
||||
|
||||
## Architektur
|
||||
|
||||
Siehe [[Three-Layer Architecture]] für Details:
|
||||
|
||||
1. **Rohdatenquellen** — Unveränderliche kuratierte Sammlung von Quelldokumenten (Artikel, Papiere, Bilder, Datendateien)
|
||||
2. **Das Wiki** — Verzeichnis von LLM-generierten Markdown-Dateien (Zusammenfassungen, Entity-Seiten, Concept-Seiten, Vergleiche, Index, Log)
|
||||
3. **Das Schema** — Konfigurationsdokument (z. B. AGENTS.md), das Struktur, Konventionen und Workflows definiert
|
||||
|
||||
## Vorgänge
|
||||
|
||||
### Aufnahme-Workflow
|
||||
1. Benutzer legt neue Quelle in Rohdatensammlung ab
|
||||
2. LLM liest die Quelle
|
||||
3. LLM diskutiert wichtige Erkenntnisse mit Benutzer
|
||||
4. LLM schreibt Zusammenfassungsseite im Wiki
|
||||
5. LLM aktualisiert relevante Entity- und Concept-Seiten im gesamten Wiki
|
||||
6. LLM aktualisiert index.md
|
||||
7. LLM fügt Eintrag zu log.md hinzu
|
||||
|
||||
**Ergebnis**: Eine einzelne Quelle könnte 10-15 Wiki-Seiten berühren.
|
||||
|
||||
### Abfrage-Workflow
|
||||
1. Benutzer stellt eine Frage
|
||||
2. LLM durchsucht index.md nach relevanten Seiten
|
||||
3. LLM liest relevante Entity- und Concept-Seiten
|
||||
4. LLM folgt Cross-References zu verwandten Seiten
|
||||
5. LLM synthetisiert Antwort mit Zitaten
|
||||
6. Wertvolle Antworten werden als neue Wiki-Seiten eingereicht
|
||||
|
||||
### Lint-Workflow
|
||||
Periodische Gesundheitsprüfung zu:
|
||||
- Widersprüche zwischen Seiten finden
|
||||
- Veraltete Aussagen identifizieren
|
||||
- Verwaiste Seiten lokalisieren
|
||||
- Fehlende Seiten finden
|
||||
- Fehlende Cross-References identifizieren
|
||||
- Verbesserungen vorschlagen
|
||||
|
||||
## Schlüsselkomponenten
|
||||
|
||||
### Indizierung und Protokollierung
|
||||
- **index.md**: Inhaltsgerichteter Katalog, nach Kategorie organisiert. Einstiegspunkt des LLM zum Finden relevanter Seiten.
|
||||
- **log.md**: Chronologischer Append-Only-Datensatz aller Vorgänge.
|
||||
|
||||
### Seitentypen
|
||||
- **Source-Seiten**: Zusammenfassungen aufgenommener Quellen
|
||||
- **Entity-Seiten**: Projekte, Systeme, Tools, Technologien, Menschen
|
||||
- **Concept-Seiten**: Architekturen, Muster, Protokolle, Workflows, Entscheidungen, Probleme
|
||||
- **Vergleichs-Seiten**: Nebeneinander-Analyse von Entities
|
||||
|
||||
## Rollen
|
||||
|
||||
### Menschliche Verantwortungen
|
||||
- Quellen kuratieren (Qualitätsdokumente finden und auswählen)
|
||||
- Die Analyse leiten (LLM anleiten, worauf zu betonen ist)
|
||||
- Gute Fragen stellen (Wissenssynthese vorantreiben)
|
||||
- Über die Bedeutung nachdenken (synthetisiertes Wissen interpretieren)
|
||||
|
||||
### LLM-Verantwortungen
|
||||
- Schlüsselinformationen aus Quellen lesen und extrahieren
|
||||
- Alle Wiki-Inhalte schreiben und verwalten
|
||||
- Cross-References erstellen und aktualisieren
|
||||
- Konsistenz über Seiten aufrechterhalten
|
||||
- Widersprüche und Lücken markieren
|
||||
- Buchführung durchführen (Ablage, Index-Aktualisierung, Protokollierung)
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Personal Knowledge Management im Laufe der Zeit
|
||||
- Tiefe Forschung zu einem Thema (Wochen oder Monate)
|
||||
- Bücher mit vielen Cross-References lesen
|
||||
- Geschäfts-/Team-interne Dokumentation
|
||||
- Konkurrenzanalyse, Due Diligence
|
||||
- Reiseplanung, Kursnotizen, Hobby-Tieftauchgänge
|
||||
- Jede Domäne, in der Wissen angesammelt und organisiert werden soll
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Einfache, einmalige Fragen (traditionelles RAG reicht aus)
|
||||
- Notwendigkeit von Echtzeit-Updates aus Live-Datenquellen
|
||||
- Domänen, in denen strukturierte Abfrage (SQL) angemessener ist
|
||||
- Wenn der Overhead der Wiki-Wartung den Vorteil überwiegt
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
## Beispiele
|
||||
|
||||
- **Persönlich**: Ziele, Gesundheit, Psychologie, Selbstverbesserung verfolgen
|
||||
- **Forschung**: Tiefer in ein Thema eintauchen, Papiere lesen, umfassendes Wiki aufbauen
|
||||
- **Lesen**: Jedes Kapitel ablegen, Seiten für Charaktere, Themen, Handlungsfäden erstellen
|
||||
- **Geschäft**: Internes Wiki mit Slack-Threads, Meetingtransskripten, Projektdokumenten gefüttert
|
||||
- **Fan-Wikis**: Wie [[Tolkien Gateway]] — Tausende verlinkter Seiten
|
||||
|
||||
## Tools
|
||||
|
||||
- [[Obsidian]]: Die IDE zum Durchsuchen von Wiki-Inhalten
|
||||
- [[qmd]]: Optionale Suchmaschine für größere Wikis
|
||||
- [[Marp]]: Zum Erstellen von Präsentationen aus Wiki-Inhalten
|
||||
- [[Dataview]]: Für dynamische Tabellen und Listen
|
||||
- [[Obsidian Web Clipper]]: Zum schnellen Aufnehmen von Quellen in die Rohdatensammlung
|
||||
|
||||
## Historie
|
||||
|
||||
- [1945] - Vannevar Bush schlägt [[Memex]]-Konzept vor
|
||||
- [2023-2024] - LLM-Agenten werden fähig genug, das Muster zu implementieren
|
||||
- [2026-07-26] - Concept-Seite erstellt; dieses Wiki implementiert das Muster
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Obsidian]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **rests-on:** [[Three-Layer Architecture]]
|
||||
- **see-also:** [[Knowledge Compounding]]
|
||||
- **contrasts:** [[RAG]]
|
||||
- **see-also:** [[Vannevar Bush]]
|
||||
- **composition:** [[Memory Lifecycle]]
|
||||
- **see-also:** [[Memex]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,105 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [mcp, library-boundary, search, server]
|
||||
created: 2026-09-02
|
||||
modified: 2026-09-02
|
||||
related:
|
||||
- operates-on: wikitool
|
||||
- see-also: Publish-Remote Gate
|
||||
- see-also: Mass-Update Gate
|
||||
- see-also: Iteration and Cost Limits
|
||||
- see-also: Chemenu
|
||||
sources: [Source - MCP Read Server Implementation Session 2026-09-02]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: sourced
|
||||
summary: 'Zweiter Konsument von chemenu ueber MCP: search/types/describe_type/lint/status auf chemenu.api.Corpus, strukturell ohne Schreibpfad, jede Antwort trage einen Commit-Stempel.'
|
||||
---
|
||||
# MCP-Leseserver
|
||||
|
||||
**Typ:** Architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Ein zweiter Konsument desselben Kerns, nicht ein zweites Programm: `tools/chemenu/mcp/` exponiert
|
||||
`search`, `types`, `describe_type`, `lint` und `status` über MCP, indem es dieselben Funktionen
|
||||
aufruft, die `wikitool` auch aufruft - vermittelt durch `chemenu.api.Corpus`, den In-Process-
|
||||
Einstiegspunkt. Ein Golden-Test hält die Ausgaben beider Wege gegeneinander, statt darauf zu
|
||||
vertrauen, dass sie übereinstimmen.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Kein Schreibpfad, strukturell.** Weder der Server noch `chemenu.api` importiert etwas unter
|
||||
`chemenu.commands` - `new`, `touch`, `xref`, `publish`, `migrate` sind aus diesem Prozess
|
||||
heraus nicht erreichbar, statt aus einer Liste gefiltert zu werden. Ein Test importiert das
|
||||
Servermodul in einem frischen Interpreter und prüft
|
||||
`sys.modules`.[^s-mcp-read-server-implementation-session-2026-09-02]
|
||||
- **Zwei Transports.** `stdio` zum Entwickeln und Testen ohne Netz; `streamable-http` für die
|
||||
Auslieferung, der einzige, vor den sich ein HTTP-Reverse-Proxy setzen kann. `sse` ist über das
|
||||
SDK erreichbar und wird bewusst nicht angeboten - der abgelöste Remote-Transport, jetzt darauf
|
||||
zu bauen verschiebt den Wechsel nur.
|
||||
- **Jede Antwort trägt den Commit, aus dem sie berechnet wurde** (`commit`, `as_of`). Ein
|
||||
veralteter Checkout antwortet sonst selbstbewusst falsch. `null` heißt: der bediente Baum hat
|
||||
uncommittete Änderungen, die Antwort entspricht keiner Revision. Der Stempel ist die Revision,
|
||||
aus der die Seiten *tatsächlich* gelesen wurden, nicht die zum Zeitpunkt des Stempelns aktuelle
|
||||
- ein Bug, der genau diesen Unterschied überging, wurde beim Schreiben des Golden-Tests selbst
|
||||
gefunden und behoben.[^s-mcp-read-server-implementation-session-2026-09-02]
|
||||
- **Telemetrie in den bedienten Baum wird beim Start verweigert**, nicht still umgeleitet. Der
|
||||
Sync, der den Checkout aktuell hält (`git fetch && git reset --hard`), darf `reports/telemetry/`
|
||||
wegräumen; ein Trace, der dort landet, wäre ein Verlust und eine stille Möglichkeit, den Baum
|
||||
zu beschmutzen, dessen Sauberkeit der Korpus-Cache prüft.
|
||||
- **Kein Iteration Budget Gate im Server.** Das Gate begrenzt eine Agenten-Session am unbemerkten
|
||||
Iterieren über den Wiki-Zustand, nicht einen Nutzer, der oft sucht - Retrieval ist deshalb
|
||||
bereits generell davon ausgenommen (siehe [[Iteration and Cost Limits]]). Rate Limiting gehört
|
||||
stattdessen vor den Prozess, neben die Authentifizierung.
|
||||
- **Authentifizierung ist Middleware, nicht Servercode.** Eine Traefik-ForwardAuth-Instanz
|
||||
(Bearer-Token gegen SHA-256-Hashes) sitzt vor dem Prozess; nicht sauber authentifizierte
|
||||
Zugriffe erreichen Python gar nicht erst.
|
||||
- **Gemessen:** Korpus-Parse für 176 Seiten 265 ms → 54 ms (`CSafeLoader`),
|
||||
`wikitool search` end-to-end 593 ms → 347 ms; die verbleibenden ~262 ms sind Modulimport und
|
||||
entfallen im residenten Serverprozess, weil er ihn einmal pro Start statt pro Aufruf
|
||||
zahlt.[^s-mcp-read-server-implementation-session-2026-09-02]
|
||||
|
||||
## Beispiele
|
||||
|
||||
- `search`/`types`/`describe_type`/`lint`/`status` als die fünf Tools - siehe
|
||||
`tools/chemenu/mcp/server.py`.
|
||||
- Der Korpus-Cache (`chemenu/corpus_cache.py`) hält einen Parse pro Commit und cacht nie einen
|
||||
schmutzigen Arbeitsbaum - dieselbe Eigenschaft, die den Antwort-Stempel korrekt hält.
|
||||
- `chemenu.api.Corpus`: nimmt einen Root, liefert exakt die `--json`-Formen der CLI, raised statt
|
||||
zu exitieren.
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Ein Konsument, der keine Shell auf der bedienenden Maschine ist, soll dieselben Fragen stellen
|
||||
können wie ein Agent, der `wikitool` direkt aufruft.
|
||||
- Mehrere gleichzeitige Leser eines Korpus, für die ein Prozess pro CLI-Aufruf (Modulimport,
|
||||
Korpus-Parse) unnötigen Overhead bedeutet.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Als Ort für einen Schreibpfad - die Ingest-Queue (geplant, Issue #32) ist ein anderes Design
|
||||
mit einer Quarantäne davor, nicht eine Erweiterung dieses Servers.
|
||||
- Als Ersatz für den Iteration Budget Gate oder das Traefik-Rate-Limiting - beide bleiben
|
||||
notwendig und leben an anderer Stelle.
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-mcp-read-server-implementation-session-2026-09-02]: [[Source - MCP Read Server Implementation Session 2026-09-02]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - MCP Read Server Implementation Session 2026-09-02]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **operates-on:** [[wikitool]]
|
||||
- **see-also:** [[Publish-Remote Gate]]
|
||||
- **see-also:** [[Mass-Update Gate]]
|
||||
- **see-also:** [[Iteration and Cost Limits]]
|
||||
- **see-also:** [[Chemenu]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [memory, lifecycle, confidence, knowledge-management]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- part-of: LLM Wiki Pattern
|
||||
- see-also: Confidence Scoring
|
||||
- composition: Supersession
|
||||
- see-also: Consolidation Tiers
|
||||
- see-also: Forgetting
|
||||
- enables: Knowledge Compounding
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Architektur des Wissenslebenszyklus mit Confidence Scoring, Supersession, Forgetting und Consolidation Tiers zur Pflege von Fakten über die Zeit.
|
||||
---
|
||||
# Memory Lifecycle
|
||||
|
||||
**Typ:** Architektur (Knowledge-Management-Muster)
|
||||
|
||||
## Definition
|
||||
|
||||
Memory Lifecycle ist die Erkenntnis, dass **Wissen einen Lebenszyklus hat** und entsprechend verwaltet werden muss. Im Gegensatz zum ursprünglichen LLM Wiki Pattern, das alle Wiki-Inhalte für immer gleich gültig behandelt, erkennt der Memory-Lifecycle-Ansatz an, dass Tatsachen unterschiedliche Bedeutung, Aktualität und Zuverlässigkeit haben, die sich im Laufe der Zeit ändern.
|
||||
|
||||
Dieses Konzept ist eine primäre Verbesserung, die in [[LLM Wiki Pattern]] v2 eingeführt wurde, basierend auf Produktionslektionen aus [[Agent Memory]].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Das Problem
|
||||
|
||||
Die flache Behandlung aller Wissenstypen des ursprünglichen Musters führt zu:
|
||||
- Alte, möglicherweise veraltete Informationen neben neuen, verifizierten Tatsachen
|
||||
- Keine Möglichkeit, zwischen etabliertem Wissen und vorläufigen Beobachtungen zu unterscheiden
|
||||
- Wissensdatenbanken, die im Laufe der Zeit laut und schwer zu navigieren werden
|
||||
- Kein Mechanismus, damit sich Wissen entwickelt oder überholt wird
|
||||
|
||||
### Die Lösung: Vier Säulen
|
||||
|
||||
**1. Confidence Scoring**
|
||||
Jede Tatsache im Wiki trägt einen Confidence-Score, der widerspiegelt:
|
||||
- **Quellenanzahl:** +0,2 pro unterstützende Quelle (Max +0,6)
|
||||
- **Aktualität:** +0,2 wenn <30 Tage, +0,1 wenn <90 Tage
|
||||
- **Quellenqualität:** +0,1 für offizielle Dokumente, +0,05 für seriöse Quellen
|
||||
- **Bestätigung:** +0,1 wenn mehrere unabhängige Quellen zustimmen
|
||||
- **Basis-Confidence:** 0,5 (Standard für einzelne Quelle)
|
||||
|
||||
Confidence fällt mit 1% pro Monat seit letzter Bestätigung, Minimum 0,2.
|
||||
|
||||
**2. Supersession**
|
||||
Wenn neue Informationen einen bestehenden Aussage widersprechen oder aktualisieren:
|
||||
- Der neue Aussage **ersetzt** explizit den alten
|
||||
- Beide sind mit Zeitstempeln verlinkt
|
||||
- Die alte Version wird bewahrt, aber **als veraltet markiert**
|
||||
- Dies ist Versionskontrolle für Wissen, nicht nur für Dateien
|
||||
|
||||
**3. Vergessen (Retention Curve)**
|
||||
Nicht alles sollte für immer leben. Eine Retention Curve inspiriert von Ebbinghaus implementieren:
|
||||
- Tatsachen, die Monate lang nicht aufgerufen oder verstärkt wurden, **verblassen allmählich**
|
||||
- Nicht gelöscht, aber **deprioritiert** bei Suche und Synthese
|
||||
- Unterschiedliche Verfallsraten für verschiedene Typen:
|
||||
- Architekturentscheidungen verfallen **langsam**
|
||||
- Vorübergehende Fehler verfallen **schnell**
|
||||
- Das LLM-Äquivalent von etwas in eine untere Schublade verschieben
|
||||
|
||||
**4. Consolidation Tiers**
|
||||
Eine Pipeline, die Informationen fördert, wenn sich Beweise ansammeln:
|
||||
|
||||
```
|
||||
Rohe Beobachtungen
|
||||
↓ (compress)
|
||||
Working Memory → aktuelle Beobachtungen, noch nicht verarbeitet
|
||||
↓ (compress)
|
||||
Episodic Memory → Sitzungszusammenfassungen, komprimiert aus rohen Beobachtungen
|
||||
↓ (compress)
|
||||
Semantic Memory → Sitzungsübergreifende Tatsachen, konsolidiert aus Episoden
|
||||
↓ (compress)
|
||||
Procedural Memory → Workflows und Muster, extrahiert aus wiederholter Semantik
|
||||
```
|
||||
|
||||
Jede Ebene ist:
|
||||
- Mehr **komprimiert** als die darunter
|
||||
- Mehr **confident** (höherwertige Beweise)
|
||||
- **Länger lebend** als die darunter
|
||||
|
||||
Von „Ich habe das einmal gesehen" zu „So funktionieren die Dinge" gehen.
|
||||
|
||||
## Implementierung
|
||||
|
||||
Basierend auf [[Agent Memory]]-Erfahrung:
|
||||
|
||||
1. **Metadaten verfolgen** für jede Aussage: Quelle, Datum, Confidence-Score, verwandte Entities
|
||||
2. **Automatisch verfallen** Confidence-Scores basierend auf Zeit
|
||||
3. **Confidence erhöhen** wenn Aussagen aufgerufen oder bestätigt werden
|
||||
4. **Supersession markieren** mit expliziten Links und Zeitstempeln
|
||||
5. **Gestuffelt Speicherung** mit unterschiedlichen Aufbewahrungsrichtlinien implementieren
|
||||
6. **Hochwertige** Informationen bevorzugt in Abfragen anzeigen
|
||||
|
||||
## Vorteile
|
||||
|
||||
- Wiki bleibt **nützlich**, während es wächst (verfällt nicht)
|
||||
- Benutzer können **der Information vertrauen** (Confidence ist explizit)
|
||||
- Wissen **entwickelt sich** natürlich (Supersession)
|
||||
- Irrelevante Informationen **verblassen** (Vergessen)
|
||||
- Muster **entstehen** (Consolidation Tiers)
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Jedes Wiki, das über mehrere hundert Seiten hinauswachsen soll
|
||||
- Domänen, in denen sich Wissen im Laufe der Zeit ändert (Technologie, Forschung)
|
||||
- Situationen, in denen die Zuverlässigkeit von Informationen variiert
|
||||
- Multi-Quellen-Wissensdatenbanken
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Agent Memory]] - Produktionsimplementierung
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Event-Driven Automation]] (Trigger für Lebenszyklus-Management)
|
||||
- [[Quality Scoring]] (komplementäre Qualitätsmetriken)
|
||||
- [[Knowledge Graph]] (Struktur zur Verfolgung von Beziehungen)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[Confidence Scoring]]
|
||||
- **composition:** [[Supersession]]
|
||||
- **see-also:** [[Consolidation Tiers]]
|
||||
- **see-also:** [[Forgetting]]
|
||||
- **enables:** [[Knowledge Compounding]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [interoperability, export, validate, okf-profile]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- see-also: awesome-llm-wiki
|
||||
sources: [Source - LLM Improvements Codex Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Optionale Kompatibilität zum Open Knowledge Framework als Export- und Prüfmodus, ohne das interne Modell zu ersetzen
|
||||
---
|
||||
# OKF Compatibility
|
||||
|
||||
**Typ:** architecture
|
||||
|
||||
## Definition
|
||||
|
||||
OKF (Open Knowledge Framework) Compatibility ist das Konzept, einen Export-/Validierungsmodus hinzuzufügen, der OKF-kompatible Formate lesen und schreiben kann, um Interoperabilität mit anderen Tools und Wikis zu ermöglichen, ohne das interne Schema oder Modell zu ersetzen. Dies ermöglicht es dem Wiki, am breiteren OKF-Ökosystem teilzunehmen und gleichzeitig seine eigenen deterministischen Grundlagen beizubehalten.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Export-Modus:** Wiki-Seiten in OKF-kompatibles Format konvertieren
|
||||
- **Validierungsmodus:** OKF-Kompatibilität vorhandener Inhalte überprüfen
|
||||
- **Kein Ersatz:** Ersetzt nicht das interne AGENTS.md-Schema oder wikitool
|
||||
- **Interoperabilität:** Ermöglicht Datenaustausch mit anderen OKF-kompatiblen Systemen
|
||||
|
||||
## Beispiele
|
||||
|
||||
- `wikitool export --format okf --output wiki-okf/`
|
||||
- `wikitool validate --format okf`
|
||||
- Interoperabilität mit Tools aus dem awesome-llm-wiki-Repository
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Beim Interagieren mit externen OKF-kompatiblen Systemen
|
||||
- Für Datenmigration oder Austausch
|
||||
- Um am OKF-Ökosystem teilzunehmen
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Als Ersatz für das interne Schema
|
||||
- Wenn OKF-Kompatibilität nicht erforderlich ist
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Three-Layer Architecture]] (OKF-Export würde eine zusätzliche Ebene oder einen Modus darstellen)
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Codex Analysis]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[awesome-llm-wiki]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related:
|
||||
- mechanism: ENVIRONMENT.md
|
||||
- contrasts: Personalization Plane
|
||||
- mechanism: wikitool
|
||||
- operates-on: Chemenu
|
||||
sources: [Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: sourced
|
||||
summary: 'Muster fuer eine Datei, die eine Instanz ueber ihre Umgebung informiert, ohne Betriebsvoraussetzung zu sein: Health-Check meldet ohne zu scheitern, pro Checkout statt pro Repo'
|
||||
---
|
||||
# Optional Instance Context File
|
||||
|
||||
**Typ:** Architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Eine **Optional Instance Context File** ist eine Datei, die eine Instanz über ihre eigene
|
||||
Umgebung informiert, ohne Betriebsvoraussetzung zu sein: sie erspart einer Sitzung Fragen, deren
|
||||
Antworten sich selten ändern, und ihr Fehlen kostet Zeit, aber keine Korrektheit.
|
||||
|
||||
Das Muster ist die schwächere Schwester der [[Personalization Plane]]. Beide liefern ein
|
||||
Template aus, beide füllen es in einem Setup-Schritt, beide prüfen das Ergebnis mit einem
|
||||
Health-Check. Der Unterschied liegt darin, was der Check tut, wenn die Datei fehlt — und dieser
|
||||
eine Unterschied entscheidet, ob „optional" hält oder nur behauptet ist.
|
||||
|
||||
Erste Umsetzung: [[ENVIRONMENT.md]] in [[Chemenu]], Stack-Version `1.8.0`[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Der Health-Check meldet, aber scheitert nie.** Eine fehlende Datei ergibt `OK` mit dem
|
||||
Vermerk „absent (optional)", kein `FAIL`. Ein `FAIL` würde die Datei durch die Hintertür
|
||||
verpflichtend machen und damit die Eigenschaft aufheben, um derentwillen sie entworfen wurde.
|
||||
Der Preis ihres Fehlens sind ein paar Fragen, keine falsche Ausgabe — und ein Check, der
|
||||
darauf rot wird, sortiert die beiden Kosten falsch ein.
|
||||
- **Genau ein Zustand ist meldenswert, und zwar als `WARN`:** ein umbenanntes, nie ausgefülltes
|
||||
Template. Diese Datei ist vorhanden, wird in jeder Sitzung mitgeladen und beantwortet nichts —
|
||||
schlechter als Abwesenheit, weil Abwesenheit ehrlich ist. Eine reine Existenzprüfung würde sie
|
||||
durchwinken; erkennbar wird sie über einen Sentinel im Template.
|
||||
- **Pro Checkout, nicht pro Repo.** Was hier steht, gilt einer Arbeitskopie: zwei Clones
|
||||
desselben Repos sind zwei Umgebungen. Deshalb ist die Datei gitignored, und deshalb ist eine
|
||||
committete Fassung schädlicher als gar keine — sie gibt dem zweiten Clone Antworten, die
|
||||
falsch sind statt zu fehlen, und eine falsche Angabe wird geglaubt.
|
||||
- **Das Ignore-Muster muss die Datei von ihrem Template trennen.** Das naheliegende
|
||||
`<Name>.md*` schluckt beides und nimmt der Distribution die Vorlage. Der Ausschluss gehört
|
||||
verankert und in beide Richtungen geprüft: die Datei muss ignoriert sein, das Template darf es
|
||||
nicht.
|
||||
- **Kontext, keine Autorität.** Die Datei beschreibt, was vorhanden ist, nicht, was erlaubt ist.
|
||||
Ein aufgeführter Remote autorisiert keinen Push an den Gates vorbei, ein aufgeführter Dienst
|
||||
öffnet kein Gate, und nichts darin ist eine Quelle für einen Wiki-Eintrag. Zugangsdaten
|
||||
gehören nicht hinein: die Datei liegt im Klartext und geht in jeden Agenten-Kontext.
|
||||
- **Raten ist schlimmer als Lücken lassen.** Der Setup-Schritt trägt ein, was aus dem Checkout
|
||||
ablesbar ist, fragt einmal nach dem Rest und akzeptiert „weiß ich nicht" — ein leerer
|
||||
Abschnitt wird gelöscht, nicht mit Plausiblem gefüllt. Eine geratene Zeile kostet mehr als die
|
||||
fehlende, aus demselben Grund, aus dem die Datei nicht committet wird.
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[ENVIRONMENT.md]] — erste und bislang einzige Umsetzung: Harness, Skills, MCP-Server,
|
||||
Connectoren, Remotes, CI-Ort
|
||||
- [[wikitool]] — trägt den `environment`-Check in `doctor` und liefert das Template über
|
||||
`dist export` aus
|
||||
- [[CLAUDE.md]] — bindet die Datei als Import ein und trägt damit den Fall „Import, der legitim
|
||||
nie auflöst"
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Wenn eine Angabe drei Eigenschaften zugleich hat: sie ändert sich selten, sie wird trotzdem
|
||||
immer wieder erfragt, und ihr Fehlen macht die Arbeit langsamer statt falsch. Dann lohnt eine
|
||||
Datei, und dann darf sie optional sein.
|
||||
|
||||
Das Muster verlangt vier Dinge, die zusammengehören: ein ausgeliefertes Template, einen
|
||||
Setup-Schritt, der es anbietet statt es zu verlangen, einen Health-Check, der meldet ohne zu
|
||||
scheitern, und einen mechanisch geprüften Ausschluss aus der Versionskontrolle. Fehlt der
|
||||
Check, verrottet die Datei unbemerkt; fehlt der geprüfte Ausschluss, wandert eine Arbeitskopie
|
||||
in das Repo aller anderen.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- **Für Betriebsvoraussetzungen.** Was eine Instanz zum Funktionieren braucht, gehört in die
|
||||
[[Personalization Plane]] oder in einen echten `FAIL`. „Optional" ist eine Aussage über die
|
||||
Folgen des Fehlens, keine Höflichkeitsform.
|
||||
- **Für Angaben, die eine Maschine ermitteln kann.** `git remote -v` beantwortet sich selbst;
|
||||
aufgeschrieben wird, was sonst erfragt würde, nicht was ohnehin abrufbar ist. Ein
|
||||
aufgeschriebener Wert, den ein Kommando widerlegen kann, ist eine Kopie, die driftet.
|
||||
- **Für Regeln.** Wer Normatives hineinschreibt, erzeugt die zweite Kopie, die Invariante 8 von
|
||||
[[AGENTS.md]] verbietet.
|
||||
- **Für Geheimnisse.** Tokens und Passwörter gehören in die Shell-Konfiguration, nicht in eine
|
||||
Datei, die jede Sitzung mitliest.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[KB Stack Versioning]] — das Muster kam mit `1.8.0`, ohne Kompatibilitätsbruch
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]: [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[ENVIRONMENT.md]]
|
||||
- **contrasts:** [[Personalization Plane]]
|
||||
- **mechanism:** [[wikitool]]
|
||||
- **operates-on:** [[Chemenu]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related:
|
||||
- mechanism: wikitool
|
||||
- operates-on: Chemenu
|
||||
- see-also: Optional Instance Context File
|
||||
sources: [Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: sourced
|
||||
summary: 'Schicht fuer Instanz-Identitaet: USER.md/SOUL.md werden als Template ausgeliefert, im Setup-Interview woertlich befuellt und vom doctor-Check auf fehlend wie unbefuellt geprueft'
|
||||
---
|
||||
# Personalization Plane
|
||||
|
||||
**Typ:** Architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Die Personalization Plane ist die Schicht eines verteilbaren Agenten-Stacks, die festhält, **wer
|
||||
eine Instanz bedient** und **wie sie klingt** - in `USER.md` und `SOUL.md` im Repo-Wurzelverzeichnis.
|
||||
Sie löst einen Zielkonflikt, der bei jeder verteilbaren Software mit persönlicher Konfiguration
|
||||
auftritt: die beiden Dateien sind Betriebsvoraussetzung und werden in jeder Sitzung gelesen,
|
||||
ihr Inhalt gehört aber genau einer Person und darf nicht in jede exportierte Kopie.
|
||||
|
||||
Die Auflösung ist nicht „ausliefern oder nicht", sondern eine Dreiteilung: die Distribution
|
||||
trägt `USER.md.template` und `SOUL.md.template`, die Installation befüllt sie im Interview, und
|
||||
ein Health-Check prüft beides. In [[Chemenu]] eingeführt mit Stack-Version `1.1.0`.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Template statt Inhalt.** Ausgeliefert werden nur die `.template`-Dateien. Dass die
|
||||
befüllten Fassungen nicht mitgehen, ist keine zusätzliche Regel, sondern Folge der
|
||||
bestehenden Root-Allowlist in `dist_cmd.py`: kopiert wird, was dort namentlich steht.
|
||||
- **Sentinel statt Existenzprüfung.** Jedes Template trägt eine Zeile mit dem Token
|
||||
`wikitool:template-unfilled`. Damit lässt sich „umbenannt" von „ausgefüllt" unterscheiden -
|
||||
eine reine Existenzprüfung würde eine Datei durchwinken, die vorhanden ist und nichts
|
||||
beantwortet.
|
||||
- **Interview statt Ableitung.** Der Installationsschritt befragt den Nutzer entlang der
|
||||
Template-Abschnitte und schreibt die Antworten wörtlich mit. Zwei Angaben darf ein Agent
|
||||
nicht raten: den Persona-Namen und die Themen, die bewusst draußen bleiben.
|
||||
- **Keine neue Autorität.** `USER.md` ist Kontext über den Nutzer, keine Instruktionsquelle;
|
||||
`SOUL.md` bestimmt nur Ton und Stimme und verliert gegen [[AGENTS.md]], die Contracts, Gates
|
||||
und Schemas. Eine Nutzeraussage ist keine Quelle und wandert nie ohne den normalen
|
||||
Quelle/Provenance/Confidence-Prozess nach `kb/`.
|
||||
- **Durchsetzung über den Health-Check.** `wikitool doctor` meldet `personalization: FAIL` bei
|
||||
fehlender Datei und bei einer, die noch den Sentinel trägt.
|
||||
- **Persona als Instanz-Eigenschaft.** Die Persona von [[Chemenu]] heißt **Thoth**,
|
||||
passend zur ägyptischen Namensgebung des Stacks selbst. Der Name ist eine
|
||||
Nutzerentscheidung, keine Vorgabe des Stacks: das Template schlägt keinen vor.
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[Chemenu]] - erste Instanz mit befüllter Personalization Plane, Persona Thoth
|
||||
- [[wikitool]] - liefert die Templates über `dist export` aus und prüft sie über `doctor`
|
||||
- [[AGENTS.md]] - Abschnitt „Personalization"; die Kontrollebene behält den Vorrang
|
||||
- [[CLAUDE.md]] - importiert beide Dateien, damit sie unter Claude Code überhaupt geladen werden
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Wenn eine Datei gleichzeitig Betriebsvoraussetzung und persönlicher Inhalt ist. Das Muster
|
||||
verlangt drei Dinge, die zusammengehören: ein ausgeliefertes Template, einen
|
||||
Installationsschritt, der es befüllt, und einen mechanischen Check, der beide Fehlerfälle
|
||||
trennt. Fehlt der Check, ist der Installationsschritt eine Bitte; fehlt das Template, muss die
|
||||
Installation die Struktur raten.
|
||||
|
||||
Der Ansatz ist zugleich das Gegenmodell zu einer Instanz-Aktion als Migration: eine offene
|
||||
Personalization ist keine Korpus-Änderung und gehört nicht in die Kette aus [[KB Migration]],
|
||||
sondern in den Health-Check.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Für Angaben, die eine Maschine ermitteln kann. Autor-Identität kommt aus `git config`, nicht
|
||||
aus einem Interview.
|
||||
- Für Regeln. Wer Normatives in `SOUL.md` schreibt, erzeugt die zweite Kopie, die Invariante 8
|
||||
verbietet; Regeln stehen in [[AGENTS.md]] und den Contracts.
|
||||
- Für Wissen. Was der Nutzer im Interview sagt, ist Kontext, keine belegte Aussage - es
|
||||
begründet keinen Eintrag in `kb/`.
|
||||
- Für harness-spezifische Dateien. Eine Instanz, die ein bestimmtes Harness nicht benutzt,
|
||||
braucht dessen Konfiguration nicht, und ein `FAIL` dafür wäre falsch.
|
||||
- Für Angaben, deren Fehlen nur Zeit kostet. Wo ein `FAIL` unangemessen wäre, weil die Datei
|
||||
eine Sitzung beschleunigt statt sie zu ermöglichen, greift das schwächere Muster
|
||||
[[Optional Instance Context File]][^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31].
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[KB Migration]] - Abgrenzung: dort Korpus-Form, hier Instanz-Zustand
|
||||
- Optional Instance Context File - dasselbe Muster ohne Pflicht: dort meldet der
|
||||
Health-Check nur, hier scheitert er[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]
|
||||
- [[KB Stack Versioning]] - die Plane kam mit `1.1.0`, ohne Kompatibilitätsbruch
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]: [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[wikitool]]
|
||||
- **operates-on:** [[Chemenu]]
|
||||
- **see-also:** [[Optional Instance Context File]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- part-of: Consolidation Tiers
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Langlebigste Speicherschicht für Abläufe, Muster, bewährte Vorgehensweisen und Rezepte, gewonnen aus wiederholten semantischen Beobachtungen.
|
||||
---
|
||||
# Procedural Memory
|
||||
|
||||
**Typ:** architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Höchste Konfidenz und am stärksten komprimiert der Tiers; wird langsam aktualisiert, wenn neue Muster entstehen, und informiert automatisierte Entscheidungsfindung.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Consolidation Tiers]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,121 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [ai, retrieval, generation, knowledge-management]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- see-also: LLM Wiki Pattern
|
||||
- see-also: NotebookLM
|
||||
- see-also: ChatGPT
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Architekturmuster, bei dem LLMs die Generierung um Dokumente aus einer Wissensbasis anreichern.
|
||||
---
|
||||
# RAG
|
||||
|
||||
**Typ:** Architecture (Retrieval Augmented Generation)
|
||||
|
||||
## Definition
|
||||
|
||||
RAG (Retrieval Augmented Generation) ist ein KI-Architekturmuster, bei dem ein großes Sprachmodell (LLM) relevante Informationen aus einer Knowledge Base abruft, bevor es eine Antwort generiert. Dies ermöglicht dem LLM, Antworten bereitzustellen, die in externen Dokumenten verankert sind, anstatt sich ausschließlich auf seine Trainingsdaten zu verlassen.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Wie RAG funktioniert
|
||||
|
||||
1. **Indexierung**: Dokumente werden verarbeitet und für die Suche indexiert
|
||||
2. **Abruf**: Bei jeder Abfrage werden relevante Chunks aus dem Index abgerufen
|
||||
3. **Augmentation**: Abgerufene Chunks werden zum LLM-Kontext/Prompt hinzugefügt
|
||||
4. **Generierung**: LLM generiert eine Antwort basierend auf seinem Wissen und den abgerufenen Chunks
|
||||
|
||||
### Traditionelle RAG-Systeme
|
||||
|
||||
Beispiele sind:
|
||||
- [[NotebookLM]] (Google)
|
||||
- [[ChatGPT]] Datei-Uploads (OpenAI)
|
||||
- Die meisten kommerziellen RAG-Implementierungen
|
||||
|
||||
### Begrenzungen von traditionellem RAG
|
||||
|
||||
Laut dem [[LLM Wiki Pattern]]-Artikel:
|
||||
|
||||
1. **Keine Knowledge Accumulation**: Wissen wird bei jeder Abfrage von Grund auf neu abgeleitet
|
||||
2. **Keine persistente Synthese**: Verbindungen zwischen Dokumenten werden nicht aufrechterhalten
|
||||
3. **Keine Querverweise**: Keine expliziten Links zwischen verwandten Konzepten über Quellen hinweg
|
||||
4. **Keine Widerspruchserkennung**: Konfliktinformationen werden nicht gekennzeichnet
|
||||
5. **Kein Compounding**: Das Hinzufügen neuer Quellen baut nicht auf vorherigem Verständnis auf
|
||||
6. **Ineffizient für komplexe Abfragen**: Subtile Fragen, die eine Synthese mehrerer Dokumente erfordern, müssen jedes Mal neu abgeleitet werden
|
||||
|
||||
### Wann RAG geeignet ist
|
||||
|
||||
- Bei einfachen, einmaligen Fragen
|
||||
- Für schnelle Informationssuche
|
||||
- Wenn Persistenz und Compounding nicht erforderlich sind
|
||||
- Wenn der Aufwand für Wiki-Wartung nicht gerechtfertigt ist
|
||||
|
||||
### Wann über RAG hinausgehen
|
||||
|
||||
Das [[LLM Wiki Pattern]] in Betracht ziehen, wenn:
|
||||
- Wissen im Laufe der Zeit angesammelt werden soll
|
||||
- Persistente Querverweise benötigt werden
|
||||
- Widersprüche zwischen Quellen gekennzeichnet werden sollen
|
||||
- Wissen benötigt wird, das zusammengesetzt wird, wenn neue Quellen hinzugefügt werden
|
||||
- Komplexe Abfragen, die Multi-Dokument-Synthese erfordern, häufig vorkommen
|
||||
|
||||
## RAG vs. LLM-Wiki-Pattern
|
||||
|
||||
| Aspekt | RAG | LLM-Wiki-Pattern |
|
||||
|--------|-----|-------------------|
|
||||
| Knowledge Accumulation | Nein | Ja |
|
||||
| Persistente Querverweise | Nein | Ja |
|
||||
| Widerspruchserkennung | Nein | Ja |
|
||||
| Knowledge Compounding | Nein | Ja |
|
||||
| Wartung | Automatisch | LLM-gepflegt |
|
||||
| Abfrage-Geschwindigkeit | Schnell | Schnell (nach Kompilierung) |
|
||||
| Setup-Komplexität | Niedrig | Mittel |
|
||||
| Am besten für | Einmalige Abfragen | Laufende Knowledge Accumulation |
|
||||
|
||||
## Implementierungen
|
||||
|
||||
### RAG-Varianten
|
||||
- Naive RAG: Einfache Ähnlichkeitssuche
|
||||
- Vector RAG: Embedding-basierter Abruf
|
||||
- Hybrid RAG: Kombiniert Schlüsselwort- und Vector-Suche
|
||||
- Graph RAG: Verwendet Knowledge Graphs für Abruf
|
||||
|
||||
### LLM-Wiki-Pattern als verbessertes RAG
|
||||
Das [[LLM Wiki Pattern]] kann als eine Verbesserung zu RAG angesehen werden, die hinzufügt:
|
||||
- Persistenz-Schicht (das Wiki)
|
||||
- Automatische Querverweise
|
||||
- Widerspruchserkennung
|
||||
- Knowledge Compounding
|
||||
- Menschliche Kuratierung in der Schleife
|
||||
|
||||
## Tools, die RAG verwenden
|
||||
|
||||
- [[NotebookLM]]
|
||||
- [[ChatGPT]] (mit Datei-Uploads)
|
||||
- Viele unternehmensweite Knowledge-Management-Systeme
|
||||
- Verschiedene Open-Source-RAG-Frameworks (LangChain, LlamaIndex, etc.)
|
||||
|
||||
## Geschichte
|
||||
|
||||
- [2020] - Frühe RAG-Papers und -Implementierungen
|
||||
- [2023] - Kommerzielle RAG-Systeme entstehen (NotebookLM, ChatGPT Datei-Uploads)
|
||||
- [2023-2024] - LLM-Wiki-Pattern entwickelt als Verbesserung zu RAG
|
||||
- [2026-07-26] - Konzeptseite erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Knowledge Compounding]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[NotebookLM]]
|
||||
- **see-also:** [[ChatGPT]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [scale, limitations]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related:
|
||||
- see-also: Token Economics
|
||||
- see-also: Cross-platform Agent Skills
|
||||
- see-also: Context Isolation
|
||||
sources: [Source - Copilot Skill Restructure Instructions]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Punkt, ab dem Wiki-Ansätze mit einem einzigen Kontext qualitativ abfallen
|
||||
---
|
||||
# Scale Ceiling
|
||||
|
||||
**Typ:** architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Scale Ceiling ist der Punkt, an dem Single-Context-Wiki-Ansätze (eine große Anweisungsdatei, vollständiger Index wird jede Sitzung neu gelesen) an Qualität degradieren, typischerweise sobald ein Wiki etwa 100-200 Seiten überschreitet[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Qualitätsverschlechterung**: Mit wachsendem Wiki verlieren LLMs Verbindungen und die Qualität sinkt mit Single-Context-Ansätzen[^s-copilot-skill-restructure-instructions]
|
||||
- **Schwellenwert**: Evidenz deutet darauf hin, dass die Verschlechterung um die 100-200 Seiten beginnt[^s-copilot-skill-restructure-instructions]
|
||||
- **Symptom**: Das LLM verliert Verbindungen zwischen verwandten Informationen
|
||||
- **Lösung**: Zu kontextisoliert, Skill-basierten Ansätzen übergehen
|
||||
|
||||
## Beispiele
|
||||
|
||||
- Dokumentierter Fall: RTFM/Retrieval-Layer-Ansatz bei einem 8.260-Datei-Corpus erreichte 100% Erfolgsquote (von ~55-64%) durch Bereitstellung von Metadaten zuerst und Erweiterung nur das Notwendige[^s-copilot-skill-restructure-instructions]
|
||||
- Das Chemenu-Repository nähert sich dem Scale Ceiling mit monolithischer AGENTS.md[^s-copilot-skill-restructure-instructions]
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Scale Ceiling beachten, wenn:
|
||||
- Das Wiki sich 100 Seiten nähert oder überschreitet
|
||||
- Das LLM Verbindungen zwischen verwandtem Inhalt vermisst
|
||||
- Die Abfragequalität inkonsistent oder verschlechtert ist
|
||||
- Für langfristiges Wiki-Wachstum geplant wird
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
Scale Ceiling ist kein Problem wenn:
|
||||
- Das Wiki klein ist und klein bleiben soll
|
||||
- Retrieval-Augmented-Ansätze genutzt werden, die alles in den Kontext laden vermeiden
|
||||
- Die Workflows kein Verständnis von Verbindungen über das gesamte Wiki erfordern
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Token Economics]]
|
||||
- **see-also:** [[Cross-platform Agent Skills]]
|
||||
- **see-also:** [[Context Isolation]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- part-of: Consolidation Tiers
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Langlebige Schicht für sitzungsübergreifend verdichtete Fakten aus mehreren Episoden, mit höherer Konfidenz und stärkerer Verdichtung als episodische Erinnerungen.
|
||||
---
|
||||
# Semantic Memory
|
||||
|
||||
**Typ:** architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Ergebnisse der Konsolidierung wiederholter Beobachtungen über Sitzungen hinweg; verwendet um das Reasoning zu unterstützen und dient als Grundlage für die Muster-Extraktion in prozeduralem Gedächtnis.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Consolidation Tiers]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,274 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [llm-wiki, layers, structure]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- see-also: LLM Wiki Pattern
|
||||
- contrasts: RAG
|
||||
- composition: Memory Lifecycle
|
||||
- composition: Knowledge Graph
|
||||
sources: [Source - LLM Wiki Pattern, Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: "Strukturmodell des LLM-Wiki-Musters mit drei Schichten: unver\xE4nderliche Rohquellen, vom LLM gepflegtes Wiki und Schemakonfiguration, die Knowledge Compounding tr\xE4gt."
|
||||
---
|
||||
# Three-Layer Architecture
|
||||
|
||||
**Typ:** Architecture (Foundation of LLM Wiki Pattern)
|
||||
|
||||
## Definition
|
||||
|
||||
Die Three-Layer Architecture ist die strukturelle Grundlage des [[LLM Wiki Pattern]], bestehend aus drei unterschiedlichen Schichten: Rohquellen, Das Wiki und Das Schema. Jede Schicht hat eine spezifische Rolle und behält Separation of Concerns bei um die Wissens-Kompoundierungs-Effekte des Patterns zu ermöglichen.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Schicht 1: Rohquellen
|
||||
|
||||
**Zweck:** Unveränderliche Quelle der Wahrheit
|
||||
|
||||
**Merkmale:**
|
||||
- Kuratierte Sammlung von Quelldokumenten
|
||||
- Read-only aus der Perspektive des LLM
|
||||
- Enthält: Artikel, Papiere, Bilder, Datendateien, Notizen, Spezifikationen
|
||||
- **Niemals verändert** durch das LLM
|
||||
- Human-verwaltet: Benutzer fügt Quellen hinzu und organisiert sie
|
||||
|
||||
**Verzeichnis:** `raw/`
|
||||
|
||||
**Unterverzeichnisse:**
|
||||
- `raw/articles/` — Web-Artikel, Blog-Beiträge
|
||||
- `raw/documents/` — PDFs, Spezifikationen, Handbücher
|
||||
- `raw/notes/` — Persönliche Notizen, Besprechungstranskriptionen
|
||||
- `raw/assets/` — Bilder, Diagramme, Binärdateien
|
||||
|
||||
**Begründung:**
|
||||
- Erhält Originalmaterial der Quelle
|
||||
- Stellt Audit-Trail zurück zu primären Quellen bereit
|
||||
- Ermöglicht Neuverarbeitung, wenn nötig
|
||||
- Benutzer behält Kontrolle über Quellenauswahl
|
||||
|
||||
---
|
||||
|
||||
### Schicht 2: Das Wiki
|
||||
|
||||
**Zweck:** LLM-gepflegte Wissens-Synthese
|
||||
|
||||
**Merkmale:**
|
||||
- Verzeichnis von LLM-generierten Markdown-Dateien
|
||||
- **Vollständig besessen und gepflegt durch das LLM**
|
||||
- Human liest es; LLM schreibt es
|
||||
- Enthält: Zusammenfassungen, Entity-Seiten, Concept-Seiten, Vergleiche, Index, Log
|
||||
- Dynamisch aktualisiert, während neue Quellen ingested werden
|
||||
|
||||
**Verzeichnis:** `kb/`
|
||||
|
||||
**Collections:** Ein Verzeichnis unter `kb/` ist eine Collection genau dann, wenn es eine
|
||||
`COLLECTION.md` trägt; ein Unterverzeichnis darin ist ein Bereich, der sie erbt.
|
||||
|
||||
- `kb/entities/` — Entity-Seiten (Projekte, Systeme, Tools, Technologien, Personen)
|
||||
- `kb/concepts/` — Concept-Seiten (Architekturen, Patterns, Protokolle, Workflows)
|
||||
- `kb/sources/` — Zusammenfassungen von ingested Quellen
|
||||
- `kb/comparisons/` — Vergleichstabellen und Analysen
|
||||
- `kb/CONTRACT.md` — Regeln, die von jeder Collection geteilt werden
|
||||
- `kb/index.md` — Katalog aller Seiten
|
||||
- `kb/log.md` — Chronologisches Audit-Log
|
||||
|
||||
In diesem Repository wurde die Wiki-Schicht am 2026-08-21 von `wiki/` zu `kb/` umbenannt, wenn jedes
|
||||
seiner Unterverzeichnisse zu einer First-Class-Collection mit eigenem Contract befördert wurde. Eine vierte
|
||||
Phase, `reports/`, hält generierten Lint-Output außerhalb des Knowledge-Baums und ist gitignoriert.
|
||||
|
||||
**Seitentypen:**
|
||||
- **Source-Seiten**: Zusammenfassungen mit Metadaten, Kernpunkte, Aufgaben
|
||||
- **Entity-Seiten**: Strukturierte Informationen über spezifische Elemente
|
||||
- **Concept-Seiten**: Definitionen, Beispiele, wann zu verwenden
|
||||
- **Vergleichs-Seiten**: Nebeneinander-Analyse
|
||||
- **Index**: Content-oriented Katalog
|
||||
- **Log**: Chronologischer Betriebsdatensatz
|
||||
|
||||
**Begründung:**
|
||||
- Trennt synthetisiertes Wissen von Rohquellen
|
||||
- Ermöglicht Querverweise und Verbindungen
|
||||
- Erlaubt LLM Konsistenz zu wahren
|
||||
- Bietet Mensch-lesbare Struktur
|
||||
|
||||
---
|
||||
|
||||
### Schicht 3: Das Schema
|
||||
|
||||
**Zweck:** Konfiguration und Betriebsanweisungen für das LLM
|
||||
|
||||
**Merkmale:**
|
||||
- Definiert wie das Wiki strukturiert ist
|
||||
- Dokumentiert Konventionen und Seitenformate
|
||||
- Spezifiziert Workflows (Ingest, Abfrage, Lint)
|
||||
- **Co-entwickelt** durch Mensch und LLM über Zeit
|
||||
- Normalerweise eine einzelne Konfigurationsdatei
|
||||
|
||||
**Datei:** `AGENTS.md` (oder `CLAUDE.md` für Claude Code)
|
||||
|
||||
**Inhalt:**
|
||||
- Verzeichnis-Struktur-Definitionen
|
||||
- Seitenformat-Templates
|
||||
- Workflow-Beschreibungen
|
||||
- Namenskonventionen
|
||||
- Qualitätsstandards
|
||||
- Wartungsplanung
|
||||
- Benutzereinstellungen
|
||||
|
||||
**Begründung:**
|
||||
- Macht LLM zu disziplinertem Wiki-Verwalter statt generischem Chatbot
|
||||
- Mensch und LLM arbeiten zusammen bei Schema-Entwicklung
|
||||
- Stellt Konsistenz über Sessions sicher
|
||||
- Dokumentiert das System für zukünftige Referenz
|
||||
|
||||
---
|
||||
|
||||
## Architekturdiagramm
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ THREE-LAYER ARCHITECTURE │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ ┌─────────────────┐ ┌─────────────────┐ ┌───────────┐ │
|
||||
│ │ LAYER 1: │ │ LAYER 2: │ │ LAYER 3: │ │
|
||||
│ │ Raw Sources │───▶│ The Wiki │◀───│ The │ │
|
||||
│ │ │ │ │ │ Schema │ │
|
||||
│ │ - Immutable │ │ - LLM-maintained│ │ │ │
|
||||
│ │ - Human-curated│ │ - Dynamic │ │ - Config │ │
|
||||
│ │ - Source truth │ │ - Synthesized │ │ - Workflows││
|
||||
│ └─────────────────┘ └─────────────────┘ └───────────┘ │
|
||||
│ │
|
||||
│ User ↔ AGENTS.md (Layer 3) ↔ LLM ↔ Wiki (Layer 2) ← Raw (Layer 1)│
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Datenfluss
|
||||
|
||||
### Ingest-Ablauf
|
||||
```
|
||||
User adds file to raw/
|
||||
↓
|
||||
LLM reads source (Layer 1)
|
||||
↓
|
||||
LLM follows AGENTS.md instructions (Layer 3)
|
||||
↓
|
||||
LLM creates/updates pages in kb/ (Layer 2)
|
||||
↓
|
||||
LLM updates index.md and log.md
|
||||
```
|
||||
|
||||
### Abfrage-Ablauf
|
||||
```
|
||||
User asks question
|
||||
↓
|
||||
LLM reads index.md (Layer 2) to find relevant pages
|
||||
↓
|
||||
LLM reads relevant wiki pages (Layer 2)
|
||||
↓
|
||||
LLM follows cross-references
|
||||
↓
|
||||
LLM synthesizes answer with citations
|
||||
↓
|
||||
Valuable answers filed back into kb/ (Layer 2)
|
||||
```
|
||||
|
||||
## Vorteile dieser Architektur
|
||||
|
||||
### Separation of Concerns
|
||||
- **Rohquellen**: Human-Verantwortung (Kurationen, Organisation)
|
||||
- **Das Wiki**: LLM-Verantwortung (Wartung, Querverweise)
|
||||
- **Das Schema**: Gemeinsame Verantwortung (Entwicklung, Verfeinerung)
|
||||
|
||||
### Ermöglicht Wissens-Compounding
|
||||
- Rohquellen bleiben stabil für Neuverarbeitung
|
||||
- Wiki wächst und verbindet sich ohne Quellen zu ändern
|
||||
- Schema verbessert sich, wenn Mensch und LLM lernen, was funktioniert
|
||||
|
||||
### Wartbarkeit
|
||||
- Klare Grenzen zwischen Schichten
|
||||
- Jede Schicht kann sich unabhängig entwickeln
|
||||
- Einfach zu debuggen und zu verstehen
|
||||
|
||||
### Flexibilität
|
||||
- Funktioniert mit jedem LLM-Agent (Claude, Codex, etc.)
|
||||
- Anpassbar an verschiedene Domänen
|
||||
- Modulare Komponenten können ausgetauscht werden
|
||||
|
||||
## Vergleich mit anderen Architekturen
|
||||
|
||||
| Feature | Three-Layer | Traditional RAG | Simple Wiki | Database |
|
||||
|---------|-------------|----------------|-------------|----------|
|
||||
| Persistenz | Ja | Nein | Ja | Ja |
|
||||
| Automatisierung | LLM | LLM | Manuell | Manuell |
|
||||
| Querverweise | Automatisch | Nein | Manuell | Manuell |
|
||||
| Quellen-Trennung | Ja | Teilweise | Variiert | Nein |
|
||||
| Skalierbarkeit | Hoch | Mittel | Niedrig | Hoch |
|
||||
|
||||
## Implementierungshinweise
|
||||
|
||||
### Für dieses Wiki
|
||||
- **Schicht 1**: `raw/` Verzeichnis mit Artikeln, Notizen, usw.
|
||||
- **Schicht 2**: `kb/` Verzeichnis mit allen generierten Inhalten
|
||||
- **Schicht 3**: `AGENTS.md` am Repository-Root
|
||||
|
||||
### Anpassung an andere Domänen
|
||||
- Modifiziere Schema (Schicht 3) um Domänen-Konventionen zu erfüllen
|
||||
- Passe Entity/Concept-Typen im Wiki an (Schicht 2)
|
||||
- Quellen-Schicht (Schicht 1) bleibt weitgehend gleich
|
||||
|
||||
## V2-Erweiterungen
|
||||
|
||||
Die ursprüngliche Three-Layer Architecture bleibt die Grundlage. [[Source - LLM Wiki v2]] (siehe [[Source - LLM Wiki v2]]) addiert zusätzliche Schichten und Erweiterungen, die auf dieser Grundlage aufbauen:
|
||||
|
||||
### Zusätzliche Schichten
|
||||
|
||||
**Schicht 4: Knowledge Graph** (Optional)
|
||||
- Strukturierte Darstellung von Entities und Beziehungen
|
||||
- Erweitert Schicht 2 (Das Wiki) mit Maschinen-lesbarer Struktur
|
||||
- Ermöglicht Graph-Traversal-Abfragen
|
||||
- Siehe: [[Knowledge Graph]]
|
||||
|
||||
**Schicht 5: Memory Tiers** (Optional)
|
||||
- Working Memory, Episodic Memory, Semantic Memory, Procedural Memory
|
||||
- Gestaffelte Speicherung mit verschiedenen Aufbewahrung und Zugriffsmuster
|
||||
- Siehe: [[Consolidation Tiers]], [[Memory Lifecycle]]
|
||||
|
||||
### Erweiterte Schichten
|
||||
|
||||
**Erweiterte Schicht 2 (Das Wiki):**
|
||||
- Kann nun Vertrauens-Scores für Fakten enthalten (siehe [[Confidence Scoring]])
|
||||
- Unterstützt Supersession-Beziehungen (siehe [[Supersession]])
|
||||
- Implementiert Vergessen/Aufbewahrung-Kurven (siehe [[Forgetting]])
|
||||
|
||||
**Erweiterte Schicht 3 (Das Schema):**
|
||||
- Kann Hooks und Automatisierungs-Regeln definieren (siehe [[Event-Driven Automation]], [[Hooks]])
|
||||
- Kann Qualitäts-Standards und Scoring spezifizieren (siehe [[Quality and Self-Correction]])
|
||||
- Kann Datenschutz- und Governance-Richtlinien konfigurieren (siehe [[Privacy and Governance]])
|
||||
|
||||
Die Three-Layer Architecture bleibt gültig und ausreichend für viele Anwendungsfälle. Die v2-Erweiterungen sind optionale Verbesserungen, die nach Bedarf übernommen werden können (siehe [[Implementation Spectrum]]).
|
||||
|
||||
## Geschichte
|
||||
|
||||
- [1945] - Vannevar Bushs [[Memex]]-Konzept deutet auf gestaffelte Wissensverwaltung hin
|
||||
- [2023-2024] - LLM Wiki Pattern formalisiert Three-Layer Architecture
|
||||
- [2026-07-26] - Concept-Seite erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- AGENTS.md
|
||||
- [[Knowledge Compounding]]
|
||||
- [[Implementation Spectrum]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[LLM Wiki Pattern]]
|
||||
- **contrasts:** [[RAG]]
|
||||
- **composition:** [[Memory Lifecycle]]
|
||||
- **composition:** [[Knowledge Graph]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [tokens, cost, efficiency]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related:
|
||||
- see-also: Cross-platform Agent Skills
|
||||
- see-also: Scale Ceiling
|
||||
- see-also: Context Isolation
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
|
||||
confidence: 0.60
|
||||
confidence_base: 0.60
|
||||
provenance: mixed
|
||||
summary: Kosten- und Effizienzüberlegungen zum Tokenverbrauch von LLMs - die genannten Werte 5-8x/61%/100% sind unbestätigt, keine gesicherten Fakten
|
||||
---
|
||||
# Token Economics
|
||||
|
||||
**Typ:** architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Token Economics bezieht sich auf Kosten- und Effizienzüberlegungen zur Nutzung des LLM-Kontextfensters, insbesondere darauf, wie die Menge der geladenen Anweisungen und des Kontexts Leistung, Kosten und Qualität beeinflusst[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Kostenmultiplikator:** Eine vollständige Aufnahme gegen ein kompiliertes Wiki liest mehr Token als eine Abfrage, weil die Aufnahme viele Seiten berührt, während eine Abfrage normalerweise nur eine Handvoll liest - dies ist grundsätzlich korrekt, aber die spezifische „~5-8x die Quellen-Token-Anzahl"-Zahl aus der Anweisungsmenge, die dieses Konzept einführte, hat **keine auffindbaren Quelle** und sollte nicht als Fakt wiederholt werden[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- **Abfrage-Effizienz**: Eine Abfrage gegen nur einen Index plus 2-4 Seiten kostet einen Bruchteil der vollständigen Aufnahmekosten[^s-copilot-skill-restructure-instructions]
|
||||
- **Monolithischer Overhead**: Das Laden eines vollständigen Anweisungssatzes (wie AGENTS.md) bei jedem Task zahlt auch für einfache Abfragen den höheren Preis[^s-copilot-skill-restructure-instructions]
|
||||
- **Kontextisolations-Vorteil**: Diskrete Skills, die nur bei Aufruf geladen werden, reduzieren die Token-Nutzung erheblich
|
||||
|
||||
## Allgemeine Hinweise (unbelegt)
|
||||
|
||||
Die „RTFM/Abruf-Schicht"-Statistik unten (61% Token-Reduktion, 100%-Lösungsquote auf einem 8.260-Datei-Korpus) konnte während der Faktenprüfung nicht auf eine auffindbaren Quelle zurückgeführt werden und sollte als illustrativer, unverifizierter Aussage statt als bestätigter Fakt behandelt werden[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
|
||||
## Beispiele
|
||||
|
||||
- Das Chemenu-Repository mit monolithischem AGENTS.md (ursprünglich ~745 Zeilen), das bei jeder Operation geladen wird - **direkt bestätigt**: 745 Zeilen, gemessen über `grep`, vollständig unabhängig von der Task angehängt, bevor es am 2026-08-04 in 5 Skills aufgeteilt wurde[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- ~~Der RTFM/Abruf-Schicht-Ansatz, der die Token-Nutzung um 61% auf einem 8.260-Datei-Korpus reduzierte~~ **unverifiziert** - keine Quelle für diese Statistik gefunden[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Token Economics in Betracht ziehen, wenn:
|
||||
- Der Anweisungssatz das Kontextfenster des LLM überschreitet
|
||||
- Sie eine Qualitätsverschlechterung bemerken, wenn das Wiki über ~100-200 Seiten wächst
|
||||
- Einfache Abfragen unverhältnismäßig lange oder kostspielig werden
|
||||
- Sie Zuständigkeiten in diskrete, unabhängig aufrufbare Vorgänge trennen können
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
Token Economics ist weniger entscheidend, wenn:
|
||||
- Das Wiki klein (<100 Seiten) ist und bequem in den Kontext passt
|
||||
- Die Workflows inhärent gekoppelt sind und nicht getrennt werden können
|
||||
- Der Entwicklungsaufwand der Kontextoptimierung die Vorteile übersteigt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]: [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Cross-platform Agent Skills]]
|
||||
- **see-also:** [[Scale Ceiling]]
|
||||
- **see-also:** [[Context Isolation]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- part-of: Consolidation Tiers
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Kurzlebige Speicherschicht für jüngste Beobachtungen und vorläufige Befunde vor der Verdichtung; niedrigste Konfidenz, keine Verdichtung, wird zum Sitzungsende erneuert.
|
||||
---
|
||||
# Working Memory
|
||||
|
||||
**Typ:** architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Die erste Stufe in der Konsolidierungs-Pipeline; speichert Rohbefunde, bevor sie mit umfassenderen Kenntnissen integriert werden, und werden automatisch am Ende der Session zu episodischem Gedächtnis heraufgestuft.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Consolidation Tiers]]
|
||||
<!-- /wikitool:links -->
|
||||
Reference in New Issue
Block a user