FAQ

Can I use these subsystems without the rest of "zerda"? Nine of the ten can — they only depend on the standard library plus a duck-typed rag_system/llm you supply. graph_rag is the exception: it hard-imports DocumentChunk from four levels above this archive (....chunks), so it needs the parent project present. See Installation.

Which subsystem should I start with? If you just need multi-turn chat, use conversational_rag. If retrieval quality is inconsistent for hard questions, self_improving_rag.SelfIRAG or agentic_rag.AgenticRAG add iterative correction. If you have several existing RAG backends and want to combine them, federated_rag is the composition layer — see Architecture.

Can I combine multiple subsystems? Yes — none of the ten packages import each other, and they're designed to be layered. The most explicit example in the source is federated_rag, whose add_source() accepts any object with a retrieve/generate (or query) method, which every other subsystem's main class satisfies.

Why are two different RetrievalError classes defined? agentic_rag.agentic_rag.RetrievalError and self_improving_rag.self_improving_rag.RetrievalError are independent classes with the same name, defined in separate exception hierarchies (AgenticRAGError vs. RAGSystemError). This is a real code duplication in the archive, not a documentation error — see Self-Improving RAG.

Why does so much default to Arabic (lang="ar")? Several modules (conversational_rag, domain_rag, multi_hop, multi_doc_rag) default their language/lang parameter to "ar", and prompt templates throughout the codebase contain explicit Arabic strings and language-matching instructions (e.g. streaming_rag's default prompt_template). This reflects the library's origin and primary use case; pass language="en" (or another supported code) explicitly if you need a different default.

Is any of this thread-safe? Only where explicitly documented. federated_rag.federat_cache.TTLCache is documented as thread-safe. agentic_rag.cache.TTLCache is explicitly documented as not thread-safe. No other class in the archive makes an explicit thread-safety claim in its docstring, so treat the rest as single-threaded unless you've verified otherwise.

Do these modules make real network calls to an LLM provider? No — every module calls .generate() / .stream() / .astream() on whatever llm or rag_system object you inject. There is no embedded HTTP client or provider SDK anywhere in this archive.