Karpathys LLM-Wiki: eine Wissensdatenbank locale

#LLM-Wiki: das Prinzip in zwei Minuten

Am 2. April 2026 beschreibt Andrej Karpathy auf X, wie er Sprachmodelle verwendet, um persönliche Wissensbasen aufzubauen. Zwei Tage später veröffentlicht er einen Gist mit dem Titel « LLM Wiki », den er als Muster zum Aufbau einer solchen Basis mit einem LLM vorstellt. Beide Texte sind kurz und in zehn Minuten gelesen; die Links stehen am Ende der Seite.

Das Gist geht von einer Beobachtung aus: Die meisten Anwendungen, die LLMs und Dokumente verbinden, ähneln RAG. Man legt Dateien ab, das System findet zum Zeitpunkt der Frage Auszüge, und das Modell formuliert eine Antwort. Karpathy räumt ein, dass dies funktioniert, merkt aber an, dass das Modell das Wissen bei jeder Frage neu entdeckt und sich nichts ansammelt. Eine Frage, die das Verknüpfen von fünf Dokumenten erfordert, verlangt jedes Mal, dieselben Teile wiederzufinden und zusammenzusetzen.

Das LLM Wiki verlagert die Arbeit nach vorne. Wenn eine neue Quelle hinzukommt, begnügt sich das Modell nicht damit, sie zu indexieren: Es liest sie, extrahiert das Wesentliche und integriert es in eine miteinander verknüpfte Sammlung von Markdown-Seiten. Es aktualisiert bestehende Seiten, überarbeitet Zusammenfassungen und vermerkt die Stellen, an denen die neue Quelle dem bisher Geschriebenen widerspricht. Im Gist ist von einem dauerhaften Artefakt die Rede, das mit der Zeit besser wird: Die Querverweise sind bereits erstellt, wenn die Frage gestellt wird.

Die Rollenverteilung ist im Text klar. Der Mensch wählt die Quellen aus, erkundet sie und stellt die Fragen. Das Modell erledigt alles Weitere: zusammenfassen, verknüpfen, klassifizieren, Register führen. Karpathy sagt, er arbeite auf einer Bildschirmseite mit dem offenen Agenten und auf der anderen mit Obsidian, und fasst die Einrichtung mit einem Bild zusammen: Obsidian ist die IDE, das LLM ist der Programmierer, das Wiki ist die Codebasis.

#Drei Ebenen: Quellen, Wiki, Konventionen

Das Gist beschreibt eine Architektur mit drei Ebenen. Keine davon benötigt ein spezielles Tool: Es handelt sich um Ordner und Textdateien.

Die Rohquellen

Ihre Dokumentsammlung: Artikel, Forschungsarbeiten, Bilder, Datendateien. Sie sind unveränderlich: Das Modell liest sie und verändert sie nie. Sie sind es, nicht das Wiki, die maßgeblich sind.

Das Wiki

Ein Ordner mit vom Modell verfassten Markdown-Dateien: Zusammenfassungen von Quellen, Entitätsseiten, Konzeptseiten, Vergleiche und eine Gesamtsynthese. Diese Ebene gehört zum Modell, das die Seiten erstellt, aktualisiert und die Verknüpfungen pflegt. Sie lesen, es schreibt.

Die Konventionsdatei

Ein Dokument, das dem Modell erklärt, wie das Wiki strukturiert ist, welche Regeln zu befolgen sind und wie beim Einlesen einer Quelle, beim Beantworten einer Frage oder beim Aufräumen vorzugehen ist. Das Gist verweist auf CLAUDE.md für Claude Code und AGENTS.md für Codex. Diese Datei macht aus einem Generalisten-Agenten einen disziplinierten Wiki-Maintainer.

Zwei besondere Dateien helfen dem Modell und Ihnen dabei, den Überblick zu behalten. Die erste, index.md, ist ein Katalog: Jede Seite ist dort mit einem Link und einer einzeiligen Zusammenfassung nach Kategorie aufgeführt. Um eine Frage zu beantworten, liest das Modell zuerst den Index und öffnet anschließend die relevanten Seiten. Die zweite, log.md, ist ein chronologisches Protokoll, an das nur angehängt wird: Ingestionen, Fragen und Überprüfungsdurchläufe.

Der Gist empfiehlt, jeden Protokolleintrag mit einem regelmäßigen Präfix zu beginnen, sodass er mit einfachen Unix-Werkzeugen gefiltert werden kann. Das angegebene Beispiel hat folgende Form:

