Hybrid Search Benchmark

1.1 Hybrid Retrieval as a Graph-Distance Problem

Brinicle treats hybrid product retrieval as a distance-function problem over one encoded representation. Each item is encoded with symbolic title evidence and, in hybrid mode, a dense title embedding. Queries are encoded in the same representation family. Search is then performed through one HNSW graph using a custom distance function that combines title-token agreement and vector similarity during graph traversal.

The retrieval mode is controlled by the distance configuration. A lexical configuration emphasizes title-token matching. A vector configuration emphasizes embedding similarity. A hybrid configuration combines both signals inside the same graph search process. This differs from the common architecture in which lexical and vector retrieval produce separate candidate sets that are merged afterward. In Brinicle, candidate exploration itself is hybrid-aware because the graph traversal uses the combined distance.

1.2 Product Search as a Motivating Task

Product retrieval is a useful setting for evaluating this idea because it requires both exactness and tolerance. A product query may contain short fragments that carry precise meaning:

In these cases, numbers, model identifiers, and capacities are not incidental text. They are part of the user’s intent. A semantically related result with the wrong model or capacity may be commercially incorrect.

At the same time, product titles are often long and noisy. They may contain brands, colors, editions, years, bundle descriptions, packaging terms, seller formatting, and marketing phrases. Users rarely type the full title. A retrieval system therefore needs to tolerate partial queries and vocabulary mismatch without losing exact symbolic evidence. This makes product search a natural hybrid retrieval task. Lexical matching helps preserve exact constraints. Dense embeddings help recover semantically related titles when surface forms differ.

1.3 Brinicle’s Approach

Brinicle encodes product-title tokens and dense embeddings into a single HNSW-searchable representation. The graph is built over this representation, and a custom scorer defines how the symbolic and semantic components contribute to distance.

At a high level, the method consists of three parts:

The encoded representation stores title-token evidence and, when enabled, a dense vector. The HNSW graph provides approximate nearest-neighbor traversal. The distance function determines whether the search behaves lexically, semantically, or as a hybrid of both.

This paper focuses on title-based hybrid retrieval. The evaluated configuration uses product titles and precomputed title embeddings for both documents and queries. Brinicle’s broader item-search representation can include structured fields such as category, subcategory, and attributes, but the benchmark isolates the title + vector retrieval setting.

1.4 Evaluation Overview

We evaluate Brinicle on WANDS and US-filtered Amazon ESCI, comparing it with Weaviate, Meilisearch, Typesense, and OpenSearch. All systems are tested under shared CPU and memory limits using the same precomputed embedding model.

The evaluation reports ranking quality, search latency, throughput, memory usage, and build cost. The main result is a system-level trade-off: Brinicle achieves competitive retrieval quality while reducing search memory usage and P99 latency in the tested setup. The results support the architectural claim that hybrid product retrieval can be expressed through one graph and one distance function, rather than requiring post-hoc fusion over separate lexical and vector retrieval structures.

1.5 Contributions

This paper makes four contributions.

1. It presents a single-graph formulation for hybrid product retrieval, where lexical and semantic evidence are represented inside one HNSW-searchable object.
2. It describes Brinicle’s encoded item representation and hybrid-aware distance function, including symbolic title matching, dense-vector similarity, and the alpha mechanism used to control semantic bias.
3. It evaluates the approach on two product-search benchmarks against four established hybrid search systems under shared resource limits.
4. It reports the resulting trade-off between retrieval quality, memory usage, and search latency, showing that a single-graph design can provide competitive hybrid retrieval behavior with a smaller search-time resource footprint.

2.1 Retrieval as Distance over Structured Representations

Brinicle represents each item as a structured numeric object rather than as an ordinary dense vector alone. The representation contains enough information for the distance function to interpret different components separately.

For title-based hybrid retrieval, the relevant components are:

The query is encoded in the same representation family:

The distance function then compares the query and document through both symbolic and semantic components. Title-token overlap contributes lexical evidence. Vector similarity contributes semantic evidence. The final distance is a weighted combination of these signals.

This makes the HNSW graph a retrieval structure over hybrid-search objects. The graph organizes items according to the distance function used during construction, and the same family of distance functions is used during search.

2.2 Unified Candidate Exploration

