Knowledge Base Manager

Build and maintain high-quality knowledge bases for AI systems and human consumption.

Core Principle

Knowledge Base = Structured Information + Quality Curation + Accessibility

A knowledge base is not just a data dump—it's curated, validated, versioned information designed to answer questions and enable reasoning.

---

When to Use Knowledge Bases

Use Knowledge Bases When:

• ✅ Need to answer factual questions consistently
• ✅ Information changes frequently and needs version control
• ✅ Multiple sources need to be unified and reconciled
• ✅ Provenance and citation tracking is critical
• ✅ Building AI systems that need grounded, verifiable information
• ✅ Organizational knowledge needs to be preserved and searchable
• ✅ Complex domain with interconnected concepts

Don't Use Knowledge Bases When:

• ❌ Static documentation is sufficient (use docs + search)
• ❌ No one will maintain/update it (knowledge rot guaranteed)
• ❌ Simple FAQ covers all questions (<50 items)
• ❌ Information doesn't change (static site faster/cheaper)
• ❌ Team lacks resources for curation

---

Knowledge Base Types: Decision Framework

1. Document-Based Knowledge Base (RAG)

What it is: Collection of documents, chunked and embedded for semantic search

Best for:

• Technical documentation
• Support articles, FAQs
• Policy documents
• Research papers
• Blog content
• User manuals

Strengths:

• Easy to add new documents
• Preserves full context
• Natural for text-heavy content

Weaknesses:

• Hard to query relationships ("Who works where?")
• Duplicate information across documents
• Difficult to keep facts consistent

Use: rag-implementer skill + vector-database-mcp

---

2. Entity-Based Knowledge Base (Knowledge Graph)

What it is: Network of entities (people, places, things) connected by relationships

Best for:

• Organizational charts
• Product catalogs with relationships
• Social networks
• Recommendation systems
• Fraud detection
• Supply chain tracking

Strengths:

• Excellent for "how are X and Y related?" queries
• Consistent facts (one source of truth)
• Powerful traversal ("friends of friends")

Weaknesses:

• Upfront modeling required (ontology design)
• Harder to add unstructured information
• Learning curve for graph queries

Use: knowledge-graph-builder skill + graph-database-mcp

---

3. Hybrid Knowledge Base (RAG + Graph)

What it is: Documents for unstructured knowledge + Graph for structured entities/relationships

Best for:

• Enterprise knowledge management
• Research with citations and relationships
• Medical systems (documents + patient/drug relationships)
• Legal systems (cases + precedents + entities)
• E-commerce (products + specs + relationships)

Strengths:

• Best of both worlds
• Flexible for different knowledge types
• Rich querying capabilities

Weaknesses:

• Most complex to build and maintain
• Requires expertise in both RAG and graphs
• Higher infrastructure costs

Use: Both rag-implementer + knowledge-graph-builder skills

---

Decision Tree: Which KB Type?

What kind of knowledge do you have?

├─ Mostly unstructured text (docs, articles, content)?
│  └─ Document-Based KB (RAG)
│     Use: rag-implementer skill
│
├─ Mostly structured entities with relationships?
│  └─ Entity-Based KB (Graph)
│     Use: knowledge-graph-builder skill
│
└─ Mix of both?
   └─ Hybrid KB (RAG + Graph)
      Use: Both skills + This skill for integration

---

6-Phase Knowledge Base Implementation

Phase 1: Knowledge Audit & Architecture

Goal: Understand what knowledge exists and how to structure it

Actions:

1. Inventory existing knowledge sources

   • Internal: databases, documents, wikis, Slack, emails
   • External: public data, APIs, third-party sources
   • Tribal: SME interviews, recorded conversations

2. Classify knowledge types

   • Factual: Verifiable facts ("Product X costs $50")
   • Procedural: How-to knowledge ("How to deploy")
   • Conceptual: Definitions and explanations
   • Relationship: Connections between entities

3. Choose KB architecture

   • Document-based? Entity-based? Hybrid?
   • Decision: Use framework above

4. Define knowledge schema

   • For documents: metadata fields (source, date, author, category)
   • For entities: ontology (entity types, relationship types, properties)

Validation:

• All knowledge sources inventoried and prioritized
• KB architecture chosen and justified
• Schema defined and validated with users
• Success metrics established

---

Phase 2: Knowledge Curation & Ingestion

Goal: Transform raw information into high-quality knowledge

Actions:

1. Extract knowledge from sources

   • Automated: scraping, API ingestion, file parsing
   • Manual: expert input, annotation, validation

2. Clean and normalize

   • Remove duplicates
   • Standardize formats
   • Fix inconsistencies
   • Enrich with metadata

