Ragrig — RAG framework for Research and Prototyping

A trait-driven Retrieval-Augmented Generation library built around three independently swappable AI agents — Embed, Memory, and Chat — each behind a Rust trait that allows hot-swapping backends at runtime.

Designed for students and researchers. The default build compiles with zero external dependencies — no C++ toolchain, no cmake, no protoc. Install Rust, install Ollama, and you're done.

🔧 ragrig is the library crate. The terminal REPL binary lives in ragrig‑cli — install with cargo install ragrig-cli (on crates.io soon) or clone from GitHub. Build your own application on top of the same traits the REPL uses.

• Zero extra dependencies — default build is pure Rust; Ollama provides models at runtime
• Trait-driven — every pipeline stage is a Box<dyn Trait>; add new backends (OpenAI, Anthropic, Groq, …) or document parsers without touching existing code
• Hardware-aware — delegate heavy models to the cloud, run small models locally, or go fully offline with CPU-only Fastembed (compiled into the binary)
• Hot-swappable — switch chat, memory, or embedding engines at runtime without losing document index or conversation context
• Token-efficient cloud usage — use a tiny local model for query rewriting and only send the final prompt + context to an expensive cloud API
• Hybrid retrieval — BM25 full-text search fused with cosine vector similarity via Reciprocal Rank Fusion. Hot-swappable ranking algorithms (RRF, weighted linear, MMR diversity, LLM re-rank) let you experiment with retrieval strategies without changing your document index
• Pluggable ranking — the Ranker trait decouples scoring from storage; compare Cosine vs. BM25 vs. RRF fusion on the same document set at runtime
• Cross-platform — Linux, macOS, WSL, and Windows (MSVC / MinGW)

---

What is RAG?

Retrieval-Augmented Generation lets an LLM answer questions about documents it has never seen before. Instead of stuffing every document into the prompt (which would overflow the context window), RAG works in two phases:

1. Indexing — Documents are split into overlapping chunks, each chunk is converted to a numeric embedding vector (a list of floats that captures its meaning), and both the text and its vector are saved in a vector store.

2. Querying — When you ask a question, the same embedding model converts your query to a vector. The store finds the k most similar chunks (via cosine similarity, BM25 keyword matching, or a hybrid of both). Those chunks are injected into the LLM prompt alongside your question, so the model can ground its answer in your documents.

Ragrig wraps this pipeline in three swappable agents — Embed (vectorise), Memory (optionally rewrite the query for better retrieval), and Chat (generate the final answer). The diagram below shows how data flows through the system:

flowchart TD
    U[User query] --> M[Memory]
    M -->|rewritten query| E[Embed]
    E -->|query vector| V[(Vector Store)]
    V -->|top-k chunks| C[Chat]
    U -->|original query| C
    C -->|grounded answer| R[Response]

If you are new to these concepts, a more detailed introduction can be found at retrieval-augmented-generation on the Prompt Engineering Guide.

Quick Start (Library)

Add ragrig to your Cargo.toml:

[dependencies]
ragrig = "0.9"

You need two things

1. Rust — rustup.rs
2. Ollama — ollama.com/download (provides models at runtime)

Pull the models you need:

ollama pull gemma2:latest           # chat
ollama pull nomic-embed-text        # embeddings

Index and query in 4 function calls

use ragrig::{
    embed::EmbedderSpec,
    agents::ChatAgentSpec,
    parsers::{DocumentParsers, build_parsers},
    store::open_store,
    types::ChunkConfig,
    vector::{collect_documents, search_similar},
};
use std::path::Path;

let embedder = EmbedderSpec::Ollama { model: "nomic-embed-text".into() }.build()?;
let chat = ChatAgentSpec::Ollama { model: "gemma2:latest".into(), params: Default::default() }.build()?;
let parsers = DocumentParsers::new(build_parsers());
let store = open_store(Path::new("./my_docs")).await?;

// Index
collect_documents(&*embedder, &parsers, Path::new("./my_docs"), &ChunkConfig::default(), &*store).await?;

// Search
let results = search_similar(&*embedder, 5, 0.0, &*store, "quantum computing").await?;

// Generate
chat.generate("Summarise the following:\n\n...").await?;

Model parameters

Control generation with GenerationParams:

use ragrig::{agents::ChatAgentSpec, GenerationParams};

let agent = ChatAgentSpec::Ollama {
    model: "qwen3.5:9b".into(),
    params: GenerationParams {
        temperature: Some(0.1),  // near-deterministic
        seed: Some(42),          // reproducible runs
        ..Default::default()
    },
}.build()?;

