While working on a data project involving tech stacks from job descriptions, I experienced one of those moments that changes how you think about a technology. I was scraping job boards to extract tech stacks mentioned in descriptions and associate them with companies. The goal was simple: build a searchable database that could tell me which companies use specific technologies.

After loading this data into Pinecone (a vector database), I started querying for "companies which use Snowflake." To my surprise, even when a company explicitly mentioned Snowflake in their tech stack description, the matching scores were disappointingly low—around 0.3-0.4 out of 1.0.

This confused me. If a company profile contains the word "Snowflake" and my query includes "Snowflake," shouldn't there be a near-perfect match? But when I modified my query to "companies using Snowflake for data warehouse," the matching scores significantly improved.

This was my epiphany: vector matching isn't about matching words; it's about matching meanings.

What I Did: The Project Setup

Let me walk through the project that led to this realization:

1. Data Collection: I scraped job postings from various job boards, focusing on the technical requirements and tools mentioned in job descriptions.

2. Extraction: For each job posting, I extracted the company name and identified the technologies mentioned in the description. This created a dataset where each company was associated with their tech stack.

3. Vector Embeddings: I converted these tech stack descriptions into vector embeddings using a language model that transforms text into numerical representations.

4. Database Storage: These vectors were stored in Pinecone, making them searchable by semantic similarity.

5. Query Testing: I started testing queries like "companies using Snowflake" or "startups with Python experience."

What Happened: The Unexpected Results

When I queried for "companies which use Snowflake," I expected companies that mentioned Snowflake explicitly to have matching scores close to 1.0. Instead:

• Companies that explicitly mentioned "Snowflake" scored only 0.3-0.4 in similarity

• When I changed my query to "companies using Snowflake for data warehouse," the scores improved significantly

• Adding context about how the technology was used dramatically increased matching quality

This pattern repeated across different technologies. Simple keyword queries performed worse than contextual queries that described how the technology was used.

The Learning: Vector Semantics vs. Keyword Matching

This experience taught me a fundamental lesson about vector embeddings:

Vector matching is fundamentally about semantic similarity, not keyword matching.

When we create vector embeddings of text, we're not just encoding the presence of specific words. Instead, we're encoding the meaning and context of those words. This has several important implications:

1. Context Matters: The word "Snowflake" alone has multiple potential meanings. It could refer to the data warehouse technology, actual snow, or even a personality type. The embedding model needs context to know which meaning is intended.

2. Usage Patterns: How a technology is used provides essential context. "Snowflake for data warehouse" carries much more specific semantic information than just "Snowflake."

3. Semantic Neighborhoods: Vector spaces organize concepts by meaning. Adding relevant words that share the semantic neighborhood (like "data warehouse" with "Snowflake") helps locate the intended meaning more precisely.

Understanding Vector Embeddings

To explain why this happens, let's dive deeper into how vector embeddings work:

What Are Vector Embeddings?

Vector embeddings are numerical representations of words or phrases in multi-dimensional space. Each dimension captures some aspect of meaning. Words with similar meanings cluster together in this space.

For example, in a simplified 3D space:

• "Database" might be at coordinates (0.2, 0.8, 0.3)

• "Data warehouse" might be at coordinates (0.25, 0.75, 0.35)

• "Snowflake" (the weather phenomenon) might be at (0.9, 0.2, 0.7)

• "Snowflake" (the technology) might be at (0.3, 0.7, 0.4)

The proximity of points represents semantic similarity.

Why Single Terms Can Be Ambiguous

The word "Snowflake" alone is ambiguous:

• It could refer to frozen precipitation

• It could be the data warehouse technology

• It could describe a person sensitive to criticism

• It could mean unique or special (like "every snowflake is unique")

When you query just "Snowflake," the embedding represents an average of all these meanings. This dilutes the specific technical meaning we want.

How Context Disambiguates

