Question 1

Is MIB just another form of Quantization or LSH?

Accepted Answer

No. Locality Sensitive Hashing (LSH) and standard quantization use random projections that degrade accuracy for speed. Maximally Informative Binarization (MIB) is an information-theoretic transformation. It identifies and encodes the most salient, high-entropy features of a vector into a compact binary code. This allows us to replace the heavy float32 representation entirely, achieving 32x compression while increasing semantic focus on what actually matters in the query.

Question 2

You claim "Geometric Distance" is fragile. What does that mean?

Accepted Answer

The industry relies on the assumption that geometric proximity (Cosine Similarity) equals semantic relevance. We prove this is a "fragile proxy." Just because two vectors point in the same direction doesn't mean they answer the user's specific intent. Moorcheh replaces geometric search with Information-Theoretic Scoring (ITS). Instead of measuring angles, ITS measures the probability of relevance.

Real-world Benchmark:
Query: "Tesla Customer Segments"

❌ Geometric Search: Returned generic results about "men"
✓ Moorcheh ITS: Returned the specific demographic "men aged 30-40"

ITS recognized the specific information gain required by the query.

Question 3

How does the "3-Part Stack" replace traditional RAG?

Accepted Answer

We don't optimize the old stack; we replace it component-by-component:

Storage:Float32 vectors→MIB Binary Codes(32x smaller)

Indexing:HNSW Graph Build→Index-Free (Pure Transform)(Instant writes)

Search:Cosine Similarity→EDM (Bitwise Ops)(CPU-optimized)

Question 4

How does Moorcheh compare to Pinecone, Qdrant, and Redis?

Accepted Answer

Metric	Moorcheh	Pinecone / Weaviate	AWS OpenSearch
Write Latency	Instant (Transform) (No Build Time)	Slow (Graph Build) (Re-indexing Lag)	Slow (Graph Build)
Real-Time Data	Native Support (Streaming Ready)	Re-indexing Lag (Consistency Delay)	Re-indexing Lag
Architecture	Index-Free (Pure Transform)	HNSW Graph (Heavy Build)	Brute Force / IVF
Storage Cost	$0 / Month (Free)	$$$ / GB / Month (Recurring)	$$$ / GB / Month
Scaling	Auto-Concurrency	Manual Sharding	Slow I/O Bound

Question 5

How does Moorcheh compare to "Storage-Separated" solutions (like AWS S3 Vectors)?

Accepted Answer

Storage-separated solutions (like S3 or PGVector) solve the cost problem but introduce High Latency and Low Accuracy. They have to fetch data from cold storage and perform brute-force search. Moorcheh breaks this trade-off. Our MIB compression makes the data small enough to be "Hot" (instantly searchable) while keeping the cost profile of "Cold" storage.

Question 6

How do you handle Hybrid Search and Filtering?

Accepted Answer

We streamline Hybrid Search into a single Syntax-Driven Query. Instead of building complex JSON filter objects, you can combine semantic search, metadata filters, and keyword constraints directly in the query string.

For example: query: 'payment failure #platform:mobile #urgent'

This command performs a semantic search for 'payment failure', restricts results to the 'mobile' platform metadata, and ensures the keyword 'urgent' exists in the text. This allows for rapid, precise tuning of retrieval results.

Question 7

What is the difference between Text and Vector Namespaces?

Accepted Answer

We support two core operating modes:

Text Namespaces (Managed): You upload raw text or files. Moorcheh handles the chunking, embedding, and indexing automatically using our internal models. Best for "Auto-ETL."

Vector Namespaces (BYO-Model): You handle the embedding and upload raw vector arrays [0.1, 0.2...]. Best if you have fine-tuned models or specific embedding requirements.

Question 8

If I use Vector Namespaces (BYO-Embedding), how do I get the text back for my LLM?

Accepted Answer

You do not need a secondary database. When uploading your raw vectors, you can attach the original text chunk as a Metadata Field. When you perform a vector search, Moorcheh returns the payload (metadata) alongside the ITS score. This allows you to run a complete RAG pipeline using your own embeddings without managing a separate PostgreSQL or Redis instance for the text.

Question 9

Can I search across multiple namespaces simultaneously?

Accepted Answer

Yes. The search endpoint accepts an array of namespaces ["legal-docs", "emails", "slack-logs"]. As long as the namespaces are of the same type (all Text or all Vector), the engine will perform a parallel search and rank the results globally using the ITS score, giving you a unified view of your data.

Question 10

Do I need to manage my own RAG chain (Search + LLM)?

Accepted Answer

No. Our /answer endpoint consolidates the entire RAG pipeline—Embedding, Search, Reranking, Prompting, and Generation—into a single API call.

Question 11

How do I switch between RAG and standard Chat?

Accepted Answer

Use the namespace field. If you provide a namespace, we perform RAG. If you send namespace: "" (empty string), we act as a Direct AI Gateway.

Question 12

What models are supported?

Accepted Answer

We support a multi-provider ecosystem including:

anthropic.claude-sonnet-4.5meta.llama4-maverickdeepseek.r1amazon.nova-pro

