The wave logs each served candidate's feature vector to rec_impression_features.
Nightly training joins them with impression outcomes, validates on the last week
and activates the model only when it beats the v1 order and the active model.
The service loads the active ranker and uses its order in place of the v1 score.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
New `ci / db` job with a pgvector service: Go applies all migrations,
rolls them back to zero and applies them again, then runs the scanner,
fingerprint, write-template, top-tracks and upload-queue store queries;
Python runs the analysis worker, catalog / profile loading and a full
ALS training run against the same schema. Until now this SQL ran
nowhere before reaching a real server.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- migration 00006: track features and embeddings (pgvector, HNSW),
analysis queue filled by a trigger on new tracks, wave sessions and
impressions, recommender profiles, model versions
- analyzer basic-1 (ADR-014): ffmpeg decode, three 30 s excerpts,
256-d timbre/rhythm embedding, tempo by onset autocorrelation, key,
loudness, energy, danceability, acousticness, intro length; worker
with SKIP LOCKED claims, retries and re-analysis on version change
- wave engine v1: candidates (session/taste similarity, fresh,
liked artists, rediscover, popular, exploration, seed), filters
(dislikes, played in 3 h, already served), heuristic score, activity
and mood fit from contexts.yaml with relaxing thresholds, MMR with
one track per artist, exploration share, session vector updated by
reactions and a change of course after three skips
- POST /internal/wave/batch with the catalog index cached in memory
and the session kept in Redis
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
mrleo1nidandClaude Opus 5.5