> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mixpeek.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Architecture
> How Mixpeek's two-tower design decouples ingestion from retrieval and learns from usage
Mixpeek follows a **two-tower architecture** — a well-known pattern in recommendation systems adapted for multimodal search.
## Document Tower (Ingestion)
Source files enter through a [bucket](/docs/platform/data-model#buckets), trigger one or more [collections](/docs/platform/data-model#collections), and pass through the Ray engine for feature extraction. Each collection produces a different representation — text embeddings, multimodal embeddings, metadata, taxonomy labels — all stored as named vectors on a single point in [MVS](/docs/vector-store/overview), the Mixpeek Vector Store.
Documents are encoded **once at ingest time**. Adding a new extractor or updating a taxonomy triggers a re-process on the bucket — documents get new representations without changing the ingestion path.
## Query Tower (Retrieval)
A query arrives, gets encoded, and passes through a [multi-stage retriever](/docs/retrieval/retrievers). The key stage is **feature search**, which runs a separate vector query per embedding space and fuses the results.
The fusion strategy determines how per-feature scores combine into a final ranking:
| Strategy | Behavior |
| ---------- | ----------------------------------------------------------------- |
| `rrf` | Rank-based, no tuning needed |
| `weighted` | Manual weights you set |
| `learned` | Weights sampled from Beta distributions, updated by user behavior |
See [Fusion Strategies](/docs/relevance/fusion-strategies) for the full comparison.
## Closing the Loop
With [learned fusion](/docs/relevance/learned-fusion), the two towers aren't static — they're connected by a feedback loop:
1. **Results** are shown to users
2. **Interactions** (clicks, purchases, skips) are captured and stored in ClickHouse
3. **Thompson Sampling** aggregates interactions into Beta(α, β) distributions per feature — α counts positive signals, β counts non-engagement
4. **Sampled weights** are drawn from those distributions on each query, naturally balancing exploration and exploitation
5. Weights converge toward the optimal blend as interactions accumulate
The system handles cold start through [hierarchical fallback](/docs/relevance/learned-fusion#hierarchical-fallback): personal weights → demographic segment → global → uniform prior. With zero interactions, learned fusion behaves identically to RRF.
## What Makes This Different
Standard two-tower systems learn a single embedding space. Mixpeek's document tower fans out into **N representation spaces** (visual, audio, text, multimodal, metadata), and the query tower traverses them in sequence through multi-stage retrieval. Learning happens at the **fusion layer** — which spaces to weight — not inside the embeddings themselves.
This means you can add a new extractor, re-process your data, and the bandit will automatically discover whether the new feature improves results — without retraining any model.
## Related
* [Feedback Loop Tutorial](/docs/tutorials/feedback-loop) — step-by-step setup guide
* [Learned Fusion](/docs/relevance/learned-fusion) — Thompson Sampling algorithm details
* [Interaction Signals](/docs/retrieval/interactions) — which signals to capture and when
* [Fusion Strategies](/docs/relevance/fusion-strategies) — all 5 strategies compared