You are not locked into one provider.

Question 13

Can I customize the prompts?

Accepted Answer

Yes. Use headerPrompt to define the AI persona and footerPrompt to define formatting rules. We handle the context injection automatically.

Question 14

Does Moorcheh support "Multi-Hop" reasoning?

Accepted Answer

Yes. Our engine supports Recursive Retrieval. If an agent asks a complex question, Moorcheh can retrieve an initial set of documents, extract new entities from them, and automatically trigger a secondary search based on those entities—all within the same API latency budget. This allows agents to "connect the dots" across disparate documents.

Question 15

How does the "Long-Term Memory" actually persist? Is it a graph?

Accepted Answer

It is a hybrid approach. We store conversational state as time-series semantic vectors. This allows an agent to recall "What did we agree on last Tuesday?" (Temporal Recall) as well as "What are the user's dietary restrictions?" (Fact Recall). We index this state differently than your static knowledge base, ensuring that "User Preferences" are always weighted higher than general document data.

Question 16

Can multiple agents share the same memory?

Accepted Answer

Yes. We support Multi-Tenant Namespaces. You can create a shared "Global Memory" namespace for all agents (e.g., Company Policy) and individual "Private Memory" namespaces for specific user sessions or specific agents. You can query across both simultaneously.

Question 17

Can I run Moorcheh locally (e.g., Docker)?

Accepted Answer

Moorcheh is a cloud-first semantic engine designed to leverage massive distributed compute for MIB compression and ITS scoring. We do not currently offer a local Docker container. However, the Moorcheh Console Playground acts as your "Local Host" in the cloud. It provides a free, zero-latency environment to build, test, and debug your entire RAG pipeline before you ever write a line of code.

Question 18

Do I need external tools to parse and chunk my files?

Accepted Answer

No. You can delete your scraping scripts. Our /upload-file endpoint accepts raw files directly:

.pdf.docx.xlsx.json.csv.md.txt

We handle the Full Ingestion Lifecycle:
Extraction: OCR and text parsing.
Enrichment: Auto-generation of metadata and document summaries.
Transformation: Intelligent chunking and MIB encoding.

All happens asynchronously with a single cURL command.

Question 19

Can I upload structured data like Excel or JSON?

Accepted Answer

Yes. Unlike basic vector stores that only handle unstructured text, Moorcheh natively parses .xlsx and .json files. We preserve the structural relationships in the data, making it possible to perform semantic searches over structured datasets (e.g., 'Find all transactions over $500 in the Q3 report').

Question 20

How do I debug performance or hallucinations?

Accepted Answer

The Moorcheh Console is a complete Observability Suite, not just an admin panel. You get granular logs for every single action, including:

Latency Breakdowns: See exactly how many milliseconds were spent on Embedding vs. Search vs. Generation.
Action Logs: Trace the full history of API calls.
Uptime Monitoring: Real-time status of your specific namespaces.

This allows you to pinpoint bottlenecks or quality issues immediately.

Question 21

Can I build a chatbot without writing code?

Accepted Answer

Yes. The Visual Playground allows you to configure the entire system visually. You can select your Knowledge Base, choose the AI Model (e.g., Claude 3.5, Llama 4), set the prompts, and even Customize the Chat UI (colors, avatars, themes). You can chat with your data immediately in the browser—completely free of charge—to validate accuracy.

Question 22

How do I move from the Playground to my own app?

Accepted Answer

We offer a unique "One-Click Export" workflow. Once you are happy with your setup in the Playground, you can download a single Configuration File. Simply drop this file into our open-source Chat Boilerplate , and your fully customized, production-ready application will work anywhere—on Vercel, Netlify, or your own servers. It bridges the gap between "No-Code prototyping" and "Full-Code deployment."

Question 23

Many vector DBs claim to be "Serverless." How is Moorcheh different?

Accepted Answer

Most "Serverless" vector databases are actually managed servers hidden behind an API—because you cannot fit a 300GB stateful HNSW graph into a stateless Lambda function. Moorcheh is True Serverless. Because MIB compresses the index so aggressively, we can load the search engine inside the stateless function (e.g., AWS Lambda, Google Cloud Run). This eliminates the network hop to a separate vector server and allows for infinite "Scale-to-Zero" cost efficiency.

Question 24

Do I have to trade off accuracy for QPS (Queries Per Second)?

Accepted Answer

No. In traditional HNSW systems, you often have to tune down search parameters (like ef_search) to handle high traffic, which kills accuracy. Because Moorcheh uses EDM (Bitwise Operations), our search is orders of magnitude computationally cheaper than floating-point math. We can maintain maximum search breadth and accuracy even under massive QPS loads, eliminating the "Accuracy vs. Speed" compromise.

Question 25

Can I stream live data (e.g., stock ticks, logs) into an agentic workflow?

Accepted Answer

Yes, this is a primary use case. Because we use an Index-Free Architecture, Moorcheh supports Real-Time Ingestion. Unlike traditional vector databases that must constantly re-balance their HNSW graph structures as new data arrives (which kills write performance), MIB is a pure transformation. We simply transform the vector and append it. This means adding or deleting 1 million vectors happens instantly without locking the database or degrading search speed. Data is searchable the exact millisecond it is uploaded, allowing agents to react to live events immediately.