When you add "for data warehouse" to "Snowflake," you're providing crucial context that pulls the embedding firmly toward the technical meaning. This eliminates ambiguity and improves matching.

Practical Takeaways for Vector Search

This experience gave me several practical insights for working with vector databases:

1. Be Specific in Queries: Include relevant context about how technologies are used.

2. Consider Ambiguity: Be aware of terms that might have multiple meanings across different domains.

3. Test Different Phrasings: Try variations of your query to see which produces the best results.

4. Understand Your Embedding Model: Different models handle context differently. Understand how yours works.

5. Quality Over Quantity: A single, well-formulated query with proper context often outperforms multiple vague queries.

The Growing Complexity of Search

As our digital world expands, searching has become increasingly difficult. We've moved far beyond the days when a simple keyword match was sufficient. Today's search problems are multi-dimensional:

1. Volume Challenge: The sheer amount of data we need to search through has exploded exponentially.

2. Ambiguity Problem: Terms have multiple meanings across different domains and contexts.

3. Intent Detection: Understanding what a user is actually looking for beyond the literal words they use.

4. Contextual Relevance: What's relevant depends not just on keywords but on user context, history, and domain.

5. Specificity vs. Recall: Finding the right balance between precise (but possibly narrow) results and comprehensive (but possibly diluted) results.

In my tech stack project, this complexity became evident when trying to search for specific combinations of technologies within company profiles.

The Multi-Faceted Search Problem

Multi-faceted searches—where we're looking for entities that satisfy several criteria simultaneously—represent an even bigger challenge:

• "Companies using Snowflake AND Python AND located in Seattle"

• "Job postings requiring Kubernetes experience BUT NOT requiring on-call rotations"

• "Teams using GraphQL WITH React FOR e-commerce applications"

These complex queries expose several difficulties:

Vector Dilution

When we combine multiple concepts in a single query, we risk "diluting" the vector representation. The embedding might end up in a semantic space that doesn't truly represent any of the individual concepts well.

For example, creating a single embedding for "companies using Snowflake and Spark for real-time analytics" might produce a vector that's equidistant from specialized Snowflake-only and Spark-only vectors, potentially missing the best matches for either.

Balancing Facet Importance

Not all facets of a multi-part query are equally important. Should "Snowflake" be weighted more heavily than "Seattle" in our search? Vector searches don't inherently provide a way to specify these weights.

Handling Exclusions

Traditional vector search doesn't handle negations well. How do you represent "NOT requiring on-call rotations" in a vector space that's designed to find similarities rather than differences?

Solutions Emerging

To address these challenges, advanced vector search implementations now use:

1. Hybrid Search: Combining traditional keyword filtering with vector semantic search

2. Multi-Vector Queries: Breaking queries into component vectors and combining results

3. Re-Ranking: Using multiple passes where initial results are re-scored with secondary criteria

4. Filtered Vector Search: Applying metadata filters before or after vector similarity matching

In my project, I found that breaking down complex queries into component parts and then combining the results often worked better than trying to encode everything into a single vector query.

Conclusion: The Power and Complexity of Semantic Search

What initially seemed like a limitation—"why doesn't Snowflake match Snowflake perfectly?"—turned out to be both the strength and the challenge of vector search. Unlike traditional keyword search, vector search understands context and meaning, but this comes with increased complexity in query formulation.

This makes it more powerful but also requires us to think differently. We need to feed it not just what we're looking for but also the context that helps disambiguate our intent. And for complex, multi-faceted searches, we often need to employ sophisticated strategies that combine the best aspects of traditional search with the semantic power of vectors.

The next time you're working with vector embeddings and search, remember: don't just search for a word; search for a meaning. And when searching for multiple things, consider whether your approach should combine multiple targeted searches rather than a single diluted one.

Have you had similar experiences with vector search? What were your "aha moments" working with this technology? How do you handle complex, multi-faceted searches? Share in the comments below!