Hugging Face published its Papers with Code search architecture on August 21, 2026. The design combines PostgreSQL full-text search with pgvector semantic retrieval, then merges both result sets with Reciprocal Rank Fusion. For teams building search around technical documents, the useful lesson is the division of responsibilities: lexical search remains dependable, while embeddings improve matches when the query and document use different wording.
Build the lexical path first
Start with PostgreSQL full-text search and make it useful on its own. This branch is the system’s baseline, not a disposable fallback: it remains available when the embedding service is slow, cold or unavailable. Normalize the searchable fields, then confirm that ordinary keyword queries return sensible results before introducing semantic retrieval.
In the Papers with Code corpus, each paper is encoded as its normalized title, followed by two line breaks and its normalized abstract. Keep that format stable across the indexing pipeline. Changing the text sent to the embedding model changes every document representation and makes later comparisons less reliable. Apply the same normalization rules to live queries wherever the architecture calls for them.
That order also gives you a clear checkpoint. If the lexical branch does not return sensible results, adding vectors will make the system more complicated without fixing the underlying document or query preparation.
Add embeddings against a measured target
The semantic branch uses pgvector to improve recall when a query’s wording differs from the wording in a paper. Hugging Face’s production generation uses Qwen/Qwen3-Embedding-0.6B, pinned to an exact revision, with 256-dimensional L2-normalized vectors. The model’s official card describes a 32k context and configurable output dimensions from 32 to 1024; the reported production setup uses the smaller 256-dimensional output.
Use that configuration as a documented reference, not as a universal setting. The relevant question is whether semantic retrieval improves the queries that matter for your corpus enough to justify its storage and inference cost.
The reported 5,000-paper pilot provides a concrete benchmark. The 256-dimensional index reached a Recall@20 of 0.9955, with HNSW latency of 1.31 ms at p50 and 2.21 ms at p95. The table and index used about 27% of the storage required by the 1024-dimensional version, while approximate-nearest-neighbor quality was judged essentially equivalent in that test.
Those figures belong to that pilot. They are not a guarantee for another corpus, model revision or query mix. Measure recall and latency against a representative evaluation set before deciding whether the semantic branch earns a permanent place in the serving path.
- Keep PostgreSQL full-text search as the initial result source.
- Generate document embeddings from the same normalized title-and-abstract format.
- Use an authenticated inference service for live query embeddings.
- Measure recall and latency against a representative evaluation set.
- Keep the semantic branch only if the measured improvement justifies its storage and service cost.
Merge lexical and semantic ranks
The architecture combines the two result sets with Reciprocal Rank Fusion. Both branches use equal weights and k=60. This lets an exact terminology match remain visible while giving a semantically close paper a route into the combined ranking when it uses different language.
Equal weighting is a starting point, not an automatic optimum. If evaluation queries show that exact identifiers, model names or technical acronyms matter more than conceptual similarity, the lexical branch may deserve greater influence. Make that change from measured search quality rather than from a general preference for one retrieval method.
Keep the evaluation query set stable while comparing weighting choices. The goal is to see whether the merged ranking improves the intended results, not merely whether one branch produces more candidates.
Keep indexing separate from query serving
Hugging Face separates corpus construction from online search. The batch process exports the latest version of each paper from a repeatable-read PostgreSQL snapshot, streams rows instead of loading the full catalogue into memory, writes bounded JSONL shards and creates a SHA-256 checksum manifest. The importer can then verify the generated artifacts before they are activated.
For batch embedding, the documented setup mounts a private Storage Bucket in an l4x1 Job with an NVIDIA L4 GPU and 24 GB of VRAM. The command is configured for a maximum of six hours. In the 5,000-paper pilot, the Qwen Job encoded roughly 75 papers per second at 1024 dimensions on an L4 GPU.
Use that throughput only as a planning datapoint for the stated pilot. Larger documents, a different corpus or another configuration can change the result, so capacity planning still needs measurements from the workload you intend to run.
Hugging Face Jobs handles the GPU computation, while Storage Buckets provide durable transfer between systems. The online side uses an authenticated Inference Endpoint backed by Text Embeddings Inference. It receives the query text and returns a normalized 256-dimensional vector using the query prompt.
Define the failure path before launch
The inference endpoint can be cold, busy, unavailable or return an invalid vector. In every case, the system immediately drops the semantic branch and keeps the lexical results. Search therefore stays available, but result quality can change during the failure window. Operators need monitoring that makes this degradation visible rather than treating the fallback as an invisible success.
The endpoint is limited to one replica and can scale down to zero while idle. Cold starts are consequently part of the request design. The documented query client uses a one-second production timeout, giving the semantic call a bounded opportunity to improve the result without holding the request open indefinitely.
Privacy has an equally concrete boundary: the client logs only a normalized query fingerprint, not the raw query text. Preserve that rule in surrounding application logs, traces and error reports. A timeout fallback protects availability, but it does not protect query privacy if other observability paths record the original text.
Update the index in small, verifiable generations
The incremental process runs hourly, handles at most 500 papers per pass and processes batches of 16. Before writing, it rechecks the row lock and content hash. That check prevents an embedding job from quietly replacing a representation after the underlying paper has changed.
Before activating a generation, the importer checks schemas, checksums, dimensions, normalization, unique identifiers and content hashes. It enables the HNSW index atomically only when all current admissible papers are covered. Follow that sequence: validate the complete generation first, then switch the serving index in one operation. A partially populated semantic index should not become the default by accident.
This generation model also gives the lexical path a clear role during updates. Until the new semantic generation passes validation and becomes active, the existing serving behavior remains the safer point of reference.
Related-paper recommendations reuse the document vector already stored in the database, so they need no model call at query time. They are a natural addition after the core search path is stable, provided the same document identity and generation checks apply.
Choose the smallest architecture that meets the target
If keyword search already meets the quality target, keep it as the main path and add embeddings only after evaluation shows a measurable gain. If semantic retrieval improves the target queries, use the documented hybrid pattern with equal rank weights as a starting point, while preserving the one-second timeout and lexical fallback.
The operational safeguards determine whether that compromise remains manageable: private transfer storage, authenticated inference, no raw query logging, checksum validation and atomic index activation. They do not eliminate the trade-off between semantic coverage, infrastructure cost and cold-start behavior. They make the trade-off observable, bounded and recoverable.
The practical sequence is therefore straightforward: establish a useful lexical search, measure the semantic gain, merge the ranks, isolate batch work from online requests and validate every generation before activation. The result to verify is not simply that vectors exist, but that search quality improves without turning the embedding service into a single point of failure.