> Source: https://builder.ema.ai/v2/core-concepts/knowledge-bases > Title: Knowledge Bases # Knowledge Bases A **knowledge base** (KB) is a private collection of documents that an AI Employee's [agents](/builder/v2/core-concepts/agents) can search at run time. When an agent needs grounding — answering from your policies, your product docs, your help center — it retrieves the most relevant passages from its attached knowledge bases and reasons over them. This is **retrieval-augmented generation (RAG)**: the model's answer is grounded in your content, and it can cite the exact sources it used. A knowledge base belongs to exactly one AI Employee. It is scoped by `ai_employee_id`, so a KB's content is only ever searched by the AI Employee that owns it. ## How a knowledge base works Documents flow through an ingestion pipeline, then become searchable: 1. **Connect or upload.** A KB draws its documents from a connector (SharePoint, Google Drive, Confluence, Box, ServiceNow) or from direct file uploads. 2. **Extract.** The pipeline extracts text from each document, including PDFs and Office files (.docx, .xlsx, .pptx). 3. **Chunk.** The text is split into overlapping chunks — by default about **1024 tokens** per chunk with **128 tokens** of overlap — so each chunk is small enough to embed and large enough to carry meaning. Overlap keeps context from being cut at chunk boundaries. 4. **Embed.** Each chunk is turned into a vector embedding by EmaFusion™. The embedding model is a platform-level setting shared by all tenants. 5. **Store.** Chunks and their embeddings are stored in a vector index, with the document's folder path kept alongside for filtering. Once a document finishes ingesting, its chunks are immediately searchable. > [INFO] > **Connections and KBs are managed by administrators.** Source _connections_ (the credentials for SharePoint, Drive, and so on) and _knowledge bases_ are created by administrators. As a builder, you select from the knowledge bases available to your AI Employee and scope them with a folder filter — you never handle credentials. ## Retrieval at run time (RAG) When an agent with attached knowledge bases runs, the platform performs a vector search: 1. The agent's query is embedded with the same model used for the documents. 2. The platform runs an approximate-nearest-neighbor search (an HNSW index) over the KB's chunks using **cosine similarity** (similarity = `1 − distance`). 3. Chunks scoring below the agent's `min_score` floor (default 0.15) are dropped, and the top `top_k` matches that remain are ranked by similarity and injected into the agent's context with numbered source labels so the model can cite them. Retrieval is tunable per agent through its `type_config`. Values outside the valid range are ignored and fall back to the default: Parameter Default Range Notes `top_k` (chunks returned) 20 1–50 How many chunks the agent retrieves. Out-of-range values fall back to the default. `min_score` (similarity floor) 0.15 0.05–0.95 Chunks below this cosine-similarity score are dropped. Knowledge bases per agent — — An agent can search several KBs in one query. The **Search & Respond** agent type is built around this loop and cites its sources automatically. See [Agents](/builder/v2/core-concepts/agents#search--respond). ## Folders and the folder filter Documents carry a **folder path** from their source. You can scope an agent's retrieval to a subset of a knowledge base with a **folder filter** — a path prefix the search must match. The folder filter is applied at **search time**, not at ingestion time. That has two practical consequences: - Adding or changing a folder filter on an agent node takes effect on the next run, with no re-ingestion. - One knowledge base can serve several agents, each scoped to a different folder. For example, a single "Company Docs" KB might back an HR agent filtered to `policies/hr/` and a finance agent filtered to `policies/finance/`, with no duplicate ingestion. ## Search and extraction knowledge bases A knowledge base has an **intent** that determines how its content is prepared: - **Search** (the default) — content is chunked, embedded, and indexed for vector retrieval. This is what RAG agents query. - **Extraction** — the full extracted text is stored as a single LLM-ready document, with no chunking or embedding. Use this when an agent needs the whole document (for example, an Extraction agent reading an uploaded file) rather than retrieved passages. ## How a knowledge base stays current - **Connector sync** keeps a KB aligned with its source. Sync runs on a schedule (or on demand) and uses incremental change detection so unchanged documents aren't re-processed. - **Document triggers** can run a workflow when a document finishes ingesting in an attached KB — useful for pipelines that act on newly added content. The run executes against the AI Employee's live published version. - **Version snapshots** capture which documents a workflow version searched, so reverting a published version reconciles the KB back to that state. See [Workflows](/builder/v2/core-concepts/workflows#drafts-versions-and-publishing). ## Where to go next - [Agents](/builder/v2/core-concepts/agents) — how the Search & Respond agent uses knowledge bases. - [Integrations and data](/builder/v2/integrations-data) — connecting sources and managing knowledge bases. - [EmaFusion™](/builder/v2/emafusion) — the model layer that embeds documents and queries.