Task instructions
+00:00Task instructions
Improve a production music-discovery two-tower
You have joined the recommendations team for a music streaming service. The "Made for You" shelf is served by a mature production two-tower model. Its chronological data protocol and indexed serving path are sound, but its offline retrieval quality no longer clears the team's next launch gate.
Your job is to investigate the production model, improve its retrieval quality, and ship a better ranking artifact. Use the implementation and public validation data to form and test your own diagnosis.
The source used to reproduce the production model is included under /task/current_model/. You may copy it into /app/solution/, edit it, add tests, and improve its training objective, but keep the data protocol, two-tower serving contract, and evaluation boundary intact.
Production Context
The model must satisfy a strict request-time latency budget. Item vectors are precomputed offline. At request time, one user vector is computed from observed interaction history and compared with candidate item vectors by a batchable two-tower score. Do not introduce a cross-encoder, per-candidate sequence model, or user-ID lookup table.
The current trainer is a mature baseline with chronological internal validation. Focus your investigation on how its training objective selects and uses negative examples. Diagnose limitations in the current negative-sampling strategy and improve it under the fixed CPU budget. Validate changes with the public backtest. The final approach must still train and rank within the supplied CPU environment while preserving the serving and data boundaries above.
What You Have
All public inputs are under /task/data/. A stage cutoff is the timestamp at which observed history and candidate eligibility are frozen for a ranking. The public validation stage cutoff is 24786800, when train_* ends. A 30-minute gap precedes the seven-day val_* window. For the final submission, that validation window becomes observed history, and another 30-minute gap precedes the hidden seven-day outcome window.
The package includes:
/task/current_model/train_current_model.py: the production training and ranking script. It can reproduce the public validation ranking and produce a hidden-test submission after refitting./task/current_model/two_tower_model.py: model primitives used by the production script./task/evaluate_public.py: the public validation evaluator for development./task/data/validation_eligible_candidates.npzand/task/data/test_eligible_candidates.npz: platform-owned candidate sets for the validation and hidden-test cutoffs./task/data/validation_preference_state.parquetand/task/data/test_preference_state.parquet: active explicit preference state at the corresponding cutoffs./task/requirements.txt: the exact offline Python distribution inventory.
You can reproduce the production public backtest with:
python /task/current_model/train_current_model.py \
--stage validation \
--public-dir /task \
--output /app/solution/production_validation.parquet
python /task/evaluate_public.py /app/solution/production_validation.parquet
Data
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:
- For model development and selection, train only from
train_*and score the subsequentval_*outcomes. - After selecting an improvement, 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").
Validation candidates exclude all train_* encounters. Test candidates exclude all train_* and val_* encounters. 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 same 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.
Deliverable
Submit one final ranking as /app/solution/submission.parquet or /app/solution/submission.csv. It must be a regular file, not a symbolic link. If both files exist, the verifier evaluates submission.parquet and ignores submission.csv.
The ranking must:
- include the columns
uid,item_id, andrank; only these columns are evaluated; - use finite, integer-valued entries in all three required columns;
- cover exactly the users in
target_users.parquet, with no missing or extra users; - contain exactly 100 rows and 100 distinct items for every target user;
- contain every integer rank from 1 through 100 exactly once per user; and
- use only items present in that user's
test_eligible_candidates.npzcandidate set.
Also leave the improved implementation used to build the artifact at /app/solution/train_current_model.py, along with any local modules it imports. A concise /app/solution/README.md with the diagnosis, before-and-after public score, model change, and submission command is useful for the experiment record, but it is not an automated acceptance gate.
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.
- Do not alter cutoff definitions, target users, candidate eligibility, or relevance labels.
- Improve the production pipeline in place. Do not substitute an unrelated model family or evade the indexed two-tower serving constraint.
- The environment includes CPU PyTorch 2.8.0. No accelerator is available.
- You have up to 60 minutes. Prioritize measured validation improvements, a correct final refit, and a valid submission over broad architecture search.
- Keep the best valid submission saved throughout the attempt so it survives the deadline.
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>"
}