LlamaIndex vs LLM Wiki — Fit on Pi 4
Status: ACTIVE (observation) Agent: opencode/ext-agent (sandshrew) Timestamp UTC: 2026-05-11T23:55:00Z Session: MjF question — what does LlamaIndex offer vs LLM wiki? Can they layer?
What LlamaIndex Offers
| Capability | How It Works |
|---|---|
| Semantic search | Embeddings → cosine similarity → find relevant docs regardless of keywords |
| Auto-chunking | Splits large docs into retrievable pieces |
| Multi-step workflows | Query → retrieve → rerank → synthesize → cite |
| RAG pipelines | Load → chunk → embed → index → query |
| Connectors | GitHub, Slack, Notion, PDFs, APIs — ingest from anywhere |
| Provenance | Tracks which chunk came from which source, with confidence |
What the LLM Wiki Offers
| Capability | How It Works |
|---|---|
| Structured curation | Agents manually digest sources into summary/concept/decision pages |
| Navigable index | index.md → category page → specific topic |
| Immutable sources | Raw captures never change; synthesis evolves separately |
| Append-only traceability | log.md records every ingest, query, lint pass |
| Agent-native | Agents read/write markdown, link with Obsidian-style [[wikilinks]] |
| Zero dependencies | File-based. No vector DB, no embedding model, no Python packages |
Key Difference: Retrieval Model
| LlamaIndex | LLM Wiki | |
|---|---|---|
| How you find things | Semantic search ("what's relevant to this query?") | Navigation (index → page → section) |
| Scale ceiling | Thousands of documents | Tens to low hundreds of pages |
| Setup cost | Embedding model + vector store + indexing pipeline | mkdir + markdown files |
| Sync maintenance | Re-index when content changes | Immediately consistent (files ARE the index) |
| Pi 4 cost | ~500MB RAM for sentence-transformers + ~200MB for vector store | Negligible (<1MB) |
Can They Layer?
Yes, in a specific pattern:
LLM Wiki (structured depot) ← Agents write curated synthesis
│
▼
LlamaIndex (semantic layer) ← Indexes wiki pages, enables search
│
▼
LangGraph node (context fetch) ← Agent queries index for relevant pages
The LLM wiki is the authoritative store. LlamaIndex is the semantic retrieval frontend on top. Agents write to the wiki (structured, linked, curated). LlamaIndex indexes it. LangGraph nodes query LlamaIndex to find context they didn't know they needed.
Does It Make Sense for This Prototype?
Not yet. At 36 nodes and ~20 wiki pages:
- The LLM wiki's index.md + [[wikilinks]] provide sufficient navigation
- LangGraph's access gating (context_access / context_block) already delivers targeted context
- Adding LlamaIndex on Pi 4 would consume ~700MB RAM for a search capability that ~20 pages don't need
- The Q-05 Knowledge Depot answer explicitly recommended: "LLM-wiki for MVP, optional SQLite enhancement, avoid LlamaIndex"
When it would make sense: - Wiki grows past 100 pages — navigation by index alone becomes tedious - Agents need cross-topic discovery ("what other nodes reference SqliteSaver?") - Provenance becomes critical ("this claim traces to source X, date Y, confidence Z") - The harvester pattern is live — auto-indexing harvested intel makes it discoverable
What the migration path looks like: 1. Today: LLM wiki + LangGraph access lists. Agents curate what nodes see. 2. Later: Add SQLite index for structured queries (fast lookups by tag, phase, status). 3. Later still: Add LlamaIndex for semantic search across 100+ pages. Embedding model runs on Pi 4 (sacrificing ~500MB RAM for better discovery).
Each layer adds capability at the cost of complexity. Add them when the capability is needed, not before.