Task instructions
+00:00Task instructions
Build a latency-efficient PyTorch two-tower neural-network ranker
Build a two-tower neural network in CPU PyTorch for the "Made for You" shelf of a music streaming service. Although the supplied benchmark is small, it represents a production system with millions of users and millions of items; the training approach must scale to that setting and therefore must not construct or decompose a global user-item interaction matrix. The production shelf has a strict request-time latency budget. Candidate item embeddings are computed offline and stored in a nearest-neighbor index. At request time, the system computes one user embedding and retrieves items by maximum inner-product search.
The model must therefore decompose exactly into a user vector and an independently precomputable item vector of the same dimensionality, with the final relevance score equal to their dot product. Both vectors must be produced by separate trainable user and item towers implemented as PyTorch neural networks. The user tower must derive its representation from interaction history rather than a user-ID lookup. Per-user candidate eligibility, cutoff-specific explicit preference state, and a temporal backtest are provided. Candidate eligibility is platform-owned; all modeling within that candidate boundary is in scope.
Data
All inputs are under /task/data/. Training data ends at timestamp 24786800. A 30-minute gap precedes a seven-day public validation window. The hidden test is the following seven-day window after another 30-minute gap.
For each event family there is a train_*.parquet and val_*.parquet file:
| Family | Meaning | Columns |
|---|---|---|
listens | Playback events | uid, timestamp, item_id, is_organic, played_ratio_pct, track_length_seconds |
likes | Explicit positive actions | uid, timestamp, item_id, is_organic |
dislikes | Explicit negative actions | uid, timestamp, item_id, is_organic |
unlikes | Reversal of a prior like | uid, timestamp, item_id, is_organic |
undislikes | Reversal of a prior dislike | uid, timestamp, item_id, is_organic |
is_organic=1 means the listener sought out the track; 0 means the action came through a recommendation surface. A listen is a conventional positive at 50% completion. The discovery-quality objective below uses the stronger 80% threshold.
The two public windows have different roles:
- Build and tune a validation ranker using only
train_*as history andval_*as subsequent outcomes. - After selecting the approach, refit it on
train_* + val_*. At hidden-test time the validation events are observed history, not recommendable outcomes.
Do not use val_* events as features when measuring a validation ranking. They may and should be used when refitting the final hidden-test ranker.
Additional files under /task/data/:
candidate_catalog.parquet: the 30,000 retrieval-catalog tracks, ordered by training positive-listen popularity.target_users.parquet: users with at least 20 positive listens in the 90 days before the training cutoff, selected without future labels.validation_preference_state.parquet: active explicit state at the training cutoff, for validation ranking.test_preference_state.parquet: active explicit state after validation, for the final hidden-test ranking. State islikedordisliked; a pair may have both active channels.validation_eligible_candidates.npzandtest_eligible_candidates.npz: cutoff-correct candidate sets for every target user. Each contains aligned arraysuids,item_ids, andpacked_eligible. For user rowr, recover the Boolean item mask withnp.unpackbits(packed_eligible[r], count=len(item_ids), bitorder="little").
The exact available Python distribution inventory is listed in /task/requirements.txt. Future test interactions are hidden and used only by the separate Harbor verifier.
Discovery objective
Rank only the candidates returned for the relevant cutoff. Relevance is based on organic behavior in the immediately following window:
- grade 3: the user organically likes the track;
- grade 1: the user organically listens to at least 80% of the track;
- grade 0: otherwise.
If both positive events occur, grade 3 wins. Ranking quality is measured with graded NDCG@10. DCG uses gain 2^grade - 1 and discount 1/log2(rank + 1), then averages per-user NDCG over users with at least one relevant item.
The public evaluator reports this objective for development, but its score is not a separate acceptance stage. Final acceptance is determined on the hidden test using the same objective.
The Yambda logs contain interactions, not impression propensities. Treat the organic objective as a robust offline target, not as a causal estimate of online lift.
Public tools
/task/evaluate_public.py scores a validation-stage ranking against the public window. Pass the path to a ranking with the same schema as the final deliverable:
python /task/evaluate_public.py solution/validation.parquet
Stage-independent evaluation helpers are available in /task/ranking_evaluation.py. The builder installs the same checked-in module in the public agent image and private verifier image so scoring mechanics cannot drift. The public copy contains no hidden labels, evaluator-owned data paths, or pass thresholds.
The public evaluator uses validation_eligible_candidates.npz; it is not a validator for the final artifact. No model implementation, fitted representation, or example submission is supplied. Design and tune the required PyTorch neural two-tower model, then refit the selected approach as described above.
Deliverable
Write /app/solution/submission.parquet or /app/solution/submission.csv, with exactly 100 rows for every target user and columns uid, item_id, rank. Ranks must be the integers 1-100 with no ties or duplicate items. Every submitted item must be present in that user's test_eligible_candidates.npz candidate set.
Leave the code that defines, trains, and applies both towers, along with a concise /app/solution/README.md, in /app/solution/. The README should state the model architecture, training objective, public validation score, and final submission command. Keep the best valid submission saved throughout the attempt so it survives the deadline.
Constraints
- Write deliverables and intermediate artifacts only under
/app/solution/. - Treat
/task/and the installed Python environment as read-only. - Do not invoke nested agents or attempt to access verifier files, credentials, other trials, or host paths.
- Do not install packages or use network access except for the model provider connection managed by Harbor.
- The environment includes CPU PyTorch 2.8.0. No accelerator is available.
- You have up to 60 minutes. Improve the model as much as possible within that limit. Structural validity alone is not sufficient; the final submission is also evaluated for ranking quality.
Harness context deferred tools delta
{
"type": "deferred_tools_delta",
"addedNames": [
"CronCreate",
"CronDelete",
"CronList",
"EnterWorktree",
"ExitWorktree",
"NotebookEdit",
"RemoteTrigger",
"SendMessage",
"TaskOutput",
"TaskStop",
"WebFetch",
"WebSearch"
],
"addedLines": [
"CronCreate",
"CronDelete",
"CronList",
"EnterWorktree",
"ExitWorktree",
"NotebookEdit",
"RemoteTrigger",
"SendMessage",
"TaskOutput",
"TaskStop",
"WebFetch",
"WebSearch"
],
"removedNames": [],
"wireHiddenNames": [],
"readdedNames": [],
"pendingMcpServers": [],
"needsAuthMcpServers": [],
"failedMcpServers": []
}Harness context agent listing delta
{
"type": "agent_listing_delta",
"addedTypes": [
"claude",
"Explore",
"general-purpose",
"Plan",
"statusline-setup"
],
"addedLines": [
"- claude: Catch-all for any task that doesn't fit a more specific agent. FleetView's default when no agent name is typed. (Tools: *)",
"- Explore: Read-only search agent for broad fan-out searches — when answering means sweeping many files, directories, or naming conventions and you only need the conclusion, not the file dumps. It reads excerpts rather than whole files, so it locates code; it doesn't review or audit it. Specify search breadth: \"medium\" for moderate exploration, \"very thorough\" for multiple locations and naming conventions. (Tools: All tools except Agent, Artifact, ExitPlanMode, Edit, Write, NotebookEdit)",
"- general-purpose: General-purpose agent for researching complex questions, searching for code, and executing multi-step tasks. When you are searching for a keyword or file and are not confident that you will find the right match in the first few tries use this agent to perform the search for you. (Tools: *)",
"- Plan: Software architect agent for designing implementation plans. Use this when you need to plan the implementation strategy for a task. Returns step-by-step plans, identifies critical files, and considers architectural trade-offs. (Tools: All tools except Agent, Artifact, ExitPlanMode, Edit, Write, NotebookEdit)",
"- statusline-setup: Use this agent to configure the user's Claude Code status line setting. (Tools: Read, Edit)"
],
"removedTypes": [],
"isInitial": true,
"showConcurrencyNote": false
}Harness context skill listing
{
"type": "skill_listing",
"content": "- dataviz: Use this skill whenever you are about to create ANY chart, graph, plot, dashboard, or data visualization, in ANY output medium — an HTML or React artifact, inline SVG, plotting code in any library (matplotlib, plotly, d3, Recharts, …), an image/PNG you will render and upload, or a chart shared into Slack. Read it BEFORE writing the first line of chart code, choosing chart colors, building a stat tile / meter / KPI row, or laying out a dashboard. When the destination is a first-party document connector (host-designated, never self-described) that renders live charts, hand it the rows (inline, or as an uploaded data file the chart cites) rather than a rendered PNG/SVG — a picture of a chart loses hover, data inspection and per-value comments. Produces visualizations that read as one system — elegant, accessible, consistent in light and dark — using a brand-neutral placeholder palette you swap for your own. Teaches a design-system-agnostic method: a form heuristic, a color formula with a runnable validator, mark specs, and interaction rules. A validated default palette is documented in `references/palette.md` — swap that file's values for your brand's. Triggers on: \"chart\", \"graph\", \"plot\", \"data viz\", \"visualization\", \"dashboard\", \"analytics\", \"visualize data\", \"categorical colors\", \"sequential / diverging palette\", \"stat tile\", \"sparkline\", \"heatmap\", \"legend\", \"axis\", \"tooltip\", \"chart colors\", \"color by series\".\n- update-config: Use this skill to configure the Claude Code harness via settings.json. Automated behaviors (\"from now on when X\", \"each time X\", \"whenever X\", \"before/after X\") require hooks configured in settings.json - the harness executes these, not Claude, so memory/preferences cannot fulfill them. Also use for: permissions (\"allow X\", \"add permission\", \"move permission to\"), env vars (\"set X=Y\"), hook troubleshooting, or any changes to settings.json/settings.local.json files. Examples: \"allow npm commands\", \"add bq permission to global settings\", \"move permission to user settings\", \"set DEBUG=true\", \"when claude stops show X\". For simple settings like theme/model, suggest the /config command.\n- keybindings-help: Use when the user wants to customize keyboard shortcuts, rebind keys, add chord bindings, or modify ~/.claude/keybindings.json. Examples: \"rebind ctrl+s\", \"add a chord shortcut\", \"change the submit key\", \"customize keybindings\".\n- code-review: Review the current diff, or a PR number/branch/path target, for correctness bugs and reuse/simplification/efficiency cleanups at the given effort level (low/medium: fewer, high-confidence findings; high→max: broader coverage, may include uncertain findings); with no level given, it reuses the level you typed last. Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after the review.\n- simplify: Review the changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Quality only — it does not hunt for bugs; use /code-review for that.\n- fewer-permission-prompts: Scan your transcripts for common read-only Bash and MCP tool calls, then add a prioritized allowlist to project .claude/settings.json to reduce permission prompts.\n- loop: Run a prompt or slash command on a recurring interval (e.g. /loop 5m /foo). Omit the interval to let the model self-pace. - When the user wants to set up a recurring task, poll for status, or run something repeatedly on an interval (e.g. \"check the deploy every 5 minutes\", \"keep running /babysit-prs\"). Do NOT invoke for one-off tasks.\n- schedule: Create, update, list, or run scheduled cloud agents (routines) that execute on a cron schedule. - When the user wants to schedule a recurring cloud agent, set up automated tasks, create a cron job for Claude Code, or manage their scheduled agents/routines. Also use when the user wants a one-time scheduled run (\"run this once at 3pm\", \"remind me to check X tomorrow\").\n- claude-api: Reference for the Claude API / Anthropic SDK — model ids, pricing, params, streaming, tool use, MCP, agents, caching, token counting, model migration.\nTRIGGER — read BEFORE opening the target file; don't skip because it \"looks like a one-liner\" — whenever: the prompt names Claude/Anthropic in any form (Claude, Anthropic, Fable, Opus, Sonnet, Haiku, `anthropic`, `@anthropic-ai`, `claude-*`, `us.anthropic.*`, `[1m]`); the user asks about an LLM (pricing/model choice/limits/caching) — never answer from memory; OR the task is LLM-shaped with provider unstated (agent/MCP/tool-definition/multi-agent/RAG/LLM-judge/computer-use; generate/summarize/extract/classify/rewrite/converse over NL; debugging refusals/cutoffs/streaming/tool-calls/tokens).\nSKIP only when another provider is being worked on (overrides all triggers): OpenAI/GPT/Gemini/Llama/Mistral/Cohere/Ollama named in the query; OR `grep -rE 'openai|langchain_openai|google.generativeai|genai|mistralai|cohere|ollama'` over the project hits (run this grep FIRST if no provider named — don't Read the file).\n- workflow-authoring: Reference for writing a Workflow tool script (script API and gotchas, resume, quality patterns, worked examples). Load before authoring a script for a workflow the user already opted into; it does not itself authorize running one.\n- run: Launch and drive this project's app to see a change working. Use when asked to run, start, or screenshot the app, or to confirm a change works in the real app (not just tests). First looks for a project skill that already covers launching the app; otherwise falls back to built-in patterns per project type (CLI, server, TUI, Electron, browser-driven, library).\n- init: Initialize a new CLAUDE.md file with codebase documentation\n- security-review: Complete a security review of the pending changes on the current branch",
"skillCount": 13,
"isInitial": true,
"names": [
"dataviz",
"update-config",
"keybindings-help",
"code-review",
"simplify",
"fewer-permission-prompts",
"loop",
"schedule",
"claude-api",
"workflow-authoring",
"run",
"init",
"security-review"
]
}Harness context total tokens reminder
{
"type": "total_tokens_reminder",
"text": "<total_tokens>15000000 tokens left</total_tokens>"
}