unstarred

Which repos would you have starred already, if you had seen them? A two-tower retrieval model trained on public star histories reads your stars and your own repos, and ranks the corpus you haven't seen. An LLM sits on top in three load-bearing roles: it fingerprints every candidate README (the cold-start path), it writes your taste dossier, and it is the librarian you can talk to. The librarian never picks a repo. It compiles your words into queries against the trained space and the fingerprint index; every recommendation is a K-NN hit from the model.

A recommendation is resemblance to starring behavior, never a quality verdict.

The result

unstarred v3, two towers of 64 dims (logQ-corrected in-batch softmax) over 1,015,374 star events from 9,331 users. Held out by time: the test set is the 203k stars users actually added after the 80th-percentile timestamp, scored against a 362k-repo corpus.

recall on 144,193 future stars (6,879 users)	@10	@50	@100	MRR@100
unstarred v3 (served)	2.24%	6.89%	10.45%	0.0102
fingerprint-off ablation	2.35%	7.10%	10.72%	0.0108
shuffled-label control	1.09%	4.02%	6.65%	0.0047
GitHub-star popularity (trending)	0.03%	0.24%	0.28%	0.0001

Three honest readings:

• The shuffled control did not collapse to trending, and that is the most interesting number here. With the logQ correction, a model trained on shuffled labels can learn exactly one thing: which repos are popular inside this corpus. So 6.65% is the corpus-popularity floor, a far stronger blind ranker than GitHub trending (0.28%). The personalization is what stands above it: 1.6x at recall@100, 2.1x at recall@10 and MRR. Taste matters most at the top of the shelf.
• The LLM fingerprints are neutral in the tower (10.72% without vs 10.45% with, within noise). Their value is elsewhere: the semantic search, the cold-start index and every pitch on a card come from them, none of which the towers provide.
• One test star in ten is in the model's top 100 out of 362k repos, from nothing but the order people starred things in.

Caveats

