> ## 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 as well as 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={"dark"}
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.
## How a search runs
A query is run two ways at once against the same collection:
* **Dense** — the query is embedded and matched against chunk embeddings by meaning.
* **Sparse** — the query is turned into BM25 term weights and matched on the terms themselves.
The two rankings are combined with reciprocal rank fusion in a single request to the vector store. Reranking, when it is on, runs on the fused list.
Where the document has them, the chunks immediately before and after a match are joined into the passage that comes back, so a hit does not arrive stripped of the lines around it.
The dense leg is what lets a question find a passage it shares no words with:
| Question a user actually asks | Terms alone | With the dense leg |
| - | - | - |
| "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. That is why chunk boundaries matter: a chunk that mixes three topics embeds to the average of three topics and matches none of them well.
## Reranking
Fused ranking 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 is one account-wide switch — **Knowledge reranker**, under Settings → Features — sitting beneath a platform-level enable. A search is reranked when both are on. There is no per-knowledge-base override; the only per-knowledge-base search setting is `max_results`.
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 hit is reliably right, it may not be.
## 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.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.