level-1-essentials/company/06-rag-knowledge-base/README.md

06 — RAG Knowledge Base

The retrieval layer. Where department copilots get their grounded facts.

Files

• knowledge-base-structure.md — folder taxonomy, document standards, refresh rules
• chunking-strategy.md — how to split documents before embedding
• permissions-model.md — how to enforce source-system ACLs through retrieval

Non-negotiables

1. One canonical source per topic
2. Every doc has an owner and review date
3. Permissions match source system
4. Every chunk has classification metadata
5. Adversarial retrieval tests before ship

level-1-essentials/company/06-rag-knowledge-base/chunking-strategy.md

Chunking Strategy

How to split documents before embedding. Get this wrong and RAG is useless.

The default recipe

• Chunk size: 500 tokens (target)
• Chunk overlap: 100 tokens (20%)
• Split on: heading boundaries first, then paragraphs, then sentences
• Preserve: section titles as prefixes in each chunk
• Minimum chunk: 100 tokens (smaller merges into neighbor)
• Maximum chunk: 1000 tokens (larger splits at sentence boundary)

Variant strategies

Semantic chunking

Group sentences by embedding similarity, split when similarity drops below threshold. Slower to compute but better retrieval quality on prose-heavy corpora.

Sliding window

Fixed-size windows with heavy overlap (50%). Good for narrow question-answer patterns. Wasteful on storage.

Recursive splitting

Try to split on \n\n, then \n, then ., then space. Falls back gracefully.

Document-type-aware

• Code files: split on function/class boundaries
• Markdown: split on H2/H3 boundaries
• PDFs: extract by page, then apply text splitting
• Slides: one slide = one chunk (or a group of related slides)
• Spreadsheets: rows or logical groups; consider text-serialization

Chunk metadata

Every chunk carries:

{
  "chunk_id": "sales-playbook-v3::obj-pricing::0",
  "doc_id": "sales-playbook-v3",
  "section_path": ["Objections", "Pricing"],
  "chunk_index": 0,
  "chunk_count": 5,
  "prev_chunk_id": null,
  "next_chunk_id": "sales-playbook-v3::obj-pricing::1",
  ... [all doc-level metadata inherited] ...
}

Pre-embedding cleaning

Before embedding, strip / normalize: - Boilerplate headers/footers - Watermarks - Extra whitespace - Repeated navigational text - Table of contents entries (dedupe against body) - Signatures and email routing

Contextual retrieval

Anthropic-recommended pattern: prepend each chunk with a short LLM-generated context summary (50–100 tokens) that says "This chunk is from [doc] discussing [topic]. Prior context is: [summary]." Improves retrieval by 30-50% but adds cost.

Multi-representation

Store multiple representations of each chunk: - Raw text (as-is) - Cleaned text (whitespace normalized) - Summary (LLM-generated 1-line summary — searched with a different embedding) - Entities extracted (for filter-based retrieval)

Retrieve using summary embeddings, return raw text.

Verification

For any RAG deployment, verify chunking with:

1. Random inspection — sample 20 chunks. Are they self-contained? Do they include enough context?
2. Reconstruction test — retrieve the top 5 chunks for a real question. Does the LLM produce a correct answer?
3. Ground-truth eval — for known answers, does the retrieval find the right chunk in top-5?

If retrieval@5 is below 80%, chunking or embedding needs work.

level-1-essentials/company/06-rag-knowledge-base/knowledge-base-structure.md

Knowledge Base Structure

The KB is the foundation of every department copilot. Structure it right and RAG works. Structure it wrong and it hallucinates.

Organizing principle

One canonical source per topic. Every piece of information should live in exactly one authoritative document. Copies decay.

Folder structure

knowledge-base/
├── 01-company-fundamentals/
│   ├── mission-values.md
│   ├── org-chart.md
│   ├── glossary.md
│   ├── brand-voice-guide.md
│   └── policies/
│       ├── acceptable-use-policy.md
│       ├── data-classification-matrix.md
│       ├── code-of-conduct.md
│       └── ...
├── 02-product/
│   ├── product-overview.md
│   ├── feature-catalog.md
│   ├── roadmap-published.md
│   ├── api-reference/
│   └── release-notes/
├── 03-customers/
│   ├── icp-profiles.md
│   ├── personas.md
│   ├── approved-case-studies/
│   └── customer-list-approved-for-reference.md
├── 04-competition/
│   ├── landscape-map.md
│   └── battle-cards/
├── 05-sales/
│   ├── playbook.md
│   ├── pricing-sheet.md
│   ├── objection-handling.md
│   ├── email-templates/
│   └── ...
├── 06-marketing/
│   ├── style-guide.md
│   ├── messaging-house.md
│   ├── content-calendar.md
│   └── ...
├── 07-engineering/
│   ├── architecture-overview.md
│   ├── coding-standards.md
│   ├── runbooks/
│   ├── postmortems/
│   └── ...
├── 08-support/
│   ├── kb-articles/
│   ├── escalation-matrix.md
│   └── ...
├── 09-legal-compliance/
│   ├── standard-nda.md
│   ├── msa-template.md
│   ├── privacy-policy.md
│   └── ...
├── 10-hr/
│   ├── handbook.md
│   ├── benefits.md
│   └── ...
├── 11-finance/
│   ├── chart-of-accounts.md
│   ├── budget-model.xlsx
│   └── ...
└── 99-archived/
    └── [retired docs with dates]