See examples/pseudonymizer for a complete multi-turn pseudonymization loop.

Three-Agent Architecture

Every pipeline stage is a trait object — swap any agent at runtime without losing your document index or conversation memory.

Documents (PDF/EPUB/DOCX/HTML)
    │
    ▼
chunkedrs — token-accurate splitting with overlap
    │
    ├── Embedder trait ──────────────────────────────────────────┐
    │   OllamaEmbedder       (local, nomic-embed-text)           │
    │   FastembedEmbedder    (CPU-only, Nomic-Embed-Text-v1.5)   │
    │   NoopEmbedder         (pure chat, no document search)     │
    │                                                             │
    ▼                                                             │
VectorStore trait ────────────────────────────────────────────────┤
    BruteForceStore   (pure Rust, MessagePack on disk)  ← default │
    LanceDbStore      (Arrow columnar, hybrid BM25+vector)        │
    │                                                             │
    ▼                                                             │
Query                                                                    
    │                                                                    
    ▼                                                                    
Memory strategy (MemoryStrategy trait) ← hot-swap: /memory
    RewriteMemory / TranscriptMemory                                   
    │                                                                    
    ▼                                                                    
Embed → VectorStore.search → Ranker → top-k chunks                   
    │                                                                    
    ▼                                                                    
Chat agent (Generator trait)           ← hot-swap: /chat                
    OllamaGenerator / DeepSeekGenerator                                   
    │                                                                    
    ▼                                                                    
Streamed response with retrieved context + conversation memory           

Hybrid Search Tuning

The vector store uses Reciprocal Rank Fusion (RRF, k=60) to combine cosine vector similarity with BM25 full-text search. Two parameters control retrieval quality:

Parameter	Default	What it does
top_k	50	Maximum chunks injected into the prompt
similarity_threshold	0.04	Cosine pre‑filter — chunks with cosine < threshold are excluded from RRF fusion

Understanding the threshold:

• The threshold operates on cosine similarity (range: 0.0–1.0).
• RRF fusion produces scores in the 0.0–0.03 range (rank‑based, not similarity‑based). The trace output shows RRF scores, not cosine scores.
• A threshold of 0.0 passes everything; 0.04 filters out chunks with negligible vector overlap while letting BM25 keyword matches through.
• Values above ~0.05 will aggressively prune — use when you have high‑quality embeddings and want strictly semantic results.

Tune at runtime:

Query > /search                      # show current values
Query > /search topk 10              # fewer chunks, tighter context
Query > /search threshold 0.08       # stricter semantic filter

Hot-Swap Examples

Start with everything local, switch chat to cloud mid-session:

Query > /chat deepseek deepseek-chat sk-...
Chat agent swapped: Ollama (gemma2:latest) → DeepSeek (deepseek-chat)

Forgetful mode — ask Alice's name, then make her forget:

Query > My name is Alice
Assistant > Nice to meet you, Alice!

Query > /memory off
Memory disabled (was: Ollama qwen2.5:1.5b)

Query > What's my name?
Assistant > I don't know — you haven't told me yet.

Raw transcript — no query rewriting, test context-window pressure:

Query > /memory transcript
Memory strategy: rewrite → transcript

Query > What is a vector database?
Assistant > A vector database stores embeddings ...

Query > Can you summarize that?
# "that" is NOT rewritten — the raw transcript in the prompt
# provides context.  Good for testing how models handle growing
# context windows with full conversation memory appended.

Session persistence — exit, restart, and recall past context:

Query > What are random effects in meta-analysis?
Assistant > Random effects models assume that the true effect size
varies across studies, as opposed to a single fixed effect …

Query > /exit
# next day …

$ ragrig --folder ~/papers
Session: 1718400000

Query > /memory log
History diffusion: off → log

Query > What was I asking about yesterday?
# The chat prompt now includes the raw transcript of the previous
# session, so the model can pick up the thread without you
# repeating yourself.
Assistant > Yesterday you asked about random effects in
meta-analysis.  We discussed how they differ from fixed-effect
models …

Pure chat — no document search, no memory, cloud-only:

Query > /embed none
Query > /memory off
Query > /chat deepseek deepseek-v4-pro
Query > Explain quantum entanglement in one paragraph.

Switch embeddings to CPU-only (no network):

Query > /embed fastembed
Embedder swapped: Ollama (nomic-embed-text) → Fastembed (Nomic-Embed-Text-v1.5)

Experiment with ranking algorithms — same index, different retrieval:

