Notifications
Clear all
Topic starter
19/08/2026 3:45 pm
TL;DR: Phrase search over agent traces fails when common words create rare ordered intersections, and shingled bloom filters cut scan volume from over 100 GB to under 4 GB on a 290 GB test slice, according to Braintrust. The practical lesson is that index design, not just query tuning, becomes the bottleneck as trace datasets grow.
NHIMG editorial — based on content published by Braintrust: Faster phrase search with shingled bloom filters in Brainstore
By the numbers:
- 5% of the dataset, e-term bloom filters eliminated only 5% of the dataset, while shingle search eliminated 98.5%.
- Brainstore compared 63 of 64 segments eliminated with trigram shingles versus 3 of 64 with unigram filters.
Questions worth separating out
Q: How should teams improve phrase search for large agent trace datasets?
A: They should index for selectivity, not just recall.
Q: Why do common words make phrase search so slow in log and trace systems?
A: Common words generate huge postings lists, so the search engine cannot narrow candidates early.
Q: How do you know if a trace search index is actually effective?
A: Measure how much data and how many segments the query must scan before it finds the answer.
Practitioner guidance
- Map your dominant query shapes first Classify whether your investigators usually search by rare identifiers, common phrases, or mixed token sequences before choosing an index strategy.
- Introduce shingle-based pruning for phrase-heavy workloads Where exact wording or ordered token sequences matter, emit overlapping trigrams at index time and probe those shingles during segment elimination.
- Benchmark against cold-storage reads, not just warm-cache queries Test the search path on realistic object-storage backed datasets and measure how many segments and gigabytes are scanned before a match is returned.
What's in the full article
Braintrust's full engineering post covers the indexing and segment-pruning details this analysis intentionally leaves at the architecture level:
- How trigram emission is wired into the Brainstore indexing path for tokenized text fields
- Why the same per-segment bloom-filter structure can be reused without redesigning the full search stack
- What the 290 GB representative dataset showed about scan reduction and query timeouts
- Where Brainstore still plans to improve object-store reads, columnar execution, and aggregation performance
👉 Read Braintrust's engineering analysis of shingled bloom filters for phrase search →
Shingled bloom filters for phrase search: what changes for agent teams?
Explore further
19/08/2026 4:23 pm
Phrase-search performance is now an observability governance issue, not just an engineering optimisation. When teams cannot find the right trace or log fragment quickly, they lose investigative continuity across agent workflows. That affects how security, platform, and identity teams validate what an agent did, when it did it, and which credentials or sessions were involved. The operational conclusion is that search architecture has become part of evidence retention.
A question worth separating out:
Q: What should security teams do when search latency blocks agent investigation?
A: They should treat retrieval latency as an incident-response constraint and tighten the search path around the queries they use most often. If the team regularly searches for ordered phrases, identifiers, or evidence trails, the index must be tuned so those searches stay bounded under real storage conditions.
👉 Read our full editorial: Phrase search at agent scale needs shingled bloom filters
