Earnings Call Embeddings

What are earnings call embeddings?

Each earnings call transcript is chunked into semantically coherent segments and vectorized using Google's gemini-embedding-2-preview model, producing 768-dimensional dense vectors optimized for cosine similarity search.

All data is bitemporal: every embedding chunk carries an effective_ts (when the earnings call occurred) and a knowledge_ts (when VectorFin ingested and vectorized the data), enabling point-in-time backtesting without look-ahead bias.

Typical use cases: semantic search across earnings calls, cross-ticker similarity, earnings surprise detection, quant factor construction, and grounding LLM answers through Retrieval-Augmented Generation (RAG).

Retrieval-Augmented Generation systems are only as good as their retrieval step. Generic embedding models miss a lot of financial language, and building your own over thousands of earnings calls takes months. VectorFin ships that retrieval layer as a data product.

A typical financial RAG pipeline with VectorFin:

1. Embed the user query with gemini-embedding-2-preview.
2. Run vector similarity over VectorFin's transcript and filing chunks (REST or Iceberg).
3. Pass the top-k chunks as context to your LLM with citations.

Because every chunk is keyed by ticker, fiscal_period, and chunk_idx, citations come free. And because everything is bitemporal, you can safely answer historical questions (“what did management say about margins in Q2 2022?”) without future-information leakage. That matters for backtested RAG evaluations and regulated use cases.

The model documents Matryoshka-style truncation, so a shorter prefix of a 768-dim vector still works as a valid embedding of the same chunk. No re-embedding, no separate model.

Two ways to use it: (1) query Gemini at a smaller dimension with output_dimensionality=256, where Gemini renormalizes automatically; (2) slice the stored 768-dim vectors client-side and renormalize yourself. Either way, a cheap first-pass retrieval at a smaller width can be re-ranked against the full 768-dim vectors for precision, all from one corpus.

*A small benchmark delta between higher and lower dimensions, per Google's model card. Dimension is orthogonal to effective_ts / knowledge_ts, so point-in-time RAG works identically at any width.