Query > /search rank Cosine
Ranker set to Cosine.

Query > /search rank BM25
Ranker set to BM25.

Query > /search rank Weighted alpha 0.7
Ranker set to Weighted.

Query > /search rank MMR lambda 0.7 inner Cosine
Ranker set to MMR.

Query > /search rank LLM inner Cosine model qwen2.5:0.5b
LLM reranker using Ollama (qwen2.5:0.5b)
Ranker set to LLM.

---

Compilation Paths

Default — Zero extra dependencies (recommended)

cargo build --release

Nothing to install beyond Rust itself. Uses a pure-Rust vector store (custom BM25 + cosine similarity + RRF fusion, persisted to MessagePack). Embeddings come from Ollama over HTTP at runtime.

This is the path we ship to students. It compiles without a C++ toolchain, cmake, or protoc — works on Windows, macOS, and Linux with zero platform friction.

Internal embeddings — Fastembed (CPU-only)

cargo build --release --features internal-embed

Adds FastembedEmbedder — runs Nomic-Embed-Text-v1.5 on the CPU. Zero network overhead for embeddings. Needs a C compiler (gcc or cl.exe) at build time. Use /embed fastembed at runtime.

LanceDB backend (large collections)

cargo build --release --no-default-features --features lancedb,ollama-embed

Adds Arrow C++, protobuf, and compression codecs. Requires cmake and protoc at build time. Faster hybrid search for collections with 100k+ chunks.

Feature flags

Flag	Default	Description
ollama-embed	on	Local embeddings via Ollama HTTP (no extra deps)
internal	on	Pure-Rust vector store (MessagePack + cosine + BM25)
internal-embed	off	In-process Fastembed embeddings (needs C compiler)
internal-generate	off	In-process Candle LLM — zero network inference
offline	off	Meta: enables internal + internal-embed + internal-generate
lancedb	off	LanceDB hybrid index (needs protoc, Arrow C++)
test-fixtures	off	Compile-time embedded test documents for downstream crates
kreuzberg	off	Kreuzberg PDF parser (OCR, layout, DOCX)

The offline feature is a convenience meta-flag that enables every local component: chat, embeddings, and vector store all run in-process with zero network dependencies. Use offline-cuda, offline-metal, or offline-mkl for GPU-accelerated variants.

---

Requirements

Dependency	When needed
Rust 1.94+	Build (always)
Ollama	Runtime — provides chat, embed, and memory models
C compiler (gcc/cl.exe)	Only with internal-embed feature
C++ toolchain, protoc, cmake	Only with lancedb feature

Default build: Rust + Ollama. Nothing else.

---

Platform Setup

Linux / macOS / WSL

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh   # Rust
cargo build --release                                                # that's it

Windows

1. Install Rust from rustup.rs (MSVC host triple, the default)
2. Run cargo build --release

No extra tools needed. If you later want Fastembed (--features internal-embed), install the Visual C++ Build Tools (select "C++ build tools" workload).

---

For the REPL commands, CLI flags, and interactive usage, see the ragrig-bin README.

---

API Usage (Developers)

ragrig is a library. Build your own frontend — GUI, web server, headless bot — on top of the same traits.

use ragrig::{
    embed::{EmbedderSpec, OllamaEmbedder},
    agents::{ChatAgentSpec, Generator},
    parsers::{DocumentParsers, build_parsers},
    store::open_store,
    types::ChunkConfig,
    vector::{collect_documents, search_similar},
};
use std::path::Path;

// Build agents and parser registry
let embedder = EmbedderSpec::Ollama { model: "nomic-embed-text".into() }.build()?;
let chat_agent = ChatAgentSpec::Ollama { model: "gemma2:latest".into(), params: Default::default() }
    .build()?;
let parsers = DocumentParsers::new(build_parsers());
let folder = Path::new("./my_docs");
let chunk_cfg = ChunkConfig::default();
let store = open_store(folder).await?;

// Index documents
let _stats = collect_documents(&*embedder, &parsers, folder, &chunk_cfg, &*store).await?;

// Search
let results = search_similar(&*embedder, 5, 0.0, &*store, "quantum computing").await?;

// Chat
chat_agent.generate_stream(&prompt, &|token| { print!("{}", token); }).await?;

Configuration profiles

RagrigConfig is the library's single format-agnostic configuration surface. It composes four sub-configs (ChatConfig, EmbedConfig, ParseConfig, MemoryConfig) and derives Serialize + Deserialize — so the same struct works for CLI arguments, JSON, TOML, or programmatic construction.