## [2026-04-02] ingest | Article Title

#Drei Vorgänge: aufnehmen, abfragen, überprüfen

Ingestieren (ingest)

Sie legen eine Quelle im Ordner für Rohquellen ab und bitten das Modell, sie zu verarbeiten. Dem Gist zufolge liest es die Quelle, bespricht die wichtigsten Punkte mit Ihnen, schreibt eine Zusammenfassungsseite, aktualisiert den Index sowie die betroffenen Entitäts- und Konzeptseiten und fügt anschließend einen Eintrag zum Protokoll hinzu. Karpathy weist darauf hin, dass eine einzige Quelle 10 bis 15 Wiki-Seiten betreffen kann.

Abfragen (query)

Sie stellen eine Frage. Das Modell sucht die relevanten Seiten, liest sie und verfasst eine Antwort, die ihre Quellen zitiert. Das Gist betont einen Punkt: Eine gute Antwort kann als neue Seite im Wiki abgelegt werden, sodass sich Ihre Erkundungen ansammeln, anstatt im Verlauf eines Gesprächs zu verschwinden.

Prüfen (Lint)

Von Zeit zu Zeit bitten Sie das Modell um eine Gesundheitsprüfung des Wikis: Widersprüche zwischen Seiten, Aussagen, die durch neuere Quellen überholt sind, verwaiste Seiten ohne eingehende Links, zitierte Konzepte ohne eigene Seite und fehlende Querverweise.

Warum diese Arbeit einem Modell anvertrauen? Das Argument des Gists ist einfach: Was persönliche Wikis zugrunde richtet, ist weder das Lesen noch das Nachdenken, sondern die Pflege der Register. Verweise aktualisieren, Zusammenfassungen auf dem neuesten Stand halten, Widersprüche erfassen: Der Pflegeaufwand wächst schneller als der Wert des Wikis, und man gibt auf. Ein Modell wird nicht müde und kann fünfzehn Dateien in einem Durchgang ändern. Karpathy führt die Idee auf das von Vannevar Bush 1945 erdachte Memex zurück.

#Voraussetzungen für ein von einem lokalen Modell gepflegtes Wiki

Das Gist setzt keinen bestimmten Anbieter voraus. Es benötigt einen Agenten, der Dateien lesen und schreiben kann und von einem Modell gesteuert wird. Lokal ergibt das die folgenden Bausteine.

Ollama, aktuell

Damit wird das Modell auf http://localhost:11434 bereitgestellt. Der weiter unten verwendete Befehl ollama launch existiert nur in neueren Versionen. Die Installation wird in unserem Leitfaden „Ollama installieren“ behandelt.

Ein Agent mit Dateizugriff

Eine Chat-Oberfläche reicht nicht aus: Es wird ein Tool benötigt, das Dateien auf der Festplatte öffnet, erstellt und ändert. Das folgende Beispiel verwendet OpenCode, einen im Gist erwähnten Open-Source-Agenten im Terminal, der eine im Stammverzeichnis des Ordners abgelegte AGENTS.md-Datei liest.

Ein Modell, das Werkzeuge aufrufen kann

Das Lesen und Schreiben von Dateien erfolgt über Tool-Aufrufe. Wählen Sie ein Modell, das in der Ollama-Bibliothek die Fähigkeit tools anzeigt. Unser Leitfaden „OpenCode + Ollama“ führt mehrere auf, darunter qwen3-coder:30b, devstral-small-2:24b und gpt-oss:20b.

Speicher für den Kontext

Richtwerte in Q4_K_M nur für die Gewichte: etwa 5 GB für 7 Milliarden Parameter, 9 GB für 14 Milliarden, 19 GB für 32 Milliarden. Die Dokumentation von Ollama verlangt für Agenten mindestens 64.000 Kontext-Tokens, die zu diesen Zahlen hinzukommen.

Git

Das Wiki ist lediglich ein Ordner mit Markdown-Dateien: Der Gist weist darauf hin, dass ein Git-Repository daraus Versionshistorie liefert, ohne etwas hinzuzufügen.

Obsidian (optional)

Zum Lesen des Wikis, Folgen von Links und Anzeigen des Seitengraphen. Jeder Markdown-Editor ist geeignet; Obsidian wird nicht zum Verfassen verwendet.

#Einrichtung mit Ollama, Schritt für Schritt