3. Structure knowledge

   • For documents: chunk intelligently (semantic boundaries)
   • For entities: extract entities, relationships, properties

4. Add provenance

   • Source URL or reference
   • Last updated timestamp
   • Author/contributor
   • Confidence score (if applicable)

Curation Best Practices:

• Single Source of Truth: One canonical answer per question
• Deduplication: Merge similar knowledge entries
• Conflict Resolution: When sources disagree, establish priority rules
• Metadata Richness: More metadata = better filtering and search

Validation:

• Knowledge extracted and structured
• Quality metrics above threshold (accuracy >95%)
• Provenance tracked for all entries
• Sample queries return relevant results

---

Phase 3: Storage & Retrieval Setup

Goal: Implement technical infrastructure for knowledge access

Architecture Patterns:

For Document-Based KB:

// Vector database for semantic search
interface DocumentKB {
  store: 'Pinecone' | 'Weaviate' | 'pgvector'
  chunks: {
    content: string
    embedding: number[]
    metadata: {
      source: string
      title: string
      updated_at: string
      category: string
    }
  }[]
}

For Entity-Based KB:

// Graph database for relationship queries
interface EntityKB {
  store: 'Neo4j' | 'ArangoDB'
  nodes: {
    id: string
    type: 'Person' | 'Organization' | 'Product' | 'Concept'
    properties: Record<string, any>
  }[]
  relationships: {
    from: string
    to: string
    type: string
    properties: Record<string, any>
  }[]
}

For Hybrid KB:

// Both vector DB + graph DB
interface HybridKB {
  vectorDB: DocumentKB
  graphDB: EntityKB
  linker: {
    // Links documents to entities mentioned in them
    linkDocumentToEntities(docId: string): string[]
    // Links entities to documents that mention them
    linkEntityToDocuments(entityId: string): string[]
  }
}

Actions:

1. Choose database(s)

   • Document: Pinecone, Weaviate, pgvector
   • Entity: Neo4j, ArangoDB
   • Hybrid: Both + linking layer

2. Implement search/query layer

   • Vector similarity search (for documents)
   • Graph traversal (for entities)
   • Hybrid queries (combining both)

3. Add caching and optimization

   • Cache frequent queries
   • Optimize for common access patterns

Validation:

• Database deployed and accessible
• Search/query functionality working
• Performance meets requirements (<100ms for most queries)

---

Phase 4: Quality Control & Validation

Goal: Ensure knowledge base accuracy and reliability

Quality Metrics:

1. Accuracy: % of correct answers to test questions
2. Coverage: % of user questions answerable
3. Freshness: Average age of knowledge
4. Consistency: % of conflicts/contradictions
5. Source Quality: % from authoritative sources

Validation Strategies:

1. Test Question Sets Create 100+ test questions with known correct answers:

interface TestQuestion {
  question: string
  expected_answer: string
  category: string
  difficulty: 'easy' | 'medium' | 'hard'
}

2. Human Review

• Sample random knowledge entries
• Subject matter expert validation
• User feedback loops

3. Automated Checks

• Duplicate Detection: Find near-identical entries
• Conflict Detection: Find contradictory facts
• Staleness Detection: Flag outdated information
• Citation Validation: Verify sources still exist

4. Continuous Monitoring

interface KBHealthMetrics {
  accuracy_score: number // 0-100
  coverage_score: number // % questions answered
  freshness_score: number // avg days since update
  consistency_score: number // % no conflicts
  user_satisfaction: number // feedback rating
}

Actions:

1. Run test question validation (target: >90% accuracy)
2. Conduct human review (sample 10% of entries)
3. Fix detected issues (duplicates, conflicts, staleness)
4. Establish monitoring dashboards

Validation:

• Accuracy >90% on test questions
• Coverage >80% of user questions
• <5% conflicting information
• Monitoring dashboard operational

---

Phase 5: Versioning & Evolution

Goal: Track knowledge changes over time and enable rollback

Why Versioning Matters:

• Knowledge changes (facts update, policies change)
• Need audit trail (who changed what when)
• Rollback capability (undo bad updates)
• Historical queries ("What was policy on X in 2023?")

Versioning Strategies:

1. Snapshot Versioning

interface KnowledgeEntry {
  id: string
  content: string
  version: number
  created_at: string
  updated_at: string
  updated_by: string
  changelog: string
  previous_version?: string // ID of prior version
}

2. Event Sourcing

interface KnowledgeEvent {
  event_id: string
  entity_id: string
  event_type: 'created' | 'updated' | 'deleted'
  timestamp: string
  changes: {
    field: string
    old_value: any
    new_value: any
  }[]
  author