Three entry points:

use ragrig::types::RagrigConfig;

// 1. Programmatic — builder-style via Default + struct update
let config = RagrigConfig {
    folder: "./my_docs".into(),
    chat: ChatConfig { model: "gemma4:e4b".into(), ..Default::default() },
    ..Default::default()
};

// 2. From a JSON file (zero extra dependencies — serde_json is already included)
let json = std::fs::read_to_string("profile.json")?;
let config: RagrigConfig = serde_json::from_str(&json)?;

// 3. From a TOML file (add `toml = "0.8"` to Cargo.toml)
let toml_str = std::fs::read_to_string("profile.toml")?;
let config: RagrigConfig = toml::from_str(&toml_str)?;

Example TOML profile — save this as profile.toml and load it at startup via a small wrapper binary, or deserialise it programmatically:

folder = "./research-papers"
semantic_scholar_api_key = "s2k-xxxxxxxxxxxx"

[chat]
provider = "Ollama"
model = "gemma2:latest"
context_tokens = 8192
context_size_mode = "Auto"

[chat.params]
temperature = 0.1
max_tokens = 2048

[embed]
provider = "Ollama"
model = "nomic-embed-text"
top_k = 20
similarity_threshold = 0.04

[parse]
pdf_parser = "Extract"
chunk_size = 512
chunk_overlap = 64

[memory]
model = "qwen2.5:1.5b"

Merging CLI overrides on top of a profile — use override_with() to apply only the fields the user explicitly changed on the command line:

// Load the base profile
let mut config: RagrigConfig = serde_json::from_str(&fs::read_to_string("profile.json")?)?;

// Parse CLI args and convert to a RagrigConfig (binary-side code)
let cli_config = RagrigConfig::from(Cli::parse());

// Merge: CLI values override profile values where they differ from defaults
config.override_with(&cli_config);

Adding a new backend

Implement the Generator, Embedder, VectorStore, or DocumentParser trait:

struct OpenAiChat { model: String, api_key: String }

#[async_trait]
impl Generator for OpenAiChat {
    async fn generate_stream(&self, prompt: &str, on_token: &(dyn Fn(String) + Sync)) -> Result<()> {
        // POST to https://api.openai.com/v1/chat/completions, stream SSE chunks
    }
    fn backend_name(&self) -> &'static str { "OpenAI" }
    fn model_name(&self) -> &str { &self.model }
}

Then wire it into ChatAgentSpec::parse("openai", ...) — no other code changes needed.

Implementing a new document parser

Add support for a new PDF backend or file format (~30 lines). Example using justpdf (pure-Rust PDF library):

use ragrig::parsers::DocumentParser;
use std::path::Path;

struct JustpdfParser;

impl DocumentParser for JustpdfParser {
    fn extensions(&self) -> &[&str] { &["pdf"] }

    fn parse(&self, path: &Path) -> anyhow::Result<String> {
        let bytes = std::fs::read(path)?;
        let doc = justpdf::Document::load(&bytes)?;
        let mut md = String::new();
        for page in doc.pages() {
            md.push_str(&page.text());
            md.push_str("\n\n");
        }
        Ok(md)
    }

    fn name(&self) -> &'static str { "justpdf" }
}

Then register it in parsers::build_parsers() (or hot-swap via /parser pdf justpdf once you add the variant to PdfParserBackend). The chunker, embedder, and search pipeline all work unchanged — they only see Markdown.

Implementing a custom memory strategy

Memory backends implement the [MemoryStrategy] trait. The trait controls only query rewriting — the session always replays the raw transcript whenever *a strategy is active, regardless of whether rewriting happened.

Example: a strategy that rewrites using only the immediately preceding turn, discarding older turns so the rewriter isn't distracted by stale context:

use async_trait::async_trait;
use ragrig::{agents::Generator, memory::MemoryStrategy};

struct LastTurnOnly {
    agent: Box<dyn Generator>,
}

#[async_trait]
impl MemoryStrategy for LastTurnOnly {
    async fn generate_rewrite(&self, prompt: &str) -> Option<String> {
        // The prompt is "Conversation:\nUser: …\nAssistant: …\n\n"
        // followed by the system rewrite prompt.  Split at the
        // double-newline, then grab only the last User/Assistant pair.
        if let Some((memory_part, rest)) = prompt.split_once("\n\n") {
            let lines: Vec<&str> = memory_part.lines().collect();
            let mut tail = Vec::new();
            for line in lines.iter().rev() {
                if line.starts_with("User: ") || line.starts_with("Assistant: ") {
                    tail.push(*line);
                    if tail.len() >= 2 {
                        break;
                    }
                }
            }
            tail.reverse();
            let trimmed = format!("Conversation:\n{}\n\n{}", tail.join("\n"), rest);
            self.agent.generate(&trimmed).await.ok()
        } else {
            None
        }
    }

