Week 2 Updates: Improved search

Note: this blog was created with the help of AI based on the ramblings I put in.

Purili v2: Week 2 Search Update

Purili has now been running entirely on its schema-v2 search stack for a second week.

This week focused less on adding visible features and more on retrieval quality: making better use of a much larger index, protecting official results, improving how-to searches, measuring more representative queries, and rejecting ranking changes that only improved a narrow set of examples.

A larger index with better ranking

Purili's web and news index has grown from roughly 245 million to more than 368 million documents.

The larger corpus improved recall and result-page depth, especially for local, informational, comparison, and developer searches. It also made ranking more difficult: more indexed pages means more weak, duplicated, regional, and partially relevant candidates competing for the first page.

This week's ranking work therefore focused on stability and precision:

• exact official destinations remain protected for known navigational queries;
• broad how-to searches no longer force a single publisher such as wikiHow;
• technical intent detection covers more libraries, infrastructure tools,

ranking concepts, vector databases, observability systems, and runtimes;

• relevant primary documentation receives bounded candidate support;
• comparison queries do not automatically favor one product's documentation;
• Dutch local and government searches give more weight to matching first-party

domains;

• low-quality authority candidates can no longer displace stronger normal

results outside the intent where they are useful.

Comparable 500-query results

The frozen 500-query inventory remains Purili's main broad regression benchmark. Compared with the end of week one:

How-to topicality improved from 52.2% to 62.9% during the latest ranking work. Informational searches remain the strongest part of the benchmark at 86.9% topicality.

The final independent 131-query production gate measured:

• 55.0% top-1
• 61.1% top-3
• 77.9% good@3
• 69.0% lexical precision at 10
• 0 spam queries and 0 zero-result queries

Direct API latency was 181 ms at p50 with a 1,003 ms maximum in the final post-deployment validation. The complete 500-query run measured 523 ms at p50 and 3,204 ms at p95.

A broader 1,000-query benchmark

The original benchmark contains a deliberately difficult concentration of search-engine engineering, Tantivy, reranking, and long compositional queries. That is useful for finding weaknesses, but it is not representative of every normal search task.

Purili now also has a reproducible 1,000-query inventory. The original 500 queries remain frozen, while the new half adds common navigation, factual questions, how-to tasks, Dutch local services, shopping, current information, health and civic topics, discovery, mainstream software development, and Dutch, German, French, Spanish, and Italian searches.

The combined benchmark passes the earlier 60% and 40% targets, but Purili does not use that result to declare the historical target complete. The added common-task cohort is materially easier for the automated lexical evaluator. Both halves will continue to be reported separately.

The inventory is curated rather than collected from personal search histories. Purili does not retain users' search queries for benchmark construction.

Smarter result pages

Purili continues to provide direct information without generative AI.

The result page can combine:

• persistent exact Wikipedia infocards;
• typed factual and relation answers;
• structured FAQPage answers from indexed pages;
• carefully gated, source-attributed indexed excerpts;
• official destinations and local first-party results;
• books, videos, and news inserted when they match the detected intent;
• calculators, conversions, weather, currency, sports, time, translation,

dictionary, color, and graphing tools.

Currency no longer triggers on arbitrary three-letter words, exact book searches retain their infocard, and regional or parameter-based duplicates are collapsed before they can occupy several result positions.

The current 69-query instant-answer production gate passes 68 out of 69 checks. The remaining failure is a refund query where a newly indexed university policy displaced the intended general business-refund excerpt. This is being treated as a source and intent-selection problem rather than hidden by the aggregate score.

Experiments that did not ship

More ranking movement is not automatically better ranking.

This week Purili tested broader conjunctive retrieval, two-term long-query anchors, expanded natural-language stopwords, mandatory technology anchors, and a small local cross-encoder reranker. Some improved individual examples or the automated 500-query proxy, but reduced the independent 131-query gate, added latency, or failed to improve topicality consistently.

Those variants were removed instead of being deployed. The production update contains only the bounded changes that passed both regression suites.

Current search coverage

Purili now searches more than:

• 368 million web and news documents
• 40 million books
• 70 million videos

Books and videos remain available through dedicated search pages and can also appear inside web results when they are relevant to the query.

What comes next

Purili is noticeably stronger on common informational, how-to, shopping, and discovery searches, but complex, comparison, and specialist developer queries remain the largest weaknesses.

The next priorities are:

• keep pushing the frozen 500-query benchmark beyond 60% top-10 topicality;
• raise fully topical pages beyond 40% on that same unchanged benchmark;
• improve long-query decomposition without introducing broad partial matches;
• retrieve exact framework and API documentation more reliably;
• expand pooled human judgments for trustworthy NDCG@10 and MRR;
• fix the remaining instant-answer source-selection failure;
• preserve low latency while the index continues to grow.

Week two confirms two things at once: Purili performs substantially better on common search tasks than the specialist-heavy benchmark alone suggests, and the difficult retrieval gaps are still real. Both measurements are necessary to build a search engine that improves in practice rather than only on paper.