A Tenth of Google's Index, 99.9% Recall: How 20 People Built Brave Search

Nathan Labenz opens this Cognitive Revolution as the show's first sponsored episode and says so immediately. Brave has been a sponsor for months; he still approached the recording the way he always does, with a product deep dive, and he argues the conversation holds the usual standard. Josep M. Pujol, Brave's chief of search, is unusually open about how the index and infrastructure were built, including the trade-offs the team accepts to keep user data private. The scale is already real: more than a million searches an hour, roughly 300 per second.

What Labenz found most useful is not a young-startup story. Brave's habit, under live traffic, is to refuse steps backward. Each generation adds models and techniques, which makes the ensemble more effective and more complicated. Evaluation still has no fully automated substitute for human judgment. After the taping, Labenz kept testing the Brave Search API against Google and Bing for Waymark, his company's small-business profile builder, which today leans on scraping. He found Brave notably better, recommended it to the product team, and expects to augment rather than replace the current pipeline: faster returns, coverage for URLs the scraper misses, and bonus context from discussion and review sites. He published a Colab notebook that hits all three APIs so listeners can run the same comparison.

Pujol joined Brave about three and a half years ago after Clicks, a search startup that died for lack of funding and COVID-era timing. The team had other offers and picked Brave because the values matched: privacy-preserving software, and a full technology suite that does not have to rent its stack from big tech. The company was founded by Brian Bondy and Brendan Eich. The product line now includes a browser, a VPN, an ad network, the Leo chatbot, and an independent search engine. Brave as a whole is about 100 people. The core of search — engineering plus quality raters — is about 20.

The most distinctive data path started at Clicks and continued as Brave's Web Discovery Project. Users who opt in send browsing signals, which sounds dangerous until the collection design is on the table. Pujol rejects the data-versus-privacy dichotomy. The danger is not data as such; it is purpose and method. Contributors do not upload a browser history or a search history. They send individual anonymous elements: someone visited this site and engaged with it this much. Brave has no way to know whether two elements came from the same person, so it learns nothing about you. It learns that a page is popular, or that a page was clicked after a particular query.

The plumbing is meant to make that claim hold under attack. There are no user IDs, implicit or explicit. Messages travel a mixing network to strip network fingerprints, they are homogenized, and they must pass a quorum: more than *N* people have to send the same data before Brave will receive it. The result is record unlinkability. Even a worst-case dump to a hacker or a government agency, Pujol says, would not let anyone identify or profile a particular person. The cost is that the data cannot be reused. Google and Microsoft collect similar signals; the problem is a dataset designed to answer every question, legitimate and illegitimate. Brave collects one element per class of question. Profile data is more useful. It is also how a session gets deanonymized.

The index is not built only from those visits. A URL that survives the quorum is public enough to fetch; Brave does not accept the page content from the user, because content might hold private information. Most of what the team does is fetching rather than a blind crawl of the whole web. Blind crawls, Pujol says, drown you in noise — at least ten GitHub clones, Knuth clones, copies that inflate the index tenfold. Noise reduction is the single thing you have to do extremely well, because noise hits model quality, scalability, and cost at once. The relative size of the index, against Google, is a tenth. With that, he claims 99.9% recall. Labenz calls it power laws in action.

Labenz assumes PageRank still contributes some authority from the link graph. Pujol does not. "PageRank is a myth." He was already an adult, almost starting a PhD, when Google appeared, and he used it while it still lived on a Stanford URL. Google released two papers: the PageRank scientific paper, and a technical report, *The Anatomy of a Large-Scale Hypertextual Web Search Engine*, that he treats as the real meat. PageRank was a gimmick that worked and made a story journalists could tell — an algorithm that changes everything, a straight line from invention to victory. That is not what happened.