    fn name(&self) -> &'static str { "last-turn" }
}

The trait provides three methods:

Method	Purpose
generate_rewrite(prompt) -> Option<String>	Return Some(rewritten) to replace the query before vector search, or None to use the raw query.
clear()	Wipe persistent state (default no-op).
name()	Label displayed in /memory output.

Built-in strategies (RewriteMemory, TranscriptMemory) cover the common cases; implement the trait directly when you need custom truncation, keyword extraction, or external rewriter services.

Implementing a custom history strategy

History backends implement the [HistoryStrategy] trait from ragrig::longterm_memory. The trait controls how past sessions are diffused into the current chat prompt.

Example: a strategy that loads only the most recent session, formats a compact summary header, and skips the full transcript:

use async_trait::async_trait;
use ragrig::longterm_memory::{HistoryStrategy, SessionStore};

struct LatestSessionOnly;

#[async_trait]
impl HistoryStrategy for LatestSessionOnly {
    async fn build_context(
        &self,
        store: &dyn SessionStore,
        current_query: &str,
    ) -> anyhow::Result<String> {
        let manifests = store.list().await?;
        let Some(latest) = manifests.last() else {
            return Ok(String::new());
        };
        let Some(session) = store.load(&latest.id).await? else {
            return Ok(String::new());
        };
        // Extract just the questions the user asked last session.
        let questions: Vec<&str> = session
            .turns
            .iter()
            .filter(|t| matches!(t.role, ragrig::TurnRole::User))
            .map(|t| t.text.as_str())
            .collect();
        Ok(format!(
            "[Last session ({:?}): {} turn(s), topics: {}]\n",
            session.created,
            session.turns.len(),
            questions.join("; "),
        ))
    }

    fn name(&self) -> &'static str {
        "latest-session-only"
    }
}

The trait provides two methods:

Method	Purpose
build_context(store, query) -> String	Return a preamble injected into the system prompt. Return "" to skip.
name()	Label displayed in /memory output.

Built-in strategies (LogHistory, SummaryHistory) cover the common cases; implement the trait directly when you need custom filtering, selection from multiple sessions, or non-LLM recombination.

Implementing a custom ranker

The [Ranker] trait lets you plug in any scoring algorithm. Implement rank() and name() — dyn_clone::DynClone (required supertrait) provides Clone for free:

use ragrig::{Ranker, ScoredChunk, store::StoredChunk};

#[derive(Debug, Clone)]
struct LengthRanker;

// Tell dyn_clone how to clone your ranker.
dyn_clone::clone_trait_object!(Ranker);

#[async_trait]
impl Ranker for LengthRanker {
    async fn rank(
        &self,
        chunks: &[StoredChunk],
        _query_vec: &[f32],
        _query_text: &str,
        top_k: usize,
        _threshold: f64,
    ) -> Vec<ScoredChunk> {
        // Trivial baseline: prefer shorter chunks (less context bloat).
        let mut indexed: Vec<(usize, f64)> = chunks
            .iter()
            .enumerate()
            .map(|(i, c)| (i, -(c.text.len() as f64)))
            .collect();
        indexed.sort_by(|a, b| a.1.total_cmp(&b.1));
        indexed.truncate(top_k);
        indexed
            .into_iter()
            .map(|(idx, _)| ScoredChunk {
                score: 0.0.into(),
                chunk: DocumentChunk {
                    text: chunks[idx].text.clone(),
                    source_file: chunks[idx].source_file.clone(),
                    meta: Default::default(),
                },
            })
            .collect()
    }

    fn name(&self) -> &'static str { "length" }
}

The built-in rankers — HybridRrfRanker, WeightedFusionRanker, MmrDiversityRanker, and LlmReranker — already cover the most common retrieval strategies. The decorator pattern (MmrDiversityRanker and LlmReranker) lets you wrap any inner ranker for diversity or LLM re-ranking.

Test fixtures for downstream crates

Enable the test-fixtures feature to get compile-time embedded copies of ragrig's own test documents — PDF, R Markdown, and HTML files suitable for writing parser integration tests without shipping your own files.