Question 26

How long does it take to ingest massive datasets?

Accepted Answer

Ingestion is bound only by network speed, not CPU. Since we don't spend cycles building an HNSW graph, our ingestion throughput is orders of magnitude higher than graph-based alternatives. We just transform and store. There is no "Build Time" in Moorcheh—data is live instantly.

Question 27

I'm currently using Pinecone/Weaviate. How hard is it to migrate?

Accepted Answer

We offer a "Zero-Downtime Migration" tool. If you can export your data to JSON/Parquet, we can bulk-ingest it. Since we usually handle the embedding step too, it is often better to re-ingest the raw text to take advantage of our optimized embedding models, but we support vector-only migration as well.

Question 28

Do you offer a Sandbox or Free Tier?

Accepted Answer

Yes. The Builder Plan is free forever. It includes up to 10,000 vectors and full API access. It is not a "trial"; it is a functional tier for prototyping and small internal tools.

Question 29

Do I pay for storage (Data at Rest)?

Accepted Answer

No. Unlike other vector databases that charge you monthly rent for SSD/RAM usage, Moorcheh provides Zero Recurring Storage Costs. You only pay a small one-time fee for Ingestion ($0.01 per 10MB) to cover the processing power. Once your data is indexed, it can sit in Moorcheh forever for free. You only pay when you actually search or generate answers.

Question 30

How does the Credit System work?

Accepted Answer

We use a simple consumption model where 1 Credit = $0.01.

Ingestion:1 Credit per 10MB (One-time)

Search:5 Credits per 1,000 API calls

Gen AI:1–3 Credits per answer, depending on model tier

There are no "Idle Pods" or hourly fees. If you don't use the API, your bill is $0.

Question 31

Which Gen AI models are included in which tier?

Accepted Answer

We offer three tiers of generation:

Standard (1 Credit)

Llama 3 70B, DeepSeek-R1
Great for speed/code

Advanced (2 Credits)

Claude 3.7 Sonnet, Amazon Nova Pro
Great for reasoning

Premium (3 Credits)

Claude Sonnet 4, Llama 4 Maverick
1M+ Context

You can switch models per-request to optimize costs.

Question 32

Why is your TCO (Total Cost of Ownership) lower than Pinecone or Redis?

Accepted Answer

Traditional vector databases are RAM-bound. They require you to pay for expensive "Provisioned RAM" to keep your HNSW graph in memory 24/7, even when idle. This is a "RAM Tax." Moorcheh is Stateless & Serverless. Our binarized index (MIB) is stored cheaply on disk and loaded instantly into stateless functions only during execution. You pay for Query Execution, not Idle RAM.

Question 33

Do I need to manage Sharding or "Pods" as I scale?

Accepted Answer

No. Sharding is a legacy constraint of the HNSW architecture. Because HNSW graphs are monolithic and stateful, scaling requires complex horizontal sharding and re-balancing of nodes. Moorcheh uses Automatic Function Concurrency. We handle scale the way AWS Lambda does: by simply spinning up more stateless execution environments instantly. There are no pods to provision and no shards to balance.

Question 34

Do you offer SLAs and Enterprise Support?

Accepted Answer

Yes. Our Production Plan includes a 99.9% Uptime SLA. Our Enterprise/Sovereign Plan includes a 99.99% SLA, dedicated support channels (Slack/Teams), and designated Solutions Architect hours to help you design your agentic workflow.

Question 35

What happens if I go over my plan limits?

Accepted Answer

We do not hard-stop your service (unless on the Free tier). For Production plans, we have a Usage-Based Overage model. You simply pay for the extra compute/storage at the standard metered rate. We will alert you, but we won't break your app.

Metric	Moorcheh	Traditional Vector DBs
Input	Auto File Ingestion (up to 100 MB/file)	BYO (limited support)
Write Latency	Instant (Transform) (no build time)	Slow (Graph Build) (re-indexing lag)
Real-Time Data	Native Support (streaming ready)	Re-indexing Lag (consistency delay)
Architecture	Index-Free (pure transform)	HNSW Graph (heavy build)
RAG Built-in	Yes + Bedrock (closed VPC ecosystem)	No (BYO) (calling external API)
VPC Deploy	Cloud-Native (auto-scaling microservices)	Cloud-Hosted (large RAM, manual scaling)
Idle Cost	$0	Always-on

The Information-Theoretic Search Engine for RAG & Agentic Memory

Watch Interactive Demo

Three Reasons Teams Choose Moorcheh

Deterministic Results You Can Trust

Unit Economics That Actually Work

Zero Ops, Infinite Scale

Moorcheh vs. Traditional Vector Databases

Proven Performance: MAIR Benchmark

Native VPC Deployment. Full Infrastructure-as-Code.

Technical Deep Dive

Core Technology & Accuracy

Start ArchitectingBuild the next generation of agentic AI with Moorcheh's unified semantic infrastructure