Larry Page and Sergey Brin, using Stanford resources, were the first to brute-force a crawl of the whole web. The hard-drive-on-Lego photographs exist because they bought so many disks they had no iron racks, only brick stands. Crawling everything meant backlinks, and backlinks carry anchor text: everybody else's description of your site, instead of the webmaster's own blurb, which is what AltaVista had. Noise reduction again. What is cleaner, the page's own copy or a thousand other people's summaries of it? From the adjacency matrix you can compute an eigenvector and write a lovely paper about a random walk. That was icing. The meat was a full-web crawl on one filesystem and the realization that you now had a cleaner representation of a page than the page content.

Brave still has a notion of authority, but Pujol says they drive it from popularity and traffic, maybe one or two hops of calculation, a small contribution. The real parallel to anchor text is query logs: other people's queries as a description of what a page is about. Brave Search started life as a recommender. Logs accumulate, then you expand semantically across queries. You have never seen "what is the age of Lady Gaga," but you have seen "Lady Gaga's age," so a result that worked for one can work for the other. The query-similarity system holds more than nine billion unique queries and, given a new one, returns a set of historical neighbors in 20 milliseconds, using both embeddings and query n-grams. Later come synthetic queries that a page might answer, then conventional n-gram indexing of page content, which is more expensive and only makes sense as the next increment. The story is boring: 1% steps until it works.

Hardware made some of those steps possible at all. At Clicks, a memory-mapped recommender needed the whole cache in RAM. Servers topped out at 16 GB; two terabytes would have meant thousands of machines and unworkable latency. Then Amazon shipped instances with a terabyte of RAM, and a four-machine cluster made the design easy. Without NVMe, Pujol says Brave Search would not exist as a cost-effective product. Spinning disks are impossible; ordinary flash is still an order of magnitude too slow compared with RAM. A hundred terabytes or a petabyte of NVMe changes the architecture. Brave Search was stacked by taking whatever the world happened to offer at each moment.

The Lady Gaga example was already semantic matching. Brave started with StarSpace embeddings in 2019: 200 dimensions, two bytes, nearest-neighbor search before people called it vector search. Pure semantics is not enough then or now. Some queries have no semantic meaning — a product model, a stack error, a name. Pujol's own name is Josep Pujol, not José; Spanish and Catalan sit very close in any semantic model, and they are different people. The takeaway he would give anyone is that there is no single bullet. A problem worth solving is always a combination of techniques and models, with an ensemble on top.

On page content they run both. Dense embeddings from BERT-like Transformers are 384 dimensions at two bytes each, one to five vectors per page, for semantic matching. Sparse embeddings are 16,000 dimensions at one bit each, for literal matching. Search uses both. Query "Trump Tower" and you want Trump Tower, not Trump plus something else. The university intuition — take OpenAI embeddings, dump them in a vector database, done — works only for narrow verticals. Embeddings are not error-free. If they fail once every 10,000 items, a 100,000-document store looks fantastic. At 20 billion documents those errors flood the recall set: 2,000 candidates, 10% noise, and you are blind unless other models can pull the noise out.

They learned the vertical lesson the hard way. Early on, with few people, they tried splitting search into a hundred verticals: weather, cities, famous people, cars. Every vertical worked perfectly. There was no way to put them together. They had pushed the real problem into a future mixing module. In the movie vertical, "Ted" has one meaning. On the whole web it is a movie, a person, a conference, a part. General-purpose search is hard because of that noise. Labenz's plumbing-catalog project — old paper parts manuals, identifiers with no semantics — is landing in the same place: hybrid search, exact match beside a general embedding, rather than leaping straight to fine-tuning. Pujol's engineering rule is to fall in love with the problem, not with a framework.

The ensemble is learned, not a pile of heuristics. Distances from the various embeddings become features. Across the engines they run at different stages, that can mean 200 to 300 features feeding a gradient-boosted decision tree for final ranking. Labenz asks if that is a mixture of experts. Pujol says it is the same idea, "a really bad mixture of experts": an ensemble, except MoE typically picks two of eight experts at a time. For a builder choosing embeddings, he would try five or ten uncorrelated models — some semantic, some literal, some multilingual, some English — rather than hunt for one perfect vector. Correlated models add nothing. Uncorrelated distances are extra features, and extra features are how ranking improves.