# Cargo.toml
[dev-dependencies]
ragrig = { version = "0.5", features = ["test-fixtures"] }

use ragrig::fixtures;

#[test]
fn parse_all_pdf_fixtures() {
    // fixtures::pdf::DIR is an include_dir::Dir with all files baked in.
    for entry in fixtures::pdf::DIR.files() {
        let name = entry.path().to_str().unwrap();
        let tmp = std::env::temp_dir().join(name);
        std::fs::write(&tmp, entry.contents()).unwrap();

        let parsers = ragrig::DocumentParsers::new(ragrig::parsers::build_parsers());
        let markdown = parsers.parse(&tmp).unwrap();
        assert!(!markdown.is_empty(), "{} produced no text", name);

        let _ = std::fs::remove_file(&tmp);
    }
}

// Also available as named constants:
assert!(fixtures::rmd::GETTING_STARTED.len() > 1000);
assert!(fixtures::html::INDEX.len() > 100);

Reactive UI integration (egui, ratatui, web, …)

Streaming generation to a GUI or TUI is a 4-call pattern. The same slim API works identically in egui, ratatui, a web server (SSE), or any reactive framework:

use ragrig::agents::{ChatAgentSpec, Generator};
use tokio::sync::mpsc;

// 1. Build the agent — one line
let agent = ChatAgentSpec::Ollama { model: "gemma2:latest".into() }.build()?;

// 2. Run generation on a background runtime, bridge to UI via channel
let (tx, mut rx) = mpsc::unbounded_channel::<String>();
let agent = std::sync::Arc::new(agent);
let agent_clone = agent.clone();
tokio::runtime::Runtime::new()?.spawn(async move {
    let _ = agent_clone.generate_stream(&prompt, &|token| {
        let _ = tx.send(token);  // callback is sync, channel decouples
    }).await;
});

// 3. Drain tokens in the UI loop (called every frame / event loop tick)
fn poll_stream(rx: &mut mpsc::UnboundedReceiver<String>, buffer: &mut String) -> bool {
    loop {
        match rx.try_recv() {
            Ok(t)         => buffer.push_str(&t),   // more tokens coming
            Err(Empty)    => return false,           // nothing right now
            Err(Disconnected) => return true,        // generation done
        }
    }
}

That's it — 4 ragrig calls: build, spawn, generate_stream, try_recv. The remaining 95% of a chat UI is framework-specific layout and input handling, not ragrig. See examples/streaming_chat_egui/ and examples/streaming_chat_ratatui/ for complete runnable demos.

Typed errors

ragrig defines typed error variants in [RagrigError] that carry structured payloads so callers can recover programmatically:

Variant	Payload	Recovery
ContextSizeExceeded	current, max (tokens)	Reduce top_k or expand context window
EmbedModelNotFound	model: String	Run ollama pull {model} and retry
StoreCorrupt	path: String	Delete the store file and re-index
NoDocumentsFound	folder: String	Add PDF, EPUB, or HTML files to the folder
OllamaUnreachable	context: String	Start Ollama with ollama serve — see troubleshooting for common causes
GenerationFailed	backend, model, detail	Check model is pulled and fits in VRAM

Every variant provides a [suggested_action()] method with a human-readable recovery hint. Use [RagrigError::log_or()] to log the error and its action in one call.

Downcast from anyhow::Error and switch on the variant:

use ragrig::RagrigError;

let result = agent.generate_with_context("query", &[]).await;
match result {
    Err(e) => {
        if let Some(ce) = e.downcast_ref::<RagrigError>() {
            match ce {
                RagrigError::ContextSizeExceeded { current, max } => {
                    eprintln!("Prompt ({current} tk) exceeds model limit ({max} tk). Truncating.");
                }
                RagrigError::EmbedModelNotFound { model } => {
                    eprintln!("Run: ollama pull {model}");
                }
                RagrigError::StoreCorrupt { path } => {
                    std::fs::remove_file(path).ok();
                    eprintln!("Removed corrupt store. Re-index on next run.");
                }
                RagrigError::NoDocumentsFound { folder } => {
                    eprintln!("No supported files in {folder}. Add PDFs, EPUBs, or HTML.");
                }
            }
        } else {
            eprintln!("Unexpected: {e}");
        }
    }
    Ok(answer) => println!("{answer}"),
}

Runnable examples

Clone the repo and run any example with cargo run in its directory (an Ollama server must be running):

git clone https://github.com/schmettow/ragrig.git
cd ragrig

# Single-shot RAG query — index fixtures, search, generate
cargo run --manifest-path examples/rag_query/Cargo.toml -- "What is RAG?"