Die Befehle sind für macOS und Linux geschrieben; unter Windows ist der einfachste Weg über WSL. Die Verzeichnisstruktur und die Konventionsdatei sind anzupassende Beispiele: Der Gist weist darauf hin, dass Ordnerstruktur, Konventionen und Seitenformat von Ihrer Domäne und Ihrem Modell abhängen und alles darin optional und modular ist.

1. 01
   Ordner und Repository erstellen

   Ein Verzeichnis für die Rohquellen, eines für die Seiten, ein Index und ein Protokoll, alles unter git.
2. 02
   Die Konventionsdatei schreiben

   Eine AGENTS.md im Stammverzeichnis, die die Struktur, die Schreibregeln und die drei Abläufe beschreibt: Einlesen, Fragen und Überprüfung.
3. 03
   Modell und Agent starten

   Ollama stellt ein toolfähiges Modell bereit, mit 64 000 Tokens Kontext; OpenCode wird im Wiki-Ordner geöffnet.
4. 04
   Eine erste Quelle einlesen

   Ein einziges Dokument, das vor Ihren Augen verarbeitet, erneut gelesen und anschließend in git gespeichert wird.
5. 05
   Antworten abfragen und ablegen

   Fragen werden im Wiki gestellt; nützliche Zusammenfassungen werden zu Seiten.
6. 06
   Regelmäßig überprüfen

   Ein Prüfdurchlauf, der Widersprüche, verwaiste Seiten und defekte Links auflistet.

#1. Ordner und Repository erstellen

mkdir -p ~/wiki/raw
mkdir -p ~/wiki/wiki/sources ~/wiki/wiki/entites ~/wiki/wiki/concepts
cd ~/wiki
touch wiki/index.md wiki/log.md
git init

Im Ordner raw/ werden Ihre Dokumente abgelegt, im Ordner wiki/ die vom Modell verfassten Seiten. Die Namen sind frei wählbar, solange die Trennung zwischen beiden sichtbar bleibt.

#2. Die Konventionsdatei schreiben

Das ist der wichtigste Baustein. Ohne ihn improvisiert der Agent in jeder Sitzung eine andere Struktur. Erstellen Sie im Stammverzeichnis von ~/wiki eine Datei AGENTS.md, zum Beispiel auf dieser Grundlage:

# Conventions du wiki

Tu es le mainteneur de ce wiki. Tu écris et tu mets à jour les pages.
L'humain choisit les sources et pose les questions.