In a two-index hybrid system, candidate generation is usually split across retrieval structures. A lexical index explores term-based candidates, while a vector index explores embedding-based candidates. Fusion happens after those candidate sets have already been produced. Brinicle moves the hybrid decision earlier. Since graph traversal uses a distance function that includes both title-token matching and vector similarity, lexical and semantic evidence affect candidate exploration directly. This changes the role of the hybrid scorer. It is not only a final ranking function. It also helps define local neighborhoods in the graph and influences which candidates are reached during approximate search. The result is a single candidate-exploration structure: 1. encoded query 2. HNSW traversal using hybrid distance 3. candidate set 4. ranked results.

This is the central architectural distinction. Hybrid behavior is part of the graph-search process itself.

2.3 Retrieval Modes as Distance Configurations

Brinicle’s retrieval modes are expressed through distance configuration. The same encoded representation can support lexical, vector, or hybrid retrieval by changing the active components and their weights:

This gives the system a single conceptual model:

In lexical mode, retrieval is driven by symbolic title evidence. In vector mode, retrieval is driven by embedding similarity. In hybrid mode, both signals contribute to the distance used during graph traversal. The benchmark in this paper focuses on the hybrid configuration, where product titles and title embeddings are both active.

2.4 Product-Title Hybrid Retrieval

Product titles provide a useful test case for one-graph hybrid retrieval because they combine short exact identifiers with longer noisy descriptions. A title may contain model numbers, capacities, color names, brand names, technical variants, and marketing text. Some tokens are highly specific and must be matched carefully. Other parts of the title provide broader semantic context.

Brinicle’s representation preserves title-token evidence explicitly while also attaching dense semantic vectors. This allows the distance function to reward exact symbolic matches and semantic proximity within the same graph search. For example, a query such as “iphone 15 256gb” benefits from exact matching on iphone, 15, and 256gb, while vector similarity can still help when relevant product titles use different surrounding language.

The same principle applies to product queries involving model identifiers, abbreviated names, or partial descriptions. The graph does not need to choose between symbolic and semantic retrieval as separate execution paths. Both signals are available to the distance function.

2.5 Summary

One-graph hybrid retrieval can be summarized as follows:

This formulation makes hybrid product search a graph-distance problem. The next section describes how Brinicle encodes items and queries so that the distance function can compare symbolic and semantic evidence inside one representation.

3.1 Encoded Object Layout

Each encoded object begins with a fixed-size header followed by a variable-length payload. The header stores metadata needed by the distance function:

The payload stores the searchable content:

The header allows the scorer to parse the representation without external metadata. It can determine how many title tokens are present, whether structured fields exist, whether a dense vector is attached, and where each region begins.

For title-based hybrid retrieval, the active regions are:

This layout keeps the representation numeric while preserving internal structure. The scorer can interpret title evidence and vector evidence separately instead of treating the object as an opaque dense vector.

3.2 Title-Token Encoding

Product titles are converted into sorted token identifiers. The title encoding pipeline is: 1. title text 2. normalization 3. isolated tokenization 4. token-id extraction 5. special-token filtering 6. term-frequency packing 7. sorted title-token representation.

The tokenizer preserves short product-specific fragments such as numbers, model names, and compact identifiers. These fragments are important in product retrieval because small textual differences can change the target item. Examples include:

Dense embeddings can place related products near each other, but exact fragments still need to remain available to the scorer. Brinicle therefore stores symbolic title evidence explicitly as part of the indexed representation.

3.3 Term-Frequency Packing

Title tokens include a small saturated term-frequency signal. Conceptually, each stored title token combines a token id with a compact frequency component:

The frequency component allows repeated title terms to contribute additional evidence without making repetition dominate the score. This is useful for product titles, where repeated words may reflect emphasis, formatting, or seller-side noise rather than true relevance. The term-frequency signal is intentionally bounded. A repeated token can matter slightly more than a single occurrence, but excessive repetition is saturated by the scorer.

3.4 Dense Vector Attachment

In hybrid mode, Brinicle appends a dense embedding to the lexical representation. The benchmark uses title embeddings for documents and query embeddings for queries.

A document is encoded as:

A query is encoded as:

The vector region is parsed using the vector_dim value stored in the header. This allows the same distance function to combine token-based title matching with vector similarity. The resulting object is still a single HNSW-searchable representation, but the scorer can evaluate its regions separately.