# Two-agent dialog with shared vector store and transcript
cargo run --manifest-path examples/dialog/Cargo.toml -- "What is a p-value?"

# Streaming chat GUI with markdown bubbles (egui)
cargo run --manifest-path examples/streaming_chat_egui/Cargo.toml

# Streaming chat TUI with two-color bubbles (ratatui)
cargo run --manifest-path examples/streaming_chat_ratatui/Cargo.toml

# Streaming chat GUI with chat bubbles, provider/model picker, and RAG folder (Iced)
cargo run --manifest-path examples/streaming_chat_iced/Cargo.toml

# Binary with embedded vector store — indexed at build time
cargo run --manifest-path examples/embedded_togo/Cargo.toml -- "What is RAG?"

Example	Concept
rag_query	Single-shot pipeline: index → embed → search → generate via RagAgent
dialog	Multi-agent orchestration: two RagAgent instances sharing one vector store and one transcript
streaming_chat_egui	Reactive GUI: generate_stream + channel bridge → egui markdown bubbles
streaming_chat_ratatui	Reactive TUI: same channel pattern → ratatui two-color bubbles with scroll
streaming_chat_iced	Reactive GUI: Iced native GUI with provider/model picker, RAG folder picker, and streaming chat bubbles
embedded_togo	Embedded store: build.rs indexes fixtures at compile time, include_bytes! bakes it into the binary

Transcripts

The TurnPairs newtype converts a session's Vec<Turn> into a slice of (&str, &str) pairs suitable for RagAgent::generate_with_context():

use ragrig::{Turn, TurnRole, TurnPairs};

let turns = vec![
    Turn { role: TurnRole::User, text: "Hello".into(), perf: None },
    Turn { role: TurnRole::Assistant, text: "Hi!".into(), perf: None },
];
let pairs = TurnPairs::from(&turns[..]);
agent.generate_with_context("What is RAG?", &pairs.0).await?;

---

Q & A

What is unique about ragrig and why should I use it?

Ragrig tries to be a flexible and zero-friction prototyping tool for researchers and students, not an enterprise-grade framework with all bells and whistles. Here are the points that distinguish Ragrig from other crates:

Zero native dependencies in default build.** Every other crate needs at minimum a C compiler (for tokenizers, ONNX runtime, tree-sitter, etc.) or an API key. Ragrig builds with cargo build --release and nothing else. This is a genuinely unique selling point for students, workshops, and quick-start scenarios.

2. Runtime hot-swapping via trait objects. Every other crate uses compile-time feature flags to select backends. Ragrig lets you switch chat/embed/memory engines mid-session without losing state. langchainrust has multiple providers but you pick them at Cargo.toml time. ragrig's /chat deepseek, /embed fastembed, /memory off commands have no equivalent in any competitor.

3. Panic-safe multi-parser PDF pipeline. Three PDF parsers (pdfsink for layout-aware, pdf-extract for flat text, sloppy binary scavenger as fallback) with catch_unwind wrapping. No other crate does this — they pick one parser and crash on malformed PDFs.

4. Token-efficient cloud usage pattern. Use a tiny local model for query rewriting, only send the final prompt + context to the cloud. This is described in the README hot-swap examples and baked into the MemoryStrategy trait. No competitor has this pattern explicitly designed in.

5. Student-focused UX. The README's quick-start is 3 commands (rustup, ollama pull ×3, cargo build --release). The REPL has 15+ slash commands with clear transition messages. Session persistence works out of the box.

When should I not use it?

Ragrig is designed as an accessible framework to build multi-agent interactive prototypes. It is not intended for production use or highly scalable deployments. For these purposes, you should use a dedicated RAG framework like rig-core on which Ragrig is heavily based.

I am a Python programmer. I am not able to program in Rust. How can I use Ragrig?

Ragrig provides a fully documented API with numerous examples and a dedicated agent skill (only available on Github). With this information, a good coding agent can produce working Ragrig applications with not more than a few instructions.

For version 2.0, we plan to provide Python (and possibly R) bindings.

Ollama is unreachable — what should I check?

If ragrig reports OllamaUnreachable, work through these in order:

1. Ollama isn't running. Start it in a terminal:

   ollama serve
   

   On macOS and Windows, launching the Ollama desktop app also starts the server.

2. Ollama is running on a non-default port. By default ragrig connects to localhost:11434. If you changed the port (e.g. via OLLAMA_HOST), set the same variable in the terminal where ragrig runs:

   export OLLAMA_HOST=127.0.0.1:11435
   cargo run -- --folder ./my_docs
   

