CASE STUDY · SEMANTIC ANALYTICS

DEEP RESEARCH.
ONE REQUEST.

"Of calls about wifi issues, how many are 2.4GHz vs 5GHz, and what are the key issues?" One question bundles retrieval, aggregation, labeling and evidence — normally an OLAP engine plus a vector store, with ETL between them. In XERJ it is one POST /_search: slice, breakdown, metrics and evidence come back together.

FOR·AI-OVER-SUPPORT TEAMS·DATA PLATFORM ENGINEERS

GENERATED CORPUS · NOT A BENCHMARK · 130 SYNTHETIC CONVERSATIONS

XERJ SPLIT STACK

Requests per question 1 2

Stores to operate 1 2

ONE RESPONSE CARRIES

01SEMANTIC SLICEk=80 nearest conversations

02BREAKDOWNterms buckets: band, key issues

03METRICScsat p50 · handle-time avg, per bucket

04EVIDENCE3 example hits → LLM narrative

SPLIT STACK = OLAP + VECTOR STORE + ETL, OR TWO ROUND TRIPS IN ONE ENGINE · SOURCES IN docs/case-studies/calltree-analytics →

THE SPLIT-STACK TAX

Two systems before one answer. An OLAP engine for the columns, a vector store for the embeddings, ETL between them.
No cross-system join. The semantic slice lives in one store, the metrics in the other.
Two round trips even inside one engine. Run the kNN, ship the ids back to the client, aggregate with a filter.
Evidence arrives separately. The example conversations the LLM narrative needs are yet another query.

THE XERJ ANSWER

One index holds everything. Keyword columns, full text, and the 768-dim vector are fields of the same document.
Aggregations run on the kNN slice. rc.6 computes the buckets over the retrieved top-k neighbour set, in-request.
Exact buckets by design. An aggs-bearing kNN routes to the exact scan, so counts are never approximate.
Evidence rides along. Example hits return in the same response; one LLM call turns them into the narrative.

ONE REQUEST, WHOLE ANSWER.

query.knn retrieves the semantic slice; the aggs block computes the band split, key issues, CSAT percentile and handle-time average over that slice; size: 3 returns the evidence hits. Demonstrated live with real 768-dim vectors — XERJ stores and searches them, it does not embed, so retrieval quality is your embedding model's job (EmbeddingGemma is a stand-in for yours).

curl -s localhost:9200/conversations/_search -H 'Content-Type: application/json' -d '{
  "query": { "knn": { "field": "vec", "query_vector": [/* embed("wifi issues...") */],
                       "k": 80, "num_candidates": 130 } },
  "size": 3, "_source": ["band","issue","body"],
  "aggs": { "by_band": { "terms": { "field": "band" }, "aggs": {
      "key_issues": { "terms": { "field": "issue", "size": 4 } },
      "csat": { "percentiles": { "field": "csat", "percents": [50] } },
      "aht":  { "avg": { "field": "handle_time_s" } } } } }
}'

ONE POST /_search · RC.6

"of calls about wifi issues, how many 2.4 vs 5GHz, and what are the key issues?"

retrieved 80 nearest wifi calls; aggregated in the same request:
  2.4GHz  29 (54%)  csat_p50=4.0  aht=897s  issues: channel-overlap, congestion, disconnects, legacy-device
  5GHz    25 (46%)  csat_p50=4.0  aht=924s  issues: range, disconnects, congestion

deep-research narrative (LLM over the retrieved examples):
  The key issue is that the 5GHz signal is weak in a nearby room, dropping to 2.4GHz
  and resulting in slower speeds.

RECORDED RUN · SEEDED-GENERATOR OUTPUT · 54 OF THE 80 CARRIED A WIFI BAND; THE 26 N/A ARE FILTERED CLIENT-SIDE · 03_deep_research.py

WHAT THIS DOES NOT SHOW.

EXACT SCAN, NO SPEED CLAIM.

An aggs-bearing kNN always runs the exact brute-force scan: num_candidates is ignored, HNSW never serves it, and cost scales with corpus size × dims. Nothing here was timed.

BUCKETS COUNT THE SLICE.

Aggregations count only the retrieved top-k neighbour set, and hits.total.value echoes k — the 80 is the request parameter coming back, not a corpus match count.

KNOWN GAPS.

significant_terms over a kNN slice returns empty, hybrid (RRF) + aggs is rejected with a 400, and kNN inside bool.filter returns no buckets. Use terms in-slice, or the two-step pattern.

SYNTHETIC, NOT EXCLUSIVE.

The numbers are artifacts, not findings. ES/OpenSearch or Postgres + pgvector can express this shape too — what differs is cost model and operational weight, not possibility.

DEEP RESEARCH.
ONE REQUEST.

THE SPLIT-STACK TAX

THE XERJ ANSWER

ONE REQUEST, WHOLE ANSWER.

WHAT THIS DOES NOT SHOW.

READ THE WALKTHROUGH.

RUN IT ON
YOUR CONVERSATIONS.

DEEP RESEARCH.ONE REQUEST.

THE SPLIT-STACK TAX

THE XERJ ANSWER

ONE REQUEST, WHOLE ANSWER.

WHAT THIS DOES NOT SHOW.

READ THE WALKTHROUGH.

RUN IT ONYOUR CONVERSATIONS.

DEEP RESEARCH.
ONE REQUEST.

RUN IT ON
YOUR CONVERSATIONS.