Document standards

Every document has:

---
title: [Title]
owner: [Name / Role]
last_reviewed: YYYY-MM-DD
next_review: YYYY-MM-DD
classification: [Public / Internal / Confidential / Restricted]
tags: [array]
version: X.Y
---

# Title

[Content]

Chunking-friendly writing

Write documents so they chunk well for RAG:

• H2 sections break at natural knowledge units
• One idea per section — don't cover multiple topics in one section
• Self-contained sections — a section should stand alone when retrieved out of context
• Explicit terminology — spell out acronyms first use per section
• Concrete examples included where relevant
• No inline "see above" or "as mentioned" — those break when the chunk is retrieved standalone

Metadata for filtering

Every chunk carries metadata for filtered retrieval:

{
  "doc_id": "sales-playbook-v3",
  "section": "objection-handling-pricing",
  "classification": "internal",
  "department": "sales",
  "last_reviewed": "2026-08-01",
  "tags": ["objection", "pricing"],
  "permissions_group": "all-employees"
}

Retrieval filters: - Copilot only retrieves chunks the user is authorized to see (permissions_group) - Only current (not archived) unless user asks for history - Only classification appropriate to the current session tool

What NOT to put in the KB

• Personal drafts
• Ephemeral status updates
• Duplicates (any information more than once is wrong)
• Anything > 18 months old without explicit re-review
• Unstructured chat logs
• Deprecated processes without archived tag
• Individual PII of employees or customers beyond what's business-critical
• Content that could go stale within a week

Refresh rules

• Every doc has next_review — after that date, either re-approve or archive
• Doc owner gets a monthly digest of docs coming due
• Any change to a policy triggers a KB update within 5 business days
• Retired docs move to 99-archived/ with a redirect stub in the original location if links exist

level-1-essentials/company/06-rag-knowledge-base/permissions-model.md

RAG Permissions Model

RAG that ignores permissions leaks confidential data. This is the top RAG security issue.

Principle

The RAG system enforces the same permissions as the source documents.

If a user can't see the source doc in Google Drive / Confluence / SharePoint, they can't see it via RAG either.

Implementation patterns

Pattern 1 — Permissioned namespaces (best for scale)

• Each user or role has a namespace of chunks they're authorized for
• Query only searches the user's namespaces
• Requires syncing permissions from source system to vector DB at ingest time
• Requires re-sync when permissions change (nightly or event-driven)

Pattern 2 — Post-retrieval filtering

• All chunks are indexed together
• After retrieval, filter out chunks the user isn't authorized for
• Simpler but leaks information via retrieval score signals if not careful
• Not recommended for high-sensitivity environments

Pattern 3 — Query-time authorization

• Attach user identity to every query
• Vector DB filters by ACL metadata during retrieval
• Requires ACL as metadata on every chunk
• Supported by Pinecone, Weaviate, Qdrant natively

ACL metadata

Every chunk carries:

{
  "permissions": {
    "read_roles": ["all-employees", "sales-team"],
    "read_users": ["alice@co.com"],
    "confidential": true,
    "source_system_acl_ref": "gdrive-file-123"
  }
}

Rules: - Union of role membership and explicit user grants - Never OR-across roles for confidential — require the specific role - Denial by default

Source-system sync

For each connected source (Drive, Notion, SharePoint, Confluence, GitHub):

• Sync file metadata daily (permissions, last_modified, ACLs)
• Re-embed on content change
• Remove from index on delete
• Update ACLs on permissions change (within 1 hour target)

User identity

Every query includes: - Authenticated user identity (via SSO) - Their role(s) at query time (fresh, not cached) - Any context restrictions (e.g., "this session is for external customer response — restrict to public and internal only")

Auditing

Log for every retrieval: - Timestamp - User identity - Query (redacted for PII) - Chunks retrieved - Chunks filtered (permissions denied) - Response generated (redacted)

Retain per policy (typically 90 days minimum for security review).

Testing

Every RAG deployment has these red-team tests:

1. Direct ask: User A queries for content in a doc User A can't see. Must return "not found" or refusal, not the content.
2. Indirect ask: User A queries for the topic of a restricted doc. Must not surface the restricted doc's information.
3. Permission change: After removing User A from a group, they can't retrieve previously-authorized content.
4. Injection: Adversarial input in a document tries to override permission checks.

Run these tests before every RAG deployment, and quarterly thereafter.