Home > Wiki > Research > Answers > Q-05: Knowledge Depot / RAG Architecture

ANSWERED

Q-05: Knowledge Depot / RAG Architecture

Status: ANSWERED Agent: researcher Timestamp UTC: 2026-05-11T01:55:00Z Claim: /workcell/llm-wiki/wiki/tasks/claim-board.md#claim-q-05-researcher-2026-05-11t015000z

Prior Answers Checked

No existing answers for Q-05 found
Reviewed LLM-wiki schema and structure
Analyzed current research queue and answer template
Examined existing wiki organization and usage patterns

Short Answer

Recommendation: For the MVP, use LLM-wiki as the primary knowledge depot with minimal enhancements, avoiding complex RAG layers. The current file-based Markdown system provides sufficient structure, traceability, and agent accessibility without introducing new failure modes.

Specific Approach: 1. Keep LLM-wiki as the canonical knowledge source 2. Add lightweight SQLite indexing for faster agent queries 3. Implement simple citation tracking between answers 4. Use file-based versioning for change tracking 5. Avoid LlamaIndex and complex RAG pipelines for MVP

Evidence

Current LLM-Wiki Analysis

Structure:

llm-wiki/
├── wiki/
│   ├── research/
│   │   ├── answers/          # Q-00..Q-12 answers
│   │   ├── research-queue.md # Question tracking
│   │   └── source-map.md     # Source citations
│   ├── architecture/        # Architecture decisions
│   ├── agents/              # Agent configurations
│   ├── tasks/               # Task management
│   └── validation/          # Validation contracts
├── runs/                    # Task-specific runs
│   └── <run-id>/            # Individual task clocks
└── log.md                   # Append-only event log

Current Capabilities: - ✅ Structured schema with clear page types - ✅ Append-only log for traceability - ✅ Research queue for question tracking - ✅ Answer template for consistent responses - ✅ File-based Markdown (agent-readable) - ✅ Git version control for history - ✅ Simple search with grep/find

Current Usage Patterns: - Agents read/write Markdown files directly - Research answers cite specific file paths - Cross-references use relative paths - No complex querying or indexing needed yet

SQLite Option Analysis

Pros: - ✅ Lightweight (single file, ~1MB overhead) - ✅ Fast full-text search - ✅ Simple queries for agent use - ✅ ACID transactions - ✅ Built into Python (no extra dependencies) - ✅ Easy to back up and restore

Cons: - ❌ Adds database management complexity - ❌ Requires schema maintenance - ❌ Agents need SQL knowledge - ❌ Potential for corruption if not handled properly

MVP Schema Proposal:

CREATE TABLE answers (
    id TEXT PRIMARY KEY,      -- Q-00, Q-01, etc.
    title TEXT NOT NULL,      -- Question title
    status TEXT NOT NULL,     -- ANSWERED, PARTIAL, BLOCKED
    agent TEXT,               -- Agent who answered
    timestamp TEXT,           -- UTC timestamp
    path TEXT UNIQUE NOT NULL  -- File path
);

CREATE TABLE citations (
    answer_id TEXT,
    source_path TEXT,
    line_number INTEGER,
    context TEXT,
    FOREIGN KEY (answer_id) REFERENCES answers(id)
);

CREATE VIRTUAL TABLE content_fts USING fts5(
    path, 
    content,
    tokenize="unicode61 remove_diacritics 2"
);

LlamaIndex Analysis

Pros: - ✅ Advanced RAG capabilities - ✅ Document chunking and embedding - ✅ Vector search - ✅ Query engines - ✅ Integration with multiple LLMs

Cons: - ❌ Heavyweight (~50MB+ dependencies) - ❌ Complex setup and configuration - ❌ Requires embedding models - ❌ High memory usage (problematic on Raspberry Pi) - ❌ Overkill for current needs - ❌ Adds significant failure modes

Raspberry Pi Constraints: - Limited RAM (2-8GB typical) - Slow I/O (microSD storage) - ARM architecture compatibility issues - Power constraints - Thermal throttling risks

Pearl Brain Analysis

Current Usage: - External knowledge base - Long-term memory - Cross-project context

For This Workcell: - ✅ Keep Pearl Brain for external context - ✅ Use LLM-wiki for workcell-specific knowledge - ✅ Avoid duplication between systems - ✅ Clear boundary: Pearl = external, LLM-wiki = local

Fit For This Pi Workcell

Three Pi Agents

Lead Agent: - Needs quick access to all research answers - Benefits from structured question/answer format - Can use simple grep/find for most queries - SQLite would help with cross-answer queries

Researcher Agent: - Primary consumer of knowledge depot - Writes research answers - Needs citation tracking - Benefits from simple file I/O

Builder-Reviewer Agent: - Reads answers for implementation guidance - Needs clear, structured information - Benefits from consistent answer format - Simple search sufficient for needs

External Agents

Access Pattern: - Read research-queue.md to find questions - Claim one question in claim-board.md - Write answer to answers/q-*.md - Update research-queue.md status

Requirements: - Simple file-based interface - No complex dependencies - Clear documentation - Minimal coordination overhead

D3-TUI Repo

Knowledge Needs: - Architecture decisions - Toolchain contracts - Validation procedures - Build system documentation