3.5 Optional Structured Fields

Brinicle’s general item representation can also encode structured fields:

Category and subcategory are stored as stable identifiers. Attributes are stored as sorted key/value id pairs:

This allows structured evidence to participate in the same distance function as title tokens and dense vectors. For example, a product item may include title evidence, category identity, and attribute matches inside one encoded object. The experiments in this paper use the title + vector configuration, but the same representation layout supports richer item-search configurations.

3.6 Shared Representation Family

Documents and queries are encoded into the same representation family. This is what allows HNSW traversal to operate over hybrid-search objects directly.

A document may contain:

A query may contain:

The distance function compares the two encoded objects by reading their corresponding regions:

This shared representation is central to the one-graph design. The graph stores encoded items, and the query enters the graph as a comparable encoded object.

3.7 Encoding Summary

Brinicle’s item/query representation can be summarized as:

The representation is numeric, but not unstructured. Its internal layout allows the distance function to combine symbolic and semantic evidence during graph traversal. The next section defines the distance function used to compare these encoded objects.

4.1 Title Distance

The title component measures symbolic agreement between query tokens and document-title tokens. Product queries are usually shorter than product titles, so the title scorer uses an asymmetric overlap measure. Brinicle uses a Tversky-style similarity:

Here:

The parameters α_title and β_title control the relative cost of missing query tokens and extra document tokens. This is useful for product retrieval because a relevant product title may contain all query terms plus additional descriptive text. For example, query “iphone 15 256gb”, and document title “Apple iPhone 15 256GB Blue Unlocked Smartphone 2023”. The extra document terms provide context, but missing query terms usually represent a stronger mismatch. The asymmetric title distance reflects this behavior.

4.2 Term-Frequency Saturation

Title-token matches use the packed term-frequency signal described in Section 3. Repeated terms are passed through a saturation function before contributing to the title score:

The saturation limits the effect of repeated title terms. A repeated token can increase the contribution of a match, but repeated words do not scale linearly without bound. This gives the title component a controlled lexical signal. Token match is positive evidence, repeated token is slightly stronger evidence, and excess repetition is saturated contribution.

4.3 Build-Time and Search-Time Title Configuration

Brinicle can use different title-distance settings during graph construction and query-time search.

The build-time configuration shapes graph neighborhoods using balanced title overlap. The search-time configuration gives more weight to query coverage, which is appropriate for short product queries matched against longer product titles.

4.4 Vector Distance

The vector component measures semantic similarity between the query embedding and the document embedding. Brinicle uses scaled cosine distance:

The scaling maps cosine distance into a range compatible with the lexical distance components. Since cosine similarity lies in [-1, 1], the unscaled expression 1 - cos(q, d) lies in [0, 2]; multiplying by 0.5 maps it to [0, 1]. When vectors are normalized, cosine similarity can be computed through a dot product. The distance function can also use the general cosine path when normalization is not assumed.

4.5 Structured-Field Distances

The general Brinicle scorer can also compare structured fields. Category and subcategory are treated as identifier matches. Attribute fields are treated as sorted key/value pairs.

For category-like identifiers, the distance is direct:

For attributes, the scorer compares matching keys and evaluates whether their values agree:

These structured components allow category, subcategory, and attribute evidence to participate in the same distance function as title tokens and dense vectors. In the experiments reported in this paper, the active retrieval configuration uses title and vector evidence.

4.6 Hybrid Weighting

The general distance function is controlled through component weights. In title-based hybrid retrieval, the active weights are w_title and w_vector.

A lexical configuration sets the vector contribution to zero:

A vector configuration sets the title contribution to zero:

A hybrid configuration activates both:

This makes retrieval behavior a property of the distance configuration. The same encoded representation can be searched with different component weights depending on the desired retrieval mode.

4.7 Brinicle Alpha

Brinicle uses an alpha parameter to control the balance between semantic distance and lexical correction. For 0 < p < 1, alpha p is converted into:

The vector component keeps full weight, while the lexical components are scaled by w_lexical. At the boundaries:

For example, when p = 0.90:

If the base title weight is 0.45, the effective title weight becomes:

while the vector weight remains:

This parameterization treats dense-vector distance as the primary semantic geometry and uses lexical evidence as a correction term. Lower alpha values increase the strength of lexical correction. Higher alpha values make retrieval more vector-oriented.

