Rank recommendation candidates.
One Chalk query.
This live demo scores hundreds of recommendation candidates for a shopper in a single Chalk online query. Pick a shopper, add categories to their session, watch the ranking change, and time the query.
Change session context and inspect the ranking
A bulk query scores the retrieved candidates together using the fictional shopper’s features.
Try this experiment · expected results
1Change one shopper’s session
Choose a shopper and rank their candidates. Add a category, select Rank candidates again, and compare the top items.
Expected: The ranking reflects the new session context alongside the existing history.
2Compare query execution
Enable the comparison that times a 15-row sample as single queries.
Expected: Compare the measured bulk-query time with the extrapolated single-query estimate; the estimate is not a timed run over every candidate.
Choose a shopper and rank the candidates. Chalk computes shared shopper features once and scores candidate rows in one bulk query; browsing changes the next ranking.
Built on Chalk
Fresh features for every candidate, computed in one request.
One round trip, not hundreds
Scoring 500 candidates is one request instead of 500. In the runs we measured, Chalk executed all 500 rows in about 75 milliseconds.
Windows at request time
Seven-day item popularity and a shopper's ninety-day spend are aggregated against the moment of the request, not last night's snapshot.
Live session context
What the shopper browsed a minute ago is a query input, combined with history in the same features. Ranking reacts on the next request.
The model is a feature
The ranking score is defined next to its inputs, so training and serving share one definition of every feature.
A candidate is a feature class
Model each (shopper, item) pair as a Chalk feature class that joins to the shopper and the item. Its cross features and the ranking score are expressions over both sides. Then send every candidate as a row of one bulk online query.
In this demo the ranking service is a small Python app on a Chalk scaling group, and the features are a Chalk project on the same environment. Candidate retrieval is a simple sampler standing in for a vector index.
from chalk.client.client_grpc import ChalkGRPCClient
client = ChalkGRPCClient() # or ChalkClient().query_bulk(...) over HTTP
candidate_ids = retrieve(user_id, k=500) # your ANN index or popularity sampler
# One request, one row per (shopper, item) pair.
result = client.online_query_bulk(
input={
Candidate.id: [f"{user_id}:{i}" for i in candidate_ids],
Candidate.user_id: [user_id] * len(candidate_ids),
Candidate.item_id: candidate_ids,
Candidate.session_categories: [",".join(session)] * len(candidate_ids),
},
output=[
Candidate.score,
Candidate.category_affinity_30d,
Candidate.price_misfit,
Candidate.item.title,
Candidate.item.price,
],
)
ranked = result.to_polars().sort("candidate.score", descending=True).head(10)Implementation details
How the example works
Retrieve
The ranking service pulls a few hundred candidate items for the shopper: some from their tastes, some popular, some to explore. Retrieval is cheap and broad.
Score in bulk
One online query carries every (shopper, item) row. Chalk resolves the shopper once, each item once, then computes the cross features and model score column-wise.
Rank and serve
The service sorts by score and returns the top items. Browsing in this session goes in with the request, so the next ranking already reflects it.
More capabilities
Expressions, not loops
Cross features and the model compile to native expressions, so cost grows with columns, not with Python calls per row.
Same features offline
The definitions that score candidates online also generate point-in-time training data offline, so the next model trains on what serving computed.
Score every candidate, every request
Talk to an engineer about serving ranking features for recommendations, search and feeds.