Geeth गीत

Context

Popularity-based recommendation is self-reinforcing. A song needs signal to be surfaced, and needs to be surfaced to earn signal. Work that never clears that threshold is not judged and rejected — it is simply never heard.

Geeth starts from the opposite premise: judge the song on the song.

Why it matters

Every listener has the experience of finding something excellent that almost nobody has heard, and no reliable way to repeat it. The interesting product problem is not more recommendations — it is a floor. Something that guarantees the overlooked gets evaluated on merit.

Product approach

• Represent songs by their audio, not their metadata — embeddings first, popularity signals second or not at all.
• Give the listener a reason. A recommendation without an explanation is indistinguishable from noise.
• Optimise for the discovery moment, not for session length.

System direction

Interface. Next.js, TypeScript, Tailwind

Services. FastAPI, Python

Store. Postgres with pgvector for embedding search

Audio. LAION-CLAP for audio–text embeddings, librosa for signal features

LLM. Planner and explainer — query understanding and articulating why a track surfaced

Major decisions and tradeoffs

• The LLM does not rank. It plans and explains. Putting a language model in the ranking path makes results unreproducible and hides the actual retrieval quality.
• Audio embeddings over collaborative filtering — accepting a colder start in exchange for not inheriting the popularity bias the product exists to counter.
• pgvector over a dedicated vector database, so retrieval stays next to relational data at this scale. Revisit when corpus size, not curiosity, demands it.

What I'd do next

• Establish an evaluation for discovery quality that is not a proxy for popularity.
• Test explanation formats — does saying why a track surfaced change whether people trust it?
• Stress the cold-start path on genuinely obscure catalogue.