4.8 Alpha and Graph Construction

In Brinicle, the distance function is used during graph construction as well as query-time search. Therefore, the selected hybrid configuration affects both neighborhood formation and query traversal.

The build process uses the configured distance function to decide how items connect inside the HNSW graph. A more lexical configuration creates neighborhoods influenced more strongly by title-token overlap. A more semantic configuration creates neighborhoods influenced more strongly by vector similarity.

The same principle applies during search: the query traverses the graph using the configured distance function, and candidates are ranked according to the resulting distances. This makes alpha part of the index configuration. In the benchmark, Brinicle indexes are built with the selected alpha value for each dataset.

4.9 Distance-Function Summary

Brinicle’s distance function combines interpretable regions of the encoded representation:

For title-based hybrid retrieval, the main distance is:

This distance is used by HNSW for graph construction and search, making hybrid behavior part of candidate exploration rather than a separate fusion stage.

5.1 Retrieval Task

For each query, the engine receives:

The corpus contains documents represented as:

Each engine returns the top K product identifiers. The returned identifiers are compared against the relevance judgments provided by the dataset. All experiments use top_k = 100. Metrics are reported at K = 1, 5, 10, 20, 50, 100.

5.2 Datasets

5.3 Compared Systems

5.4 Embedding Model

5.5 Indexed Fields

All engines index the product title as the lexical search field. For hybrid retrieval, each document also contains a dense vector field holding the precomputed title embedding.

The Brinicle configuration used in the benchmark activates title-token evidence and dense-vector evidence. Structured fields such as category, subcategory, and attributes are part of Brinicle’s general item representation, but they are not active in this benchmark configuration.

5.6 Runtime Environment

5.7 Retrieval Parameters

5.8 Hybrid Parameter Tuning

Each system exposes its own parameter for controlling the lexical-semantic balance. The parameters are tuned separately for each engine and dataset using the held-out tuning queries.

5.9 Benchmark Procedure

Each benchmark run has two phases. First, the engine builds or ingests the index. During this phase, the benchmark records build time and build memory. Second, the benchmark runs the evaluation queries. During this phase, the benchmark records returned product identifiers, per-query latency, throughput, and search memory.

The measured search outputs include:

5.10 Memory Measurement

Memory is measured separately for build and search. The benchmark records multiple memory counters, including:

The main results report peak search memory. Additional memory counters are included in the appendix.

5.11 Evaluation Metrics

The benchmark reports ranking metrics at K = 1, 5, 10, 20, 50, 100.

6.1 WANDS Results

On WANDS, OpenSearch has the highest Hit@1, nDCG@10, and Hit@100. Brinicle is close on all three relevance metrics, with the lowest P99 latency and the lowest peak search memory among the compared systems.

The WANDS results show a narrow relevance spread among the strongest systems. OpenSearch reaches 0.4956 Hit@1, while Brinicle, Meilisearch, and Typesense each reach 0.4844. At Hit@100, OpenSearch reaches 0.7467, while Brinicle reaches 0.7444.

The system measurements show a larger separation. Brinicle records 0.516 ms P99 latency and 129 MB peak search memory. The closest non-Brinicle P99 latency is OpenSearch at 1.480 ms, while the closest non-Brinicle search memory is Meilisearch at 239 MB.

6.2 ESCI Results

On ESCI, Brinicle has the highest Hit@1 and nDCG@10. Weaviate has the highest Hit@100, followed by OpenSearch. This indicates a difference between early exact-match ranking and deeper top-k retrieval.

Brinicle records 0.4280 Hit@1 and 0.3661 nDCG@10. The strongest non-Brinicle Hit@1 is OpenSearch at 0.4226, and the strongest non-Brinicle nDCG@10 is also OpenSearch at 0.3601. At Hit@100, Weaviate reaches 0.9054, OpenSearch reaches 0.9009, and Brinicle reaches 0.8932.

The system measurements again show the largest differences in latency and memory. Brinicle records 0.773 ms P99 latency and 1,731 MB peak search memory. The closest non-Brinicle P99 latency is OpenSearch at 3.407 ms. The closest non-Brinicle peak search memory is Weaviate at 4,794 MB.

6.3 P99 Search Latency

Figure 1. P99 search latency on WANDS

Figure 2. P99 search latency on ESCI

