RAG Development · Seattle, WA

Custom RAG development in Seattle.

A production RAG system is mostly a cloud architecture problem wearing a machine learning hat. The retrieval pipeline has to live inside your existing VPC, respect your IAM model, share your observability stack, and stay inside your unit economics at the volume your product actually does. The model choice is roughly the last interesting decision.

We build cloud-native RAG pipelines for Seattle engineering teams on AWS Bedrock with OpenSearch vector, Azure AI Search for Microsoft-heavy orgs, and self-managed alternatives when the volume or cost profile demands it. The engagements we like best start with someone on your team who has already mapped the retrieval pipeline on a whiteboard.

Pricing is scoped per engagement depending on cloud surface, document scale, and observability requirements.

How we work

Tell us about your cloud architecture and the retrieval pipeline you need to land inside it.

The cloud-engineering reality of production RAG.

A demo RAG built on a vendor SDK and a hosted vector store takes a weekend. A production RAG that serves a million users inside an enterprise AWS account takes a quarter of careful engineering. The difference is everything that touches IAM, VPC, observability, cost, and the standard cloud-team operating model. At Amazon, Microsoft, Expedia, and Zillow scale, that operating model is non-negotiable.

The standard AWS pattern we deploy: documents in S3 with versioning and event notifications, ingestion handled by Lambda or Step Functions, embeddings via Bedrock (Titan, Cohere, or Anthropic embeddings depending on language and domain), vectors in OpenSearch Serverless with the k-NN plugin, generation via Bedrock Claude or InvokeModel against whatever foundation model fits the task. PrivateLink endpoints for Bedrock and OpenSearch keep all of it inside your VPC.

The Azure pattern looks different but solves the same problem. Azure AI Search now ships with integrated vector and hybrid search and (critically for Microsoft-stack orgs) handles security trimming against Entra ID and SharePoint permissions automatically. For a Tableau or Auth0 deployment integrated into a Microsoft 365 enterprise, this is usually the right default. Azure OpenAI provides the inference layer; Cosmos DB or Azure Database for PostgreSQL handle structured metadata.

Cost engineering is where most teams underbudget. A naive production RAG calling text-embedding-3-large on every ingestion change and Claude Sonnet on every query lands at $0.04 to $0.08 per query at moderate scale. At 50,000 queries a day, that's $60k to $120k per month. With caching, model tiering, and right-sized embedding choices the same workload comes in at $10k to $20k per month with no user-visible quality difference. We design for that from the first sketch.

What we build for Seattle teams.

Six components, each shaped by how AWS and Azure deployments actually go to production.

AWS Bedrock + OpenSearch deployment

Documents in S3, embeddings via Bedrock Titan or Cohere, vectors in OpenSearch Serverless k-NN, generation via Bedrock Claude or InvokeModel. PrivateLink endpoints keep traffic inside your VPC. CloudFormation or CDK for repeatable infra.

Azure AI Search integration

Vector and hybrid search via Azure AI Search with semantic ranker. Security trimming against Entra ID and SharePoint permissions handled at the index layer. Azure OpenAI for inference, Cosmos DB or Azure Postgres for metadata.

Cost-engineered ingestion path

Embedding caching keyed by content hash to avoid re-embedding unchanged chunks. Batch ingestion via Step Functions or Azure Data Factory. Cost telemetry surfaced in CloudWatch or Azure Monitor so you can see per-query spend before it surprises you.

Latency-budgeted query path

Sub-500-ms end-to-end retrieval and generation through warm Lambda or container endpoints, in-region embedding and re-ranking, and streaming generation. Latency budget broken out per stage and measured in production via OpenTelemetry.

Caching and model tiering

Redis or ElastiCache for hot-query results. Model tiering between Claude Haiku 4.5 for citation lookup, Claude Sonnet or GPT-5 for synthesis. Embedding model selection (Titan, Cohere, text-embedding-3-large) chosen against your actual cost and accuracy profile.

OpenTelemetry instrumentation

Distributed traces across every retrieval stage with chunk IDs, similarity scores, and re-ranker scores as span attributes. Exported to Datadog, Honeycomb, X-Ray, or Azure Monitor so production debugging happens in your existing tool.

