Loading…
RAG Development · Portland, OR
Portland engineering teams at Nike, Intel Hillsboro, Columbia Sportswear, and Vacasa are already deploying internal AI tools. The ones that stick are built on retrieval, not hallucination. We build the retrieval layer: vector stores, hybrid search, reranking, and the evaluation harness that tells you when it breaks.
Most Portland-based Series B and C companies we talk to have tried a RAG proof-of-concept. The prototype works in demos. It fails in production because the chunking strategy was guessed, not measured, and nobody set up evals. We fix that.
The VP Engineering at a Series B SaaS company who needs a customer-facing AI feature shipped this quarter. The Head of Data at an established Portland employer who wants internal search across product documentation, contracts, and support tickets. The CTO at a Hillsboro-area hardware company who needs retrieval over technical specs and compliance docs.
What they share: they want production code, not notebooks. They have an existing stack (usually AWS or Azure, sometimes GCP) and do not want to bolt on a third-party AI platform they cannot control. They measure success by query latency and answer accuracy, not demo quality.
Who this is not for: teams that want us to pick their use case. If you do not have a defined document corpus and a user persona with a stated problem, we recommend a paid discovery sprint before committing to a full RAG build.
Document parsing, chunking strategy selection (fixed-size, sentence, recursive, semantic), overlap tuning, and metadata enrichment. We test chunk configurations against real queries before settling on a strategy. Most teams we inherit from used 512 tokens because a tutorial said so. We measure.
Embedding model selection (OpenAI, Cohere, open-source), vector database setup (Pinecone, Weaviate, pgvector, Chroma), and namespace or tenant isolation for multi-tenant products. We work with your existing vector store if you have one already deployed.
Keyword search (BM25) alongside vector similarity, with a reranker (Cohere Rerank, cross-encoders) to re-score the top candidates before passing to the LLM. Hybrid retrieval consistently outperforms pure vector search on heterogeneous document types. Most Portland teams need it.
A question-answer test set built from your actual queries, RAGAS-style faithfulness and relevancy scoring, and a CI gate that fails when accuracy drops. We also set up retrieval logging so you can see which chunks are getting hit and which queries are falling through.
Portland companies tend to run lean engineering teams that do not want to manage additional infrastructure. That shapes how we build: we default to managed vector databases over self-hosted, serverless inference over dedicated GPU, and incremental sync over full re-index. The goal is a RAG system your three-person data team can own without a dedicated ML platform engineer.
We also see a lot of Portland companies with mixed document types: internal wikis, Notion exports, PDF specs, and Slack message history all in the same retrieval scope. That requires different parsing pipelines for each source and a metadata schema that lets you filter by source type at query time. We build the pipeline, not just the vector store.
Data residency is increasingly relevant for Portland companies working with enterprise clients in regulated industries. If your customer base includes healthcare or financial services clients, we design the architecture around US-only deployment from the start rather than retrofitting it later.
Ingestion, retrieval, and generation running in your cloud environment under your API keys.
A scored test set of real queries with pass/fail CI gates. You know when quality degrades.
Chunking rationale, embedding choices, retrieval flow, and the trade-offs we considered and rejected.
Query logs, retrieval hit rates, latency percentiles, and LLM cost tracking in your observability stack.
A working session with your engineering team covering the codebase, tuning levers, and how to extend the corpus.
We stay engaged for 30 days post-launch to fix retrieval issues that only surface with real user queries.
A standard chatbot generates answers from training data that goes stale. RAG retrieves from your live documentation, product knowledge base, or proprietary data before generating. For a Portland SaaS company like Vacasa or Puppet, that means answers stay accurate as your product changes without retraining.
For a well-scoped RAG project with a single document corpus, most Series B teams see a working prototype in 3-4 weeks and a production-ready system in 8-12 weeks. Scope is the main variable: a customer support RAG is faster than a multi-tenant knowledge graph serving different enterprise clients.
Yes. If you already have Pinecone, Weaviate, or Chroma set up, we build the retrieval pipeline on top of what exists. We evaluate whether your chunking strategy and embedding model match your query patterns, and fix the gaps rather than rebuilding from scratch.
Cost depends on scope: a single-corpus internal tool costs less than a multi-tenant product feature with hybrid search and reranking. We send a fixed-price proposal after a discovery call, once we understand what you're building.