Brinicle has the lowest measured P99 latency on both datasets. On WANDS, its P99 latency is 0.516 ms, compared with 1.480 ms for OpenSearch, the closest non-Brinicle system. On ESCI, its P99 latency is 0.773 ms, compared with 3.407 ms for OpenSearch.

6.4 Search Memory

Figure 3. Peak search memory on WANDS

Figure 4. Peak search memory on ESCI

Brinicle has the lowest measured search memory on both datasets. On WANDS, Brinicle uses 129 MB, followed by Meilisearch at 239 MB. On ESCI, Brinicle uses 1,731 MB, followed by Weaviate at 4,794 MB. The memory difference is larger on ESCI, where the corpus is substantially larger. In that setting, Brinicle’s peak search memory is less than half of the closest non-Brinicle measurement.

6.5 Hit@K Curves

Figure 5. Hit@K curve on WANDS

Figure 6. Hit@K curve on ESCI

Figures 5 and 6 report Hit@K curves across K = 1, 5, 10, 20, 50, 100. On WANDS, OpenSearch is slightly ahead across the main reported relevance points, while Brinicle remains close. On ESCI, Brinicle leads at early ranking points reported in Table 2, while Weaviate and OpenSearch reach higher Hit@100. The full Hit@K, Recall@K, nDCG@K, and MRR@K tables are provided in the appendix.

6.6 Result Summary

Across both datasets, the results show three main patterns.

First, relevance is competitive across systems. On WANDS, OpenSearch has the strongest exact-relevance metrics among the reported values. On ESCI, Brinicle has the strongest Hit@1 and nDCG@10, while Weaviate has the strongest Hit@100.

Second, Brinicle has the lowest measured P99 search latency on both datasets.

Third, Brinicle has the lowest measured peak search memory on both datasets.

These results support the single-graph formulation as a practical retrieval design for title-based hybrid product search: lexical and semantic evidence can be combined during graph traversal while maintaining competitive exact-relevance quality and a smaller search-time resource footprint.

7.1 Interpreting the Retrieval Trade-Off

The relevance results differ across datasets and ranking depths. On WANDS, OpenSearch has the strongest reported exact-relevance metrics. Brinicle remains close across the main relevance points, with a small difference in Hit@1, nDCG@10, and Hit@100.

On ESCI, Brinicle has the strongest Hit@1 and nDCG@10, while Weaviate has the strongest Hit@100. This indicates that Brinicle performs strongly in early ranking, while other systems retrieve more exact matches at deeper top-k positions.

This pattern is useful because it separates two retrieval behaviors:

For product search, both behaviors can matter. Early ranking is important when results are shown directly to users. Deeper candidate coverage is important when the retrieval stage feeds reranking, recommendation, or downstream selection. The benchmark results therefore describe an operating profile rather than a single leaderboard. Brinicle’s profile is strongest in search-time efficiency and early exact-match ranking on the larger ESCI benchmark, while other systems show advantages in specific relevance metrics and deeper retrieval settings.

7.2 Hybrid Retrieval Inside Graph Traversal

The central architectural result is that lexical and semantic evidence can participate in the same graph traversal. In a conventional hybrid system, lexical and vector retrieval are usually performed through separate structures, and hybrid behavior is introduced through score fusion or reranking. Brinicle moves this combination into the distance function used by HNSW.

This has two consequences. First, hybrid scoring affects candidate exploration, not only final ranking. The graph traversal is guided by a distance function that includes both symbolic title evidence and dense-vector similarity. Second, the retrieval system has a smaller structural surface. The benchmarked Brinicle configuration uses one encoded representation, one HNSW graph, and one hybrid-aware distance function for title-based hybrid retrieval.

The results suggest that this design is sufficient to produce competitive retrieval behavior on the evaluated product-search tasks.

7.3 Early Ranking and Deeper Top-K Behavior

The ESCI results show a clear distinction between early ranking and deeper top-k retrieval. Brinicle leads the reported early-ranking metrics:

Weaviate leads the reported deeper metric:

This distinction is important for interpreting hybrid retrieval systems. A method can be strong at placing an exact result near the top while another method can be stronger at retrieving more exact results somewhere inside a larger candidate set. The appropriate retrieval profile depends on the application. A direct product-search interface benefits from strong early ranking. A multi-stage ranking system may prefer broader top-k coverage before reranking. In this benchmark, Brinicle’s strongest relevance behavior appears in early exact-match ranking on ESCI, while its strongest system behavior appears consistently in latency and memory across both datasets.