• The corpus is who we crawled. 9,849 currently-active starring users from GH Archive. Their taste sets the candidate pool and its biases.
• Resemblance, not quality. A recommendation means people with similar star histories starred it, never that the code is good.
• Cold repos ride the LLM. Repos with thin interaction history are only as findable as their README fingerprint is accurate.
• 199 of the top-40k candidates ship without fingerprints (security tooling whose READMEs tripped the fingerprinting model's safeguards); they stay recommendable through the collaborative signal alone.

The two towers

Two small MLPs that project users and repos into the same 64-dim unit sphere, where the dot product is the recommendation score. The repo id embedding table is shared between the towers: the same 32-dim vector represents a repo when it is a candidate and when it sits in someone's history.

flowchart TB
    subgraph QT[query tower: who you are]
        h[last 30 starred repo ids] --> le[shared id embedding, 32d]
        le --> avg[masked mean over history]
        sc[taste scalars: volume, recency,<br>language entropy, own-repo profile] --> qc[concat]
        avg --> qc
        qc --> qd[Dense 128 relu -> Dense 64] --> qn[unit norm]
    end
    subgraph CT[candidate tower: what a repo is]
        rid[repo_id] --> ce[shared id embedding, 32d]
        strs[language + LLM fingerprint<br>category / maturity / audience, 8d each] --> cc[concat]
        nums[log stars, forks, size,<br>age, fork/archived flags] --> cc
        ce --> cc
        cc --> cd[Dense 128 relu -> Dense 64] --> cn[unit norm]
    end
    qn --> dot(("u . v / 0.05"))
    cn --> dot
    dot --> loss[in-batch softmax,<br>logQ-corrected for popularity]
    style dot fill:#a371f722,stroke:#a371f7,color:#e6edf3

Loading

Training pairs are (user history before t, repo starred at t): predict the next star from everything before it, sampled negatives being the rest of the batch. Uncorrected, in-batch sampling punishes popular repos (they appear as negatives in proportion to their popularity); the logQ correction subtracts log P(item) so the score is taste, not rarity.

At serving the towers split: the candidate tower runs once per pipeline over the corpus into an online KNN index (repo_embeddings), the query tower runs per request on KServe against your live GitHub stars. A shelf is one dot product away from a cold start.

Architecture

An FTI (feature, training, inference) system on Hopsworks. Feature extraction is one shared, pure module (unstarred_features.py), imported by the feature pipeline, the trainer, and the serving predictor, so training and serving cannot skew.

flowchart LR
    gh([GH Archive bulk]):::ext
    api([GitHub REST API]):::ext
    raw([raw READMEs]):::ext
    subgraph FE[Feature]
        gh --> f1[discover_users] --> f2[pull_interactions]
        api --> f2 --> se[(star_events)]:::hops
        f2 --> rp[(repos)]:::hops
        f2 --> ow[(own_repos)]:::hops
        raw --> f3[fingerprint_readmes + Claude batch] --> fp[(repo_fingerprints + KNN)]:::hops
    end
    subgraph TR[Training]
        se --> fv{{unstarred_fv}}:::hops --> t[two-tower Keras + controls] --> m[(Model Registry)]:::hops
        rp --> fv
        fp --> fv
    end
    subgraph INF[Inference]
        m --> i1[embed_candidates] --> emb[(repo_embeddings + KNN)]:::hops
        m --> i2[query tower on KServe]
        i2 --> app[unstarred app: shelf + dossier + librarian]
        emb --> app
        fp --> app
    end
    classDef hops fill:#10b98122,stroke:#34d399,color:#e5e7eb;
    classDef ext fill:none,stroke:#6b7280,color:#9ca3af,stroke-dasharray:4 3;

Loading

The file-by-file map:

unstarred_features.py   shared, pure: API objects -> rows; user history -> taste scalars
discover_users.py       F1  GH Archive WatchEvents -> active starrer seed list   (job)
pull_interactions.py    F2  API snowball -> star_events, repos, own_repos        (job)
fingerprint_readmes.py  F3  READMEs -> Claude fingerprints -> repo_fingerprints  (job)
train_towers.py         T   unstarred_fv -> two-tower + controls -> registry     (job)
embed_candidates.py     I1  candidate tower over corpus -> repo_embeddings       (job)
predictor.py            I2  KServe: login -> live pull -> user vector + profile
app/server.py           I3  the app: shelf, dossier, ask-the-librarian
deploy_*.py             one per job/deployment/app

Data

All public and free. GH Archive hourly event dumps (bulk, no auth) to discover currently-active starring users; the GitHub REST API (5000 req/hr with any free token) for full per-user star histories with starred_at timestamps and each user's own public repos; READMEs via raw.githubusercontent, snapshotted on one capture date so no text from after the temporal split leaks in. Captures are kept out of git.

Honesty rules

• Metric is recall@k / MRR on stars users actually added after the temporal split; features only ever see the window before it.
• Blind baseline is popularity in the feature window: what a trending list gives everyone. If the model cannot beat that, it has learned nothing personal.
• Controls: shuffled-label run (must collapse) and a fingerprint-off ablation (reported either way).
• The model registry keeps every version, including retired ones, with their metrics and the note why.

Reproduce

Clone into a Hopsworks project on the /hopsfs/... FUSE mount. Paths self-derive. Secrets: GITHUB_TOKEN, ANTHROPIC_API_KEY in project secrets.

python deploy_discover.py     && hops job run discover-users        # F1
python deploy_pull.py         && hops job run pull-interactions     # F2 (hours, resumable)
python deploy_fingerprints.py && hops job run fingerprint-readmes   # F3
python deploy_train.py        && hops job run train-towers          # T
python deploy_embed.py        && hops job run embed-candidates      # I1
python deploy_serving.py                                            # I2 KServe
python app/deploy_app.py                                            # I3 the app