How you upgrade depends on the component. The AI summarizer, a RAG answer Brave shows for about 25 to 30 percent of queries, is the easy case. The team puts real weight on snippet selection and runs narrower QA models on those snippets, then sends a prompt to an LLM. Summarizer v1 started about a year before the taping with Flan-T5, moved to other models, and went through three changes in a few months, including a fine-tune. Version two launched on Mixtral; Llama 3 came out two weeks later, tests showed comparable quality on fewer resources, and they switched in a week. A test set plus a stateless part in the pipe is enough.

Embeddings are the opposite. The 2019 StarSpace query embeddings are still in production and, Pujol says, will never be replaced. Content embeddings from BERT-style Transformers run at about 500 pages per second — two milliseconds a page, fully optimized, on a single GPU — which anyone who has batched Transformers will recognize as fast. Even so, the full dataset takes about a year and a half. You do it once, then build narrower models and heuristics on those outputs. You cannot churn that every quarter. What you can do is keep embeddings v1, v2, and v3 in the mix. Adding is never a problem: each new vector family is another set of distances for the GBDT. Replacing is the disaster, because you throw away an uncorrelated signal you already paid for.

Labenz pushes on the word "never": the world changes, surely you need a new model for new developments. Pujol's point is that you add the new model so you can have two query-document distances instead of one. The cost of a fresh embedding pass might be a month of many GPUs and a lot of money, which is not a three-month cadence; it might be another year. Constraints differ at 1,000 documents or a million, he notes. A plumbing catalog can be re-embedded without much trouble. At search-engine scale, anything bound to the data you do not touch. Anything stateless — the LLM that summarizes or paraphrases — you can change from one day to the next.

Swapping a model is easy. Knowing it is better is not. Brave keeps a team of human assessors, a significant chunk of search though not the majority, with a homogeneous methodology for summaries, rankings, and accuracy. Volume is limited; quality is the ground truth. Query logs, including Web Discovery Project traffic, let them compare against Google, Bing, and Yandex with NDCG and result-set intersection. When a query class diverges from Google, they sample and judge by hand: are we wrong, or do we have different criteria? Search engines end up resembling each other because they cross-reference. Over time the test sets grow to tens of thousands of high-quality human labels and hundreds of thousands to millions of automatic ones. Some queries are held only by the quality team so engineering cannot overfit them, including the quiet overfitting that happens when you tune hyperparameters. The release rule is best effort: if quality and performance are not worse, ship; if performance is worse, a judgment call — go and optimize later, or cancel the release.

Labenz asks whether the summarizer has something like OpenAI's model spec, a constitution for length, tone, and taste. "Yes, but it's a constitution of one" — the colleague who owns it, plus common-sense guidelines: do not be biased, be as concise as possible. They do not have time for a full guardrail document. Periodic fine-tunes on results the team considers very good are how style is supposed to transfer. There is no editorial line, Pujol says, no politics, no censorship; taste still belongs to whoever is rating, as it does at every other product. Llama 3 is more verbose than Mixtral, so after the switch Brave's summaries got longer. They can turn that down a little. Some behavior is inherent in the tool. If you do not know what the right thing is, the honest move is to do nothing until you have more data and assessment capacity — not to jerk the model because someone on Twitter complained.

Labenz, as a power user, routes queries: Perplexity for the shortest answer, You.com research mode for a two-page thousand-word brief, Brave in the middle. Pujol pours cold water on that as a model of normal behavior. Search is a one-stop shop. People are not discovering; they have a problem. They want Hotmail, or they want a Mojito recipe because they are making the Mojito right now. They do not want two pages of Mojito history. Because Brave is the default search engine of the browser in many countries, it has to serve the common denominator. Fancy experiments are easier when you have no traffic. Users do not reward good experiences; they punish bad ones. You stop going to the shop that treated you wrong once. Google, sitting on running-water traffic, has less room to innovate than You.com, Perplexity, or Kagi. About 30 percent of Brave users are in the United States; Europe is the next large market. The search team itself is entirely in Europe, with some people in Africa, all in the same time zone, even though Brave is a U.S. company.

