Elastic (@elastic)

3 patterns for multimodal RAG. Here's how they differ and when each one breaks down. Most RAG systems add multimodal support by converting everything to text first. Is your system natively multimodal, or just a conversion pipeline? The architecture choice shapes what you can query and what you lose. Shared vector space - Cross-modal search without format conversion - Requires large multimodal training datasets - Semantic drift is a real risk if training data is narrow Single grounded modality - Works with any existing text search setup - Spatial relationships in images don't survive conversion - Retrieval quality depends on captioning/transcription accuracy Separate retrieval pipelines - Best per-modality retrieval accuracy - Most complex to rank across modalities - Highest compute cost, independent search per modality Pick your pattern, clone the repo, and build it.

0.89 recall at k=10 and zero cross-tenant leaks on a persistent agent memory layer. Built on Elasticsearch with 3 indices mapped to cognitive science: episodic events, semantic facts, procedural playbooks. Each has its own write rate, aging rules, and update logic. Episodic decays. Semantic gets superseded when a user contradicts it (the old fact stays for audit, a filter hides it from recall). Procedural tracks success and failure counts across conversations. Recall is one hybrid query: BM25 + Jina v5 dense fused with RRF, then a cross-encoder reranker on the merged candidates. Time decay and use-count scoring keep fresh, frequently-recalled facts on top. DLS scopes every query to the user's API key. The cluster won't return another user's documents regardless of what the agent asks for. Open source, with an MCP endpoint for any agent runtime.

3 types of mappings in Elasticsearch Dynamic: Elasticsearch detects field types as documents arrive. Explicit: you define every field upfront. Recommended for production. Runtime: schema-on-read, no reindexing needed. Each trades setup speed for indexing control.

Learn how to cut Elasticsearch log storage by up to 76% with LogsDB: 1. Create a LogsDB index with "index.mode": "logsdb" 2. Reindex your logs into both a standard and LogsDB index 3. Force merge both indices with _forcemerge?max_num_segments=1 4. Measure the difference with the _stats API In our test: 15.37 MB (standard) vs 8.6 MB (LogsDB). 44% reduction on test data. 76% in production benchmarks.

Here are 5 distance metrics in vector search. But how do you choose the right one? • L1 (Manhattan): sum of absolute differences, exact kNN only with no HNSW support • L2 (Euclidean): straight-line distance, the safe default for most models • Cosine similarity: angle between vectors, magnitude ignored • Dot product: same ranking as cosine on normalized vectors, less compute • Max inner product: dot product without the normalization constraint Most teams default to cosine and move on. That works until your model outputs non-normalized vectors, and suddenly dot product or max inner product is the better fit. Scoring formulas and config details in the blog.

Building a dashboard mid-investigation means losing the thread you were pulling. Open the editor, pick indices, configure panels, wire up ES|QL queries. That's ten minutes of context switching before you've answered a single question. Kibana skips that now. • Describe what you need in plain language. • The agent explores your indices, generates ES|QL, picks chart types, and lays out the panels. Everything stays in your conversation until you save it. Then it becomes a first-class Kibana object your team can open and edit. Already viewing one? The agent attaches automatically. Ask why a metric spiked, add a comparison panel, break it down by region: all inline. Available as a technical preview in Elastic 9.4