Built for Seattle engineering teams.

Seattle is a cloud town. Amazon and Microsoft are the two largest cloud providers in the world and they ship from here. Most technical teams in the city, whether at AWS itself, Microsoft, Expedia, Zillow, Redfin, Tableau, Auth0, or any of the hundreds of cloud-native startups around South Lake Union, have a meaningful opinion about where their compute and data live. That opinion drives the RAG architecture, not the other way around.

Real-estate tech is a quiet leader in Seattle RAG adoption. Zillow, Redfin, and the in-house teams at Compass and other brokerages run enormous property document libraries (MLS listings, inspection reports, title searches, comparable sales) that are exactly the right shape for retrieval-augmented search. The user-facing search experience and the internal agent-facing answer engine are typically two different surfaces on the same pipeline, with different latency budgets and different cost profiles per query.

Travel tech is the second major vertical. Expedia and Vacasa both deal with vast volumes of hotel descriptions, rental property listings, and supplier content that needs to be searchable in natural language. The pipeline shape mirrors the real-estate one but with the additional complication of multilingual content (BGE-M3 or Cohere multilingual embeddings become the right default rather than text-embedding-3-large). We deploy these the same way: AWS-native if you're already there, Azure-native if you're a Microsoft shop, no architectural religion either way.

Questions from Seattle engineering buyers.

How do you deploy a RAG pipeline cleanly on top of an existing AWS account using Bedrock?: Most of our Seattle deployments land on Bedrock for inference plus OpenSearch Serverless with the k-NN plugin for vectors. The architecture is: documents land in S3, Lambda triggers an ingestion pipeline (Bedrock embeddings via the InvokeModel API, chunk metadata into DynamoDB), and the retrieval handler is either a Lambda behind API Gateway or an ECS Fargate task depending on latency and concurrency requirements. PrivateLink endpoints for both Bedrock and OpenSearch keep traffic off the public internet, which matters for any team operating under existing AWS security baselines. We have also delivered the same shape against the new Bedrock Knowledge Bases service when the team wants a more managed surface.
What's the right choice between Azure AI Search and a self-managed vector store for a Microsoft-heavy org?: If the team is already in Azure and running Microsoft 365 with Entra ID, Azure AI Search with its vector and hybrid search capabilities is usually the right default. You get the integrated security trimming (documents respect the SharePoint and Entra permissions of the requesting user), built-in semantic ranker on top of vector retrieval, and the deployment matches your existing security review process. The case for a self-managed alternative (pgvector on Azure Database for PostgreSQL, or Weaviate on AKS) is when you need either fine-grained control over the HNSW parameters or significantly lower per-vector cost at scale beyond roughly 100 million vectors. For Redfin, Zillow, or similar real-estate tech-scale catalogs, self-managed often wins on cost. For internal Microsoft-stack knowledge bases, Azure AI Search wins on integration.
How do you keep query latency under 500 ms when retrieval, re-ranking, and generation all add up?: Budget allocation matters more than picking the fastest component. A typical sub-500-ms budget breaks down: 30 ms for query embedding (cached aggressively), 60 to 80 ms for vector search on a properly-sized HNSW index, 100 to 150 ms for cross-encoder re-ranking on the top 30 results, and 200 to 300 ms for token-streamed generation. The win comes from running the embedding model and re-ranker in the same region and VPC as the vector store (cross-region calls eat 40 to 60 ms each), warming Lambda containers for the retrieval path, and using streaming generation so time-to-first-token rather than time-to-last-token is what the user feels. For high-traffic deployments we also push frequently-asked queries into a Redis or ElastiCache cache keyed on a normalized query hash.
How do you instrument a RAG system so we can debug production retrieval issues?: OpenTelemetry traces on every stage: query received, query rewritten, embedding generated, vector search executed, re-ranker scored, context assembled, generation requested, response returned. Spans carry the retrieved chunk IDs, similarity scores, and re-ranker scores as attributes. We export to whatever you already use (Datadog, Honeycomb, AWS X-Ray, Azure Monitor) so production debugging happens in your existing tool. When a user complains that an answer is wrong, you can trace the exact query, see which chunks were retrieved, and decide whether the bug is in chunking, embedding, retrieval, or generation. Without this instrumentation, RAG quality issues are almost impossible to debug after the fact because the retrieval state is gone.