3. A model pull was interrupted. Partial downloads can leave the Ollama registry in a broken state. Re-pull the model:

   ollama pull nomic-embed-text
   ollama pull gemma2:latest
   

   If that fails, remove the partial model and pull fresh:

   ollama rm nomic-embed-text && ollama pull nomic-embed-text
   

4. Firewall or port conflict. Ensure port 11434 is not blocked by a firewall or already bound by another process:

   # Linux / macOS / WSL
   lsof -i :11434
   # Windows (PowerShell)
   netstat -ano | findstr :11434
   

5. WSL → Windows networking. When Ollama runs on Windows and ragrig runs inside WSL, localhost does not automatically forward. Find the Windows host IP from inside WSL and set OLLAMA_HOST:

   export OLLAMA_HOST=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):11434
   

   Alternatively, install Ollama directly inside WSL so both processes share the same network namespace.

When the context size exceeds the model's maximum, how can I adjust this?

Context-size errors happen for two reasons:

1. Hardware VRAM limits — Ollama caps the context window at 4096 tokens on GPUs with less than 24 GB VRAM to prevent out-of-memory crashes.
2. Architectural limits — some distilled reasoning models (e.g. DeepSeek R1 8B/14B) have a hard-coded 4096-token maximum that even Ollama cannot override.

Library consumers can catch the typed error directly:

match chat_agent.generate(prompt).await {
    Err(e) => {
        if let Some(ce) = e.downcast_ref::<ragrig::RagrigError>() {
            // ce.current_size(), ce.max_size() — use these to trim
            // your embedding results before retrying.
        }
    }
    Ok(response) => { … }
}

Why does Generator::generate_stream take &self when my backend needs &mut self?

The trait is designed for stateless LLM backends (Ollama, DeepSeek) where a prompt-in/response-out call has no observable side-effects on the client. If your backend tracks session state — rule-usage counters, connection pools, an internal memory queue — you need interior mutability.

Solution: wrap the mutable state in Arc<Mutex<T>>:

use std::sync::{Arc, Mutex};

struct MyStatefulBackend {
    inner: Arc<Mutex<ThirdPartyEngine>>,
}

#[async_trait]
impl Generator for MyStatefulBackend {
    async fn generate_stream(
        &self,
        prompt: &str,
        on_token: &(dyn Fn(String) + Sync),
    ) -> Result<()> {
        let response = self.inner.lock().unwrap().respond(prompt);
        on_token(response);
        Ok(())
    }
    // ...
}

Arc also gives you a trivial clone_box implementation — just Arc::clone the inner handle. See examples/eliza_generator for a complete worked example wrapping the stateful eliza crate.

Why do I have to implement Debug on my Generator?

The Generator trait inherits Debug from its supertrait bound (: Send + Sync + Debug). This is so the RagAgent can print a human-readable representation of the active backend in diagnostic output and log messages.

The problem: many useful types (Regex, raw file handles, opaque third-party structs) don't implement Debug. Deriving fails, and you're left writing a manual impl.

Solution: implement Debug by hand — it's two lines:

impl fmt::Debug for MyBackend {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        f.debug_struct("MyBackend")
            .field("model", &self.model)
            .finish()
    }
}

For fully opaque types, a placeholder string is fine:

.field("engine", &"<opaque>")

The point is that Debug is informational, not load-bearing — nothing in the framework parses the output. If your backend fields are all plain data (String, usize, bool), the derive works automatically and you won't see this issue at all.

Why do I need async_trait even for a synchronous backend?

The Generator trait is declared with #[async_trait] so that every backend — network, local, or pure computation — presents the same async interface. This lets RagAgent call generate_stream().await uniformly without knowing whether the backend makes HTTP requests or runs a local regex loop.

The cost: one extra dependency (async-trait = "0.1") and one extra annotation (#[async_trait] on the impl block). The method body itself can be completely synchronous — async doesn't force you to spawn tasks or touch the network:

#[async_trait]
impl Generator for MySyncBackend {
    async fn generate_stream(
        &self,
        prompt: &str,
        on_token: &(dyn Fn(String) + Sync),
    ) -> Result<()> {
        // Purely synchronous computation — no .await anywhere.
        let response = compute_response(prompt);
        on_token(response);
        Ok(())
    }
}

The async keyword on the method signature is a promise to the caller (the framework), not a requirement that your code be asynchronous.

---

License

MIT License — see LICENSE.