Embeddings are a good starting point for the AI curious app developer

Original Article ↗ Hacker News Discussion ↗

Embeddings—numeric vectors that represent text or images—are highlighted as an accessible way for developers to add semantic search and recommendation features without diving deep into full LLMs. Commenters trade practical advice on running embedding models locally, storing vectors in existing databases like Postgres or SQLite versus dedicated vector stores such as Pinecone, and when simple brute‑force cosine similarity is enough. They also dig into conceptual questions around what embeddings really are, how they relate to older techniques like bag‑of‑words and TF‑IDF, and where they fall short on issues like homonyms and context.

Running embeddings locally and in databases

  • Multiple options cited for local embedding generation: Rust libraries, Candle-based wrappers, SentenceTransformers, HuggingFace models, CLIP models inside Postgres extensions, Ollama/BERT-based models, and Supabase’s built‑in embedding API.
  • Embeddings can be stored in “boring” databases as arrays of floats; vector DBs or extensions (pgvector, sqlite‑vss, Redis vector search) mainly help with fast similarity search.
  • Some prefer keeping DBs “dumb” (no HTTP calls/cron logic), others like DB‑integrated pipelines that auto‑update embeddings.
  • Performance experiences vary: pgvector works fine for many up to low‑millions of vectors; others argue specialized systems (Pinecone, FAISS, hnswlib, etc.) matter at larger scales.

Do you really need a vector database?

  • Several commenters argue vector DBs are overkill for learning and small apps: brute‑force cosine similarity with NumPy/Pandas or in‑memory arrays is often fast enough.
  • Others emphasize convenience and ecosystem support, especially outside Python, as reasons to adopt vector stores early.
  • Cost and operational overhead of hosted vector DBs are raised as concerns for hobby projects.

What embeddings are and how to understand them

  • Debate over pedagogy: some advocate starting with bag‑of‑words / TF‑IDF + cosine similarity to build intuition; others call that a “dead end” that misleads about modern embeddings.
  • Clarifications that simple word‑count vectors are document embeddings, not word embeddings; useful but high‑dimensional and crude.
  • Discussion connects older IR methods (BoW, co‑occurrence matrices, PMI, SVD) to modern word embeddings, with disagreement on how strong that conceptual link is.
  • Several readers want deeper explanations of how embeddings are trained and why they exhibit properties like analogies; others argue you don’t need that depth to be productive.

Limitations: homonyms, style, meaning

  • Homonyms cause amusing but problematic results (e.g., “king” → “ruler” tool icons, “rodent” → computer mice); context and attention mechanisms are seen as necessary to disambiguate.
  • Hybrid search (keyword + semantic), richer descriptions, rerankers, user feedback, and contextual queries are suggested mitigations.
  • Questions arise about using embeddings for style rather than semantics; some think it’s possible but may require classifiers on top, others see current embeddings as too crude.

Use cases and experimentation

  • People report success using embeddings for semantic search (docs, icons, images, resumes, news clustering, deduplication), recommendation, and SEO/“topical authority” understanding.
  • Many emphasize embeddings as a low‑friction, deterministic entry point into AI for app developers, even if the underlying models remain “black boxes.”