Deep Dive into LLM Wiki Engineering: AI Coding, Obsidian Integration, and RAG Collaboration

AI Coding Knowledge Map

LLM Wiki + OKF can be used for AI coding in large enterprises where knowledge is scattered across many repositories and layers. The author proposes building an OKF Knowledge Bundle for a coding agent.

Designing the Knowledge Map

The Wiki is tool‑agnostic and does not rely on databases or vector indexes. It should be organized around the paths an agent needs to follow: business, architecture, engineering, etc. An example directory structure is shown.

The root index.md serves as the entry point, directing the agent to sub‑directories such as business, architecture, and engineering. Index.md navigates, knowledge units hold the facts, and source code remains the ultimate evidence.

Progressive Context Loading

Instead of loading the whole Wiki at once, the agent reads the root index, selects the most relevant domain, loads the corresponding sub‑index, and then expands only the concepts required for the task. The process is illustrated with a bullet list:

- Read root index.md and choose the most relevant knowledge domain
- Load the corresponding directory index.md
- Load related concepts and follow Markdown links as needed
- Distinguish verified facts, sourced opinions, and inferred conclusions; flag gaps
- Stop when enough context is gathered and execute the task

An example task “add automatic compensation for order failures” shows how the agent navigates the map, checks code signatures, and records conclusions together with evidence.

Metadata for a Practical AI Coding Wiki

resource

: link to code, OpenAPI spec, DB schema source_commit: fixed verified code version owner: maintainer review_status: draft, agent inference, human review, deprecated timestamp: last meaningful update

Body: detailed applicability, counter‑examples, verification points

The OKF bundle should be maintained by the LLM, with humans reviewing and guiding.

Compounding Knowledge Benefits

Because the Wiki is continuously maintained, each development task can add new cross‑module constraints, update API contracts, or record new failure patterns, creating a “compound interest” effect where future agents reuse the enriched map.

Building LLM Wiki in Obsidian

Obsidian’s strong linking and plugin ecosystem make it a convenient IDE for a Wiki. Two approaches are described.

Path 1 – Karpathy LLM Wiki Plugin

The third‑party “Karpathy LLM Wiki” plugin embeds the ingest, query, and maintenance workflow directly in Obsidian. After installing the plugin and configuring an LLM provider, users can ingest single files, folders, or multiple selections. The plugin parses Markdown or PDF, extracts entities, creates Wiki links, and updates wiki/index.md. A query panel lets users converse with the knowledge base without a separate vector store.

The plugin can automatically detect duplicate pages, broken links, empty pages, and inconsistent aliases, and can watch folder changes to trigger re‑ingestion.

Path 2 – Custom Agent/Skill

For teams that need OKF compatibility, Git‑based review, or custom governance, the author suggests treating the existing Obsidian vault as a read‑only raw source while an LLM‑driven agent maintains a separate LLM Wiki. The workflow includes detecting new or changed notes, generating change plans, updating concept pages, performing quality checks (metadata, link integrity), and submitting changes via Git diff and pull request for human review.

Advantages: flexibility, strong customization, team‑wide knowledge governance. Drawbacks: higher implementation complexity.

LLM Wiki vs. RAG

The article contrasts the two paradigms:

LLM Wiki + OKF focuses on knowledge organization, governance, and exchange format; it compiles documents into reusable knowledge units that retain hierarchical relationships.

RAG + vector retrieval emphasizes runtime retrieval of relevant chunks to augment model context.

A comparison (summarized) lists dimensions such as positioning, core tasks, working time, main units, long‑term artifacts, loading method, applicable scenarios, context handling, advantages, and primary risks. Key points include:

LLM Wiki offers governance, versioning, and progressive disclosure but may incur maintenance cost and performance issues at large scale.

RAG provides fast semantic search and long‑tail coverage but can suffer from context fragmentation and index update overhead.

Fusion

The author recommends using LLM Wiki as the authoritative, continuously updated knowledge source and RAG as a retrieval acceleration layer. The combined system can first navigate the Wiki for structured understanding and then employ vector search to fetch precise API details.

Limitations and Best Practices

When the knowledge base grows very large, pure Wiki navigation can become costly; in such cases, RAG may be more efficient for well‑structured, independent knowledge like API specs. Scaling strategies include starting with a few concepts indexed by index.md, adding BM25 + vector hybrid search as the number of pages grows, leveraging graph queries for cross‑system impact analysis, and incorporating multimodal parsing for images or audio.

The article concludes that LLM Wiki is not a replacement for RAG but a complementary paradigm that turns enterprise knowledge into a maintainable, evolving system, enabling agents to perform critical tasks such as AI coding more reliably.