The meme that recipe sites open with a diary entry is, in his account, SEO: a random walk that happened to work, then copying. Do not underestimate accident. A page with good information in a format Google's parser dislikes will index worse than worse information in free text the parser is sure to get. Optimizers ensemble many formats against an algorithm that may not have a strong rationale — a structure penalized because it parsed badly, a boost that fell between two stacks. According to the leaked Google documents, the company has 14,000 features per page. Pujol finds that a little much, but Brave has hundreds, so thousands would not shock him. Nobody can narrate why each feature exists.

Asked how the web changes under LLM spam and rising walls around training data, Pujol is mildly pessimistic. Incentives have been shifting for a long time — advertising, then ad blocking. If AI answers remove both the economics and the reputation of a visit, the reason to produce content thins out. He is old enough to prefer YouTube to Netflix and Myspace to Facebook because he likes variety, gems mixed with crap. AI will not be the thing that kills the web, he says, but it is another turn away from the web he grew up with. Convenience always has a price. Answers are not knowledge; questions are knowledge, and answers are just answers. An oracle that replies to anything is a world in which everything else does not exist.

The convenience is why Google is forced to ship AI answers and why Brave feels the same pressure. It is not cheap. They serve about 27 to 30 million queries a day; 10 to 30 percent of those go through an LLM. A summary usually maxes a 4,000-token context window. Everything is self-hosted, both for independence and because third-party LLM bills would be unaffordable. The big model currently sits on 28 H100s at Amazon, plus more GPUs for smaller QA models and classifiers. Large, he says, but not as massive as people imagine, and not yet expensive enough to force a business-model change. Doubling search infrastructure to run LLMs is less exotic than the hype suggests: a search engine was never cheap. Google could absorb it. The harder question is whether most searchers even want a chatbot in the way. Once you are running water for the general public, you cannot experiment as freely as a small, self-selected audience can.

The Search API exists because Brave finally stopped needing Bing. At launch the engine could answer 87 percent of queries independently; the rest went to Bing. That share climbed through 90, 92, 93, 94, and a little more than a year before the episode they left Bing entirely. Only then could they sell an API, because Bing's terms would not have allowed resale. Public options, as Pujol counts them, were Google's Custom Search — capped at 10,000 queries a day, meant for site search, not production — and Microsoft's paid API. Brave's differentiators are a public, pay-and-use API, looser terms (no required attribution, mix results as you like), and more payload. Labenz's Colab comparison found that for a ten-result query, Brave often returned a multiple of the raw characters from Google or Bing, via extra snippets and structured data. The summarizer tier he would actually use is $9 per thousand queries against a roughly comparable Bing tier at $25, more than 60 percent cheaper.

Brave did not set out to dump volume for its own sake. Data without noise is the constraint. Dynamic snippet generation already produces multiple candidates that a QA model scores; above a threshold, Pujol asks why you would withhold them. Extra snippets let a developer choose, fill a prompt, or cherry-pick. That cherry-picking, not the LLM, is the summarizer's secret sauce: they switched Mixtral to Llama 3 in a heartbeat, and the time goes into feeding the prompt non-repeated, non-contradictory information. He will not name customers. Most forbid it in a competitive market; some big names use the index to train foundation models, and one pattern he likes is grounding — segment an LLM's output and run it back through search to check whether the claims are legitimate. A YouTube-and-GitHub Perplexity clone stitched together LangChain, Brave, and Groq is the demo he points builders toward. The goal, he says, is simply that there is one more search API to choose.