> ## Documentation Index
> Fetch the complete documentation index at: https://noorle.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Knowledge Bases & RAG
> How documents become searchable chunks, the two ways an agent reaches them, and what reranking actually does
A **knowledge base** is a collection of documents you upload. Its contents are chunked, embedded, and indexed so an agent can search them by meaning rather than by keyword — and answer from your material instead of from the model's training data.
This is a different system from [memory](/docs/learn/concepts/memory-system). Memory is what the agent has learned about a conversation or a user. Knowledge is what you gave it to read.
## The pipeline
```mermaid theme={null}
graph LR
D["Document"] --> E["Extract to markdown"]
E --> C["Split into chunks"]
C --> Em["Embed each chunk"]
Em --> Q["Index in the vector store"]
```
Documents are extracted to markdown, split into chunks, embedded, and stored in a per-account vector collection.
Chunking is token-based and sized against the embedding model's capacity, with a small overlap between adjacent chunks so a sentence spanning a boundary is not lost. Chunks below a minimum size are not embedded on their own.
Which **embedding model** is used is an account-level indexing setting rather than a fixed platform property. New accounts start on `text-embedding-3-small`. The vector dimension follows from the model you are on.
Chunk size, overlap, and the minimum embedding size are platform-level and derived from the embedding model's capacity. They are not per-knowledge-base settings.
## Two ways an agent reaches knowledge
This is the distinction that matters when you configure an agent, and the two are independent.
### Attach the knowledge base to the agent
List knowledge bases on the agent, and relevant chunks are retrieved and injected into context **automatically at the start of each run**. The agent does not decide to search; the search happens.
Defaults for that automatic retrieval: at most **10** chunks, with a minimum relevance score of **0.15**. A per-knowledge-base `max_results` can lower the cap.
Use this when the material is always relevant — product documentation for a support agent, policies for a compliance assistant.
### Bind the Knowledge Retrieval capability
Bind `KnowledgeRetrieval` and the agent gets three tools it can call when it decides to: `search`, `list`, `get_by_id` — namespaced `knowledge_search`, `knowledge_list`, `knowledge_get_by_id`.
Use this when lookups are occasional and the agent should choose the query.
### Both together
They compose. Attached bases give every turn a baseline of context; the capability lets the agent go looking for something specific on top of that. A common shape is to attach the one base that is always relevant and bind the capability for everything else.
## Reranking
Vector similarity gets you close. It also confidently returns things that are *about* the right topic but do not answer the question.
Reranking adds a second pass: fetch more candidates than you need, then have a small model order them against the actual query and keep the top slice.
| Setting | Value |
| ------------------------------- | ---------------------------------------------- |
| Enabled by default | Yes |
| Model | `gpt-5.6-luna` |
| Over-fetch multiplier | **3×** the requested limit, then reranked down |
| Chunk text sent to the reranker | truncated to **500 characters** per chunk |
Reranking can be overridden per account and per knowledge base. A knowledge base that leaves it unset inherits the account setting, which in turn inherits the platform setting.
The trade is latency and a small model call per search. For a support agent answering from policy text it is usually worth it; for a high-volume lookup where the top vector hit is reliably right, it may not be.
## What semantic search buys you
| Question a user actually asks | Keyword match | Semantic match |
| ------------------------------------ | -------------------------------------------- | -------------- |
| "Can I get my money back?" | misses a document titled *Refund policy* | finds it |
| "how long do I have to send it back" | misses *Returns are accepted within 60 days* | finds it |
The embedding puts the question and the passage near each other in vector space even when they share no words. That is the whole trick, and it is why chunk boundaries matter: a chunk that mixes three topics embeds to the average of three topics and matches none of them well.
## Managing knowledge bases
In the Portal, **Knowledge Bases** is its own section. Create a base, upload documents, and ingest runs in the background — the Portal receives a live hint when it completes.
Removing a document removes its chunks from the index.
## Costs
Indexing and storage are metered. See [Pricing](https://noorle.com/pricing/).
## Practical guidance
Splitting product docs, policies, and runbooks into separate bases lets you attach only what an agent needs and keeps retrieval focused.
Automatic injection costs tokens on every turn. Attach the base an agent needs every time; use the capability for the rest.
If results are topically right but not answer-right, turn on reranking before you touch anything else.
A confidently retrieved stale policy is worse than no retrieval. Re-upload when the source changes.
***
Next: [Tool Presentation](/docs/learn/concepts/tool-presentation) — controlling how many tools a model sees.