The hard parts of hybrid retrieval, already done. Elasticsearch Vector Database is a new serverless offering where expert-level tuning is the default: - bfloat16 storage: half the disk footprint before quantization even starts - BBQ: up to 32x vector compression, 95% less memory - Auto-calibration re-tunes quantization on every merge as your data drifts - Filtered vector search at up to 8x higher throughput than OpenSearch - Jina AI embeddings and reranking on managed GPU inference, or bring your own models You bring documents and queries. We handle the embeddings, tuning, and infrastructure. Full breakdown, including the semantic_text quickstart and what ships in vectorDB index mode:

1 question to an AI agent: 24 spans, 10 model calls, 160K input tokens. Elastic 9.5 records all of it out of the box. There's no collector to set up. Every Agent Builder run lands as OTel traces in your own cluster, down to each ES|QL query the agent wrote and which index it ran against. Half the model calls went to a cheaper model. You'd never know from the answer text. It's only in the trace. One thing traces don't hold by default: content. Prompts and responses stay off unless you flip the privacy toggles. And they never tell you who approved the action. That record you write yourself.

"It feels slow" is the worst ticket a self-hosted LLM generates. vLLM starts, serves, and reports success whether it's configured brilliantly or wastefully. Nothing tells you which. But the answer is already sitting on /metrics: latency split by phase, cache hit rates, batch occupancy, completion outcomes. Almost nobody scrapes it. On a single A10G, 6 metric checks turned "it feels slow" into a verdict: TTFT: 51 ms against a 300 ms p95 target Queue time: 0.01 ms Decode: 97% of total latency Prefix cache: 32% of prefill work skipped entirely The server was over-provisioned, not under. The slowness lived somewhere in front of it: the app, the gateway, or the prompt. Tuning an LLM server is reading telemetry and reasoning about saturation. SREs have been doing that for 20 years. Full walkthrough with the ES|QL queries, the DCGM setup, and all 6 metric checks on an A10G:

Code is the only documentation that's never outdated. Our field teams get asked things like: does App A v1.2.3 work with App B v9.8.7 on Kubernetes? Docs rarely cover that. The code always does. So one of our field engineers built Sourcerer. It searches a billion lines of our code across every repo and version we support. Every answer cites the exact file and line. Built on Elasticsearch and Agent Builder. Open source, Apache 2.0. Full benchmarks and solution design:

How can a text embedding model map audio and image vectors? After being transformed via a projector (translator), a foreign modality vector must announce itself before entering an embedding model for an unrelated modality. Think of HTML.

These tags let the document know this element is a paragraph.

Vectors work the same way.

Retraining a model is an expensive process. LoRA adapters allow you to fine-tune an existing model without retraining. For jina-embeddings-v5-omni, we use a LoRA adapter to tweak the final output to be optimized for 4 distinct tasks.

You mapped product_name as a keyword a year ago. Now someone wants to search inside it. That used to mean reindexing a year of data. In 9.5 you wrap it in TO_TEXT and ES|QL MATCH analyzes it at query time instead.

Your Claude Code agent forgets everything between sessions. So you bolt on a memory service. Another API, another thing to run. If you already run Elasticsearch, you already have the parts. semantic_text handles embeddings at index time. ES|QL gives you hybrid recall in one query: BM25 for the exact task ID, vector search for the related concept, a DECAY function so today's context outranks last month's. agent-memory wires it in with three hooks: SessionStart syncs, PostToolUse indexes every .md you write, Stop logs the session. The agent never has to remember to remember. Honest caveat: cross-device recall needs ES reachable from both machines. Not a local-only trick.

Run the same vector search benchmark across 3 engines. Jingra is a new open-source framework that uses YAML config to run identical workloads on Elasticsearch, OpenSearch, and Qdrant. The part that matters: with await_index_ready enabled, it holds evaluation until the index reaches the state you intend to measure. Elasticsearch merges segments after ingest. Qdrant runs its own post-ingest optimizations. Both affect query latency, and most benchmarks measure before either finishes. Parameter sweeps generate recall vs latency curves in a single run. Results go to console, CSV, or an Elasticsearch index for dashboarding. Apache 2.0, Docker Compose demos, one make command.

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