SuperRAG (Managed RAG as a service)

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:

Detects the content type — PDF, code, markdown, images, video, etc.
Extracts content optimally — Uses type-specific extraction (OCR for images, transcription for audio)
Chunks intelligently — Applies the right chunking strategy for the content type
Generates embeddings — Creates vector representations for semantic search
Builds relationships — Connects new knowledge to existing memories

// Just upload — Supermemory handles the rest
await client.documents.uploadFile({
  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 client.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". It skips the memory pipeline entirely and only does the chunk → embed → index work needed to make the content searchable.

await client.add({
  content: "...", // e.g. a long internal wiki page
  containerTag: "docs_kb",
  taskType: "superrag",
});

client.add(
    content="...",
    container_tag="docs_kb",
    task_type="superrag",
)

curl -X POST "https://api.supermemory.ai/v3/documents" \
  -H "Authorization: Bearer $SUPERMEMORY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "...",
    "containerTag": "docs_kb",
    "taskType": "superrag"
  }'

	`taskType: "memory"` (default)	`taskType: "superrag"`
Chunking, embedding, indexing	✅	✅ — searchable immediately via `searchMode: "documents"`
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 for the exact rates.

Content ingested as superrag is retrievable via document search (searchMode: "documents"), 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.

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

Code is chunked using code-chunk, our open-source library that understands AST (Abstract Syntax Tree) boundaries:

Functions and methods stay intact
Classes are chunked by method
Import statements grouped separately
Comments attached to their code blocks

// A 500-line file becomes meaningful chunks:
// - Imports + type definitions
// - Each function as a separate chunk
// - Class methods individually indexed

This means searching for “authentication middleware” finds the actual function, not a random slice of code.

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 for the full list of supported formats.

Hybrid Memory + RAG

Supermemory combines the best of both approaches in every search:

Traditional RAG

Finds similar document chunks
Great for knowledge retrieval
Stateless — same results for everyone

Memory System

Extracts and tracks user facts
Understands temporal context
Personalizes results per user

With searchMode: "hybrid" (the default), you get both:

const results = await client.search({
  q: "how do I deploy the app?",
  containerTag: "user_123",
  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:

const results = await client.search({
  q: "complex technical question",
  rerank: true  // +~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:

const results = await client.search({
  q: "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

Content Types

All supported formats and how they’re processed

How It Works

The full processing pipeline

Memory vs RAG

When to use each approach

Search

Search parameters and optimization

Billing

Exact meter rates for memory vs SuperRAG tokens

Adding Memories

taskType and other ingestion parameters

Getting Started

Concepts

Using supermemory

Deployment

Other resources

Migration Guides

Automatic Content Intelligence

Ingesting as pure SuperRAG (`taskType: "superrag"`)

Smart Chunking by Content Type

Documents (PDF, DOCX)

Code

Web Pages

Markdown

Hybrid Memory + RAG

Traditional RAG

Memory System

Search Optimization

Reranking

Query Rewriting

Why It’s “Super”

Next Steps

Content Types

How It Works

Memory vs RAG

Search

Billing

Adding Memories

​Automatic Content Intelligence

​Ingesting as pure SuperRAG (taskType: "superrag")

​Smart Chunking by Content Type

​Documents (PDF, DOCX)

​Code

​Web Pages

​Markdown

​Hybrid Memory + RAG

Traditional RAG

Memory System

​Search Optimization

​Reranking

​Query Rewriting

​Why It’s “Super”

​Next Steps

Content Types

How It Works

Memory vs RAG

Search

Billing

Adding Memories

Automatic Content Intelligence

Ingesting as pure SuperRAG (`taskType: "superrag"`)

Smart Chunking by Content Type

Documents (PDF, DOCX)

Code

Web Pages

Markdown

Hybrid Memory + RAG

Search Optimization

Reranking

Query Rewriting

Why It’s “Super”

Next Steps