## Structure
- raw/ : sources brutes. Lecture seule : ne jamais modifier, renommer ni supprimer.
- wiki/sources/ : une page de résumé par source.
- wiki/entites/ : une page par personne, organisation, outil ou produit.
- wiki/concepts/ : une page par notion.
- wiki/index.md : catalogue de toutes les pages (lien + résumé d'une ligne), par catégorie.
- wiki/log.md : journal chronologique, ajout seul.

## Règles d'écriture
- Noms de fichiers en minuscules, avec tirets, sans accents.
- Liens internes au format [[nom-de-page]].
- Chaque affirmation renvoie au fichier de raw/ dont elle vient.
- Si deux sources se contredisent, garder les deux versions et le signaler.
- Avant de créer une page, vérifier dans l'index qu'elle n'existe pas déjà.

## Ingestion
Quand on te demande d'ingérer un fichier de raw/ :
1. Lire la source en entier.
2. Présenter les points clés et attendre la validation.
3. Écrire la page de résumé dans wiki/sources/.
4. Mettre à jour ou créer les pages d'entités et de concepts concernées.
5. Mettre à jour wiki/index.md.
6. Ajouter une entrée à wiki/log.md : ## [AAAA-MM-JJ] ingest | Titre

## Question
1. Lire wiki/index.md, puis les pages utiles.
2. Répondre en citant les pages et les sources brutes.
3. Ne rien affirmer qui ne figure pas dans le wiki ; dire ce qui manque.
4. Si la réponse apporte une synthèse nouvelle, proposer de l'enregistrer comme page.

## Vérification
Signaler sans corriger d'office : contradictions, affirmations dépassées,
pages orphelines, concepts cités sans page, liens cassés.

Diese Datei ist unsere, nicht die von Karpathy: Das Gist beschreibt die Rolle der Konventionsdatei, liefert jedoch kein Muster dafür und empfiehlt, sie gemeinsam mit dem Modell weiterzuentwickeln, sobald Sie sehen, was in Ihrem Bereich funktioniert. Halten Sie sie kurz. Der Agent liest sie in jeder Sitzung erneut, und jede Zeile nimmt Platz im Kontext ein.

#3. Modell und Agent starten

Laden Sie ein Modell herunter, das Tools aufrufen kann, und öffnen Sie OpenCode im Wiki-Ordner. Der Befehl ollama launch opencode startet OpenCode mit einem von Ollama bereitgestellten Modell, das Sie im Auswahlmenü auswählen. Die Installation von OpenCode selbst wird in unserem Leitfaden „OpenCode + Ollama“ beschrieben.

# Un modèle généraliste avec appel d'outils (à adapter à votre mémoire)
ollama pull gpt-oss:20b

# Ouvrir l'agent dans le dossier du wiki
cd ~/wiki
ollama launch opencode

Bleibt der Kontext. Laut der Dokumentation von Ollama hängt das Standardfenster vom VRAM ab (4 000 Tokens unter 24 GB, 32 000 zwischen 24 und 48 GB), während Agenten mindestens 64 000 benötigen. Die Variable OLLAMA_CONTEXT_LENGTH legt ihn beim Start des Servers fest; wenn Ollama bereits als Anwendung oder Dienst läuft, stellen Sie den Wert in dessen Einstellungen ein, statt einen zweiten Server zu starten.

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# Dans un autre terminal, une fois le modèle chargé :
ollama ps

Der Befehl ollama ps zeigt an, ob das Modell vollständig auf der GPU Platz findet. Wenn es auf den Prozessor ausweicht, wird jede Ingestion sehr langsam: Nehmen Sie ein kleineres Modell, bevor Sie den Kontext kürzen.

#4. Eine erste Quelle ingestieren

Legen Sie ein erstes Dokument in raw/ ab, vorzugsweise im Markdown- oder Textformat. Für Webseiten weist das Gist auf die Erweiterung Obsidian Web Clipper hin, die einen Artikel in eine Markdown-Datei umwandelt. Geben Sie dem Agenten anschließend die Anweisung:

Ingère raw/mon-premier-article.md en suivant AGENTS.md.
Présente-moi d'abord les points clés et attends ma validation avant d'écrire.

Der Agent liest die Quelle, schlägt die wichtigsten Punkte vor und erstellt und bearbeitet anschließend die Seiten. Lesen Sie das Ergebnis durch, bevor Sie weitermachen: die Zusammenfassungsseite, die erstellten Entitätsseiten, den Index, das Protokoll. Speichern Sie anschließend den Zustand des Wikis.

git status
git add -A
git commit -m "ingest: mon-premier-article"

#5. Antworten abfragen und ordnen

Stellen Sie dem Agenten nach einigen Quellen Ihre Fragen im selben Ordner. Bitten Sie ihn ausdrücklich, seine Seiten und Quellen zu zitieren und zu sagen, was das Wiki nicht enthält.

D'après le wiki, qu'est-ce qui distingue l'approche A de l'approche B ?
Cite les pages et les sources brutes utilisées, et signale ce qui manque.
Si la réponse apporte une synthèse nouvelle, enregistre-la dans wiki/concepts/
puis mets à jour l'index et le journal.

#6. Regelmäßig überprüfen

Führen Sie nach jeweils einigen Ingestions einen Prüfdurchlauf aus. Fordern Sie vor jeder Korrektur eine Liste der Probleme an: So behalten Sie die Kontrolle darüber, was zusammengeführt, umbenannt oder gelöscht wird.

Fais une passe de vérification du wiki en suivant AGENTS.md.
Liste les problèmes trouvés, sans rien modifier pour l'instant.

Das Protokoll lässt sich ohne Agenten einsehen. Mit dem regelmäßigen Präfix der Einträge zeigt der im Gist angegebene Befehl die letzten Vorgänge an (nur der Pfad wird an unsere Verzeichnisstruktur angepasst):

grep "^## \[" wiki/log.md | tail -5

#LLM-Wiki oder RAG: Was der Patron nicht ersetzt

Das Gist stellt Wiki und RAG gegenüber, um die Idee verständlich zu machen. Es sagt nicht, dass das eine das andere ersetzt, und auch dieser Leitfaden sagt das nicht: Beide Ansätze eignen sich für unterschiedliche Situationen. Hier sehen Sie, was sie unterscheidet, ohne Zahlen, weil wir keine Messung vorlegen können.

Der Zeitpunkt der Arbeit

Ein RAG arbeitet bei jeder Frage: Es sucht Auszüge, anschließend formuliert das Modell den Text. Das Wiki arbeitet bei der Aufnahme: Die Zusammenfassung wird einmal geschrieben und bei jeder Frage erneut gelesen.

Was erhalten bleibt

Ein RAG speichert Ausschnitte und deren Vektoren, die so nicht lesbar sind. Das Wiki speichert ausformulierte Seiten, die Sie lesen, korrigieren und versionieren können.

L'infrastructure

Ein RAG benötigt ein Embedding-Modell, eine Vektordatenbank und eine Strategie zur Aufteilung. Das Wiki benötigt einen Ordner und einen Agenten. Laut Gist genügt der Index in einem moderaten Umfang (in der Größenordnung von hundert Quellen und einigen hundert Seiten) und erspart den Aufbau einer Embedding-basierten RAG-Infrastruktur.

Die Quellentreue

Ein RAG gibt dem Modell originale Textpassagen zurück. Das Wiki gibt ihm eine von einem Modell verfasste Umformulierung zurück, mit dem damit verbundenen Fehlerrisiko.

Die Lautstärke

Ein RAG ist für große Korpora ausgelegt. Das Wiki wird durch das begrenzt, was das Modell auf einmal lesen kann: Index, relevante Seiten und Quelle müssen in das Kontextfenster passen.

Jenseits eines moderaten Umfangs führt das Gist die Suche selbst wieder ein. Es zitiert qmd, eine lokale Suchmaschine für Markdown-Dateien, die BM25, Vektorsuche und ein LLM-Reranking kombiniert und über die Kommandozeile oder als MCP-Server nutzbar ist. Ein großes Wiki stützt sich daher letztlich auf die Bausteine eines RAG, die auf bereits zusammengefasste Seiten statt auf Rohdokumente angewendet werden. Die beiden Ansätze ergänzen sich eher, als dass sie sich ausschließen.

In der Praxis sollten Sie ein klassisches RAG beibehalten, wenn der Korpus umfangreich ist oder sich ständig ändert (Unternehmensdokumentation, Tickets, Verträge), wenn die Antwort die genaue Passage eines Dokuments wiedergeben muss oder wenn mehrere Personen mit unterschiedlichen Berechtigungen dieselbe Datenbank abfragen. Das LLM Wiki eignet sich besser für ein Thema, das man über Wochen vertieft: Beobachtung, Recherche, Lektüre eines Buches, Vorbereitung einer Unterlage. Dies sind Anwendungsfälle, die der Gist selbst nennt.

#Grenzen, die Sie kennen sollten, besonders lokal

Auch die Fehler häufen sich

Ein in eine Seite geschriebener Zusammenfassungsfehler wird erneut gelesen, zitiert und auf die folgenden Seiten übertragen. In einem RAG verschwindet eine falsche Antwort mit der Unterhaltung; in einem Wiki bleibt sie bestehen. Darin liegt der Grund für die systematische Rückverweisung auf die Rohquellen und die Überprüfung von Änderungen.

Ein lokales Modell hat weniger Spielraum

Die Aufnahme erfordert, eine lange Anweisung zu befolgen, mehrere Dateien zu lesen und etwa zehn davon zu ändern, ohne eine zu vergessen. Kleine Modelle bewältigen diese Art langer Aufgabe im Allgemeinen schlechter als die großen Modelle, die hinter den im Gist genannten Agenten betrieben werden. Beurteilen Sie es anhand Ihrer eigenen Quellen und beginnen Sie klein.

Das Kontextfenster begrenzt alles

Eine sehr lange Quelle, ein gewachsener Index und zehn erneut zu lesende Seiten passen nicht immer in 64 000 Tokens. Teilen Sie umfangreiche Quellen nach Kapiteln auf und halten Sie die Seiten kurz.

Die Aufnahme braucht Zeit

Jede Quelle löst eine Reihe von Lese- und Schreibvorgängen aus. Rechnen Sie auf einer bescheidenen Maschine eher mit einer Verarbeitung Quelle für Quelle als mit der import d einer ganzen Bibliothek an einem Abend.

Die Struktur driftet ab

Ohne strenge Regeln erstellt der Agent Duplikate (dieselbe Entität unter zwei Namen) und Seiten, die nichts miteinander verknüpft. Die Benennungsregeln in der Konventionsdatei und der Prüfungsdurchlauf dienen genau diesem Zweck.

#Tipps und Fehlerbehebung

Der Agent überspringt Schritte bei der Aufnahme

Der Kontext ist wahrscheinlich zu kurz: Die Anweisung verlässt unterwegs das aktuelle Fenster. Überprüfen Sie den Wert von OLLAMA_CONTEXT_LENGTH, kürzen Sie AGENTS.md oder teilen Sie die Quelle auf.

Der Agent beschreibt, was er tun würde, ohne etwas zu schreiben

Das Modell kommt mit Tool-Aufrufen schlecht zurecht. Nehmen Sie ein Modell, das in der Bibliothek Ollama die Fähigkeit tools anzeigt.

Dieselbe Entität erscheint unter zwei Namen

Fordern Sie eine gezielte Prüfrunde auf doppelte Einträge an, bestätigen Sie die Zusammenführungen einzeln und ergänzen Sie die Benennungsregel, die in der Konventionsdatei fehlte.

Der Index wird zu lang

Teilen Sie es nach Kategorien auf, mit einem Hauptindex, der auf Nebenindizes verweist, oder fügen Sie ein Suchwerkzeug für Markdown-Dateien hinzu, etwa qmd, das im Gist erwähnt wird.

Die Antworten ignorieren vorhandene Seiten

Der Index wurde während einer Aufnahme nicht aktualisiert. Lassen Sie ihn anhand des Inhalts des Ordners wiki/ neu erstellen und prüfen Sie anschließend das Protokoll.

#Einsatzbereite Implementierungen

Sie müssen nicht alles von Hand schreiben. Hermes Agent, der Open-Source-Agent von Nous Research, dokumentiert eine integrierte Skill namens llm-wiki, die in der Kategorie Recherche eingeordnet ist und dieses Muster übernimmt. Wenn Sie diesen Agenten bereits mit Ollama verwenden, ist das ein schnellerer Ausgangspunkt; die unten verlinkte Dokumentationsseite beschreibt seine Funktionsweise. Das Prinzip bleibt dasselbe: Lesen Sie die Konventionen, bevor Sie ihnen Ihre Quellen anvertrauen.

#Quellen

Alles, was über die Vorlage gesagt wird, stammt aus dem Beitrag und dem Gist von Andrej Karpathy. Die Einstellungen von Ollama und OpenCode stammen aus deren Dokumentation, die bereits in unserem Leitfaden „OpenCode + Ollama“ zitiert wurde. Lesen Sie diese Seiten erneut, bevor Sie einen Befehl einfügen: Diese Tools entwickeln sich schnell weiter.

https://x.com/karpathy/status/2039805659525644595

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

https://hermes-agent.nousresearch.com/docs/user-guide/skills/bundled/research/research-llm-wiki

https://docs.ollama.com/context-length

https://docs.ollama.com/integrations/opencode

#Weiterführende Informationen

Das LLM-Wiki liegt am Schnittpunkt mehrerer Themen, die auf der Website bereits behandelt wurden. Jeder dieser Leitfäden behandelt das, was dieser hier bewusst auslässt.

Lokales RAG: Einführung

Embeddings, Vektordatenbank, Aufteilung: die Funktionsweise des klassischen RAG, die Sie kennen sollten, um zu wissen, wann es weiterhin die richtige Wahl ist. https://quelllm.fr/guide/rag-local-introduction

Obsidian + lokales LLM

Ein lokales Modell mit einem Obsidian-Tresor über die Plugins Copilot und Smart Connections verbinden, um mit Notizen zu sprechen, die Sie selbst schreiben. https://quelllm.fr/guide/obsidian-llm-local-ollama

NotebookLM lokal

Die Open-Source-Tools, die Quellen-Notizbücher und zitierte Antworten ohne zwischengeschaltetes Wiki nachbilden. https://quelllm.fr/guide/notebooklm-local-alternative

Fine-Tuning vs. RAG

Karpathy erwähnt in seinem Beitrag als Ansatz zur weiteren Untersuchung die Feinabstimmung eines Modells auf den Daten seiner Datenbank. Dieser Leitfaden hilft Ihnen zu entscheiden, ob sich der Aufwand lohnt. https://quelllm.fr/guide/fine-tuning-vs-rag-choisir

OpenCode + Ollama

Die Installation des hier verwendeten Agenten, die Einstellung des Kontexts und die Berechtigungen. https://quelllm.fr/guide/opencode-ollama-agent-terminal