The problem with pure vector search
Vector search excels at semantic similarity — understanding that “package manager” and “npm” are related. It struggles with:- Exact project names (e.g. “carq”, “memcontext”)
- Company and product names
- Acronyms (e.g. “PNPM”, “JWT”)
- Concrete technical decisions (e.g. “chose PostgreSQL over MySQL”)
MemContext’s approach
MemContext combines two retrieval methods and merges their results:| Method | Strengths | Runs on |
|---|---|---|
| Vector search | Semantic similarity, paraphrased queries | pgvector embeddings (1536 dimensions) |
| Full-text search | Exact matches, keywords, names | PostgreSQL tsvector index |
Query variants
Before searching, MemContext generates alternative phrasings of your query using an LLM. For example:- Original: “What database does the project use?”
- Variant: “database technology PostgreSQL MySQL choice”
- Variant: “which database was selected for this project”
Configuring search precision
Thethreshold parameter controls how strict the vector search is:
| Threshold | Behavior | Use case |
|---|---|---|
0.2 - 0.4 | Strict matching, fewer results | High-precision lookups for specific facts |
0.6 | Default balance | General-purpose retrieval |
0.7 - 0.8 | Broad matching, more results | Exploratory searches, gathering related context |