RAG Development · San Francisco, CA

Custom RAG development in San Francisco.

Retrieval-augmented generation is a pipeline problem, not an embedding problem. The teams that get this right have spent more time on chunking strategy, metadata schemas, and evaluation harnesses than on picking which embedding model is two points better on MTEB.

We build production RAG systems for San Francisco SaaS companies, AI platforms, and developer tooling teams. The engagements that go well start from a clear question: what does the user query distribution actually look like, and what does "correct" mean for each query type. The rest is engineering.

Pricing depends on document volume, query complexity, and the evaluation bar, and we scope it with you before any work begins.

How we work

Tell us about your retrieval architecture or the one you're about to build.

Retrieval is a pipeline problem.

A working RAG system has roughly seven stages: document ingestion, parsing, chunking, embedding, indexing, retrieval, and generation. Each one has independent failure modes. A team that swaps text-embedding-ada-002 for text-embedding-3-large and sees no quality improvement is almost always bottlenecked upstream of embeddings, on chunking that splits sentences in the middle of definitions, or on a metadata schema that makes pre-filtering impossible.

The chunking decision alone has more design space than most teams realize. Fixed-size chunks with overlap are the baseline. Recursive character splitting respects paragraph boundaries. Semantic chunking (via SBERT or a sliding-window similarity pass) groups topically related sentences. Layout-aware chunking using a model like unstructured.io or LayoutLMv3 respects document structure. Each one is right for different document types. For a Stripe-style API reference, layout-aware wins. For a Notion knowledge base, recursive splitting on heading hierarchy is usually best.

Embedding model selection is the most over-discussed and under-impactful decision in the stack. The current sensible defaults are text-embedding-3-large from OpenAI for general purpose work, Voyage AI's voyage-3 family for finance and legal corpora, and BGE-M3 when you need multilingual or self-hosted. The MTEB leaderboard differences between the top models are typically 1 to 3 points; the differences from getting chunking right are 10 to 20 points.

Hybrid search (BM25 plus dense) outperforms either alone on almost every enterprise corpus we have benchmarked. The reason is simple: dense embeddings handle paraphrase well but lose on rare proper nouns and exact technical terms (product SKUs, API endpoint names, function signatures). BM25 catches what dense misses. Reciprocal rank fusion or a learned weighting on top gives you both. This is the move that quietly takes a system from 78 percent answer accuracy to 89 percent.

What we build for SF technical teams.

Six components, each chosen for engineering teams who already know what RAG is and want it built well.

Chunking strategy benchmarking

We benchmark recursive, semantic, and layout-aware chunking on your actual corpus and report recall@5 and answer accuracy for each. Final chunking config is the result of a measured comparison, not a default.

Embedding model selection

Head-to-head evaluation of text-embedding-3-large, Voyage-3, BGE-M3, and (if licensing supports) Anthropic-recommended embeddings on your domain. Cost-per-million-tokens and recall numbers in the same report.

Hybrid search with RRF

Dense vectors paired with BM25 via reciprocal rank fusion or a learned alpha. Implemented on pgvector with tsvector, Weaviate hybrid, or OpenSearch with the knn plugin depending on what your platform already runs.

Re-ranker integration

Cohere Rerank v3, Voyage rerank-2, or self-hosted BGE Reranker tuned to your domain. We measure the precision lift against the latency cost and recommend only when it earns its place.

Ragas evaluation harness in CI

Faithfulness, answer relevancy, context precision, and context recall metrics running on every pull request against a domain-specific test set. Regressions block merge. Drift is visible from week one.

Cost-engineered inference path

Embedding caching by content hash, retrieval-stage Redis cache for hot queries, and model tiering (Haiku/GPT-5 mini for simple lookups, Sonnet/GPT-5 for synthesis) to keep monthly inference cost predictable at scale.

Built for San Francisco engineering buyers.

San Francisco is the densest concentration of technically sophisticated RAG buyers in the world. Anthropic and OpenAI ship the foundation models. Databricks and Snowflake (with its SF presence) ship the data platforms underneath them. Salesforce, Stripe, Notion, Figma, Airtable, and most of the YC mid-stage cohort are building retrieval-backed product features on those foundations. The bar is correspondingly high. SF engineering teams know what HNSW is, have an opinion on cosine versus dot product, and want a vendor who can have the actual conversation.

The build-versus-buy framing matters more here than anywhere else. A Series B SaaS team in SoMa is staffed with senior engineers who could absolutely build a RAG pipeline in-house. The question is opportunity cost. A six-week external engagement that delivers a benchmarked production pipeline plus the evaluation harness frees those engineers to work on the actual product differentiator. We are honest about the cases where in-house is the right call (you have specific domain constraints, you have time, you have the right people) and the cases where it isn't.

We deploy where you already run. AWS us-west-2 (Oregon) is the standard SF default for proximity. GCP us-west1 and Azure West US 2 are equally well-supported. For teams already deep on Modal, Fly.io, or Vercel, we deploy the retrieval pipeline alongside whatever you're using rather than introducing a new ops surface.

Questions from SF engineering buyers.

