---
title: "SuperRAG (managed RAG as a service)"
sidebarTitle: "SuperRAG"
description: "Supermemory provides a managed RAG solution - extraction, indexing, storing, and retrieval."
icon: "/icons/hugeicons/flash.svg"
---
Supermemory doesn't just store your content—it transforms it into optimized, searchable knowledge. Every upload goes through an intelligent pipeline that extracts, chunks, and indexes content in the ideal way for its type.
## Automatic content intelligence
When you add content, Supermemory:
1. **Detects the content type** — PDF, code, markdown, images, video, etc.
2. **Extracts content optimally** — Uses type-specific extraction (OCR for images, transcription for audio)
3. **Chunks intelligently** — Applies the right chunking strategy for the content type
4. **Generates embeddings** — Creates vector representations for semantic search
5. **Builds relationships** — Connects new knowledge to existing memories
```typescript
// Just upload — Supermemory handles the rest
await supermemory.documents.uploadFile("docs_kb", {
file: fs.createReadStream('technical-documentation.pdf'),
metadata: JSON.stringify({ title: "Technical Documentation" }),
});
```
No chunking strategies to configure. No embedding models to choose. It just works.
---
## Ingesting as pure SuperRAG (`taskType: "superrag"`)
By default, every `supermemory.add()` call runs on the **memory** path (`taskType: "memory"`): Supermemory chunks and embeds the content for retrieval, *and* runs it through the memory pipeline — extracting facts, updating the profile, and linking it into the knowledge graph.
If you're ingesting content that's purely reference material — documentation, a large PDF, a knowledge base article — and you don't need Supermemory to derive personal facts or update a profile from it, set `taskType: "superrag"` in the request body. It skips the memory pipeline entirely and only does the chunk → embed → index work needed to make the content searchable.
```typescript TypeScript
await supermemory.add("docs_kb", { // e.g. a long internal wiki page
content: "...",
taskType: "superrag",
});
```
```python Python
client.add(
"docs_kb",
content="...", # e.g. a long internal wiki page
task_type="superrag",
)
```
```bash cURL
curl -X POST "https://api.supermemory.ai/ns/docs_kb/document" \
-H "Authorization: Bearer $SUPERMEMORY_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "content": "...", "taskType": "superrag" }'
```
| | `taskType: "memory"` (default) | `taskType: "superrag"` |
|---|---|---|
| Chunking, embedding, indexing | ✅ | ✅ — searchable immediately via `searchMode: "chunks"` |
| Fact extraction into memories | ✅ | ❌ skipped |
| Profile (`static`/`dynamic`/buckets) updates | ✅ | ❌ skipped |
| Graph linking (updates/extends/derives) | ✅ | ❌ skipped |
| Price per ingested token | Full rate | **5x cheaper** |
`taskType: "superrag"` is a **5x discount on ingested tokens** — `sm_superrag_text`/`sm_superrag_rich` are priced at 20% of `sm_tokens_text`/`sm_tokens_rich`. See [Billing → Memory vs SuperRAG tokens](/overview/billing#memory-vs-superrag-tokens) for the exact rates.
Content ingested as `superrag` is retrievable via chunk search (`searchMode: "chunks"`), but it will **never** surface as a memory, contribute to a user's profile, or connect into the knowledge graph. Use it for reference material you want searchable, not for anything that should shape what Supermemory knows about a user — that still needs the default `taskType: "memory"`.
When you're searching over a mix of both, `searchMode: "hybrid"` (below) is what pulls memory-path facts and superrag-path document chunks into one result set. More ingestion guidance: [Rules of supermemory → Ingest with SuperRag when you just need search](/concepts/rules#ingest-with-superrag-when-you-just-need-search).
---
## Smart chunking by content type
Different content types need different chunking strategies. Supermemory applies the optimal approach automatically:
### Documents (PDF, DOCX)
PDFs and documents are chunked by **semantic sections** — headers, paragraphs, and logical boundaries. This preserves context better than arbitrary character splits.
```
├── Executive Summary (chunk 1)
├── Introduction (chunk 2)
├── Section 1: Architecture
│ ├── Overview (chunk 3)
│ └── Components (chunk 4)
└── Conclusion (chunk 5)
```
### Code
When content is recognized as Markdown, fenced code blocks are kept whole when they fit in a chunk. Larger blocks are split and re-wrapped in the original fence, including its language tag. Overlap can contain part of a previous line, so chunks are not guaranteed to be independently valid code.
Raw source files and content not recognized as Markdown use plain-text chunking. A lone fenced block may not be enough for automatic Markdown detection.
### Web pages
URLs are fetched, cleaned of navigation/ads, and chunked by article structure — headings, paragraphs, lists.
### Markdown
Chunked by heading hierarchy, preserving the document structure.
See [Content Types](/concepts/content-types) for the full list of supported formats.
---
## Hybrid memory + RAG
Supermemory combines the best of both approaches in every search:
- Finds similar document chunks
- Great for knowledge retrieval
- Stateless — same results for everyone
- Extracts and tracks user facts
- Understands temporal context
- Personalizes results per user
With `searchMode: "hybrid"` (the default), you get both:
```typescript
const results = await supermemory.search("user_123", {
query: "how do I deploy the app?",
searchMode: "hybrid",
});
// Returns:
// - Deployment docs from your knowledge base (RAG)
// - User's previous deployment preferences (Memory)
// - Their specific environment configs (Memory)
```
---
## Search optimization
Two flags give you fine-grained control over result quality:
### Reranking
Re-scores results using a cross-encoder model for better relevance. `rerank` takes `"none"` (default), `"order"`, or `"aggregate"`:
```typescript
const results = await supermemory.search("user_123", {
query: "complex technical question",
rerank: "order", // +~100ms, significantly better ranking
});
```
**When to use:** Complex queries, technical documentation, when precision matters more than speed.
### Query rewriting
Expands your query to capture more relevant results:
```typescript
const results = await supermemory.search("user_123", {
query: "how to auth",
rewriteQuery: true, // Expands to "authentication login oauth jwt..."
});
```
**When to use:** Short queries, user-facing search, when recall matters.
---
## Why it's "Super"
| Traditional RAG | SUPER RAG |
|-----------------|-----------|
| Manual chunking config | Automatic per content type |
| One-size-fits-all splits | AST-aware code chunking |
| Just document retrieval | Hybrid memory + documents |
| Static embeddings | Relationship-aware graph |
| Generic search | Rerank + query rewriting |
You focus on building your product. Supermemory handles the RAG complexity.
---
## Next steps
All supported formats and how they're processed
The full processing pipeline
When to use each approach
Search parameters and optimization
Exact meter rates for memory vs SuperRAG tokens
`taskType` and other ingestion parameters