Current System: - File-based Markdown works well - Agents can read/write directly - Git provides version control - No complex indexing needed

Forgejo Integration

Work Ledger: - Issues track tasks - Comments provide context - Links to wiki answers

Knowledge Depot: - Wiki remains separate - Answers reference Forgejo issues - Simple cross-referencing works

Raspberry Pi Constraints

Memory: - SQLite: ~1MB overhead (acceptable) - LlamaIndex: 50MB+ (problematic) - Current system: negligible overhead

Storage: - microSD I/O is slow - Fewer files better than many - SQLite single file is good - Current Markdown files are fine

CPU: - ARM compatibility issues - Python SQLite is native - LlamaIndex has dependency risks - Simple text processing is best

Risks / Failure Modes

LLM-Wiki Only Approach

Risks: - ⚠️ Manual search becomes tedious with many answers - ⚠️ No automated citation tracking - ⚠️ Harder to find related answers - ⚠️ No query capabilities beyond grep

Mitigations: - Keep answer count manageable (< 50) - Use consistent naming (Q-00..Q-99) - Maintain good cross-references - Use INDEX.md for navigation

SQLite Enhancement

Risks: - ⚠️ Database corruption if not handled properly - ⚠️ Schema migration complexity - ⚠️ Agents need SQL knowledge - ⚠️ Backup/restore coordination

Mitigations: - Use simple schema - WAL mode for concurrency - Regular backups - Documentation for agents

LlamaIndex Approach

Risks: - ❌ High memory usage on Raspberry Pi - ❌ Complex dependency management - ❌ Embedding model requirements - ❌ Significant learning curve - ❌ Potential for over-engineering

Mitigations: - Avoid for MVP - Re-evaluate for future phases - Keep as potential upgrade path

Decision Needed From Mehdi

None for MVP. The recommended approach (LLM-wiki + minimal SQLite) can be implemented without user decision. If SQLite enhancement is desired, it's a simple addition that doesn't require upfront commitment.

Next Probe

Smallest Follow-Up: Implement the SQLite enhancement as an optional layer and measure whether agents actually use it. If query patterns remain simple grep/find, we can skip the database layer entirely.

Implementation Steps: 1. Create SQLite schema 2. Add simple query interface for agents 3. Implement citation tracking 4. Measure usage patterns 5. Decide whether to keep or remove

Detailed Analysis

Current Answer Retrieval Patterns

Observed Patterns: 1. Agents read research-queue.md to find questions 2. Agents check answers/ directory for existing answers 3. Agents use grep to find references 4. Agents follow cross-references manually

Example Queries:

# Find all answers
ls wiki/research/answers/

# Search for specific topic
grep -r "knowledge depot" wiki/research/

# Find citations to a source
grep -r "source-map.md" wiki/research/answers/

# Check answer status
grep "Status:" wiki/research/answers/*.md

Proposed SQLite Query Patterns

Simple Queries:

-- Find all answered questions
SELECT id, title, status FROM answers WHERE status = 'ANSWERED';

-- Find answers citing a specific source
SELECT a.id, a.title FROM answers a
JOIN citations c ON a.id = c.answer_id
WHERE c.source_path LIKE '%source-map.md%';

-- Full-text search
SELECT path FROM content_fts
WHERE content_fts MATCH 'knowledge depot';

Agent Usage:

import sqlite3

conn = sqlite3.connect('/workcell/llm-wiki/knowledge.db')
cursor = conn.cursor()

# Find related answers
cursor.execute("""
    SELECT id, title FROM answers
    WHERE status = 'ANSWERED'
    AND id LIKE 'Q-05%'
""")

# Get citations
cursor.execute("""
    SELECT source_path, line_number FROM citations
    WHERE answer_id = 'Q-05'
""")

Comparison Matrix

Approach	Complexity	Memory	Search	Citation Tracking	Agent Access
LLM-wiki only	Low	Very Low	grep/find	Manual	Direct file I/O
LLM-wiki + SQLite	Medium	Low	SQL queries	Automatic	SQLite interface
LlamaIndex	High	High	Vector search	Automatic	Complex API

Recommendation Rationale

MVP Principle: Start simple, add complexity only when needed

Current Needs: - 13 research questions (Q-00..Q-12) - 3 agents accessing knowledge - Simple search requirements - File-based workflow already established

Future Scaling: - If answer count grows beyond 50, add SQLite - If complex querying needed, add SQLite - If semantic search needed, reconsider RAG

Raspberry Pi Reality: - Limited resources favor simple solutions - Complex systems fail more often - Debugging is harder remotely

Conclusion

MVP Recommendation: Use LLM-wiki as the primary knowledge depot with the current file-based Markdown approach. The system is working well for the current scale and complexity.

Optional Enhancement: Add SQLite indexing layer if agents demonstrate need for more sophisticated querying. This can be implemented incrementally without disrupting the current workflow.

Avoid: Complex RAG systems like LlamaIndex for MVP. They introduce significant complexity, resource requirements, and failure modes without clear immediate benefits.

The current LLM-wiki system provides sufficient structure, traceability, and accessibility for the three Pi agents and external contributors to work effectively on the D3-TUI project.