Ready to scope your pipeline?

Send us your cloud architecture, your document scale, and your latency and cost targets. We reply within one business day with concrete recommendations and a price range.

Custom RAG development in Seattle.

Pricing is scoped per engagement depending on cloud surface, document scale, and observability requirements.

The cloud-engineering reality of production RAG.

What we build for Seattle teams.

Six components, each shaped by how AWS and Azure deployments actually go to production.

AWS Bedrock + OpenSearch deployment

Azure AI Search integration

Cost-engineered ingestion path

Latency-budgeted query path

Caching and model tiering

OpenTelemetry instrumentation

Built for Seattle engineering teams.

Questions from Seattle engineering buyers.

How do you deploy a RAG pipeline cleanly on top of an existing AWS account using Bedrock?

Most of our Seattle deployments land on Bedrock for inference plus OpenSearch Serverless with the k-NN plugin for vectors. The architecture is: documents land in S3, Lambda triggers an ingestion pipeline (Bedrock embeddings via the InvokeModel API, chunk metadata into DynamoDB), and the retrieval handler is either a Lambda behind API Gateway or an ECS Fargate task depending on latency and concurrency requirements. PrivateLink endpoints for both Bedrock and OpenSearch keep traffic off the public internet, which matters for any team operating under existing AWS security baselines. We have also delivered the same shape against the new Bedrock Knowledge Bases service when the team wants a more managed surface.

What's the right choice between Azure AI Search and a self-managed vector store for a Microsoft-heavy org?

If the team is already in Azure and running Microsoft 365 with Entra ID, Azure AI Search with its vector and hybrid search capabilities is usually the right default. You get the integrated security trimming (documents respect the SharePoint and Entra permissions of the requesting user), built-in semantic ranker on top of vector retrieval, and the deployment matches your existing security review process. The case for a self-managed alternative (pgvector on Azure Database for PostgreSQL, or Weaviate on AKS) is when you need either fine-grained control over the HNSW parameters or significantly lower per-vector cost at scale beyond roughly 100 million vectors. For Redfin, Zillow, or similar real-estate tech-scale catalogs, self-managed often wins on cost. For internal Microsoft-stack knowledge bases, Azure AI Search wins on integration.

How do you keep query latency under 500 ms when retrieval, re-ranking, and generation all add up?

Budget allocation matters more than picking the fastest component. A typical sub-500-ms budget breaks down: 30 ms for query embedding (cached aggressively), 60 to 80 ms for vector search on a properly-sized HNSW index, 100 to 150 ms for cross-encoder re-ranking on the top 30 results, and 200 to 300 ms for token-streamed generation. The win comes from running the embedding model and re-ranker in the same region and VPC as the vector store (cross-region calls eat 40 to 60 ms each), warming Lambda containers for the retrieval path, and using streaming generation so time-to-first-token rather than time-to-last-token is what the user feels. For high-traffic deployments we also push frequently-asked queries into a Redis or ElastiCache cache keyed on a normalized query hash.

How do you instrument a RAG system so we can debug production retrieval issues?

OpenTelemetry traces on every stage: query received, query rewritten, embedding generated, vector search executed, re-ranker scored, context assembled, generation requested, response returned. Spans carry the retrieved chunk IDs, similarity scores, and re-ranker scores as attributes. We export to whatever you already use (Datadog, Honeycomb, AWS X-Ray, Azure Monitor) so production debugging happens in your existing tool. When a user complains that an answer is wrong, you can trace the exact query, see which chunks were retrieved, and decide whether the bug is in chunking, embedding, retrieval, or generation. Without this instrumentation, RAG quality issues are almost impossible to debug after the fact because the retrieval state is gone.

Ready to scope your pipeline?

Send us your cloud architecture, your document scale, and your latency and cost targets. We reply within one business day with concrete recommendations and a price range.