How do you pick between pgvector, Pinecone, and Weaviate for a production SaaS deployment?: The decision is mostly about operational surface area, not raw recall. For most production SaaS workloads under roughly 50 million vectors per tenant we recommend pgvector on the existing Postgres instance: HNSW index, halfvec storage to halve the memory footprint, and the standard cosine ops. You inherit your existing Postgres backups, point-in-time recovery, IAM, and observability. Pinecone wins when you need serverless scaling past a few hundred million vectors and want zero index-management work. Weaviate is the choice when you genuinely need hybrid search with BM25 in the same engine and dont want to run a separate OpenSearch cluster. We benchmark all three against your actual query distribution before recommending.
What evaluation harness do you build, and why isn't a vibes-based demo enough?: We use Ragas for the standard metrics (faithfulness, answer relevancy, context precision, context recall) and add a domain-specific test set of 100 to 300 question-answer pairs derived from your real user queries. The harness runs on CI: any change to chunking, embedding model, retrieval parameters, or prompt template kicks off a benchmark run and posts a diff to the pull request. Without this, every retrieval system regresses silently. We have seen production RAG systems lose 15 percent of their answer accuracy over six months from drift that nobody noticed because nobody was measuring. The harness is the unsexy part of a real engagement and the part that determines whether the system still works in a year.
When does a re-ranker like Cohere Rerank actually earn its place in the pipeline?: Re-rankers are worth their token cost when your top-k recall is high but top-5 precision is the metric users actually feel. If you embed with text-embedding-3-large and retrieve top 50, the right answer is in that set most of the time, but it might be at position 27. A cross-encoder re-ranker (Cohere Rerank v3, BGE Reranker, or Voyage rerank-2) re-scores those 50 with full query-document attention and pushes the right answer into the top 3. The latency cost is 80 to 200 ms; the quality gain is typically 10 to 15 percent on top-5 precision for enterprise corpora. We skip re-ranking when the corpus is small enough that the embedding model alone already nails it, or when the latency budget is sub-300 ms end to end.
How do you keep token costs sane on a production system serving 100k queries a day?: Three levers. First, embedding caching at the chunk level: text-embedding-3-large is roughly $0.13 per million tokens, so we hash chunks and only re-embed on content change. Second, retrieval-stage caching for hot queries via Redis with a normalized query key; in most B2B SaaS workloads 20 to 30 percent of queries hit cache. Third, model tiering on the generation step: a Claude Haiku 4.5 or GPT-5 mini handles the long tail of simple lookups (citation extraction, factual recall) while Claude Sonnet or GPT-5 handles complex synthesis. At 100k queries per day this typically lands monthly inference cost between $4k and $9k rather than the $25k-plus you would see calling Sonnet for every request.

Ready to scope your pipeline?

Send us your current retrieval architecture, query patterns, and the metric you care about most. We reply within one business day with concrete pipeline recommendations and a price range.

Custom RAG development in San Francisco.

Pricing depends on document volume, query complexity, and the evaluation bar, and we scope it with you before any work begins.

Retrieval is a pipeline problem.

What we build for SF technical teams.

Six components, each chosen for engineering teams who already know what RAG is and want it built well.

Chunking strategy benchmarking

Embedding model selection

Hybrid search with RRF

Re-ranker integration

Cohere Rerank v3, Voyage rerank-2, or self-hosted BGE Reranker tuned to your domain. We measure the precision lift against the latency cost and recommend only when it earns its place.

Ragas evaluation harness in CI

Cost-engineered inference path

Built for San Francisco engineering buyers.

Questions from SF engineering buyers.

How do you pick between pgvector, Pinecone, and Weaviate for a production SaaS deployment?

The decision is mostly about operational surface area, not raw recall. For most production SaaS workloads under roughly 50 million vectors per tenant we recommend pgvector on the existing Postgres instance: HNSW index, halfvec storage to halve the memory footprint, and the standard cosine ops. You inherit your existing Postgres backups, point-in-time recovery, IAM, and observability. Pinecone wins when you need serverless scaling past a few hundred million vectors and want zero index-management work. Weaviate is the choice when you genuinely need hybrid search with BM25 in the same engine and dont want to run a separate OpenSearch cluster. We benchmark all three against your actual query distribution before recommending.

What evaluation harness do you build, and why isn't a vibes-based demo enough?

We use Ragas for the standard metrics (faithfulness, answer relevancy, context precision, context recall) and add a domain-specific test set of 100 to 300 question-answer pairs derived from your real user queries. The harness runs on CI: any change to chunking, embedding model, retrieval parameters, or prompt template kicks off a benchmark run and posts a diff to the pull request. Without this, every retrieval system regresses silently. We have seen production RAG systems lose 15 percent of their answer accuracy over six months from drift that nobody noticed because nobody was measuring. The harness is the unsexy part of a real engagement and the part that determines whether the system still works in a year.

When does a re-ranker like Cohere Rerank actually earn its place in the pipeline?

Re-rankers are worth their token cost when your top-k recall is high but top-5 precision is the metric users actually feel. If you embed with text-embedding-3-large and retrieve top 50, the right answer is in that set most of the time, but it might be at position 27. A cross-encoder re-ranker (Cohere Rerank v3, BGE Reranker, or Voyage rerank-2) re-scores those 50 with full query-document attention and pushes the right answer into the top 3. The latency cost is 80 to 200 ms; the quality gain is typically 10 to 15 percent on top-5 precision for enterprise corpora. We skip re-ranking when the corpus is small enough that the embedding model alone already nails it, or when the latency budget is sub-300 ms end to end.

How do you keep token costs sane on a production system serving 100k queries a day?

Three levers. First, embedding caching at the chunk level: text-embedding-3-large is roughly $0.13 per million tokens, so we hash chunks and only re-embed on content change. Second, retrieval-stage caching for hot queries via Redis with a normalized query key; in most B2B SaaS workloads 20 to 30 percent of queries hit cache. Third, model tiering on the generation step: a Claude Haiku 4.5 or GPT-5 mini handles the long tail of simple lookups (citation extraction, factual recall) while Claude Sonnet or GPT-5 handles complex synthesis. At 100k queries per day this typically lands monthly inference cost between $4k and $9k rather than the $25k-plus you would see calling Sonnet for every request.

Ready to scope your pipeline?

Send us your current retrieval architecture, query patterns, and the metric you care about most. We reply within one business day with concrete pipeline recommendations and a price range.