7.4 Search-Time Resource Profile

The memory and latency measurements show the clearest separation between Brinicle and the compared systems. Brinicle has the lowest measured peak search memory on both WANDS and ESCI. The difference is especially visible on ESCI, where Brinicle uses less than half the search memory of the closest non-Brinicle system. Brinicle also has the lowest measured P99 latency on both datasets. This result is consistent across the smaller WANDS corpus and the larger ESCI corpus. Together, these measurements show that the single-graph design changes the search-time resource profile of hybrid retrieval. The system does not maintain separate lexical and vector retrieval structures for the benchmarked hybrid task, and the measured search memory reflects that architectural choice.

7.5 Alpha as Index Configuration

Brinicle’s alpha affects graph construction as well as query-time search. This makes the hybrid parameter part of the index configuration rather than only a runtime fusion parameter. When the graph is built, the configured distance function influences neighborhood formation. A more semantic configuration creates graph neighborhoods shaped more strongly by vector similarity. A stronger lexical correction changes how symbolic title evidence contributes to those neighborhoods.

This is different from hybrid systems where the lexical and vector indexes are built independently and the hybrid parameter only affects query-time score combination. In the benchmark, each Brinicle index is built using the tuned alpha selected for that dataset. This means the reported Brinicle results reflect both the encoded representation and the graph topology produced by the selected hybrid distance.

7.6 Deployment Implications

The measured trade-off is relevant for deployments where search memory and latency are important constraints. A lower search-time memory footprint can reduce infrastructure cost, allow more indexes to run on the same machine, or leave more memory available for application logic. Lower latency can improve interactive search behavior and increase the headroom available for additional downstream processing.

Brinicle’s design is therefore most directly relevant to search systems where hybrid retrieval is needed but maintaining multiple retrieval structures is expensive. The benchmarked setting is title-based product retrieval, but the architectural pattern is broader: encode multiple retrieval signals into one comparable object, then use a distance function that combines those signals during graph traversal.

7.7 Discussion Summary

The results support three main observations. First, title-based hybrid product retrieval can be expressed through one HNSW graph and one hybrid-aware distance function. Second, Brinicle achieves competitive exact-relevance quality on both evaluated datasets, with stronger early-ranking results on ESCI and close relevance results on WANDS. Third, Brinicle shows a consistent search-time resource advantage in the reported measurements, with the lowest P99 latency and lowest peak search memory on both datasets. These observations support the paper’s main claim: hybrid product retrieval can be modeled as a single-graph retrieval problem, with lexical and semantic evidence combined during graph traversal rather than through post-hoc fusion over separate retrieval structures.

WANDS Citation

@InProceedings{wands,
  title = {WANDS: Dataset for Product Search Relevance Assessment},
  author = {Chen, Yan and Liu, Shujian and Liu, Zheng and Sun, Weiyi and Baltrunas, Linas and Schroeder, Benjamin},
  booktitle = {Proceedings of the 44th European Conference on Information Retrieval},
  year = {2022},
  numpages = {12}
}

Amazon ESCI Citation

@article{reddy2022shopping,
  title = {Shopping Queries Dataset: A Large-Scale {ESCI} Benchmark for Improving Product Search},
  author = {Chandan K. Reddy and Llu\'{i}s M\'{a}rquez and Fran Valero and Nikhil Rao and Hugo Zaragoza and Sambaran Bandyopadhyay and Arnab Biswas and Anlu Xing and Karthik Subbian},
  year = {2022},
  eprint = {2206.06588},
  archivePrefix = {arXiv}
}

D.1 WANDS Hit@K

D.2 WANDS Recall@K

D.3 WANDS nDCG@K

D.4 WANDS MRR@K

D.5 ESCI Hit@K

D.6 ESCI Recall@K

D.7 ESCI nDCG@K

D.8 ESCI MRR@K

E.1 WANDS Latency and Throughput

E.2 ESCI Latency and Throughput

F.1 WANDS Search Memory

F.2 ESCI Search Memory

G.1 Build Time

G.2 WANDS Build Memory (MB)

G.3 ESCI Build Memory (MB)